Linked by Eugenia Loli on Tue 30th Sep 2003 05:20 UTC
General Development In the dawn of the renovation of freedesktop.org's web site, David Zeuthen announced the release of HAL 0.1. HAL is an implementation of a hardware abstraction layer, as defined by Havoc Pennington's paper. It encompasses a shared library for use in applications, a daemon, a hotplug tool, command line tools and a set of stock device info files. Carlos Perelló Marín also announced the design of a similar concept, but it is expected the two projects to merge. More people are encouraged to join this innovative project. Elsewhere, Gnome's Seth Nickell is giving us a first taste of his effort to replace the Init system.
Permalink for comment
To read all comments associated with this story, please click here.
Re: oGALAXYo
by Rayiner Hashem on Wed 1st Oct 2003 01:51 UTC

There are some advantages to a tightly integrated kernel and desktop. They are *not* what most people think they are. Its not the number layers that affects the performance* but the inability to make hacks that make the system *seem* fast. Take BeOS for example. BeOS has never very fast. For most things, (compiling, untarring archives, etc) it has actually quite slow. However, the BeOS kernel was very well matched to the BeOS GUI. If there was a limitation in one component, a less general solution in another could make the problem go go away. WinXP provides a good example: In XP, when an application plays a sound, it gets a temporary priority boost. That's not a very general solution, but it works. Now, a correct solution is much harder to design, but is fully general. Linux must be built on these fully general solutions, because the kernel and the DE projects aren't tied together so closely. That's something that you can't avoid. To Linux, GNOME is just another C program, and to GNOME, Linux is just another UNIX. That's the way it should be --- that's proper program design.

PS> On the performance issue --- the only place all this layering is having an affect is in application startup speed. The correct solution is not the cop-out (to reduce the number of libraries, and thus developer convenience) but the smart one --- to optimize library loading. It would be a big boost if Linux supported the kind of optimized program loading that debuted in Windows XP, where the kernel tracks the pages needed in the first X seconds of an apps execution, and preloads those. That way, all the libraries would be loaded in one go. Also, prelinking will go a long way in fixing startup time issues.

PS2> Which libraries are you complaining about. I don't use GNOME, but I see a list of 41 libraries linked to Konqueror, and every single one is important.