On 9/16/07, address@hidden <address@hidden
> wrote:Of course any specific feature can, in theory, be added to existing
systems. That's Linus approach: Only adapt the system if there is a
specific problem at hand that requires it.
Since when? Lately, the Linux kernel has been adding a plethora of random useful features that weren't necessarily brought on by absolute need.
The difference is in the cost. With Linux (or other monolithic kernels),
any change at system level requires kernel hacking, which is very
involved. Moreover, for the changes to be realistically useful, they
need to go upstream, which requires even more involvement, costing a lot
of time and energy, and there is no guarantee that they it will even
succeed in the end.
The result is that much more often people settle for solutions based on
existing kernel features, which tend to be much more complicated,
fragile, limited, hard to setup and manage, and inefficient.
No. In the modern Linux kernel, people are constantly using third party modules, or even third party kernel patches. Neither of those require upstream access, and kernel module programming is not kernel level hacking.
I can give you a good many examples, too, of how lately there have been a lot of novel solutions that do things just as well as a Hurdish solution would do them, too. People innovate a lot on that platform, too, and rarely settle for "complicated, fragile, limited, hard to setup and manage, and inefficient" solutions.
With the Hurd, it's not only much easier to change functionality at
system level; but also the change can be immediately used, on any
machine running the Hurd -- without requiring consent from upstream or
from the admin. Even normal application programs can come with modified
Hurd servers, providing mechanisms better suited for the applicaton.
I'd like to see a really good example of how this privelege model can be applied. Say your kernel provides two needed things: one, necessary features to run standard software, and two, all the drivers for accessing hardware on the host system. What is there that could potentially need to be added, that couldn't be conceivably ran in the normal, traditional user space?
Linux now, for example, has an infrastructure that allows filesystem extensions, much like translators, to be ran in userspace.
I'm not saying the current Hurd implementation is already perfect in
this. Some things are still too hard to do, and I hope we can further
optimize the design over time. But even as it is, the Hurd is much more
powerful in this regard than any other system I know of, UNIX-compatible
or not.
-antrik-