Plug-In Architecture On the Way For GCC 342
VonGuard writes "This year marks the 25th anniversary of the GNU Operating System. A major part of that system has always been the GNU Compiler Collection. This year, some of the earliest bits of GCC also turn 25, and yet some of the collection's most interesting years of growth may still be ahead. The GCC team announced today that the long-standing discussion over how to allow plug-ins to be written for GCC has been settled. The FSF and the GCC team have decided to apply the GPL to plug-ins. That means all that's left is to build a framework for plug-ins; no small task to be sure. But building this framework should make it easier for people to contribute to the GCC project, and some universities are already working on building windows into the compilation process, with the intent of releasing plug-ins."
So why do I want plugins in my complier? (Score:4, Interesting)
Re:So why do I want plugins in my complier? (Score:5, Funny)
Spell check.
How spell check could work in a C compiler (Score:3, Informative)
Re: (Score:3, Insightful)
that sames more appropriate for an IDE. if you have the spell check in the IDE, you can easily identify and immediately fix typos as you code. waiting for the compiler to spell check your code is like building a spell-checker into your printer driver or PostScript interpreter.
since most modern IDEs already feature syntax highlighting, which typically comes with function lists, symbol databases, and a live parser, it would just be a simple matter of integrating an additional user dictionary to the parser so
Re: (Score:3, Interesting)
Re:So why do I want plugins in my complier? (Score:5, Funny)
So you can watch trippy visualizations while you compile.
Re:So why do I want plugins in my complier? (Score:5, Informative)
Go to the GCC Plugins Wiki [gnu.org] & search for "Potential use cases".
Nice (Score:5, Interesting)
Mod me as a troll if you must but... People ought to read the link given by the parent. Wow.
Nice. You know, in a very funny way, the FSF and their jiahad against the evils of proprietary software are basically creating their own twisted form of DRM. Witness this brilliant idea:
Nice. The Linux kernel guys did this and look at the result--it is a bitch for hardware guys to write drivers for Linux. I'm sure deliberately altering the API with a script will work really well for the GCC guys! Makes me want to participate. Not! In truth, it makes me feel like I'm some kind of criminal--only guilty until proven innocent.
Sadly, the FSF did some very nice things, but I think they are becoming so extreme they are going to marginalize themselves and fade away. You know what the biggest hurdle for the BSD guys go separate themselve from GPL? The compiler. The compiler really is the last bit of power the FSF holds over the open source world as a whole. Pretty much every other bit of the toolchain has been replaced with a non-GPL lisence except a good compiler.
LLVM seems to be coming along nicely with major players backing it. I'd be pretty nervous if I was the FSF.
Re:Nice (Score:4, Insightful)
Nice. The Linux kernel guys did this and look at the result--it is a bitch for hardware guys to write drivers for Linux
Bullshit. The result is that it's a bitch for proprietary guys to write binary only drivers for linux.
And you know - why should the GCC & Linux projects make things easy for the proprietary guys? It's not like the proprietary guys go out of their way to make life easier for OSS.
Re:Nice (Score:5, Insightful)
Because biting the hand that feeds you have never been a good strategy. There's not enough open hardware - free operating systems are still dependent on the goodwill of proprietary vendors to be able to support mainstream hardware with anywhere near the same features and performance as users of proprietary OS take for granted.
Granted, this may well change soon, but until then making it hard for hardware developers to provide good Linux drivers is just making things harder for Linux users who have no interest in being dragged into your religious wars.
Re:Nice (Score:4, Insightful)
Not the developers; the users of GCC benefit (are "fed") by the availability of plugins, proprietary or no. I assume that most developers of GCC are also users, so this benefits the developers as well.
Also, I would hope that the developers of a popular software package would see fit to act in the best interests of their users, rather than fight stupid religious wars over which of proprietary/open is better. Fact is we'll always have both kinds of code, so we should try to get along with each other rather than fight pointlessly.
Unfortunately many free software advocates are more than happy to fight these wars, because they put ideology above the goal of creating great software, making them no better than the greedy corporations they so despise.
Re: (Score:3, Interesting)
And there are tons more use cases than that! My research group has a complete plugin system already implemented for GCC, and I've written a few plugins for it.
I've got plugins that put hooks in for all sorts of variable access, function call and lock events so I can put in custom debugging code. My current project involves collecting statistics and detailed logs for these events in the Linux kernel.
Because the compiler knows so much data-flow and type information, we also think that these plugins could be
Re: (Score:2, Interesting)
Can someone explain what kind of plugins might be made? What extra functionality wold I want in a compiler?
Static analysis [mozilla.org].
Essential plugin (Score:2, Insightful)
I thought GCC (Score:5, Funny)
... was a plugin for emacs.
Re:I thought GCC (Score:4, Funny)
... was a plugin for emacs.
Well, duh. Everything is a plugin for emacs.
Re: (Score:2, Funny)
Re:I thought GCC (Score:5, Funny)
Re: (Score:3, Funny)
And Emacs is a plugin for what?
Woah, woah, let's not get into Metaphysics here ;-)
GPL to plugins? (Score:5, Interesting)
Does this mean they want to force all plugins to use the GPL? How is that possible? I was under the impression that the GPL is purely a distribution license. It comes into force when you distribute software licensed under it, and requires you to distribute (or make available) source code and other things.
If I write a plugin and do not distribute it with GCC, what legal basis do they have to force me to GPL it? Nothing I distribute is copyrighted by the FSF, and so how can their distribution license apply to my code? I'm confused.
Re: (Score:2)
Its if you distribute it at all, not if its distributed with GCC.
There is a clause in the GPL about how other software can interact with it.
Plugins have to be GPL.
Re: (Score:3, Informative)
Umm.. no. This is exactly why RMS is so against GCC having a plugin framework. IF (and only if) you don't distribute GPL code with the plugin THEN you are free to place your plugin under any license you like.
Reminds me of this incident [gnu.org].
Re:GPL to plugins? (Score:5, Interesting)
Re:GPL to plugins? (Score:4, Informative)
No it's not Bruce. It's exactly what has been said by legal representatives of the FSF.. http://gcc.gnu.org/wiki/GCC_Plugins [gnu.org]
Re:GPL to plugins? (Score:5, Informative)
Bruce
Re:GPL to plugins? (Score:4, Interesting)
Sorry for the multiple replies.
Friend of mine once pointed out that practically the whole "let's GPL the library so any apps that use it have to be GPL too" strategy has been thoroughly dismantled by the BSD community.
Consider libedit. It's a BSD-like licensed replacement for libreadline - RMS's favorite example of "strategic" non-use of the LGPL. It's binary compatible with libreadline. So you can create your app and link it to libedit and happily distribute it under the BSD. To claim that libedit is somehow a derived work of libreadline because it has the same binary interface would be absurd. However, many installation scripts make a symbolic link from /usr/lib/libedit -> /usr/lib/libreadline.
That's the strong case for dynamic linking == derivative work.. plugin frameworks have always been the weak case. If the strong case doesn't stand up anymore, how can the weak case?
Don't get me wrong, I don't want to see proprietary plugins for GCC anymore than I like seeing all the proprietary modules for the Linux kernel. But claiming there is some clear legal principle that makes them a copyright violation is a joke.
Re: (Score:2)
Re: (Score:3, Interesting)
define "bad". RMS thinks proprietary plugins would be bad because he thinks everything proprietary is bad.
But let me give you an example. I once worked at a company called Codeplay in the UK. They made compilers, proprietary compilers, and one of their biggest markets was the Playstation 2. Everyone used GCC to develop on the PS2. Ok, a few people used Metroworks' compiler - whatever. So they were directly competing with GCC. Our C++ support was horrid. Our C support was better, but one of the thing
Re:GPL to plugins? (Score:5, Informative)
from a quick look at the mailing list it appears to me the problem is
1) company produces new hardware
2) company produces proprietary plug-in to produce asm for their hardware platform
3) they do not open their specifications
4) they are able to take advantage of GCC and its front ends while using a closed backend
5) ???
6) profit
I may by wrong as i said this is just a quick read of the javabyte code discussion somebody linked to from here.
Re:GPL to plugins? (Score:4, Insightful)
And this is bad because...
Because it violates freedoms 0 to 3? The whole reason for GNU's existence?
Re: (Score:2)
There are a couple of problems with what the BSD folks think they have done. First, the BSD license is GPL-compatible, so nobody's going to sue them for infringement. Thus there is no case law to tell us if they are right or not. Second, the fact that libedit has the same binary interface as libreadline and perhaps does something that libreadline does (I haven't tried it) doesn't make it 100% clear that libedit is not derivative of libreadline. Third, if the distributor of proprietary software were to arran
Re: (Score:3, Insightful)
According to the GPL, BSD-like-licensed code that is distributed in binary form must be accompanied by the full corresponding source code or an offer to provide the source code valid for 5 years (or whatever). That's what the BSD nerds are complaining about.
There's no case law that even suggests that copying an API can result in a copyright infringement. That's SCO all over again.
Re: (Score:3, Interesting)
It's not just that the API is duplicated, it is that the duplicate is made to be dynamic linked to the main work. The closest thing we have had to a dynamic linking case was Nintendo v. Goloob Games. That was about the Game Genie plugging between the Nintendo console and the game cartridge. It's not entirely germane to what we're talking about here. Over the 20 years we've been talking about dynamic linking,
Re: (Score:3, Insightful)
Second, the fact that libedit has the same binary interface as libreadline and perhaps does something that libreadline does (I haven't tried it) doesn't make it 100% clear that libedit is not derivative of libreadline
doesn't that make wine a derivative of windows
Re: (Score:3, Insightful)
If in the real world they distribute a plugin which calls an api entrypoint in the gcc plugin framework, how would they tell it not being a derivative work?
Because work A being a "derivative work" of work B is defined to mean that A includes material from B. Program C calling a function in program D does not mean that C includes part of D, so it does not make C a "derivative work" of D.
Whether A is a "derivative work" of B from the perspective of copyright, and whether it is derived from B from the perspective of scientific/academic attribution are separate questions.
Re: (Score:3, Informative)
This is really bad advice. If your plugin is not distributed with the GPL software, it's still a derived work.
Mmm I suspect in the area of plugins at least this opens a serious can of worms. If the GCC team write a decent stable plugin architecture with a well documented API and then someone goes and writes a set of BSD header files from that documentation then the argument that it's a derived work gets a bit strained.
If the FSF continue to push that line then we start to move toward the territory of trying to copyright facts about interfaces which after the SCO fiasco most in the free software community might be
Re: (Score:2)
If there is a requirement for modules to identify their licensing, as with Linux, it may be that FSF changes their license to require that such identification be accurate, and that the rejection of improper licenses by the software remain intact. This is a sort of anti-DRM. FSF turned copyright on its head, why not DRM too?
Re: (Score:3, Interesting)
Re: (Score:2)
Of course, since you don't need any license to distribute software that isn't a distributive work under copyright law, even if it "interacts with" another piece of software, such a license term has dubious effect.
Re: (Score:2)
Re: (Score:2)
If it's run-time linked to a GPL work, it's probably a derivative work anyway.
As far as the plugin host is concerned, it's a data file that happens to run as code when run. The plugin just has to adhere to some specification (and I'm sure that somebody will reverse-engineer the spec, if it's not publicly available just as text). That doesn't make it a derivative work.
Re: (Score:2)
Reverse engineering is a means of avoiding trade-secret protection, not copyright. In the case of GCC, it's fully disclosed, and it's not at all clear to me that a document good enough to allow a working plugin would not be derivative.
But I suspect that this is all moot. If FSF puts a plugin mechanism in GCC, they're probably going to modify the license attached to it, too.
Re: (Score:2)
Reverse engineering is a means of avoiding trade-secret protection, not copyright.
What about the clean-room BIOS (re)implementation for the IBM PC clones?
Re: (Score:2)
it's not at all clear to me that a document good enough to allow a working plugin would not be derivative.
That is the point of the reverse engineering. For example, Wine is reverse engineered, and no one seriously claims Wine is derivative of Windows source code.
Re:GPL to plugins? (Score:4, Insightful)
Re: (Score:2)
You actually raise an excellent point because the GPL can only be enforced on redistribution of either the original work OR a derivative work based on the original GPL'd code. In this case, the FSF wants to say that the plugins are derivative works... but unless you actually include GPL'd code in your plugin, there is no way for them to force you to distribute the code as GPL. Now, the GCC developers may try to entice developers into making a derivative work by giving out a GPL'd "skeleton" plugin that ha
Re: (Score:2)
Require all plugins to link against a small (512 byte or so?) GPL'ed blob, and check for it at load time.
Re: (Score:2)
The FSF could let the TIVO hole work _for_ them -- Require all plugins to link against a small (512 byte or so?) GPL'ed blob, and check for it at load time.
That has been tried before, and the courts said it doesn't work that way.
News article [cnet.com] that mentions an older case (while discussing one that was ongoing):
The outcome of the case that article was abou [wikipedia.org]
Sega v. Accolade (Score:2)
Require all plugins to link against a small (512 byte or so?) GPL'ed blob, and check for it at load time.
The wiki article [gnu.org] mentions this legal theory. Search for "A gcc-based scripting interpreter could by default check for a mandatory license statement". But other companies have tried this in the United States, and courts have rejected the originality (and therefore the copyright) of such magic cookies. Look up Sega v. Accolade (pre-DMCA) and Lexmark v. Static Control (post-DMCA).
Nothing More Than GNU/Panic Over LLVM/Clang (Score:2, Interesting)
All the exciting complier action going on now is with LLVM and Clang. It's incredibly clean and modern code. It has an free and open non-viral license.
The GNU crowd sees it as a massive threat to the stranglehold GCC has over open source compilers. This is nothing but a desperation move by GCC to try to fend off the massive migration to LLVM that is going on. The GNU crowd has been acting in ways that would put Microsoft to shame in their efforts to keep their stranglehold on compliers. All the way from the
Re: (Score:3, Informative)
Does this mean they want to force all plugins to use the GPL? How is that possible?
A plugin uses the host application's API. It is, therefore a derived work. In the case of the GPL, derived works must be distributed under compatible licenses.
Some applications allow plugins or modules under incompatible licenses, but in those cases, it is the applications' authors prerogative to grant exceptions for plugins.
Re: (Score:2)
How does using an API make your software a derived work? By that logic every program that runs on Windows is a derived work, since you're using Microsoft's API.
Does Microsoft get to dictate your license because your software runs on Windows?
Re: (Score:2)
A plugin uses the host application's API. It is, therefore a derived work. In the case of the GPL, derived works must be distributed under compatible licenses.
It's only a "derivative work" of the application if it contains actual copyrightable stuff from the application. Things required purely for interoperability (like, say, function declarations or the data structures required by those functions) don't count.
Back when the IBM clone PCs [oldcomputers.net] came out, the clones had reverse-engineered and reimplemented BIOS code, very much derived from the original (copyrighted) BIOS. But it wasn't a "derivative work", because copyright covers the actual code itself, rather than what
Re: (Score:2)
Re:GPL to plugins? (Score:5, Informative)
A plugin uses the host application's API. It is, therefore a derived work.
From Sega V. Accolade [eff.org]:
Computer programs pose unique problems for the application of the "idea/expression distinction" that determines the extent of copyright protection. To the extent that there are many possible ways of accomplishing a given task or fulfilling a particular market demand, the programmer's choice of program structure and design may be highly creative and idiosyncratic. However, computer programs are, in essence, utilitarian articles - articles that accomplish tasks. As such, they contain many logical, structural, and visual display elements that are dictated by the function to be performed, by considerations of efficiency, or by external factors such as compatibility requirements and industry demands. Computer Assoc. Int'l, Inc. v. Altai, Inc., 23 U.S.P.Q.2d (BNA) 1241, 1253-56 (2d Cir. 1992) ("CAI"). In some circumstances, even the exact set of commands used by the programmer is deemed functional rather than creative for purposes of copyright. "[W]hen specific instructions, even though previously copyrighted, are the only and essential means of accomplishing a given task, their later use by another will not amount to infringement."
Even if the header file can't be legally copied verbatim, you can write a new header file that's API-compatible and not be infringing. Good thing, too, or the Wine folks would be in some serious trouble.
Re:GPL to plugins? (Score:5, Interesting)
More precisely, the exception states that if the end compiled product is built with non-GPL compatible plugins, then the end compiled product is subject to the licenses of the linked libraries using the exception. As at least some of those linked libraries are subject to the GPL (being part of GCC) then the end product will be subject to the GPL. If you want to propagate (distribute) the end compiled product, it needs to be a GPL-compatible program, which then means that any libraries linked with it need to be GPL-compatible too, which prevents proprietary libraries linked in. If you do not propagate the end compiled product, then no problem.
So, long story short, if you have a non-GPL plugin, then either (1) the plugin must be GPL-compatible, (2) the plugin can't affect the end compiled product, or (3) the compiled program must be GPL-compatible and not be linked with anything non-GPL-compatible (say, a proprietary plugin). Basically, they want to prevent plugin writers the ability to lock down a GPL program by requiring that it be compiled with the proprietary plugin. I think there is a loophole in (3), so I hope I did not misunderstand it.
Re: (Score:2)
Clever, so it's not the license of the GCC they're using to enforce this rule, but rather the license of the standard libraries.
Of course, one could always replace those GPL'd libraries with non-GPL'd ones, but that's starting to increase the amount of work required.
Re: (Score:3, Insightful)
The solution for the problem is very simple, if you don't to release your software as GPL code - don't use GPL code as a base for your software.
Thus if you don't want to write GPL code, don't write a plugin to GCC. Instead write some other software that has nothing to do with GCC.
If you want to write software and base it on GPL code, the least you can do is to return the favor and also release your own code as GPL code.
The GNU project is based on the old tradition that if you are nice to others so will ho
Re: (Score:2)
Okay, so if I write a fairly configurable plugin that takes a configuration file (that just happens to be compiled machine code) and at run time (compile time that is) my plugin calls into this configuration file (read non-GPL library) to do its work well then I'll just make my plugin available under the terms of the GPL license. Of course it won't work to well without the configuration file but that is just data, obviously I don't need to redistribute my data under the GPL. Well sure my plugin isn't very
Re: (Score:3, Interesting)
I'm not g
25 years of .... (Score:3, Interesting)
This year marks the 25th anniversary of the GNU Operating System.
No, this year marks the 25th year of work on the GNU OS. There is still no GNU OS as such, and it's pretty obvious there never will be.
I'm not saying that there's nothing to show for all that work. The GNU libraries and many GNU utilities are key components in many projects, not the least of which is Linux. (<Sarcasm> Oh, excuse me, GNU/Linux.</Sarcasm> ) These are real achievements, and so is the introduction of a new collaborative model of joint software development.
But the original goal of GNU, to create a free alternative to Unix, has never been achieved. No big loss, there are other free Unix alternatives and even true Unixes for free. I just wish that GNU and its fanboys would stop and ask themselves why they never achieved their primary goal.
Re:25 years of .... (Score:5, Interesting)
That's because it takes thousands of people to make an OS.
Look at Microsoft and their lines of OSes.. They have what, 50k people on staff at any one time with perhaps 2/3 of them doing programming work? Most of their code is already written from buy-oughts, so they now provide mostly maintenance and scripting. There's maybe 20-50 people doing *interesting* stuff at any one time, it being 10 years away.
Look at OSX now. They have a similar issue, but leveraged theirs away by choosing a FreeBSD-like platform which to design everything on top of. They also reduce features for their core GUI programs to reduce testing and errors. They also focus much more aesthetically, in direct comparison to Linux GUIS and Windows. And their equipment is much higher priced (can buy 2-3 laptops of the same quality of 1 mac laptop), considering they discourage Hackintoshes.
The Linux guys ad to design everything from the ground up, because of the choice in license. It was also a NiH kind of "I can do it better" kind of game, because Linux was new and exciting. But development still requires large resources. Linus happened to be the appropriate coder/manager to herd the cats at the bottom. Then everything else fell into place: some by luck and others by necessity.
FreeBSD: Its THE academic system, and it works well. It's a traditional fork from SYS I which they license it very openly. There's work done on it, but the "cool" work is Linux. The BSD's are perfect for stability, file sharing, and network code. It has a healthy set of adherents and users, but mostly is relegated to core network technologies.
Now, we look at HURD.. It's there, with a Debian/HURD system install possible. It's there's few device drivers, even fewer developers, doesnt work with basic equipment, buggy as hell (because few developers), and there's something that's "Just As Free", and works to boot (Linux). Would the FSF be better off on discontinuing the HURD? Probably, but it's their choice, and we dont know what its possible uses are yet either.. There's always a critical mass which things like these hit that make them explode, and they might be right about making their own kernel.
Re: (Score:3, Insightful)
Huh? You're saying GNU didn't have enough resources? Then how did Linux ever achieve critical mass? Which certainly doesn't have much more in the way of resources, given that their code bases overlap so much.
The difference between GNU and Linux is not resources. The difference is the people running the show. RMS is on a holy mission; Linus just wants to get the job done.
Re: (Score:3, Insightful)
That's because it takes thousands of people to make an OS.
AST debunked that years ago [cs.vu.nl]. And now that minix is available under a free license there is nothing to stop the FSF calling it the GNU OS.
Re:25 years of .... (Score:5, Insightful)
This year marks the 25th anniversary of the GNU Operating System.
No, this year marks the 25th year of work on the GNU OS. There is still no GNU OS as such, and it's pretty obvious there never will be.
I'm not saying that there's nothing to show for all that work. The GNU libraries and many GNU utilities are key components in many projects, not the least of which is Linux. (<Sarcasm> Oh, excuse me, GNU/Linux.</Sarcasm> ) These are real achievements, and so is the introduction of a new collaborative model of joint software development.
But the original goal of GNU, to create a free alternative to Unix, has never been achieved. No big loss, there are other free Unix alternatives and even true Unixes for free. I just wish that GNU and its fanboys would stop and ask themselves why they never achieved their primary goal.
Having tried to get involved a few years back, I think I know why. While I don't deny the extree skill of some of the gnu programmers, GCC, Emacs and Gnuplot are ample evidence of this, they lack, or seemed to lack then, any form of cohesive organisation.
There was a distinct impression that if you didn't code in C, you weren't good enough, and that little use should be made of widely available, and equally free technology, because it wasn't 'hard core' enough, or so it seemed. There certainly was no logical reason for it. They spent, in my opinion, far too much time trying to write clever code, and not enough time trying to make things easily accessible for prospective new members. Since those new members would probably bring in new ideas and fresh impetus, I'd have thought this was a priority. Attracting some managers would have helped.
Their mailing list for Hurd showed their problem quite well. In spite of there being plenty of solutions available for spam filtering, they used nothing, which took me somewhat by surprise. This meant I ended up having to sift through literally hundreds of viagra and porn emails each week to try and follow something.
I asked someone else about it, and he had a script he ran himself to clear the spam. Very clever, very geeky, but very useless for those who think they shouldn't have to do that themselves to make such a mailing list usable.
I gave up after a couple of months, with a much better idea why we never got Hurd.
Re: (Score:2)
Having tried to get involved a few years back, I think I know why. While I don't deny the extree skill of some of the gnu programmers, GCC, Emacs and Gnuplot are ample evidence of this, [snip]
Ah, gnuplot has nothing to do with GNU or the FSF. From the gnuplot FAQ [gnuplot.info]
Re: (Score:3, Funny)
NO NO NO! They do NOT need to ask themselves that! If they do, they'll form a committee to go about finding a way of answering the question. After years of deliberating, that committee will decide another committee is better suited, and send them off into the desert for 30 days and nights, to search for their spirit guide.
Upon their long-hair-bearded-and-sandalised return, they shall proclaim that the original committee was mistaken in their decision, and call for a review on the whole process.
Years down th
Arrogance (Score:4, Insightful)
To quote the rationale document:
This is the kind of ideological arrogance that drives me up the wall with the FSF and GPL. There is this over riding presumption that they're right, and further more, anything contrary to their aims is "Bad for society". What childish bullshit.
It's not even as if they soften it by making it a question of belief. They could just as easily say "We believe developing non-free software is not good for society". The absolutism in their position reminds me of religious fundamentalism. Which also bugs the shit out of me.
Re: (Score:2, Funny)
Of course, this was posted anon to avoid reprisals from the faithful.
Re:Arrogance (Score:4, Informative)
Sorry, no. They stated their opinion. Here is a newsflash for you: nothing is absolute. Should everyone prefix their opinions, assumptions and even what they think is a fact, with a disclaimer that it's just their opinion, and not to worry, but there is no free software god that is going to send all Microsoft devs to hell?
Lets see;
"I believe evolution is the best explanation."
"I believe you need 3 AAA batteries."
"I believe my hair is on fire."
I am sorry to have to point this out to you, but it's the FREE SOFTWARE FOUNDATION. I think that anyone capable of understanding the English language would be able to recognize that it is their opinion, politically-correct belief disclaimer or not.
That means all that's left is to build a framework (Score:4, Funny)
Re:That means all that's left is to build a framew (Score:5, Interesting)
Or just do what the rest of us are doing...? (Score:3, Informative)
It says on the LLVM website FAQ, "GCC is licensed under the GPL license. clang uses a BSD license, which allows it to be used by projects that do not themselves want to be GPL"
The LLVM site is registered in the name of Chris Lattner who works for Apple.
What the FAQ ought to have said is, "clang uses a BSD license, which allows it to be used by projects which wish to take the source code, close it, and profit off the backs of those who contributed without rewarding them."
Go ahead and hack on LLVM, but don't
Sean Callanan... (Score:3, Informative)
Sean Callanan, a graduate student at Stony Brook University, has created a plugin system for GCC. It's been languishing in a branch for the past year or so.
Many people have wanted this branch to be merged from trunk, but a few people with licensing concerns have blocked it in the past.
Re:It's Linux, NOT GNU/Linux!! (Score:5, Funny)
why do people still try to attach GNU/ to Linux? It makes no sense.
Me? I run Gnu/KDE/Xorg/Gnome/vim/perl/rxvt/Fluxbox/Firefox/Java/Linux
Re:It's Linux, NOT GNU/Linux!! (Score:5, Insightful)
Re:It's Linux, NOT GNU/Linux!! (Score:5, Funny)
but most of the third-party software which gets installed on top has been touched by the hand of gnu somewhere along the lines
I delight in reminding your that gnus don't have hands, they have hoofs!
Re: (Score:2)
It's GNU/Linux if it's not uClinux (Score:4, Interesting)
but trying to run an open source based box without any of the software that gnu has touched is pretty hard
I for one say "GNU/Linux" to distinguish an operating environment designed for a workstation or server from embedded Linux. It's possible to run a useful box, especially one handling embedded style workloads such as IP packet routing, with very little FSF-owned code. A "uClinux" environment might use uClibc or Newlib instead of glibc, uClibc++ instead of GNU libstdc++, and BusyBox instead of Bash and GNU Coreutils.
Re: (Score:2)
Re: (Score:2, Insightful)
Given that nobody mentioned Linux in either the summary or the article, one can only assume you're trolling.
Re:It's Linux, NOT GNU/Linux!! (Score:4, Insightful)
The article claims that GNU has produced an operating system, and that GCC is somehow the cornerstone of that "operating system". I don't think the word means what GNU thinks it means. And Stallman's insistence on calling Linux "GNU/Linux" is part and parcel of that misconception.
Re: (Score:3, Insightful)
GNU has produced an operating system. It's nowhere near as advanced in functionality as Linux, but it exists, and GCC one of the largest parts of it.
It's true that Stallman is a self-important man who makes himself look arrogant by delineating that GNU tools are part of the operating system but not making the same claim for a whole slew of other important tools.
But however correct the OP's statement, I agree with the reply made to it that the fact it comes apropos of nothing indicates it's a troll.
Re: (Score:2, Insightful)
But however correct the OP's statement, I agree with the reply made to it that the fact it comes apropos of nothing indicates it's a troll.
Only in as much as the original poster is a troll, then. The plugin system for GCC could have been discussed in a purely neutral manner if the article hadn't been submitted with the business about GCC being part of an operating system. GCC may be what compiled the operating system, or what developers use to develop for the operating system... but it's not part of an operating system. The fact that we're even discussing this implies the submitter's comments were trollish, IMHO.
If the article was supposed
Re: (Score:3, Insightful)
While I agree that "GNU" is not an operating system in any sense of the word (unless you include poorly-designed experimental attempts like HURD), it should be said that a compiler is an absolutely essential component to any operating system.
That popular operating systems ship without a compiler is only a sign of those systems being broken. If you aren't provided with a tool that lets you tell the system how to operate, you haven't got an operating system.
Re: (Score:2)
GNU Operating System (Score:5, Funny)
That depends on your definition of "has produced". GNU certainly is actively developing an operating system, but I would say that an OS project that has managed to go 25 years without a stable kernel release cannot fairly be said to "have produced" an operating system.
Re: (Score:2)
So? The issue isn't whether GNU has produced lots of useful free components that have been incorporated in various OS's. Its the claim that it "has produced an operating system".
Re: (Score:2)
Hurd was released in a working state?
I must have missed it.
Re:It's Linux, NOT GNU/Linux!! (Score:4, Insightful)
Well, the meaning of the word 'operating system' is subective of course. But the goal of GNU since the start was always to produce a UNIX-like operating system. And the UNIX operating system was always a lot more than just a kernel, it included tools, a shell, a compiler, etc. From the UNIX perspective, the GNU definition of 'operating system' makes perfect sense. Now if you're coming from the microcomputer persective, where an "operating system" was nothing more than the kernel and possibly a shell, you'd obviously be more inclined to simply label the kernel as an operating system. On the other hand, back when DOS was created, it barely would've been considered an operating system by the folks using UNIX and VMS. Indeed, DOS would barely qualify as an operating system today, especially considering what modern BIOSes can do.
Re: (Score:2)
Comment removed (Score:5, Funny)
Re: (Score:3, Interesting)
why do people still try to attach GNU/ to Linux?
Ah, the great Gnu/Linux naming controversy [wikipedia.org]. It's a long page for a short issue, but if you really want to kill a tree, try printing the talk page, instead.
You know that there's zealotry involved when the argument for justification of a single sentence is longer than the entire article.
Re: (Score:2)
Point me to the planet on which that's relevant to the issue at hand.
We're talking about "GNU/Linux" vs. "Linux". "Linux", as defined by its creator, is an operating system kernel. By definition, using that name refers to an operating system kernel, not to ANY "project" including GNU.
GNU, on the other hand, is a project to c
Re: (Score:2)
Except, that we don't call it Grub/GNU/Xorg/KDE/Linux. We don't call it by everything we attach to make a minimal distro. We simply call it Linux, because for the people that use Linux, the kernel is the only completely consistent aspect. The GNU tools are probably the second most consistent aspect of any Linux usage, but Linux does not completely depend on using the GNU tools.
Re: (Score:2)
The kernel is far from completely consistent; it's patched and selectively built on almost every distro. If anything, libc, bash, and the gnu core utils and toolchain are the main consistencies.
But this is a silly thing to argue about, since we're obviously not going to agree. Let's agree to disagree :)
Re: (Score:2)
Re: (Score:3, Insightful)
Exactly! HURD is the kernel, Emacs is the operating system.
Re:Operating System? (Score:4, Funny)
More precisely:
No, the hurd is the (still incomplete) kernel, GNU is the (still incomplete) Operating System.
Re: (Score:3, Funny)
Poppycock. That's utter BS, and you know it. If Windows wasn't reliable enough, then it wouldn't be so popular, even for servers. I find Windows to be more reliable and stable than my Mac Book Pro running OS X 10.5.x, and that's based on UNIX. Stop the childish FUD.