281–290 of 317 posts
Earlier quoted context omitted.
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.)
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.
Earlier quoted context omitted.
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…
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.
See my comment up thread about Jordan Hubbard's plans.
Earlier quoted context omitted.
As an avid git user, I believe that git's victory against current tools does nothing to stop someone from creating a better DVCS in the future. They'll just have to identify why git won and address those points, if they want to dethrone git.
The success of git is - apart from the speed - related with its property of being the "stupid content tracker". Git's architecture is a simple bottom-up engineering approach. The user interface (porcellain) builts upon a conceptually simple core (plumbing). Other VCS have defined nice UI which where then implemented by a core that depends on the UI. This top-down approach means that the core components can suddenly b…
Earlier quoted context omitted.
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.
FreeBSD does not have Mach ports (the IPC system). There is a ton of what OSX does that needs this. See my comment up thread about Jordan Hubbard's plans.
Earlier quoted context omitted.
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 des…
Over those 30 years the emacs codebase must have moved through several revision control systems. Why is moving to another one such a big deal?
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 h…
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] [1] https://lists.gnu.org/archive/html/em…
Earlier quoted context omitted.
for me it's the easy branching and rebasing that make git the winner. That's in spite of the inconsistent cli. If Hg were as good at branching and rebasing, I'd reconsider it. btw, anyone know of a python command line client for git? I just keep finding stuff for programmatically using git and that's not what I want.
What do you mean, a python command line client? If you're using it from the command line and not programmatically, why does it matter what language it's written in? (gitless may possibly be what you want)
Earlier quoted context omitted.
for me it's the easy branching and rebasing that make git the winner. That's in spite of the inconsistent cli. If Hg were as good at branching and rebasing, I'd reconsider it. btw, anyone know of a python command line client for git? I just keep finding stuff for programmatically using git and that's not what I want.
http://www.samba.org/~jelmer/dulwich/