Kivio had actually been considered for the previous article. Your editor, however, had seen a tool which, apparently, could only draw lines and text. Thinking that kivio must be a little too young for a real review, your editor set it aside and moved on. Kivio users will understand the problem at this point: your editor missed the little icon (shown at left) in the toolbar which loads stencils into the system. Kivio, the main purpose of which is the creation of flowcharts, is all about stencils. A large set of stencils is provided with the program; they include the full library of shapes from Dia, national flags, a map of Belgium, UML symbols, and "people shapes" including a woman in a bikini. Working with kivio is really a matter of finding the stencils you like, dragging them onto the screen, and drawing lines between them.
Strangely, there seems to be no mechanism built into kivio for the creation and editing of stencils; they all would appear to come from the outside. Nothing in the menus or online documentation says anything about how to get stencils into the system. Unless, of course, you want to buy the proprietary stencil builder or get some stencils on a per-seat license from theKompany.com.
Kivio has a number of the features your editor was looking for, including layers, attachment points, etc. But the simple fact is that kivio is an awkward and difficult tool to work with. Attributes (colors, line widths, arrowheads, etc.) must be set individually for every object; there appears to be no way to get kivio to apply user-specified attributes to new objects. There is no way to adjust the dimensions of arrowheads (and, interestingly, the "start arrowhead" appears at the second point of the connector). Connectors can only be straight lines. Alignment operations are done via a separate, popup dialog. The "docker" feature, which puts tools like the layer manager on the edge of the diagram, looks cute, but the tools are forever popping in and out when the diagram is being edited. Kivio cannot export to an image file; it is limited to KOffice format or (via the print operation) PostScript or PDF.
Kivio is a reasonable tool for some simple tasks now, and may well develop into a capable, general-purpose diagram editor eventually. But it is not up to your editor's needs at this time.
Skencil (formerly "sketch") was highly recommended by some LWN commenters. Skencil, in its stable version, is a Tk-based vector drawing package. This tool is currently being reworked to use GTK instead, but that version is not yet ready for release. Skencil has many of the typical drawing functions, and it supports layers. It does not support attachment points, and it cannot export to image formats.
Once again, your editor found this tool to be awkward and frustrating to work with. The interface is highly modal and confusing at times. Changing the default attributes of objects is hard. The arc-drawing tool is very confusing to use at the outset (though, once you get the hang of it, it turns out to be a powerful tool). The alignment operations require dealing with a separate dialog.
On the other hand, skencil has some slick features, such as the ability to draw text along an arbitrary path. There is a plugin mechanism allowing the addition of new features programmed in Python. Skencil also can import images in a number of formats. It may well be a useful tool for those engaged in more artistic pursuits; it is not, however, the best diagramming tool out there.
Finally, your editor took a look at inkscape. As a drawing tool, inkscape has a nice feature set; it has a reasonable set of drawing options, a full set of path operations, etc. Perhaps the biggest omission is the lack of support for layers. For the creation of diagrams, however, inkscape is not the right tool. There are no attachment points, no arrowheads, and no image export. Inkscape's priorities are simply elsewhere.
Worth a quick mention: if your main interest is the creation of UML diagrams, Umbrello may be worth checking out. It is, however, very much a special-purpose tool, with UML assumptions wired deeply into it; as such, it's not suitable for more general purpose diagramming.
To conclude: your editor will stick with dia for now for his cheesy diagram creation needs. Of all the tools reviewed, dia stands out for its focus on this particular task, the quality of its output, and its ease of use. There is a lot of development happening in this area, however; the situation could well be different next year.2004 GCC & GNU Toolchain Developers' Summit will take place June 2nd through June 4th in Ottawa, Canada. GCC developers from around the world will get together to discuss the "state of the art," and the long term roadmap for GCC.
The conference presentations give some insight into the focus of the developers who are working on GCC, and technical direction for the project. For example, last year's GCC Developers' Summit included three talks on support for 64-bit systems, including the IBM's S/390 and x86-64 architecture. If last year's Summit is any example, you can expect GCC to include many of the features that are being talked about this year at the Summit.
One heavy focus that's carried over from last year is testing and benchmarking code produced by GCC. Árpád Beszédes of the University of Szeged will be speaking about the Code-Size Benchmark Environment (CSiBE) for GCC, which is used to measure the size of code produced by GCC. (Beszédes's paper from last year is available for those who are interested.) Paolo Carlini of SUSE is also focusing on performance in his presentation, on approaches being used to improve performance in the GNU Standard C++ Library v3 (libstdc++-v3).
David Edelsohn will present a paper on loop optimizations for GCC using high-level loop transformations. The loop optimizations described by Edelsohn are implemented on top of Tree SSA, which was an up-and-coming project for GCC when described at last year's GCC Developers' Summit. (Slides in PDF are available.) Now it's headed for inclusion in GCC 3.5. (See this week's Development Page for more information on Tree-SSA).
Diego Novillo will be speaking about the design and implementation of Tree SSA this year. According to Novillo, several other GCC optimizations are being implemented on top of Tree SSA as well. Dorit Naishlos will be speaking about another optimization technique, automatic vectorization, that is implemented on top of Tree SSA.
Users of the GNU Compiler for the Java Programming Language (GCJ) may be interested in Andrew Haley and Tom Tromey's paper on the new GCJ binary-compatibility ABI which will "let us upgrade the compiler and runtime library in many useful ways without requiring any application-level recompilation," instead of breaking binary compatibility with each new release. Nathan Sidwell's presentation will make the case for implementing statically typed trees in GCC, with an outline for a full conversion from dynamically typed trees.
In all, there are fifteen scheduled presentations, and two Birds of a Feather session, for the Summit. Abstracts for all of the paper presentations are available on the GCC Developers' Summit website. For those with a little extra time on their hands, registration for the event is open and it promises to be a fun three days for anyone interested in GCC and compiler development.an informal transcript of the proceedings.
The $50 million in capital which was pumped into SCO last October is usually termed the "BayStar investment," but, in fact, $30 million of that total came from the Royal Bank of Canada (RBC). RBC made a couple of interesting moves last week:
From RBC's point of view, the moves are perhaps understandable. The chances of ever getting the original investment back from SCO were small and shrinking; RBC (or whatever investor is hiding behind RBC) decided to cut its losses and get out while it still could.
BayStar's motivation is a little harder to comprehend. After all, BayStar stated last month that it wanted to redeem its investment in SCO and get out; now it has, instead, doubled the number of preferred shares it holds. One assumes that BayStar got the shares for less than their original price, but, given BayStar's public lack of confidence in SCO and its management, why is it increasing its stake in the company?
One possibility which has been raised is that BayStar wants to increase its leverage over the board of directors and thereby improve its chances of forcing management changes on SCO. The RBC shares, if converted, would give BayStar an approximately 20% stake in SCO; enough to be heard, but still nowhere near enough to dictate changes. Alternatively, BayStar may think that, by way of court, it can extract the full $40 million represented by those preferred shares from SCO.
The most ominous possibility, perhaps, is that BayStar may be maneuvering to take possession (or, at least, control) of the IBM suit after SCO collapses. That suit is, after all, the one SCO asset that BayStar sees as being worthwhile. In this scenario, the case could continue long after SCO collapses. BayStar could, conceivably, apply more financial resources to pursuing this case. But no amount of money can make SCO's claims any more legitimate.
Finally, SCO's second fiscal quarter ended on April 30; an earnings report is due within the next few weeks. One assumes that its results will be something other than spectacular. Expect the usual theatrics as SCO's management attempts to distract attention from the fact that the company is losing its traditional customers, is not selling "Linux licenses," and continues to bleed cash.
Page editor: Jonathan Corbet
Next page: Security>>
Copyright © 2004, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds