LWN.net Weekly Edition for December 9, 2004

The Linux roadmap

Certain proprietary vendors have long liked to criticize Linux for its lack of a "roadmap," a multi-year plan with release dates and included features. Without such a roadmap, they say, customers have no idea where the technology is going, cannot plan for the future, and have no assurance that needed features and capabilities will be built into Linux. This Information Week article is the latest contribution to this debate; the way the Linux kernel is developed, says the author, "...makes it even harder for technology professionals using Linux to plan around one major release that's, say, 18 months down the road." The lack of a roadmap is said to be a sign that the kernel development process has not yet "grown up."

We contend, instead, that the lack of a PowerPoint-friendly release and feature plan is a sign that the free software development process is different - and better.

It would be interesting to ask the aforementioned "technology professionals" how useful corporate roadmaps truly are - especially in the software arena. Betting the company on another vendor's promised future software releases seems risky at best. Relying on a vendor's claims for software which is available now is dangerous enough; competent "technology professionals" know that reality often fails to live up to those claims. The only way to know whether a given software release will work in a given situation is to try it, and trying it is difficult for releases which exist only on a timeline in some roadmap.

Then again, Linux can be said to have a roadmap which can make reasonably reliable predictions fairly far into the future. One need only look at the projects which are being worked on now. With a bit of research, anybody can see what features are contemplated, which of them work now, the amount of development effort which is going into those features, whose priorities are driving development, and more. So, for example, one might make some reasonable predictions about future distributions by looking at what the developers are doing today:

• They will almost certainly include enhanced security technologies, including mandatory access control mechanisms and, perhaps, heavier use of encrypted filesystems. SELinux looks likely to be the technology deployed by many distributors, unless the ongoing complexity issues end up forcing a shift to something else.

• The kernel will continue to scale to larger systems with more processors, memory, and disks. Some additional scalability work will be done for 32-bit systems, but the emphasis will be on using 64-bit processors to the fullest extent. There will be improved support for clustered filesystems, and, perhaps, for leading-edge, transactional filesystems as well. Future hardware will be quickly supported as long as the requisite information is made available to developers.

• The desktop experience will continue to improve, especially for business users. The available applications will continue to develop quickly, and future distributions will include advanced search capabilities. More home-oriented applications, including personal finance, high-end games, Feng Shui garden layout assistants, etc. will be rather slower to develop.

And so on. Predictions of this sort are somewhat unreliable, but they are nonetheless far more trustworthy than a corporate marketing department's rendition of an otherwise obscure development process.

Roadmaps can also force a company to ship what it promised, rather than what is best. Imagine if IBM were in charge of the Linux kernel, and that IBM had promised that 2.6 would include its own EVMS volume management software. Can you imagine IBM subsequently announcing that EVMS would be passed over for inclusion because the developers like the device mapper code better? If you make promises about future releases, you have to at least try to live up to those promises. It is hard to switch to an idea which turns out to be better in practice without losing credibility. Without this ability to make decisions based on what actually works and is maintainable, the free software development process would be weaker.

The final problem is that the free software development model is resistant to central planning in general. Linus Torvalds can express his vision and desire for future kernel developments, but he is unable (and unwilling) to force anybody to work on those developments. The community makes its own decisions about what it thinks is important. The results are often surprising, but the success of Linux so far makes it clear that they are meeting somebody's needs. Trying to impose a roadmap on this process is unlikely to improve it.

Comments (32 posted)

Vector graphics with Inkscape

With the release of Inkscape 0.40, we decided to take a look at the latest release and get up to speed with the status of the project. Inkscape started as a fork of the Sodipodi project, but has evolved into a robust project in its own right.

Inkscape is a drawing tool that uses the Scalable Vector Graphics (SVG) specification for its native format, and also exports to PNG, as well as saving in Adobe Illustrator format, PostScript, Encapsulated PostScript and PovRay formats. Inkscape will open or import graphics from Adobe Illustrator and Dia, other programs' SVG documents and a wide array of bitmap graphics formats. Inkscape runs on Linux, Windows and Mac OS X.

We installed the Inkscape static RPM on a SUSE 9.2 system to see what the program is capable of, and whether Inkscape was stable and feature-complete enough for productive use. The Inkscape download page on SourceForge includes source packages, RPMs and Windows binaries.

To test Inkscape we started off by creating basic shapes using Inkscape's rectangle and ellipse tools and fiddling with color fills, stroke styles, rotation and so forth just to get a feel for Inkscape's tools. It took about fifteen minutes for this writer to get comfortable with the Inkscape interface.

With an application like Inkscape, using a mouse (or tablet) is almost unavoidable. However, Inkscape's shortcut keys allow the user to perform a lot of actions, such as selecting different tools or raising and lowering an object from one layer to another, from the keyboard -- rather than having to grab the mouse to switch between tools or adjust layers. For example, to toggle the current tool from Inkscape's path tool to the select tool, all that's necessary is to hit the space bar or F1. To move an object up one layer, simply hit "Page Up" or "Page Down" to move it lower.

Speaking of layers, layer management is one of the major new features in Inkscape with the 0.40 release, according to the release notes.

Another new feature in 0.40 is a "text-on-path" feature. This allows the user to conform text to a path -- which is useful for creating interesting logos and other artwork that requires text to wrap text to a shape other than a rectangle. The feature is certainly easy to use. All that's required is to select a path and the text object that is to conform to the path. Rectangles, ellipses and other objects must be converted to a path before the user can wrap text to fit that object. By manipulating that object, the user can change the flow of the text even if the text has been removed from the object or if the object is "invisible" because there is no fill color or stroke color associated with the object. The only thing we couldn't figure out was how to specify a starting point on a path for the text.

We also enjoyed Inkscape's "Trace Bitmap" feature, which allows the user to trace an imported bitmap. By importing a photo or other bitmap, it's possible to create an scalable object that can then be turned into paths or otherwise edited in Inkscape. Inkscape has incorporated the potrace utility for this. The trace bitmap feature works best with line art, but can be used to produce some fun effects with photos or other artwork.

Inkscape's performance and stability are excellent. We created a number of documents using Inkscape, exported our documents and some of the Inkscape tutorials to PNG, EPS and PS, and didn't see any glitches. The program never crashed while we were testing, and all of the features that are currently in Inkscape seem to work as advertised. We did notice that some detail was lost when exporting to EPS from the tutorials, but this may not be an Inkscape limitation.

Though Inkscape doesn't have a full user manual at this stage, it does include several useful tutorials for basic and advanced concepts when working with Inkscape, as well as an excellent man page. It also features an "Elements of Design" document, which may be useful for users who lack a background in art and design. The Inkscape interface also features context help for most tools as well as context-sensitive tips in the bottom status bar.

For the most part, this writer found the interface to be straightforward and intuitive. The "Vacuum Defs" item under the File menu was a bit of a puzzler at first, though it was finally determined that it was for removing unused information from the defs tags in a document. We presume this is a good thing.

Some of Inkscape's functions can be used without even needing to start the Inkscape GUI. For example, inkscape file.svg -e file.png will convert an SVG file to a PNG. This can be particularly useful for users who wish to convert a number of SVG files into PNG format.

SVG experts can edit an SVG document directly, if they so choose, by using Inkscape's built-in XML editor. Very few users will be likely to need this tool, but it's there for those who need or want to edit a document's elements directly.

Inkscape may not be at the same level of functionality as Adobe Illustrator or Corel Draw, but it's certainly capable of creating some excellent graphics -- even if this writer isn't quite up to the task of fully exploiting its potential. With other open source applications like The Gimp and Scribus, Linux is a serious contender for users who are looking for a desktop publishing platform.

Comments (10 posted)

The Common Development and Distribution License

Sun has submitted a new license (the "Common Development and Distribution License" or CDDL) to the Open Source Initiative's license-discuss mailing list. This license, derived from the Mozilla Public License, may (or may not) be what Sun chooses to use for its possible open-source Solaris release, so it is worth a look.

This license is GPL-like in its intent, but (as Sun acknowledges up front) it is not compatible with the GPL. There are certain extra terms in the CDDL which, while not necessarily objectionable in their own right, conflict with the GPL's "no additional restrictions" terms. This incompatibility came as a surprise to few people; nobody has ever expected Sun to encourage the mixing of Solaris and Linux kernel code.

The CDDL licenses the copyrights in the code for use, distribution, and modification - the usual free software rights. It also contains a patent grant, but here the language is a bit more constrained:

In other words, the CDDL does not license any patents for use in derived products. Other terms in the license suggest that Sun is concerned about patent infringements caused by modifications, but the above exclusion is not restricted to such infringements.

The license requires that anybody distributing the code in binary form make the associated source available under the CDDL. The license says nothing about how the source must be made available; in theory, one could satisfy the license by requiring people to pick up the source in person at one's Mongolian software distribution center. Interestingly, the license allows the binaries themselves to be distributed under any license, so long as (1) the source is available under the CDDL, and (2) the person distributing binaries under a different license indemnifies the copyright holders for any liabilities.

Unlike the GPL, the CDDL allows developers to make modifications to the license text itself (for their own code).

The CDDL contains patent defense language: if you sue a copyright holder for patent infringement, you can lose your rights to use the code under the license. In any patent litigation settlement talks, the value of the patent license granted by the CDDL must be taken into account - essentially, the party initiating the lawsuit loses any patent license granted by the CDDL. There is one other strange term:

So if you are a software distributor, and you got the code from somebody who later turns around and sues Sun, you can lose your rights to the software under the license.

The discussion has been relatively muted; there seems to be an early consensus that the license, possibly with some small tweaks, is, indeed, a free software license. It will probably get the stamp of approval that Sun seeks. What Sun will then do with this license remains to be seen, however.

Comments (7 posted)

Page editor: Jonathan Corbet

Inside this week's LWN.net Weekly Edition

• Security: Review: Introduction to Computer Security; New vulnerabilities in hpsockd, imlib, rssh, viewcvs, ...
• Kernel: Page fault scalability; Improving kernel release quality; The fairest I/O scheduler of them all.
• Distributions: Fedora Core 3 on AMD64; Xandros Desktop 3 and RedHawk 2.2 released
• Development: The HP Linux Imaging and Printing System, new versions of KDar, pgAdmin, GParted, BBClone, mnoGoSearch, Logfmon, GNOME, KDE, GARNOME, SQL-Ledger, Eye of Gnome, Gaim, Konversation, Wine, Evolution, Thunderbird, Guikachu, AbiWord, GGV, gedit.
• Press: Venting on script kiddies and spammers, Sun's license choice, the Lycos DDoS, The Government Open Code Collaborative, embedded Gentoo, network file system choices.
• Announcements: PalmOS to be built on Linux, Fluendo funds Vorbis and Theora, Mandrakesoft financial analysis, OSDL and Bull work on POSIX Test Suite, Open Source Modeling and IDEs CFP, GUADEC 2005 CFP, ETech registration.
• Letters: RMS on "intellectual property"

Next page: Security>>