I went back and looked at the older discussion, and it doesn't paint Stallman very well as the head of a project. He pins the question of whether to keep using bzr not on whether it is good or whether the Emacs developers want it, but on whether it's being "maintained".
But then he seems to define maintenance as having fixed a specific bug that's been around for over a year, blocking a point release.
He admits that he can't follow the developers list to see if they're genuinely doing active maintenance (reasonable enough: he has a lot on his plate), but also won't accept the testimony of Emacs developers that the mailing list is dead and there's no evidence of real maintenance.
When questioned, he says that there's too much at stake to abandon bzr if it can be avoided at all. But the proposed replacement is GPL software. This is just madness.
I think this is more inertia than anything else. It is pretty obvious that Stallman isn't the easiest person to talk to, but he has consistently put huge amount of efforts into GNU for lots of years, and, whatever he did as the maintainer, seems to have worked out pretty much in the end. If there was anyone as active in the Emacs community today as Stallman was in his prime, they could easily push through changes despite Stallman's disagreement, via a fork or otherwise, but there isn't such a person, and that is that.
Consider that it has been almost 30 years since GNU Emacs started, for most of this time RMS has been the maintainer, and GNU Emacs continues to this day to be the most advanced, popular and active Emacs there is, while the various forks in existence like XEmacs, SXEmacs lost steam pretty quickly. So it certainly hasn't been all bad on his side.
The popularity of a specific fork of Emacs is a moot point, it's the popularity of Emacs as an editor (or should I say, as a platform?) that is at issue. Stallman was active, how that he's not active he needs to either defer to people who are active or watch as fewer and fewer people take advantage of his work.
Stallman doesn't have much influence on Emacs development itself anymore, but Emacs is a GNU project, Stallman is still the head of GNU, and a move to another VCS would be a major organizational change. I too wish he would be less hard-headed about this, but lets not overblow this issue out of proportion.
In replies, he says he doesn't oppose the move to git. Most devs who've replied support git. There's already a mirror. Let's not make mountains out of molehills...
As he said, 'more than Emacs is at stake here.'.[1]
I presume this refers to Bazaar's status as part of the GNU project, and that RMS did not want to write off part of GNU without being certain he needed to.
Regardless, he has since OKd the switch from bzr:
I don't insist that Emacs should stay with bzr. I chose to support bzr because it was still a contender at the time. [2]
I mean, don't not fixing what ain't broke is certainly a matter of integrity. Fixing something to the latest hippest new fad just to "attract young hackers" detracts from integrity. Making the editor an awesome badass attractive editor should be enough. Otherwise you'll only be attracting groupthink-prone douchebags, anyway.
For better or worse, having a vision is a very different skillset from having the management skillset to make things happen. Sometimes people deride management when talking about the importance of vision and leadership. There is also the current trend of companies giving up managers entirely.
RMS is a prime example of why management is an important skill. It is inefficient for him to do everything himself. It's also inefficient for him to chase people down for all the details. If he had a solid COO who understood his vision, his organization would be much more effective.
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.
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!"
Poaching the lead dev to work on your own fork is a hostile move, and in my book, it provides a reasonable excuse for the delays, since nobody was able to take his succession immediately.
The guys at Lucid also barely communicated for long periods of time, making collaboration impossible.
>> 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?
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.
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
> 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.
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.
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?
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]
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.)
>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.
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.
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.
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:
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.
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…).
It is odd, I predicted about 5 years back that Apple would gradually converge the API to FreeBSD and then switch. They would still be better off doing that I think, but they show no signs of doing this.
It's a huge effort worth that seems to be paying off quite handily. XNU seems like a competitive edge over the monolith FreeBSD, as far as desktop and mobile OS is concerned. FreeBSD has plenty of cool stuff, but in a completely different domain.
> XNU seems like a competitive edge over the monolith FreeBSD, as far as desktop and mobile OS is concerned.
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.
I don't know anyone saying Apple's success is rooted in any one thing. However, IOKit is very important, "common code for device drivers, this framework also provides power management, driver stacking, automatic configuration, and dynamic loading of drivers". Even if the entire OSX could have been implemented on top of Linux and FreeBSD reusing those kernels (and it does reuse FreeBSD for low level POSIX apis!), how productive would that have been? I honestly don't know, but I choose to trust what I read from the original developers.
Those other kernels have driver frameworks too. And if they find them inadequate for some reason, they are of course able to make modifications.
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.
You are right. An actual crash in kext causes kernel panic. I think I read that this is was possible, but I can't find how, and when, right now. The common thing that I'm thinking of is just voluntary error (exception) handling in kexts and reloading of kext on their own. There is some isolation and benefit to it.
Edit: ok, I just figured out my source of confusion. IOKit allows userspace drivers, which can crash without resulting in panic.
IOKit allows communication between kexts and userland. You could call that "userland drivers", but it's not like you can write only userland code to implement a driver.
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.
One of the reasons I chose GNU Emacs over XEmacs was a feeling that GNU Emacs will be maintained, even advanced, for as long as RMS has the strength to type. It's his baby.
(There were other reasons, the big one being momentum. XEmacs didn't run on the platform I was on for a long time, so it would have been a switch.)
An excellent point; for example, although I don't have any reason to think RMS himself did this, Emacs 24.4 will have file change notification support across all platforms where it compiles and where such notifications are available.
I grant that's a somewhat overdue feature for Emacs to have (e.g., I've wanted it ever since I set up Dropbox to synchronize my org-mode files across all my boxes), but it's definitely evidence that Emacs isn't lacking of maintenance and improvement.
I wonder: If Emacs rarely gains new features in core, is it because there aren't enough developers doing enough to improve it, or rather because people are having a hard time thinking up new features to add which Emacs doesn't already have?
Sorry, I was unclear; by "core" I mean "the Emacs distribution itself", as opposed to libraries you find on Github, EmacsWiki, or wherever else that isn't part of the standard Lisp library you get when you download the Emacs tarball.
"When questioned, he says that there's too much at stake
to abandon bzr if it can be avoided at all."
The big difference between then and now is that this time you have a very competent developer with an exceptional reputation offering to lead the migration. With esr leading things, there is a lot less at risk.
But then he seems to define maintenance as having fixed a specific bug that's been around for over a year, blocking a point release.
He admits that he can't follow the developers list to see if they're genuinely doing active maintenance (reasonable enough: he has a lot on his plate), but also won't accept the testimony of Emacs developers that the mailing list is dead and there's no evidence of real maintenance.
When questioned, he says that there's too much at stake to abandon bzr if it can be avoided at all. But the proposed replacement is GPL software. This is just madness.
Refs: http://lists.gnu.org/archive/html/emacs-devel/2013-03/msg009....
http://lists.gnu.org/archive/html/emacs-devel/2013-03/msg008...
(and surrounding posts).