Debian GNU/Hurd 2019 Released
lists.debian.org
lists.debian.org
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...)
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.
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.
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.
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.
Is it curiosity or is there some use case for Hurd that I'm not aware of?
Thanks.
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.
Kind of like how I waited for HAMMER2.
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.
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.
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!).
Does Hurd still not support amd64?!
> 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.
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...
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.
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?
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.
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.
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.
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.
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.
"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?
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.
Design failures highlighted in the Hurd critique paper still not addressed.
I'd look elsewhere, such as Genode with seL4, or Minix3.