Re: A niche for the Hurd

[Michal Suchanek]

Hello

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


The first and most important part is reliability.

While I can understand that on a system used by next to nobody not
everything works well 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 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.

This meant that a mail client repeatedly checking for new mail would
eventually lock up the filesystem on which the mail spool is located,
typically with disastrous results.

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. Also
there are no good samples of any actual functionality that is not
available on the current UNIX-like systems.

Users are theoretically free to do whatever they want but good desktop
oriented system distributions go to great lengths to run services that
perform priviledged tasks for the users that the users should
logically be able to do themselves.

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 and this model is used throughout user
tools and system software.

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 (yes, it uses OSKit to emulate some particular version
of Linux but is tied to that single version of a particularly unstable
API). Even Linux and BSDs use wrappers around Windows NDIS
(networking) drivers these days. Imagine the benefits of using the
same OS-independent drivers with different systems..


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).

These systems are supposedly used in production embedded systems so
there should be support at least for some real hardware
configurations. 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?

The one thing where EROS is innovative is persistence - the OS is not
booted - it is installed. From then on it keeps running, and only puts
occasional snapshots of the OS state on the disk so that if there is a
power outage it can continue from the last snapshot - or at least this
is how it should look like - some drivers cannot be persistent for
obvious reasons.

The possible flaw of the ROCK system for some applications is
replacement of timesharing with a CPU-pool sharing.

The timesharing on general-pupose OSes makes it possible to change the
virtual CPU pool in a flexible way. The single CPU can be sliced into
many small ones or be allocated as a whole to a single task that
requires lots of processing power.

On a typical desktop system I can think of these cases when the CPU is
used almost exclusively by a single task:

- malfunctioning application - this is probably the most common and
undesirable case

- multimedia decoding and encoding, including playback. Some of the
decoding or encoding workloads could be possibly distributed between
multiple CPUs but I do not know enough about the codecs to tell if
processing a single stream can be split efficiently.

In video decoding and encoding which tends to be one of the most CPU
intensive application on a desktop computer there are multiple phases
in processing (decoding, error correction and postprocessing, scaling,
color conversion). The phases can be certainly separated but that
requires fast concurrent communication between the different phases  -
probably something like daisy chain topology rather than a single bus
topology. Splitting the single phase into multiple tasks might be
possible for some phases but not necessarily for others.

Note that SGI has made a fortune selling their specialized graphics
systems, and the invariant part that some consider important in them
is an interconnect switch that allows communication between multiple
CPUs at speeds far greater than the competition.

Another CPU intensive tasks that are less common but still done on
some desktop systems include graphics editing and rendering, and video
editing. The video editing might be more IO intensive rather than
anything else, though.

Most typical desktop tasks do not need almost any CPU time at all or
require very little CPU time a single task, though.

Also ROCK somewhat resembles the Cell CPUs which are the core of
Playstation3s and some IBM servers.

When the Cell was about to be released I read somewhere about the
planned features and use although I am not sure how much of that was
actually implemented.

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. The address space is probably allocated from the main
address space, and the instruction set probably different from PowerPC
(imagine shaders teared from the GPU and attached to the CPU).

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.

Another feature envisioned was building some Cell PCs which would be
easily extensible by stacking multiple Cell units together.
I have not heared of actual implementation so far. I am not sure if
this is because this is not technically feasible in the end or if it's
just that the Cell PCs would be so expensive that nobody would use
them. Even Sony was (and possibly still is) losing money by selling
PS3s.
Or might have just missed something.

The other thing that seems somewhat far fetched about ROCK is the
assumption that timesharing is the root of unreliability in current
OSes.

I would say it is not so. While context switching might be tricky it
is a very small portion of a typical OS, and heavily used. Thus I
would think that any shortcomings in this area are likely to be
addressed sooner rather than later.

However, there are things that greatly contribute to unreliability.

Especially on the desktop there are many small tasks that require
passing events as result of system changes or user input. Many of
these small tasks rely on shared address space rather than message
passing because marshalling objects is additional work. It is so much
easier to implement with shared address space, and so much less
reliable. An outstanding example of this approach is the Mozilla line
of products.

Another problem is security. Most security relies on attacker not
getting to a system because there is near-zero internal security
inside a single system. Since security is user based, users need
previledges do do anything, and any application that a user runs has
all the previledge of the user, any malfunctioning application can
cause a lot of damage. Also malfunctioning applications would affect
system state unrelated to their normal operation. This lack of
granularity in security is a great source of unreliability in the
system.

It is certainly possible that some of the shortcomings listed above
were already addressed.
As I am somewhat behind on the stuff I would appreciate if people
point out where that is described.

Thanks

Michal