Bzr is dying; Emacs needs to move • Hacker News Board

Re: Bzr is dying; Emacs needs to move

#171

Post by rpgmaker » Thu, Jan 02, 2014, 6:05 PM UTC

pedrocr wrote: post #160

lmm wrote: post #81

Earlier quoted context omitted.

Microsoft did win the war; very little progress has been made by its competitors from the time; what's had success has been new OSes - OSX, iOS and Android (which while built of GNU/Linux pieces, is radically different from traditional GNU/Linux - enough to qualify as a different OS IMO, since the API is different). Vim did win the war; there's still nothing better. IBM did win the war, and then shot themselves in th…

> Android (which while built of GNU/Linux pieces, is radically different from traditional GNU/Linux - enough to qualify as a different OS IMO, since the API is different). The "GNU/Linux" vs "Linux" discussion is a long one but I'm pretty sure there's (almost?) no GNU in Android.

There's GNU in android.

Re: Bzr is dying; Emacs needs to move

#172

Post by justincormack » Thu, Jan 02, 2014, 6:05 PM UTC

asveikau wrote: post #134

vezzy-fnord wrote: post #105

Earlier quoted context omitted.

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

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.

Re: Bzr is dying; Emacs needs to move

#173

Post by justincormack » Thu, Jan 02, 2014, 6:07 PM UTC

mathattack wrote: post #109

stiff wrote: post #18

FWIW, just a few days ago I was browsing through the Emacs Bzr repository - after a full bzr clone, that took ridiculously long as well, a simple bzr blame takes 40-60 seconds to execute locally, and I have an SSD drive, four-core intel i7 and 8GB of RAM. I have never seen this kind of slowness with Git, with any repository size.

Does this make the issue a critique of RMS's management style, or of the FSF licensing that is unable to back out of a failed project?

If you look at the thread, it seems to be neither, just inertia. The licensing is fine, its GPL, no different from bzr.

Re: Bzr is dying; Emacs needs to move

#174

Post by justincormack » Thu, Jan 02, 2014, 6:09 PM UTC

rpgmaker wrote: post #171

pedrocr wrote: post #160

Earlier quoted context omitted.

> Android (which while built of GNU/Linux pieces, is radically different from traditional GNU/Linux - enough to qualify as a different OS IMO, since the API is different). The "GNU/Linux" vs "Linux" discussion is a long one but I'm pretty sure there's (almost?) no GNU in Android.

There's GNU in android.

I don't think there is. What are you thinking of? All of userland is not GPL licensed, I don;t even think any is LGPL, so I don;t think there is any GNU there.

Re: Bzr is dying; Emacs needs to move

#175

Post by justincormack » Thu, Jan 02, 2014, 6:12 PM UTC

sillysaurus2 wrote: post #25

gizmogwai wrote: post #15

Earlier quoted context omitted.

All of them emerged due to the end of license agreement for a free license of bitkeeper for the linux kernel. Git won due mainly to Linus personnality and the rise of "social coding" via github. Bazaar failed because, at the beginning, it was painfully slow compare to git and mercurial. It speed has increase over time, but bad reputation is hard to get rid of.

All of them emerged due to the end of license agreement for a free license of bitkeeper for the linux kernel. Bet bitkeeper regretted that decision...

They don't seem to have updated their website since http://www.bitkeeper.com/

Re: Bzr is dying; Emacs needs to move

#176

Post by bronson » Thu, Jan 02, 2014, 6:15 PM UTC

rlpb wrote: post #16

iv_08 wrote: post #10

Earlier quoted context omitted.

Canonical mismanagement, contributor license agreement, missing manpower.

The article and the quite detailed bzr history it links to do not appear to suggest this at all. Can you provide any justification for your three claims?

License Agreement: the first paragraph in the section "Hard to land patches" describes the CLA as one reason why it's hard.

Missing manpower: just glance at the mailing list archives.

Re: Bzr is dying; Emacs needs to move

#177

Post by Beliavsky » Thu, Jan 02, 2014, 6:17 PM UTC

Do people really decide whether to contribute to an open source project based on the version control system it uses, rather than the importance of the project itself?

Re: Bzr is dying; Emacs needs to move

#178

Post by [deleted] » Thu, Jan 02, 2014, 6:19 PM UTC

sparkie wrote: post #138

joelthelion wrote: post #104

Earlier quoted context omitted.

>Now? It's A Big Deal to a lot of younger developers. It is almost totemic. If it's not Git and (ideally) Github then.. it isn't worth hacking on? Do you really want those guys on your project?

I wonder if any of those guys would ever contribute to emacs anyway, unless we rewrite it in javascript.

[deleted]

Re: Bzr is dying; Emacs needs to move

#179

Post by bronson » Thu, Jan 02, 2014, 6:22 PM UTC

rlpb wrote: post #16

iv_08 wrote: post #10

Earlier quoted context omitted.

Canonical mismanagement, contributor license agreement, missing manpower.

The article and the quite detailed bzr history it links to do not appear to suggest this at all. Can you provide any justification for your three claims?

Actually, sources for all three statements can be found within 2 paragraphs (moving forward and backward) of "Decline and focus on Ubuntu and UDD"

Re: Bzr is dying; Emacs needs to move

#180

Post by Crito » Thu, Jan 02, 2014, 6:23 PM UTC

StavrosK wrote: post #169

wirrbel wrote: post #91

Earlier quoted context omitted.

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…

> It turns out however that Git is really easy to grasp. Please write something to explain it. I must be pretty dumb, because I don't get it, even after reading about ten explanatory texts.

Since you have already read ten things about it and don't understand it, it would help if you told us what you do not understand so that we do not waste our time rehashing things that you have already not understood.