Live data from Hacker News

Clang and FSF's strategy

gcc.gnu.org

71–80 of 143 posts

Re: Clang and FSF's strategy

#71
post #31

I found the counter-argument made in the first reply to be more compelling. http://gcc.gnu.org/ml/gcc/2014-01/msg00178.html Whether you agree with the FSF or not, their whole existence stems from their beliefs about software freedom. If they compromise their principles in exchange for 'market share', then they quite literally have no purpose.

Correct. Don't forget one of the most striking differences between free software vs open source software is the promotion of a community of people who add to the public knowledge of software engineering, not merely to make better software artifacts. If you had to choose, which would you foster? An individual truth or a community of truth seekers? FSF is clearly about the latter.

Re: Clang and FSF's strategy

#72
post #40

I wrote this six months ago: If people switch from GCC to Clang/LLVM in enough numbers that Apple think they can get away with it, Apple will, in a heartbeat, close the development of Clang/LLVM and make all new versions proprietary. ( https://news.ycombinator.com/item?id=6146066 ) This is still true, and this is the reason we cannot allow GCC to give up or declare “victory” and move on.

No, it is not still true. It was never true. It is pure FUD. Apple has absolutely no way to "close the development" of llvm. Why do GPL zealots still post such crappy FUD even when MIT/BSD/apache/ISC licensed projects make up a massive portion of the infrastructure of the net, and no magical closing has ever managed to cause any problems at all?

Re: Clang and FSF's strategy

#73
post #47

Earlier quoted context omitted.

Why would anyone use a closed fork of llvm? The open one would continue as normal without Apple.

The open one would stagnate without the developers who Apple pays to out-compete then both GCC and the free fork of LLVM.

The open one would stagnate because it has over 3 times as many developers, writing over 3 times as much code? You seriously think that?

Re: Clang and FSF's strategy

#74
post #47

Earlier quoted context omitted.

Why would anyone use a closed fork of llvm? The open one would continue as normal without Apple.

The open one would stagnate without the developers who Apple pays to out-compete then both GCC and the free fork of LLVM.

Apple is not the largest contributor to LLVM, Google is. The various other non-Apple contributors also outweigh Apple. It would be hugely expensive for Apple to hire all those compiler developers from Google and Intel and dozens of other companies. Why would they do it? What would it gain them other than to be comically villainous.

The reality is that GCC is stagnating because a lot of things people want to do are just not very easy to do with GCC, due to architectural decisions that were made for purely political reasons (and these arguments have been going on since long before LLVM even existed).

It used to be that academics, students, post grads and hackers who wanted to do something interesting and new with a compiler would start with GCC. That hasn't been true for some years now. Pretty much all the interesting new projects are based on LLVM. And that isn't because of Apple paying people. It's because LLVM has modular design that gives you a stable clean interface to various things while GCC only offers unstable and complicated internal data structures.

So increasingly people interested in studying and developing compilers are hacking on LLVM and GCC is left only with developers who have a very strong political agenda that motivates them to contribute to GCC. Unfortunately for RMS most compiler developers don't work for free out of their basements. They are well paid and work at large companies and so any emotional or political arguments about freedom don't get any weight with their bosses compared with the ability to actually get shit done. So they are switching to working on LLVM.

As detailed elsewhere in these comments RMS knows full well that the political decisions limit the functionality of GCC. He says he is happy to pay that price to prevent anybody using GCC in a project that isn't GPL licensed.

Re: Clang and FSF's strategy

#75
post #51

Earlier quoted context omitted.

>"proved wrong by Apple's Xcode? " As far as I know, Xcode is not an compiler, it's an IDE that uses LLVM/Clang underneath as primary option but also gcc if it is your choice. In the same way, Visual Studio uses cl.exe underneath but it can be hooked up with Clang too.

I don't think it's your choice what you hook underneath Xcode. I think it's Apple's choice. Since Xcode is non-free, you can't modify it to use something else will-nilly. All of the fancy static analysis that Xcode does is completely tied to clang, for example. Its debugger front-end is tied to lldb's idiosyncratic interface. It's not something that you can just easily replace with non-Apple compilers.

  All of the fancy static analysis that Xcode does is completely tied to clang, for example.
Xcode doesn't do static analysis; Clang/LLVM does, and it's perfectly possible to do it from the command line, or embed it in other tools. (This is an example of the difference between LLVM's modular library architecture and GCC plugins — LLVM doesn't insist on being ‘on top’.)

Re: Clang and FSF's strategy

#76
Ugh, more free software vs. open source politics. In the interest of actually collaborating and getting shit done, I'd like "freedom" from all this nonsense please.

Re: Clang and FSF's strategy

#77
"The clang developers very carefully do _not_ say that they aim to make GCC obsolete and relegate it to the dustbin of discarded tech. But I believe that is unmistakably among their goals"

Beliefs don't need them, but I don't see a rational argument supporting that. IMO, clang developers just won't cripple their product to prevent the potential collateral damage to gcc.

Re: Clang and FSF's strategy

#78
post #70
post #12

Earlier quoted context omitted.

I can't claim to know anything about GCC's internals, but from what I know/read, it does have a plugin system and I don't see any indication of that being held back for political reasons (there are many other potential reasons for technical inferiority). And I don't see how the FSF could ever have furthered their political goals by making it technically hard to use GCC in free software tools, quite the contrary. Woul…

https://lists.gnu.org/archive/html/emacs-devel/2012-12/msg00... RMS says "freedom" is worth sacrificing functionality for. GCC is a monolithic mess of shit that is virtually impossible to debug, and produces incorrect code very frequently. Being forced into a terrible architecture where everything is smushed into everything else just to prevent people from being able to use gcc as a front end and something else as a…

   GCC is a monolithic mess of shit that is virtually impossible to debug
This is the “RMS loophole” in the GPL. In principle you have the right to modify GCC to suit yourself; in practice, the barrier to entry is too high.

Re: Clang and FSF's strategy

#79
post #62

Earlier quoted context omitted.

Agreed. It's very rare these days to find people who are willing to stick to their principles; we should respect those who do, rather than criticize them for not compromising on their principles[0]. From your linked post: > You are crossposting to two public project lists of the GNU project with inflammatory language and mischaracterizations. You have been involved with the GNU project long enough to be well aware th…

Seems like ESR is still fighting the Open Source vs Free Software battle of the late 90s. It hasn't dawned on him yet that everyone else thinks that there's little purpose in cannibalizing the movement over minor philosophical differences.

By "everybody else" I think you're excluding the people who run the Free Software Foundation, in other words the very people ESR was addressing.

Re: Clang and FSF's strategy

#80
post #26

As other's have noted, GCC has a plugin system (and not a [edit:stable] external interface) -- so that extensions/tools (plugins) will have to link to GCC, and be covered by the GPL. This is similar to how the Linux kernel tries to limit binary drivers, by explicitly not having a stable ABI (although, in the case of the Linux kernel I think it is also a case of "we don't want the burden of maintaining an outdated, in…

Why not just write the license in such a way that linking against the stable ABI requires your code to also be GPL licensed?

Is there a legal reason why the requirement can only apply to the original source code and not the compiled source code? Don't the "proprietary binary" people exert some kind of license over their proprietary binaries?

And why can't the Linux Kernel have a versioned ABI? I don't know enough about it, but does it really get revised that often and by that much? I mean, Apple and Microsoft seem to be able to make this work, and everyone seems to think they aren't very capable compared to the Linux Kernel crew. The argument about "having to support old things" also doesn't seem to hold water, because one of the big reasons people use Open Source software is to leverage older, outdated hardware or to have access to older, outdated software and data that the proprietary vendors leave behind.

Post reply on HN