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

201–210 of 317 posts

Re: Bzr is dying; Emacs needs to move

#201

Post by maxlybbert »

gillianseed wrote: post #139
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.

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 necessar…

IIRC, ARPA at some point was more interested in funding projects based on Mach than based on any other kernel.

Re: Bzr is dying; Emacs needs to move

#202

Post by peacetara »

DigitalJack wrote: post #68
zobzu wrote: post #9

Earlier quoted context omitted.

git is used by a bigger project (the kernel), that's mainly why. they're all ok, otherwise, even with their technical differences. github also contributed to amplify the adoption as its makes it really easy to use (even thus people generally use git in a non-distributed way with github) (i do prefer git in usage, tho, but thats subjective i suppose)

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/

Re: Bzr is dying; Emacs needs to move

#203

Post by lmm »

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.

I don't normally say "GNU/Linux", but I felt this was a case where the distinction is particularly important, because Android does run the Linux kernel, but is (IMO) a different OS from GNU/Linux.

Re: Bzr is dying; Emacs needs to move

#204

Post by __david__ »

bachback wrote: post #28

wow. please, please, you Emacs/LISP gurus out there: make a working modern package manager and integrate the browser like lighttable does. and perhaps rewrite emacs from scratch so that the source code makes sense in today's world not in 1980's world. unfortunately lighttable is staying closed for much too long, but something like it is desperately needed.

> make a working modern package manager

    M-x packages-list-packages
> and integrate the browser like lighttable does.

    M-x eww
> and perhaps rewrite emacs from scratch

Would you like a pony, too?

> so that the source code makes sense in today's world not in 1980's world.

I've actually found that Emacs's source it very readable (even the C lisp engine stuff). Do you object to the lisp or to the C?

Re: Bzr is dying; Emacs needs to move

#205

Post by justincormack »

Demiurge wrote: post #191
justincormack wrote: post #172

Earlier quoted context omitted.

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.

Why would they do that? Mach allows for some cool stuff, like kernel extensions being isolated.

Because building and maintaining a competitive OS is a huge effort, and FreeBSD has lots of cool stuff which they can't use...

Re: Bzr is dying; Emacs needs to move

#206

Post by Crito »

StavrosK wrote: post #189
Crito wrote: post #180

Earlier quoted context omitted.

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.

That's a very good question. I hadn't really tried to pinpoint what exactly I don't understand about it until now, but here's what some thinking uncovered: Branching/merging/committing is pretty straightforward. The problem is that some commands seem to be very convoluted. For example, why does reset do four different things depending on whether it's soft or hard or plain? I keep having to Google to find how I can re…

Ah yeah. The "why" with a lot of the porcelain stuff probably tends to be an unsatisfying "Because somebody didn't think it through very much a few years ago." git-reset would probably be better if it defaulted to --soft, and possibly left the other options to other commands.

Re: Bzr is dying; Emacs needs to move

#207

Post by lmm »

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…

> 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 project directory. The way to turn that off is to find some ifdefs and comment them out. If vim won then well, I'm not sure what winning means.

Winning means the user experience, not the code. And sure, I was lazy, it would be more accurate to say vim and emacs won between them (and are still fighting it out).

> Yeah ok, "zombie-revival" sure, your credibility gets a score of 0 here.

Do you disagree that a) Objective-C was more or less dead prior to the release of iOS b) almost all people currently using Objective-C are doing so solely because it's the language you can write iOS apps in c) absent huge, radical changes, Objective-C will never threaten Java's popularity the way that post-Java languages (C#, GHC Haskell (very different from the language that was standardized in 1990), Go, Scala) are?

Re: Bzr is dying; Emacs needs to move

#208

Post by bitwize »

binarycrusader wrote: post #152
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…

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.

Most game devs -- I'd say even most devs in grown-up, professional shops -- use p4.

Re: Bzr is dying; Emacs needs to move

#209

Post by lmm »

hamburglar wrote: post #190
belorn wrote: post #120

Earlier quoted context omitted.

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 communit…

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 yo…

Funny, I had the opposite view. I guess your opinion of the personalities really does change everything.

Re: Bzr is dying; Emacs needs to move

#210

Post by comex »

Demiurge wrote: post #191
justincormack wrote: post #172

Earlier quoted context omitted.

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.

Why would they do that? Mach allows for some cool stuff, like kernel extensions being isolated.

xnu kexts are not isolated and probably never will be, although IOKit exposes some things to userspace.
Post reply on HN