6 ms·

MINIX 3, 2-3 people? You're kidding, it's far more than that. Especially given how many students AST supervises at the Vrije Universiteit. EDIT: Also, version

MINIX 3, 2-3 people? You're kidding, it's far more than that. Especially given how many students AST supervises at the Vrije Universiteit. EDIT: Also, version names in of themselves don't mean much. Hurd is at 0.7 yet capable of running multiple folds more Unix software than MINIX at 3.3.x.

nickpsecurity 11y ago
I was going by Tannenbaum's claim about the original work. "we've only been at it for a bit over a year with three people" By now, probably a lot more. I'm only talking about original architecture and implementation that possessed the reliability features.
- carussell 11y ago
  Another notable difference between Hurd and MINIX is that Tanenbaum got millions of funding from the EU to improve MINIX. Having the organizational backing of a research university helps, too.
  - nickpsecurity 11y ago
    Hey, millions of dollars can always help. It will be in my HOWTO for successful FOSS if I ever write one. :) I think the simple architecture is their main benefit, though. They only put in complexity where the most benefit. Then they reused NetBSD's work. A common cheat.
    - carussell 11y ago
      The units of measure there are Euro, even, so after the conversion to USD, we're talking about even larger numbers. Not an order of magnitude in difference, though.
  - gaius 11y ago
    How is that a difference? Stallman has goten millions from the MacArthur Foundation, Takeda Foundation, etc etc. Neither project is short of funding.
    - nickpsecurity 11y ago
      It's not except in terms of features they can produce and bugs they can eliminate. The research I did in response to vezzy-fnord's comment shows that Hurd ignored a proven codebase (4.4BSD) in favor of trying to build on Mach, a problematic microkernel. The Hurd author admitted the first part. They continue down the path that didn't work while Minix 3 adopted a better microkernel architecture built on their proven codebase. So, their stuff is predictably in better shape.
      - gaius 11y ago
        Right, but "they are more successful because they made better decisions" is tautological.
        nickpsecurity 11y ago
        A kind of troll-like remark that offers no counter-points or further information. I'll reply to it anyway. Here's the specifics I gave that they could've applied at the start or later on: https://news.ycombinator.com/item?id=10486120 https://news.ycombinator.com/item?id=10486120 Note the quote from the head of the project who confessed to the specific mistake. That's not tautological at all: it's what 5-10 seconds of Google would've earned you. It also matched the first idea that came to my head about where I would've started at the time. Linus and Tannenbaum both started with Minix codebase, one indirectly and one directly, to achieve success. So, Hurd was just Doing It Wrong. Further, that starting with a poor architecture or not building off a good codebase often leads to failure are proven heuristics.
        gaius 11y ago
        Yes I suppose you could consider better decisions leading to better outcomes to be "problematic". Much more convenient to ascribe it to more funding i.e. privilege. Now who's trolling?
- vezzy-fnord 11y ago
  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. ;)

nickpsecurity 11y ago

I was going by Tannenbaum's claim about the original work. "we've only been at it for a bit over a year with three people" By now, probably a lot more. I'm only talking about original architecture and implementation that possessed the reliability features.

carussell 11y ago
Another notable difference between Hurd and MINIX is that Tanenbaum got millions of funding from the EU to improve MINIX. Having the organizational backing of a research university helps, too.
- nickpsecurity 11y ago
  Hey, millions of dollars can always help. It will be in my HOWTO for successful FOSS if I ever write one. :) I think the simple architecture is their main benefit, though. They only put in complexity where the most benefit. Then they reused NetBSD's work. A common cheat.
  - carussell 11y ago
    The units of measure there are Euro, even, so after the conversion to USD, we're talking about even larger numbers. Not an order of magnitude in difference, though.
- gaius 11y ago
  How is that a difference? Stallman has goten millions from the MacArthur Foundation, Takeda Foundation, etc etc. Neither project is short of funding.
  - nickpsecurity 11y ago
    It's not except in terms of features they can produce and bugs they can eliminate. The research I did in response to vezzy-fnord's comment shows that Hurd ignored a proven codebase (4.4BSD) in favor of trying to build on Mach, a problematic microkernel. The Hurd author admitted the first part. They continue down the path that didn't work while Minix 3 adopted a better microkernel architecture built on their proven codebase. So, their stuff is predictably in better shape.
    - gaius 11y ago
      Right, but "they are more successful because they made better decisions" is tautological.
      - nickpsecurity 11y ago
        A kind of troll-like remark that offers no counter-points or further information. I'll reply to it anyway. Here's the specifics I gave that they could've applied at the start or later on: https://news.ycombinator.com/item?id=10486120 https://news.ycombinator.com/item?id=10486120 Note the quote from the head of the project who confessed to the specific mistake. That's not tautological at all: it's what 5-10 seconds of Google would've earned you. It also matched the first idea that came to my head about where I would've started at the time. Linus and Tannenbaum both started with Minix codebase, one indirectly and one directly, to achieve success. So, Hurd was just Doing It Wrong. Further, that starting with a poor architecture or not building off a good codebase often leads to failure are proven heuristics.
        gaius 11y ago
        Yes I suppose you could consider better decisions leading to better outcomes to be "problematic". Much more convenient to ascribe it to more funding i.e. privilege. Now who's trolling?
vezzy-fnord 11y ago
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. ;)