9 ms·

Two things: a) The MINIX 3 developers had an enormous head start from reusing MINIX 2 in its entirety. In fact, that's how the project began: it was a refactor

Two things: a) The MINIX 3 developers had an enormous head start from reusing MINIX 2 in its entirety. In fact, that's how the project began: it was a refactoring of MINIX 2. The same cannot be said for the Hurd, which for the first few years was literally one guy (Thomas Bushnell) writing everything from scratch based on the stock CMU Mach 3.0 he was only getting acquainted with (he was much more familiar with 4.4BSD instead), and that the GNU project spent about 3 years procuring due to its proprietary licensing. Further, the MINIX 3 people later imported NetBSD, again heading on from that. b) I ran GitStats on MINIX 3 and got a lifetime contributor count of 70, with around 13 major developers. Contrast to Hurd's lifetime of 51 with never more than 4-5 major devs, first few years being only 1. EDIT: The EU grant no doubt helped, too.

nickpsecurity 11y ago
So, they started with a proven codebase, refactored it with some developers + funding, got more developers/funding, and imported other proven code. The result was a working system in a short period of time. So, I might change how I present the project. Nonetheless, sounds like what any well-managed project does and what Hurd could've done. Matter of fact, I was going to suggest they could've reworked BSD 4.4 when I get a holy shit moment doing a quick fact-check on Wikipedia: "According to Thomas Bushnell, the initial Hurd architect, their early plan was to adapt the 4.4BSD-Lite kernel and, in hindsight, "It is now perfectly obvious to me that this would have succeeded splendidly and the world would be a very different place today"." That was an epic hit. :) Far as microkernels, the few in existence were tied up in I.P.. So, I wouldn't rag them if they had to do that part custom. Mach was available with painful work. I believe Chorus was, but commercial. Only alternative I would consider was cloning Hydra's capability-secure microkernel. It ran on PDP-11's that UNIX was built on. CMU might have even given up the code since the project was dead. So, possibilities there. Past that, doing a microkernel at that time would be foolish and 4.4BSD integrated with GNU components was obvious choice. After certain amount of time passed, there were a number of usable microkernels that could be split off and turned into working systems. There had also been numerous published projects... TrustedMach, Distributed TrustedMach, DTOS... by DOD to improve Mach's failures with UNIX compatibility without much success. Several commercial microkernels, including QNX, achieved success in in the market while publishing concrete details on how. Given all this, I think there's little justification for Hurd to keep trying failed strategy on the very microkernel that gave the rest a bad name. They're better off trying to rewrite parts from scratch on a L4-based kernel or QNX clone. Or joining MINIX 3. ;)
- gnufx 11y ago
  I recall that the AT&T/BSD lawsuit was relevant then, especially for Linux as an alternative at the right time. A microkernel design seemed sane from experience in the UK. I don't know if it was technically a microkernel, but the GEC OS4000 Nucleus <https://en.wikipedia.org/wiki/OS4000> https://en.wikipedia.org/wiki/OS4000> supported a system that made VMS VAXen look slow in the 80s. (Latterly, OS6000, with a software Nucleus, still compared well with System V on the same hardware.) L4 was already tried for Hurd, surely.
  - nickpsecurity 11y ago
    That's a good point. Lawsuit might have factored into the decision although they don't reference it. In any case, I think Nucleus is a good recommendation as I also regularly cite it as a great idea worth emulating. That GEC work integrated just the right functions into the kernel, built entire OS around that for consistency, and had non-software-writable firmware for security. Way ahead of it's time. Well, one company did build on that work that I can tell. They built on it so well they dropped bombs on the formal verification community. You might be surprised which company that was. Safe to the last instruction: Automated verification of a type-safe operating system (2010) http://research.microsoft.com/pubs/122884/pldi117-yang.pdf http://research.microsoft.com/pubs/122884/pldi117-yang.pdf
    - gnufx 11y ago
      [I assume, but don't know, that GEC 4000 was influenced by Brinch Hansen's RC 4000, but all I remember about the then-ancient RC 4000 at the Niels Bohr Institute was that it seemed pretty primitive and the systems language was Algol, c.f. OS4000's structured assembler, and was pretty grotty.] I don't know to what extent security was the reason for the hardware nucleus rather than a by-product of the fast system. (I recall French colleagues thought the context switching was slow, thiking it must be in milliseconds, not microseconds.) However, the software versions for the later OS6000 and whatever the 88k implementation was called, seemed OK. I don't understand the reference to the paper. I don't think there was any formal verification in OS4000 (or the hardware, given the 4190 arithmetic bug), or GC in Nucleus, and the typed assembler doesn't look to have much in common with Babbage. Which company? Good to see an OS4000 user who appreciates its significance after all this time, anyhow.

nickpsecurity 11y ago

So, they started with a proven codebase, refactored it with some developers + funding, got more developers/funding, and imported other proven code. The result was a working system in a short period of time. So, I might change how I present the project. Nonetheless, sounds like what any well-managed project does and what Hurd could've done. Matter of fact, I was going to suggest they could've reworked BSD 4.4 when I get a holy shit moment doing a quick fact-check on Wikipedia: "According to Thomas Bushnell, the initial Hurd architect, their early plan was to adapt the 4.4BSD-Lite kernel and, in hindsight, "It is now perfectly obvious to me that this would have succeeded splendidly and the world would be a very different place today"." That was an epic hit. :) Far as microkernels, the few in existence were tied up in I.P.. So, I wouldn't rag them if they had to do that part custom. Mach was available with painful work. I believe Chorus was, but commercial. Only alternative I would consider was cloning Hydra's capability-secure microkernel. It ran on PDP-11's that UNIX was built on. CMU might have even given up the code since the project was dead. So, possibilities there. Past that, doing a microkernel at that time would be foolish and 4.4BSD integrated with GNU components was obvious choice. After certain amount of time passed, there were a number of usable microkernels that could be split off and turned into working systems. There had also been numerous published projects... TrustedMach, Distributed TrustedMach, DTOS... by DOD to improve Mach's failures with UNIX compatibility without much success. Several commercial microkernels, including QNX, achieved success in in the market while publishing concrete details on how. Given all this, I think there's little justification for Hurd to keep trying failed strategy on the very microkernel that gave the rest a bad name. They're better off trying to rewrite parts from scratch on a L4-based kernel or QNX clone. Or joining MINIX 3. ;)

gnufx 11y ago
I recall that the AT&T/BSD lawsuit was relevant then, especially for Linux as an alternative at the right time. A microkernel design seemed sane from experience in the UK. I don't know if it was technically a microkernel, but the GEC OS4000 Nucleus <https://en.wikipedia.org/wiki/OS4000> https://en.wikipedia.org/wiki/OS4000> supported a system that made VMS VAXen look slow in the 80s. (Latterly, OS6000, with a software Nucleus, still compared well with System V on the same hardware.) L4 was already tried for Hurd, surely.
- nickpsecurity 11y ago
  That's a good point. Lawsuit might have factored into the decision although they don't reference it. In any case, I think Nucleus is a good recommendation as I also regularly cite it as a great idea worth emulating. That GEC work integrated just the right functions into the kernel, built entire OS around that for consistency, and had non-software-writable firmware for security. Way ahead of it's time. Well, one company did build on that work that I can tell. They built on it so well they dropped bombs on the formal verification community. You might be surprised which company that was. Safe to the last instruction: Automated verification of a type-safe operating system (2010) http://research.microsoft.com/pubs/122884/pldi117-yang.pdf http://research.microsoft.com/pubs/122884/pldi117-yang.pdf
  - gnufx 11y ago
    [I assume, but don't know, that GEC 4000 was influenced by Brinch Hansen's RC 4000, but all I remember about the then-ancient RC 4000 at the Niels Bohr Institute was that it seemed pretty primitive and the systems language was Algol, c.f. OS4000's structured assembler, and was pretty grotty.] I don't know to what extent security was the reason for the hardware nucleus rather than a by-product of the fast system. (I recall French colleagues thought the context switching was slow, thiking it must be in milliseconds, not microseconds.) However, the software versions for the later OS6000 and whatever the 88k implementation was called, seemed OK. I don't understand the reference to the paper. I don't think there was any formal verification in OS4000 (or the hardware, given the 4190 arithmetic bug), or GC in Nucleus, and the typed assembler doesn't look to have much in common with Babbage. Which company? Good to see an OS4000 user who appreciates its significance after all this time, anyhow.