Emacs Needs To Move To GitHub, Says ESR

Git, not Github by codl · 2014-01-02 02:34 · Score: 5, Informative

ESR's original posting does not mention Github at all.

Re:Git, not Github by monzie · 2014-01-02 02:42 · Score: 2, Insightful

Good catch there. If you read just the summary ( and not the article ) - it's misleading! Git != Github, folks. You may like Git *because* of github but please don't confuse the two.
Re:Git, not Github by Desler · 2014-01-02 02:45 · Score: 5, Informative

"The article" (the first link which is to hypnosec's spam site) also says Github. ESR's post says merely Git.
Re: Git, not Github by Anonymous Coward · 2014-01-02 02:51 · Score: 1

I thought emacs ran on top of git. or was it the other way around ? meh I can never remember ...
Re:Git, not Github by JonahsDad · 2014-01-02 02:54 · Score: 1

Funny enough, the article now has all "Github" items crossed out and replaced by "git"
Re:git, not GitHub by fuzzyfuzzyfungus · 2014-01-02 03:11 · Score: 4, Insightful

The original source (ESR himself) never mentioned GitHub. Just git. Can people stop conflating the two please?
C'mon, man, get with the times. Having 'protocols' with 'definitions' that allow for 'multiple vendor-neutral implementations' is so totally outdated, man. Everybody knows that the future is snappily named proprietary services dependent on a single vendor with a nonsensical business model, ideally accessible only through an iPhone app!
Re:Git, not Github by kthreadd · 2014-01-02 03:25 · Score: 1

They probably did the same mistake.
Re:Git, not Github by Desler · 2014-01-02 03:30 · Score: 2

There is no "they". "hypnosec" is "Ravi Mandalia". The mistake was made by the same person.
Re:git, not GitHub by Medievalist · 2014-01-02 03:49 · Score: 1

The original source (ESR himself) never mentioned GitHub. Just git. Can people stop conflating the two please?
C'mon, man, get with the times. Having 'protocols' with 'definitions' that allow for 'multiple vendor-neutral implementations' is so totally outdated, man. Everybody knows that the future is snappily named proprietary services dependent on a single vendor with a nonsensical business model, ideally accessible only through an iPhone app!
Said snappily named services discovered through a multicast DNS portal into a Microsoft Active Directory, of course.
Why have a single single vendor dependency when you can stack 'em up like cordwood?
Re:Git, not Github by slim · 2014-01-02 03:52 · Score: 2

"They" is sometimes used as a non-gendered singular.
Re:git, not GitHub by fuzzyfuzzyfungus · 2014-01-02 04:13 · Score: 1

That sounds dangerously like a suggestion that the assorted vendor lock-in products should inter-operate with one another in some sane way... True endarkenment is only achieved when each product has some stupid dependency on the others; but not anything that would actually make the whole mess easier. Making a 'cloud' service dependent on a local MS server/client setup, for instance, is excellent; but having that 'cloud' service capable of authenticating against your AD, rather than it's own half-assed credentials system, totally spoils the effect....
Re:git, not GitHub by Medievalist · 2014-01-02 04:32 · Score: 1

That sounds dangerously like a suggestion that the assorted vendor lock-in products should inter-operate with one another in some sane way.
Oh, don't worry, there's no sanity involved!
Re:git, not GitHub by Anonymous Coward · 2014-01-02 04:35 · Score: 0

snappily named proprietary services
Exactly. All these antique applications should move to Snapchat and silently autodestroy when their time has come.
Re:Git, not Github by Desler · 2014-01-02 04:37 · Score: 0

Yes it can, but the post was clearly using it as if there were two different people.
Re: Git, not Github by Jeremiah+Cornelius · 2014-01-02 04:43 · Score: 2

Will the last EMACS user, kindly turn out the lights?
JWZ likes sitting in the dark... :-)

--
"Flyin' in just a sweet place,
Never been known to fail..."
Re:git, not GitHub by knarf · 2014-01-02 05:21 · Score: 1

This. So true. The only thing to be added is an icon in the style of Dick Bruna's 'Nijntje Konijntje' to appeal even the lowest of the lowest common of denominators.

--
--frank[at]unternet.org
Re:git, not GitHub by broken_chaos · 2014-01-02 06:20 · Score: 1

You forgot that it has to be a non-free (speech and beer) iPhone app!
Re:git, not GitHub by Anonymous Coward · 2014-01-02 06:29 · Score: 0

a nonsensical business model
GitHub may be many things, but a company with a nonsensical business model isn't one of them. GitHub make a buttload of cash from GitHub Enterprise licenses. I mean, stupid money.
Re:Git, not Github by Anonymous Coward · 2014-01-02 06:47 · Score: 0

But 95% of the developers out there think github when git is mentioned.
Why? oh boy, I can name 10 reasons but all would be easy flamebait on / . aside from git offers the best tradeoff of complex management to easy SCM if it's distributed.
Re: Git, not Github by rk · 2014-01-02 08:19 · Score: 1

It used to be this way for me:
1. pico then nano for text documents
2. vi/vim for sysadmin-style tasks and quick edit jobs
3. emacs/xemacs for heads-down heavy duty development work
But vim has improved to the point that it is now my first choice for all three use cases. I used to be fairly good at using emacs, but it's been so long since I last used it all I can remember now is how to save or quit.
Re:Git, not Github by VortexCortex · 2014-01-02 10:18 · Score: 1

there were two different people.
As any scientist can see: That is an unevidenced claim. Prove it.
It is commonly accepted that everyone else on the Internet is one fat guy in his mom's basement -- Yes, even the "girls".
Recent leaks reveal he's an NSA employee.
Re:Git, not Github by epyT-R · 2014-01-02 10:52 · Score: 0

It's not supposed to be. Genderless singular is 'it'.
Re:Git, not Github by Anonymous Coward · 2014-01-03 12:03 · Score: 0

Please also note that people have never "done" mistakes. They have _made_ mistakes.

What's bzr? by Anonymous Coward · 2014-01-02 02:35 · Score: 2, Interesting

Never heard of it.

Re:What's bzr? by Anonymous Coward · 2014-01-02 02:41 · Score: 0

Canonical's NIH version of Git.
Re:What's bzr? by Anonymous Coward · 2014-01-02 02:48 · Score: 0

How bizarre.
Re:What's bzr? by Rinisari · 2014-01-02 02:54 · Score: 2

Bazaar. It's a VCS that Canonical developed. Why Switch to Bazaar?
IMO, the only things that Bazaar has up on Git these days is released, official support for Windows and thus better GUIs all around for all platforms. Git is still technically a pre-release for Windows. Bazaar is also purportedly better for binary files than Git, and allows downloads from any point in the history (instead of Git requiring that you download the whole repository history).

--
Colin Dean Go a year without DRM
Re:What's bzr? by Sponge+Bath · 2014-01-02 02:59 · Score: 5, Funny

How bizarre.
The cathedral and the bizarre?
Re:What's bzr? by Anonymous Coward · 2014-01-02 03:02 · Score: 0

I wonder how ESR reacted to Canonical's choice of Bazaar as the name of their open source collaboration tool. Flattered? Territorial? I guess neither.
Re:What's bzr? by dominux · 2014-01-02 03:08 · Score: 3, Informative

it pre-dates git by a year, it was the NiH version of cvs and svn. Bzr was doing useful stuff before anyone realised Git would ever be used for anything other than the Linux kernel source tree. That isn't to say that NiH isn't sometimes a good thing, and that Canonical do daft things from time to time, but bzr wasn't a NiH reaction to Git.
Re:What's bzr? by FreonTrip · 2014-01-02 03:24 · Score: 1

How bizarre. (Ooh, baby)
I'll, uh, show myself out then, yeah? Yeah. *cough*
Re:What's bzr? by Desler · 2014-01-02 03:28 · Score: 1

it pre-dates git by a year
Nope, initial release of bzr only predates the first release of git by 12 days. March 26, 2005 vs April 7, 2005.
Re:What's bzr? by Anonymous Coward · 2014-01-02 03:36 · Score: 0

Git doesn't require you to download the whole history. You can use the "git clone --depth X" to only download X number of revision. It does add some restrictions, so you can't clone/fetch/push from your clone.
Re:What's bzr? by allo · 2014-01-02 03:45 · Score: 1

Maybe it was an attempt to become the kernel VCS, as the kernel hackers already were angry about bitkeeper at this time.
Re:What's bzr? by Anonymous Coward · 2014-01-02 03:58 · Score: 0

kernel hackers
At Canonical?
Re:What's bzr? by DrXym · 2014-01-02 04:00 · Score: 3, Informative
Git seems to be perpetually in preview on Windows but in practice it works relatively well. There are quite a few front ends for it if you hate the command line.
The biggest issues I have with it are:
- Line ending conversion is a massive pain in the arse. Windows is CRLF, Linux is LF. Msysgit asks during installation what line ending conversion policy to use. If you get it wrong, you'll see spurious issues with files marked as modified when no difference is visible. The best advice I can give is set core.autocrlf to false when you install msysgit so that line endings are left alone. You can do stuff with a file called .gitattributes to turn off line ending conversion in the repo itself but JGit (the Java pure impl of Git in Eclipse) doesn't actually bother to honour the settings in that file.
- Performance is a bit poor. You won't notice in small repos but when the repo is 10,000+ files, simple things like "git status" can sit there for minutes. MSYS has an inefficient lstat and performance becomes noticeably in Git as a consequence. An SSD helps a lot, but that's no consolation for devs who can't ask for one.
- 260 char MAX_PATH imposes restrictions on path length that the fs itself could cope with.
Nothing is a deal breaker. I think Git on Windows works as well as most other source control systems when its up and going and comes with its own advantages that compel its use for software development. I wouldn't use it for document management though - something like Subversion would be better for that.
Re:What's bzr? by Lemming+Mark · 2014-01-02 04:08 · Score: 3, Informative

I thought there was a fairly complex history here, since the current bzr was (I thought) bzr-ng originally, an alternative to some original Bazaar tool. And I thought that *that* came from GNU Arch, which (speaking loosely) I gathered wasn't well understood or enjoyable to use. I don't know how much of the current behaviour dates back that far, though, so there may not be too much in common now!
Re:What's bzr? by allo · 2014-01-02 04:31 · Score: 1

the kernel hackers were angry about bitkeeper.
Then bzr was released, maybe just in that moment, to get the kernel hackers to use it.
Then Linus released git, which canonical could not expect.
AFAIR, the monotone people had hope, too.
Re:What's bzr? by Anonymous Coward · 2014-01-02 04:42 · Score: 0

How bizarre.
The cathedral and the bizarre?
Boom! Mod parent up!
Re:What's bzr? by Jeremiah+Cornelius · 2014-01-02 04:46 · Score: 2

That's a pretty antipodian reference... :-)

--
"Flyin' in just a sweet place,
Never been known to fail..."
Re:What's bzr? by Anonymous Coward · 2014-01-02 08:11 · Score: 0

Linus looked at bzr and monotone quite seriously. He didn't like bzr. He did like monotone, but it was too slow at the time (nowadays it is much better, but not as fast as git. Well, no DVCS is as fast as git, but most of the good ones are fast enough nowadays).
Re:What's bzr? by Anomalyst · 2014-01-02 09:52 · Score: 1

That's a pretty antipodian reference... :-)
I got nuthin' against feet, but find the notion of people being replaced by alien garden-grown replicas disquieting.

--
There is no right to feel safe thru security vaudeville at the expense of everyone's freedom, privacy and tax money.
Re:What's bzr? by Anomalyst · 2014-01-02 10:05 · Score: 1

260 char path?!?, the 80's called, they want their asinine name limitations back. I lost a years worth of coding history to a backup program that silently truncated fie paths it was supposed to be archiving. If they give such a rats ass about it use a vchar[2048] field. Hopefully it will at least produce a warning that the brain dead field length is too small.

--
There is no right to feel safe thru security vaudeville at the expense of everyone's freedom, privacy and tax money.
Re:What's bzr? by Anonymous Coward · 2014-01-02 10:22 · Score: 1

How bizarre.
The cathedral and the bizarre?
Boom! Mod parent up!
But, Captain, it's as high as it'll go!
Re:What's bzr? by Anonymous Coward · 2014-01-02 10:40 · Score: 2, Informative

260 characters is a Windows limitation ("C://" + 256). To get longer paths you need to switch to the Unicode-based API, and change the format of path strings. See http://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx
Re:What's bzr? by Anonymous Coward · 2014-01-02 10:49 · Score: 0

I highly doubt the limitation is on the git side, and if it's on the Windows-side, it's probably there for backwards compatibility.
Re: What's bzr? by loufoque · 2014-01-02 11:12 · Score: 1

monotone is written in C++, and we all know what Torvalds thinks of C++
Re:What's bzr? by shutdown+-p+now · 2014-01-02 13:57 · Score: 1

Visual Studio 2013 has Git integration. If that's not "official" than I don't know what is.
(it doesn't use msysgit or any other console version, but rather libgit2)
Re:What's bzr? by shutdown+-p+now · 2014-01-02 13:58 · Score: 1

260 characters is a Windows limitation ("C://" + 256)
It's actually rather "C:\" + 256 chars of path + null terminator.
Re:What's bzr? by complete+loony · 2014-01-02 16:06 · Score: 1

While I tend to use the command line for working with commit history (commit / rebase / etc), I often install SmartGit for looking at history and editing the index before a commit / merge operation.

--
09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
Re:What's bzr? by DrXym · 2014-01-02 21:06 · Score: 1

It's not on the Windows side. It's either in the MSYS layer, or the git code itself. From an end-user perspective in means having to keep your paths as close to the root as possible or use the SUBST command to map a subdir to a drive letter.
Re:What's bzr? by DrXym · 2014-01-02 21:17 · Score: 1

I like SmartGit too although it's a licensed product. The best thing about it is the visualization which is much easier to follow than Tortoise or EGit.
Re:What's bzr? by DrXym · 2014-01-02 21:57 · Score: 1

msysgit has Unicode file support since 1.8.x but most of the accompanying tools like Bash aren't unicode aware and the path length issue is still there. Long path notation requires a \\?\ prefix on an absolute path and most of git's operations are relative where it can't be easily tacked on. So if a repo had a > 260 char relative path it would be pummelled. They could potentially fix instances where absolutePath > 260 chars by using the prefix. I don't know how UTF-8 encoding would play into this but perhaps unicode paths would hit the limit in less readable chars. Basically it's a mess.
Re: What's bzr? by doti · 2014-01-03 01:12 · Score: 2

IIRC he dislikes C++ for kernel development.

--
factor 966971: 966971
Re: What's bzr? by allo · 2014-01-03 12:51 · Score: 1

But maybe he wants to be able to patch the VCS he's using.
Re:What's bzr? by greg1104 · 2014-01-04 07:25 · Score: 1

MAX_PATH is a Windows API limitation. You can get around it by using Unicode aware versions of some functions, but since that has limitations, too, you can't just swap to those without adding a new set of problems.
There is a lot of Windows software that suffers from this same limitations, most of them just don't talk about it. git is just taking the less troublesome of the two bad options presented by the OS. The standard workaround is to map a drive letter to some subset of the path when it grows large enough to hit this limit. As for the 80's calling, this part of the Windows code is in fact still worrying about 8.3 file names from DOS too...

GNU Savannah supports git by byolinux · 2014-01-02 02:35 · Score: 4, Informative

No need to move to a proprietary hosting service like Github.

I wrote about this previously: http://www.fsf.org/blogs/community/savannah

--
Join the Free Software Foundation

Re:GNU Savannah supports git by ThePhilips · 2014-01-02 02:45 · Score: 1

Wow. Support for GNU Arch is really an outstanding feature!
TLA is for all intent and purposes is dead. The .gitignore alone is reason enough to migrate to git.
OK, archives is a very cool feature found literally nowhere else, but it alone isn't enough to sway any decision process in favor of TLA.

--
All hope abandon ye who enter here.
Re:GNU Savannah supports git by mwvdlee · 2014-01-02 02:48 · Score: 1, Interesting

Just wondering; why doesn't your article mention Github, which is probably the most popular service right now?

--
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
Re:GNU Savannah supports git by devent · 2014-01-02 02:48 · Score: 1

There are more alternatives. For example Redmine http://www.redmine.org/
Redmine offers a full project management suite: bug track, wiki, forum, files and document, version control, GANT chart, and so on.

--
http://www.mueller-public.de - My site http://www.anr-institute.com/ - Advanced Natural Research Institute
Re:GNU Savannah supports git by Desler · 2014-01-02 02:50 · Score: 1

Did you not even bother reading the person's first sentence?

No need to move to a proprietary hosting service like Github.
Re:GNU Savannah supports git by scubamage · 2014-01-02 02:51 · Score: 1

Most likely because Stallman completely avoids all cloud services because when you use them, you don't really own your data. Git has an actual chance of being used. Github? Unlikely.
Re:GNU Savannah supports git by mwvdlee · 2014-01-02 02:52 · Score: 1

I did. Why didn't you?

Just wondering; why doesn't your article mention Github, which is probably the most popular service right now?

--
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
Re:GNU Savannah supports git by Desler · 2014-01-02 02:52 · Score: 1

GNU Savannah is a "cloud service". The difference to someone like Stallman is GNU Savannah is "free software" whilst Github is not.
Re:GNU Savannah supports git by Desler · 2014-01-02 02:54 · Score: 0

Yes, and the first sentence of his post that you responded to tells you exactly why:

No need to move to a proprietary hosting service like Github.
It's an FSF article. Why would they recommend a proprietary service? Are you ignorant of who and what the FSF are?
Re:GNU Savannah supports git by just_another_sean · 2014-01-02 02:54 · Score: 1

proprietary hosting service

--
Creationist Textbook Stickers Declared Unconstitutional by CowboyNeal
Re:GNU Savannah supports git by Desler · 2014-01-02 02:57 · Score: 1, Insightful

Exactly. His question is as dumb as asking "Why doesn't the FSF recommend Windows?".
Re:GNU Savannah supports git by scubamage · 2014-01-02 03:01 · Score: 1

That I did not know. I know he has posted some rants before about avoiding cloud services, but you could very well be right about that being the difference.
Re:GNU Savannah supports git by mwvdlee · 2014-01-02 03:05 · Score: 1

I wondered why the article didn't mention it.
I fully understand why he wouldn't recommend it, which is why I didn't ask about that.
Three other proprietary services are mentioned, but the most popular one was omitted.

--
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
Re:GNU Savannah supports git by Desler · 2014-01-02 03:10 · Score: 2

Because the list was not meant to be exhaustive? Because when the article was written in August 2008, Github was only a couple of months old at the time and had far less users than the other services mentioned?
Re:GNU Savannah supports git by mwvdlee · 2014-01-02 03:14 · Score: 1

Read my comment above.
Imagine Microsoft wrote an article about OS'es, recommending Windows and mentioning only Haiku, ReactOS and FreeDOS as possible open source OS'es, failing to even mention Linux.
This is not about what the article recommends, it's about the article completely ignoring the elephant in the room.

--
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
Re:GNU Savannah supports git by Desler · 2014-01-02 03:16 · Score: 1

This is not about what the article recommends, it's about the article completely ignoring the elephant in the room.
The article was written in August 2008. Github was 4 months old. It was no "elephant in the room". The article also didn't mention Codeplex, Bitbucket, JavaForge, and countless other sites that existed at the time in 2008. So what? His article was not meant to be an exhaustive list. The article merely was about the biggest source code hosts at the time it was written.
Re:GNU Savannah supports git by Anonymous Coward · 2014-01-02 03:36 · Score: 0

Stallman is a whackjob and the free software movement would be 10x better off without him.
Re:GNU Savannah supports git by Wootery · 2014-01-02 04:00 · Score: 0

Because when the article was written in August 2008
I think that was mwvdlee's point. It's hard to take them seriously if they make no mention of GitHub, but do single out other rivals including Google Code.
It's their responsibility to stay up to date with this stuff. Failing to keep your web-site relevant isn't a good sign.
Re:GNU Savannah supports git by DrXym · 2014-01-02 04:03 · Score: 1

Source code has to be hosted somewhere. Even if the FSF hosts source code on their own servers it's still "in the cloud" as far as people pushing and pulling from it are concerned. Anyway, if it's a big deal, they could set up GitHub as a mirror and host the "master" copy on their server even if in practice most people would be pushing to GitHub and that would be periodically synced to the FSF.
Re:GNU Savannah supports git by Anonymous Coward · 2014-01-02 04:34 · Score: 0

Are you ignorant of who and what the FSF are?
A bunch of hardcore, militant zealots who believe proprietary software is evil. Just one notch above radical Islamic groups.
Re:GNU Savannah supports git by Desler · 2014-01-02 04:39 · Score: 1, Insightful

Entitlement much? Why should they have to continually update some 5.5 year old article?
Re:GNU Savannah supports git by Wootery · 2014-01-02 04:58 · Score: 1

Entitlement? I'm not saying they owe me anything, I'm saying they have awful marketing.
I know they're driven by philosophy not money, but still, they really ought to maintain their why-you-should-use-us page.
Re:GNU Savannah supports git by Anonymous Coward · 2014-01-02 05:06 · Score: 0

... and has pitiful git support ...
Re:GNU Savannah supports git by Anonymous Coward · 2014-01-02 05:09 · Score: 0

8==========D
8=============D
Ok we have to admit it, the gentelman #2 in above intellectuall discussion clearly wins by around 1 inch.
Congratulations, YOU'R WINNER.
Re:GNU Savannah supports git by Anonymous Coward · 2014-01-02 05:18 · Score: 0

Technically git doesn't need any central repository. I never tried it and it should be a real pain but you can distribute patches by mail and git can merge from them. Check "Applying Patches from E-mail".
(Posting as AC to preserve mods)
Re:GNU Savannah supports git by unixisc · 2014-01-02 05:41 · Score: 1

He'd probably look for an AGPL3 license on such a service before he touches it
Re:GNU Savannah supports git by unixisc · 2014-01-02 05:44 · Score: 1

I think the FSF is fine w/ cloud services as long as they are AGPL3 licensed. In other words, if someone runs a service on such a server, the source code of all the services that the server runs has to be made available. Unlike in the case of GPL3 or LGPL3, where source code only had to accompany distribution of software, here it has to accompany remotely running software.
Re:GNU Savannah supports git by MouseTheLuckyDog · 2014-01-02 05:47 · Score: 1

I believe when Stallman said that he was referring to the "traditional cloud services".
Re:GNU Savannah supports git by Sri+Ramkrishna · 2014-01-02 07:39 · Score: 1

he's not a whack job, he's a person who rigidly does not compromise certain principles. That is actually really hard because every day we make compromises. Moral rigidity is sometimes looked upon as crazy sometimes. You should think of him as a canary in a coal mine. The further you start moving away from the original goals of hte movement, the louder he gets. He's a warning bell. For that reason alone, FOSS needs him.
Re:GNU Savannah supports git by Anonymous Coward · 2014-01-02 07:51 · Score: 0

AGPL3, the license that is actually a EULA and violates freedom zero. I see cracks in the ivory tower.
Re:GNU Savannah supports git by ragefan · 2014-01-02 09:12 · Score: 1

You might consider him a whackjob, but he and his ideas are responsible for a lot of the software you use directly and indirectly.
Re:GNU Savannah supports git by Darinbob · 2014-01-02 11:34 · Score: 1

Changing source code control may be a useful idea, but having a centralized server that everyone is supposed to use is a very poor idea. Variety is good, centralized sameness is bad. Adding peer pressure to adhere to conformity will not be something that RMS responds to. Besides, github will die within a decade or two anyway if history is any judge.
Re:GNU Savannah supports git by Darinbob · 2014-01-02 11:40 · Score: 1

Stallman is still like a young man in many ways, in that he maintains his idealism. Meanwhile most of the rest of us older people just don't have the energy to fight for what's right and instead give in to convenience. So while I don't always agree with him he still gets my respect.

Git... by Anonymous Coward · 2014-01-02 02:36 · Score: 5, Informative

He wants to move emacs to git and not to Github. Journalists...

Re:Git... by Anonymous Coward · 2014-01-02 02:39 · Score: 3, Informative

"hypnosec" is not a journalist. It's someone who's spamming his regurgitation blog posts to drive ad impressions.
Re:Git... by Anonymous Coward · 2014-01-02 02:43 · Score: 0

The mistake was already in the article by Ravi Mandalia.
Re:Git... by monzie · 2014-01-02 02:43 · Score: 1

and Slashdot Editors.. if there are any of them left....
Re:Git... by Desler · 2014-01-02 02:46 · Score: 3, Informative

Ravi Mandalia is "hypnosec".
Re:Git... by Desler · 2014-01-02 02:48 · Score: 5, Informative

To add, Ravi Mandali's first version of his spam site was called "Hypno Security" which just basically regurgitated a couple of paragraphs of other people's news as "articles" and started spamming it here.
http://www.freelancer.com/u/hypnosec.html
Re:Git... by Desler · 2014-01-02 03:05 · Score: 1

Having an editor is useless when they are basically functionally illiterate.
Re:Git... by Anonymous Coward · 2014-01-02 03:11 · Score: 0

To add, Ravi Mandali's first version of his spam site was called "Hypno Security" which just basically regurgitated a couple of paragraphs of other people's news as "articles"
So like Slashdot?
Re:Git... by Anonymous Coward · 2014-01-02 03:20 · Score: 0

Slashdot "editors" focus on whatever article will generate the most page hits. This month it's obviously all the NSA/Snowden noise; greenlighting essentially the same article three times a day won't change as long as people keep commenting on it.
Re:Git... by Desler · 2014-01-02 03:21 · Score: 3, Funny

No, actually worse. His grammar and factual accuracy makes the Slashdot editors look top notch.
Re:Git... by Anonymous Coward · 2014-01-02 03:39 · Score: 0

Slashdot has never in its entire existence had "editors".
Re:Git... by tgd · 2014-01-02 03:39 · Score: 1

and Slashdot Editors.. if there are any of them left....
If it doesn't reduce ad impressions, why would the editors care?
The criticisms people are leveling against this Ravi Mandali guy are for doing the same crap that DICE has ensured Slashdot does every day.
Re:Git... by Anonymous Coward · 2014-01-02 06:50 · Score: 0

We're (e.g. journalists) living in the corporate western world folks. Brand > tech.

Eric S. Raymond Unsubscribes from LKML by Anonymous Coward · 2014-01-02 02:36 · Score: 0

http://www.trollaxor.com/2013/02/eric-s-raymond-unsubscribes-from-lkml.html

Re:Eric S. Raymond Unsubscribes from LKML by unixisc · 2014-01-02 05:55 · Score: 1

Apparently, he was floored by Linus' chivalrous behavior

git, not GitHub by Anonymous Coward · 2014-01-02 02:36 · Score: 5, Informative

The original source (ESR himself) never mentioned GitHub. Just git. Can people stop conflating the two please?

He never mentioned "GitHub" by Anonymous Coward · 2014-01-02 02:37 · Score: 0

What? GitHub isn't a version control system, is a proof of concept on how to centralize a distributed technology.

Re:He never mentioned "GitHub" by Anonymous Coward · 2014-01-02 03:14 · Score: 0

Haha, well put. And true.

Marketing by i+kan+reed · 2014-01-02 02:47 · Score: 1

Oh god, the marketing-speak is coming from inside the open source developers. Get out! Get out now!

Surprised by DaveAtFraud · 2014-01-02 02:51 · Score: 4, Funny

I'm surprised that emacs didn't already have a version control system built into. It has everything else.

Cheers,
Dave

--
They that can give up essential liberty to obtain a little temporary safety deserve neither safety nor liberty.
Ben

Re:Surprised by Anonymous Coward · 2014-01-02 03:02 · Score: 5, Funny

It has everything but still lacks decent editor
Re:Surprised by fuzzyfuzzyfungus · 2014-01-02 03:13 · Score: 1

Given that emacs is Turing-complete, it might be said that it includes all possible features. Some, of course, are available out of the box, while some require considerable configuration (mysteriously, this configuration process takes almost exactly the same amount of time as re-implementing the feature in emacs Lisp...)
Re:Surprised by ebno-10db · 2014-01-02 03:20 · Score: 4, Funny

You will spend eternity in a circle of hell where you're forced to use Notepad.
Re:Surprised by UnknowingFool · 2014-01-02 03:27 · Score: 2

It does: C-x M-c M-git

--
Well, there's spam egg sausage and spam, that's not got much spam in it.
Re:Surprised by Anonymous Coward · 2014-01-02 03:47 · Score: 0

There is evil: http://www.emacswiki.org/emacs/Evil
Re:Surprised by RyansPrivates · 2014-01-02 03:52 · Score: 0

True, but you can add a decent editor: http://www.emacswiki.org/emacs/Evil

--
If at first you don't succeed... How does that go again? Ah, forget it.
Re:Surprised by Anonymous Coward · 2014-01-02 04:22 · Score: 0

notepad is nirvana.
hell is ed.
Re:Surprised by Anonymous Coward · 2014-01-02 10:28 · Score: 0

Actually for git repositories it is M-x magit-status
Magit is truly worth a try.
See e.g. http://www.masteringemacs.org/articles/2013/12/06/introduction-magit-emacs-mode-git/
Re:Surprised by dkf · 2014-01-02 10:36 · Score: 1

hell is ed.
No, there's also EDLIN, which is a retarded knock-off of ed.

--
"Little does he know, but there is no 'I' in 'Idiot'!"
Re:Surprised by Darinbob · 2014-01-02 11:44 · Score: 1

Oh ya. I could get a lot of work done using ed (the Unix one, not the CP/M one that edlin copied).
Re:Surprised by DaveAtFraud · 2014-01-02 14:44 · Score: 1

teco (PDP-11 and earlier)
Cheers,
Dave

--
They that can give up essential liberty to obtain a little temporary safety deserve neither safety nor liberty.
Ben

The only winning move is to laugh at ESR by 0xdeadbeef · 2014-01-02 02:53 · Score: 0

Doing anything ESR tells you to do also has social and signaling effects damaging to your prospects.

So, Emacs should just keep on truckin' on.

Re:The only winning move is to laugh at ESR by Sri+Ramkrishna · 2014-01-02 07:40 · Score: 1

Why do we not like ESR? (I got my own reasons)

But how exactly? by nashv · 2014-01-02 02:56 · Score: 0

Should we take this to mean that Facebook, and Twitter have vulnerabilities that allow a third-party to usurp control of an account?

I thought modern authentication procedures were solid enough that you couldn't just get access to the account typing a few commands. There had to be more.

--
Entia non sunt multiplicanda praeter necessitatem.

Re:But how exactly? by Desler · 2014-01-02 03:00 · Score: 1

What does that have to do with Emacs and Git?
Re:But how exactly? by Anonymous Coward · 2014-01-02 06:21 · Score: 0

maybe GP was trying to answer the post about skype's twitter/facebook accounts being hacked ?
I'm pretty sure there is a joke to be made out of this mistake and his post wording, but I can't figure it out yet ... There has to be more.

Pretty sure... by Anonymous Coward · 2014-01-02 03:03 · Score: 0

People should just stop using emacs already... :(

Re:Pretty sure... by ebno-10db · 2014-01-02 03:24 · Score: 1

Heretic, apostate, blasphemer! (I can never remember the differences between the three).
Re:Pretty sure... by mellon · 2014-01-02 03:35 · Score: 3, Informative

A heretic uses XEmacs. An apostate doesn't take the time to install Emacs where it is not available, instead using vi. A blasphemer suggests that emacs and vi are essentially interchangeable, denying emacs' uniqueness and primacy. All three prefer emacs; only pagans and barbarians prefer something else.
Re:Pretty sure... by 93+Escort+Wagon · 2014-01-02 03:44 · Score: 1

Heretic, apostate, blasphemer! (I can never remember the differences between the three).
The last two were not games released by Id Software.

--
#DeleteChrome
Re:Pretty sure... by unixisc · 2014-01-02 05:50 · Score: 1

A heretic uses vi. An apostate is someone who previously used emacs, but switched to something else s/he liked better. A blasphemer criticizes emacs
Re:Pretty sure... by Darinbob · 2014-01-02 11:48 · Score: 1

This makes sense. Although I don't think it's heresy anymore to use XEmacs like it used to be. True heresy would be Gosling Emacs.
Re:Pretty sure... by mellon · 2014-01-02 13:22 · Score: 1

Naw, the cultists of gosmacs live in caves in the Utah desert, and haven't been seen in years. They aren't heretics so much as ultra-orthodox.

They anticipated the move by hcs_$reboot · 2014-01-02 03:05 · Score: 1

M-x move-from-bzr-to-github

--
Slashdot, fix the reply notifications... You won't get away with it...

Re:They anticipated the move by Shompol · 2014-01-02 03:28 · Score: 1

C-x M-x M-butterfly

Insufficient Resources by Anonymous Coward · 2014-01-02 03:07 · Score: 2, Insightful

Github doesn't have the resources to host something that bloated.

Re:Insufficient Resources by ebno-10db · 2014-01-02 03:26 · Score: 1

So Github isn't the Eclipse repository?
Re:Insufficient Resources by jmak · 2014-01-02 03:33 · Score: 1

I see what you did there, but Emacs' codebase is actually quite small by today's standards.
Re:Insufficient Resources by H0p313ss · 2014-01-02 04:07 · Score: 1

So Github isn't the Eclipse repository?
Eclipse moved from CVS to git, but is still hosted by eclipse.org

--
XML is a known as a key material required to create SMD: Software of Mass Destruction

annoying by Anonymous Coward · 2014-01-02 03:09 · Score: 0

What has he added to the previous discussion they had about version control months ago on emacs-devel? Does he think the fact he's saying it instead of John Wiegley changes things somehow? rms is going to think to himself, "ah, my good friend Eric Raymond, that paragon of reason thinks this way, so maybe it's time to revisit the vcs again?"

What about Mercurial? by ebno-10db · 2014-01-02 03:15 · Score: 5, Insightful

Since VC wars are almost as much fun as language wars, and I've already donned my Nomex underwear, why not Mercurial? It isn't as popular as git, but it's not going to die either (e.g. Python project uses Hg). It seems that most people or organizations that have actually sat down and evaluated Hg vs. git have chosen Hg. Examples include Google's online repository and Fog Creek's Kiln. Both now also support git, but that's because of demand by users. Of course user demand is, at least from a marketing PoV, important, but why the user demand for git over Hg? Both have technical pros and cons (and fortunately for both the dev teams compete with each other), but Hg has always had a much better command line user interface, better GUI integration, and was well designed from the ground up to be portable, as opposed to a pile of shell scripts and C programs to run on Linux. Arguably git's use on the Linux kernel is a factor, but why? For all its visibility and importance, the Linux kernel is but one FOSS project, and the vast majority of FOSS devs don't work on it.

Now for the statement that some will see as flamebait :-) but which is a sincere observation. I think the difference is the fanboi factor; people who think that git is the choice because it's from Linus, the ultimate cool kid. No, I don't think everyone who uses git does so because they're a fanboi. I suspect the main reason is going with that flow, but it's the fanbois who originally pushed that flow so hard. As your mother used to say, if all your friends decided to jump off a cliff, would you jump too? Vociferous debate welcome.

Sincerely,
Don Quixote

Re:What about Mercurial? by cjjjer · 2014-01-02 03:33 · Score: 1

My thoughts exactly, if an OSS project success has more to do with the VC system that houses it than the developers working on it I feel OSS is doomed. This mentality spits in the face of all the OSS projects that don't use git.
Re:What about Mercurial? by Waffle+Iron · 2014-01-02 03:58 · Score: 2

Of course user demand is, at least from a marketing PoV, important, but why the user demand for git over Hg? Both have technical pros and cons (and fortunately for both the dev teams compete with each other), but Hg has always had a much better command line user interface, better GUI integration, and was well designed from the ground up to be portable, as opposed to a pile of shell scripts and C programs to run on Linux. Arguably git's use on the Linux kernel is a factor, but why?
The network effect explains it. Git probably got an early boost of popularity because of who its author was. This initial momentum was enough to snowball into the most popular distributed RCS. Once it is established, learning curves and database lock-in create a barrier to other alternatives, and they apparently aren't currently "better enough" to prompt people to work through those barriers.
For example, even if Hg has a better CLI than git as you say, I'm sure that just learning and using just the git CLI is easier than filling one's head with both git and Hg knowledge. (In a similar circumstance, I currently have to use both yum and apt. They have similar concepts but different CLIs, and now I have to use a cheat sheet to run almost any command on either one. If I only used one or the other, I could probably keep the common commands straight in my head.)
I doubt that git is going to get knocked out of prominence until someone invents the next major concept in version control. This has happened before: both when Subversion surpassed CVS in buzz factor, and when git surpassed Subversion.
Re:What about Mercurial? by magic+maverick+ · 2014-01-02 04:00 · Score: 1

Funny, I thought much the same about Bzr. Bzr has at least one GUI (bzr-gtk), is better supported on more than just Linux-based systems, is also written in Python, etc.
Unfortunately, Bzr development has apparently stalled (hence the email from esr suggesting moving off bzr to git -- he notes that he would prefer hg, but that Git has basically won). But, bzr does everything I ask of it. I'll be continuing to use it, so long as it continues to work. When it stops, I guess I'll have to find a tool to convert all my shit to Git or whatever, and find replacements for the various tools that I use (e.g. integration into Gedit).

--
HELP MY ACCOUNT HAS BEEN HACKED BY AN ILLIBERAL ART STUDENT SET TO DESTROY THE INTERWEBZ!
Re:What about Mercurial? by daveisfera · 2014-01-02 04:05 · Score: 1

The discussed email from ESR states that git has won the mindshare war and that Mercurial is "is not looking real healthy these days". So while I agree with everything you said, it appears that the general opinion does not.
Re:What about Mercurial? by Anonymous Coward · 2014-01-02 04:34 · Score: 0

Those OSS projects are spitting in their own faces.
Re:What about Mercurial? by bledri · 2014-01-02 05:44 · Score: 1

Since VC wars are almost as much fun as language wars, and I've already donned my Nomex underwear, why not Mercurial?...
Because mercury causes autism!

--
Some privacy policy Slashdot.
Re:What about Mercurial? by Yunzil · 2014-01-02 05:46 · Score: 1

And git causes brain damage.
Or possibly is the [i]result[/i] of brain damage.
Re:What about Mercurial? by Chemisor · 2014-01-02 06:39 · Score: 0

For me at least, the deal breaker is that Mercurial is written in Python. Scripting languages are something you use to make a duct-tape patch until you have a real application. Performance difference is particularly noticeable in an infrequently run program. Loading Python creates a visible pause long enough to annoy. Learn C++ already, people!
And then, of course, Mercurial does not do anything better than git. If you think hg's command line is easier to use, it is only because you are used to it. I find git's interface far more intuitive and powerful. Git is faster, has more and better features, and results in smaller repositories. Why would anybody consider an inferiour also-ran like Mercurial? bzr at least offered a different approach that you could argue about being better or worse. Mercurial is little more than a really bad git implementation.
Re:What about Mercurial? by Anonymous Coward · 2014-01-02 07:02 · Score: 0

Really, why is git so popular?
Linus. That is all.
Git is no different from Hg, Clearcase/Synergy (VOBs!), Bitkeeper or other distributed VCSs. And really CC with remote/offline vobs were sort of the beginning of distributed VCSes. And you will always get into a merge mess eventually on any of these systems. Linus had to move from Bitkeeper when they went closed (also when Bz was the defacto standard for many FOSS projects at the time) and wanted to "roll his own". Everyone jumped thinking it was another linux revolution (Git that is) and we are here today cause everyone wants to be have a knowledge base (cause git and Hg have steep learning curves) and on the same bandwagon.
IMO Hg does appear to have the edge on usability, ease of use, and consistency.
Re:What about Mercurial? by Phillip2 · 2014-01-02 07:36 · Score: 1

Why not mercurial? Two main reasons, I can think of. Firstly, some of Emacs (ELPA) is already hosted on git. And, secondly, because Emacs support for git (magit) is way ahead of that for mercurial.
ESR gives a third reason, which is that git has won and mercurial is not in great health, and may end up in the same position as bzr. Maybe, maybe not, but it's a factor.
Re:What about Mercurial? by Sri+Ramkrishna · 2014-01-02 07:44 · Score: 1

Linus doesn't manage the project anymore. Honestly, though, a lot of people like it because it's just really fast.
Re:What about Mercurial? by Anonymous Coward · 2014-01-02 11:01 · Score: 0

And git causes brain damage.
Or possibly is the [i]result[/i] of brain damage.
Do you know what one of the signs of brain damage is? Here's a [i]hint[/i].
Re:What about Mercurial? by Nivag064 · 2014-01-02 11:13 · Score: 1

Linus Torvalds knew about Mercurial (though it was started at about the same time s git), but he still chose to complete the implementation of git. You can be sure Linus thought very carefully about he needed for the Linux Kernel before he did so. So git was superior to Mercurial for his needs. Now many more projects chose git for large projects with a distributed user base, so a large number of other developers find it best for them too. Amongst other things, git handles branches, and branch merging, a lot better & far faster than anything else.
see also:
http://felipec.wordpress.com/2011/01/16/mercurial-vs-git-its-all-in-the-branches
http://programmers.stackexchange.com/questions/96933/why-did-git-get-so-much-hype-while-others-dont
http://beta.slashdot.org/story/85783
Re:What about Mercurial? by shutdown+-p+now · 2014-01-02 14:02 · Score: 1

Personally, I do like Mercurial more. However, it is not substantially different from git, and in the world where everyone and their mother now use git (and GitHub), well... sometimes you go not with the best choice, but with a "good enough" one that's also popular - it makes it easier to support in the future, and for other people to work with it. A good example of a similar "good enough that alternatives don't matter" thing is C, except that there it has been entrenched for so long that most people don't even remember those alternatives (like Modula-2). I suspect git will end up the same eventually.
Re:What about Mercurial? by Anonymous Coward · 2014-01-03 05:34 · Score: 0

And why is nobody bothering with bzr development any more? Because it is obvious to everyone involved that no matter how much effort is invested or how painful git is to use, git will still have the mindshare and userbase. If there is a future to bzr, it is as a saner front end to git repos.
Re:What about Mercurial? by Yunzil · 2014-01-03 10:31 · Score: 1

I know. It's because I used git.
Re:What about Mercurial? by greg1104 · 2014-01-04 08:24 · Score: 2

Mercurial is missing a few key features that make it less appropriate for solving some difficult collaboration problems, and some of those turn out to be important to people outside of Linux kernel development too. That's the technical part underneath what you're dismissing as a fanboy phenomenon.
Allowing octopus merges and making it easy to rewrite/rebase local branches are two such important features. The way those fit together into git's remote tracking branch concept is a particularly useful mental model for widely distributed development. And the way git (but not Mercurial) forces explicit branch naming and sharing gets people thinking in a way that usefully leads toward using these features for collaborative development. Mercurial vs Git; it’s all in the branches covers most of the important area usefully.
Basically, git includes some weird features that were built specifically for the style of distributed development done by the Linux kernel. But those turn out to be similarly powerful for other widespread collaborative software efforts too. These things aren't really appreciated by people until they've used git seriously for a while, and therefore they don't show up on most of these formal "which DVCS should we switch to" documents done by people still evaluating their options. That link I just referenced goes over how Google completely missed out on that in their comparison. You can't just compare the opinion of new users. The interesting thing to compare is what git is capable of on a project with some number of serious git users involved.
Once you've gotten used to things like git's remote tracking branches, good rebasing practices for code sharing, and malleable history when in tough spots, it's impossible to take Mercurial seriously for some of those jobs. Eventually Mercurial got some of the rebasing features, but by that point it had already lost quite a bit of the mind share war. They still are struggling with how the branch name model mismatches what some people want.

Can't we settle this like geeks? by fuzzyfuzzyfungus · 2014-01-02 03:15 · Score: 4, Funny

Why make a contentious choice between bzr and git when we could implement a new, metalevel distributed revision control system that supports revision control across multiple revision control systems, each potentially running on multiple nodes?

Given sufficient time, I'm sure we can generalize away any petty disagreements!

Re:Can't we settle this like geeks? by Anonymous Coward · 2014-01-02 04:16 · Score: 0

I thought that was the point of bzr already.
(http://www.stationary-traveller.eu/pages/bzr-a-retrospective.html)
Re:Can't we settle this like geeks? by Anonymous Coward · 2014-01-02 05:46 · Score: 0

I know you're being funny, but bzr actually is that already. One of the reasons it's not maintained better is that there is lots of code for support of foreign version control systems, making it difficult to maintain. The good news is that all the current users will still be able to use the same UI; just the backend will be different.
dom
Re:Can't we settle this like geeks? by slackergod · 2014-01-02 07:00 · Score: 1

Mercurial is actually making some strides in that direction... the hg-git mercurial plugin lets you push/pull from git repositories, and it transparently integrates itself into the mercurial command line, not as a separate tool.
Re:Can't we settle this like geeks? by DoofusOfDeath · 2014-01-02 07:08 · Score: 1

Why make a contentious choice between bzr and git when we could implement a new, metalevel distributed revision control system that supports revision control across multiple revision control systems, each potentially running on multiple nodes?
Good call. I'll get started on the Emacs macro right away!
Re:Can't we settle this like geeks? by Anonymous Coward · 2014-01-02 08:16 · Score: 0

git has those, too. However, git hg is actually something that can work better than, say, git svn, because well... Hg doesn't suck (nor does git).
Re:Can't we settle this like geeks? by dotancohen · 2014-01-02 12:15 · Score: 1

I hate to be the one to tell you that it already exists:
http://www.fogcreek.com/kiln/

--
It is dangerous to be right when the government is wrong.
Re:Can't we settle this like geeks? by IwantToKeepAnon · 2014-01-02 15:20 · Score: 1

http://xkcd.com/927/

--
"Happy families are all alike; every unhappy family is unhappy in its own way." -- Anna Karenina by Leo Tolstoy

The usual ESR self-aggrandizement by mvdwege · 2014-01-02 03:23 · Score: 4, Interesting

Apparently Eric has decided he has been out of the public eye too long, as he posts yet another self-aggrandizing screed on a mailing list.

Seriously, after the kernel configuration debacle and his hysterical rants on the Fedora list, does anyone take this man seriously anymore? Look at how he represents himself: an expert on source control systems, whose highest achievement is moving troff to a git repo. It's kconfig all over again.

--
"I know I will be modded down for this": where's the option '-1, Asking for it'?

Re:The usual ESR self-aggrandizement by NoNonAlphaCharsHere · 2014-01-02 03:39 · Score: 1

Rogers on that. I had a Bob Metcalfe flashback when I read the headline.
Re:The usual ESR self-aggrandizement by Anonymous Coward · 2014-01-02 04:17 · Score: 0

But he's a level 30 wizard and alpha mall-ninja! We ignore this lethal baked potato at our peril.
Re:The usual ESR self-aggrandizement by Anonymous Coward · 2014-01-02 05:24 · Score: 0

++1.
Plus, it must be a SUPER slow news day if *this* is /. worthy.
Re:The usual ESR self-aggrandizement by DoofusOfDeath · 2014-01-02 07:10 · Score: 1

I don't know anything about ESR's recent history, but I learned a lot from reading his book, The Art of Unix Programming.
Re:The usual ESR self-aggrandizement by Anonymous Coward · 2014-01-02 11:07 · Score: 0

++1.
error: lvalue required as increment operand
Re:The usual ESR self-aggrandizement by Anonymous Coward · 2014-01-02 11:07 · Score: 0

Then you really haven't read much of the UNIX canon. All ESR has done is to summarise the canonical literature into one book, often missing the point of the original work. You can still pick up most of the canonical works (Kernighan, Plauger, Pike, Stevens, ...) really cheap second hand. The BSD distribution also has a set of essays, one per user-space system, explaining the system's design and implementation (there are books covering the kernel). It's a shame that this practice wasn't carried forward to today, about the only people who do it anymore are Rusty Russell in his HOWTOs and Lennart Poettering on his blog site.
Ironically some of the best modern programming books are from Microsoft, such as McConnell's "Code complete".
Re:The usual ESR self-aggrandizement by shutdown+-p+now · 2014-01-02 14:03 · Score: 1

Seriously, after the kernel configuration debacle and his hysterical rants on the Fedora list
Can you link to those? ESR may be a clown, but he is an entertaining one to watch.
Re:The usual ESR self-aggrandizement by Anonymous Coward · 2014-01-02 14:10 · Score: 0

http://rationalwiki.org/wiki/Eric_S._Raymond
The writeup is not particularly great; the main value of this is in the assortment of links to Eric's own blog, where he is quite open in his insanity.

emacs on bzr? by csumpi · 2014-01-02 03:25 · Score: 1

It's baffling that such a large project would use bzr as source control. Bzr doesn't have branching. Before you yell at me, I know, there is a command to create a "branch", but it is essentially a copy of the whole repo. Unusable for any project larger than a couple files. I would not be one bit surprised if it in fact was dying.

This is the result of picking a tool based on "what's trending this hour", "their website looks better", "look, they have an ipad app", "the ceo's son uses this" etc..

Happens way too often. Instead of doing some research. Sleep in the bed you made.

The real question is about Emacs by hcs_$reboot · 2014-01-02 03:28 · Score: 4, Interesting

Actually, is the dying one being Emacs, instead? That would be sad - but I wonder how younger generations do appreciate Emacs which is quite tricky to get used to - while so convenient and still unequaled in 2014 when it comes to some features (hyper customization thanks to (e)Lisp, M-x features with completion, intra-shell/processes, apropos, ^x-( ), languages modes ...). It seems the major IDE or text editors did not even try to reproduce the main features of Emacs - do they ignore the Emacs logic because they have no knowledge of it, or do they simply feel those features are obsolete? For once, nobody reinvents the wheel, which is going to die eventually. Sad, really.

--
Slashdot, fix the reply notifications... You won't get away with it...

Re:The real question is about Emacs by Greyfox · 2014-01-02 03:50 · Score: 2

People don't use a lot of the old tools because they're not aware of the old tools. You never see anyone use Lex and Yacc, for example. Slightly more people seem to know about gdb and efence, but only slightly. I've been talking to a relative as he's going through a CS program and most of his work has been either Java/Eclipse or C++ on a Microsoft Visual C++ platform, with not even the cursory look at the UNIX tools that were common back in the '80s.

--
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Re:The real question is about Emacs by Warbothong · 2014-01-02 04:18 · Score: 1

I've been using Emacs for a couple of years now and think it's pretty good. The most important bug IMHO is its lack of concurrency. Connecting to remote machines with TRAMP is great, but having the whole app become unresponsive for a period is jarring. Also, I have to run GNUs from a separate process so I can actually do some work while it refreshes.
Giving ELisp lexical scope is a good start in this direction, since it allows for fully encapsulated closures which won't trample over each others' namespaces. Once that becomes pervasive, it wouldn't be too (conceptually) difficult to add a concurrent event handler to fire off asynchronous functions like node.js.
Re:The real question is about Emacs by Anonymous Coward · 2014-01-02 04:45 · Score: 1

Emacs has to die. At least it should be castrated so these byzantine key combos are no longer replicated in other applications. When I tried out Matlab's internal editor I sat there yelling at it, because all the standard keys would not work or produce unexpected results. Then someone told me that the keyboard shortcuts are from Emacs. The expectation that users memorize strings of key presses with no visual support at all is misguided and premodern.
Re:The real question is about Emacs by bfr99 · 2014-01-02 05:00 · Score: 1

My experience is that programs and computer languages can not be enhanced indefinitely. In fact they reach a peak and further changes only make them more complex and less reliable. Some believe C++ passed its peak long ago and emacs may be in that situation as well.
Re:The real question is about Emacs by mangobrain · 2014-01-02 05:10 · Score: 1

This; a million times this. The problem is exacerbated by the long-running trend towards computers as consumer appliances, instead of specialised tools. I grew up coding in BASIC on an Acorn Archimedes, which was state-of-the-art at the time; when my family finally "upgraded" to a Win98 PC, the second thing I noticed (the first being the massive jump in performance) was the lack of printed reference manuals and built-in development tools. When I was at university, the teaching language was Object Pascal (via Delphi), I had a vague knowledge of Linux due primarily to the social circles I moved in, and I eventually ended up doing the bulk of my work in C++ on Solaris for the simple reason that the UNIX labs on campus always had plenty of free machines (which could not be said of the Windows labs). This rekindled my love of plain-text editors and the command line, to the extent that I still bind F12 to spawn terminals on my Linux machines (any RISC OS user will know where I'm coming from ;) ).
Had my background and social set been different, I could very easily have graduated knowing only how to do RAD on Windows via graphical IDEs. Not really fitting for a comp sci course with software development modules.
Re:The real question is about Emacs by Anonymous Coward · 2014-01-02 05:12 · Score: 0

all the standard keys would not work or produce unexpected results
What standard are you talking about? Microsoft's?

Different standards come with different sets of expectations.
Re:The real question is about Emacs by hey! · 2014-01-02 05:26 · Score: 1

Lex and YACC are awesome tools, but they're quite special purpose when compared to something like an editor. Also these days its much less common to devise special purpose languages for data interchange tasks; tasks I would have used lex and yacc for twenty-five years ago I'd do in XML or JSON today.
It took a long time to wean myself off of Emacs and onto Eclipse, but the thing that finally did it for me was refactoring support. The one thing I still use Emacs for is poking around very large data files, which it does better than anything. Some of the things I might use PERL for, if they're one-off tasks, I'll do in Emacs because the interactivity outweighs repeatability.

--
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Re:The real question is about Emacs by ebno-10db · 2014-01-02 05:27 · Score: 2, Insightful

Emacs ... byzantine key combos
What are you talking about? It's not Emacs' fault that some later programs decided to break compatibility.
Re:The real question is about Emacs by Anonymous Coward · 2014-01-02 05:38 · Score: 0

I might understand a complaint about things like ^A, ^E for Home, End (bash supports both, don't know Matlab) but what is the common visual counterpart of ^K or of vim's D? Shift End and Shift Home followed by a ^X are not visual and are slower. Their only advantage is that they are consistent among many applications of Windows and Linux (OSX too?). But there are always shortcuts that must be learned or done without.
BTW, I concede that Shift Home + ^X is easier to discover than ^0 ^K but my emacs 24 also supports the standard Windows keybindings. I don't know if it's built in or added by some .el loaded by my .emacs. Too much history to dig through :-)
Re:The real question is about Emacs by Cid+Highwind · 2014-01-02 07:40 · Score: 2

It is absolutely Emacs' fault that that the default keybindings are still set up for MIT Lisp machines (Super and Meta? In 2014? Really??).
It is also emblematic of the problems within Emacs' user community that they can say with apparent seriousness that the problem is every keyboard and OS since nineteen-seventy-fscking-five "breaking compatibility" with Emacs, instead of their own failure to adapt to a changing environment.

--
0 1 - just my two bits
Re:The real question is about Emacs by CronoCloud · 2014-01-02 08:37 · Score: 1

What standard are you talking about? Microsoft's?

No, IBM's
http://en.wikipedia.org/wiki/IBM_Common_User_Access
Re:The real question is about Emacs by CronoCloud · 2014-01-02 08:41 · Score: 1

The real problem is that the Emacs userbase/developers/RMS uses computers in the same manner as someone might at MIT in 1975.
They simply don't know, kind of like how the non-jabber pidgin protocols didn't receive attention or updates to match the features of the original programs because the pidgin devs were all using finch on the command line, didn't use X and didn't use the other protocols.
Re:The real question is about Emacs by TangoMargarine · 2014-01-02 09:32 · Score: 1

I learned (the basics of) emacs when I was hired into a Java development team at my first job out of school 2 years back. Other than me, 9 of the other 12 people were vi-heads, but 2 of the team leads used emacs, and I had seen it used before in a class, so I went with it.
While it took me a long time to get used to it and fix several glaring default-config bugs (I still can't explain why nobody has made the system clipboard interact properly with the kill ring out of the box), the multiple window paradigm and command line inside were the initial draws.

--
Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF
Re:The real question is about Emacs by ebno-10db · 2014-01-02 10:20 · Score: 1

It is absolutely Emacs' fault that that the default keybindings are still set up for MIT Lisp machines
Then how come I have no trouble using Emacs on a bog standard laptop?
Re:The real question is about Emacs by Anonymous Coward · 2014-01-02 11:25 · Score: 0

As a longtime emacs fan I would plug my favorite editor of the day, sublime text. It gets most of the features you mention(extendable with python, autocomplete commands, coding patterns, language modes, intra shell stuff), plus some awesome additional ones (multiple cursors, minimap).
Its not open source, though.
Re:The real question is about Emacs by jrumney · 2014-01-02 13:31 · Score: 1

Shift Home to select back to beginning of line is built in to Emacs and enabled by default. Ctrl-X to cut is enabled by selecting "Use CUA keys (Cut/Paste with C-x/C-c/C-v)" from the Options menu. The talk about Emacs being difficult to use for beginners (especially coming from people promoting vim as an alternative) ceased being relevant 15 years ago when a bunch of keybindings was modified to fit with modern convention. Home going to beginning of line instead of beginning of buffer, F1 being bound to Help by default, Shift-Insert, Ctrl-Insert, Ctrl-Delete being given their CUA bindings by default being some of the changes from that time.
Re:The real question is about Emacs by jrumney · 2014-01-02 13:48 · Score: 1

Emacs is basically a counterexample to your experience. Released versions of Emacs are very stable. I haven't seen a non-development version of Emacs crash since the 1990's. And there are always new features coming along from the underlying platform that are useful additions to Emacs (if a bit late getting to Emacs). If Emacs had been declared complete at the last release, I wouldn't be able to use it to edit and manipulate files on my Android phone from my desktop. It wouldn't support filesystem notification APIs or ACLs. And looking at Emacs now, vs Emacs from 24 years ago when I first started using it, from the user's perspective it is much less complex and more reliable now than it was then. And since most of the features are a self contained lisp package, it really isn't any more complex for developers either, despite the increased functionality.
Re:The real question is about Emacs by jrumney · 2014-01-02 13:57 · Score: 1

I still can't explain why nobody has made the system clipboard interact properly with the kill ring out of the box
I think this is one of those things that falls under the category of "for some definition of properly, which may vary from your definition". Would you care to expand on what your expectation is, as recent versions work perfectly well for me. The main area of contention now is the emulation of X's primary selection mechanism (which is separate from the clipboard) on platforms that do not support it. On Windows, this used to use the clipboard, which caused valid complaints from users that merely selecting text in Emacs causes the clipboard contents to be clobbered. Now that it doesn't clobber the clipboard complaints from users that became used to pasting into other programs after merely selecting in Emacs start to come in.
Re:The real question is about Emacs by TangoMargarine · 2014-01-03 02:52 · Score: 1

By default, the kill ring and clipboard are completely separate, which seems a bit weird. I would think it would be easy enough to just copy the top thing on the ring to the clipboard (although the other way might be a bit more problematic). And the X selection when pasted in truncates after a certain point. And nothing I did short of mouse-selecting text (which has its own formatting problems) could get text out of emacs properly either. After a couple months of fiddling with emacs settings and trying an external utility or two, I finally found xsel, which luckily was installed already on our work machines and is available in the Ubuntu repos.
I would have accepted either the clipboard or X selection working, but they were both broken in different ways and I couldn't find any obvious ways to fix them online *that actually worked* until finally xsel, which is admittedly a kludgy solution as you're spawning a thread every time you make a selection (I assume).
I believe this was emacs 22 or 23. After 20 years on Linux, this still isn't properly supported? Wow.

--
Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF
Re:The real question is about Emacs by TangoMargarine · 2014-01-03 02:54 · Score: 1

In case it wasn't clear, this was on Linux. I find the idea of opening emacs sans -nw rather heretical and pointless so short of Cygwin, I wouldn't use it on Windows.

--
Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF
Re:The real question is about Emacs by jrumney · 2014-01-03 16:33 · Score: 1

I find the idea of opening emacs sans -nw rather heretical and pointless

Here lies the source of all your problems. You are explicitly starting Emacs without X support, then complaining that X features are not working perfectly (because they are handled by the xterm you are running emacs in, not by emcs itself). Why not just start Emacs in its own window, and turn off any newfangled features like menu and toolbars that you don't like?
Re:The real question is about Emacs by TangoMargarine · 2014-01-04 08:26 · Score: 1

Ha! When you say it like that, I just sound idiotic now don't I...

--
Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF

Don't leave us hanging by Anonymous Coward · 2014-01-02 03:31 · Score: 0

a version control system built into

Built into what?

What prospects of Emacs left to be damaged? by Anonymous Coward · 2014-01-02 03:35 · Score: 4, Insightful

Is there still any prospect at all? I left 5 years ago because they stopped improving anything for a decade.

A decade ago it was comparably decent IDE for Java and C++, today it's nothing thanks to incomplete project management UI, incomplete file tab support, and over-reliance on ctags which can't really understand syntax and parse things properly, and their inability to work on on-the-fly static code-analysis, which requires basic threading support that (still) isn't done.

the same could be said for Vim as well. While both remain very efficient text editors, they no longer matter because it's far more important to study and write correct code than to writing code faster, and other IDEs have improved on such parts drastically these years.

Re:What prospects of Emacs left to be damaged? by bfr99 · 2014-01-02 04:57 · Score: 1

I seldom see this sentiment expressed but you are absolutely correct. Coding, text editing and compilation are the least important part of software development and may ultimately be automated away. In my view those who brag about their mastery of obscure keystroke combinations are missing the boat. Similarly those who brag about efficiency (speed or size) instead of correctness are scary for a slow program may still be useful but an incorrect one may be dangerous.
Re:What prospects of Emacs left to be damaged? by Anonymous Coward · 2014-01-02 07:35 · Score: 0

Whilst I agree in principle, I see a lot of hardcore Scala developers using Emacs/Ensime - which seems to outsource the static code-analysis to a separate process (the Scala Presentation Compiler).
Re:What prospects of Emacs left to be damaged? by Sri+Ramkrishna · 2014-01-02 07:52 · Score: 1

I wouldn't say VIM hasnot improved. It has improved quite a bit and is quite modern. They even have drop in packages now that automatically gets things set up, it also has a lot of hte modern, new features. That said, have you tried gedit?
Re:What prospects of Emacs left to be damaged? by Anonymous Coward · 2014-01-02 08:57 · Score: 0

Emacs does have some shortcomings. However, it has killer features not found in, say, Eclipse:
* I can dedicate a slice of my screen to an emacs window and use the remaining screen space for other useful activities including online reference manuals.
* I can run emacs in a text terminal. I do it every day, in fact.
* M-x compile integrates nicely with build scripts and tools. With Eclipse, you need to wade in advanced dialogs and don't know the exact equivalents on the command-line if you want to automate stuff. Eclipse needs plugins for things so you depend on the right ones to be available because not every user is expected to be able to write ad hoc plugins.
Re:What prospects of Emacs left to be damaged? by jrumney · 2014-01-02 14:19 · Score: 1

The same is possible using cppcheck or clang for C/C++, and many other checkers for other languages and file formats.
Re:What prospects of Emacs left to be damaged? by WWWWolf · 2014-01-03 00:24 · Score: 1

Is there still any prospect at all? I left 5 years ago because they stopped improving anything for a decade.
Emacs still has plenty of awesome projects going on, just that they're bloody haphazardly organised. You need to really go look for them and sometimes some minor assembly is required.
For example, the single most awesome Emacs package right now is Org-Mode, which especially speaks to me as a writer (a lot of writers swear by Scrivener, but screw it, we have a better open source alternative in Org). You'll note that it's developed outside of Emacs proper with its own release schedule. You'll note that if you want the newer versions (which aren't always required, the ones shipped with Emacs itself are usually pretty decent) you need to get the git version or use the one from Emacs ELPA package manager, which in itself is still kind of in early stages and not many projects make themselves available through it (translation: I use a whole bunch of emacs extensions, but none of them are available through ELPA). If you want nifty extensions for Org, you really need to hunt random files all around the interwebs and pray they actually work in current version of Org.
This sort of disorganisation is actually just what Emacs has been all about for decades. The core Emacs devs don't innovate that much (well, at least they do add cool new features in major releases, which is a good thing), and just package the outside contributions whenever they can. There's all sorts of cool shit going on, but you just wouldn't always know where to find them.
(That said, if you want to develop Java or C++, NetBeans just blows Emacs off the water.)
Re:What prospects of Emacs left to be damaged? by Anonymous Coward · 2014-01-04 06:55 · Score: 0

You should check out packages like https://github.com/Sarcasm/irony-mode or https://github.com/Andersbakken/rtags

Emacs is awesome!! by Andover+Chick · 2014-01-02 03:36 · Score: 1, Funny

Just wanted to say, unrelated to the GitHub discussion, that Emacs is awesome! I've been using it since the mid-80s on 2400 baud modems and have been a big fan of Stallman and the boys. There are things I'd like, for example a GUI object browser. But overall it is f-a-n-t-a-s-t-i-c!

Re:Emacs is awesome!! by Anonymous Coward · 2014-01-02 07:58 · Score: 0

I can see it now:
vi editing emacs git entries, git running on a Linux VM on virtual box o Windows 8.
Head explodes.... Fanboi wars begin.
Re:Emacs is awesome!! by Krishnoid · 2014-01-02 08:51 · Score: 1

There are things I'd like, for example a GUI object browser.
I know Emacs has a common-lisp extension library, but I'm not sure what you're referring to by 'objects' in Emacs.
Re:Emacs is awesome!! by Anonymous Coward · 2014-01-02 09:32 · Score: 0

I'm glad you like it, but I don't like key combinations like f-a-n-t-a-s-t-i-c.
Re:Emacs is awesome!! by Andover+Chick · 2014-01-02 09:32 · Score: 1

For example, say I'm in Netbeans. On the left margin there is typically a panel listing packages, classes, methods in a collapsible tree GUI. So if I've instantiated any of the classes I can browse thru their definitions in the packages. Sometimes having a GUI is good.
Re:Emacs is awesome!! by Anomalyst · 2014-01-02 10:21 · Score: 1

I'm glad you like it, but I don't like key combinations like f-a-n-t-a-s-t-i-c.
hmmm, what would the actual result of that metakey sequence be?

--
There is no right to feel safe thru security vaudeville at the expense of everyone's freedom, privacy and tax money.
Re: Emacs is awesome!! by Anonymous Coward · 2014-01-02 18:28 · Score: 0

ECB (emacs code browser) package does this nicely.
Re: Emacs is awesome!! by Andover+Chick · 2014-01-03 02:59 · Score: 1

Nice. Just installed it. Thanks!!!!!

No, it doesnt by nurb432 · 2014-01-02 03:52 · Score: 1, Troll

It needs to move to /dev/null Worthless piece of bloated garbage. Its 2014, it has no place in the modern world.

--
---- Booth was a patriot ----

Re:No, it doesnt by Anonymous Coward · 2014-01-02 04:43 · Score: 0

i use emacs all the time and I agree.
do you think there is any viable alternative?
Re:No, it doesnt by Andover+Chick · 2014-01-02 04:58 · Score: 1

Just like the works of Bach and Mozart need to be trashed, they're old and bloated... Just like modern songs by the Black Eye Peas are sooo much better than say Jesu Joy of Man's Desiring or Piano Concerto #21...

Emacs is an OS by duckgod · 2014-01-02 03:54 · Score: 1

Doesn't it have a version control in it? Possible no one has found it yet. Anyways I know mere text editors like VIM can do just fine on Mercurial.

Re:Emacs is an OS by munch117 · 2014-01-02 07:53 · Score: 3

Like many things, Emacs doesn't have version control as much as it interfaces or wraps it. You know, dired wraps /bin/ls (and mv and rm), compile wraps e.g. /usr/bin/make, tramp wraps ftp and grep wraps .. um .. grep. And vc wraps version control:
;;; vc.el --- drive a version-control system from within Emacs ;; Supported version-control systems presently include CVS, RCS, GNU ;; Arch, Subversion, Bzr, Git, Mercurial, Monotone and SCCS (or its ;; free replacement, CSSC).
Emacs is the glue that binds together all the little tools into a more powerful whole. And not just Unix tools, e.g. I wrote a function (3 lines of elisp) that launches Windows Explorer with the current file pre-selected. On a Mac the same key combo launches Finder. You seriously underestimate Emacs by calling it a mere OS...
By the way, I don't use vc.el myself. Never have. Nor do I use Emacs to read mail. Unlike other editors of more monolithic design, you don't pay for what you don't use.

The problem is Emacs, not bzr by Anonymous Coward · 2014-01-02 04:28 · Score: 0

Emacs simply was unable to come up with any innovation or anything that would make it attractive for new users since some time in the 90ies. Instead they had a huge shit-storm going on over XEmacs vs Gnu Emacs and they probably still have not resolved that either.
Let some elderly developers have fun with anachronistic software that already has become rather irrelevant.

Re:The problem is Emacs, not bzr by hey! · 2014-01-02 05:53 · Score: 2

Why should it innovate? Emacs is roughly as good at being Emacs as it is likely ever be.
I became disenchanted with Gnome and KDE, not because they did new things, but because they couldn't do those new things without undermining what I liked about them. As for emacs, the world may have passed it by, but it probably has more users today than when I first learned it in the 1980s. That's healthy enough for an ongoing project. It doesn't have to, say, beat Eclipse at being an IDE, emacs has to meet the needs of its users. The fact that other, somewhat different projects are successful doesn't make Emacs a failure.

--
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Re:The problem is Emacs, not bzr by Sri+Ramkrishna · 2014-01-02 07:55 · Score: 1

Which would be exactly the situation GNOME and KDE would have been in, a lifeless project because it wasn't willing to make any changes thatwould keep up with the modern day.
Re:The problem is Emacs, not bzr by hey! · 2014-01-02 08:19 · Score: 1

Projects should make changes to meet the needs of their users, not to "keep up with the modern day".

--
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Re:The problem is Emacs, not bzr by Sri+Ramkrishna · 2014-01-02 10:19 · Score: 1

You won't have any users if you don't keep up. Remember each new generation of users have different expectations of what their software does. Today's kids for instance, grow up on touch interfaces more than anything else so as they become older they'll be more familiar and work more efficiently with something similar. If you only catered to the "Unix" crowd for instance, these folks are pushing their mid 40s or higher. If you still want to be around, you're going to have to occasionally make changes.
Re:The problem is Emacs, not bzr by hey! · 2014-01-02 11:27 · Score: 1

Strawman argument. I didn't say "never make changes". I'm talking about making changes just to be seen as innovative or keeping up with other projects.
If you try to be "creative" or "innovative", the result is usually a disaster. You need to struggle with what the user is struggling with, and make that the driver of change rather than change for its own sake or because other projects are changing.
I have no problem with emacs changing, as long as it still remains emacs and doesn't try to become eclipse or something unrecognizable as emacs; it would be better to start a whole new project from scratch than to stop serving people who use emacs for what it is. Gnome made that mistake with Gnome 3, which drove many users to Mint, XFCE or even OSX. The ambition of the developers was admirable, but the result had many of us voting with our feet.

--
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.

Hate to go completely off-topic, here... by Slartibartfast · 2014-01-02 04:36 · Score: 2

But, while ESR is likely right, my kneejerk response is to say, "No!" Why? Because ESR is such a freaking windbag, who's so damn convinced of his own moral and intellectual superiority. His whole schtick gets really tiresome after a while.

$.02.

Why chase fads? by Anonymous Coward · 2014-01-02 04:57 · Score: 1

Why chase these tool fads? Today it's git, tomorrow it will be something else. You end up spending more time migrating from one fad to another than getting any work done. Make, ant, maven, whatever - it's always something new to chase. The velocity of change has increased to the point it's not feasible to keep up with fads any longer. From Make to ant was several generations, and from ant to maven was only a few years. From sccs/rcs to svn was a few generations with cvs in between, but from svn to git was only a few years. Will we start changing tools every few months? Weeks? Days?

I could make the same point about Tomcat / Glassfish / whatever J2EE container is the fad right now.

All the time spent reinventing the wheel could be spent making one toolchain better.

Re:Why chase fads? by Anonymous Coward · 2014-01-02 05:06 · Score: 1

Because if people just used what works to solve real problems, unemployment would be in the 60-70% range. This is what technology would allow, and the unemployed people could still have the same standard of living as before. This is what technology is supposed to do. But because humans are defective, they want other people to suffer as much as they do and insist that everyone must "work". That the work is nothing more than theater for many people doesn't matter. It's the show that counts.
There is a reason why bureaucracies are getting bigger and bigger, it's an excellent way to create "jobs". The social cost of not accepting the fruits of technology is creating a police state where people spy on each other because there's nothing else to do.
Re:Why chase fads? by HBI · 2014-01-02 05:19 · Score: 1

I agree entirely with the AC.

--
HBI's Law: Frequency of calling others Nazis is directly correlated with the likelihood of the accuser being Communist.
Re:Why chase fads? by Anonymous Coward · 2014-01-02 11:32 · Score: 0

AC here, watch this:
http://www.youtube.com/watch?v=hdr_9TVXx8g
Let me know if you see where I'm getting at...
Re:Why chase fads? by shutdown+-p+now · 2014-01-02 14:19 · Score: 1

If reinventing the wheel makes it more round and helps you go much faster, you'd be foolish to not do it. Infrastructure investments like that often have the highest ROI because everyone in the industry benefits.
And if you truly don't understand why svn was more productive than cvs, and why git is more productive then svn, then I pity you.

The Emacs userbase is still growing by ciaran_o_riordan · 2014-01-02 05:17 · Score: 4, Interesting

> I wonder how younger generations do appreciate Emacs

Someone said that to me in 2002. I was a new Emacs user then, and I'm still using it now.

Debian's package install stats suggest the Emacs user base is steadily growing:

http://qa.debian.org/popcon-graph.php?packages=emacsen-common

And the developer mailing list is very active and high-quality:

https://lists.gnu.org/archive/html/emacs-devel/

However, Hip-Hop's future is looking less certain:

http://www.theonion.com/video/there-are-people-in-world-who-are-concerned-about,32163/

--
Expert in software patents or patent law? Contribute to the ESP wiki!

Interesting reason... by Aikiplayer · 2014-01-02 06:12 · Score: 1

The reason he gives for wanting to switch is interesting. It's not for any technical reason (bzr still works); it's to attempt to stay relevant. I think it's odd that the relevance discussion is centered around the SCM tool used to keep the source in and not emacs itself. Others have made the point that efficiently using multiple SCM systems is a pain, so perhaps there's something there. "In practice, I judge that sticking with bzr would have social and signaling effects damaging to Emacs's prospects." I agree with the change but the fundamental reason is odd to me and has a little PHB feel to it.

Python should do the same. by jcdr · 2014-01-02 06:54 · Score: 1

For the same reasons.

Re:Python should do the same. by munch117 · 2014-01-02 08:06 · Score: 1

What reasons? CPython uses Mercurial, which is doing just fine, despite what ESR may think. Let anyone who believes in choosing tools based on marketshare remember that at one point Visual Source Safe was the market leader by a large margin.
Let's not be so hasty to devolve into monoculture.
Re:Python should do the same. by jcdr · 2014-01-02 12:39 · Score: 1

In more than 20 years, this is the first time I hear about VSS. Hopefully since according to Wikipedia this was a Windows only product since this time. RCS was the dominant tool in my field of work when I started.
You can always make things different, but this add complexity for the others. having something in common help the grow of communities. Mercurial don't bring any clear advantage over git, but have the big problem that only a few people know it. So peoples that wants to contribute to a project using Mercurial have first to learn Mercurial, and this was not there primary goal. The probability that an user have to learn git only for a project is actually far lower than for Mercurial.
Almost any large project includes peoples with different culture. But there use it to merge new features instead of creating an other project that will never get enough audience to change anything but add complexity to potentials users of the features.
Re:Python should do the same. by jrumney · 2014-01-02 14:36 · Score: 1

Be thankful. VSS was basically like RCS without branches, and first appeared on the market after everyone had already moved from RCS to CVS.

The editor wars continue in version control by Boawk · 2014-01-02 07:12 · Score: 2

Emacs will settle on git, vim has settled on mercurial. Oh, how delicious!

Re:The editor wars continue in version control by munch117 · 2014-01-02 08:19 · Score: 2

XEmacs uses Mercurial. Therefore we can be sure that GNU Emacs will never, ever, use Mercurial, lest its divine purity is contaminated by contributions from the blasphemers.

Two complaints, one non-complaint by tlambert · 2014-01-02 08:09 · Score: 2

Two complaints, one non-complaint

Complaint #1: ESR's reasoning, and the only theoretically justifiable one in the entire blog post, is that bzr is slow. All version control systems are slow. The more you keep the modification history around, the more people you have hitting a single repo, the slower they get.

When Apple moved from CVS to SVN, it was because of two things: The first was Linux-based Apple RAID boxes that Apple was OEM'ing from a third part had some bug where they lost data, and this messed up some of the CVS backing files. With a single backing file, as in SVN, this situation only improved because the switch came around the time the bugs in AppleRAID had already been resolved; otherwise, it would have been the whole repo, not just a couple of files, getting screwed up. The second one was that the CVS repo was slow. This was pixable by sharding it so different projects used repos on different servers. The new SVN server on the other hand, was lightening fast ... until we moved over the entire modification history from the CVS server to the SVN server, and all the CVS users stopped hitting the CVS server, and started hitting the SVN server instead. Then the SVN server was just as slow as the CVS server had been, and we were back to the status quo.

The lesson you should take from this is that it doesn't matter your version control system is slow, because they *ALL* are, and so it doesn't make a difference what VCS you end up using, as long as the primary maintainer likes it.

Complaint #2: ESR claims that, because it's in bzr and not git, it's harder to submit patches to EMACS. This is patently false. The older an Open Source project is, the harder it is to submit patches, and you VCS doesn't matter to this, because the difficulty isn't the VCS, it's the politics of change.

As projects get older and older, there's kingdom building that happens, and it's nigh impossible to get a change in that's going to cross one or more boundaries between kingdoms. The more kingdoms you code changes go into, the more code it changes, the more impossible it is to get those changes in. One of the big deals here is the "I won't approve your patch until you rewrite it the way I would have written it if I'd done it, but since I don't have the time (except to review and complain, of course -- then I have buckets of time), I'm not going to take the patch". This is called "time to get a new king instead of an asshole" effect for short.

The lesson you should take from this is that it's not the VCS, it's the politics, and yeah, if you switch VCSs, you'll get a window when not everyone is up enough on the new stuff that they can get in your way, if you're working with smart people: they will be. So switching VCSs is typically a means of cutting through red tape that shouldn't be there in the first place, and it never works for long.

Non-complaint #1: ESR states that bzr is "old and crufty" and that "it's mailing lists are dying and patches are dwindling", and that this is somehow bad.

It's not bad: that's what happens with mature, purpose-built tools: once the damn things work well enough, unless you have someone pushing change for changes sake to get themselves into the commit log or README file, the changes dry up, and the tool tends not to change. So activity on a mailing list or in a commit log for a mature tool is not a way to value that tool.

Before anyone jumps on me for this posting please read this: I personally don't use bzr, so I have no skin in this game. I've used over a dozen different VCSs, and with the exception on one that ran on DOS, which I would never use again, they're all pretty much solving the same problem, and you shouldn't really give a damn about what a projects primary maintainer likes to use, as long as the thing does the job.

Re:Two complaints, one non-complaint by jrumney · 2014-01-02 14:52 · Score: 1

It's not bad: that's what happens with mature, purpose-built tools
I'd be in agreement with you if it wasn't for the other linked post in the summary from one of bzr's ex-core developers basically saying the same thing. Actually I think open source would benefit in general from a clear winner emerging among DVCS systems, much as the way CVS did in the 1990s, and SVN looked to be doing before DVCS came along and stole its thunder before everyone had finished migrating from CVS. Focusing on one tool would simplify things for the community and improvements to that tool would come much faster.
Re:Two complaints, one non-complaint by complete+loony · 2014-01-02 16:17 · Score: 1

git is much faster than SVN. Firstly, since most operations are performed locally, you aren't all bogging down a central server for common operations. Secondly when you do need to fetch or push changes, they are compressed locally before transmission and then streamed instead of chatting back and forth.

--
09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
Re:Two complaints, one non-complaint by Bogtha · 2014-01-02 20:51 · Score: 1

Non-complaint #1: ESR states that bzr is "old and crufty" and that "it's mailing lists are dying and patches are dwindling", and that this is somehow bad.
It's not bad: that's what happens with mature, purpose-built tools: once the damn things work well enough

That's the thing - it doesn't work well enough. There are year-old bugs in bzr that affect EMACS that remain unfixed. This is not a codebase that has ceased development because it is finished, this is a codebase that has been largely abandoned.

--
Bogtha Bogtha Bogtha
Re:Two complaints, one non-complaint by Lisias · 2014-01-03 11:53 · Score: 1

Focusing on one tool would simplify things for the community and improvements to that tool would come much faster.
NEVER, EVER, focus on only one tool for ANYTHING.
Build intercommunication tools to standardize an interface (that what's matter, after all), and let each one choose the tool that best fits his needs (being that technical, political or emotional).
That's being the reason I stick with Mercurial - I can checkout and commit to almost every single VCS around.

--
Lisias@Earth.SolarSystem.OrionArm.MilkyWay.Local.Virgo.Universe.org

Ughhh why? by Anonymous Coward · 2014-01-02 08:32 · Score: 0

Development on EMACS is about as stable as ... um... well there' no good analogy.. It's just stable.
Why does it need to be in any "modern" code management? Will there really be a ton of changes?

Summary of ESR by Anonymous Coward · 2014-01-02 10:28 · Score: 0

https://www.gittip.com/esr/

lol.

Wrong solution by Anonymous Coward · 2014-01-02 11:37 · Score: 0

"Eric S. Raymond, co-founder of the Open Source Initiative, has recommended that Emacs should move to another version control system like GitHub, as bzr is dying. In an email, Raymond highlighted the key reasons why he believes that Emacs should move. Raymond said that bzr is moribund; its dev list has flatlined;"

I disagree. The problem is not that bzr is dying, it is more that Emacs is _long_ moribund/dead/irrelevant.
Yes it still is in use, but really, how is bloatware such as Emacs more relevant than the bloatware out of Redmond?
Not even M$ is silly enough to embed a LISP interpreter and a psychiatric "program" (ELIZA) in an editor.

Re: usability: over the years I have watched over the shoulders of some rather good developers, and it is absolutely agonizing to watch them try to come up with the correct set of (rather complex) keystrokes to perform the pertinent action that they wish to do at that moment.

Anecdote by rdnetto · 2014-01-02 18:46 · Score: 1

I'm in my early 20s, and very much grew up with GUIs and Windows. Despite this, I now use Vim (cue flame war) as my text editor after seeing how fast proficient users could be with it. I have a friend who uses Emacs as his desktop environment - no KDE or Gnome, just Emacs.
Both are powerful text editors with niche uses. e.g. programming. While fewer people are learning them now that they are no longer the default text editors on most distros, they're hardly dying.

--
Most human behaviour can be explained in terms of identity.

Mercurial by Lisias · 2014-01-03 11:45 · Score: 1

I would move it to Mercurial.

Better integration with foreign repositories, including GIT.

--
Lisias@Earth.SolarSystem.OrionArm.MilkyWay.Local.Virgo.Universe.org

ESR by Dabido · 2014-01-03 18:16 · Score: 1

I thought ESR was a Gnu name for ESR's Still Recursive.

--
Sure enough, the cow costume was hanging up next to the superhero outfit and sailors uniform. (S,Spud)

Slashdot Mirror

Emacs Needs To Move To GitHub, Says ESR

252 comments