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

61–70 of 143 posts

Re: Clang and FSF's strategy

#61

Post by anon1385 »

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

I really don't see that happening. Google engineers are the largest contributors to LLVM/Clang these days. Why would Apple reject the contributions of a company that employs some of the best compiler engineers? It would make it much more expensive for them to maintain and develop LLVM.

Re: Clang and FSF's strategy

#62

Post by frezik »

chimeracoder wrote: post #55
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 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.

Re: Clang and FSF's strategy

#63

Post by taybin »

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.

But but but ESR is a social hacker! http://esr.1accesshost.com/

Re: Clang and FSF's strategy

#64

Post by icefox »

Shamanmuni wrote: post #41
bjourne wrote: post #30

Earlier quoted context omitted.

I believe he is talking about different kind of plugins. For example, suppose you are an editor and you want to syntax highlight c source code. You could then feed .c files to clang, get back a parsed ast and use that for awesome syntax highlighting. You can not do that with gcc and the fsf does explicitly not want you to be able to. Because you could then be writing a non-free editor to take advantage of and using g…

Oh, I think you are right, esr was talking about using GCC as a plugin and I understood plugins for GCC. Apparently Alexandre Oliva and many of us made the same mistake. Considering that, I mostly agree with David Kastrup; it doesn't make sense for the FSF to bend its principles and help propietary software in order to get market-share. But, unfortunately, it's also affecting FOSS developers.

Yup, there are many, many times when I want to be able to do simple things with C or C++ code. Writing a little static analyzer tool that can check some internal code for a practice we have found harmful, parse some headers to automatically generate python bindings, documentation stubs, generate really good unit tests stubs with the information the ast give you, grab all of the comments and run your own verification on them, automagically re-write code to not use an old api anymore. And this is all just with using the source parser side of things of llvm

These are the tools I write, they are not big commercial enterprises, most of them are one off projects that are used and tossed away within a year, very few are ever published. Clang makes me more productive because they give me the ability flat out do this type of thing. It doesn't matter what GNU political agenda is, their tool flat out doesn't let me do this like llvm can. As long as this is the case long term I will use llvm more and more over gcc.

Re: Clang and FSF's strategy

#65

Post by frezik »

pdw wrote: post #43
dalke wrote: post #32

Earlier quoted context omitted.

As one of the commenters points out, Intel continues to develop a proprietary compiler. I think that's a better example than Apple for this case. In general, the world is more than just C/C++. IBM dominates the enterprise COBOL market. (See http://www.itworldcanada.com/article/most-wanted-the-elusive... .) And there are several commercial Fortran compilers besides Intel, including that of NAG (Numerical Algorithms Gr…

Proprietary C compilers are also alive and well in the embedded world.

But a lot of them use GCC, too. Atmel, for example.

Re: Clang and FSF's strategy

#66

Post by jordigh »

pmelendez wrote: post #58
jordigh wrote: post #51

Earlier quoted context omitted.

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…

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

It's about as much of an Apple compiler as gcc is an FSF compiler.

Re: Clang and FSF's strategy

#67

Post by jjindev »

anon1385 wrote: post #59
jjindev wrote: post #53

Earlier quoted context omitted.

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

But don't most people here, at HN, want that right to decide their own openness? I mean, does everyone here plan to do a web startup and then produce a tarball of [their] full work? A full DB API?

I understand that we all, or most of us, have contributed to free or open projects, but I thought the pure-souls, without a little "IP" one way or another, were very rare.

Re: Clang and FSF's strategy

#68

Post by asdasf »

lazyjones wrote: post #2

esr seems to conflate technical differences with political issues here. clang is not superior in some areas because it isn't GPL'd. It's because it is a newer project with more resources and different priorities. Sure, it attracted some developers who didn't like gcc's and the FSF's policies, but so do all kinds of crappy proprietary products. The point is, gcc doesn't need to relax its policies to better compete wit…

You are the one conflating the technical and political. This has little to do with licenses. GCC is written poorly on purpose in order to make it difficult to work with gcc. They do not want gcc to be used as a typical unix tool, doing some task and then having the output piped to some other tool to do some other task. They want you to have to directly extend gcc to add whatever functionality you want, this way you would have to make your functionality GPL. The consequence of this moronic decision is that gcc is an absolute nightmare to work on, is full of bugs that are very hard to isolate, and is being abandoned by everyone sane in favor of clang.

Re: Clang and FSF's strategy

#69

Post by kps »

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

Apple developers are significant contributors to LLVM, but not a majority. It's roughly one quarter Apple, one quarter Google, one quarter other paid commercial developers, and one quarter individuals (including academics).

Re: Clang and FSF's strategy

#70

Post by asdasf »

fhd2 wrote: post #12
Tuna-Fish wrote: post #8

Earlier quoted context omitted.

No. It's not that at all. The GCC/LLVM debate has nothing whatsoever to do with licensing, but crippling the design of gcc for political aims. Educate yourself on the subject.

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 backend is absolutely a case of making the code worse for the sake of trying to further a political agenda.

Post reply on HN