> Linus Torvalds had begun his project to write a UNIX-like kernel for the IBM 386. IBM 386? What in the world is an IBM 386?
Whatever happened to the Hurd? – The story of the GNU OS
51–60 of 93 posts
Re: Whatever happened to the Hurd? – The story of the GNU OS
#52> Linus Torvalds had begun his project to write a UNIX-like kernel for the IBM 386. IBM 386? What in the world is an IBM 386?
[deleted]
Re: Whatever happened to the Hurd? – The story of the GNU OS
#53So if things like Arch Hurd exist... Are we just missing the user interest in Hurd or are there usability problems with it or?
AFAIK a lot of it is due to issues as simple as Linux having more device drivers than Hurd.
Re: Whatever happened to the Hurd? – The story of the GNU OS
#54Earlier quoted context omitted.
Well, people are still working on the problem. You can run some runtimes directly on Xen, like the JVM and Haskell. http://labs.oracle.com/projects/dashboard.php?id=185 http://readwrite.com/2010/11/30/haskell-virtual-machine
Is this comparable to eLua? http://www.eluaproject.net/home/overview EDIT: I found this on YouTube: https://www.youtube.com/watch?v=W_aXsutL4rQ I was interested in this a while back, but never took the plunge. Seems you can run it in an 'emulator' on i386.
Well, kind of but not really. Xen isn't really bare metal in any sense of the phrase. It's just at a similar (but different) level of abstraction. In an embedded system you will need to have device drivers, respond to hardware interrupts, etc. On Xen you make hypercalls.
So eLua and these projects are similar in, say, the same way that a typical RTOS is similar to running Linux on AWS. They both have kernels, but the environments are vastly different.
Re: Whatever happened to the Hurd? – The story of the GNU OS
#55Earlier quoted context omitted.
> I don't think the fundamental problem with them — performance is horrible — had been made obvious yet. On the contrary, the idea that performance of microkernels is "horrible" is the current received wisdom, believed by the majority of programmers without critical examination, and based on very performance-poor early microkernel designs like Mach. The truth is that modern microkernel designs like L4 can perform IPC…
> Someday, hopefully not too far in the future, someone is going to write a modern, practical, and free microkernel-based OS that implements all of POSIX with performance the rivals Linux, but that offers a level of isolation and modularity that Linux could never offer. Why, when we already have VMs like Xen which are modern, practical, free, host guest OSes that run at full speed to provide whatever API the applicat…
I think that's a fair question, though I disagree that microkernels are somehow inherently less modular and isolated than hypervisors.
I should say, first of all, that when I said "that implements all of POSIX" I didn't mean that POSIX should be its native or only API, but just one API that is offered for compatibility with the incredible amount of existing code that targets it. I agree with your implied argument that POSIX is by no means the be-all, end-all user-space API.
But that said, I don't think that multiple OS's running under a hypervisor is the ideal way of promoting choice and diversity of APIs. First of all, there's a lot more software involved: a hypervisor, a dom0 OS, and a guest OS, just to run anything at all. Sure it works, but there's a lot to be said for a smaller and simpler base system.
When you take the hypervisor approach, every guest OS has to implement very tedious and hardware-dependent basic functionality like booting, context-switching, paging, interrupt handling, etc. instead of being able to use an API that provides these things. This is all not to mention drivers, which is one of Linux's biggest advantages over all competitors.
I see that Xen has a paravirtualization interface that can solve some of these problems, and indeed the more that the XenGuestOS interface becomes like an API/ABI and less like hardware emulation, the more Xen starts to look like a microkernel. I don't know the details of how Xen's paravirtualization interface works (and couldn't find good docs on in in a quick search) so can't comment on the specifics of it.
Maybe Xen's paravirtualization will morph into what I have in mind. One litmus test would be: do I have to statically configure the amount of RAM that each guest OS is allocated? There's no need to do this for multiple processes under a single OS, but any approach that is based on hardware emulation has to decide up front how much RAM the "hardware" has available.
Re: Whatever happened to the Hurd? – The story of the GNU OS
#56> Linus Torvalds had begun his project to write a UNIX-like kernel for the IBM 386. IBM 386? What in the world is an IBM 386?
http://en.wikipedia.org/wiki/IBM_386SLC
> http://en.wikipedia.org/wiki/IBM_386SLC
Very interesting. Thank you.
Re: Whatever happened to the Hurd? – The story of the GNU OS
#57Can someone explain to me if the problem with Hurd was that the basic idea was impossible, or it was the way they went about it? i.e. was it the relentless restarting of the project that was to blame, or did they keep restarting because every way they approached it turned out to be impossible?
Not only was it perfectly possible, microkernels have been sold commercially for decades and are extremely popular in hard real time environments where you want to be able to pre-empt a driver as though it is just another user process (which they are!).
Re: Whatever happened to the Hurd? – The story of the GNU OS
#58Can someone explain to me if the problem with Hurd was that the basic idea was impossible, or it was the way they went about it? i.e. was it the relentless restarting of the project that was to blame, or did they keep restarting because every way they approached it turned out to be impossible?
Microkernels were an immensely popular idea in academia (Mach, Minix, …) when Hurd was begun; I don't think the fundamental problem with them — performance is horrible — had been made obvious yet. Microkernel design is probably a good idea, but the message passing overhead kills actual microkernel implementations. I've heard the Windows NT kernel described as being designed like a microkernel architecture (separate m…
> I don't think the fundamental problem with them — performance is horrible — had been made obvious yet.
Microkernels can be just as fast as macrokernels and other than raw throughput can give latency guarantees that a macrokernel can't.
Message passing overhead can be minimized (by using the paging mechanism for passing messages between tasks on the same node).
Re: Whatever happened to the Hurd? – The story of the GNU OS
#59Can anyone tell me how computing would be different today if micro kernels had taken off? If everyone working on Linux had been working on Gnu Hurd?
Then everyone would have ran BSD. (J/K) Micro kernels are very hard to debug.
> Micro kernels are very hard to debug.
Absolute nonsense. Micro kernels are much easier to debug than macro-kernels.
The reasons are obvious to anybody that has spent more than an afternoon working with both, a microkernel is so small that the chances that your problem is in the kernel are minute compared to having your problem in user space. That means that all your luxury debug tools are available to debug the vast majority of your problems.
After the initial write the kernel code of a microkernel system is hardly ever touched. A good microkernel will limit itself to do the most limited subset that will still allow the system to function and will move everything else to regular processes.
Re: Whatever happened to the Hurd? – The story of the GNU OS
#60Earlier quoted context omitted.
Microkernels were an immensely popular idea in academia (Mach, Minix, …) when Hurd was begun; I don't think the fundamental problem with them — performance is horrible — had been made obvious yet. Microkernel design is probably a good idea, but the message passing overhead kills actual microkernel implementations. I've heard the Windows NT kernel described as being designed like a microkernel architecture (separate m…
I've read the same issues about performances and have always wondered how the QNX micro-kernel could power embedded devices (and the next BlackBerry). http://en.wikipedia.org/wiki/QNX
QnX is extremely low overhead, and gets a much more responsive system out of the same hardware than a linux based system. Linux simply doesn't do soft-realtime well, forget about hard realtime, even with the patches applied the granularity is terrible, and prioritization is worse.
Those are the things where a microkernel shines. Because realtime systems value responsiveness (and minimal latency) over raw throughput they look worse on paper, but in use they feel a lot more responsive.
In a nutshell, having 300 MB/s throughput for some system function with latency ranging from 2 ms to 100 ms vs having 200 MB/s with latency ranging from 2 ms to 5 ms will give a very strong edge to the slower system if there is some cut-off beyond which the latency becomes unacceptable (for instance, machine or process control).
Lower performance on paper does not always mean worse performance, it depends very much on which criteria are considered to be more important. And latency can be much more important than throughput.