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: @ Jason
by Nicolai on Tue 30th Sep 2003 12:35 UTC

This is getting really boring.

You see, if you know everything oh so perfectly well, then
a) why don't you tell the Freedesktop people about it. Apparently they're so stupid that they could really need your help!
b) why don't *you* do something? Why don't *you* check out the source to one of those libraries you claim are so uberslow [1] and actually fix it instead of whining and generally getting on everybody's nerve?

Not that the 2 functions would hurt, no the loading of these libraries do, specially under heavy load.

This might actually be valid criticism of the way dynamic library loading works on Linux-based systems. However, the solution is *not* axing libraries - that's something you could do in a top-down mandated environment, i.e. a proprietary operating system. However, it will never work in an open source environment.

This doesn't mean architectural improvements aren't possible. For example, one could try to improve sharing of dynamic libraries between adress spaces/processes (i.e. basically what the kdeinit hack does, but on a system-wide level).
There are two ways I believe this can be done:
a) implement library loading in the kernel
b) implement library loading in a system-wide dynamic library daemon; whenever an application needs to load a library, it contacts that daemon, which will load the library (if it hasn't already been loaded), relocates its symbols and provides a read-only mmap to the fully relocated library to the client application.

Has anyone ever made a real life test of GNOME or KDE under heavy load ? E.g. when copying big files across the harddisk.

Actually, yes, and interactive apps can come to a crawl when copying big files across partitions. That's mainly a kernel/scheduler problem, though. You'll notice that advanced console apps are affected by latency/responsiveness issues in that case, too.


[1] Yes, apparently there *are* some libraries using horribly inefficient algorithms out there. But in most cases, those libraries are able to survive because there's no alternative - and it's generally better to have *something* that works (even if it's slow) than to have nothing at all.