Debian GNU/Hurd 2019 Released(lists.debian.org)
lists.debian.org
Debian GNU/Hurd 2019 Released
https://lists.debian.org/debian-hurd/2019/07/msg00001.html
97 comments
I think that it is exciting that people are still working on Hurd and there is a new release synced with Buster. I think there is latent potential in microkernels and that we may actually be at in position to exploit some of the benefits such as heightened security and stability. While at the same time the performance cost of context switching could be reduced due to the higher number of cores on modern chips (especially compared to the hardware available in the 90s). One of the biggest adoption challenge any new operating presents is hardware compatibility and well a reason to try it. 80% software compatibility with Debian is a big accomplishment, so this is probably worth spinning up a virtual machine to play around with.
Well I've been hearing about those benefits for at least 20 years. None yet actually sighted in the wild. Any attempted explanations from the microkernel religious zealots has been thoroughly unconvincing (because mach is slow, so?). Maybe you're right, I'd love to see it if you are. But while prior performance is no guarantee of the future, as they say in the funds management adverts, a pattern of repeated failure is something maybe not to completely ignore. Is there a reason for it that is being overlooked or glossed over. (In mutual funds it was and is M.E.R.) Stallman talks about hurd being really hard to debug, is that a thing? Or is there some kind of combinational explosion using multiple servers a message passing that isn't there with a monothlithic kernel? Something else entirely?
Anyway I'll go back to the american monolithic kernel conspiracy to destroy OS research and keep the Europeans out and ask the brothers if they can think of anything. (That's a joke, right? Yet I've heard it said in the absence of irony...)
Anyway I'll go back to the american monolithic kernel conspiracy to destroy OS research and keep the Europeans out and ask the brothers if they can think of anything. (That's a joke, right? Yet I've heard it said in the absence of irony...)
Well Intel chose minix to run their often despised management engine, so their engineers saw some benefit there to the microkernel architecture. Google is putting at least nomimal developer resources into Fuschia. And the L4 microkernel and derivatives displayed that microkernels aren't doomed to be slow.
I think that Linux is probably going to be the dominant free software kernel for quite some time especially since it has finally gotten to the point of at least receiving nominal driver support by hardware manufacturers. So Hurd will be a curiosity for now but considering its history it is still very cool that development continues. Whether it will become useful in ways that Linux is not remains to be seen.
I think that Linux is probably going to be the dominant free software kernel for quite some time especially since it has finally gotten to the point of at least receiving nominal driver support by hardware manufacturers. So Hurd will be a curiosity for now but considering its history it is still very cool that development continues. Whether it will become useful in ways that Linux is not remains to be seen.
The L4 microkernel is currently being used by Apple in the secure enclave.
See https://support.apple.com/en-us/HT209632
See https://support.apple.com/en-us/HT209632
And General Dynamics[1] bought OK Labs[2] in 2012, so presumably OKL4 or a descendant is in use there, eh? (In addition to "over 2 billion mobile phones".)
[1] https://en.wikipedia.org/wiki/General_Dynamics
[2] https://en.wikipedia.org/wiki/Open_Kernel_Labs
[1] https://en.wikipedia.org/wiki/General_Dynamics
[2] https://en.wikipedia.org/wiki/Open_Kernel_Labs
Looks interesting. My former colleagues worked on porting osx to l4 more than a decade ago.
That still doesn't look like a microkernel based, multi server os to me and does not claim to exhibit those of touted advantages. This reminds me more of dresdens live demo cd from about 2006. Great stuff, but more of a virtualisation layer than an os.
I'd like to see it stand up.
That still doesn't look like a microkernel based, multi server os to me and does not claim to exhibit those of touted advantages. This reminds me more of dresdens live demo cd from about 2006. Great stuff, but more of a virtualisation layer than an os.
I'd like to see it stand up.
Just out of curiosity, are you saying you don’t think the OS running on the Secure Enclave processor (which is separate from the main OS) looks like a multi server microkernel, or are you still referring to the osx on L4 Experiment you mentioned?
I've worked on l4 fwiw.
Show me those benefits on the wild. Intel's use of Minix, Qualcomm's use of l4 aren't showing me those benefits yet. If that's changed and they have I really do want to see it. Pointing out i haven't yet shouldn't be a sin, it should be quick to prove me wrong with some reasonable links with production ready more secure, more robust OSes. I'd pay performance for security and reliability in many instances. But AFAIK I can't.
Show me those benefits on the wild. Intel's use of Minix, Qualcomm's use of l4 aren't showing me those benefits yet. If that's changed and they have I really do want to see it. Pointing out i haven't yet shouldn't be a sin, it should be quick to prove me wrong with some reasonable links with production ready more secure, more robust OSes. I'd pay performance for security and reliability in many instances. But AFAIK I can't.
[deleted]
You may also recall hearing about the benefits of GC for the 40 or so years before it became mainstream (because GC is slow, right?).
When advantages exist, they will eventually be exploited. It may take new research (better algorithms), new hardware (faster processors), or a new context (internet security), and those take time, but the original reasons for inventing the technology don't expire. As far as application of technology goes, a couple decades is not very long at all.
Nearly every computing technology I use today was loudly rejected by the mainstream, right up until it wasn't. Being unpopular seems to have no impact on the eventual success of computing technology, if it's a good idea.
When you have to resort to name-calling ("religious zealots") to explain why you won't look at actual advantages in computing, it makes me even more convinced that it's the correct approach, and will eventually win out.
When advantages exist, they will eventually be exploited. It may take new research (better algorithms), new hardware (faster processors), or a new context (internet security), and those take time, but the original reasons for inventing the technology don't expire. As far as application of technology goes, a couple decades is not very long at all.
Nearly every computing technology I use today was loudly rejected by the mainstream, right up until it wasn't. Being unpopular seems to have no impact on the eventual success of computing technology, if it's a good idea.
When you have to resort to name-calling ("religious zealots") to explain why you won't look at actual advantages in computing, it makes me even more convinced that it's the correct approach, and will eventually win out.
[deleted]
Graphics drivers.
I'm curious, but why are people still spending time and resources on Hurd?
Is it curiosity or is there some use case for Hurd that I'm not aware of?
Thanks.
Is it curiosity or is there some use case for Hurd that I'm not aware of?
Thanks.
I can't speak for the developer of Hurd.
But I think it's fun and something different.
It's one of the few OS up there that seems to be able to take advantage of multicores.
Other such as barrelfish and dragonflyBSD.
But I think it's fun and something different.
It's one of the few OS up there that seems to be able to take advantage of multicores.
Other such as barrelfish and dragonflyBSD.
???
Hurd doesn't even support SMP yet.
Hurd doesn't even support SMP yet.
That's correct Hurd doesn't support SMP yet [1]. In theory it should and I'm waiting for that.
Kind of like how I waited for HAMMER2.
1. https://www.gnu.org/software/hurd/faq/smp.html
Kind of like how I waited for HAMMER2.
1. https://www.gnu.org/software/hurd/faq/smp.html
Because we already have enough UNIX clones and there are people that care about bringing forward the computing stack with modern concepts.
personally, I think people who are interested in hurd should take a look at redox. Its a new microkernel with similar design goals that uses rust as its implementation language.
The L4 ecosystem is much more mature. There are formally proven variants like seL4, and more widely used variants like wrmOS.
https://en.wikipedia.org/wiki/L4_microkernel_family
I am excited to see how redox evolves, but unless they start writing, virtualizing, or porting drivers it is not much more than an experiment in how well Rust can handle OS programming.
https://en.wikipedia.org/wiki/L4_microkernel_family
I am excited to see how redox evolves, but unless they start writing, virtualizing, or porting drivers it is not much more than an experiment in how well Rust can handle OS programming.
Hurd is part of the GNU system; it's the intended kernel for the GNU userspace. Linux has been used as an intermediary because Hurd isn't ready for widespread use. But the idea has always been that Hurd would replace Linux and create a GNU system that is entirely under the FSF.
Beyond the philosophical differences, another difference is that Hurd is a microkernel and Linux is monolithic. Hurd can be considered a research project for exploring microkernels. The most well-developed microkernels are not open source or free.
Beyond the philosophical differences, another difference is that Hurd is a microkernel and Linux is monolithic. Hurd can be considered a research project for exploring microkernels. The most well-developed microkernels are not open source or free.
> But the idea has always been that Hurd would replace Linux and create a GNU system that is entirely under the FSF.
I don't think that's the case. The FSF has long been satisfied that Linux meets its goals for an OS kernel, and the Hurd project has changed somewhat from "this will be the final piece of the GNU operating system" to "this is something we're working on to explore microkernel design." I think its developers have given up on it ever replacing Linux, as it's very behind in hardware support, and the gap is only ever growing rather than shrinking. For example, it doesn't support multicore or 64-bit userland (in a time when projects are pulling 32-bit userland support!).
I don't think that's the case. The FSF has long been satisfied that Linux meets its goals for an OS kernel, and the Hurd project has changed somewhat from "this will be the final piece of the GNU operating system" to "this is something we're working on to explore microkernel design." I think its developers have given up on it ever replacing Linux, as it's very behind in hardware support, and the gap is only ever growing rather than shrinking. For example, it doesn't support multicore or 64-bit userland (in a time when projects are pulling 32-bit userland support!).
You don't know the fundamental difference between Hurd and Linux, do you?
Please don't post dismissive comments like this. If you know more, share what you know so the rest of us can learn. If you don't want to do that or don't have time, that's fine, but then please just don't post anything.
https://news.ycombinator.com/newsguidelines.html
https://news.ycombinator.com/newsguidelines.html
Hurd is like Mazda Wankel engine. :-)
> Debian GNU/Hurd is currently available for the i386 architecture with about 80% of the Debian archive, and more to come!
Does Hurd still not support amd64?!
Does Hurd still not support amd64?!
From https://www.gnu.org/software/hurd/faq/64-bit.html
> There are currently no plan for 64-bit userland, but there are plans for 64-bit kernelland with 32-bit userland, which will notably permit to efficiently make use of more than 2 GiB memory and provide 4 GiB userland addressing space. Work on this is currently in the master-x86_64 and port-amd64 branches for GNU Mach.
> That being said, you can always run a 32-bit version on a 64-bit machine, it just works, processes are just limited to a couple GiB available memory.
> There are currently no plan for 64-bit userland, but there are plans for 64-bit kernelland with 32-bit userland, which will notably permit to efficiently make use of more than 2 GiB memory and provide 4 GiB userland addressing space. Work on this is currently in the master-x86_64 and port-amd64 branches for GNU Mach.
> That being said, you can always run a 32-bit version on a 64-bit machine, it just works, processes are just limited to a couple GiB available memory.
Debian x32 has a pretty similar concept wrt more efficient memory usage: https://wiki.debian.org/X32Port
You can also store pointers for more than 4 GB in a 32 bit address by compressing them.
But you are still using 32 bit registers so your load and save instructions can't really make use of compressed addresses
[deleted]
I don't really understand how all this stuff works at the kernel level, but if you have a 64-bit kernel what would prevent you from also having 64-bit user programs?
There is quite a lot of surface area between a program and the kernel - C library, dynamic linker, system call interface, memory layout, droves of permission and sanity checking logic etc. that would need to be updated too. A 64 bit kernel is a first step
That's ironic, given that last I heard anything about Hurd, it was that partition size was constrained by bus width (i.e., it couldn't access disks larger than 2 GiB on most computers at the time), but since everyone was moving to 64-bit architectures soon enough, that wouldn't be an issue. (Not sure where I heard that particular excuse, but the explanation why is here: [1])
32-bit userland makes Hurd basically unusable for many server applications, where multi-gigabyte in-memory lookup tables are critical for performance.
[1] https://developers.slashdot.org/comments.pl?sid=44492&cid=46...
32-bit userland makes Hurd basically unusable for many server applications, where multi-gigabyte in-memory lookup tables are critical for performance.
[1] https://developers.slashdot.org/comments.pl?sid=44492&cid=46...
Does the Hurd team go around lecturing people who call it "Hurd" about how it's actually "GNU"/Hurd, how Hurd is the kernel and that's only one part, or is that only when the kernel wasn't their idea?
Hurd is a GNU project so it doesn't even really need a second mention, it only needs that mention because there is a competing kernel (Linux) that is used with the system. Otherwise it's just known as the GNU system. The kernel is pretty irrelevant for most users, we don't call it Android/Linux or Windows/NT for a reason. A kernel is not an operating system. Calling the whole OS Linux is both inaccurate and does not introduce anyone to the whole reason why the GNU project was started, which is having the freedom to really own and control your computer. Linus Torvalds doesn't give a shit about that and is happy with chromebooks as long as they use his kernel. Freedom is irrelevant to him and most of the "open-source" community. That should be reason enough to not call the entire system Linux.
You're argument holds water, but the problem is when we start getting into OS's that actually don't ship any of the GNU userland. The classic example is Alpine Linux. Do we call that BusyBox/Linux? WSL 1 was a super weird anti-example where Microsoft skipped out on the Linux and shipped GNU stuff and still called it Linux. I think the colloquial naming convention became something like Kleenex or Google where we default to blowing our nose with (generic usage, not brand usage) "kleenex" with off-brand tissues or had our parents (generic usage, not brand usage) "google" something on Bing (as thats the default search engine of Windows).
Depends on what you mean by Linux. The ABI Microsoft were attempting to emulate was absolutely Linux. (This API business is exactly the issue with Oracle vs Google over Java).
I assume Linus is a pragmatist who doesn't want to torpedo his own product by putting a slash and abbreviation in its name and forcing the whole world to only call it that. I think accusing him of not caring about freedom because he balances pragmatism and ideology differently is throwing out the proverbial baby with the bath water.
I don't think it's nice to spit in the face of a person that hands you half of the cake you wanted. The GNU project has the freedom to get their own HURD kernel into a sufficiently working state and compete, which does not seem to be that trivial a task for all the years I've been following this drama.
I don't think it's nice to spit in the face of a person that hands you half of the cake you wanted. The GNU project has the freedom to get their own HURD kernel into a sufficiently working state and compete, which does not seem to be that trivial a task for all the years I've been following this drama.
I don't disagree on any particular point, but I'd love to be able to post about network stacks and system calls on the Internet without someone butting in with, "Actually... I think you mean GNU/Linux. Linux is just a kernel..."
> The kernel is pretty irrelevant for most users
For most users, so is the command line. So when a user is on a Gnome desktop, we can call it Gnome/Linux right? Since a normal user doesn't touch the terminal?
For most users, so is the command line. So when a user is on a Gnome desktop, we can call it Gnome/Linux right? Since a normal user doesn't touch the terminal?
Hell, for most users what matters is the browser, let's just go with Firefox/Linux.
Hurd is the official kernel of GNU project, so essentially it's just GNU. You could call it Debian GNU but I guess since that's confusing they decided to call it Debian GNU/Hurd.
We've come full circle.
Debian GNU/GNU?
also Hurd/Hird
I don't believe I've ever seen someone refer to a full system as "Hurd". It probably doesn't come up much.
I've been considering switching my servers to Alpine just to annoy the GNU people when they try to pull this.
Oh wow, I didn't realize hurd was still alive, and even 80% of the packages are working! Impressive
How well does it work? Can you run Gnome, for instance?
What does Hurd uniquely solve?
Well apart from actually building and researching how to build an OS. This stems from a very very deep seated itch.
The answer is "because we can".
It's volunteer engineering; because they can! Also it is not possible to know how the fruits of innovation might materialise. There might be achievments coming from this in a serendipitous way. The Hurd is a process.
It's volunteer engineering; because they can! Also it is not possible to know how the fruits of innovation might materialise. There might be achievments coming from this in a serendipitous way. The Hurd is a process.
"Remember when men were men and wrote their own device drivers." --Linus Torvalds
"Come and join the fun!" --Alan Cox
Linux wasn't going to big and professional, like Hurd, but better fun. Perhaps those roles have switched?
"Come and join the fun!" --Alan Cox
Linux wasn't going to big and professional, like Hurd, but better fun. Perhaps those roles have switched?
Which microkernel based OSes are ccurrently deployed? Which of these are open source?
QNX is widespread in embedded systems, it's sadly closed source (it's a magnificent OS).
L4 is a family of operating systems, sharing an API, not code. The ancestor was built to prove that microkernels could be fast. SeL4 is a formally proved variant. They are open source. They are also used in embedded systems, like baseband processors.
Minix 3 is an academic project by Andrew Tanenbaum. A few eyebrows were raised when it turned out that it is present in all new Intel chipsets.
L4 is a family of operating systems, sharing an API, not code. The ancestor was built to prove that microkernels could be fast. SeL4 is a formally proved variant. They are open source. They are also used in embedded systems, like baseband processors.
Minix 3 is an academic project by Andrew Tanenbaum. A few eyebrows were raised when it turned out that it is present in all new Intel chipsets.
Symbian (you can still buy handsets), QNX, L4, INTEGRITY OS, GenodeOS, muen, Fuchsia.
Then you have the hybrid ones from Apple, Android with Treble (classical Linux drivers are referring to as legacy driver on the documentation) and Windows is kind of hybrid as well.
As of Catalina, Apple was very clear that the long term roadmap for their OSes is to move all drivers and kernel extensions into userspace, which will be a gradual process.
Then you have the hybrid ones from Apple, Android with Treble (classical Linux drivers are referring to as legacy driver on the documentation) and Windows is kind of hybrid as well.
As of Catalina, Apple was very clear that the long term roadmap for their OSes is to move all drivers and kernel extensions into userspace, which will be a gradual process.
That is fascinating. So is everyone moving to be more microkernel-y? It's anyone actually transitioning to a more monolithic system?
It's a natural evolution of any system - monoliths are ok only as long as you don't need much of reliability, security, productivity, cooperation, etc.
> monoliths are ok only as long as you don't need much of reliability, security, productivity, cooperation, etc
As a supporter of microkernels I feel this is more a list of side effects. I'd put it this way: monoliths are ok so long as any critical code stays very small and comprehensible in it's entirety by an individual. It's also respectful of things that are not microkernels.
Good microkernels designs operate on the same principle, to achieve reliability and security they keep their critical code very small. It's not invulnerable to bugs, but it is well understood that minimising this surface area is the first step in minimising bugs, the secondary effect is also focusing attention due to minimising total lines of critical code. Microkernels are an attempt to take this to an absolute minimum by adding a layer of abstraction that makes otherwise critical code non-critical.
As a mere enthusiast I feel like this is the most useful lesson to take away from microkernels in other software, not triple redundancy or fancy reincarnation servers, but the fact that scale breeds complexity breeds bugs. Making sure the critical parts remain lean and inspectable helps a great deal in all software even when the separation is not as strict.
As a supporter of microkernels I feel this is more a list of side effects. I'd put it this way: monoliths are ok so long as any critical code stays very small and comprehensible in it's entirety by an individual. It's also respectful of things that are not microkernels.
Good microkernels designs operate on the same principle, to achieve reliability and security they keep their critical code very small. It's not invulnerable to bugs, but it is well understood that minimising this surface area is the first step in minimising bugs, the secondary effect is also focusing attention due to minimising total lines of critical code. Microkernels are an attempt to take this to an absolute minimum by adding a layer of abstraction that makes otherwise critical code non-critical.
As a mere enthusiast I feel like this is the most useful lesson to take away from microkernels in other software, not triple redundancy or fancy reincarnation servers, but the fact that scale breeds complexity breeds bugs. Making sure the critical parts remain lean and inspectable helps a great deal in all software even when the separation is not as strict.
Yes, because when you connect the whole world into a kernel, written in C, every little barrier helps.
HelenOS is an interesting open-source micro-kernel based operating system project primarily fueled by Charles University in Prague. It has a working GUI and USB support. It appears to be driven by various dissertations that add functionality see http://www.helenos.org/
The Intel processors all ship with Minix in their Management Engine.
The Apple iOS devices all have L4 in their security enclaves.
Both of these OSes have open source options, though the ones shipped in the processors are closed.
The Apple iOS devices all have L4 in their security enclaves.
Both of these OSes have open source options, though the ones shipped in the processors are closed.
Fuschia, for example; there are also various L4-based systems, some of which are open source.
It was probably more unique when it started 30+ years ago.
The idea was a mach microkernel + daemons/message passing to do higher-level things.
Note the microkernel was also used in nextstep and now macos.
The idea was a mach microkernel + daemons/message passing to do higher-level things.
Note the microkernel was also used in nextstep and now macos.
Maybe if Hurd decide to rewrite their kernel in rust I would give a s@#!, but since it's still a none usable kernel after decades of debugging and development, maybe it's ripe for /dev/null ?
Can someone with more knowledge answer, is it possible to have one core in kernel mode and another core in user mode? If yes, is it quicker to message between cores or to context switch?
Still stuck using Mach (1st gen microkernel).
Design failures highlighted in the Hurd critique paper still not addressed.
I'd look elsewhere, such as Genode with seL4, or Minix3.
Design failures highlighted in the Hurd critique paper still not addressed.
I'd look elsewhere, such as Genode with seL4, or Minix3.
I own a 32-bit machine specifically for trying out GNU/Hurd, just for fun. Glad to have an excuse for dusting it off once again.
I've been reading about hurd for so long, today is the day I try it in Virtualbox! Cool stuff, good work people!
..and the Symbian guys will be thinking where did they go wrong? :)
stdcall83(1)