Re: GNU/Hurd

["Torbjörn Gannholm" <torbjorn.gannholm@fra.se>]

Alan Cox wrote:

> > A possible minus is the message-passing between the servers which might
> > be time-consuming.
>
> "Yesterdays technology, next week" to quote an OSI saying

Possibly, but maybe Unix and Linux also are yesterdays technology in some sense,
but cooperative development is the future (and a small bit of the present) and I
think it's sad that science is held back because of money and prestige
(Although, mind you, I don't mind paying for software and giving credit where
it's due, but I want to know what it does and be able to change it if I think I
can do something better).

>
>
> > Still, my feeling is that this could be a real winner on flexibility and
> > performance. Any comments?
>
> If you want a pre-emptible OS core its not HURD. Being pre-emptible without
> deadlocks or other interesting suprises is a very very hard problem. Consider
> things like disk sorting algorithms when you have 40 blocks for a low pri
> process queued up with 2 for a real time one.

 Actually, for the most part I couldn't care less about preemptible or
real-time. I just want to get maximum cream out of my system (scaled to a
zillion cpus), and I want it to run until I kill it. Maybe I'm being boring, but
to watch video I use a TV, to listen to music I use a HiFi, reality is a lot
more interesting than virtual, and to run a nuclear power station I have
dedicated machines. And if I did want to use my computer for any of this I could
probably load the appropriate mechanisms if they existed and everything else is
nicely designed.

IMHO, maybe preemptibility is a fix rather than a solution and the solution lies
in another dimension.

But still, why wouldn't some implementation of HURD (or mach) be able to be
preemptible?

--
/Torbjörn

This message is a personal message from Torbjörn Gannholm
and does not necessarily represent the opinion of my employer.