Older blog entries for audriusa (starting at number 1)

21 Oct 2007 (updated 27 Oct 2007 at 14:26 UTC) »

GNU Classpath 0.96 - "Staying alive"

Again, a new version of GNU Classpath, our old Free java runtime library, has been released - GNU Classpath 0.96. Apart version numbers, many releases also have smart names: A La Mort Subite, All for One, One for All, Dreamland ... But for everybody who is more or less aware about the current history of java, the recent name of 0.96 sounds more aggressive than any previous. Staying alive. Too pretty to die.

Who have changed since the times of 0.93, when multiple GNU Classpath hackers, myself including, were demonstrating fully functional GNU Classpath Swing for the astonished public in a number of software conferences? How happened that the nine year old project with near two millions lines of code feels proud just surviving? Well, we, surely know: Sun have released the majority of its own java runtime library under GPL. Soon it will not be necessary to use and develop the GNU Classpath code just because it is Free when Sun's code is not. Unless, of course, other reasons would appear.

Somebody who is not aware about the current state of the GNU Classpath may say: that is fine, just merge the Sun's code in! However while Classpath continues getting multiple patches per day, no significant merging activity have ever been seen. The reason is simple: GNU Classpath implementation is too complete. There were several useless, non functional stubs in the past (RMI-IIOP implementation, for instance). However it is long time since they are replaced by the fully working code. There are no parts that are just non-functional, clearly deserving to be ripped out, stuffing the Sun's code instead. Or should we believe that any single line of code from Sun is doubtlessly better? Written by professionals? That do you know about the GNU Classpath team, if you think so?

Yes, there are tasks where the current Sun's 1.5 implementation (with some pretty proprietary stuff inside remaining, by the way) performs faster, but does this mean that GNU Classpath should now be abandoned? The programming user who does not want to spend any time comparing the sources of these two implementations would likely just pick the variant that is more efficient today. But it is possible to imagine projects that dig deeper than just using java. Now, then the Free Sun's implementation starts emerging, the major value of GNU Classpath may be in that it implementation is different.

From one side, GNU Classpath implements the same official API. But from the other side, no GNU Classpath hacker has ever been allowed to look into Sun's code while writing the alternative implementation. This means, that many or even majority of the algorithms in Sun's and GNU's implementations are realized differently. This opens a really exiting prospects to compare the solutions, picked by various developers when implementing exactly the same framework. From the first sight, this comparison may look very difficult and work-intensive to do. However we should not forget that (differently from GNOME and KDE, for instance) we speak about the system where the modules of the alternative implementations are aligned against each other. Packages consist of classes, classes consist of methods and these methods must have the exactly the same functionality implemented. Hence it is surely possible to compare package versus package, and in many cases it should be possible to compare even class against class. It may well be - and I personally am sure in this - that some methods, classes or even packages exist where GNU Classpath implementation may actually be better. Yes, that is not funny. During development I did a lot of side-by-side comparisons at least for CORBA and HTML parser (both were later continued by my friends) and have reasons to suspect that Sun might not be an absolute winner in all possible test cases. Also, it may be other parts of code where the better implementation can be written after comparing the two existing ones and learning from mistakes of both sides. It is not frequent to have opportunity to compare the two different implementations seriously, package versus package or may be even class versus class.

Hence it may well be that the best Free java runtime library is yet to be written, uniting the best solutions from Sun's, GNU Classpath and Apache Harmony implementations. Such project can be an independent initiative, but it also may start as a branch (or even head) of the GNU Classpath project. Hence a serious hacker can find a new ways to the future of the GNU Classpath. Ways that do not look just like a gradual decay. Ways that lead forward though staying alive.

6 Oct 2007 (updated 6 Oct 2007 at 19:13 UTC) »
Linux in the USB stick - direct installation

Recently I checked the old idea to install Linux into USB stick directly, as into any other hard drive. This would be very simple and straightforward approach: just plug in USB drive, boot from the installation CD and expect to the /dev/sda (or similar) between devices during installation. Then direct the installation into that drive and tell the installer to leave other disks alone. The approach is not directly dependent from the distribution and looked very attractive for beginners.

Debian have found the attached USB drive and fully completed the installation. In only asked me a couple of times if I really do not want a swap. I said I do not (how reasonable is to have a swap partition even on 4 Gb USB drive?). GRUB, however, was not configured correctly: in device map and menu.lst the pen drive (/dev/sda) appeared as hd2 and the flash did not even think to boot. However all I needed was to correct the boot device name to hd0 in menu.lst. The attempt to get rid of hard-coded /dev/sda name in /etc/fstab (using the LABEL approach) was also fully successful.

OpenSUSE that we use at work was even smarter in the beginning: GRUB was configured correctly and it was possible to boot from the flash immediately. Just fstab needed corrections to get rid of hard coded dependencies, again. Also, both Debian and OpenSUSE installers configured the graphic and network settings along the lines of the hardware that they have found on that particular machine - so if the machines from where you will need to boot are different enough, it is necessary to switch into something like VESA manually afterwards (xdebconfigurator seems a magic curse for Debian).

Still, I find this experiment interesting. It seems that with very little additional effort various Linux distributions could support USB stick a rather specific (generic drivers must be chosen) but still 'just one more hard drive'. I know that some distros have the 'install into USB stick' item on a user friendly level, but it does not necessary work well either. While I do needed to discover and fix several nonsenses myself, there are a lot of web sites where installation into USB drive is described as something horribly more complicated (see Debian instructions, for instance).

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!