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

81–90 of 143 posts

Re: Clang and FSF's strategy

#81

Post by guscost »

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.

> If ... Apple think they can get away with it, Apple will, in a heartbeat, close the development of Clang/LLVM

Followed shortly by Google, Microsoft, IBM, and Oracle. Classic prisoners' dilemma.

Re: Clang and FSF's strategy

#82

Post by jordigh »

kps wrote: post #75
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.

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’.)

So it is easily replaceable? You could easily tell xcode to use gcc if gcc supported the same kind of static analysis? How would you do this?

Re: Clang and FSF's strategy

#83

Post by belorn »

jjindev wrote: post #67
anon1385 wrote: post #59

Earlier quoted context omitted.

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.

A common business model today is to threaten customers with lawsuit after the exchange of money for software has happened.

As a author, I want to decide if I can accept having my work used in the above mode. I think such threats can cause quite a bit of harm, and there are many notable cases where ordinary people has had their whole life physically hurt by it.

I can see how many developers want to decide for themselves if they are going to use the "threaten customers with lawsuit" model to earn a living. But it is no ones right to decide for me if they can use my work for it.

Re: Clang and FSF's strategy

#84

Post by mikeash »

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.

All true, but that makes Xcode a proprietary IDE, not a proprietary compiler. Apple doesn't make a proprietary compiler.

Re: Clang and FSF's strategy

#85

Post by kps »

jordigh wrote: post #82
kps wrote: post #75

Earlier quoted context omitted.

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’.)

So it is easily replaceable? You could easily tell xcode to use gcc if gcc supported the same kind of static analysis? How would you do this?

I don't work for Apple and have never seen Xcode source, but my guess (based on what I would do) would be that Xcode invokes Clang/LLVM as libraries rather than a standalone binary, in order to keep persistent state. In principle GCC could present such an interface, but in practice FSF policies prevent it. The point is that the static analysis can be used directly or by other tools (there is a web interface, for instance); it is not restricted to Xcode.

Re: Clang and FSF's strategy

#86

Post by oso2k »

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…

For one, ESR isn't asking that the FSF change (directly). He's asking that FSF change with respect to GCC and the audience it serves. There's many developers, and especially young developers, that feel the GPL & FSF are "over-principled". I think we can all agree that "Open Source" has largely won.

But if you ask about "Free Software," and take github as data point, I'd say "Free Software" is losing, and is losing because, like proprietary software, it's "over-principled". Young people everywhere, "feel" like content, many forms of "public" data, and the tools to use, create, play, view, and store such content & data ought to be "free as in beer" (or close to it) based on the principle that the effort to copy & transfer data, content, binary, and source is "almost free". Whether there is a restriction in creating plug-ins, linking or modifying code (as in the GPL/Free Software), or copying binaries and/or content as in proprietary software, these are still restrictions.

This is the reason why I prefer the more permissive licenses for my works like the BSD and MIT licenses. Essentially, my work is a gift, in the purist sense, to the entire universe. To place restrictions on my gift is to have given the world a poison and not a gift.

The reason why is easier to understand when you consider the quote by Jim Warren from a 1976 ACM Programming Language newsletter [1], referencing Bill Gates' famous letter to the Homebrew Computing Club, "There is a viable alternative to the problems raised by Bill Gates in his irate letter to computer hobbyists concerning 'ripping off' software. When software is free, or so inexpensive that it's easier to pay for it than to duplicate it, then it won't be 'stolen'."

Said another way, people will continue to do the "wrong" thing so long as it takes less effort than to do the "right" thing. In my mind, we should be incentivizing the "right" things, like openness, sharing, technical merit, and capability.

[1] http://en.wikipedia.org/wiki/Tiny_BASIC#An_early_free_softwa...

Re: Clang and FSF's strategy

#87

Post by lazyjones »

asdasf wrote: post #68
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 w…

> GCC is written poorly on purpose in order to make it difficult to work with gcc

That's a strange conspiracy theory that has been posted here several times and debunked as well. It seems particularly odd to me because when I worked at a university 15 years ago, everyone in the compiler research world would occasionally hack on gcc to add features, retarget it, add optimizations etc. ... It didn't seem prohibitively difficult.

Re: Clang and FSF's strategy

#88

Post by jordigh »

kps wrote: post #85
jordigh wrote: post #82

Earlier quoted context omitted.

So it is easily replaceable? You could easily tell xcode to use gcc if gcc supported the same kind of static analysis? How would you do this?

I don't work for Apple and have never seen Xcode source, but my guess (based on what I would do) would be that Xcode invokes Clang/LLVM as libraries rather than a standalone binary, in order to keep persistent state. In principle GCC could present such an interface, but in practice FSF policies prevent it. The point is that the static analysis can be used directly or by other tools (there is a web interface, for inst…

So... it's not apparently possible without modifying the source code. So like I said originally, what Xcode is using for static analysis is apparently Apple's choice, not yours nor mine.

Re: Clang and FSF's strategy

#89

Post by erichocean »

fhd2 wrote: post #3

Sounds like the open source vs free software debate all over again. I don't have a strong position in that one, but I find GCC's position rather obvious: They want to support free tools, and they explicitly don't want to support proprietary tools. I cannot believe that this isn't obvious to esr, of all people. Is this just him trying to start a flame war? edit: I'm now aware that esr is not talking about license rest…

GCC's position [is] rather obvious: They want to support free tools

I don't have a strong position either, but unless you work for the FSF in their PR department, software developers should really be stating the FSF's position accurately, which is:

The Free Software Foundation only want to promote free^H^H^H^HFree Software Foundation-licensed tools, primarily tools that use its GPL license.

To the FSF, "free" is just a shorthand way of saying "Free Software Foundation-licensed". It doesn't mean "free" as normally understood. Just because the FSF wants to conflate the two to obscure what's going on doesn't mean the rest of the world should go along with the ruse.

(And it is clearly non-standard, which is easily demonstrated by how often FSF people have to explain what "free" means. As they say in politics, if you're explaining, you're losing. If there was no difference from the standard usage, no explanation would be needed. Therefore, the FSF usage is non-standard. QED)

FWIW I doubt anyone has a problem with the FSF's actual mission, since people are free (normal usage) to do what they want (and even encouraged to do so). It's the rhetorical duplicity of their PR that we shouldn't be supporting. Let the FSF's mission stand on it's own merits, rather than by trying to gain credibility/respectability by association with something else (in this case, our pre-existing affinity for freedom).

Re: Clang and FSF's strategy

#90

Post by dragonwriter »

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…

> 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

Why should I respect someone for sticking with principles that are misguided? The whole idea that "sticking to principles" is a virtue independent of the merits of the principles involved is perverse.

Its even more perverse when the "principles" being stuck too are tactical judgments about how to best acheive strategic aims, and they are being stuck too even when they are operating against the strategic aims -- which is, precisely, the charge ESR is levelling against the anti-plugin policy vis-a-vis the stated goals of the FSF with regard to GCC.

> asking the FSF to do something that they believe hinders free software is like asking MADD to open a drive-through liquor store

ESR's argument is that FSF is wrong that this hinders free software, and in fact that FSF's status quo approach inhibits the FSF's stated goals for GCC.

Post reply on HN