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
