Re: A niche for the Hurd

[olafBuddenhagen]

Hi,

On Wed, Nov 12, 2008 at 11:12:28PM +0100, Michal Suchanek wrote:

> Since the brainstorming non-critique period is over I would like to
> point out where the Hurd failed to fulfill some expectations for me.

This doesn't at all fit the topic of this thread, which was about
finding niches for the Hurd... But I'll reply nevertheless.

> there was a severe design flaw at that time that limited the number of
> transactions any Hurd server can perform during its lifetime,
> including the filesystem servers. Each server allocated a thread for
> each transaction, and the threads were never freed

That's not entirely true. Threads are reused regularily; new ones are
allocated only when no worker threads are free. So problems only occur
when a huge number of requests comes in at the same time.

While fixing this properly will require some major work, there is a
surprisingly effective workaround in place... (Simply limiting the
number of threads.)

> which eventually lead to exhausting some system resources (probably
> some mach-specific MAXTHREAD) as the system would rune fine if the
> exhausted translator was killed and restarted.

Actually it is not a fixed limit. The kernel uses a "zone allocator" for
all kinds of kernel structures, and once the zone memory is exhausted, a
kernel panic occurs...

> This meant that a mail client repeatedly checking for new mail would
> eventually lock up the filesystem on which the mail spool is located,

No, it never meant that.

There are some locking bugs in the filesystem servers; but these are
entirely unrelated, and not a design problem.

> The second thing in which the Hurd was failing for me was innovation.
> 
> You can theoretically replace parts of the system or set up weird
> filesystems in the Hurd but that can be done with library preloading,
> chroots, virtualization, and FUSE on most platforms these days.

It's never about what is possible, it's always about what is realistic.

In theory, it's possible to implement pretty much anything on pretty
much any system. What differs is how much effort it takes. Many things
that require kernel changes and/or complicated user space solutions in a
traditional UNIX-like system, can be done in a much simpler and more
elegant way on the Hurd.

> Also there are no good samples of any actual functionality that is not
> available on the current UNIX-like systems.

Indeed, we are short on these. That's precisely what this thread is
about.

> The security model on the Hurd is the same "security" as that of UNIX
> so no improvement there. There might be different underlying security
> primitive in the Mach but it is translated to UNIX users in very
> lowlevel parts of the system

Not exactly, see other subthread.

> The GNU Mach is microkernel-like but still has the drivers in the
> kernel so no easy driver replacement, stable driver API or different
> API emulation

Indeed, this is a major shortcoming of the current implementation :-(

> (yes, it uses OSKit to emulate some particular version of Linux but is
> tied to that single version of a particularly unstable API).

Actually we do not use OSKit. There was an oskit-mach branch once, but
the developer who worked on it lost interest before it was really
usable, and as OSKit wasn't maintained upstream anymore, it didn't offer
any real advantages at that point.

ddekit seems an interesting option though: It is similar in spirit to
OSKit, but seems to be actively maintained...

(The present gnumach uses custom glue code, which is unfortunately badly
outdated...)

> Imagine the benefits of using the same OS-independent drivers with
> different systems..

I'm not really convinced that we need that. One of the great advantages
of free software is that code can easily be reused without fixing an
interface up front...

> As for the ROCK thing: you might be better off trying to port it to
> Coytos or one of its predecessors (EROS, KeyOS).
> 
> While Coytos is still in development its predecessors should be
> already usable for some specialized tasks (although I am not sure if
> they are available).

KeyKOS was (or still is?) used in production systems, but it's non-free,
and runs on mainframes.

EROS supposedly is used some production embedded systems. It is free and
runs on PCs as well, but it lacks a lot of components necessary for
everyday use AFAIK.

The Hurd is *much* closer to actual usability. (In fact, it's much
closer to that than any other true microkernel system I know of...)

> Unlike GNU Mach the Coyotos kernel supports multiple hardware
> platforms (arm,powerpc,.. ?) so it opens more interesting
> possibilities for actual implementation. Or was it just that no
> distributions of  the Hurd for any platforms other than x86 are built?

There used to be Mach ports for a few architectures, but nobody has been
interested in these for years.

> The one thing where EROS is innovative is persistence

"Innovative" is not really the right word here: Persistent systems
existed even before KeyKOS, several decades ago... It is true though
that this is quite distinctive compared to all current mainstream
systems.

Do we really want this kind of persistence, though? I think it is quite
a useful feature in certain kinds of embedded applications -- but I
don't believe it is useful for general purpose operating systems one
runs on the desktop.

(Marcus finally came to the same conclusion BTW, and interestingly for
the very same reasons I have been trying to point out all along, though
I never succeed in doing so...)

> The Cell was supposed to have several autonomous processors - one
> central CPU unit based on PowerPC and several (4 in PS3, IIRC up to 8
> planned) numeric processors that run independent programs in separate
> address space.

This is really off-topic here, but to shed some light: It's actually 7
SPUs in the PS3, and 8 in the "enterprise" versions. Variants with more
cores are planned, 16 being the next step IIRC.

> The numeric processors would suggest an architecture less dependent on
> the GPU for graphics rendering but the PS3s have a beefy nVidia GPU so
> in the end the platform does not seem that interesting.

Indeed, between normal CPUs growing more cores and more powerful SIMD
units on one hand, and GPUs becoming more generic on the other hand,
it's hard to find a niche for the Cell... It's neither here nor there:
Not as generic as a traditional CPU, and not quite as parallel as
today's GPUs.

More consequent implementations of asymmetric multicore chips, with a
combination of CPU and GPU cores, are expected soon though.

-antrik-