Debian GNU/Hurd 2013 Released

jrepin writes "The GNU Hurd is the GNU project's replacement for the Unix kernel. It is a collection of servers that run on the Mach microkernel to implement file systems, network protocols, file access control, and other features that are implemented by the Unix kernel or similar kernels (such as Linux). The Debian GNU/Hurd team announces the release of Debian GNU/Hurd 2013. This is a snapshot of Debian 'sid' at the time of the Debian 'wheezy' release (May 2013), so it is mostly based on the same sources. Debian GNU/Hurd is currently available for the i386 architecture with more than 10,000 software packages available (more than 75% of the Debian archive)."

Comments

Need Clarity

[CrimsonKnight13]

Would anyone mind explaining to me the key differences between Debian Wheezy & Debian GNU/Hurd 2013? What are the benefits of using GNU/Hurd 2013?

Re:Need Clarity

[Anonymous Coward]

What are the benefits of using GNU/Hurd 2013?

There aren't any.

Re:Need Clarity

[Pecisk]

Debian Wheezy - Linux kernel, GNU tools, 100% of software compiled for i386/64.
Debian GNU/Hurd 2013 - Hurd kernel, GNU tools, 75% of software compiled for i386/64 (I'm ready to assume it doesn't have support for other platforms but might be wrong).

Hurd has been conceptual official kernel of GNU project for years (But then Linux came and put Hurd on backburner). Thanks to renewed interest it's development has picked up and therefore we have some actual distribution running with it.

Main problem for Hurd would be support for hardware who needs closed parts (firmware, binary drivers) as Hurd propably is GPL3 which essentially forbids usage of such things without disclosure to user, essentially killing any chances of having binary Nvidia driver supported. Still, most of open source stuff can be ported to be used with it.

Re:Need Clarity

[andy.ruddock]

Debian Wheezy is the Linux kernel based O/S we all know and love - Debian 7.0.
The Debian devs took a huge number of the packages available and re-built them to work in the Hurd environment, which uses a different kernel.

There are probably no inherent benefits to using Hurd over Linux - and there are certainly many reasons for picking Linux over Hurd, support being just one of them.
If you have a spare VM though then it may be worth installing Hurd just as a learning process.

Re:Need Clarity

[CrimsonKnight13]

Thanks to all of you for explaining it. I'll gladly stick with Debian Wheezy then. =)

Re:Need Clarity

[Anonymous Coward]

http://en.wikipedia.org/wiki/GNU_Hurd

Lets start with that. Basically a different kernel (BSD and linux are 'monolitic' kernels, MacOSX is a hybrid).

The idea is everything as much as possible runs in its own process and funnels thru an IPC. The actual kernel does not do much other than scheduling and memory management and IPC.

The idea is you can upgrade your network stack without rebooting the computer. This was very appealing 20 years ago when rebooting to 15+ mins for some bigger hardware. When you can reboot a computer in under 30 seconds it is not as interesting. It is becoming a bit more interesting today with companies wanting '0 downtime' with SLA's. It was also possible that you could run stuff on another machine and it be considered part of the OS. Cool stuff but in practice it ended up being slower than direct calls in many key instances.

Now the downside, they have been working on this since 1987. So work is slow, updates few, resets of the project seem to happen every 3-5 years. At this point you have 4 major OS's to choose from that are all very good (2 of them basically being Unix and one that is a very good clone).

The end user POV of say MacOSX vs Linux vs BSD vs Hurd. Not much. At this point Hurd is basically a research project. Oh I am sure there are a few out there who use it for 'production use'. But not many.

Re:Need Clarity

[SirGarlon]

There are probably no inherent benefits to using Hurd over Linux - and there are certainly many reasons for picking Linux over Hurd, support being just one of them.

At this stage of Hurd's development, parent is correct. For daily desktop use, Linux is clearly mature enough and Hurd is very probably not.

From the perspective of design, Hurd has some good ideas, as the GNU Web site explains. My favorite is:

the Hurd goes one step further in that most of the components that constitute the whole kernel are running as separate user-space processes and are thus using different address spaces that are isolated from each other. This is a multi-server design based on a microkernel. It is not possible that a faulty memory dereference inside the TCP/IP stack can bring down the whole kernel, and thus the whole system, which is a real problem in a monolothic Unix kernel architecture.

So there are design features of the Hurd that make it attractive to developers. I can foresee the Hurd maturing to the point where embedded device makers would seriously consider it, for example.

Re:Need Clarity

[Anonymous Coward]

Debian Wheezy - Linux kernel, GNU tools, 100% of software compiled for i386/64.

Wheezy is also available for other CPU architectures, e.g. ARM and MIPS. And, as a preview, you can use it with a FreeBSD kernel on i386 and amd64 instead of the normal Linux kernel.

Debian GNU/Hurd 2013 - Hurd kernel, GNU tools, 75% of software compiled for i386/64 (I'm ready to assume it doesn't have support for other platforms but might be wrong).

You're right, in fact it's only i386, not i386 and amd64.

Re:Need Clarity

[armanox]

I was going to say the same thing. Think of Debian GNU/Hurd 2013 as a snapshot of a subset of the whole Debian collection.

Re:Need Clarity

[satuon]

To tell you the truth, I'm using Ubuntu daily and I don't remember ever having the kernel itself crash, which I assume would produce the Linux equivalent of a BSOD. Usually it's just user-space programs that crash.

So if the kernel not crashing is the main selling point of Hurd, I don't see much reason why I personally would use it, because it fixes a nonexistent problem (at least for me).

Re:Need Clarity

[dpiven]

Debian Wheezy - Linux kernel, GNU tools, 100% of software compiled for i386/64.
Debian GNU/Hurd 2013 - Hurd kernel, GNU tools, 75% of software compiled for i386/64 (I'm ready to assume it doesn't have support for other platforms but might be wrong).

i386 != x86_64. Hurd is 32-bit only, according to the FAQ.

Re:Need Clarity

[Thud457]

It is funny how the GNU/world newspeak has become so reflexive that it has lost all meaning.

That is a worship word. Yang worship. You will not speak it.

Re:Need Clarity

[LoRdTAW]

Wheezy is a GNU/Linux operating system based on the Linux kernel. GNU/Hurd is the GNU operating system based on the Herd kernel. Commonly people simply call GNU/Linux "Linux" but Linux is the kernel which GNU runs atop of.

If you do a bit of research on Hurd the benefits are quite intriguing. One interesting bit is since Hurd is a microkernel, the concept of kernel-space and user-space disappears as everything runs in userspace. The kernel only worries about memory management, process/thread scheduling and message passing. Services are provided by "servers" running in userspace and talk to each other via messages. Users no longer need root access to do simple tasks like installing software, mounting disks, accessing hardware or other tasks which require root access or sudo because they live in kernel space. Instead they talk to the servers directly. The idea is that by moving services to user space, the need to grant users any type of root access (setuid, su or sudo) is removed. There is still a security hierarchy with a "root" user who has full control of the system, but users never need access to that user or group. No need for root access means less chance that the root account can be compromised. Imagine the problem of "privileged ports" disappearing because those services (ftp, http, etc.) no longer need any sort of root access. They are simply allowed to read/write certain files/directories and access the network. If that service is compromised, it can't gain root access.

Some have said microkernels are not necessary or that they impose a larger overhead in the form of message passing. That argument was valid ten plus years ago but today we have quad core 1.5GHz cell phones and PC hardware that is so fast that its stagnated the market. Linus Torvalds famously argued against the microkernel with Andrew Tanenbaum (Minix creator who inspired Torvalds) who is in favor of them. Eric S. Raymond once said about Plan 9 (The planned successor to Unix that failed) "There is a lesson here for ambitious system architects: the most dangerous enemy of a better solution is an existing codebase that is just good enough.". Hurd may never see production use and like Plan 9 be relegated to a research or pet project of a handful of developers interested in operating system design. I hope it succeeds.

Re:Need Clarity

[MBGMorden]

I'd just like to interject for a moment. What you're referring to as Linux, is in fact, GNU/Linux, or as I've recently taken to calling it, GNU plus Linux.

Sorry, but this war has been fought, and your side lost. I'm not using GNU/Linux/x.org/XFCE anymore than others are using Windows/CrystalReports/Office/PhotoShop.

Listing every single component of the system is stupid. Linux is the kernel, Linux is what gets recognized as the OS. There are a lot of programs that go into making the system usable - each one need not be referenced in the name.

Re:Need Clarity

[IRWolfie-]

Naturally I assume you of course call android by the name Linux as well.

Re:Need Clarity

[slim]

Listing every single component of the system is stupid. Linux is the kernel, Linux is what gets recognized as the OS. There are a lot of programs that go into making the system usable - each one need not be referenced in the name.

Mmm, but why do you choose the kernel as the piece so important that you name your whole system after it?

I'm forever seeing posts that say "Windows sucks and Linux rules, because in Linux I can do stuff like {insert neat adhoc bash script}". But you could run that script in a MacOS terminal, with Darwin replacing the Linux kernel. You could run it in Cygwin, with the combination of the Windows Kernel and the Cygwin compatibility libraries replacing the Linux kernel.

Linux is great, but it's a thin layer compared to the collection of GNU (mostly) tools that *actually provide the interface people love*.

Re:Need Clarity

[paulpach]

I'd just like to interject for a moment. What you're referring to as Linux, is in fact, GNU/Linux, or as I've recently taken to calling it, GNU plus Linux. Linux is not an operating system unto itself, but rather another free component of a fully functioning GNU system made useful by the GNU corelibs, shell utilities and vital system components comprising a full OS as defined by POSIX.

Both GNU components and the Linux kernel come with a written permission to call it whatever you want. I can take all these components, distribute them even verbatim and call them "yomama", and I would be fully compliant with the licenses. The difference is that no one would have a clue what I am talking about.

For this reason it is correct to call it Linux, or Android or Ubuntu or any other name (subject to trademark laws of course). Just use the name most people are familiar with so they know what you are talking about. Calling these systems GNU is merely a courtesy, a form of respect you pay to the GNU project, not a requirement in any way, and not "the right way" but merely your preference.

Re:Need Clarity

[mark-t]

The GNU project was a project to develop a free OS and tools.

All works developed for the GNU project were released under the GNU license. Numerous other projects were released under the same license as well.

Linux was a project to develop a free drop-in (and superior) replacement for Minix, and although released under the GNU license, and was distributed with GNU tools, it was never actually part of the GNU project, any more than AIX or HPUX would have become part of the GNU project by replacing their standard tools with GNU equivalents (I personally used an HPUX system at university which had all of the standard tools replaced with GNU ones, but that wouldn't suddenly change the name of that system to GNU/HPUX).

The notion that without the GNU tools, a Linux distribution would not be usable, and therefore the GNU prefix should be applicable to Linux also ought to apply to Minix itself, which like Linux, was never part of the GNU project (and was released under a different license), but was practically unusable out of the box, and most users of it took the source code to the GNU tools, which was freely and readily available, and compiled them to run under Minix to create a usable system. Minux, starting from approximately v 3 onwards, actually started being distributed with the GNU tools to make it more fully functional out of the box, but nobody ever tries to call Minix GNU/Minix.

Linux is Linux. GNU/Linux is just a name that people who were tired of waiting forever for Hurd wanted to call it so they feel like they had some closure.

Re:Need Clarity

[Cro Magnon]

One could argue that the OS is Debian (or Fedora or Ubuntu). All of which use the Linux kernel, and the GNU tools.

Re:Need Clarity

[Anonymous Coward]

The war is still ongoing. And it will, as long as we still have to use closed software. You are too old to fight, that's all. Calling it GNU/Linux is simply a way to give credit to the people who started all the Free Software movement. Without GNU, there would be no Linux.

Re:Need Clarity

[slim]

That's entirely pragmatic of you, and that's fine.

But say you wanted to try out an experimental device driver. In Linux it would be a kernel module. If it went wrong, it could potentially cause a kernel panic and halt your entire system. Or, since it has kernel privileges, it could just quietly spy on some element of your system and phone home with your confidential data without you knowing.

On a microkernel, your experimental device driver would run in separate memory space to other components. If the experimental driver crashes out, the rest of the system keeps going. It can't spy on your other components, because its access is restricted.

It may not address a need *you* have, but it may well be useful to others.

Re:Need Clarity

[LordLimecat]

Yall are posting in a troll thread.

Hint: Google parent's post.

Re:Need Clarity

[magic maverick]

I run Busybox/Linux, and when Toybox gets done, I'll think about switching to Toybox/Linux. ^_^

Re:Need Clarity

[greg1104]

If you're developing kernel components, having a kernel that crashes cleanly can make development much easier. Being able to shut down your buggy kernel level program and then try again sure beats rebooting after a panic. Even though this isn't directly helpful to users of the system, making the test side of development easier can lead to the program evolving more quickly over time. The Hurd design has been filled with taking the side of various trade-offs that take longer, but are believed to be more powerful in the end.

Re:Need Clarity

[LordLimecat]

On the flip side, having all that stuff in userspace surely means a massive performance hit, does it not?

I seem to recall for instance with various *nixes it is possible to have a single box handling tens of thousands of IPSec requests, because IPSec is handled within the kernel (IIRC), whereas that same box might handle a few hundred OpenVPN sessions simply because it is all userland and context switching absolutely kills performance.

If that is an accurate example of the type of performance hit incurred on the networking layer, would you really want that in userland?

Re: Need Clarity

[oso]

"What you're referring to as Linux, is in fact, GNU/Linux, or as I've recently taken to calling it, GNU plus Linux."

Wow. This statement is absolute proof that marketing spin works.

Re:Need Clarity

[greenfruitsalad]

If you were really following your logic, you'd call the operating system Debian or GNU. Just as Mac OS X isn't called "Mach" or MS Windows isn't "NT kernel".

Re:Need Clarity

[umeboshi]

Excellent point! I'll remember that one. I just cut to the chase and call all my systems debian.

Re:Need Clarity

[socode]

Yep, that will be incredibly handy, and will be addressing a clear problem that many users and enterprises have to solve,

We can move to a completely different OS design, to avoid running a development machine [where an experimental driver is mated to experimental hardware], and to avoid setting up a VM for experimental driver software, and the driver will only take out entire subsystems on the host machine (network, filesystem) when it fails.

Re:Need Clarity

[Anonymous Coward]

Because people like an easy, pronounceable, memorable label for things.

It usually goes like:
GNU: Do you spell it out, "gee en you"? Or is it "new" like the wildebeest? And what's with the recursive acronym (GNU's Not Unix)? Why do you geeks pick such awkward names?
Linux: Only two possible pronunciations, both easy.

Given a choice between technically correct and easy, most people will pick easy.

Re:Need Clarity

[gmack]

That makes plenty of sense until you realize that device drivers that interact with the hardware are far more likely to crash than things like TCP. Hardware often has things like Direct Memory Access(DMA) to and from the device to make access more efficient and when a hardware driver crashes, a misplaced DMA setting on the hardware can scribble over any memory it wants.

Re:Need Clarity

[ta_gueule]

GNU carries a philosophy and Linux does not. I want to promote the philosophy and therefore I call it GNU. Technically, Linux is not better than NT or Mach. I have no reason to promote Linux on a technical level. I call it GNU to promote free software. Linux is important because of the GPL. The real value is in the philosophy.

Re:Need Clarity

[Skiron]

To pretend you are still a hippy in the 70's?

Re:Need Clarity

[DrXym]

The war is still ongoing. And it will, as long as we still have to use closed software. You are too old to fight, that's all. Calling it GNU/Linux is simply a way to give credit to the people who started all the Free Software movement. Without GNU, there would be no Linux.

Most people recognize that a distribution is the sum of its parts (many of which have nothing to do with GNU or the FSF) and therefore don't elevate any particular group above the others and are quite content to refer to the whole lot as Linux. I suspect that the whole GNU/Linux thing is just some underlying resentment that Linux succeeded precisely for the reasons Hurd failed so miserably - because the FSF is big on ideas, not so big on actually bringing them to fruition in a timely and practical fashion.

Re:Need Clarity

[buchner.johannes]

If courts decide GPL2 doesn't cover some loophole and people are abusing Linux in some way that Linus does not like, Linus is screwed. With Hurd, there is a license upgrade path.

Re:Need Clarity

[MBGMorden]

No, to do that would be to do the same silliness as the GNU/Linux crowd. The Android system is a separate entity. I don't hark on ideals. It has become standard to refer to that system as "Android". Insisting on putting "Linux" in the name (or making it the name) is just as silly and foolish as insisting that GNU be in the name of what's become commonly called the "Linux" desktop OS.

Re:Need Clarity

[hduff]

What are the benefits of using GNU/Hurd 2013?

There aren't any.

There are. You can keep a dying dream alive and foster hope that the Linux poseur can be dethroned and GNU WILL LIVE!

Re:Need Clarity

[devman]

GNU/Linux is not a OS. Android is an OS, Debian is an OS, Ubuntu is an OS, Arch Linux is an OS. When you make a distro feel free to call it IRWolfie GNU/Linux if you want.

Re:Need Clarity

[MBGMorden]

I think you parsed my intent incorrectly. I wasn't stating the Linux is the kernel and THUS the OS, I was stating that Linux is the kernel AND the OS.

Re:Need Clarity

[slim]

Imagine the problem of "privileged ports" disappearing because those services (ftp, http, etc.) no longer need any sort of root access.

The "privileged ports" restriction is a historical artefact that should be retired, in my opinion. It supposedly reassures the client that the service they're talking to is blessed by root on the server. That meant something in the days when UNIX only ran on big expensive boxes with admins holding the reins tight; when people generally trusted the routes between hosts. It means almost nothing when everyone and their dog can be root on a system of their own, and you've no idea what NAT routers and MITM exploits are messing with your TCP packets.

I reckon the risk introduced by programs starting as root, and the programmer having to get the privilege-dropping code right, far outweighs the benefits of privileged ports.

Services should run as non-root users. The OS should let them bind to low port numbers. Clients should use SSL/SSH/etc. to establish trust, if required -- and never treat a port number as any sort of evidence of trustworthiness.

Re:Need Clarity

[femtobyte]

Sorry, but this war has been fought, and your side lost. I'm not using GNU/Linux/x.org/XFCE anymore than others are using Windows/CrystalReports/Office/PhotoShop.

Actually, people *do* typically refer to their computer software stack at a level appropriate for the task being described. If someone asks, "what did you photoshop that picture with," do you say "Mach microkernel"? --- No, you describe what you're using at a level appropriate to the activity: you might say "Gimp, on Ubuntu." Thus, if your work consists of using GNU utilities and applications, or writing programs linking against GNU libraries (and compiling them with a GNU compiler) --- it's perfectly reasonable to say you're using GNU on Linux (just like someone might say "Office on Windows" to describe their computer work environment, instead of saying "I write company newsletters using a Core i5-3350p").

Re: Need Clarity

[Anonymous Coward]

You just described how language works. Things are called something because people call them that, regardless of whether or not that is fair or technically correct.

Re:Need Clarity

[Anonymous Coward]

In 1994 I had SUN, SGI, and NeXT computers to use with a nice interface.
Linux was the first one I could afford to have in my house, and no longer needed to head to a computing facility.

Re:Need Clarity

[slim]

In 1994, at university, I was in much the same situation (except it was only Sun -- we didn't have SGI boxes, and I couldn't make head nor tail of the solitary NeXT box).

I cut my teeth on SunOS. Then I got a 486 and ran Slackware on it in my dorm room. I found that bash was better than csh (which our admins had made the default shell on SunOS). I found that GNU date was better than SunOS date.

Then I found that our admins had a /usr/gnu/bin NFS mount for the Sun boxes, which we just had to put in our paths to make SunOS feel like Slackware.

So for the last three years of my four year course, I was running GNU/Linux at home and GNU/SunOS in the labs.

The point being that the GNU utilities were the "nice thing" I was interacting with. The kernel was only there to prop them up.

Re:Need Clarity

[Waffle Iron]

By your definition, Microsoft WIndows must not be an OS. After all, it can't compile itself, because it doesn't come with a compiler.

Nor is Android; I doubt that it even has a compiler. Even app development for Android is done with a cross compiler on a different system.

Of course, all of those dilemmas are false, because in reality, the definition of "OS" simply does not contain a requirement for self-compilation.

Re:Need Clarity

[fahrbot-bot]

I'd just like to interject for a moment. What you're referring to as Linux, is in fact, GNU/Linux, or as I've recently taken to calling it, GNU plus Linux.

Sorry, but this war has been fought, and your side lost. I'm not using GNU/Linux/x.org/XFCE ...

Listing every single component of the system is stupid. Linux is the kernel, Linux is what gets recognized as the OS. There are a lot of programs that go into making the system usable - each one need not be referenced in the name.

Although, there is a LOT more GNU in a "Linux" system than Linux - which was also built using GNU utilities...

Re:Need Clarity

[Anonymous Coward]

What are the benefits of using GNU/Hurd 2013?

There aren't any.

There are. You can keep a dying dream alive and foster hope that the Linux poseur can be dethroned and GNU WILL LIVE!

Ph'nglui mglw'nafh GNU/Hurd R'lyeh wgah'nagl fhtagn!

Re:Need Clarity

[fahrbot-bot]

From the perspective of design, Hurd has some good ideas

From the perspective of design, Hurd, has some interesting ideas. Unfortunately, they have for the most part, not turned out to be good ones. Microkernels have failed.

[ citation needed ]

Re:Need Clarity

[Chris Mattern]

Hurd has been in "development" for thirty years without ever coming close to moving to production. Aside from that and Minix (which was never intended to be a production system), name me a microkernel that can number its user base in five figures.

Re:Need Clarity

[aaaaaaargh!]

Linux is the kernel, Linux is what gets recognized as the OS.

False. Everybody knows that it's called GNU/Linux, "Linux" is just an everyday abbreviation to make life easier, nothing more.

Credit to where it's due. Or, try to run your kernel without the GNU utilities.

Re:Need Clarity

[fahrbot-bot]

Hurd has been in "development" for thirty years without ever coming close to moving to production. Aside from that and Minix (which was never intended to be a production system), name me a microkernel that can number its user base in five figures.

Good points all, but also all irrelevant to the question. Success/failure are not measured simply by the size of the user base. Adoption, acceptance and usage - sure, but just those.

I don't know to what extent micro-kernels are used for production in the real world, but Tandem Non-Stop systems used a message-based OS and Cray had UNICOS variants based on Mach and Chorus for use on their YMP and other systems. According to Wikipedia, Symbian (used on Nokia and Vertu smart phones) is a real-time micro-kernel OS. It would be difficult to argue that all those were/are failures.

Re:Need Clarity

[Bert64]

What about those of us using the Linux kernel with a BSD derived or Android userland?

Re:Need Clarity

[Ultra64]

"I was stating that Linux is the kernel AND the OS."

But it isn't.

Linux is only the kernel + drivers.

There is no userland, which is where GNU comes in.

GNU is the OS, Linux is the kernel.

Re:Need Clarity

[Bert64]

But today most users would be interfacing with gnome, or kde, or unity etc and are unlikely to touch the gnu tools - ie they do useful stuff in the background, just like the kernel does...

Re:Need Clarity

[Ultra64]

"Hurd is 32-bit only, according to the FAQ [gnu.org]."

What in the actual fuck. Do they think it's still the '90s or something?

Re:Need Clarity

[tnk1]

More to the point, everyone calls it Linux, and while there is actually something called Linux in there, they're not going to call it GNU/Linux. It's annoying enough to write the additional characters down in text, but even more cumbersome to say. And all for the effect of someone thinking you're either pedantic, or an uninformed audience wondering what the hell you are talking about.

Yeah, all the tools are GNU tools, but honestly, no one has forgotten that. We all know who we need to contribute to in order to keep gcc or coreutils updated properly.

I know why RMS clarifies that, as it is more accurate and he has irons in the fire. However, the battle is over, and no one is planning on altering how they talk about it. Still, by all means, express yourselves the way you like, I just don't think it is worth the trouble.
   

Re:Need Clarity

[Larryish]

And some people think cucumbers taste better pickled.

Re:Need Clarity

[lister king of smeg]

"I was stating that Linux is the kernel AND the OS."

But it isn't.

Linux is only the kernel + drivers.

There is no userland, which is where GNU comes in.

GNU is the OS, Linux is the kernel.

gnu or busybox or plan9 or bsd or some mix there of

Re:Need Clarity

[slim]

I wonder whether that's true.I must admit I haven't used a Linux GUI for years -- and where I did, it was a window manager for XTerms. I get the impression there are an awful lot more Linux instances in server roles than in desktop roles.

But in any case, what does the G in "Gnome" stand for?

Re:Need Clarity

[lister king of smeg]

precisely for the reasons Hurd failed so miserably

Hurd did not fail, it's right on time. Someday when there is a huge lawsuit against Linux (if there is one, it's just a possibility) you might appreciate the fact that Hurd exsists(sic).

We already had it, SCO lost and we are still using Linux.

Re:Need Clarity

[jones_supa]

This is the best answer in my opinion. In most cases you can just use the operating system name to cover all the stuff it includes.

Re:Need Clarity

[lister king of smeg]

the mach micro kernal is the bases of osx and ios but it is not acting as a microkernal in those environments.

Re:Need Clarity

[mark-t]

GNU carries a philosophy and Linux does not.

I agree completely with this, which is why I think that trying to prepend "GNU" onto Linux is a rather foolishidea.

Re:Need Clarity

[osu-neko]

Linux: Only two possible pronunciations, both easy.

There are a lot more than two possible pronunciations, although there are two that come to mind to most English-speakers readily, neither of which is "correct" (in the sense of how the creator said it).

Re:Need Clarity

[oreiasecaman]

What are the benefits of using GNU/Hurd 2013?

There aren't any.

Then maybe we should start calling it GNU/Turd

Re:Need Clarity

[osu-neko]

Ah yes, the "war" is over. If the majority believes a falsehood, it becomes the truth...

Re:Need Clarity

[DrXym]

Hurd did not fail, it's right on time. Someday when there is a huge lawsuit against Linux (if there is one, it's just a possibility) you might appreciate the fact that Hurd exsists.

Where "right on time" means half-baked nearly 23 years after the project started. The one and only reason to be thankful is that in 1991, a mere year into the project development was already so moribund, mired in politics and perfectionism that a student called Linus Torvalds got pissed off enough to write his own kernel. Thus demonstrating what happens when a project is motivated by pragmatism over one motivated by politics.

Re:Need Clarity

[Anonymuous Coward]

Come on.

Poking the wrong bits into hardware (as in your experimental driver) will lock hard your entire system -- you won't even have the chance of a kernel panic, micro-kernel or not.

Then, how about those video cards that have hard access to the whole memory, bypassing whatever restrictions the kernel may put in place?

If a driver wants to 'drive' anything, he needs access to the system's interrupts, busses, locks, whatever. At that point, all bets are off.

Re:Need Clarity

[Darinbob]

But the GNU tools and utlities are still just a subset on most Linux distributions. Now if they have a Linux kernel combined with only GNU software to make a distribution, then it should be called GNU/Linux. Or Linux/GNU.

(The reason some want to call it GNU/Linux is because GNU started the whole "replace Unix with only free components" idea and didn't want to be left out when a different project was getting all the popularity, or to be more charitable, didn't want people to forget about free-as-in-freedom software in their rush to get free-as-in-beer software.)

Re:Need Clarity

[Darinbob]

Even on Mac at work it's mostly windows to bring up browsers, Outlook, terminals running bash, and emacs on a daily basis. The UI is just there most of the time to bring up the windows and navigate to them, and being able to see multiple windows at once. (most of the time, but not all of it, I use a UI based source code control which I find more convenient than the command line equivalent for example)

Re:Need Clarity

[Darinbob]

GNU was a bit slow on the kernel, I think they were being too perfectionist with it and wanted the "best" kernel, whereas Linux was "let's hack up something like minix that works with 386 features" and didn't have any grand goals. But more importantly, I'm not sure GNI was really thinking about the big picture of how to turn all the component parts into a real system. That's the hard part really, bootstrapping it all into a system that others can easily install and use and upgrade.

Linux started growing at just the right point in time too. PCs were more affordable and more powerful, making Unix practical and affordable at home. Internet accessibility was getting easier (though when I first used it I still had to download and work and carry a set of floppies home). Both combined together meant that you could get a much larger set of people working on the same system, so that it went from something a first system that was difficult to get running or use into something highly usable in less than a year.

Re:Need Clarity

[Darinbob]

Linux has a philosophy, though maybe it's more subtle. When it was new it was "this is cool, try it out". Later on it was "this is practical, use it".

You can give to a charity without joining a church or movement; similarly you should be able to write, contribute to, and use free software without adopting a structured philosophy.

Re:Need Clarity

[unixisc]

One thing I've always wondered - why didn't Linux just use Minix? As opposed to studying Tanenbaum's code to put together a different OS altogether?

Re:Need Clarity

[Darinbob]

The 1970's are over, and yet Unix is still alive and strong.

Re:Need Clarity

[Medievalist]

No problem. The benefit of using Debian/HURD is that you can find out for yourself what the differences are between a microkernel architecture (made useable by a sea of modules) and a monolithic kernel (that has evolved into a sea of modules) - instead of relying on Internet trash talk.

Re:Need Clarity

[Darinbob]

The microkernel idea was very big during the early 90's, to the point of monolithic kernels being declared obsolete, but the microkernel push seems to have mostly died away. It really only kicks around in some embedded RTOSs and educational systems. The problems of monolithic kernels were not that huge in practice, and so the arguments were really pragmatic versus idealistic, and pragmatic usually wins those fights.

I like the ideas of microkernels though. There's good stuff there. Both come with advantages and disadvantages. But practically speaking, there are many more years of experience creating high performance and stable monolithic kernels than there are with microkernels.

Re:Need Clarity

[Darinbob]

It's not really the selling point. Hurd was envisioned back when the microkernel design was popular. Many of the problems it was intended to solve were also solved in different ways on monolithic kernels.

Both ideas have problems that need to be overcome, you don't automatically have one better than the other. So for example extra work goes into a monolithic kernel to allow a preemptible kernel, but you also have extra work in microkernels to improve the performance when communicating between components, so maybe it balances out. Generally what happens is that a microkernel advocate points to the old 80's era kernels as an example, and the monolithic advocate points Mach as an outdated design, it's rare to see a modern vs modern debate.

Re:Need Clarity

[Darinbob]

However, how important is this for an operating system? The typical user does not develop experimental drivers. It's a feature that's nice for experimenters, so maybe it's a positive feature in an OS that experimental. In practice though, the microkernel may still be forced to reboot in case some driver or critical component stops working. Ie, you still need a way to recover from those crashes, if your driver was for the file system then you need to reload the stable driver from disk, but there's no file system running to do this, so you're stuck.

Even microkernel advocates would point to this as a minor feature, no one would go to all the extra work of creating a microkernel if the end goal was just to prevent some occasional reboots when developing experimental drivers. A more important goal for example would be to have a preemptible kernels and kernel components.

Re:Need Clarity

[Darinbob]

This is something that needs to be a part of the design when actually building a microkernel. Ie, you realize that this problem exists and so you make sure that your context switching and message passing can be as fast as possible. Yes, it can be a lot of work and a naive microkernel won't do well at it. On the slip side though, a monolithic kernel comes with its own set of problems to overcome, such as having to wait on the OS merely because you need it to sign a packet for you, and so designers put in lots of extra work to make sure a monolithic kernel can be preemptible or provide ways to bypass the context switching into the kernel.

In short, a well designed microkernel will beat a naive monolithic kernel, and vice versa.

Re:Need Clarity

[AlphaWolf_HK]

What if you pronounced it linooks? You know, if say you only heard the term ubuntu and figured that the word linux had a derivative of a non-english u.

So given that can have a third and fourth pronunciation, surely we can call it gnu/linux now right? :D

Re:Need Clarity

[snadrus]

Android uses Busybox.
Qualcomm's has LLVM compile Linux & use its C runtime.
There are many C runtimes for Linux nowadays.

I'm unsure how much longer any GNU pieces will be on any system. Today none are a hard requirement for Linux.

Re:Need Clarity

[bbsalem]

GNU/20Hurd thing.

Re: Need Clarity

[nbritton]

"There is a lesson here for ambitious system architects: the most dangerous enemy of a better solution is an existing codebase that is just good enough."

i.e. Windows, and why prior versions of Windows are Microsoft biggest competitor and why operating systems as a service (the way Apple puts out frequent / cheap upgrades) is probably the only model that will work over the long term.

Re:Need Clarity

[LWATCDR]

Actually conclusion is backwards. If it was the GNU tools that provide the interface people love then Linux would not be popular since those tools run on many other kernels. What people love about Linux is the stability and performance of the Kernel. And the interfaces that people love tends to be things like Apache, MySql, Postgresql, PHP, Perl, Postfix, and or Samba for servers. For the desktop it is it is KDE, Gnome, or name your desktop. So I would say the GNU tools are just tools running on Linux.

Re:Need Clarity

[DrXym]

There was a well documented email debate between Tannenbaum and Torvalds over micro and monolithic kernels. The gist of it was that Tannenbaum thought microkernels were more stable and easier to understand, Torvalds thought microkernels were more complex, less efficient and the stability wasn't worth it. There are successful microkernels, e.g. QNX so perhaps it could have gone the other way but I suspect Torvalds strongly preferred something that worked over something that was "correct" and chose his path.

Re:Need Clarity

[Galilee]

Mmm, but why do you choose the kernel as the piece so important that you name your whole system after it?

The kernel is the one common component across each of my servers. Some of our servers run Apache HTTP, others Tomcat, WebLogic, BIND, etc, but they all run the Linux kernel. Each of those programs I mentioned earlier run on multiple platforms, so saying "Tomcat" alone does not tell you the OS.

Re:Need Clarity

[w1z4rd]

In South Africa we pronounce it: Lie-nix . I notice most of the rest of the world pronounces it Lee-nix. I heard Linus said "linux is pronounced "lee-nix". He confuses all of us with that strange sounding "I"

Re:Need Clarity

[charles2678]

Aside from that and Minix (which was never intended to be a production system), name me a microkernel that can number its user base in five figures.

Obviously you don't work in embedded space -- QNX has been dominant there for decades. And then there's Mach (which underlies MacOS X)...

Re:Need Clarity

[Reservoir Penguin]

The real reason was back then Minix was under a license that did not allow patches to merged into the OS, they had to be distributed separately.

Re:Need Clarity

[unixisc]

This was much later. But at the time Linus came up with Linux 1 or whatever, the Minix that he based it on was either version 1 or 2. The first 2 versions of Minix were NOT microkernel - it was only in Minix 3 that Tannenbaum made it a microkernel OS. Tannenbaum had earlier dabbed in distributed microkernel OSs, like Amoeba. But Minux became microkernel much much later.

Re:Need Clarity

[unixisc]

As some of the above mentioned, QNX is pretty popular, albeit under the hood, so few know about it, although it's also used now by RIM. Also, Mach 3 has been the backbone of OSF/1 and some other OSs. Aside from them, Minix 1 & 2, which were not microkernel, were meant for just educational purposes, but Minix 3 is a microkernel and aimed at embedded systems as well.

Re:Need Clarity

[unixisc]

No, they think it's the 80s - when Hurd started, and the i386 came out. Since then, the i386 is all but dead, but Hurd is just now ready for any usage by end users

Re:Need Clarity

[cthulhu11]

I roll my eyes every time that I see "Linux" considered to be different from "Unix". Trademark lawyers notwithstanding, it's mostly about pretension, like the way that the San Francisco area calls itself "northern California" to distance itself from LA, despite clearly being more central than northern.

Re:Need Clarity

[lokedhs]

Clearly you never experienced the 70's...

No drivers for SATA in 2013?

[zitsky]

I know that Hurd has been in development a long time. I'm surprised that they still don't have SATA drivers.

Re:No drivers for SATA in 2013?

[Unknown Lamer]

The FAQ claims they have a working AHCI driver.

Re:No drivers for SATA in 2013?

[Anonymous Coward]

http://www.gnu.org/software/hurd/faq/sata_disk_drives.html

Re:No drivers for SATA in 2013?

[jandrese]

Wow, they got SATA support on May 10, 2013? I wonder how long it will take them to implement UEFI support. Is it always going to be a decade behind?

My understanding is that Hurd has been held back because Stallman was a bit of a control freak and made it very difficult for the community to help him develop the kernel, even after his wrists went and he couldn't personally code anymore. Linus had a much much better attitude towards community development which allowed the Linux kernel to completely displace Hurd.

Re:No drivers for SATA in 2013?

[jones_supa]

True. Stallman has some good ideas but his strict idealism is actually hurting his agenda. It's a net loss.

Re:No drivers for SATA in 2013?

[yuhong]

I think they will focus on porting to x86-64 first before implementing UEFI, given that most UEFI implementations are 64-bit.

Re:No drivers for SATA in 2013?

[jandrese]

x86_64 support seems less critical for me. Sure you'll be limited to 4GB of memory, but it's a toy OS anyway. No chip is going to drop support for ia32 anytime soon (heck, they still support old 16 bit modes!). The lack of UEFI support however is going to seriously limit the number of machines it can be installed on in the near future. It's going to become hard to find machines that still have an old style BIOS on them.

Re:No drivers for SATA in 2013?

[yuhong]

Problem is that UEFI being 64-bit means that the runtime services are also 64-bit.

Re:Oh come on.

[telchine]

Oh come on. April 1st is over. Everyone knows Hurd is a running gag. It's an ancient meme.

Ha, indeed! Someone once tried to convince me that Duke Nukem Forever had been released too. I'm not so stupid that I'd fall for that!

Does anyone have any non-silly comments?

[serviscope_minor]

Does anyone here know much about the Hurd?

I know it got stuck in "which microkernel shall we use" hell for the longest time. They seem to have settled, but it's not clear if the new one is a modern high performance one (under the Mach name), or if they just settled on the older one and suffered a performance hit.

Also, why is a microkernel OS so apparently difficult to construct?

As far as I can see, the basic bits of hurd are all in place: the things that make it an operating system that actually works. But what took it so long? Micro kernel based things sound like they ought to be easier to develop (segfaults instead of a lockup, for instance), but apparently they are not.

Anyone got any experience?

Re:Does anyone have any non-silly comments?

[i.r.id10t]

According to RMS in "Revolution OS" the difficulties with their attempt at the microkernel is in the timing of messages back and forth to all the little sub processes/daemons/whatevers

Re:Does anyone have any non-silly comments?

[Pinhedd]

Microkernel operating systems aren't inherently difficult to construct but there's a very noticeable tradeoff between the performance of a hybrid/monolithic kernel and the security/stability of a microkernel.

The performance hit comes from the hardware isolated process model used by modern microprocessors. Whenever an application needs to do something outside of its own scope, such as request additional memory, access shared resources, or interface with a device driver it makes a system call. In a monolithic system this requires the processor to switch from the running task to the kernel task, perform the requested action, and then switch back to the running task. If the kernel needs to access the tasks memory, it can access it through segmentation or shared memory with ease because the kernel in a monolithic system has no access constraints.

In a microkernel system the processor switches from the running task to an interprocess messaging task (part of the microkernel), which then copies the message to the requested server's buffer, switches to the server task, processes the message, switches back to the messaging task, copies the response back to the original client's buffer, and then switches back to the client task.

Task switches are very expensive in terms of CPU cycles, so minimizing them is key to obtaining performance. Hybrid and Monolithic kernels have a massive performance edge on modern processors because they perform a fraction as many task switches and memory operations whenever a system call is performed.

Re:Does anyone have any non-silly comments?

[putaro]

I looked at it a while back with an eye towards doing some work on it, but I'm interested in file systems and large storage and Hurd was limited to a max of 4GB per file because all files were memory mapped all the time and Hurd only runs on 32-bit architectures. So, for me, the amount of work before I could do something interesting was pretty steep.

I think the main reason that microkernels don't have great performance is because not much work has been put into them. I worked on Apple's Copland OS back in the mid-90's (the "failed" OS before OS X). Copland was a true microkernel and there were a number of performance optimizations that we'd put in. Had it shipped, we probably would have started making some modifications to the CPUs to support the microkernel better as well.

A big issue for performance is switching between processes. If you have to make multiple process switches for each kernel call that can get slow due to things like reloading the MMU tables, etc. There are a lot of different paths that could be taken. I could imagine a micro kernel, for example, written in Java or similar language running in a VM that enforced fine-grained memory controls, e.g. at the object level. If you used this for memory protection between trusted (e.g. OS level) servers you could avoid the hit of reloading the CPU's page maps. User space separations could be enforced by the CPU for better security.

Re:Does anyone have any non-silly comments?

[Pinhedd]

>I could imagine a micro kernel, for example, written in Java or similar language running in a VM that enforced fine-grained memory controls, e.g. at the object level. If you used this for memory protection between trusted (e.g. OS level) servers you could avoid the hit of reloading the CPU's page maps. User space separations could be enforced by the CPU for better security.

Microsoft Research has done a lot of work on this exact idea. They even produced a usable operating system

http://en.wikipedia.org/wiki/Singularity_(operating_system)

Re:Does anyone have any non-silly comments?

[Anonymous Coward]

Microsoft Research has done a lot of work on this exact idea. They even produced a usable operating system

ERROR IN LINE 1: DOES NOT COMPUTE!

Re:Does anyone have any non-silly comments?

[VortexCortex]

Managing the trust graph is why it's hard. Security is always hard. On a monolithic kernel we just say: Uhm, yeah, I trust all these drivers and whatever, even though I probably shouldn't because... well... That's how it works. GNU/HURD/HIRD has a more modular approach that pushes the drivers out of kernel space, but it has some design flaws ( letting a directory node provide its own ".." -- Yikes! ), and the number of developers is next to non-existent.

Furthermore modern processors are designed for monolithic kernels. Just like x86 has a bunch of cruft from when ASM coders wanted more complex instructions (for less / easier coding), Features like Multiple Execution Ring Levels are missing. ARM gives me Two Rings. AMD x86 gives me Two Rings. Intel x86 gives me 4 rings! A ring level essentially is a hardware supported security level. Each ring allows another "mode" of security. So, with only two rings, I can create an OS that has userspace and kernel mode. With 3 rings I can have Kernel, Trusted Driver/Module/Interface, and Userspace. The barriers required to easily create a secure microkernel don't exist. With only 2 rings we have to decide if userspace or kernel mode is where a module belongs -- They don't belong in either! We Need The One Ring to be an intermediary between Ring Zero (which rules them all) and give Ring 2 to the userland, and in the darkness bind them.

Everyone's using monoliths, hardware makers give us 2 rings to make that happen. Hell the hardware even prevents adoption of new (more secure) programming paradigms. Even the virtual memory addressing system in modern chipsets is designed to work best with C. I'm working on a more secure language with separate call and data stacks, and code-pointer overwrite protections for heap data, but the x86 / x64 / ARM platforms I'm working on are built for single stacks, and thus stack smashing or buffer overflow is an inherit design flaw. Segmented memory would be great for securing functions on a per call basis -- Swapping Stacks at will, Super easy Co-Routines... but those bits were sacrificed to the More Memory God, and the registers became a part of the virtual addressing system. On 16 bit code I can do some neat things that I can't do on 32bit mode code without a huge headache, because the hardware doesn't support me doing it.

So, that's why it takes so long. Because we're trying to do stuff in software that the hardware doesn't support. These things are more secure and are great for modularity, but the hardware's designed to do it faster the monolith / C way. Note that to a program it won't matter about whether the filesystem is uber modular, or the device drivers are not in ring 0. Hell, eventually I'll port a C compiler to the multi-stack code.

Note: I don't work on GNU/HURD/HIRD, just develop my own OSs. Yeah, I could work on Linux or other POSIX OSs, but why? That's not going to advance the state of the art in Operating Systems at all. A reliable design is grand for production systems, but to make the leap from the 80's, we're going to need some new hardware to help us out. Got Viruses? Blame the Chip Maker, Language Implementer (not designer), and Operating System. Seriously, they're all doing it WRONG if security is the goal. With a separate call and data stacks on chip, One Ring more, you could actually have the damn security you want.

Re:Does anyone have any non-silly comments?

[serviscope_minor]

Not sure I follow the comment about more than two rings.

Wouldn't a 2 ring system with an IOMMU be sufficient? That way drivers could sit in ring 1, but still have access to the piece of hardware required.

This may not be a sane question: I have read a fair but, but I've never tried to write a kernel.

Re:Does anyone have any non-silly comments?

[shia84]

"Just" a microkernel is fairly straightforward to build if you have a bit of experience. I could make a simple one in two afternoons.

Microkernel OSs with a very limited feature set and somewhat OK-ish performance are feasible, as shown by e.g. velOSity and embedded realtime systems like QNX.

Microkernel OSs that can be used for general purpose computing and offer a nonvanishing fraction of the performance of Linux, XNU or NT are ... well, the development times of the L4 family, Hurd (OK, this one has other roadblocks), Sawmill etc. show how hard it is.
There have been quite a bunch of microkernel research projects (by at least IBM and Microsoft for what I know, plus the usual bunch of universities), and there has been renewed interest lately. In the future it might come down to "your hardware is fast enough that a performance hit of, say, 50% doesn't matter, and the added stability, security and MUCH simpler life for developers that interact with the lower parts of the system are worth it".

Re:Does anyone have any non-silly comments?

[Chris Mattern]

Also, why is a microkernel OS so apparently difficult to construct?

In the final analysis, a modular message-passing architecture posed performance problems they were never able to adequately solve, pretty much as the nay-sayers predicting when microkernels were first proposed.

Re:Does anyone have any non-silly comments?

[Chris Mattern]

Microsoft Research has done a lot of work on this exact idea. They even produced a usable operating system

I suppose there's a first time for everything.

Re:Does anyone have any non-silly comments?

[tlhIngan]

Also, why is a microkernel OS so apparently difficult to construct?

They aren't. There are many microkernel OSes out there that are successful, like QNX (which has made plenty of noise about how it runs nuclear reactors and such). Hell, even Windows was completely microkernel at one point.

The main problem is performance. This comes from two problems - repeated kernel requests, and IPC.

Kernel requests happen because device drivers are run at application level (which provides great isolation). However, device drivers tend to require a lot of stuff at the kernel level (which is why they're typically in the kernel...) - things like interrupts, physical memory access, DMA, memory allocations (both physical and virtual), and such. Each one of those things it can't do alone (because well, it's an application - if applications can do those things, your microkernel is no better than DOS - the goal is to isolate things from each other). So it becomes an kernel API call to request an interrupt, to register an event object (the interrupt handler runs in the driver server as an interrupt thread), to get memory mappings installed, etc. Each API call is a system call in the end, which are generally expensive things because they require context saving and switching (some microkernel OSes use "thread migration" to mitigate this) and so forth.

The second problem is IPC. All the servers are isolated from each other and can only communicate through IPC mechanisms. So a microkernel has to end up being a message routing and forwarding service as well. Let's say an application wants to read a file it has open. It calls read(), which traps into the kernel (system call, after all), which the kernel then sends a message to the server which can handle the call (filesystem), so it passes the message to the filesystem server and then switches back to user mode so the filesystem server can handle it. The filesystem server then translates it to a block and issues a read to the partition driver (which if it's a separate server is yet another user-kernel-user transition), which then goes to the disk driver (u-k-u). From here, it goes to the bus handler (because said disk can be on SATA, IDE, USB, Firewire) where the transfer actually happens, and then the message winds it way back to the disk driver, the partition driver, the filesystem driver, then the application.

Switching from user to kernel is expensive - generally requires generating a software interrupt (system call) which triggers into the kernel's exception handler which then has to decode the request. Switching back is generally cheaper (usually just a return instruction which sets the proper mode bits), but you're still taking several mode switches per API call.

No big surprise, these things add up into a ton of cycles.

Microkernel OSes have developed means to alleviate the issue - thread migration being a big one (typically a server is implemented as a thread waiting on a mailbox, it gets the message then handles it). Thread migration means the application's thread context isn't saved, but migrated to the kernel, then passed onto the servers as necessary so instead of having to wake up threads and run the server loop, it becomes more expensive function calls, almost like RPC except the thread that called it is where it's executing on.

In a monolithic OS like Linux, all those messages and IPC are reduced down to function calls (usually through function pointers) - so the application making the system call becomes the only transition - the virtual filesystem handles the call, calls the filesystem driver, which calls the partition driver, which calls the disk driver, which calls the bus driver, ... and then they return up the stack like a typical subroutine call.

Oh, and Windows NT 3.51 did this as well. Guess what? Graphics performance sucked, which is why in NT 4, Microsoft moved the graphics driver into ring0 (kernel mode), thus creating the ability for poorly written graphics drivers to crash the entire OS. But, graphics are faster because you're not shuffling so much messages around. I think Windows has steadily put more and more of the graphics stack in the kernel since then, as well.

Re:Does anyone have any non-silly comments?

[Anonymous Coward]

Even without an IOMMU, you could have drivers in ring >0; you'd just run the risk of them snarfing precious bodily fluids via PCI DMA. All it takes is some function in your memory service that maps contiguous memory into the driver's address space, and tells it which hardware address it's at.

But really, microkernels aren't supposed to be the solution to the Wonky Unreliable Driver Issue. Virtualization is. Personally I'm glad we'll have widespread IOMMUs in about ten years' time.

Re:Does anyone have any non-silly comments?

[naasking]

The performance hit comes from the hardware isolated process model used by modern microprocessors.

Lets be clear: the performance hit comes from the expensive x86/x64 trap handling. RISC processors are on the order of 30 cycles. x86/x64 is on the order of 2,000-3,000 cycles. The braindead x86 architecture is the only reason microkernels haven't already "taken over the world".

The L4 and EROS/CapROS microkernels did a lot of small hacks to reduce the above overhead, and they got some pretty decent performance even out of x86. But contrary to your previous claim, x86 makes good microkernels very difficult to construct.

Re:Does anyone have any non-silly comments?

[serviscope_minor]

Even without an IOMMU, you could have drivers in ring >0; you'd just run the risk of them snarfing precious bodily fluids via PCI DMA.

I thought that was one of the things that IOMMUs were supposed to fix (e.g. like the firewire security hole).

But really, microkernels aren't supposed to be the solution to the Wonky Unreliable Driver Issue. Virtualization is. Personally I'm glad we'll have widespread IOMMUs in about ten years' time.

Well, do the two not work well together? The microkernel alleviates teh segfault in a wonky driver part: the driver just crashes. Without an IOMMU, though it doesn't solve a piece of hardware scribbling all over memory, certainly.

Re:Does anyone have any non-silly comments?

[mdmkolbe]

Performance is a problem but it isn't the problem. The distributed enforcement of policy is potentially a harder problem than even performance.

For example, on a monolithic kernel, ensuring that no process (except a specified list) is both setuid and talks to the network is (relatively) easy because different parts of the kernel can trust and rely on each others behavior. In a microkernel setting, these sorts of policies have to be encoded into how the different services interact with each other. That sort of distributed policy enforcement is much harder and something that we as a discipline are not good at yet. You can even see this play out if you look at the history of the L4/Hurd project and some of the complicated protocols that were proposed for securely establishing a basic handshake between services.

Re:Does anyone have any non-silly comments?

[Anonymous Coward]

I honestly know nothing about the topic, but what about implementing microkernels on ARM instead? Personal computing at least seems to be headed in that direction.

Re:Does anyone have any non-silly comments?

[snadrus]

Greatest post I've read in years!

Re:Does anyone have any non-silly comments?

[i.r.id10t]

http://www.youtube.com/watch?v=CjaC8Pq9-V0&t=25m25s

I dunno, its very *urp* hard to debug

Re:Does anyone have any non-silly comments?

[unixisc]

It's worth noting that Rick Rashid - the original creator of the Mach 3.0 microkernel, works/ed at Microsoft, and also contributed to Dave Cutler's NT project. So it's not surprising that Microsoft would have worked on this concept.

Re:Does anyone have any non-silly comments?

[unixisc]

No, that would be Windows 8. Of course, now we are getting into the realm of silly comments

Academic Use

[Giant Electronic Bra]

If you're interested in understanding microkernel OS architectures, then Hurd might be useful to experiment with. Other than that its pretty close to unusuable as there isn't even basic SATA and USB support (IE you're going to have to install on OLD hardware, or much more likely in a VM where you can supply virtualized IDE).

Honestly, while I certainly don't want to rain on anyone's pet project Hurd has mostly become pointless. Its user space really offers nothing beyond what Linux or other POSIX *nix user spaces offer, and while microkernels are interesting concepts they've never proven to be terribly practical in most applications. Even in terms of microkernel design Hurd is dated. I'd think it would be much more interesting to work on future-looking OSes, say something with a Plan 9-like user space and some more modern experimental kernal with features designed around high core counts and heterogeneous compute resources. Not sure what that is, but I'm sure there are people out there working on stuff like that.

Re:Academic Use

[bill_mcgonigle]

Even in terms of microkernel design Hurd is dated

Well, that would be the place to focus. If Hurd focused on being the best microkernel project (vs. Minix or whatever) then they would attract lots of help from academia. Is there something preventing this?

I wonder, too, since a (the?) major issue with microkernels is the cost of message passing, if some of the newer/alternative distributed architectures (which have an inherent message passing delay anyway) wouldn't be a better fit for Hurd than x86 hypervisors. It's been a long time since I've done any serious computer architecture work, but even back then people were playing with various weird bits of hardware that were very wide and not very deep, with barely an OS to get to the point of being able to experiment with them.

Re:Academic Use

[VortexCortex]

I agree. However, I think "mostly pointless" is the most moronic phrase. You like viruses? Keep using a single stack for code and data and having no fine grained memory access barriers... Think it's "mostly pointless" to try and solve the malware issue? Well, fuck you then. Say a solution is found, it won't be in a monolithic kernel design. We need at least one more layer between Users and Master of the Universe. Hell, we could even have another level under userspace for "plugins", wouldn't it be grand if a plugin couldn't just take over your whole program? Solving any of these issues is basically what alternate OS development is needed for. What's "mostly pointless" is throwing money and time at the monolithic approach and hoping for innovation in operating systems...

Not currently usable by end users does not make something mostly pointless. End users don't give a damn about how the OS provides security or other features. HURD is MOST IMPORTANT because it actually does things differently than all the other mainstream OSs. That you can get 75% of the Debian repo running on it is HUGE. If you don't think so, I reiterate: Fuck you, fool.

Re:Academic Use

[Giant Electronic Bra]

Yeah, I don't know. I can't even pretend to be any more than superficially informed about modern OS design. There was a day when I worked on bare metal and RTOSes, ported FORTH to new processors and such things, but its been 25 years now. I understand that people have developed some more useful communications techniques and that a lot of the issue is CPU designs that assume a monolithic kernel architecture and aren't kind to things like microkernels. I know from casual skimming there are various areas of active research. It would seem like in the future we're likely to have dozens or 100's of cores, at which point dedicating one to running your USB port doesn't seem terribly ridiculous and I'd think that would obviate some of the context-switching issues with current designs.

Re:Academic Use

[Giant Electronic Bra]

My my, and we must suppose you kiss your mother with that mouth too!

I know of no general principle which would make me conclude that message passing is safer than making system calls. In fact they offer pretty much exactly the same sorts of dangers. Much the same argument was touted by virtualization technology providers, and it hasn't proven particularly hard for exploit developers to worm their way from application to guest OS to hypervisor. I'm not at all convinced that microkernels are inherently any safer than monolithic kernels in any practical sense.

As for having more levels of privilege... There are various questions there, one being exactly what containment hierarchy is appropriate? But ultimately its the same old question all over again, how do you guarantee that the messages containing data passing between different sandboxes are benign? Why is it necessary to have a microkernel design in order to achieve this?

Finally, why in fact are you reacting as if I have badmouthed you or the concept of microkernels? I only stated that Hurd is rather obsolete at this point. Mach has been around since the 1980's and while a lot of things haven't changed THAT much its pretty clear that system architectures are evolving rapidly and are mostly held back now by software. Wouldn't it make more sense to develop an OS that was forward looking? IMHO it would draw from a wide range of experience with OSes of all types and incorporate some brand new ideas that are probably needed in order to move into the VERY many-core heterogeneous future.

Even more Finally: I don't think the answer to security issues like malware are going to be found in cleverer software designs. I think the ultimate 'solution' (and it may not look much like a solution to us) will be social and economic. Better software is clearly something we want, but its not THE solution, the bad guys will always have an almost insurmountable advantage in that realm.

Re:Academic Use

[naasking]

If you're interested in understanding microkernel OS architectures, then Hurd might be useful to experiment with.

Not even. Mach is a horrible microkernel. I have no idea why GNU/Hurd hasn't switch to something more serious, like an L4 variant.

Re:Academic Use

[unixisc]

They did try, but failed. The one thing they could have done would have been to fork Minix (since it's a BSDL microkernel) and then build Hurd on top of that. Since Minix is so well documented, they'd have had a better chance had they gone that route.

Re:Academic Use

[naasking]

Any pointers describing why they failed? L4 can run Linux as a guest with comparable performance to Xen's hypervisor, so it's not like it isn't powerful enough as a substrate.

Re:Academic Use

[unixisc]

The GNU site describes the history of HURD's experimentation w/ different microkernels. It doesn't explain why L4 failed - it just somewhat tersely states that its work stopped in 2005, after which 2 more microkernels - Coyotos and Viengoos - were tried out.

As I've noted elsewhere in this page, they could have simply forked Minix 3, which is small and well documented, and gotten a microkernel that provides all the services that HURD requires. After all, Minix is modelled on Unix and provides the microkernel underpinnings, while HURD provides the upper layers that consume the microkernel services. These 2 could have been a beautiful combination if not for the clashes b/w the licenses.

Re:Oh come on.

[VortexCortex]

It's a very elaborate troll. Perl 6 Parrot can run some Java programs on HURD / HIRD. They went all out, I'll forgive them missing the April 1 deadline, it's great fun!

MIcrokernels are yesterdays tech

[Viol8]

As a theoretical design they're very clean and simple to understand. In reality however due to all the message passing and context switching they're dog slow and when every bit of performance matters thats just unacceptable.

Re:MIcrokernels are yesterdays tech

[slim]

Surely in the past "every bit of performance mattered" more than it does today? You can compensate for slow software by throwing faster hardware at the problem. Today we have faster hardware.

That said, I'm not volunteering to use a slower kernel full-time.

Re:MIcrokernels are yesterdays tech

[cpghost]

Not that slow today, provided you use the right microkernel. Look at L4Ka::Pistachio, for example, if you're looking for very fast context switching and message passing in registers without overhead. Now, if you talk Mach, then you're right.

Re:MIcrokernels are yesterdays tech

[Anonymous Coward]

This is rediculous. Modern computers are faster than most people need. We have the cycles to go micro kernel everywhere. There are phone OS that run on a micro kernel! If a phone can do it, so can your PC.

Consider if android upgraded to a micro kernel. Sure, they couldn't sell A9 chips anymore for tablets, but beyond that it would be awesome. The sound server could restart when something crashed, etc. Tablets and phones are a great example of something that should be always up. No one wants to reboot them.

Multicore

[Anonymous Coward]

...most of the components that constitute the whole kernel are running as separate user-space processes and are thus using different address spaces that are isolated from each other.

Is it capable of using multi core CPUs effectively for those processes?

The trouble with micro kernels is that if you're not careful with CPU utilization, you get a slower machine than using a mono kernel. I know because I lived through in the 90s at a big software company that was developing a microkernel OS.

And to that, I can't wait for the performance comparisons.

I'd be surprised if HURD performs well on i3s or less.

Re:Multicore

[unixisc]

Only problem is that HURD doesn't support SMP. Nor x64. Otherwise, an i7 based system would be ideal - it has all the rings of security that HURD needs, the multi-cores would help w/ the message passing & the context switching, while the x64 would make it relevant by not limiting it to a 4GB address space.

As far as the file systems go, I can't think of ONE that is GPL3, which is what HURD would presumably need. I mean, HURD is GPL3, GNU userland is GPL3 but suddenly, the file system is just GPL2? Even the latest file systems for Linux - be it Btrfs or ext4 are not GPL3. Hopefully, they come out w/ one that doesn't suck

Re:QOTD WTF!!!!

[Thud457]

I know, I'm feeding the troll.

In case you were actually offended, place blame where it belongs.
Then help fix the problem by submitting a bug report to your favorite distro instead of just bitching about it.

So how many GNU/whatevers are there

[ebh]

We know about GNU/Linux and GNU/Hurd. ISTR someone cobbling together a GNU/BSD at some point. Any others? GNU/Solaris? GNU/HP-UX? GNU/DR-DOS?

Re:So how many GNU/whatevers are there

[Ogi_UnixNut]

There is Debian, with its GNU/BSD version:

http://www.debian.org/ports/kfreebsd-gnu/

And Gentoo has their variant:

http://www.gentoo.org/proj/en/gentoo-alt/bsd/fbsd/

Those are the only two I know about :)

Re:So how many GNU/whatevers are there

[shia84]

This particular terminology is System/Kernel, and a not at all exhaustive overview would be:
GNU/Linux (Debian, Ubuntu, ...)
GNU/Hurd (Debian has one such distribution, Arch has another called "Arch Hurd")
GNU/kBSD (Debian has one, [0])
GNU/ON (Illumian, a Debian+Solaris kernel distro)

GNU/BSD or GNU/Solaris would be somewhat more like GNU/GNU, which doesn't make a lot of sense.

[0] They call it "Debian GNU/kFreeBSD", as it uses the FreeBSD kernel, which isn't actually called "kBSD" or "kFreeBSD" but has no distinct name, as it's not Mach anymore, but simply "the kernel of FreeBSD"

Re:Oh come on.

[Big Hairy Ian]

Oh come on. April 1st is over. Everyone knows Hurd is a running gag. It's an ancient meme.

You mean this is "Debian does Dallas"?

Re:Loss of face if they dumped it

[CRCulver]

Stallman has already announced that he is content with Linux as the GNU kernel and that he has lost interest in the Hurd project. Hurd is kept alive now by hobbyists interested in alternative kernel designs, not Free Software demagogues.

Re:Loss of face if they dumped it

[serviscope_minor]

If they dumped Hurd now it would be a complete loss of face

Yay it's the daily make shit up about the FSF/RMS thread!

http://blog.reddit.com/2010/07/rms-ama.html

TL;DR

http://lists.gnu.org/archive/html/bug-hurd/2010-08/msg00000.html

Seriously, is it hard to google RMS Hurd before posting crap?

Round and Round

[bigredradio]

This was modded informative because the argument is so old, it's coming back as 'vintage' by hipsters.

Re:Loss of face if they dumped it

[greg1104]

Seriously, is it hard to google RMS Hurd before posting crap?

It takes a while when you have to fetch web pages from other sites by sending mail to a program that fetches them, much like wget, and then mails them back so you can then look at them using a local web browser. (Seriously!)

Re:Loss of face if they dumped it

[serviscope_minor]

Well played!

Stallman is entertainingly single minded, but I hope anyone can respect someone who actually manages to live day to day by the principles he claims to have[*].

[*]Well I say "anyone", of couse, but if your principles include mass murder etc, then respect is perhaps not due.

Re:Loss of face if they dumped it

[Giant Electronic Bra]

Yeah, he's a bit out there, but it would be incredibly hypocritical not to give credit where due. The guy is clearly the prime mover behind a lot of free software. I'm sitting here typing this on my nice FC17 system in Firefox and using all sorts of FSF software practically every hour of the day to run my business etc. The world needs guys like RMS, even if it doesn't seem to know it or appreciate them a whole lot. In my world one RMS is worth 12 Bill Gateses.

Re:Loss of face if they dumped it

[serviscope_minor]

Yeah, he's a bit out there, but it would be incredibly hypocritical not to give credit where due.

Not only that, but he has the annoying habit of actually being right years in advance and banging on about topics that on one cares about because he's far ahead.

Like GNU/Linux. No one cared. But now Android came along and it makes much more sense as people make funny non sensical comments about Linux, confusing the OS and the kernel.

The world does indeed need guys like RMS and they will always seem odd and stubborn. But no normal flexible person will devote their life to an important cause, so you can't have one without the other.

question

[JustNiz]

What, if any, are the advantages that a user would notice of GNU/Hurd over Gnu/Linux?

Re:Oh come on.

[MrHanky]

The Mayans were pointing to the dawn of a new era, the age of Linux on the desktop, which supposedly will last for the next B'ak'tun until Hurd is up and running on the L4 microkernel.

Is It Still Just for Nerds?

[srobert]

Most of us want to popularize the OS enough so that it will continue to be developed, and so that a larger selection of end user software will be developed for it. Getting bogged down in a disagreement about whether it should be called "Linux", "GNU/Linux", or by a distribution name, is counter-productive to that objective. It gives the impression that all of this is only for nerds (and that is a reason enough for most people to want nothing to do with it).
When I refer to the OS as "Linux", I am not discounting nor disrespecting in any way the contribution of the Free Software Foundation or Richard Stallman. I'm trying to use the most common term that is easy to pronounce, and communicates in a way most commonly understood by the listener to refer to the operating system. The fact that "GNU/Linux" doesn't roll off the tongue or lend itself to being written, or typed easily enough, is the reason I don't, and will not, use it.
The discussion reminds me of one in which fastidious guardians of exactitude allow a discussion about western democracy to get sidetracked by the insistence that the U.S. is a "republic" not a "democracy". Technically, they're right. But they're insistence on it interferes with more important ideas becoming the focus of discussion.
So, I'm not going to call it "GNU/Linux". I'm going to call it "Linux". No further discussion will change my mind on the matter. Furthermore the U.S. is a Democracy (close enough).
P.S. I've switched to FreeBSD, which I call "FreeBSD".

Windows 98 vs Windows 2000

[bussdriver]

Remember all the complaints in performance from gamers when they lost all that speed going from a shared memory OS (windows 9x) to a protected memory OS?

Microkernels are a similar problem but without a big corporation to force users kicking and screaming into the modern age. I would like to have Multics like features; my CPUs are mostly idle today. Being able to replace RAM, storage, CPUs without shutdown or even turning off half the computer for most of the day...

It's not like we don't have more CPU power than most users need and a slowing market due to an excess of power... Pros and gamers will complain, but then they don't realize they are losing FPS with today's systems they resisted in the past. Sure reboots are fast, but I hate having a buggy driver or worn out device crashing my system frequently until nail down the source (and if it didn't crash, I could just ignore it and keep the device. I have a LiteOn blueray burner that requires a reboot after moderate use-- plus the pain of digging out an HD with windows just to upgrade the firmware on the hope that they've finally fixed it.)

Technoloy Ecosystem

[ikhider]

This is good news. I am glad people are working on BSD(s), Hurd, Minix, and other systems because it ensures technological diversity. It would be a sad state if only GNU/Linux and proprietary systems were developed. If we have a thriving ecosystem of vaious operating systems and kernels, that bodes far better for advancement than a monoculture.

Re:Oh come on.

[RLiegh]

HURD was announced in 1990, "What is love" came out in 1993, "Hurt" came out in 1994...
The More You Know!

Re:Loss of face if they dumped it

[Zordak]

Like GNU/Linux. No one cared.

Hate to break it to you, but we still don't care. Seriously. 99% of the people who use Android have no idea that it has anything to do with Linux. They just call it Android. And of the small minority of people who run "Linux" on the desktop, about 99% (from my observation), just call it "Linux." Richard Stallman and a handful of his groupies are still the only people who still care about putting "GNU" in front of Linux.

Re:Oh come on.

[lister king of smeg]

The GNU/ in this case is actually unneeded as it is a GNU project unlike GNU/Linux where the Linux kernel was not a GNU project.

Re:Oh come on.

[binarylarry]

Ha! And I recently heard Jesus has risen!

Re:Oh come on.

[UltraZelda64]

But you see, it was a joke. That game was trash, completely unable to live up to over a decade's worth of expectations. Hell, even if it was released in the early 2000s it would have still sucked.

Re:Oh come on.

[lxs]

Turns out, he only got up to pee and then went back to sleep.

Re:Oh come on.

[TWX]

So, a different kind of joke then...

27 years jacking around

[iggymanz]

HURD only proves that Stallman/FSF couldn't make a kernel, ivory tower theoretical bullshit didn't work. The fact they finally had to borrow Mach shows they couldn't design a kernel themselves, and even today in the project there is debate about using other microkernel foundations but of course no talk about designing from the ground up.

Hint, if you're in a computer science class that claims to build its own OS, and they use Linux or Mach or whatever to layer various message passing schemes on top, you are NOT building an operating system.

It's a school science project, doesn't run on modern processors except in i386 mode, unusable for any practical purpose. it needs to die

Re:27 years jacking around

[unixisc]

For educational purposes, Minix is a much better option. As it is, the OS comes with Tanenbaum's textbook Operating Systems Principles

HURD vs Linux

[unixisc]

Debian Wheezy is Linux. Debian GNU/Hurd is HURD. The former is the usual Linux monolithic kernel. The latter is the GNU implementation of the Mach 3.0 microkernel, w/ the HURD collection of Unix-like services running on top of it.

The only reason to use HURD would be that it would be fully liberated software - if I'm not mistaken, HURD would be GPL3, whereas Linux is GPL2. Essentially, the only rationale to use it is religious i.e. it has the purest license. It's however not the best by a long shot - even if one wants a microkernel OS, Minix 3 would be the best bet there.

The thing that intrigues me is - would HURD be available w/ the entire collection of Debian software, or just the ones that the FSF likes? Like would it have the choices of KDE & GNOME, or just GNOME and maybe GNUSTEP? It would obviously have the entire GNU userland, all GPL3, but would HURD packages contain only the purest of liberated software i.e. GPL3 or AGPL3 licensed software? I'd be curious. On a different note elsewhere, how is Arch Hurd doing?

Hurdles for HURD

[unixisc]

Main problem for Hurd would be support for hardware who needs closed parts (firmware, binary drivers) as Hurd propably is GPL3 which essentially forbids usage of such things without disclosure to user, essentially killing any chances of having binary Nvidia driver supported. Still, most of open source stuff can be ported to be used with it.

Yeah, that is what would make it pretty much a non starter on the desktop, since it's probably GPL3 - or else, its rationale for existence separate from Linux is as strong as the rationale for East Germany or North Korea existing. Since binary blobs would be banned here, they'd be limited to Intel & AMD GPUs, however bad, and then, on top of that, run X, and GNOME 3.whatever in fallback mode, or in real mode if the drivers are liberated. In short, the best use of HURD, where it would be almost guaranteed to work right, is in CLI mode, if one is like RMS and lives in an emacs world. In which case, the login script could just as well include that, one goes into emacs, and then is off doing everything that one does there.

Just wondering if the "Libre-" Linux crowd will celebrate this, or release a list of 50 reasons why Debian doesn't pass the purity test and therefore, Debian Hurd can't be endorsed? I sure wish gNewSense comes up w/ a HURD distro based on this one.

Re:Hurdles for HURD

[aestrivex]

For the record, there is already a highly featureful and mature operating system that does the "emacs world" thing -- it is called GNU/Emacs, although I hear it lacks a decent text editor. (With all the troll about GNU/Linux, I felt entitled).

Re:Hurdles for HURD

[unixisc]

But it has to sit on a separate kernel, doesn't it? Which is Linux. Well, now, you could put emacs on HURD, and then, it would be a pure GNU sysem

Big OSs in the 90s

[unixisc]

In 1994, at university, I was in much the same situation (except it was only Sun -- we didn't have SGI boxes, and I couldn't make head nor tail of the solitary NeXT box).

I cut my teeth on SunOS. Then I got a 486 and ran Slackware on it in my dorm room. I found that bash was better than csh (which our admins had made the default shell on SunOS). I found that GNU date was better than SunOS date.

Then I found that our admins had a /usr/gnu/bin NFS mount for the Sun boxes, which we just had to put in our paths to make SunOS feel like Slackware.

So for the last three years of my four year course, I was running GNU/Linux at home and GNU/SunOS in the labs.

The point being that the GNU utilities were the "nice thing" I was interacting with. The kernel was only there to prop them up.

It was just the opposite in my case. We had a few NeXT boxes in the computer center, along w/ a few IBM MVS, DEC Vaxen & Sun SPARCstations. I could follow the VMS commands some, but the IBMs and Suns were painful to use, since I was brand new to Unix - which in Sun's case was SunOS/OpenLook. But the NeXT was a breeze, and using NeXT file manager made the entire Unix file system pretty transparent - one could see what was under /bin, /usr, opt/ and so on. And then there were those cool NeXT apps like Mail, NewsReader (a Usenet app), Lotus Improv and a whole lot of others that were a breeze to use. In our department, the VLSI lab had some DECstation 3000s (based on the MIPS R3000s), Computer Design lab had IBM RS/6000s, CS lab had SPARCstations, and so on. You had DECwindows in the DECstations, OpenLook on the Suns, and so on. Of all of these, the NeXTs were the only ones where you didn't have to know anything in order to get started?

GNOME

[unixisc]

Not to be pedantic, but actually, it was originally GNOME. Stood for GNU Networked Object Model Environment. Something that they abandoned in GNOME 2 onwards, which is where they should have renamed it, since it no longer had its original goals

Debian varies

[unixisc]

In Debian's case, it wouldn't be totally right, since Debian offers a choice of kernels - Linux, kFreeBSD and now HURD.

Typical HURD: out of date

[msobkow]

I mean, really. 386 is their standard build? Not 64 bit?

Let me know when they catch up with the century.

Re:Oh come on.

[bbsalem]

No, he meant that "The hurd is in the stall, man!"

Re:Oh come on.

[socceroos]

> Everyone knows GNU/Hurd...

Haven't GNU/Hurd...

There, FTFY.

Re:Oh come on.

[jeremyp]

No, it's the GNU operating system with the Hurd kernel whereas GNU/Linux is the GNU operating system with the Linux kernel. The GNU in GNU/(Hurd|Linux) stands for all the userland stuff.

Deserting GNU in droves

[unixisc]

The notion that without the GNU tools, a Linux distribution would not be usable, and therefore the GNU prefix should be applicable to Linux also ought to apply to Minix itself, which like Linux, was never part of the GNU project (and was released under a different license), but was practically unusable out of the box, and most users of it took the source code to the GNU tools, which was freely and readily available, and compiled them to run under Minix to create a usable system. Minux, starting from approximately v 3 onwards, actually started being distributed with the GNU tools to make it more fully functional out of the box, but nobody ever tries to call Minix GNU/Minix.

That said, since GPL3 surfaced, more and more projects have been looking at alternatives. Minix, for instance, has joined FBSD in using LLVM/Clang and uses NBSD userland. Several projects have switched compilers from GCC to LLVM/Clang, GNU userland to Busybox, and so on. It wouldn't be too long before the only people using GNU utilities would be the FSF crowd.

Battle of philosophies

[unixisc]

That is ironic, given that RMS has always belittled the concept of 'open source' and emphatically stated that the purpose was not to build better software, but to build liberated software. In fact, his philosophy has more tolerance for shabbily written code, as long as it allows the 4 GNU freedoms. Given that, HURD should have been able to be whipped up really quick, but it wasted years experimenting from one microkernel to another. I know the licenses don't allow it, but if it did, taking HURD and putting it on top of Minix3 would give it the best of both worlds

Stallman & HURD?

[unixisc]

Is RMS associated w/ HURD any more? He is on record as having endorsed Linux over it.

Does multi-core arch help alleviate that issue?

[unixisc]

From what you are describing, the reason microkernel OSs are slow is the switching from running an unprivileged task (a ring 3 task) to a kernel task (a ring 1 or 0 task). But in that case, given that most modern CPUs are multi-core, doesn't that alleviate that issue? I mean, let's say CPU2 is busy doing somethig and an application needs to make a system call, can't that call go to CPU0? That way, CPU2 merrily keeps humming along, and one of the unutilized CPUs starts getting utilized. Also, most processes don't make full use of the extra cores, but if you have a microkernel OS, can't all that task switching be avoided simply by using, say, different cores? Like use CPU0 for ring0, CPU1 for ring1, and so on (since most systems are quad core or more, and you can then route any system request to particular CPUs dedicated for just that)

Re:Does multi-core arch help alleviate that issue?

[Pinhedd]

>From what you are describing, the reason microkernel OSs are slow is the switching from running an unprivileged task (a ring 3 task) to a kernel task (a ring 1 or 0 task). But in that case, given that most modern CPUs are multi-core, doesn't that alleviate that issue?

There are some interesting scheduler hacks that may be done here to take advantage of multi-core resources, but in general, migrating a task from one processor to another has a cycle cost similar to switching tasks, as does making a cross processor call. At the moment, HURD has no support for SMP/SMT.

>Also, most processes don't make full use of the extra cores, but if you have a microkernel OS, can't all that task switching be avoided simply by using, say, different cores? Like use CPU0 for ring0, CPU1 for ring1, and so on (since most systems are quad core or more, and you can then route any system request to particular CPUs dedicated for just that)

An implementation in which one or more processor cores are used purely for handling system related tasks is actually a very effective solution, IBM uses similar implementations in their Z series mainframes. The PS3 also used a similar processing model, the purpose of the PowerPC based PPE is to load and schedule the various SPEs.

The caveat of doing this is that there's still a delay between the time that the system call is issued and the time in which it responds. IBM has solved this by scheduling 4 threads concurrently per processor core in their latest POWER 7+ processors (4 way SMT, similar to Intel's Hyperthreading).

This particular kind of process model wouldn't work too well on a system that wasn't designed for it and performance of highly concurrent applications would suffer as a result of the lost processor core. Modern x86 processors are simply far more suited to hybrid and monolithic kernels than they are towards microkernels. Other architectures such as ARM and PowerPC are better suited towards microkernels. QNX used in BlackBerry's Z10 and Q10 smartphones is a real-time microkernel based operating system and it manages to squeeze out very acceptable levels of performance on Qualcomm's Krait architecture.

The question at this point then is whether or not microkernels are at all relevant for desktop environments anymore. Modern programming techniques and hardware technologies have boosted the security and stability of monolithic and hybrid kernels to the point that the advantages of microkernels have diminished.

Re:Does multi-core arch help alleviate that issue?

[unixisc]

It would seem that CPUs that have VLIW underpinnings, such as Itanium or the ex Transmeta CPUs, would then be ideal for a microkernel based OS, such as Minix (I'm not thinking about HURD here now, but rather mature established OSs that have microkernels, be it QNX or Minix3 or L4 or Chorus). Since one of the ways of extracting more parallelism from workloads could be separating out say scheduler operations or other context switching, and dedicating one or more CPUs to just those, while having the others do just the processes being done on them and nothing else. At least that way, not only is CPU utilization improved, but so is stability of the OS as a whole, without getting dinged in performance.

Re:Does multi-core arch help alleviate that issue?

[Pinhedd]

I don't think so.

The performance hit does not stem from instruction decoding, so static multiple dispatch and dynamic multiple dispatch don't matter. Rather, the performance hit stems from the fact that most CPUs only execute one thread domain at a time per logical processor. They execute that particular thread until the time slice expires or a system call is made, then switch context to the next thread. Scheduler instructions will not be scheduled at the same time as application instructions since they operate in different contexts.

Re:Does multi-core arch help alleviate that issue?

[unixisc]

I meant that in VLIW, you have an MIMD model, which would enable multiple dispatches to happen in the first place, which was also true in Transmeta, but is not true in AMD, due to the fewer security rings. I don't exactly know about the Itanium internals, but I think it's a safe bet that it doesn't have fewer rings than x64. Unless they implement the rings in software, which would change things totally. So scheduler instructions would be travelling in parallel separately from the application instructions, but given the multiple execution units that a VLIW normally has, each will find its own playground without having to take turns

hypervizors & microkernel

[unixisc]

Uh, no, hypervizors are pretty much the very opposite of microkernels. In microkernels, things like device drivers live in user space, and have to pass messages to the kernel to access particular resources. In hypervisors, you have a mammoth kernel at the bottom that supplies services to all host VMs running over it. In case of VMware, the underlying OS is a Linux variant called the ESX server. Which is certainly not microkernel