> > >From my perspective, it would be really, really cool if HURD grew up to be
> > a media OS,
>
> The main objective of a "media OS" is real time processing.
> The Hurd has nothing to do with it, as scheduling is entirely done in the
> microkernel (there are systems where the policy for scheduling is outside
> the kernel, though). So support of real time tasks has to be done in the
> kernel.
Though there is an aspect of timing constraints, I think there's more. For
one, some old layering concepts will have to be tossed to bring the
software back down to the hardware. Applications likely need direct access
to many things (e.g. pushing pixels, low-latency audio). From what I
understand, the Hurd does a fair amount of delegation and moves many
things into user space. This already paves the way for implementation of
such a feature. For another, media manipulation tends to involve high
amounts of numerical processing and IO; to keep the OS "alive" to the user
it must be pervasively threaded. Isn't it already so? Besides .. there's a
gnumach isn't that right? It could be rtgnumach. I've read a lot about
rtmach.
It's not just about satisfying the requirements, it's also about
understanding the characteristics of and supporting the applications to
make it easy (or possible!) for them to do their jobs.
Anyone ever played with those noise canceller headsets? It is practically
impossible to implement such a thing in Linux, FreeBSD, Solaris, Windows,
Macintosh, etc .. etc .. but is possible under a media-optimized OS.
> > HURD is still in its early stages.
>
> Even if it was true (it isn't), the Hurd is not the place to implement the
> features you would like to see.
Yes, it's been in development for many years, but it is still fluid. It may
not make sense for the Linux kernel to "change directions" now, but
there aren't a lot of reasons why the Hurd cannot.
As for the features, though some of it belongs inside the kernel, like
scheduling, I think a lot of what's involved belongs as servers and just
pervasive ideas like keeping determinism in mind. How about a filesystem
is optimized for big files and that can deliver data as fast as it can be
processed? It's an implicit requirement for media systems, but the existing
filesystems aren't designed for this. I might not be "core Hurd", but it's
close.
> I think that you should write a real time microkernel that can run the Hurd
> :)
One of may tasks. And I would look into it if there is enough support from
the community.
I understand there's a general feeling that the Hurd is superior, and I
agree in the technical context. But what role do you all forsee the Hurd
taking in the current (and the new) world? Will it fill a new space or will
it displace something? If it's a new space, then great, I'd like to hear
all about it. But if it'll be displacing something that is widely used
today, I think some due consideration is in order about all the technical,
non-technical, rational and non-rational reasons why someone may or may
not choose to change. For example, I know about all the ways FreeBSD is
better than Linux, but I chose not to change because I'm just more
comfortable with it. I want to see the Hurd thrive but just like many
other technically better things, chances are that it will not if it's only
merit is its techical superiority. What are its other merits? What use
will people have for it?
