Slashdot Mirror
GPL and Project Forking
Norm writes "Linuxcare is running an informative article about project forking and how the GPL serves to prevent forking in many cases; a good expose on a timely subject, given recent fears about kernel forks, etc.. " Being at Comdex, I've heard a lot of people wondering about why Linux stays together, questions about what the GPL means and how it works. There seems to be a lot of confusion about what different distributions actually mean.
Forking is not the big issue people think it is. Usually the fork is necessary to, say, test out a new idea (egcs for example), or because the current development has gotten stale (gimp). In both cases there was negligible impact on the users. egcs has superceded gcc, and has done so without incident. There are major differences between the internals of gcc and egcs. Gimp development has been "revived" (some question if it was ever dead!), and everything is happy in linux land.
--
I think reviewing this old slashdot feature ("TurboLinux Releases "Potentially Dangerous" Clustering Software?") in the light of this newer article is particularly interesting - folks were worried that turbolinux might have a clustering solution. A clustering kernel is pretty specialized, and would have pretty much the same qualities that the article recognized as being required for a code fork.
Question: If the code does fork, do they still call it Linux, or is that just going to create confusion?
-Denor
I seem to recall, say about a year ago, the answer to everything regarding the benefits of open source was essentially: just fork it!
You have the source code, you have your bright ideas (so you think), and you want make some software better. So open source, being open source, would promote better software by allowing anyone to fork the code to increase the quality of the software. I think even Netscape was used as an example. If you don't like the browser, build your own from the pieces of Netscape that do work (can you do this with the Netscape license?).
But lately, with folks talking about forking the actual Linux kernel, forking seems to be the bad answer.
I think instead of arguing over forking, the argument should be over freedom of choice. Whether you fork or not, it's GPL. If someone likes your forked code better, isn't that success? If someone doesn't likes your code and stays with the original, isn't that success?
Who gives a hoot to forking? I have the Linux that I have. I have all the source code I need. If I ever learned programming, I could do more about it. Since I don't, I can hire somebody to do make changes for me. If there is a better feature, I'll just add it. But, I figure, if it's really that cool of a feature, someone else will add it to the current Linux kernel or other open source software as well.
The short answer or question is: Who's going to take the software (or OS) away?
Still, I'd like to count how many times forking was discussed as a benefit to open source before it seemed to become a dirty word lately.
~afniv
"Man könnte froh sein, wenn die Luft so rein wäre wie das Bier"
~afniv
"Man könnte froh sein, wenn die Luft so rein wäre wie das Bier"
Richard von Weizs
This article is quite well done. The scope is not that large, so he doesn't get bogged down in all the usual license bickering. He does make a reasonably good case for why the GPL dissuades certain types of forks, and why OS in general dissuades forking over all. I find the comments on the BSDish license promoting (a) fork interesting but underdeveloped.
The idea that a lot of non OS people are having difficulty getting is that for a fork of an OS project to be effective, there must be some sort of 'collective' agreement that is a good idea by (a significant part of) the community using that project. In many cases this is simply not going to happen. But it does allow the fork to occur when sufficient people believe it is neccessary (ie gcc->egcs->gcc).
I think the examples he gives are useful for neophytes and others who wonder what a fork is all about. I'm glad he resisted the urge to go into the muddled history of some of them in great depth --- that can be found elsewhere on the net/usenet if you really need to read about how obnoxious some people behave in the name of protecting there favorite project...
S.
Why is it that every person i have ever heard proclaiming the usefullness and flexability of Linux has claimed that forking the code is a possability, and a great idea. But whenever it makes Slashdot news people rise like religious zealots to knock it down? "Don't mess with our source!" They say. Well, its my source too, its all of ours, and we can change to fit our needs, and we should. If we change it for the better, it may cease to be a fork, if we change it for the worse, it'll probobly just die off. Code forking is at the heart of the gpl, and almost crucial to its effectiveness.
--Nuintari
slashdot : where an opinion can be wrong.
We still have the situation that GCC v2.95 Or Higher Still Out Of Favor For 2.2.3pre11
(That has changed recently, but Linus was refusing "EGCS compatibility" patches for rather a while there...)
Recently discussed.
If you're not part of the solution, you're part of the precipitate.
There is a lot of misunderstanding in the Windows World about the different Distros.
In my Place of employment people think Software has to be re-writen for each distro, or at the least re-compiled. They get this idea from industry magazines that mindlessly push the M$ FUD.
I try to point out that it's no worse than software differences between NT and 95 etc, but that at least I can re-compile if I need to...
Tokyo Joe
The argument in the article is 100% right on mark. However, I was just thinking... all this only works if the GPL is actually enforced. A large company could easily come along, take GPL code, add stuff to it, and make a proprietary product out of it (ignoring the GPL). If nobody takes legal action against this, it would just result in the "bad" forking scenario among the Unices. Does FSF enforce the GPL this way (not just for their own software)? Would we have enough funding (and manpower?) to enforce the GPL should the need arise?
(Note: I'm not being critical of FSF or GPL or whatever, this is just my consideration.)
mikre he sophia he tou Mikrosophou.
in the article, the example is given of a hypothetical Linux fork called "fooware os" and the additional hypothetical that the perpetrator of fooware is a crack ninja programmer with an army of software ninjas straight out of a bruce lee film.
one alternative not explored was suppose the fooware ninjas come up with a cool thing and Linus says, "no way, that's not going into the kernel." in this case, the coolness of the cool thing increases pressure on the system to either accept the patches into Linux, or switchover form Linux to Fooware.
what's lovely is how OpenSource routes around intransigence. we're all human, nobody's perfect, and the character traits that make us great software developers also cause us to get in our own way. when that happens, the fooware os fork becomes a Good Thing.
Also, hidden in the fork between gnu/emacs and xemacs was the different programming styles. the procedural versus oo indicates that team based projects will probably stick with OO or easily modularized projects, and gnarlie "keep it all inside one head" projects will be one-great-man projects. the risk of the gnarlies is the death or disinterest of the one-great-man. note how OO and componentized strategies favor open source teaming.
sorry, i'm stating the obvious.
I'd suggest a read of Jakob Nielsen's column on writing microcontent. Some useful snippets:
Also, the impact of good headlines can be seen in this article on the cost of poor information on intranets, but is relevant to anything that has a large number of readers -- though the economics aren't as direct.
If Hemos spends 5 extra minutes writing a clear, concise headline, and that saves 10,000 slashdot readers 5 seconds of scanning and thinking each, then that's a gain of 49,700 seconds for the /. community.
pooptruck
Not all forking is bad. Where two groups intend to take a project in mutually incompatible directions, there should be a fork. For example, if one group wants to make the Linux kernel work well in multi-processor scenarios, and another wants to make the Linux kernal into an RTOS, there might be changes that each would need to make that would be incompatible with the other. In a case like this, there should be two different versions of the kernel, because they are justified by the very different goals of the two groups (before I get flamed, this is just a hypothetical scenario -- as far as I know an RTOS multiprocessor kernel is perfectly feasible -- but there must be some situations where incompatible goals spawn incompatible code).
What open source development discourages is bad forking. For instance, if I went into the Linux kernel and made a bunch of trivial changes to suit my tastes, without any real benefit to others, my forked kernel would sit there gathering dust -- no one else would work on it. That would be a bad fork. A good fork is one which is justified for a good reason, and for that reason it is supported by a community of developers willing to work on it.
Just my random thoughts on the matter.
-Steve
Democracy is a poor substitute for liberty.
See, for example, the "Pragmatic Idealism" essay on the FSF's Web site. NeXT made an Objective-C front end to the GNU C compiler, and wanted to make this front end proprietary. The FSF's lawyer told them this would violate the GPL, and NeXT gave in.
send all spam to theotherwhitemeat@ropine.com
Look at SGI's contributions. Linus nixed a few and incorporated others. No offense intended to Linus, but I'd certainly trust SGI to have a lot more knowledge of what makes an OS scalable compared to Linus. That's their territory. It's not his fault though. Those machines cost $$$, so no developer is going to independantly purchase one just to develop a more scalable SMP kernel.
I would not even call the multiple desktop problem a true "forking" issue, since I don't think that the desktops started from a common source.
In the short term, you have a host of competing desktops, all trying to be The One True Desktop. However, since it is more professional pride/ego than dollars motivating development, the competition is more likely to be a footrace than a demolition derby. That is, I don't expect the GNOME and KDE guys to put any work into keeping the other from working well.
What will happen? Binary Darwinism. The poor interfaces will die out, and their good features and good developers will be at least partly absorbed by the better ones. Eventually, there will be either One True Desktop, or Several True Desktops that the user can choose from.
The Open Source community can afford to "burn" effort making multiple attempts to solve the same problem; indeed, I think that we can't affort not to. The diversified desktops of today will show us what a good desktop would be like, and the myriad will merge back to one or several.
--The basis of all love is respect
Think of the ability to fork as a fire hose. You generally don't want to use a fire hose, because the huge volume of water will cause significant damage. But if you have a bad fire in a building, the fire damage is a bigger problem then the water damage would be. So you turn on the water. The analogy isn't perfect, but it works. The GPL allows the code to be forked if things need it badly enough. However, the overhead of having an entirely seperate project often is not worth it. Thus, people generally approach forking with caution.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
For example, the article states that "Lucid Emacs" was proprietary, and implies that it predates the GPL. Both are false: Lucid Emacs was based on GNU Emacs 18. Lucid Emacs and Xemacs have always been released under the GPL. And the aricle left out one major reason why a merge would be very difficult: The Xemacs people do not require copyright assignments for donated code, and Stallman does require such paperwork.
The history of the gcc/egcs/pgcc is also very misleading.
Finally, Stallman did not write glibc. The original author/maintainer was Roland McGrath; the current author/maintainer is Ulrich Drepper.
The mention of non-free BSD-based commercial Unixes implies that these implementation came after the release of the free BSDs and the AT&T lawsuit; they long pre-date both.
Sorry, you're wrong. (If you're going to pick nits, get the facts right!)
(and so on, through 2.6 = 5.6.)
(released long after Solaris 2.0 due to customer backlash).
Oh, and
Hope that helps...
The article was very well written and insiteful but didn't convince me that forking isn't really a threat. It also minimized the impact on productivity that forking has caused.
Today, the different Linux distros can cause a headache for people dealing with product installation issues, usually with scripts. This isn't so bad because most UNIX people are already used to that. But it does scare off software companies. Think about it, for Windows, you just buy InstallShield or Wise and most of the problems of OS differences are taken care of. Not true for Linux today.
It gets worse at the API level. If the Linux kernel forks and the APIs contain minor annoying incompatibilities, it will be just as bad as the UNIX days of old.
I'm a strong advocate of Linux mainly because it is Open Source. I feel the advantage of this is huge, but mainly for developers. Developers need to be able to trust that the APIs they are using a) work as advertised, b) can be fixed quickly when they don't and c) aren't subject to the whims of a particular profit driven organization. Open Source, and in particular GPL'ed code guarantees those things. Nothing else does.
These benefits aren't immediately visible to the consumers (ie. the non-programmers who just use a computer to get something done). But the benefits do trickle down, when the code they use can be made more reliable and can safely incorporate innovations. The time spent reinventing the wheel for minor variations of operating systems could be spent doing useful innovations.
Realistically, freeware will never replace commercial applications, and I don't want it to. What I want to see is new products with genuinely new features, and I'm willing to pay for them, with or without source. Those new products will come a lot faster if there is a common API to work with. There will always be competing versions of products, but at some point there will be features we come to expect of all of them, and the advantages to the different versions of the products become trivial. At that point, it makes more sense to standardize on a freeware version, and forget all the others. I believe at this point in time, there are not enough technical advantages to the competing operating systems to warrant their existence. It is a detriment to everyone's productivity. Therefore, it's time for an Open Source OS to move to the forefront, and Linux is the closest of any to doing that.
Right now there is one major fork in the Linux world, and that's GNOME vs. KDE. This is particularly nasty, because there really is no way to develop software that supports both. (I mean totally supports both, not just using some common subset of features) This is a long-term threat to the viability of the OS for commercial development. Let's get real, they both are trying to accomplish mostly the same goals: a common look and feel for graphical applications. As long as they both fight for mindshare, that won't happen! I really hope at some point in time, one or the other surrenders, and concentrates their efforts on taking the useful innovations they have and putting them into the other, so we can all get on with things.
If you really want Linux to replace Windows, stop arguing over petty differences and work together to build an OS that truly offers all the advantages that Windows currently offers.
I mean "design forking," not code forking. I haven't been around long enough to know what the original X desktop was, but I bet there was one. And someone wrote a better one. Someone else, too. That's great, because now there are three good desktops, and each will make the others better. It also sucks, because each one has a camp of devoted followers, each developing to a different paradigm. It's not the division of labour that concerns me. That's almost always productive, useful, and good. The struggle for user-mindshare, however, is always bad. I don't want to learn to use apps, I want to use apps. Binary compatibility is not enough -- I, Joe Sixpack, want ergonomic compatibility too. This is not a question of Linux "winning." Linux doesn't need to win. It simply is. My concern is simply about Linux making my life easier, sooner. Your point about E-Darwinism is a good one. I must, however, quote Keynes' refutation of Adam Smith: "In the long run, we are all dead." That said, I hope you're right. Autumn
Through the GPL, the author of a program is unilaterally granting permission for the recipient to copy the program -- under certain circumstances. If the recipient doesn't want to abide by the terms of the GPL, that's fine -- but then the recipient, under copyright law, then has no right (except for the usual fair-use conditions) to copy the GPL'ed program.
By contrast, shrink-wrap or click-wrap licenses try to give a software vendor more power than mere copyright law grants. That's why they have these "if you click this button you are agreeing to these ten pages of fine print" messages. They (might) create a contract between the vendor and the consumer: in exchange for the privilege of using the vendor's software, the consumer agrees not to reverse-engineer it, not to benchmark it, not to install it on more than one computer, etc., etc. Under copyright law, the courts would laugh at restrictions like this, but if clicking on the appropriate button does create a contract, then the vendor can enforce the license through contract law.
(As contracts, click-wrap licenses are iffy, because by the time you see the license, you've already coughed up your money and taken the disk home, and the click-wrap license is now trying to renegotiate the terms of a sale that's already taken place. But that's an argument for another thread.)
Disclaimer: IANAL.
send all spam to theotherwhitemeat@ropine.com
I think that if Stallman were here, he would say that songs are different from computer software and so that the same thinking doesn't apply.
Songs are not source code that is translated into machine code. We generally do not have access to the ``source'' for the music, only to the performance, which is captured by recording the sound waves.
The GPL is special in its requirements related to the relationship between the source code and compiled code; in other respects it is a license that permits free distribution of something.
If it is the free distribution that you object to, then it's meaningless to have a debate about the relative merits of various freeware licenses, all of which permit free redistribution of the source.
Anyway, the GPL protects primarily the freedom of _users_, not the freedoms of those who want to profit by making software proprietary. Stallman has argued that this is not really freedom, but the exercise of power. (As in power == control over things that affect others, freedom == control over things that affect yourself).
And yes, it makes this stuff hard, because it becomes a combinatoric nightmare. If people would
- stop repeating this nonsense of there being One True Linux
- recognize that the vendors like Redhat, Corel, SuSE, and all the rest of them will always try to differentiate themselves from one another
- admit that for all the intents and purposes of people who are making and installing these applications, it is for them a different OS
If those steps could happen, then perhaps progress can be made. I don't think that they will be, however, because too many people have too much ego wrapped up in the myth. Which is a crying shame, because defining a problem out of Platonic existence rather than admitting its reality and repercussions helps nothing but the propaganda machine. It interferes with real people trying to get real work done. And it's so obviously a half-truth as to make plenty of folks look a lot more closely at other assertions held as Gospel.Well, if by X desktop you mean the non-open CDE (which may be an open standard that you can buy, but is not open source), yes, there may be an original X desktop.
But X users have not been able to agree on a window manager: Motif, OpenLook, fvwm, tvwm, WindowMaker, dtwm (CDE's) and so on. Most well-behaved X programs will be usable under any window manager, so people pick the one they like best.
Sun has a desktop envrionment of their own and offers CDE; IBM used to have their own but forced everyone to switch to CDE or just use plain Motif; I think HP did something similar; NeXT had a desktop which predated CDE (and which a number of the Linux desktops and window managers mimic).
The point is, there was no one X desktop environment to fork. Had the X server itself forked on Linux, that could become a serious problem. (X is already forked; every vendor's X is proprietary and closed source. XFree86, XFree68, and so on are the only open source X servers I know of... that can actually render on a display.)
The X base code is free, but derivative works do not have to be free. Since the base code does not support any display hardware, we have vendor forks for every UNIX, plus the XFree* forks.
Fortunately, people only mess with the device driver side, and so X programs continue to work across many window managers, and display properly on different remote systems.
Somewhere out there is a company collecting the best part of the GNU/Linux work, adding their own code with intent to repackage. This is what the open source movement should be afraid of.
In today's anti-piracy climate, woe to whoever is caught! The horribly bad publicity alone arising out of discovery wouldn't be worth it.
Let's look at this closely: suppose that someone does take GNU code and incorporates it into a proprietary product. Does a truly cutting edge company need to steal code? You are playing catch-up if you need to steal.
Secondly, what if someone does that? At best, they will buy themselves reduced development time on some isolated project. The real benefits of the code, namely openness, will be lost. People using the main development stream will get the latest features and bugfixes, and the pirates will be locked into playing catch-up. They can't openly advertize that they have stolen code, so if the code really has a great reputation, they can't boast of it. They can't actively participate in the development process.
Thirdly, no serious company is going to risk it. I know that in my company, nobody would even want to hear of such as thing as GPL'ed code being incorporated into our products. If we use free software, we evaluate the licenses carefully. It would be foolhardy to do otherwise.
There is plenty of useful code out there which has licenses that are more permissive than the GPL. Particularly things that provide some generic, low-level functionality such as, say, compression.
humphrm wrote:
I don't disagree with you philosophically, but take Red Hat (please!): RPMs, directories in different places, etc. etc. Granted, not "kernel" mods, but "different" -- and significantly different (IMHO) than any other Linux distro. Yet,
nobody but nobody has adopted their modifications.
Other than Mandrake, Macmillan, LinuxPPC, and a horde of other distributions. Last I checked, the LSB project has determined that RPM will be the standard file format for Linux packaging. That's why Debian is working on becoming less package-format dependant.
I'm not a kernel geek, but I'd be willing to bet that there are kernel differences too.
Red Hat generally ships its kernel with the AC patches compiled in. Most of the elements of the AC patches find their way into the main kernel tree eventually.
e.g. you can't be a Debian admin and just walk off the street and admin a Red Hat box.
It's certainly easier to go between the various Linux distros than it is to go between the various commercial Unixes. I had little problem going from Slackware to Red Hat, personally. I don't see how a Debian->Red Hat or Red Hat->Debian migration would be harder than that, likely it will be easier.
----
----
Open mind, insert foot.
The article says that Solaris is under the SCSL.
It does? I certainly didn't mean to imply that. Clearly, Sun Microsystems is contemplating such a move, but has not released the source code except possibly under NDA to some of its close business partners.
If I did imply that, than I must have been rather sloppy. Understand, please, that the whole thing got written on a laptop machine last Saturday, to occupy my mind as I waited in a hospital waiting room for my girlfriend to get medical attention. And I was seriously ill with a case of the 'flu. I'm surprised it came out as well as it did.
-- Rick M.ska wrote:
I find the comments on the BSDish license promoting (a) fork interesting but underdeveloped.
The article doesn't say the BSD license is more prone to forking than the GPL, but it does comment on the fork from 386BSD to FreeBSD/OpenBSD/NetBSD/BSDi. It says that fork is stable because of the different focuses of the different forks. GPL programs are just as likely or unlikely to have forks which persist due to such differences in focus.
Note BSDi in the above list, however. It points out one reason to fork that BSD permits but the GPL doesn't, license change. If someone wants to fork a project because they want to distribute their modifications with more license restrictions than the original, BSD allows it and GPL doesn't.
[Disclaimer: I am not saying that either BSD or GPL are better because of this difference, only that this is a notable difference]
----
----
Open mind, insert foot.
EGCS compatibility is somewhat different; it represents some examples of cases where Linux was not conforming to the official standards of how C is supposed to work. (Largely regarding treatment of pointer aliasing, I believe...) Linux has arguably been made buggy in doing things that C isn't supposed to support, but which GCC used to.
Conformance to standards isn't a "feature" in the way many kernel facilities are...
Consider that I didn't mention GGI as an example; it is an example of something that was initially rejected, and quite legitimately so, as the proposed implementation was not, three years ago, developed, debugged, and perfected. Interestingly, the recent framebuffer support is now the GGI support; they don't need to integrate big gobs of stuff as they have the crucial interface that they do need, with the benefit that it has made supporting some of the more obscure systems ( e.g. - Atari ST and such) easier.
If you're not part of the solution, you're part of the precipitate.
That's not the problem. It's not academics, really. Rather, the fault lies with those zealots who claim that anything running a Linux kernel Linux, as though that were all that mattered. Remember how they like to flame the BSD people for having 4 different operating systems while they steadfastly claim to have just one? It's a political stunt with no basis in matters practical. In fact, this whole "distro" jazz is a veiled euphemism to hide the fact that there are a zillion different Linux operating systems out there. Sometimes they're just repeating what they've heard, not understanding that "distro" is a cutsie dodge to avoid saying "operating system".
But to someone trying to develop, produce, test, distribute, configure, install, and adminstrate this applications software, they are different operating systems. Stop playing games to make your team seem less splintered than it is. The benefits of pretending the Emperor is wearing lovely new clothes are not, in my opinion, of greater import than the real-world ramifications of living a lie. People are trying to get honest work done, and this kind of crap just doesn't fly when you get down in the trenches.
That capacity to reduce diversity to a single monoculture is the _main_ reason Windows viruses are so nasty. It's the reason most Windows people are using one particular interface that is jack of all trades, master of none. It is not a good thing at all.
The only reason people think it's a good thing is because until recently there has been no evidence to suggest you could survive doing anything else. Hence, the emotional reaction is 'we must all do this or die!'. First of all, Linux is still around without doing that (and indeed growing, and indeed there are still other options neither Windows nor Linux), and secondly, this assumption was formed from observing a monopoly at the top of its form and making every effort to kill off everything resembling 'diversity'.
If even this has not made the 'monoculture', everybody-runs-Windows approach safe and beneficial to all, what good would it be to try and make Linux a monoculture, with all the disadvantages it brings, but with none of the ability to exert corporate power and influence and throw around huge sums of money?
Seriously. That'd be a _phenomenally_ bad tactical move.
It's not possible to develop any closed source commercial software for KDE without reimplementing everything. Therefore all the closed source applications will be Gnome.
Will this make a difference? I think so; many of us especially in commercial environments have to use at least one binary-only tool (even if we wish we could get rid of it)
Yes it does. The copyright holder can do ANYTHING with GPL software he wrote. Sell it as a closed product or whatever. What you speak of is "Public Domain" software. They are not the same thing.
--fatboy
Uh, because SunOS 4.x and SunOS 5.x aren't totally compatible? You should have said "...to work with SunOS 5.x", not "...to work with Solaris." Because Solaris 1.x and Solaris 2.x are incompatible in the same way as SunOS 4.x and SunOS 5.x.
Saying ``SunOS software doesn't work on Solaris'' is obviously false, because Solaris 1.0 was SunOS 4.1.1. So your use of the word ``Solaris'' is wrong.
No, ``Solaris includes SunOS'' is true without qualification. You should have said SunOS 5 when you meant SunOS 5, not Solaris (which can mean either SunOS 4 or 5, despite what the ambiguous common usage is.)
Not that anyone really cares... ``Solaris'' means ``SYSV'' in most people's minds just like ``hacking'' means ``breaking into computers.''
This is true.
This does not follow. If the goal is to have only GPLed software and no non-GPLed software, then the GPL is necessary.
You assume that to have lots of free software, there must be no non-free software, which is obviously not the case. If 10% of the world's software is free and 90% is non-free, then increasing the amount of software in the world would increase both the amout of free and non-free software (assuming the ratio held.) This is called ``growing the market'' and it benefits all who participate in that market, even if they are direct competitors.
So there are cases where non-free software can help the goal of having lots of free software. In fact, given that very nearly every piece of free software is a clone of some piece of non-free software, one could argue that non-free software is a necessary catalyst for free software! Would GIMP be as good today if they didn't have Photoshop to mine for ideas? Much though I respect the GIMP developers, I most sincerely doubt it.
Also note that the GPL is not the only license that is considered a ``free software'' license, even by GPL advocates. Don't say ``free'' when you really mean ``GPLed.''
This OS is all about what you want!
/src/usr/kernel (haha!). Lots of sed time must be spent to fix a dir name like that, and we have many more dir names that also violate the LSB, as well as general common sense (much like our IPO plans).
More communist programmers, more indignant code, and less code tyops!
We have forked the code, and are in the process of patching in more rude comments! Yeah!
On top of that, we have an exclusive (but GPLed) program for finding and fixing common tyops in the code. This is already hard at work on our copy of the kernel for ICO.
On top of that, to make sure no-one can steal our One True OS, we are making it completely incompatible! HAhah! Red Hat, your pathetic efforts to make your distro un-de-forkable are NOTHING compared to our pissing on Linux(r) standards! Want the source to the kernel? No problem, go look in
Not to mention our amazing new package format -- but we won't even tell you about it, as you'll never be able to use it (and you thought RPM's false dependency messages were evil).
As a sign of our affection for our users, we have posted this to Slashdot. We wait for you to abandon Linux(r) for ICO!
Btw, we are IPOing in a few months. As we have the assorted quota of buzzwords (slashdot, GPL, Linux(r), fork, Red Hat, kernel), we expect to have a strong opening price (around 100$ a share).
IPO keyword highlighting via Silly_Linux_IPO_Bot v1.3
---
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
It's so much fun to be a teenager.
Maybe his conclusions are correct, but in that case they definitely aren't based on his understanding of history, which is non-existent.
1. Unix.
Basically ok, as a kids version of history.
2. BSD
MachTen, NeXTStep, SunOS belong to the "Unix" camp above. OpenBSD split from NetBSD, and can thus not be characterized as a splinterproject from 386bsd.
3. Emacs
Totally crap. GNU Emacs was always under a "remain free" license. The non-free Emacsen were all written from scratch. Lucid Emacs was not only free, but the code ownership was assigned to the FSF for merging back. However, later Sun contributed code which was still GPL, but *not* assigned to the FSF.
The real story is that RMS wanted to keep total control over Emacs development, and refused to release Emacs 19 when it suited Lucid commercial interests. Today a merge is prevented partly because of the control issue, and partly because of the unassigned Sun code the FSF don't want to use.
4. httpd
I never followed that one.
5. gcc
Crap. *intel* made a pentium optimized port of gcc, and released it as GPL. They did *not* assign the code to the FSF. The version released by Intel did *not* work on any other platforms. So there were never any possibility of a remerge. Intel has later payed Cygnus for developing a new Pentium II optimized backend, which *will* be in gcc 3.0.
Egcs was created because gcc 2.8 never seemed to materialize, and in particular the C++ frontend of gcc 2.7.2 was embarrassingly old and buggy compared compared to what the Cygnus engineers had developed. Also, the Cygnus engineers found it very hard to attract outside developers with the closed developing model of gcc. Egcs was created as an experiment, with RMS blessing, to demonstrate the efficiency of a more open development model. It was a success.
6. glibc
Ok, except that the split then probably wasn't a mistake. Linux needed a working libc *then*, they couldn't wait until glibc was finished.
It's so much fun to be a teenager.
Yes. Don't waste it by spending all your time worrying about proprietary software.
--
The three BSDs have different goals, so a merge is not a solution, but the three projects actively follow the others changes, and merge wat interrest them in their own tree.
Subscribe to source-changes for any of these projects, you'll see countless commit message with (from NetBSD/FreeBSD/OpenBSD)
Since (if?) Mandrake Linux is a branch off of Redhat Linux, and Redhat Linux is a branch of Linux, and Linux is a branch of Unix, then the family tree is a huge collection of highly ramified dialects. There are places where these hundred millions flowers all blooming with varied scents is a burden, but others where it is a blessing. Let's just not call the violet a rose, because sweet though it is, it's not quite the same aroma.
Sheet music is not to a performance what source code is to binary code.
:)
The relationship between sheet music and a musical performance is more like the relationship between program text and the performance of a program, but even that is a bit of a strech.
The performance of sheet music has as its ingredients the information in the sheet music itself, plus the artist's interpretation which endow the performance with meaningful nuances.
The performance of a program, likewise, is derived from the program's code and whatever input goes into it, which may include static data, real-time inputs, etc.
Not all musical performance comes from notation; just like not all data is the output of a program.
The relationship between source and binary code is more like the relationship between a musical score and some lower-level representation of the musical score, like a piano roll. A piano roll is just like machine language: it has binary words consisting of punched holes. These trigger a ``control unit'' which drives the hammers that strike strings. Admittedly, it's a very horizontal encoding.
It would be reasonable to distribute piano rolls under a GPL-like license requiring that the sheet music be available to the pianist. But a key motivation for this isn't there: namely the need to modify. Neither form allows for easy modification, and few players are interested in rewriting a piece. There is a pragmatic need to be able to modify programs to suit changing requirements which is doesn't apply to expressive works.