Emacs and LLDB
Back in January, we looked at a dispute regarding extracting internal representation data from GCC for use by Emacs. Because of concerns about commercial entities circumventing the GPL, Richard Stallman opposed making the abstract syntax tree (AST) available from GCC, which was a feature that some Emacs developers were hoping to make use of. There are also technical barriers to using GCC's AST, it would seem, but it is the political barrier being erected that stuck in the craw of many. A more recent thread on the emacs-devel mailing list looks a bit like history repeating itself.
Andrew L. Moore obviously recognized the potential pitfalls when he asked about merging a patch adding support for
the LLDB debugger (part of the LLVM
project) to the code for the
Emacs Grand Unified
Debugger mode: "I’d be interested to know if and how this
might be accepted into the Emacs distribution, RMS’s opinion of LLVM
notwithstanding.
" Emacs maintainer Stefan Monnier was quick to respond positively to the idea. His only
concern was to "to clear the copyright status
of this code
".
On the other hand, Stallman was not in favor of the change. In fact, he saw it as an attack on the GNU project:
As might be guessed, others saw things a little differently. Several likened the situation to that of Windows and Mac OS X support in Emacs, though Stallman rejected that comparison. In addition, no one saw basic LLDB support for Emacs as the attack that Stallman made it out to be. Monnier said Stallman sounded paranoid:
Yes, they compete. But the intention is not to replace one with another. The intention of people working on LLVM is to solve their immediate problem, and for one reason or another, they don't consider GCC as a good way to solve their problem.
Nobody would benefit from killing GCC, really. Not even control freaks who think the GPL is the plague.
Furthermore, as David Kastrup put it: "If we try to close down every cooperation with non-GNU free software, we
are sacrificing our goals for the sake of our temples.
" Stallman disputed that he was suggesting that course, but
there is, at least, a perception problem that Stephen J. Turnbull pointed out:
There are several issues for Emacs (and GNU) that Stallman is currently studying, including getting AST information from GCC and support for LLDB but, to some, those studies are holding development back unnecessarily. Kastrup would like to see some rules that would help reduce the amount of study required:
And to me some hard and fast rules for interoperation seem feasible: after all, we can hardly "defend" ourselves against software that is licensed in GPL-compatible ways. Any measure against such software will equally well keep GPLed/GNU software at bay.
Stallman, though, seems to be convinced that Apple is attacking GCC through LLVM: "Apple intends LLVM and Clang to make GCC cease to be a
signal success and a reason for all sorts of companies to work on a
compiler that always gives users freedom
". But, as Eric S. Raymond
pointed out, Apple's adoption of LLVM is
actually a victory, since LLVM is licensed under a free-software license
(just not a copyleft license like the GPL):
As a result of this victory, all sorts of companies are now working on *two* compilers that always give users freedom. One is GCC. The other is clang (I haven't noticed my freedom being diminished even a little bit when I set CC=clang). That is a good thing.
Apple is not composed of angels. Apple does things that you and I would both regard as scummy. But to suppose that Apple has any desire, need, or intention to attack GCC is to attribute an importance to GCC in Apple's eyes that it has not possessed since the day clang shipped 1.0.
An interesting side note to the debate emerged when Liang Wang posted about LLVM creator Chris Lattner's offer to try to get LLVM's copyright assigned to the FSF back in 2005. It was part of an effort (that seemingly went nowhere) to integrate LLVM and GCC. Stallman never heard about the message:
If I had seen it back then, I would not have had the benefit of hindsight, but it would clearly have been a real possibility. Nothing would have ruled it out.
Helmut Eller suggested contacting Lattner to see if LLVM might be interested in switching its license but, as Kastrup pointed out, LLVM is already licensed in a GPL-compatible way. If someone wanted to, they could release a GPL fork of LLVM tomorrow. On the other hand, though, LLVM is targeted at being modular so that other tools can use it in novel ways—something that GCC has generally resisted (largely at Stallman's behest). So, Kastrup continued:
So far, at least, there has been no response from Stallman to that. In the meantime, however, Raymond posted a broadside furthering his earlier message entitled "Defending GCC considered futile". It is too late to save GCC, he said, so it is time to move on:
Obsolescence happens; this is nobody's fault. It will happen to clang/LLVM someday, too, but today is not that day.
Reaction to Raymond's message was fairly muted on the mailing list, which
is a bit surprising,
but may partly be due to the fact that it was posted to an Emacs list,
rather than one for GCC. In any case, Stallman chose to focus on the narrower issue of whether
supporting LLDB is right for Emacs—and to ignore the larger LLVM issue
taken up by most others in the threads. But he admitted a total lack of
knowledge of LLDB, though he guessed it is a "noncopylefted
debugger
", based on the name. Others confirmed that guess and went
on to describe LLDB at some length.
Stallman is still awaiting information about LLDB to try to make a decision about whether he thinks Emacs should support it or not. As he did in the earlier thread, though, Monnier made it clear that Stallman's opinions on the matter carry no weight with him. He has said he will merge LLDB support once there is code with a proper copyright assignment available.
On multiple issues, Stallman could be seen to be standing in the way of progress in ways that don't serve Emacs, GCC, or the GNU project all that well. While Raymond's assertion that he would not personally miss GCC is, characteristically, over the top (compiling a Linux kernel still requires GCC, for example, even as the LLVMLinux project gets closer to its goal), it may not be all that long before it is true. That's unfortunate in many ways, but perhaps not completely unexpected.
By all accounts, LLVM is an excellent project that provides infrastructure
for numerous compilers (including Clang) and other tools (including LLDB).
While it doesn't have the license that Stallman, the FSF, and others might
wish, it is certainly free software. There is plenty of room for two (or
more) compiler suites in the free-software world—we just may be seeing
a switch in the dominant player. Trying to stand in the way of that switch
may well turn out to be a poor place to stand.
Posted Feb 12, 2015 3:10 UTC (Thu)
by ddevault (subscriber, #99589)
[Link] (12 responses)
Posted Feb 12, 2015 4:21 UTC (Thu)
by felixfix (subscriber, #242)
[Link] (9 responses)
Posted Feb 12, 2015 8:02 UTC (Thu)
by oldtomas (guest, #72579)
[Link]
But...
> Ditto -- once you let politics influence your technical decisions, you've started down a path which is very hard to reverse.
I do disagree with this. I think one needs always both: a squishy "vision" (and politics do go into that) and hard technical insight to take a decision, and it's about the right balance and about being aware which factors do what.
Just taking "technical" decisions on "technical" grounds is being in denial about political motivations which are underneath anyway. Just inconsciously.
All IMHO, of course :-)
Posted Feb 12, 2015 18:22 UTC (Thu)
by rodgerd (guest, #58896)
[Link] (6 responses)
You end up writing gcc in the first place. Pissing and moaning about "eeeevil politics" around a tool that only exists because the author chose to do something detractors told him was silly and pointless is a bit rich.
Posted Feb 12, 2015 18:43 UTC (Thu)
by cesarb (subscriber, #6266)
[Link] (4 responses)
Were the technical decisions made during early gcc development influenced by politics?
Posted Feb 12, 2015 20:17 UTC (Thu)
by rahulsundaram (subscriber, #21946)
[Link] (1 responses)
Sure if you consider the fact that GCC is GPL licensed and the design while modular didn't allow for the sorts of things that LLVM did.
Posted Feb 17, 2015 12:02 UTC (Tue)
by nix (subscriber, #2304)
[Link]
Posted Feb 12, 2015 20:37 UTC (Thu)
by Fats (guest, #14882)
[Link]
There has been a fork (egcs) when politics got the overhand in gcc development and luckily got the development back on track.
Posted Feb 13, 2015 18:25 UTC (Fri)
by smoogen (subscriber, #97)
[Link]
The more people involved the more politics until at some point you end up with people having to lobby to get their feature done because it affects someone elses.
If you look through the very old gnu.misc.discuss and various other lists for any of the particular software (gcc, gdb, etc) there have always been debates and give and take on what features were going to happen. In the case where only one person had a say (glibc for a long time) then you have a dictatorial politics.
Posted Feb 12, 2015 23:03 UTC (Thu)
by felixfix (subscriber, #242)
[Link]
Every decision in daily life can be construed to have political and technical aspects -- when you are walking down a crowded street, you have to decide who to bump and who to dodge. It's when the politics make the major decisions that things go south.
Posted Feb 17, 2015 12:00 UTC (Tue)
by nix (subscriber, #2304)
[Link]
Posted Feb 19, 2015 1:57 UTC (Thu)
by scientes (guest, #83068)
[Link] (1 responses)
Posted Feb 19, 2015 5:38 UTC (Thu)
by pizza (subscriber, #46)
[Link]
It's unclear if you're referring to the process of using a cross-compiling GCC toolchain, or the process used to create the cross-compiling toolchain. For the former, LLVM vs GCC is a wash as they face the same sorts of problems, mainly with third-party libraries with build systems that are too clever for their own good. (Seriously, autotools is the worst option, except for all of the others...)
Meanwhile, the vast, vast majority of those doing cross-compiling will just use a pre-built toolchain provided by someone else (eg Linaro) so the effort of generating said toolchain is largely irrelevant. But that said, it's been pretty easy to do so with GCC for at least a decade, thanks to the likes of crosstool-ng (and before that, buildroot) providing a neat solution that JustWorks. That said, historically the problems haven't been with gcc so much as spotty C libraries and bleeding-edge binutils for (at the time) esoteric platforms.
And I write this as someone who has been building his own GCC cross-compilers for Linux and bare-metal systems for four or five major architectures (and many more minor variants) since 2003.
Posted Feb 12, 2015 6:05 UTC (Thu)
by rsidd (subscriber, #2582)
[Link] (1 responses)
Wilfully or not, Stallman misunderstands the offer by Lattner in 2005. It was not merely "we will turn over copyrights to FSF". It was, quoting Lattner's mail,
Emacs and LLDB
Emacs and LLDB
Emacs and LLDB
Emacs and LLDB
Emacs and LLDB
> You end up writing gcc in the first place.
Emacs and LLDB
Emacs and LLDB
Emacs and LLDB
Emacs and LLDB
Emacs and LLDB
Emacs and LLDB
Emacs and LLDB
Emacs and LLDB
Emacs and LLDB
If people are seriously in favor of LLVM being a long-term part of GCC, I personally believe that the LLVM community would agree to assign the copyright of LLVM itself to the FSF and we can work through these details.
The offer was conditional on integrating LLVM's features and goals into GCC -- features (modularity, extensibility, etc) that Stallman detests and is blocking in GCC to this day. From LLVM's point of view, it is a very good thing that nobody took up that offer!
Kastrup's comment
The current situation is not the outcome of a coordinated attack against the GNU project but rather the most obvious and natural consequence of our own actionsis spot-on and Stallman hopefully recognises it or can be made to recognise it.
Posted Feb 14, 2015 14:54 UTC (Sat)
by edelsohn (guest, #16472)
[Link]
Posted Feb 12, 2015 10:11 UTC (Thu)
by yaap (subscriber, #71398)
[Link] (6 responses)
On the other hand, as a guy involved in embedded development I'm a bit concerned about the future. Yes Clang/LLVM is open for mainstream architectures like x86 and ARM. But there are a lot of small CPU cores in embedded. Today a lot of them use GCC as they can't afford to develop a toolchain from scratch, so I can benefit from an open toolchain (although some of them sneak in licensing inside already). But one can see interest in some places in switching to LLVM, and considering how reluctant some are to provide their GCC sources I would expect at least some of them to provide a binary only and license locked LLVM based toolchain in the future. And that would be a big loss (I remember when I started and locked toolchains were the norm: yuck!).
Posted Feb 12, 2015 10:38 UTC (Thu)
by pabs (subscriber, #43278)
[Link] (5 responses)
Posted Feb 12, 2015 10:46 UTC (Thu)
by yaap (subscriber, #71398)
[Link] (4 responses)
The difference in the embedded world is that there is a lot of diversity and fragmentation. And there is not enough public interest to support an open toolchain. Just like the IP vendor depends on an open source toolchain because they don't have the resources to implement one from scratch for their architecture, most users do not have the resources to add this specific architecture support to either GCC or LLVM. So as a user you depend on the IP vendor for this.
Posted Feb 12, 2015 11:11 UTC (Thu)
by justincormack (subscriber, #70439)
[Link] (3 responses)
Posted Feb 12, 2015 14:20 UTC (Thu)
by pabs (subscriber, #43278)
[Link] (2 responses)
Posted Feb 12, 2015 14:34 UTC (Thu)
by yaap (subscriber, #71398)
[Link] (1 responses)
There are open source efforts (Mico32, Nios, 32 bits versions of RISC V, Leon...), and sometimes suitable (I've used some) but not always either due to lack of maturity, features or performance. Hopefully some will get there, for now in many applications it's not economic or practical to roll your own, so people turn to commercially supported IPs.
Posted Feb 13, 2015 10:56 UTC (Fri)
by oldtomas (guest, #72579)
[Link]
[1] <http://www.parallax.com/microcontrollers/propeller-1-open...>
Posted Feb 12, 2015 11:44 UTC (Thu)
by sorokin (guest, #88478)
[Link] (2 responses)
Many problems of gcc (ineffective data structures) and clang (redundant debug info generation) were discovered because there is alternative one an easily switches to. Could not the same be done to debuggers?
Posted Feb 12, 2015 20:55 UTC (Thu)
by mathstuf (subscriber, #69389)
[Link]
Posted Feb 21, 2015 9:07 UTC (Sat)
by sorokin (guest, #88478)
[Link]
Now I completely don't understand what this fuss is about. Emacs should just talk to debugger using MI interface and it doesn't matter whether it is GDB or LLDB.
Posted Feb 12, 2015 14:36 UTC (Thu)
by ejr (subscriber, #51652)
[Link] (34 responses)
I personally know of proprietary companies jumping on LLVM for the core with their non-free "value add" on top. They're having to re-invent things gcc already supports, and they're not releasing those. (Intel's OpenMP work isn't the first... Thankfully Intel is stepping up here.) These company projects are *not* giving back and are trying to lock up users with proprietary languages and extensions. If that isn't an attack on user freedom, I don't know what is.
But LLVM itself is *NOT* attacking GNU projects, and I doubt if any of the folks working on LLVM in the open are anti-GNU. I doubt if RMS considers that the concern. I suspect his concern lies with the lack of copyleft protection in a core area where companies related to LLVM have attempted license shenanigans.
Posted Feb 12, 2015 17:46 UTC (Thu)
by pbonzini (subscriber, #60935)
[Link] (2 responses)
I don't think RMS knows what companies related to LLVM have been doing, but he certainly understands that LLVM is a threat to copyleft (as you pointed out, GCC, together with Linux, is probably the most successful copylefted program) and as such to the GNU project's vision of software freedom.
Posted Feb 19, 2015 19:52 UTC (Thu)
by dakas (guest, #88146)
[Link] (1 responses)
Posted Feb 19, 2015 20:35 UTC (Thu)
by pizza (subscriber, #46)
[Link]
If, in order to utilize $specific_feature, you are forced to use a proprietary fork of LLVM, it doesn't matter how open/free the "central" part is, or how open or rapidly said central part is developed/improved. You are completely at the mercy of whomever provided that proprietary fork.
Look at Android if you want to see another example of how little anyone actually gives back to the "open/free" central core, and how you're generally forced to rely on proprietary forks if you want to utilize the vast majority of the devices on the market.
Posted Feb 12, 2015 18:24 UTC (Thu)
by pizza (subscriber, #46)
[Link] (21 responses)
And this is the crux of things. It doesn't matter that LLVM itself is "open source" if you're forced to use a specific proprietary fork in order to accomplish something meaningful.
Posted Feb 21, 2015 23:04 UTC (Sat)
by Wol (subscriber, #4433)
[Link] (20 responses)
I'm not arguing in favour of proprietary forks, I'm just more accepting of the economic realities that drive them. I would love however, to see a version of BSD that forced companies to distribute stuff as source on request. "You can distribute my code as part of a proprietary-copyrighted system so long as all your customers get the full source of their system on request".
The intention would be to protect customers should the software house go bust ... far too many closed-source programs become abandon-ware leaving customers up a gum tree ...
Cheers,
Posted Feb 22, 2015 2:19 UTC (Sun)
by pizza (subscriber, #46)
[Link]
FWIW, You just basically described the GPLv2.
(Though v3 is better at ensuring you can actually do something with the source code you've received..)
Posted Feb 22, 2015 2:36 UTC (Sun)
by pizza (subscriber, #46)
[Link] (18 responses)
...as opposed to being uneconomic to develop the whole thing from scratch, rather than taking advantage of a very large body of code they didn't have to pay for?
Copyleft licenses are the only meaningful way to ensure that the software commons is not neglected. Of course, that presumes one cares about the commons.
Posted Feb 22, 2015 2:43 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link] (17 responses)
The only answer is: "This package is indispensable". Right now there are basically no such relevant packages anymore.
That's a glorious victory, methinks.
Posted Feb 22, 2015 14:40 UTC (Sun)
by pizza (subscriber, #46)
[Link] (8 responses)
So...fund the development of everything yourself, instead of freeloading off of others' work. Somehow I suspect that will have an even greater effect on your business model.
I think Donald Becker (who wrote the majority of the earlier Linux network drivers) said it best -- when asked why he "gave away" so much work for free, his response was that he got the rest of the Linux kernel in return, and it was a great bargain.
> That's a glorious victory, methinks.
Perhaps, perhaps not. I'm not looking forward to the next round of the BSD wars, where nearly everyone "value-added" themselves into mutual irrelevance in the pursuit of short-term economic advantage.
Posted Feb 22, 2015 23:48 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link] (7 responses)
> I think Donald Becker (who wrote the majority of the earlier Linux network drivers) said it best -- when asked why he "gave away" so much work for free, his response was that he got the rest of the Linux kernel in return, and it was a great bargain.
Except that then GPLv3 came out and the companies got the message attached to it: "Cower on your knees, you stupid companies and thank us we don't require you to be publicly whipped to use our glorious software! It's not like you have alternatives. BWHAHAHA!"
> Perhaps, perhaps not. I'm not looking forward to the next round of the BSD wars, where nearly everyone "value-added" themselves into mutual irrelevance in the pursuit of short-term economic advantage.
Posted Feb 23, 2015 1:27 UTC (Mon)
by pizza (subscriber, #46)
[Link] (6 responses)
Android is a really lousy example, because the AOSP bears little semblance to what's actually on a random device one can purchase, and except in rare instances, "collaboration" is purely one-way, in the sense that every six months or so, Google performs a massive code dump on everyone.
Hadoop and the other Apache projects are independently governed, there's actual collaboration involved, and require an CLA (with explicit copyright and patent grants) in order to participate. Additionally, the Apache license has explicit patent grants and mutual-assured-destruction clauses that were the basis for what went into the eeeeevil GPLv3.
> Clang has been here for several years by now. So far there are no signs of proliferation of "value-added" crap.
Just off the top of my head, Apple's entire Swift language infrastructure, ARM's proprietary compilers, nVidia and AMD's shader compilers. More will undoubtedly come in time, and I'm willing to put a few dollars on a wager that in the long run LLVM will eventually be done in by a couple of big players throwing patents around in attempt to protect their "value-add" turfs.
Posted Feb 23, 2015 1:48 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (5 responses)
Patent MAD is fine with most companies, so that's also not a point. Besides, Apache License has much milder language than GPLv3 in that regard.
> Just off the top of my head, Apple's entire Swift language infrastructure, ARM's proprietary compilers, nVidia and AMD's shader compilers.
So yes, there are certainly dark corners with proprietary forks of LLVM, but they are utterly insignificant.
I'd wager that there's no risk of significant proprietary forks of LLVM and other liberally-licensed projects. It just doesn't pay.
Posted Feb 23, 2015 5:45 UTC (Mon)
by magila (guest, #49627)
[Link] (2 responses)
Posted Feb 23, 2015 6:00 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
Posted Feb 23, 2015 6:41 UTC (Mon)
by magila (guest, #49627)
[Link]
Posted Feb 23, 2015 13:01 UTC (Mon)
by pizza (subscriber, #46)
[Link] (1 responses)
It requires a CLA in order to *contribute upstream* but there's no "poison pill" clause in LLVM's license that prevents you from going after other users of LLVM without also losing the rights to use it yourself. That won't protect from NPEs (ie true trolls) but it's at least a start.
> Swift is likely to be open sourced soon.
That's really not much of a counterpoint. But we shall see, in any case.
> ARM proprietary compilers are pretty much dead.
Not by a very long shot. I know this because my employer just re-upped their licenses to the ARM compilers, which as of v6 are built on top of LLVM. Which brought many improvements, but it's still just as proprietary as before -- We stop paying, we lose the ability to take advantage of our own work.
> AMD mainlined their LLVM shader compiler
Oh, that's news to me, good for them.
> and NVidia uses a completely proprietary infrastructure (no LLVM) for their internal OpenCL system.
I'm sorry, nVidia is more credible than you: https://developer.nvidia.com/cuda-llvm-compiler
> So yes, there are certainly dark corners with proprietary forks of LLVM, but they are utterly insignificant.
That's how it always starts.
> I'd wager that there's no risk of significant proprietary forks of LLVM and other liberally-licensed projects. It just doesn't pay.
Come on, you've been around long enough to know that tangible short-term gains nearly always trump longer-term views.
Posted Feb 23, 2015 13:10 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link]
> I'm sorry, nVidia is more credible than you: https://developer.nvidia.com/cuda-llvm-compiler
However, it compiles into an intermediate language which is later optimized and executed by proprietary NVidia infrastructure.
> Come on, you've been around long enough to know that tangible short-term gains nearly always trump longer-term views.
Posted Mar 15, 2015 5:44 UTC (Sun)
by zenaan (guest, #3778)
[Link] (7 responses)
Why would you use software that someone else provides?
Go choose a proprietary software toolchain/ packages/ etc! Yes, that will incur proprietary licensing, per-seat distribution costs, support contract to get bugs fixed, and more!
Very appropriate for you to "suffer" such proprietary software grievances, since ...
> disclose my proprietary code? Even more,
... you seem to be all about developing your prietary code, and ...
> it might actually deny me some business models.
Business models are king! Profit rules! The only thing that matters is your right to make money.
Sounds like Cyberax is a corporation.
> The only answer is: "This package is indispensable".
Victory for persistence of potential for statute-enforced artificial monopolies ... ah, am I supposed to be enthusiastic?
Cyberax, your monetary and individual proprietary artificial (as in only in existence because of state-enforced statute laws) so-called "rights" appears to trump, in your mind, community, shared commons, the liberty part of libre-software and the like. You do know they say corporations are sociopathic in nature?
>> Not by a very long shot. I know this because my employer just re-upped their
Yet you "Cyberax" are the one promoting proprietary rights?!
> Anyway, do they contain any significant improvements?
Monetary and utilitarian "rights" or "arguments" seem to be your stock in trade at the moment.
"Cyberax", I didn't know you were such a proprietary-slut. Sad day...
Zenaan
Posted Mar 15, 2015 9:17 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link] (6 responses)
>> it might actually deny me some business models.
> The only thing that matters is your right to make money.
> Sounds like Cyberax is a corporation.
> Cyberax, your monetary and individual proprietary artificial (as in only in existence because of state-enforced statute laws) so-called "rights" appears to trump, in your mind, community, shared commons, the liberty part of libre-software and the like.
> You do know they say corporations are sociopathic in nature?
...
Ok, I'm back. Another social compact is destroyed, another community ruined and the world has become just a little bit more cruel. A nice day, all in all.
> Monetary and utilitarian "rights" or "arguments" seem to be your stock in trade at the moment.
1) Saner allocation of humankind's resources, avoiding unnecessary duplication of efforts and preserving the collective knowledge for everyone to use.
If it's the first one, then liberally licensed projects clearly win over the GPL. The Free Software movement has shown that the open source development model is clearly superior for pretty much any "commodity" software (except games).
So corporations are now vigorously contributing to liberally licensed projects, while lots of GPL projects are stagnating.
Posted Mar 15, 2015 10:08 UTC (Sun)
by dlang (guest, #313)
[Link] (1 responses)
and lots of GPL software is getting corporations "vigorously contributing" to them and lots of liberally licensed projects are stagnating.
(by the way, you do need to differentiate between GPLv2 and GPLv3+, there isn't "The GPL" any longer)
the real test for liberally licensed projects is to see if they survive after some of their developers take the software proprietary to found a company or if the project stagnates.
Some communities survive this, some don't. Until it happens, there's no practical difference between the program being licensed BSD or GPLv2
Posted Mar 15, 2015 22:43 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Practically the only major exception is Linux vs BSDs.
> (by the way, you do need to differentiate between GPLv2 and GPLv3+, there isn't "The GPL" any longer)
> the real test for liberally licensed projects is to see if they survive after some of their developers take the software proprietary to found a company or if the project stagnates.
Posted Mar 15, 2015 12:25 UTC (Sun)
by zenaan (guest, #3778)
[Link] (3 responses)
You say "proprietary code" is "sometimes a valid choice". I think I understand your position, yet I have no example to back up your position, so "Cyberax", I continue to hold your position is weak, pathetic, subversive and clandestinely premised.
By "proprietary code licensing is a valid choice", do you mean that your creativity is insufficient to otherwise provide for your survival by working commercially with libre/ copyleft licensed code, software stacks and corporations, and yet that your creativity is just high enough to eek out a survival by commercially licensing your code as proprietary?
I guess living in a world of amazing people, awesome opportunities and endless creativity in ethical and honourable abundance is just not your cup o' tea then eh?
Poor soul indeed ... locked in proprietary worlds of survival of the fittest, paucity of ideas and the meager supplicating 'protections' racket provided by those "awesome" government statute laws (that which creates proprietary monopoly rights at all).
Since you have no statutory right to combine "your proprietary code" with copyleft licensed code, your remaining option is to exercise your creativity to code without or wrest some yet-unexploited blood from the rock of BSD-licensed code, locking your results in a vault of survival from this cold, cruel world - might as well stand on the shoulders of some giant eh?
Now this looks like it ought to be sarcasm:
- Usually, when an LWN poster uses sarcasm, there's a refreshing, insightful, cutting and/ or poignant insight behind such use. Instead we see here pretense of sophistication masking belligerence - don't get me wrong and I grant s/he may have missed it, "I do respect your right to your opinion", but on the one hand Cyberax decries a principled approach ("forcing your ideology") to choosing how to develop software and/or a software stack, and yet he/she is unrelenting, unbalanced and contradictory in his/her own position... pretty sad effort really.
I take us back to "Cyberax"'s "glorious victory":
I called him on his/her sociopathic position, and he/she uses sarcasm to try and laugh it off thus:
Exactly how does sarcasm either justify or rationally brush off that sociopathic position, "Cyberax"?
Zenaan
Posted Mar 15, 2015 12:30 UTC (Sun)
by andresfreund (subscriber, #69562)
[Link]
Can you tone down the ad-hominem please? It's fine to disagree with Cyberax' position, in fact I do so more often than not, but these personal attacks seem to be uncalled for.
Posted Mar 16, 2015 1:39 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link]
I'm just observing that:
2) One of the best possible solutions is to make it profitable for multiple companies to work on a single project.
3) Liberal licenses are better in achieving this.
Do you have any objections? Decrying that the world is unfair and the evil corporations are intent on killing freedom is simply counter-productive.
Posted Mar 16, 2015 20:08 UTC (Mon)
by flussence (guest, #85566)
[Link]
Posted Feb 13, 2015 8:42 UTC (Fri)
by salimma (subscriber, #34460)
[Link] (8 responses)
Posted Feb 13, 2015 14:34 UTC (Fri)
by mathstuf (subscriber, #69389)
[Link]
Posted Feb 15, 2015 2:23 UTC (Sun)
by cas (guest, #52554)
[Link] (5 responses)
Remember, RMS's (and the FSF's) primary motivation is and always has been freedom (in both the short term AND the long term), not features or technology or convenience. If something is convenient now but likely to lead to a loss of software freedom in the future then it should be no surprise that RMS will argue against it....and history has shown that, more often than not, he will be right because he takes a longer view than mere short term convenience.
Posted Feb 18, 2015 20:45 UTC (Wed)
by k8to (guest, #15413)
[Link] (3 responses)
Both bother me, anyway.
Posted Feb 19, 2015 6:59 UTC (Thu)
by cas (guest, #52554)
[Link] (2 responses)
I'm far more concerned about Apple's intentions with LLVM's licensing, and RMS's "intransigence" is, as i mentioned, no surprise - he's been both open and consistent about his goals and motivations for decades. more to the point here, his stance is that software freedom is the end goal, and neither features nor convenience nor technological advantage are sufficient reason to divert from that goal.
IMO he's right - you're better off choosing free software over proprietary software even if the proprietary software is significantly better. and, in the long run, you're better off choosing free software that advances the cause of software freedom over open source software that does nothing for that cause or has licensing issues - and corporate history - that actively work against it.
Posted Feb 21, 2015 20:46 UTC (Sat)
by k8to (guest, #15413)
[Link] (1 responses)
But I don't feel at all convinced that copyleft over noncopyleft infrastructure is necessarily better. noncopyleft is sometimes more readily adopted, which can advance the cause of software freedom. copyleft is more resilient to co-option, which can advance the cause of software freedom.
If it's necessarily better to select copylefted software, then I guess I should write everything in Pike, because all the other languages have open specifications with non-copylefted and/or propriatary implementations or a single noncopylefted implementation.
Posted Mar 1, 2015 2:46 UTC (Sun)
by cas (guest, #52554)
[Link]
that's because freedom is a benefit that transcends software quality. there are many cases where proprietary software is better quality and/or has more features than comparable free software - but free software allows you to do things that you can not legally or practically do with proprietary software.
similarly copyleft software has the advantage over non-copyleft free sw that it actively promotes and enhances the cause of free software for everyone - with the only restriction being that you can't restrict the freedom of others to do whatever they want with the software or derivative works.
Posted Feb 19, 2015 14:08 UTC (Thu)
by dakas (guest, #88146)
[Link]
Posted Feb 17, 2015 13:46 UTC (Tue)
by nix (subscriber, #2304)
[Link]
Posted Feb 12, 2015 19:31 UTC (Thu)
by jwarnica (subscriber, #27492)
[Link] (1 responses)
Posted Feb 12, 2015 20:18 UTC (Thu)
by rahulsundaram (subscriber, #21946)
[Link]
If it so easily made, please make it.
Posted Feb 12, 2015 22:11 UTC (Thu)
by atai (subscriber, #10977)
[Link]
can I download the LLVM sources to build the compiler Apple ships on Mac OSX?
can I download the LLVM sources to build the compiler a SOC vendor ships as the compiler in their SDK?
I think it is important for gcc to stay healthy going forward and to be competitive, and it is good to contribute to a copylefted project. We have both GNOME and KDE. Can't we have both the GNU toolchain and the LLVM one?
Posted Feb 13, 2015 3:25 UTC (Fri)
by dennisdjensen (guest, #25165)
[Link]
Posted Feb 13, 2015 9:20 UTC (Fri)
by gebi (guest, #59940)
[Link] (20 responses)
In development clang is faster to compile and gives much better warning/error messages than gcc. (especially for C macros or C++ templates).
Posted Feb 13, 2015 14:32 UTC (Fri)
by mathstuf (subscriber, #69389)
[Link] (4 responses)
Posted Feb 19, 2015 12:58 UTC (Thu)
by mlopezibanez (guest, #66088)
[Link] (3 responses)
Posted Feb 19, 2015 13:00 UTC (Thu)
by mathstuf (subscriber, #69389)
[Link] (2 responses)
Posted Feb 19, 2015 13:22 UTC (Thu)
by mlopezibanez (guest, #66088)
[Link] (1 responses)
Perhaps I'm misunderstanding what you mean. Have you tried using -fmessage-length=100 to tell GCC to limit the output? In case of messages, they will wrap around so you don't lose any information but the caret line will be trimmed to fit in 100 columns.
Posted Feb 19, 2015 14:28 UTC (Thu)
by mathstuf (subscriber, #69389)
[Link]
Posted Feb 13, 2015 18:56 UTC (Fri)
by pizza (subscriber, #46)
[Link] (8 responses)
What versions are you comparing? (This comparison is only valid if you're comparing the latest releases of both; clang and gcc are both constantly improving)
Also, when you say "faster to compile", what's the optimization level? How do the binary sizes/execution speeds compare? Again, this comparison is only valid if you equalize all but the parameter you're trying to compare.
Posted Feb 13, 2015 20:51 UTC (Fri)
by mbunkus (subscriber, #87248)
[Link] (7 responses)
Both compilations use the very same settings, most notably among them with debugging options enabled, tons of warning messages enabled (and a select few disabled) and without any of the optimization options. All of this is running on a full up-to-date 64bit Arch Linux system which usually has the latest and greatest releases.
Without further ado here are the numbers as recorded by a simple »time …«:
gcc 4.9.2: 29m 24s
I haven't compared run time differences. First, this is about compilation speed, and during development compilation speed is the main bottleneck, so getting it down as much as possible is important. And second, the application itself is almost always I/O bound and not CPU bound.
Not saying that clang is better. But it sure as hell is faster. And I even though gcc has improved a lot I still prefer clang's error and warning messages.
Posted Feb 13, 2015 20:57 UTC (Fri)
by pizza (subscriber, #46)
[Link] (1 responses)
Posted Feb 13, 2015 21:43 UTC (Fri)
by mbunkus (subscriber, #87248)
[Link]
clang++ -std=c++11 -Wall -Wno-comment -Wfatal-errors -Wnon-virtual-dtor -Woverloaded-virtual -Wextra -Wno-missing-field-initializers -Wno-mismatched-tags -Wno-self-assign -Qunused-arguments -g -DDEBUG -D_FILE_OFFSET_BITS=64 -pthread -c -MMD -MF … -o … …
g++ -std=c++11 -Wall -Wno-comment -Wfatal-errors -Wnon-virtual-dtor -Woverloaded-virtual -Wextra -Wno-missing-field-initializers -Wlogical-op -g -DDEBUG -D_FILE_OFFSET_BITS=64 -pthread -c -MMD -MF … -o … …
Posted Feb 13, 2015 21:47 UTC (Fri)
by mathstuf (subscriber, #69389)
[Link] (4 responses)
ParaView (default settings with GCC):
(default settings with CC=clang CXX=clang++):
Builds were run with an otherwise-idle system, nuking ccache before each run. Versions:
clang-3.5.0-6.fc21.x86_64
Posted Feb 17, 2015 13:54 UTC (Tue)
by nix (subscriber, #2304)
[Link] (3 responses)
Posted Feb 17, 2015 14:06 UTC (Tue)
by mbunkus (subscriber, #87248)
[Link]
Posted Feb 17, 2015 14:50 UTC (Tue)
by mathstuf (subscriber, #69389)
[Link] (1 responses)
Posted Feb 19, 2015 0:38 UTC (Thu)
by mathstuf (subscriber, #69389)
[Link]
GCC:
Clang
Now if GCC could just use less system time like clang. Though, to be fair, GCC was run first then Clang, so that could be the warming up of the file cache by GCC during the Clang run (which doesn't help Clang's side here).
Posted Feb 19, 2015 13:00 UTC (Thu)
by mlopezibanez (guest, #66088)
[Link] (3 responses)
Examples? https://gcc.gnu.org/wiki/ClangDiagnosticsComparison
Or are you comparing GCC 4.2 with modern Clang? https://gcc.gnu.org/wiki/FAQ#gcc42apple
Posted Feb 19, 2015 13:31 UTC (Thu)
by rahulsundaram (subscriber, #21946)
[Link] (2 responses)
http://clang.llvm.org/diagnostics.html
Perhaps GCC 5 is better here? If so, the GCC page should be updated to do the same comparisons and/or show cases where GCC is better while comparing it to the latest Clang.
Posted Feb 20, 2015 12:47 UTC (Fri)
by mlopezibanez (guest, #66088)
[Link] (1 responses)
For the template diffing stuff, to be honest, we never had any request to implement such a thing (and in the diagnostics area, development is very much motivated by user-provided bug reports). Personally, I don't find it interesting enough to put the time to implement it myself, but if someone reports it and/or implements it, I'm sure it will be accepted. GCC already has the necessary information to do such a thing, it is a matter to implement the diagnostics part.
It could be a Google Summer of Code, for example.
Posted Feb 20, 2015 14:47 UTC (Fri)
by rahulsundaram (subscriber, #21946)
[Link]
Posted Mar 15, 2015 6:18 UTC (Sun)
by zenaan (guest, #3778)
[Link] (1 responses)
Since, like, firetruck freedom, coz, you know, utility features speed etc is all that matters, therefore, like, the debate is like, sooo settled like. So cool!
I'm reminded of a comment over the years:
<sarcasm? noooope, not me :)>
Posted Mar 17, 2015 6:39 UTC (Tue)
by bronson (subscriber, #4806)
[Link]
Posted Feb 13, 2015 16:48 UTC (Fri)
by rriggs (guest, #11598)
[Link] (6 responses)
Posted Feb 13, 2015 17:48 UTC (Fri)
by mathstuf (subscriber, #69389)
[Link] (2 responses)
Posted Feb 17, 2015 15:41 UTC (Tue)
by rriggs (guest, #11598)
[Link] (1 responses)
Whether designing GUIs for Android apps or managing complex pin assignments for an ARM microcontroller, one needs a tool like Eclipse to help get the job done quickly and efficiently.
Muscle memory can be retrained very quickly. Pro baseball players can still learn how to swing a golf club. Switching between Eclipse and Vi is no different. I use both every day. But I can rarely work effectively all day in only one tool.
Posted Feb 18, 2015 20:54 UTC (Wed)
by k8to (guest, #15413)
[Link]
Posted Feb 17, 2015 21:10 UTC (Tue)
by mister_m (guest, #72633)
[Link] (1 responses)
Posted Feb 18, 2015 21:00 UTC (Wed)
by k8to (guest, #15413)
[Link]
The short version is: codebases got bigger, and more powerful tooling to interact with them became more important.
You can get decent support for this kind of work in vim and emacs, but you have to be quite savvy to set it up, and it's a rare developer who does.
I certainly have never really looked to the FSF as a complete development tools provider though. Even in the heyday of gdb and gcc, I still relied on things like cscope and proprietary instrumentation tools.
Posted Feb 19, 2015 4:36 UTC (Thu)
by linuxrocks123 (subscriber, #34648)
[Link]
There are certain codebases where IDEs work well, and certain codebases where they don't. In either case it is certainly possible to code using a text editor and not lose much productivity; you just need (for example) DOxygen in a web browser so you can quickly look up API calls. Is it exactly equally as good, no, sometimes it's better and sometimes it's worse. I used an IDE in a project where I added stuff to the Java compiler and it was a boon to be able to use IntelliSense to find the right API call. I didn't even consider it with my current Python project because Python doesn't provide the static typing needed for anything like IntelliSense to even work.
This is just a dumb argument, partially because you can shift goalposts by calling Emacs an IDE or SlickEdit a text editor. I personally don't like setting up projects with classical IDEs and find they can be very brittle sometimes, but I'll use them when they're the right tool. But even if I didn't, I could get by fine without them, and I expect most good developers could, too. Browser-with-autogened-docs can replace most of the advantages, especially if you have two monitors. So, it really comes down to personal preference, so let's not argue Vi versus Emacs in its modern incarnation.
Posted Feb 13, 2015 18:42 UTC (Fri)
by bredelings (subscriber, #53082)
[Link] (27 responses)
Posted Feb 13, 2015 19:59 UTC (Fri)
by rahulsundaram (subscriber, #21946)
[Link] (25 responses)
Posted Feb 13, 2015 20:52 UTC (Fri)
by pizza (subscriber, #46)
[Link] (24 responses)
Citation, please. I'm particularly interested to see if it achieves both faster compiles and higher runtime performance *at the same time*.
> and the current limited advantage for GCC in some cases may not going to last for much longer. So while this is a relevant point for now I wouldn't really highlight it.
Why are you assuming that LLVM/Clang will continue to improve, but GCC will not?
Posted Feb 13, 2015 21:12 UTC (Fri)
by rahulsundaram (subscriber, #21946)
[Link] (23 responses)
Posted Feb 14, 2015 16:06 UTC (Sat)
by rsidd (subscriber, #2582)
[Link] (22 responses)
Posted Feb 14, 2015 16:28 UTC (Sat)
by PaXTeam (guest, #24616)
[Link] (21 responses)
if that were true then Microsoft and others would have already deployed CFI and other methods system-wide. low single-digit performance impact is tolerated at most, not >10%.
Posted Feb 14, 2015 19:45 UTC (Sat)
by dlang (guest, #313)
[Link] (20 responses)
If people were really that performance sensitive, they wouldn't be running scripting languages, .net and similar.
trading performance to get security will happen if they value security enough, if not (or if the security benefits are small enough), performance wins.
Posted Feb 14, 2015 20:19 UTC (Sat)
by PaXTeam (guest, #24616)
[Link] (19 responses)
Posted Feb 15, 2015 2:25 UTC (Sun)
by rsidd (subscriber, #2582)
[Link] (18 responses)
Posted Feb 15, 2015 10:26 UTC (Sun)
by PaXTeam (guest, #24616)
[Link] (17 responses)
Posted Feb 15, 2015 11:09 UTC (Sun)
by rsidd (subscriber, #2582)
[Link] (16 responses)
I can't find benchmarks between GCC-4.2 and the then-current LLVM, but here's the closest I can find -- various versions of GCC from 4.2.1 to a pre-4.6.0 with llvm-gcc and clang 2.8 (when gcc-4.2.1 was released, the newest llvm release version was 2.0). But even comparing llvm-2.8 (both versions) with the four-year-older gcc-4.2.1, llvm loses slightly on the benchmarks on that page -- hmmer (a bioinformatics program), 7-zip compression, lame MP3 encoding (it loses quite significantly on that last one).
Now, do you have any evidence for your claim that a 10%-20% runtime performance gap is important enough for Apple and Microsoft to trump other considerations?
Posted Feb 15, 2015 20:06 UTC (Sun)
by PaXTeam (guest, #24616)
[Link] (15 responses)
Posted Feb 15, 2015 22:56 UTC (Sun)
by dlang (guest, #313)
[Link] (2 responses)
I've been through a few compiler selection exercises at different companies, and in each case GCC produced substantially slower code (in some cases this pushed the company to not use GCC, in others, it didn't)
Posted Feb 15, 2015 23:34 UTC (Sun)
by PaXTeam (guest, #24616)
[Link] (1 responses)
> For most applications, runtime speed within 10% or 20% really doesn't matter.
what you said contradicts him, welcome to the club ;).
Posted Feb 16, 2015 3:43 UTC (Mon)
by rsidd (subscriber, #2582)
[Link]
Posted Feb 16, 2015 3:37 UTC (Mon)
by rsidd (subscriber, #2582)
[Link] (11 responses)
Posted Feb 16, 2015 11:26 UTC (Mon)
by PaXTeam (guest, #24616)
[Link] (10 responses)
Posted Feb 16, 2015 11:33 UTC (Mon)
by rsidd (subscriber, #2582)
[Link] (9 responses)
Posted Feb 16, 2015 12:25 UTC (Mon)
by PaXTeam (guest, #24616)
[Link] (8 responses)
Posted Feb 16, 2015 13:02 UTC (Mon)
by rsidd (subscriber, #2582)
[Link] (7 responses)
Posted Feb 16, 2015 13:41 UTC (Mon)
by PaXTeam (guest, #24616)
[Link] (6 responses)
Posted Feb 16, 2015 14:13 UTC (Mon)
by rsidd (subscriber, #2582)
[Link] (5 responses)
Posted Feb 16, 2015 15:40 UTC (Mon)
by PaXTeam (guest, #24616)
[Link] (4 responses)
Posted Feb 16, 2015 15:49 UTC (Mon)
by rsidd (subscriber, #2582)
[Link] (3 responses)
How much clearer can I be?
This is my last comment unless you follow up with a benchmark of your choice and the relevant gcc version.
Posted Feb 16, 2015 16:31 UTC (Mon)
by PaXTeam (guest, #24616)
[Link] (2 responses)
i never said that, but quote me back if you feel otherwise. what i did say was this:
> [...]the gcc they used at the time (4.2 and older, ones not under GPLv3)
there's some irony in that you talked about me not reading you carefully whereas it's clear that you misunderstood 'used [by Apple] at the time' as 'the current release of gcc at the time'. the two were quite different already exactly because Apple decided to stick with pre-GPLv3 versions of gcc. therefore the choice they had to make wasn't between gcc and clang versions du jour at all (which is what you've been trying to talk about).
Posted Feb 16, 2015 16:43 UTC (Mon)
by rsidd (subscriber, #2582)
[Link] (1 responses)
(Note that several phoronix benchmarks don't compile on llvm 2.8, it wasn't yet good enough technically: speed wasn't the issue. Also, there's nothing in gpl3 that should have stopped Apple using it, other than feeding paranoia.)
Posted Feb 19, 2015 17:04 UTC (Thu)
by dakas (guest, #88146)
[Link]
Patents are an entirely different game: a patent license is not restricted to only the code you contribute, and the most silly and trivial thing might be worth billions in bargaining power.
So I disagree with "there's nothing in gpl3 that should have stopped Apple using it". With a sane technology patent situation, that might have been the case. But there is no sanity in patents, so avoiding the GPLv3 in order not be cut off from windfalls for trivialities makes sense.
Posted Feb 13, 2015 21:19 UTC (Fri)
by mathstuf (subscriber, #69389)
[Link]
Posted Feb 20, 2015 21:21 UTC (Fri)
by toyotabedzrock (guest, #88005)
[Link]
Emacs and LLDB
Emacs and LLDB
Such locked toolchain would be a big minus for me and would definitely influence my choice of CPU IP. I hope it'll be common enough that it will make open source toolchain still a common choice. But there is definitely a risk there.
Emacs and LLDB
Emacs and LLDB
Emacs and LLDB
Emacs and LLDB
Emacs and LLDB
What I had in mind for deep embedded stuff is more like the Cortex M serie. So 32 bits, short pipeline with TCMs and maybe L1 caches but nothing more. The market is much more fragmented at this level.
Emacs and LLDB
Emacs and LLDB
Emacs and LLDB
Emacs and LLDB
Apple has a history with gcc.
Apple has a history with gcc.
Apple has a history with gcc.
he certainly understands that LLVM is a threat to copyleft (as you pointed out, GCC, together with Linux, is probably the most successful copylefted program) and as such to the GNU project's vision of software freedom.
The GNU project and the GPL were a reaction to academics and software company conspiring to make software closed that previously was developed openly and accessible to its users in academia and elsewhere.
The GPL and GNU were the weapon designed to work against making software proprietary, with the vision to regain a world where software was free.
Now LLVM is free, not due to the GPL though arguably due to the example and pressure the GNU project put on the market. So I have a hard time seeing it as a threat to the GNU projects's vision of software freedom. It isn't even much of a threat to copyleft: should Apple or somebody else do a heinous move on the central part of LLVM, it is likely that a workable community could be formed around a GPLed fork of LLVM.
So if someone wanted to seriously thwart LLVM serving a vision of software freedom, the GPL could become part of saving the day.
So in a somewhat amusing way, GNU and the GPL actually make sure that LLVM stays free, and they would even do that if GCC did not factor in the equation at all.
So unless some GPL-incompatible licensing change happens with the bulk of the LLVM community in support of that change, LLVM is not much of a stepping stone towards ending the free software dream. It just is not a weapon against proprietary compiler versions either. Which GCC is.
Apple has a history with gcc.
Apple has a history with gcc.
Apple has a history with gcc.
Wol
Apple has a history with gcc.
Apple has a history with gcc.
Apple has a history with gcc.
Apple has a history with gcc.
Apple has a history with gcc.
Yet that's what the industry has done. It turns out that there's a benefit in collaboration, so we have permissively licensed LLVM infrastructure, Android, Hadoop and others.
Certainly. And GPLv2 had been grudgingly accepted by companies - Apple used gcc, shipped Samba-based servers, used GNU utilities.
Clang has been here for several years by now. So far there are no signs of proliferation of "value-added" crap.
Apple has a history with gcc.
Apple has a history with gcc.
So does LLVM.
Swift is likely to be open sourced soon. ARM proprietary compilers are pretty much dead, AMD mainlined their LLVM shader compiler, and NVidia uses a completely proprietary infrastructure (no LLVM) for their internal OpenCL system.
Apple has a history with gcc.
Apple has a history with gcc.
Apple has a history with gcc.
Apple has a history with gcc.
Apple has a history with gcc.
I've no idea why people still use them. Anyway, do they contain any significant improvements?
CUDA support is _mainlined_ in LLVM: https://github.com/llvm-mirror/llvm/tree/a7f8f932a67badb2...
And so? I expect that a lot of companies are going to produce their "Super Mega Fork Of LLVM, Now With A Big Red Button!". However, they won't contain anything of interest.
Apple has a history with gcc.
> Right now there are basically no such relevant packages anymore.
> That's a glorious victory, methinks.
>> licenses to the ARM compilers, which as of v6 are built on top of LLVM.
>> Which brought many improvements, but it's still just as proprietary as before
>> -- We stop paying, we lose the ability to take advantage of our own work.
> I've no idea why people still use them.
Apple has a history with gcc.
Sometimes that's a valid choice.
> Business models are king! Profit rules!
You nailed it.
Not really, but it does matter the most when I choose what kind of software to use.
Close enough.
Yup.
Certainly. Excuse me, I have to go out and destroy another part of our society. Be back in a second.
What exactly do you want?
2) Forcing your ideology on everyone.
Apple has a history with gcc.
Apple has a history with gcc.
Examples being?...
Not really. GPLv2 was borderline acceptable for many companies, but liberal licenses were still preferable.
There are lots of successful examples here. If a project is interesting for a wide community then it usually survives.
Apple has a history with gcc.
> Why would I use a package that forces me to
> disclose my proprietary code?
> Ok, I'm back. Another social compact is destroyed,
> another community ruined and the world has become
> just a little bit more cruel. A nice day, all in all.
> Why would I use a package that forces me to disclose my proprietary code?
> Even more, it might actually deny me some business models.
> The only answer is: "This package is indispensable". Right now
> there are basically no such relevant packages anymore.
> That's a glorious victory, methinks.
> the world has become just a little bit more cruel.
> A nice day, all in all.
Apple has a history with gcc.
Apple has a history with gcc.
Just to clarify - I'm not forcing you or anyone to adopt BSD or other licenses. Nor do I wish to.
1) Free software projects eventually die if they do not have some kind of revenue stream to support their developers. It's doubly true for large projects that require close collaboration of many developers.
Apple has a history with gcc.
Apple has a history with gcc.
Apple has a history with gcc.
Apple has a history with gcc.
Apple has a history with gcc.
Apple has a history with gcc.
Apple has a history with gcc.
Apple has a history with gcc.
Apple has a history with gcc.
Apple has a history with gcc.
Still, the intransigence is making me more and more inclined towards avoiding Emacs and GCC.
Ah, real Emacs users can't avoid Emacs. We're locked in: the keybindings are wired into our souls. :)
Emacs and LLDB
Emacs and LLDB
Emacs and LLDB
Emacs and LLDB
Emacs and LLDB
For production code icc produces faster binaries in my cases than both gcc and clang do for normal situations and _much_ faster code for special cases with mkl+extensions.
Emacs and LLDB
Emacs and LLDB
Emacs and LLDB
Emacs and LLDB
Emacs and LLDB
Emacs and LLDB
Emacs and LLDB
clang 3.5.1: 15m 18s
Emacs and LLDB
Emacs and LLDB
Emacs and LLDB
ninja 3773.03s user 665.47s system 770% cpu 9:36.07 total
ninja 4597.47s user 484.16s system 755% cpu 11:12.89 total
gcc-4.9.2-1.fc21.x86_64
Emacs and LLDB
Emacs and LLDB
Emacs and LLDB
Emacs and LLDB
ninja 3505.65s user 616.39s system 769% cpu 8:55.85 total
ninja 4291.07s user 393.77s system 778% cpu 10:01.92 total
Emacs and LLDB
Emacs and LLDB
Emacs and LLDB
Emacs and LLDB
Emacs and LLDB
> ... clang is faster to compile and gives much better
> warning/error messages than gcc
> ...icc produces faster binaries than gcc and clang
> and _much_ faster code for special cases with mkl+extensions.
Oh, I didn't need that [pick any] freedom this week anyway...
Freedom-loving commie punk hippy looosers ...
I spray tha GPL nggggaaahhhhhhh.
<homer drool/>
Emacs and LLDB
Emacs and LLDB
Emacs and LLDB
Emacs and LLDB
Emacs and LLDB
Emacs and LLDB
Emacs and LLDB
Emacs and LLDB
Emacs and LLDB
Emacs and LLDB
Emacs and LLDB
Emacs and LLDB
Emacs and LLDB
Emacs and LLDB
Emacs and LLDB
Emacs and LLDB
Emacs and LLDB
Emacs and LLDB
Apple has been using llvm in one way or another since 2005. You are right that they went via llvm-gcc (which was the only C front-end for a while) but this only uses gcc's parser, the code generation is done by llvm. As for performance, I've been using all three compilers for a while and there was never a time when llvm was consistently faster than gcc, though now the gap is pretty small. 3-4 years ago it was icc > gcc > llvm, pretty consistently, for runtime speed, with a gap of 10%-20%. This was on certain bioinformatic programs that I wrote, and some third-party programs that I compiled; obviously it depends on what code you're running but this seems to be the "folk wisdom" out there.
Emacs and LLDB
Emacs and LLDB
Emacs and LLDB
Emacs and LLDB
Emacs and LLDB
Emacs and LLDB
Emacs and LLDB
Emacs and LLDB
Emacs and LLDB
Emacs and LLDB
Emacs and LLDB
Emacs and LLDB
Emacs and LLDB
Emacs and LLDB
2. I pointed out benchmarks showing gcc 4.2 slightly outperforming llvm 2.8, which is a release that occurred four years later.
3. I pointed out that a fair comparison would be between gcc 4.2 and llvm 2.0
4. I said that if you were wrong about it being gcc 4.2, I am willing to benchmark any CPU-bound program of your choice on the relevant version of gcc and the relevant (current at that time) version of llvm (llvm-gcc or clang as the case may be).
5. I claimed that the benchmark would show gcc handily outperforming llvm.
6. I claim that Apple made the switch despite a clear performance loss, for other (excellent) reasons. I claim that a 20% performance loss in CPU-bound tasks does not matter if there are significant other advantages.
Emacs and LLDB
Emacs and LLDB
Emacs and LLDB
Emacs and LLDB
Emacs and LLDB