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

121–130 of 143 posts

Re: Clang and FSF's strategy

#121

Post by asdasf »

teddyh wrote: post #113
asdasf wrote: post #72

Earlier quoted context omitted.

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?

Well, strictly speaking, neither one of us can be sure what would happen. It’s just what I think would happen. Is it “FUD” if I still really believe it? I don’t know. And speaking of closing; just look at Android with its complete anti-GPL, purged system. Only Linux remains there. Of course, I (or you) can’t prove anything either way, but I have the feeling of Google, Apple, and the rest of the permissive license pro…

>Well, strictly speaking, neither one of us can be sure what would happen

We could certainly look at the hundreds of projects setting precedent to determine that you are almost certainly wrong.

>Is it “FUD” if I still really believe it?

Yes. If you are posting something to create fear, uncertainty and doubt, then it is FUD. Even if you are sincerely crazy, it doesn't make your FUD not be FUD.

>but I have the feeling of Google, Apple, and the rest of the permissive license promulgators

Google are not "permissive license promulgators". And you wouldn't be having this conversation if not for actually free software, like freebsd, apache, bind, etc. The people who made the internet are the "permissive license promulgators". Show some fucking respect.

>And one fine day they will turn off the freedom and turn it all proprietary

And see a therapist. You are paranoid and delusional.

Re: Clang and FSF's strategy

#122

Post by dragonwriter »

mcguire wrote: post #112
dragonwriter wrote: post #90

Earlier quoted context omitted.

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

" 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. " I believe ESR is wrong. In years past, there was BSD unix, a modified version of the unix sh…

I think there is a conflict of goals here, but it's one that often goes unstated; ESR is about fostering free software, even if that incidentally also foster's non-free software.

Many on the FSF are about preventing code from being used in non-Free software, even if that incidentally is less than optimal for fostering Free software.

The thing is, many of those who act based on the latter priority present themselves as if there concern was for promoting Free software.

Re: Clang and FSF's strategy

#123

Post by protomyth »

fafner wrote: post #120
protomyth wrote: post #118

Earlier quoted context omitted.

So, if Apple had incorporated GCC's parser into Xcode like they have included clang's, what would have been the effect?

They would have to honour GCC's license, like they have to do with clang's license or any other piece of software.

And would honoring that license require them to release the source for the non-GPL licensed parts of Xcode and perhaps require some action on any patents implemented in that non-GPL code?

Re: Clang and FSF's strategy

#124

Post by belorn »

oso2k wrote: post #86
chimeracoder wrote: post #55

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…

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

The data made over repositories like Google code, debian and similar places where entries has some form of minimum standard, GPL licenses are a strong majority, and is increasingly used.

So young people are either not serious enough to warrant inclusion in the 40 000 list of programs in Debian (doubtful), or your assumptions are incorrect.

> To place restrictions on my gift is to have given the world a poison and not a gift.

Next time you gift a beer to a friend, I hope you will allow them to hit you with it. Adding restriction on hitting you with the beer is the same as putting poison in the beer which would kill your friend.

Re: Clang and FSF's strategy

#125

Post by breser »

msbarnett wrote: post #104
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?

If GCC supported that (and if Xcode supported GCC's support of it), you'd probably tell Xcode to use it the same way you tell Xcode to build with GCC instead of clang: You'd select the option in your project settings. Nobody's made the claim that Xcode is some kind of magical dynamic IDE that supports arbitrary hypothetical features of arbitrary hypothetical versions of arbitrary compilers that you can mix and match…

GCC support in XCode has been less and less GCC and more and more just the LLVM cleverly disguised as GCC. With XCode5 there is nothing left from the actual GCC project, even gdb has been entirely replaced with lldb. So now if you chose GCC in XCode you're not really using GCC at all.

Re: Clang and FSF's strategy

#126

Post by belorn »

erichocean wrote: post #89
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…

"It doesn't mean "free" as normally understood ... have to explain what "free" means. As they say in politics, if you're explaining, you're losing"

And so you are losing. You are trying to explain what "free" is, and QED, your usage is non-standard.

Re: Clang and FSF's strategy

#127

Post by belorn »

asdasf wrote: post #70
fhd2 wrote: 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…

Please take your FUD and go elsewhere.

Re: Clang and FSF's strategy

#128

Post by lazyjones »

anon1385 wrote: post #93
lazyjones wrote: post #87

Earlier quoted context omitted.

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

It's not a conspiracy theory. Could you point to the 'debunking' because I don't see one that contains any actual evidence?. There are lots and lots of public mailing list posts by RMS and other GCC engineers explaining their reasoning for not making GCC more modular. The reasons were political. For example RMS vetoed the first attempts to add support for Java bytecode to GCC because he thought it would allow people…

Are posts from 2001 and 2007 really relevant for this discussion?

Look at this for example: http://gcc.gnu.org/ml/gcc/2014-01/msg00182.html

The "debunking" in this thread was the confirmation that plugins actually work now because the policies were relaxed in favor of them.

Re: Clang and FSF's strategy

#129

Post by fafner »

protomyth wrote: post #123
fafner wrote: post #120

Earlier quoted context omitted.

They would have to honour GCC's license, like they have to do with clang's license or any other piece of software.

And would honoring that license require them to release the source for the non-GPL licensed parts of Xcode and perhaps require some action on any patents implemented in that non-GPL code?

They have to honour the license. Which provides and guarantees basic freedoms. But it allows the code to be reused in any project honouring the license. So your initial statement is false.

Re: Clang and FSF's strategy

#130

Post by protomyth »

fafner wrote: post #129
protomyth wrote: post #123

Earlier quoted context omitted.

And would honoring that license require them to release the source for the non-GPL licensed parts of Xcode and perhaps require some action on any patents implemented in that non-GPL code?

They have to honour the license. Which provides and guarantees basic freedoms. But it allows the code to be reused in any project honouring the license. So your initial statement is false.

Nope, my basic statement is true. You didn't answer the question and by "code" you don't just mean the GPL code. The GPL tries to affect all code in the project not just the GPLed code.
Post reply on HN