Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bzr is dying; Emacs needs to move

lists.gnu.org

Post reply on HN
Print view View original

151–160 of 317 posts

Re: Bzr is dying; Emacs needs to move

#151

Post by revelation »

blumentopf wrote: post #87
hyperpape wrote: post #83

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…

> 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

> 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!

Re: Bzr is dying; Emacs needs to move

#152

Post by binarycrusader »

mikro2nd wrote: post #41

>git won the mindshare war. I regret this - I would have preferred Mercurial, but it too is not looking real healthy these days I confess that my perception of Mercurial is the diametric opposite of the author's. Recently I believe I have seen a modest resurgence of interest in Hg and increased uptake. Am I just seeing this through some peculiar VCS-warped glasses? I believe that much of the popularity of git stems f…

Yep, I don't understand the author's assertions about Mercurial either.

Mercurial remains a better choice for a few use cases where git simply falls flat.

Among game developers, in particular, because of their need to have revision control for large assets, Mercurial seems to be more popular than git due to the large files extension.

And realistically, perforce or other solutions appear to be even more popular among that particular developer segment.

Personally, I use Mercurial wherever possible, but that's not because I believe Mercurial to be technically superior, it's just because I hate git's UI.

Perhaps among the general FOSS community git is more popular, but both git and Mercurial have yet to met the needs of many developers.

Re: Bzr is dying; Emacs needs to move

#153

Post by xmonkee »

belluchan wrote: post #146
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…

> Vim did win the war; there's still nothing better I'll just put this here for you: https://code.google.com/p/vim/source/browse/src/eval.c Yes that's nearly 25,000 lines of mixed spaces and tab filled pre-C89 C with 492 occurrences of #idef, many appearing in the middle of a function definition. I recently ran vim with debug symbols compiled and it was nice enough to dump a nice 4GB regular expression log file in my…

Making predictions isn't allowed on the internet anymore?

Re: Bzr is dying; Emacs needs to move

#154

Post by pritambaral »

lmm wrote: post #86
DigitalJack wrote: post #68

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)

It matters if you want to hack on it.

Re: Bzr is dying; Emacs needs to move

#155

Post by asveikau »

gillianseed wrote: post #140
asveikau wrote: post #134

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.)

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

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.

Re: Bzr is dying; Emacs needs to move

#156

Post by Macha »

sixtypoundhound wrote: post #107

Bzr certainly isn't dead. git has won the mindshare war for mainstream developers, but I've found it to be a useful FOSS alternative for developers forced to use a Windows environment [for business-related reasons, don't laugh..it pays the bills]. Their UI is a bit more intuitive than git's for new users. Now, if you're a hardcore Linux-stack career dev...get onto git ASAP... but for lesser folks...bzr works just fin…

> but I've found it to be a useful FOSS alternative for developers forced to use a Windows environment [for business-related reasons, don't laugh..it pays the bills]. Their UI is a bit more intuitive than git's for new users.

However, the same also applies to Mercurial, and even though Mercurial is less popular than Git, it still has a lot more devs who use it than Bzr.

Re: Bzr is dying; Emacs needs to move

#157

Post by aaronem »

xmonkee wrote: post #153
belluchan wrote: post #146

Earlier quoted context omitted.

> Vim did win the war; there's still nothing better I'll just put this here for you: https://code.google.com/p/vim/source/browse/src/eval.c Yes that's nearly 25,000 lines of mixed spaces and tab filled pre-C89 C with 492 occurrences of #idef, many appearing in the middle of a function definition. I recently ran vim with debug symbols compiled and it was nice enough to dump a nice 4GB regular expression log file in my…

Making predictions isn't allowed on the internet anymore?

Of course it's allowed. So is judging someone's credibility based on the predictions he chooses to make, whether by the accuracy of said predictions over time, or the plausibility of said predictions in advance of proof's arrival.

Re: Bzr is dying; Emacs needs to move

#158

Post by aaronem »

belluchan wrote: post #146
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…

> Vim did win the war; there's still nothing better I'll just put this here for you: https://code.google.com/p/vim/source/browse/src/eval.c Yes that's nearly 25,000 lines of mixed spaces and tab filled pre-C89 C with 492 occurrences of #idef, many appearing in the middle of a function definition. I recently ran vim with debug symbols compiled and it was nice enough to dump a nice 4GB regular expression log file in my…

Say what you like about Emacs; its source, both in C and in Emacs Lisp, is generally quite readable, and the former I've found to be especially well commented.

Re: Bzr is dying; Emacs needs to move

#159

Post by reddit_clone »

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.

You made me spill my coffee on the keyboard. It does seem Javascript people have taken over the obnoxious hipsterism from Ruby folks.

Re: Bzr is dying; Emacs needs to move

#160

Post by pedrocr »

lmm wrote: post #81
xradionut wrote: post #42

Earlier quoted context omitted.

I hate when people say "git won the war", it sounds like an excuse to close minds and stop progress. What if "Microsoft won the war"? Or vim? Or IBM? Or Java? Or Taco Bell?

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.

Post reply on HN