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

Clang and FSF's strategy

gcc.gnu.org

Post reply on HN
Print view View original

51–60 of 143 posts

Re: Clang and FSF's strategy

#51

Post by jordigh »

pmelendez wrote: post #45
e12e wrote: 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…

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

Re: Clang and FSF's strategy

#53

Post by jjindev »

ja30278 wrote: 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.

This is a digression, but it is slightly more complicated. The top US software companies, by market cap, all use FSF tools, but then in turn decide their own separate levels of openness. Entrepreneurs here will use FSF tools, and then decide how far to open their own kimonos. The original FSF intent, that copyleft would provide contagion to a truly open world seems actually stalled. Apologies for the digression.

Re: Clang and FSF's strategy

#54

Post by adamtj »

As I see it, the whole disagreement seems to stem from differing opinions about what happens when free/open software and non-free/closed software meet, and which is "stronger".

FSF lives on an island and worries that even one contaminated inhabitant will infect everybody. They seem to hold that non-free is a contagious disease that will overtake and destroy their freedom. FSF is worried about diminishing: what they have is perfect and it can only be reduced. FSF are Tolkein's Elves.

ESR would welcome contaminated people to that island, believing strongly in it's restorative properties. He seems to hold that open-source is more powerful and will stamp out closed software whenever they meet. ESR is worried about not expanding quickly enough and dying of stagnation. ESR would probably be Aragorn.

That's how I see this argument.

Re: Clang and FSF's strategy

#55

Post by chimeracoder »

ja30278 wrote: 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.

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 that this kind of crowbar approach does not lead to much more than headlines about Free Software infighting.

ESR is doing little more than trolling here. He knows exactly where the FSF stands, and he knows exactly why that's not going to change (asking the FSF to do something that they believe hinders free software is like asking MADD to open a drive-through liquor store).

The FSF has always been very clear that they see the "open source" movement as complementary to (though not the same as) the free software movement, fighting for similar goals but for different reasons[1]. It's sad to see ESR, an "open source" advocate, actively try to fan the flames.

Nobody wins from this. Except advocates of closed, proprietary software.

[0] Of course, ESR knows exactly what he's doing here - the issue is that he disagrees with their principles, but instead of debating those, he'd rather attack them for executing on their principles rather than executing on his principles. It's a cheap rhetorical trick and a rather low move.

[1] "We don't think of the Open Source movement as an enemy. The enemy is proprietary software.", from https://www.gnu.org/philosophy/free-software-for-freedom.en..... (Don't be fooled by the title - the content of the article is very even-keeled).

Re: Clang and FSF's strategy

#56

Post by Aqueous »

I see GCC as performing the necessary function of defining the radical antithesis to proprietary tools, historically like Think C, C++, Borland,and Metrowerks, and presents tools like Microsoft's Visual C/C++.

Without GCC staking out the position it has clang wouldn't have its middle ground to stake out. The middle ground would instead be a lot more proprietary than it is now.

Without Stallman being as radical as he is, there would be no Linus' who bridge the gap between completely free and completely proprietary software. There would be nothing to react to.

Many wrongs actually do make a right, as long as we're all wrong in opposite directions.

Re: Clang and FSF's strategy

#57

Post by lucian1900 »

jordigh wrote: post #51
pmelendez wrote: post #45

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.

Those are merely features of the IDE. The compiler used for actual building is configurable per project.

Re: Clang and FSF's strategy

#58

Post by pmelendez »

jordigh wrote: post #51
pmelendez wrote: post #45

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.

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

What I going to say might not be true any more, since the last time I worked on Xcode was roughly two years ago. But by then I worked as a mobile game developer and at the studio we happily compiled in both GCC and LLVM. Actually we preferred to use gcc and gdb since LLVM debugger was very buggy at that time.

This is how you could install gcc to work with XCode 4.3

http://stackoverflow.com/questions/9353444/how-to-use-instal...

And I wouldn't call LLVM/Clang an Apple's compiler, since it is contributed by people from Google too.

Re: Clang and FSF's strategy

#59

Post by anon1385 »

jjindev wrote: post #53
ja30278 wrote: 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.

This is a digression, but it is slightly more complicated. The top US software companies, by market cap, all use FSF tools, but then in turn decide their own separate levels of openness. Entrepreneurs here will use FSF tools, and then decide how far to open their own kimonos. The original FSF intent, that copyleft would provide contagion to a truly open world seems actually stalled. Apologies for the digression.

It largely stalled because of the web. Lots of SV startups for example are using GPL'd code, but because they only provide web apps they don't have to release their code. Worse still those startups often think they are on the 'good' side of the free software debate because they use some open source code in their products and maybe even contribute a bit back.

In my opinion the FSF screwed up majorly by concentrating on local software and the GPL while ignoring the much greater danger of software as a service. The AGPL is too weak and the FSF never really pushed it. The GNU project have tried to create some online services/protocols themselves but they are a total joke (e.g. GNU Free Call).

Re: Clang and FSF's strategy

#60

Post by lucian1900 »

vonbladet wrote: post #39
Devid2014 wrote: post #28

IMHO GCC has already lost this batle. Today one developer can create incredible tools using Clang/LLVM coda-base and release it as open-source or if he wants as closed source. This is just impossible with GCC. GCC is just a compiler but Clang is much more as this is a very powerful compiler building library... If we talk about C++ then Clang already support C++14 but GCC still not. And yes License matters, GPL just d…

> Today one developer can create incredible tools using Clang/LLVM coda-base and release it as open-source or if he wants as closed source. This is just impossible with GCC. By design. > And yes License matters, GPL just does not allow to use GCC in most cases. By design.

And esr is saying that perhaps it is (no longer) a good design.
Post reply on HN