GNU Hurd Gets Improvements: User-Space Driver Support and More
jones_supa writes "At FOSDEM 2014 some recent developments of GNU Hurd were discussed (PDF slides). In the name of freedom, GNU Hurd has now the ability to run device drivers from user-space via the project's DDE layer. Among the mentioned use-cases for the GNU Hurd DDE are allowing VPN traffic to just one application, mounting one's own files, redirecting a user's audio, and more flexible hardware support. You can also run Linux kernel drivers in Hurd's user-space. Hurd developers also have working IDE support, X.Org / graphics support, an AHCI driver for Serial ATA, and a Xen PV DomU. Besides the 64-bit support not being in a usable state, USB and sound support is still missing. As some other good news for GNU Hurd, around 79% of the Debian archive is now building for GNU Hurd, including the Xfce desktop (GNOME and KDE soon) and Firefox web browser."
Does it?
Hopefully it will be launched until 2038.
I have been working on Hurd for quite a long while (made contributions to the kernel years ago), and I would like to bring up the pertinent point that Beta sucks!
Having a project like HURD reflects poorly on Open Source/Free software. It's kind-of emblematic of the major problem with non-commerical software projects; namely, without a central guiding force and a *real* budget, big software projects have a very difficult time getting finished.
Stallman should just kill it. It's pointless.
Hurd is based on a failed Computer Science Pipe Dream, the Micro Kernel. Why would anyone embrace something that is so slow? (except to write a phd thesis)
As a rule, I support the idea of making a new OS just for the sake of it. But the important thing to realize most of these will never really get too far as in terms of market share.
Linux success was by luck. It came out when BSD had a lot of serious licencing issues and a big demand for something free, it was developed to a point of being useful fairly rapidly and got a lot of attention. At the same time the 32bit computers for home users were available, and people were jumping on getting a Real OS to do real work on. MS/DOS and Windows 3.1 wasn't a good option, for real work, other solutions just costed way too much money.
Hurd which was made during the same time BSD was having their issues, however it was more of am ambitious project, and couldn't get in during that opening which Linux did.
Now BSD with Free/Open/Net being based on original Unix code, came out of the Licencing mess as an open solution, with some still bad taste in peoples mouth. However they came out a bit more stable than Linux at that time. Where xBSD was being used in a business production settings, for a long time, while Linux matured and took over.
There is a lot of flamewars about GNU being superior then the new BSD license. Saying Linux is proof of this. I would disagree GNU and BSD are both Open Enough standards for general adoption, and Linux success was based on getting in at the right time. Otherwise you would expect HURD to be nearly as possible as BSD is now.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
Have you heard about the Hurd?
Well, everybody knows that the Hurd is a turd!
Hurd Hurd Hurd
The Hurd is a turd
Hurd Hurd Hurd
The Hurd is a turd
I'm not a developer, but if a Linux driver exists that is written to sit within a kernel, the way it is in Linux, how does one have that driver run in user mode in any OS? I'm somewhat not getting that.
I really think you're wrong. QNX, for example, is an amazing, fast operating system. Microkernels make certain things difficult, but for all of those difficulties there are technical solutions. That HURD can't implement these is not the fault of the microkernel architecture.
Sorry but it doesn't matter with Server-Client architecture operating systems are drivers located in User Space or in Kernel Space as long they are separated from the microkernel itself.
The whole reason why Server-Client architecture exist was to avoid problems what the Monolithic operating system architecture had with device driver or operating system function crashing causing whole operating system (kernel) crashing and so on the whole software system to crash at that moment.
But as we can see, Monolithic OS architecture isn't a problem like Linux kernel can proof that whole operating system can be a monolithic but still modular in binary level and be very stable, secure and fast.
Hurd would have been nice operating system if they would have got their microkernel working right and they would not chose to use Server-Client architecture for it instead superior Monolithic architecture what Linus Torvalds chose to Linux operating system (went on that time under different name before it got renamed as Linux as everyone knew it afterwards and before GNU fans tried to claim Linux is a microkernel and not a monolithic).
He said "kernel" and not to "microkernel". So he means the whole HURD operating system and not just its one of the many microkernels HURD has included.... this in sense that he claims HURD is a kernel like monolithic operating systems are instead HURD is server-client and so on just operating system and not a kernel because it has a microkernel and servers.
It used to be slow on single core CPUs. But does that have to be the case w/ today's multi-cores? I would think that in the x64, each ring could have its own CPU. They could run the microkernel on one core in ring 0, the OS management on a second on ring 1, and the user mode programs on a third on ring 2, and any VMs in ring 3.
Straw Man
Then it's simply less efficient in terms of power.
Comment removed based on user account deletion
Comment removed based on user account deletion
Hmmm, should I install Hurd or Plan9? .....
Bringing you the technology of 1997...TODAY!
Chas - The one, the only.
THANK GOD!!!
Wouldn't this make a good automated testing layer for kernel modules?
My understanding is that inter-core communications, while fast, are not as fast as the things a single core can do by itself when only interacting with the level 1 cache. Since the rings of a microkernel would be communicating very frequently and as fast as possible, I'm not sure it would work better.
But more importantly, free software is full of tens of thousands of experiments that didn't seem to make sense at a start. Most wither and die, a few become very big and hugely popular, and even the ones that never see widespread use often serve as a way their authors learn more about the problems they're trying to solve. Maybe the next major revision of the HURD will contain some architectural innovation that improves speed. Maybe some HURD developer, or even just someone reading the HURD source code, will learn something that makes them a better contributor to monolithic kernels. Any benefit is great, nobody is forced to work on it or use it.
An interesting historical tidbit about QNX is that it was started more or less on the basis of a textbook implementation of a microkernel with real-time features. In the literal sense that the company's co-founders did a class project where they implemented a basic realtime microkernel in an OS class, wondered why there wasn't something similar in the marketplace, and founded a company to sell it.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
I think you confused the purpose of IOMMU. It's for restricting the device's memory access. Without IOMMU, it just means that any firmware running on the device's coprocessor can access the main memory unrestricted, meaning that a hacked firmware can root the machine. IOMMU virtualizes device's access to main memory so that doesn't happen. On a machine without IOMMU, you can still run device drivers in user space as long as the kernel sets up the correct memory mapping for the device's PCI address space. That's called memory mapped I/O and has nothing to do with IOMMU.
I once had a signature.
Shazbot! We ran into some trouble getting the comments.
Try again... na-nu, na-nu!
WTF IS THIS GARBAGE?
Fuck Beta!
I'm not saying that Linux is the be-all, end-all of Free Operating Systems, but after 24 years I think Hurd meets the definition of a failed software project. (And you think Duke Nukem Forever was in development for a while!)
If the developers want to continue developing it, great. But I hope the project is not siphoning off any resources from the FSF's productive work. But I have my doubts as long as the FSF webpages continue to treat Linux as some sort of temporary work-around to Hurd not being available. (And please, just please, let go of the whole GNU/Linux thing... that ship sailed about fifteen years ago.)
User space driver's are one thing, but I'm still waiting for the day whe HURD gets a user.
GNU?Hurd will be at the same level of hardware support as Windows 95 in a few years
Politics is Treachery, Religion is Brainwashing
These guys are fast!
IDE AND AHCI. wow!
Your answer sounds like it is nothing more than the regurgitated result of the Torvalds - Tenenbaum debate. Basically it was an argument between the creator of Minix (Tenenbaum) and Torvalds who was inspired to write Linux after playing around with Minix. Torvalds outright called Tenenbaum an idiot and since then we have this single argument as some sort of proof that macrokernels are the holy grail of OS design. And this was over 20 years ago. Though in the end the Linux kernel won because it was available and working.
This ancient argument still poisons peoples opinion about kernel topologies and I still believe there is some hope for microkernels in the area of security. Partitioning in a microkernel is a bit more powerful than jails as Root is not needed to access things that would normally lie in kernel space (e.g. drivers.) Each user can be given their own drivers and user-space outside of the scope of root. Root serves as the true root user, NEVER allowing users any access to it.
Here is a good excerpt from the wikipedia article on microkernels (Hurd uses Mach):
So there you have it. The old argument doesn't appear to hold any water simply because no one has ever undertaken the task of actually building a modern u-kernel based OS for mass consumption. Torvalds is a bit of an egomaniac and a blowhard (though I am very grateful for his efforts) and I doubt he would ever change his opinion until someone actually wruites a u-kernel OS that gives Linux some serious competition. And I doubt it will ever happen because of a great quote I once read:
"Plan 9 failed simply because it fell short of being a compelling enough improvement on Unix to displace its ancestor. Compared to Plan 9, Unix creaks and clanks and has obvious rust spots, but it gets the job done well enough to hold its position. 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. (emphasis mine)
-Eric S. Raymond
This quote is about Plan9, the bell labs "successor" to Unix. It really explains why the sometimes better technology fails to replace existing technology. And it rings true in any area of engineering.
The Duke Nukem Forever of kernels is inching its way closer to release! Yay! I can't wait to install it so I can run firefox on another FSF desktop! I'm such a rebel!
It's the year of the GNU Hurd Desktop!
Some things I took from the PDF slides:
* 64 bit support has only just started despite the currently popular 64-bit architecture (AMD64) being available over a decade ago.
* No USB and no sound yet. Good work there.
* Whoever did the slides has poor English ("Should be not very complex"), though that's hardly the fault of Hurd so I'll give it a pass. Someone should have probably read the slides first before making them final though.
The lack of USB and sound and the fact that 64-bit support has only just started makes me wonder why people give Hurd any attention in the first place. To me it looks like a failure - technology is a moving target and you have to be able to develop faster than they have if you want to have any chance of a usable operating system capable of functionality most people expect. To the developers I'm sure they don't see it as a failure, probably because they have no pressure to make it conform to a level similar to other systems (no-one uses Hurd to do anything of merit so there's no pressure to improve it within a realistic timeframe). To the developers it's a hobby, and that's fine. But given the lack of progress I still don't understand why it gets attention.
Posting anon because fuck beta.
Why is it that so many non-coders have so many opinions as to what coders should do with their time? It's as if you think that we are somehow here to scratch your itches, rather than our own.
The Amiga microkernel was fast because there was no memory protection. "Kernel" entry consisted of pushing a few registers to the stack and doing a jump. Context switches were similar.
Practically no one is willing to do without memory protection today, and it is likely that achieving Amiga-like context switch times while retaining some kind of memory protection would require significant hardware changes.
Finally! A year of moderation! Ready for 2019?
OS X is a microkernel.and appears to be doing quite well.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
Interesting how many people come up with negative arguments against Hurd & microkernels in general, obviously without having any experience in system design at all, simply citing the same ancient crtitisms that were raised 20 years ago. Just to make this clear: performance is not the issue with microkernels today. You probably even have a cell phone that is running a microkernel as hypervisor below your actual advertised OS like Android, Symbian, Linux and more. You are not seeing it, and the vendor did not tell it, but it's there. Running on a lousy weak ARM CPU. You have a fruit phone instead? Then you are running the XNU microkernel instead.
Negative prejudices, floating around in the mass of people, are probably THE biggest problems an alternative system like Hurd has, that prevents it for being accepted by people, being adopted by new developers and thus against allowing it to grow.
Most of you are probably fine with a monolithic kernel like Linux ... today. There were also times where people were fine with systems that did not provide memory protection & virtual memory. They were simple, they were fast, so why do we need fancy stuff? But fact is, our systems are growing constantly and stability, complexity, timing and security issues already reached a level where they become hardly satisfiable with monolithic kernels. Nobody today would consider building a huge ferry or supertanker where a tiny leak could float the entire boat. But that's eactly what you got with monolithic kernels.
I'm using Linux, developed device drivers on it for years, but I do think that its design is not able to fulfill requirements soon to come. Especially the current tendency from user based isolation & protection over to task and program based isolation & protection is simply not feasible with a monolithic kernel.
So I am very happy to give Hurd a chance. I hope you too.
MySQL/MariaDB is crap and a waste of developer effort.
Seriously do yourselves a the rest of the world a favor and stop implementing applications using that crap. There is no place for it. Its not a good as an enterprise even a single application database and its not a good embedded database either. But ignorant assholes keep implementing applications in it.
You've missed that the "beige box is the hard drive" people don't consider something is an operating system until it has a GUI solitaire card game in userspace. To them that card game is part of the operating system simply because it came with the computer. Anything with less than that they consider too archaic to have an operating system. Text screen on a linux server? "How quaint, obviously far less advanced than a TV program recorder" they think.
Thus it's better ignoring them instead of trying to feed them the textbook definition that they are deliberately ignoring.
WTF!
What on earth are you basing that on or are you just punching a strawman? How is he more of an egomaniac than ANYBODY in politics and media?
Yes, I've heard the 'real-time' arguments in embedded but for consumer devices are there tangible benefits to QNX vs Linux?
I'm just thinking, hypothetically, of when Blackberry.com goes under - whether the assets be sold off again to a standalone QNX entity.
Or would it be useful for a company like Samsung re-basing their Android and Tizen efforts on their own proprietary kernel to differentiate their offerings from HTC and LG etc?
OS X is a microkernel.and appears to be doing quite well.
OSX does not have a microkernel.
Mach.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
Mach != microkernel. It's a piece of operating system building block code which implements virtual memory primitives, task context switching, and IPC primitives (message passing).
Now, one obvious (and common) thing to do with those three basic pieces of functionality is to use Mach as a microkernel in a true microkernel OS, one where device drivers and filesystems and so forth are farmed out to separate tasks which live in independent virtual address spaces and communicate with each other via Mach IPC. Paring the highest privilege code down to VM, process management, and IPC primitives, and implementing the rest as isolated message passing modules -- that's pretty much the classic definition of a microkernel.
But you don't have to use Mach that way, and the OS X "Darwin" kernel doesn't. Everything in-kernel lives in a single address space, and communicates by direct function calls instead of message passing. Some userland features (shared mem, IPC, threads) are built on top of Mach primitives instead of the traditional BSD primitives, but that doesn't make the kernel a microkernel, just a funny BSD variant with Mach code replacing a bunch of the BSD code.
The default mode of Linux use on servers is inside virtual machines (i.e. managed by a hypervisor). Same for Windows.
On the desktop we have Qubes OS and its ability to sequester hardware devices to VMs using IOMMU / VT-d, so the drivers for those devices are effectively contained.
Monolithic kernels have failed at security, so they've been demoted to largely non-security roles, held apart from the core OS like the driver modules of a microkernel.