GNU Hurd 0.9, GNU Mach 1.8, GNU MIG 1.8 Released(gnu.org)
gnu.org
GNU Hurd 0.9, GNU Mach 1.8, GNU MIG 1.8 Released
https://www.gnu.org/software/hurd/news/2016-12-18-releases.html
65 comments
Basically Linux and then BSD took all the wind out of Hurds sails. A lot of that was timing, and also because those projects were much more attractive to big business who put a tremendous amount of development resources behind them.
As far as I know QNX is the only usable OS based on a microkernel.
As far as I know QNX is the only usable OS based on a microkernel.
Errr... OSX and iOS are also MACH based. I'd call them 'usable' ? :-)
Funny bit is, back in the 90's when Apple bough NeXT, they trashed the NeXT version of MACH and used the one that was in... mklinux instead!
I bet very few people remember that bit. I remember because I had written the framebuffer console driver for mklinux back then, and seeing my init message when booting the earlier version of OSX (<=10.1 ish, perhaps a bit later too)
So I had the privilege of printing kernel crash logs and panics on zillions of devices! I'm so proud! :-)
Funny bit is, back in the 90's when Apple bough NeXT, they trashed the NeXT version of MACH and used the one that was in... mklinux instead!
I bet very few people remember that bit. I remember because I had written the framebuffer console driver for mklinux back then, and seeing my init message when booting the earlier version of OSX (<=10.1 ish, perhaps a bit later too)
So I had the privilege of printing kernel crash logs and panics on zillions of devices! I'm so proud! :-)
It's classed as a hybrid though, not a pure microkernel. There's significant amounts of BSD in there.
Also, thanks for the anecdote :)
Also, thanks for the anecdote :)
Quite a few embedded OSes are microkernels, L4 being one of them.
Interestingly L4 is being used to power the secure enclave on iOS devices so it's probably the most distributed microkernel.
There was a plan to move Hurd to use L3 instead of Mach, but apparently that project was cancelled.
> I'm also noting that Hurd is still only 32-bit.
I wonder if they'll make it to 64-bit before we start upgrading to 128-bit computers?
I wonder if they'll make it to 64-bit before we start upgrading to 128-bit computers?
Probably. It's unlikely we will be upgrading to 128 bit computers any time soon. 64 bit words are enough to store a double precision floating point number and enough bits to directly address 18.4 exabytes of RAM. The jump from 32 to 64 is a huge leap and any issues we were having with a 32 bit word are solved for a much longer period than the jump from 16 to 32 bit.
2^8 => 2^16 : 256x increase
2^16 => 2^32 : 65,536x increase
2^32 => 2^64 : 4,294,967,296x increase
2^8 => 2^16 : 256x increase
2^16 => 2^32 : 65,536x increase
2^32 => 2^64 : 4,294,967,296x increase
I know it doesn't seem likely, but these things have a way of creeping up on you. 25 years ago the prospect of everyone having 8 GB of ram was far fetched, computers still had 8MB and 8GB hard drives were years off. In 10 years we could have petabytes in our phones and from there exabytes aren't such a huge leap.
But to put it in perspective
8MB => 8GB : 1,000x increase
8GB => 8EB : 1,000,000,000x increase
The leap to 8 exabytes is 6 orders of magnitude greater than the last 25 years.
That would be 30 Moore's doublings (applied to storage) and would take 60 years. Oh, and we would still be able to address all of the ram with a 64 bit address.
In 10 years we will be closer to 256 GB in the phone, not petabytes or even terabytes (but terabytes would be close).
8MB => 8GB : 1,000x increase
8GB => 8EB : 1,000,000,000x increase
The leap to 8 exabytes is 6 orders of magnitude greater than the last 25 years.
That would be 30 Moore's doublings (applied to storage) and would take 60 years. Oh, and we would still be able to address all of the ram with a 64 bit address.
In 10 years we will be closer to 256 GB in the phone, not petabytes or even terabytes (but terabytes would be close).
They also still publish SHA1 sums, definitely stuck in the past.
It's kind of unbelievable that HURD is still going. It's been the butt of many a joke in the Unix world: our equivalent of Duke Nukem Forever, or Mordeth.
I can't admire their release schedule, but you're got to admire their persistance.
One day, it might just be ready...
I can't admire their release schedule, but you're got to admire their persistance.
One day, it might just be ready...
That's great. You make an excellent comparison between its promises vs success vs DNF's. disordinary inadvertently points out that, unlike Hurd, DNF eventually delivered and at least made some money selling 376,300 units. It's kind of a cutdown on DNF to compare it to Hurd which wasn't finished, had little adoption, and sold 0 units. Even MULTICS and SCOMP probably had more adoption in significant use cases despite them practically being case studies on things with low adoption due to expenses or tough tradeoffs.
Meanwhile, Minix 3 and Genode are going strong despite originally being made by only a handful of people for a tiny fraction of the time. Hurd is truly a dead end in marketing if the likes of DNF surpasses it in deliverables and adoption.
Meanwhile, Minix 3 and Genode are going strong despite originally being made by only a handful of people for a tiny fraction of the time. Hurd is truly a dead end in marketing if the likes of DNF surpasses it in deliverables and adoption.
...Which is why Mordeth is a more apt comparison: over 18 years of "development" by a volunteer (I think it's only one), and still no release.
Yeah that makes sense.
Hopefully it will run Project Xanadu
https://en.wikipedia.org/wiki/Project_Xanadu
(check the start date and first working version)
https://en.wikipedia.org/wiki/Project_Xanadu
(check the start date and first working version)
Huh...now I get the reference when playing Kentucky Route Zero
I didn't realize it was a reference to anything until just now.
Unlike DNF it's not a commercial product, it relies on volunteers and corporate benefactors. For multiple reasons Linux got the brunt of OSS development resources behind it which wouldn't have helped Hurds schedule.
As I mentioned in a cousin, this is why Mordeth is a more apt comparison.
Good thoughts about GNU Hurd https://www.reddit.com/r/hurd/comments/273tij/hurd_the_minix....
Do a RISC V port so hardware can be supported as it becomes available. No more need to play catch-up with drivers.
Most device drivers are more or less independent of CPU architecture. A PCI card is going to be the same PCI card no matter whether it's running on x86, Power, RISC-V or anything else.
Device drivers don't execute on the device. They execute on the CPU, instructing the OS how to use the device. So device drivers do need to support both the CPU architecture and the OS platform.
They may need compiled to a specific architecture, but the actual driver code itself is pretty device-independent. Unless you're doing something like implementing your own bus instead of using something like PCI, aside from weird corner cases, the code at that level doesn't care.
Not when they are open source...
True. Despite spending the majority of my working and personal life buried neck deep in open source, for someone reason I forgot we weren't talking about source code here and commented about the distribution of the resulting kernel modules.
@OP: Sorry for the correction. I blame my cold for the poor reasoning on my part hehe.
@OP: Sorry for the correction. I blame my cold for the poor reasoning on my part hehe.
lol. good joke there.
That's ... literally what the GP comment was about.
i don't understand.
i was trying to comment on the idea that something being open source doesn't change that it needs compiling for a particular platform, and that it should be expected to not be straightfowards. especially at the low level where you need to raise interrupts and fill particular registers...
i was trying to comment on the idea that something being open source doesn't change that it needs compiling for a particular platform, and that it should be expected to not be straightfowards. especially at the low level where you need to raise interrupts and fill particular registers...
Oh that's actually reasonably cross platform these days. You can write drivers that are ISA independent and make use of kernel APIs for interacting with the hardware. There's no reason to drop into assembly. (Although yes sometimes the memory coherency model or details of the interrupt handler protocol bleed into a driver requiring tweaks to get it to work, but those are bugs a good driver author can avoid.)
> those are bugs a good driver author can avoid
some hardware can be a nightmare for this stuff though...
i still contend that it can be much more complicated than simply recompiling for your target... and even when its not, that is still one more step than doing nothing, which was the impression i got from the "its open source you can do nothing" comment.
some hardware can be a nightmare for this stuff though...
i still contend that it can be much more complicated than simply recompiling for your target... and even when its not, that is still one more step than doing nothing, which was the impression i got from the "its open source you can do nothing" comment.
I never wrote a single driver, but I believe all bets are off with hardware. Drivers can execute logic on the cpu and on the chip, it's probably wild.
Fair point. However, there will never be AGP or IDE for it. In fact there is no hardware with PCI and RISC V and may never be. My point is that they could solve the "what hardware do we support" problem by porting to architecture that doesn't have any hardware yet ;-) it would be gamble on an arch...
Do modern motherboards even still ship with AGP and IDE? I thought those were on a death march almost a decade ago.
You can still get mainboards for modern CPUs (e.g. Intel Skylake) with PCI slots. Not sure how they work internally, e.g. if there is a PCIe bridge and if yes on what level PCI emulation happens.
PCI is a CPU-independent bus (unlike AT/ISA), it isn't really emulated, rather, there's a host bridge on these mainboards that connect it to PCIe from the CPU or southbridge.
No they don't make them any more. But my AMD64 machine from 2005 has AGP, IDE, and SATA. It's well supported by Fedora 25 which is a month old. Unless you're in new territory you have to decide what to support and will never gain traction due to the limited support.
Once RISC-V matures, I'd be very surprised if no-one makes a board with PCIe slots, a SATA controller, a USB controller and all the other things which are relatively similar to a PC.
In fact, one is already in progress (the U500): https://www.sifive.com/products/freedom/
How usable is it outside of hardware issues?
The changelog is so small... Can someone explain why do we need this? Why would we want to use it?
It is unlikely that this will ever take off.
As I understand it, the idea of this project is to build a microkernel and associated systems that might compete as an alternative to the Linux kernel.
This would allow things like, more elegant hot patching of the kernel, formal verification of core parts of the kernel, better hardware enforced isolation of different systems for security. I guess also some people like the idea of a GPL3 kernel against tivoisation.
I can see why someone might adopt a mature version of this for say, a safety or security critical system. Trouble is, until it is mature and battle tested, its not a good bet for those things. And without adoption, it's not gonna mature or get used.
As I understand it, the idea of this project is to build a microkernel and associated systems that might compete as an alternative to the Linux kernel.
This would allow things like, more elegant hot patching of the kernel, formal verification of core parts of the kernel, better hardware enforced isolation of different systems for security. I guess also some people like the idea of a GPL3 kernel against tivoisation.
I can see why someone might adopt a mature version of this for say, a safety or security critical system. Trouble is, until it is mature and battle tested, its not a good bet for those things. And without adoption, it's not gonna mature or get used.
It's technically interesting and competition is never bad.
A fringe operating system can drive innovation by taking risks that a mainstream OS would never. Ultimately any improvements will appear on main stream operating systems so even if it's never used we're going to see some benefits.
A fringe operating system can drive innovation by taking risks that a mainstream OS would never. Ultimately any improvements will appear on main stream operating systems so even if it's never used we're going to see some benefits.
The niceness of the Hurd design, conceptually, is that the microkernel orchestrates system integrity, while even an unprivileged user has a lot of freedom as to what to run on top of that. They can launch drivers, file systems, run sandboxed kernels, and so forth.
we don't want til 2060 https://xkcd.com/1508/
I know this is a bit off topic but is there anything to read about how to implement a microkernel? Like a real booting system for x86.
Andrew Tannenbaum's Minix [1] was pretty much made for this purpose. The current version is no longer a "teaching OS", but there is a lot of documentation on earlier versions around, including the original 1987 book [2] that Tannenbaum wrote on operating systems (which comes with the Minix source code).
[1] https://en.wikipedia.org/wiki/MINIX
[2] https://en.m.wikipedia.org/wiki/Operating_Systems:_Design_an...
[1] https://en.wikipedia.org/wiki/MINIX
[2] https://en.m.wikipedia.org/wiki/Operating_Systems:_Design_an...
Minix3 is designed to be usable as a real system, but the core of it is still only supposed to be 6kLOC.
I have the book but I haven't finished it yet. Will I come out having written a full kernel by the time I'm done?
No, it's not a tutorial, which I don't think would make sense. Rather, it's a walk through the design and implementation of Minix. Minix is tiny, so you can actually follow along. In theory, by the time you're done you'll not just know Minix, but you'd be able to write your own kernel if you wanted to.
This is the best source of OS development info/tutorials: http://wiki.osdev.org/Main_Page
Creating a GRUB multiboot image is the easiest way and you can just directly boot from the kernel file stored on your normal filesystem.
I hope they port Rust to it in order to take advantage of drivers ported in Rust which will become commonplace I foresee.
A lot of applications already work on the Hurd. There's GNU Guix for the Hurd as well. Support for applications is pretty great. It's hardware support that's lacking, but it's getting better with NetBSD's rump kernel.
I expect really in the GNU Hurd, keep calm and carry on.
[deleted]
Since then, on regular intervals[2] I've attempted to install the most recent version, but I have failed every single time[3].
I'm also noting that Hurd is still only 32-bit.
Is there actually a plan to make this into a system that can actually be used? Exactly what is it about the Hurd project that makes it take so long to finish? There have been several examples of single developers creating a usable[4] operating system in the span of a couple years.
[1] Yes, 20 years ago
[2] Perhaps once every one or two years
[3] Running a preconfigured VM image doesn't count
[4] More usable than Hurd is today