Live data from Hacker News

Prefer mercurial to git

lists.gnu.org

141–150 of 189 posts

Re: Prefer mercurial to git

#141
post #55
post #6

You should have linked the first post in that thread. It explains what the whole thing is actually about: https://lists.gnu.org/archive/html/emacs-devel/2014-01/msg00... Tl;dr: Mercurial is a free software project sharing GNU's goals, while Git is made by anti-GNU people who do not believe in free software and has an incompatible license.

Quite frankly, not sharing GNU's goals is a feature, not a bug. The less the source code is encumbered by onerous political restrictions, the better.

Onerous political restrictions, like, giving downstream users the same freedoms you got from the upstream author; the freedoms that the author wanted all users of their code to have?

Re: Prefer mercurial to git

#142
post #44

Earlier quoted context omitted.

>while Git is made by anti-GNU people who do not believe in free software and has an incompatible license. WTF? Git is GPLv2 - the exact same as the Linux kernel. A great many developers are avoiding v3 due to the changes it made. And "anti-GNU people" is just a lame insult.

The people who avoid the GPL3 do it because they do not share the goals of the GNU project. The GPL3 expresses the same philosophy as the GPL2. GNU released a new version only because companies discovered a loophole (a bug if you will) in the GPL which allowed them to build non-free (as in GNU) systems based on GPL software. GNU was founded to fight such systems. However, Linus Torvalds (Linux and git) has no problem…

> The people who avoid the GPL3 do it because they do not share the goals of the GNU project.

Plenty of people share the (publicly stated) goals of the GNU project regarding free software, but disagree with the FSF's approach to realizing those goals, particularly with the GPLv3. (With the GPLv2 I merely thought that the FSF's approach was more restrictive than was necessary, with the GPLv3 and the use-based discrimination in the anti-tivoization clause, I find it actively harmful.)

Re: Prefer mercurial to git

#143

Earlier quoted context omitted.

"I'd love to be proven wrong on this. Considering that their figurehead regards closed source software as unambiguously evil, I don't see many other ways to interpret their behvaior." Assuming (with confidence) that you mean RMS, he regards it as evil but my understanding is that his framework for making the assertion is more consequentialist than his detractors believe. With "evil" usually used in more deontological…

> No, by technicality of the licenses ... This teacup tempest is entirely of GNU's own making. It's nobody else's fault that their licenses are so onerous that they can't even keep them compatible with later revisions they themselves produce.

[deleted]

Re: Prefer mercurial to git

#144

Earlier quoted context omitted.

> So the complete state of the repository is cryptographically secured It should be noted, however, that Linus and others specifically disclaim that this is a security mechanism: "Git uses SHA-1 in a way which has nothing at all to do with security.... It's just the best hash you can get.... It's about the ability to trust your data." --Linus ( http://en.wikipedia.org/wiki/SHA-1#Data_integrity ) And in the midst of a…

To be honest I don't buy his argument. If it is not about security, why not use md5? It is faster after all and gives you the same protection against accidental data corruption as sha1. And if he cared about security then he should have chosen sha256 or sha512, the latter of which is even faster than sha1 on 64bit systems [1] and can be truncated if you think it is too long. And really there is no denying that git re…

I am not sure I buy it either. To me it comes off as cognitive dissonance between the party line of "don't invent your own crypto" and the pervasive love and acceptance of Git.

No one wants to say that Git, on which many of our SCM processes are now built, is suspect. But also no one wants to argue that Linus is somehow an exception to the rule against amateur cryptography.

So what we're left with a somewhat ambiguous situation where Git is described as not being crypto despite the fact that in practice people assume it is resistant to malicious attack.

Re: Prefer mercurial to git

#145
post #118

Earlier quoted context omitted.

> but he's been labeled as anti-GNU for writing software that has a more permissible license No. he has been labeled as anti-gnu because of torvalds own statement like: "So I'm pretty well-known for not exactly being a huge fan of the FSF and Richard Stallman" "Linux from the very beginning was not about the FSF ideals." I would not directly call it anti-gnu, but neither is he friendly. He can also not be directly ca…

I don't like the FSF or Stallman's ideals myself (I find them dogmatic, unrealistic, and probably a bunch of other negative adjectives) but I cannot deny they are a net positive influence on the world. I'm also annoyed because that very dogmatism weakens their very positive message.

I have a hard time seeing how the world would work if people did not strive to achieve their goals.

Take a for-profit company. Their goal is to make money. If I ask them to compromise on this and stop earning money, they get very dogmatic about it and completely refuse.

If I ask a politician to start promoting a competitor, he will also dogmatic refuse. I can not even get him to compromise. I offer him nice bribe money, and he should accept it and step down.

What I am trying to say is that dogma and compromises are not the black and white, good and evil. Dogma is required to make the world work, and compromises are only good when it doesn't interfere too much with it.

Re: Prefer mercurial to git

#146

Earlier quoted context omitted.

"I'd love to be proven wrong on this. Considering that their figurehead regards closed source software as unambiguously evil, I don't see many other ways to interpret their behvaior." Assuming (with confidence) that you mean RMS, he regards it as evil but my understanding is that his framework for making the assertion is more consequentialist than his detractors believe. With "evil" usually used in more deontological…

> No, by technicality of the licenses ... This teacup tempest is entirely of GNU's own making. It's nobody else's fault that their licenses are so onerous that they can't even keep them compatible with later revisions they themselves produce.

This is bullshit rhetorical sophistry, and I'm pretty sure you know it.

Choosing an incompatible license is the fault of the person who chose the license. The FSF made a mistake in not building "... or any later version" into the GPLv2; they acknowledge this. They've been recommending for some time - since long before the start of the Git project - that projects interested in being GPLv2 compatible include "... or any later version."

Imagine it was a piece of software with a bug. There's a patched version, it's been broadly announced that there was a bug and there is a fix. You ignore that and use the buggy version. Whose fault is it when you trip over the bug? Claiming it is "entirely of [the programmer]'s own making" is absurd.

Re: Prefer mercurial to git

#147
post #134

Earlier quoted context omitted.

> What if I don't care if some corporation comes along and takes my code and releases a product based on it? Cool! I've helped the world somehow! Say you developed a program that keep tracks of group of people. The Ku Klux Klan use it to track down black people, and the anti-tolerance movement use it to track Ku Klux Klan. You helped the world and the anti-tolerance movement should be happy right? If they would prefe…

>Say you developed a program that keep tracks of group of people. The Ku Klux Klan use it to track down black people, and the anti-tolerance movement use it to track Ku Klux Klan. Stop it. You're basically engaging in a not-hitler version of Godwin's Law. And it's not even relevant, since the GPL is only about source code, not about whatever that code is used for. In your completely arbitrary and fucked up example, a…

What you said was:

> BSD is a de-facto more permissive license. ... And people who want to use my code don't have to get involved in GPL politics and drama!

So yes, you statement was an "BSD as the right choice, GPL is the wrong choice". If you actually want to be tolerant of people right to license what they want, you should not badmouth their choices when they don't pick the same as you.

> as long as the KKK released the source code to their tracking app, the GPL has nothing to say.

I have said nothing about the license. I have said that the anti-tolerance movement would have something to say when that program helps KKK. I also said that it is an understandable reaction from the anti-tolerance movement. They are allowed to be both thankful for the help they got, and scornful about the fact that it is helping KKK.

This is the same complain when FSF dislike when proprietarization is made easier by other peoples license choices. They are thankful for the help, and also scornful about the fact that it makes their goal harder to achieve. If you don't find that relevant because "its a license" or because of godwin, then that is up to you.

Re: Prefer mercurial to git

#148

Earlier quoted context omitted.

> No, by technicality of the licenses ... This teacup tempest is entirely of GNU's own making. It's nobody else's fault that their licenses are so onerous that they can't even keep them compatible with later revisions they themselves produce.

This is bullshit rhetorical sophistry, and I'm pretty sure you know it. Choosing an incompatible license is the fault of the person who chose the license. The FSF made a mistake in not building "... or any later version" into the GPLv2; they acknowledge this. They've been recommending for some time - since long before the start of the Git project - that projects interested in being GPLv2 compatible include "... or an…

> This is bullshit rhetorical sophistry, and I'm pretty sure you know it.

No, I don't know it. The GNU's license absolutism is what got them into this mess in the first place. It's inherent in their aims.

> Imagine it was a piece of software with a bug.

Imagine that it's a piece of software with a new UX direction not everyone agrees with.

Re: Prefer mercurial to git

#149
post #101

Earlier quoted context omitted.

Then why not switch to mercurial?

Because as enterprise consultants we use what the customers require, it is not up to us to choose our tooling. Many of those customers have been sold to git hype before getting us on board.

There are some cases where customers don't know what tooling they require though ;)

Re: Prefer mercurial to git

#150
post #55

Earlier quoted context omitted.

Quite frankly, not sharing GNU's goals is a feature, not a bug. The less the source code is encumbered by onerous political restrictions, the better.

Quite frankly, not sharing GNU's goals is a bug, not a feature. The less the source code is encumbered by onerous political restrictions, the better.

I can see that the freedom to copy must be very important to you. ba-dum ching
Post reply on HN