23 ms·

> 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 http://www.jwz.org/doc/lemacs.

> 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 http://www.jwz.org/doc/lemacs.html

hyperpape 13y ago
shrug More confirmation.
vezzy-fnord 13y ago
Not to mention his insistence on GNU Hurd being based on Mach, which pretty much ended up killing the project.
- IgorPartola 13y ago
  That's a simplistic view. First, the GNU project is very much alive: the GNU tools are used in a huge number of operating systems and are installed on a staggering number of devices. I would bet that the system you are writing this comment from is running thanks to the GNU software. 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?
  - vezzy-fnord 13y ago
    Wait. You misunderstood me. I didn't say the entire GNU Project is dead. Hell no. When I said "project", I was referring specifically to GNU Hurd. 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 http://www.groklaw.net/article.php?story=20050727225542530 [1]
    - dragonwriter 13y ago
      Note, in regard to Bushnell's quote, that "1991 or so" and "way before Linux" are contradictory. (Or, at least, require an strained definition of "way before"; Linux was first released in 1991.)
  - Sssnake 13y ago
    >the GNU tools are used in a huge number of operating systems 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.
    - makomk 13y ago
      Last I heard a lot of users of Solaris and other Unixes often also use the GNU tools, though those are generally dying out in favour of Linux anyway.
      - Sssnake 13y ago
        Last you heard wrong then. Occasionally we begrudgingly install some GNU bloatware because some poorly written software requires it. That's about it. Every other OS already comes with its own versions of all the unix tools.
    - josephlord 13y ago
      GNU tools were often used on other OSes too including Solaris and other commercial Unixes but also Windows under Cygwin. Particularly GCC, make etc. but also command line tools such as grep where the default platform versions were often not as feature rich. I didn't use those platforms so others will remember and know better but I don't think huge was an obviously wrong description.
      - Sssnake 13y ago
        There is a big difference between "some people optionally could install GNU stuff in addition to their existing tools" and "those OSes use GNU tools".
        13y ago
- asveikau 13y ago
  Apple still insists on building their kernel atop Mach, and it doesn't seem to stop their momentum. (Even though it's kind of a strange choice.)
  - gillianseed 13y ago
    From what I understand, the Mach kernel which is now used in XNU is not the Mach micro kernel (3.0 >) but based upon the pre-micro-kernel 2.5 version of Mach. I'm not sure where I read this originally but I just googled this source which seems to back it up: http://www.roughlydrafted.com/0506.mk3.html http://www.roughlydrafted.com/0506.mk3.html
    - asveikau 13y ago
      I am not intimately familiar with the history of Mach, but what I do see is that in the late 80s and early 90s these two groups (NeXT and GNU) seeing Mach as the future (a position that makes no sense at a later time), and having vastly different outcomes. 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.
    - empthought 13y ago
      According to the Apple docs XNU is based on Mach 3.0. https://developer.apple.com/library/mac/documentation/Darwin/Conceptual/KernelProgramming/Mach/Mach.html https://developer.apple.com/library/mac/documentation/Darwin...
      - valleyer 13y ago
        That's misleading. Apple merged in a bunch of Mach 3 code but still maintains the architecture of Mach 2.5 (i.e., Mach + BSD both running in supervisor mode in one big monolith; no BSD server; xnu is not a microkernel…).
- gillianseed 13y ago
  Back when the choice was made, micro-kernels was all the rage in both academia and commercial ventures, and Stallman chose Mach since he thought it would speed up development, he was hardly alone in choosing Mach at this time, Apple (MkLinux, NeXTSTEP), IBM (Workplace OS) amongst others. 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.
  - maxlybbert 13y ago
    IIRC, ARPA at some point was more interested in funding projects based on Mach than based on any other kernel.
belorn 13y ago
I'm not sure that conversation is a good example of what you are trying to describe. 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.
- hamburglar 13y ago
  I tried to read that conversation in a neutral light, because I think RMS and JWZ are both kind of ... polarizing personalities, but RMS really came off as a stubborn, ineffective whiner in that whole thread. In particular "you hired away my maintainer" is a pathetic excuse for not releasing something for so long. Anybody could have hired away your maintainer, and you'd have to soldier on; it has no relevance that your maintainer went to a "competing" (in your territorial view) 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!"
  - lmm 13y ago
    Funny, I had the opposite view. I guess your opinion of the personalities really does change everything.
    - hamburglar 13y ago
      There is one (and only one) other possibility, which is that you and I both read the conversation with flawless objectivity, and that you are wrong. :D
revelation 13y ago
> I couldn't change the plans, so I had to make the best of them. I suggested a design to him, one oriented toward editing formatted text--a feature I wanted Emacs to have, eventually. Hah, 20 years in the making!
mempko 13y ago
the exchange made lucid seem like a bunch of assholes
- eropple 13y ago
  Care to explain? I thought that the Lucid guys made reasonable technical arguments (especially in light of, y'know, history, over the last twenty years) and that RMS was attempting to both grandstand and emotionally manipulate people into adopting his preferred position.

> 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 http://www.jwz.org/doc/lemacs.html

hyperpape 13y ago

shrug More confirmation.

vezzy-fnord 13y ago

Not to mention his insistence on GNU Hurd being based on Mach, which pretty much ended up killing the project.

IgorPartola 13y ago
That's a simplistic view. First, the GNU project is very much alive: the GNU tools are used in a huge number of operating systems and are installed on a staggering number of devices. I would bet that the system you are writing this comment from is running thanks to the GNU software. 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?
- vezzy-fnord 13y ago
  Wait. You misunderstood me. I didn't say the entire GNU Project is dead. Hell no. When I said "project", I was referring specifically to GNU Hurd. 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 http://www.groklaw.net/article.php?story=20050727225542530 [1]
  - dragonwriter 13y ago
    Note, in regard to Bushnell's quote, that "1991 or so" and "way before Linux" are contradictory. (Or, at least, require an strained definition of "way before"; Linux was first released in 1991.)
- Sssnake 13y ago
  >the GNU tools are used in a huge number of operating systems 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.
  - makomk 13y ago
    Last I heard a lot of users of Solaris and other Unixes often also use the GNU tools, though those are generally dying out in favour of Linux anyway.
    - Sssnake 13y ago
      Last you heard wrong then. Occasionally we begrudgingly install some GNU bloatware because some poorly written software requires it. That's about it. Every other OS already comes with its own versions of all the unix tools.
  - josephlord 13y ago
    GNU tools were often used on other OSes too including Solaris and other commercial Unixes but also Windows under Cygwin. Particularly GCC, make etc. but also command line tools such as grep where the default platform versions were often not as feature rich. I didn't use those platforms so others will remember and know better but I don't think huge was an obviously wrong description.
    - Sssnake 13y ago
      There is a big difference between "some people optionally could install GNU stuff in addition to their existing tools" and "those OSes use GNU tools".
      - 13y ago
asveikau 13y ago
Apple still insists on building their kernel atop Mach, and it doesn't seem to stop their momentum. (Even though it's kind of a strange choice.)
- gillianseed 13y ago
  From what I understand, the Mach kernel which is now used in XNU is not the Mach micro kernel (3.0 >) but based upon the pre-micro-kernel 2.5 version of Mach. I'm not sure where I read this originally but I just googled this source which seems to back it up: http://www.roughlydrafted.com/0506.mk3.html http://www.roughlydrafted.com/0506.mk3.html
  - asveikau 13y ago
    I am not intimately familiar with the history of Mach, but what I do see is that in the late 80s and early 90s these two groups (NeXT and GNU) seeing Mach as the future (a position that makes no sense at a later time), and having vastly different outcomes. 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.
  - empthought 13y ago
    According to the Apple docs XNU is based on Mach 3.0. https://developer.apple.com/library/mac/documentation/Darwin/Conceptual/KernelProgramming/Mach/Mach.html https://developer.apple.com/library/mac/documentation/Darwin...
    - valleyer 13y ago
      That's misleading. Apple merged in a bunch of Mach 3 code but still maintains the architecture of Mach 2.5 (i.e., Mach + BSD both running in supervisor mode in one big monolith; no BSD server; xnu is not a microkernel…).
gillianseed 13y ago
Back when the choice was made, micro-kernels was all the rage in both academia and commercial ventures, and Stallman chose Mach since he thought it would speed up development, he was hardly alone in choosing Mach at this time, Apple (MkLinux, NeXTSTEP), IBM (Workplace OS) amongst others. 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.
- maxlybbert 13y ago
  IIRC, ARPA at some point was more interested in funding projects based on Mach than based on any other kernel.

belorn 13y ago

I'm not sure that conversation is a good example of what you are trying to describe. 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.

hamburglar 13y ago
I tried to read that conversation in a neutral light, because I think RMS and JWZ are both kind of ... polarizing personalities, but RMS really came off as a stubborn, ineffective whiner in that whole thread. In particular "you hired away my maintainer" is a pathetic excuse for not releasing something for so long. Anybody could have hired away your maintainer, and you'd have to soldier on; it has no relevance that your maintainer went to a "competing" (in your territorial view) 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!"
- lmm 13y ago
  Funny, I had the opposite view. I guess your opinion of the personalities really does change everything.
  - hamburglar 13y ago
    There is one (and only one) other possibility, which is that you and I both read the conversation with flawless objectivity, and that you are wrong. :D

revelation 13y ago

> I couldn't change the plans, so I had to make the best of them. I suggested a design to him, one oriented toward editing formatted text--a feature I wanted Emacs to have, eventually. Hah, 20 years in the making!

mempko 13y ago

the exchange made lucid seem like a bunch of assholes

eropple 13y ago
Care to explain? I thought that the Lucid guys made reasonable technical arguments (especially in light of, y'know, history, over the last twenty years) and that RMS was attempting to both grandstand and emotionally manipulate people into adopting his preferred position.