> it doesn't paint Stallman very well as the head of a project
Is this news to you?
Cf. e.g. http://www.jwz.org/doc/lemacs.html
Is this news to you?
Cf. e.g. http://www.jwz.org/doc/lemacs.html
Let's see if someone did the following things to the python project:
1#: Hire away the package maintainer. Then rather than continue and finish any current work, effectively remove that person from the community project.
2#: Redesign underlying structure of the project (like say, PyPy), but don't discuss any changes with the community. No PEPs, no discussion on mailing lists, no communication what so ever.
3#: Ignore current list of new feature being worked at. Community goals are unimportant.
4#: Add code regression! Do not care about maintaining performance.
5#: Demand that the changes get implemented immediately in next official release.
Would anyone expect that to actually work today? Sure, Stallman could be more diplomatic and find (and succeed) with a middle ground solution, but the above steps are not how you join an ongoing software project.
I also read the argument about the redesign of the event system and was pretty flabbergasted. The argument seems to reduce to "lucid emacs decided to design a proper event datatype because having an event be entirely represented by a simple integer keycode both lost information and made it impossible to represent certain keystrokes" versus "but ints are simple and backward compatible!"
The guys at Lucid also barely communicated for long periods of time, making collaboration impossible.
That's an argument one can use when asked to spend more time with kids.
> it provides a reasonable excuse for the delays, since nobody was able to take his succession immediately
Huh?!? Open Source model not working or what?
> Huh?!? Open Source model not working or what?
I guess its only illusion and crazy lawyers who like to add anti-poaching clauses in employee contracts. If a company can't handle loosing their top engineers, clearly its the the proprietary model that is not working.
Hah, 20 years in the making!
Second, it is debatable whether sticking to Hurd was a good or a bad idea technically. Imagine if Stallman and co. managed to convince a good number of developers that it was a good idea and the kernel was competitive with Linux, BSD's, etc. If you believe you have a technically superior vision for your product, should you compromise on it just because people who do not share in your vision will not join you?
In the end, I think what killed the pure GNU/Hurd OS was bad PR and absolutism. Hurd as a technical question was just a small part of that. Remember, the debate between the Free and the Open Source guys was pretty fierce. Today we use terms like FOSS to describe all open software, but when Linux and Hurd were young these were different camps with opposing philosophies, and the one that appealed to more developers won out. In simplistic terms, you can think of this as the VHS vs Betamax debate. Can you blame the Betamax backers for continuing to try to push it and "killing" it as a result?
Also my statement was going by the words of the Hurd's former project leader Thomas Bushnell:
"RMS was a very strong believer -- wrongly, I think -- in a very greedy-algorithm approach to code reuse issues. My first choice was to take the BSD 4.4-Lite release and make a kernel. I knew the code, I knew how to do it. It is now perfectly obvious to me that this would have succeeded splendidly and the world would be a very different place today.
RMS wanted to work together with people from Berkeley on such an effort. Some of them were interested, but some seem to have been deliberately dragging their feet: and the reason now seems to be that they had the goal of spinning off BSDI. A GNU based on 4.4-Lite would undercut BSDI.
So RMS said to himself, "Mach is a working kernel, 4.4-Lite is only partial, we will go with Mach." It was a decision which I strongly opposed. But ultimately it was not my decision to make, and I made the best go I could at working with Mach and doing something new from that standpoint.
This was all way before Linux; we're talking 1991 or so." [1]
http://www.groklaw.net/article.php?story=20050727225542530 [1]
You mean linux? That isn't a huge number.
>and are installed on a staggering number of devices
The staggering number of devices you refer to almost exclusively run busybox or one of the similar projects. GNU software is hugely bloated and not a good choice for embedded systems.
>Second, it is debatable whether sticking to Hurd was a good or a bad idea technically
No, it was fine technically. It had no developers and so nothing happened. Minix exists, obviously microkernels are possible.
Fair enough, I read "in" as a synonym for "on" but read in a less casual way the difference could be important.
Even in the "in" case I think many BSD's used GCC as the default compiler (CLANG seems to be taking over now).
I'm not sure where I read this originally but I just googled this source which seems to back it up:
I don't know much about how these people work, but I always figured Mach at Apple is just about momentum and familiarity of contributors, rather than technology. NeXT hired Tevanian who worked on Mach at CMU, they spent roughly a decade hacking on Mach, then Apple did the same. I'd imagine they employ people who know Mach well and haven't seen it as worthwhile to replace it.
I even remember they had this goofy project "MkLinux", which sought to put Linux in the position that BSD carries with XNU, on top of Mach... Just goofy stuff, unless you figure they had Mach hackers on staff.
https://developer.apple.com/library/mac/documentation/Darwin...
This seems a bit delusional. I don't think it's controversial to say that Apple's biggest differentiators exist at higher levels than kernel space. I'd go so far as to say that anyone who claims that Apple's success is rooted in XNU and that the same could not have been done with Linux or *BSD at the lowest layer and all other pieces being equal does not understand what a kernel is.
But this is not a suggestion for them to scrap it, necessarily. As I said in some other comments on this thread, I think the real reason is that they had people that knew their existing kernel well, and don't see a need to replace it.
See my comment up thread about Jordan Hubbard's plans.
xnu is also a monolithic kernel, just with some nice message-passing primitives. Think Mach 2.5.
Edit: ok, I just figured out my source of confusion. IOKit allows userspace drivers, which can crash without resulting in panic.
He fully acknowledged that he made a mistake in going with Mach and as soon as Linux took off FSF focused on providing the necessary software to combine with Linux into an operating system and placed Hurd on 'life support', where it's been ever since.