Slashdot Mirror
TurboLinux Releases "Potentially Dangerous" Clustering Software?
relaye writes "The performance clustering software and services announced today by Linux vendor TurboLinux Inc. and a cabal of partners including Unix vendor SCO Inc. takes the Linux market in an unusual and somewhat risky direction, analysts are saying. " The article cites risks of forking the kernel - not an incredibly probable risk, but a thought-provoking scenario. The danger comes if Linus decides not to incorporates TurboLinux's changes into the kernel.
Does anyone really see this as a threat? Why wouldn't Linus add this? I guess the media is just trying a dose of FUD on us.
"When I look down I miss all the good stuff, When I look up I trip over things..."-Ani DiFranco
Maybe these guys can explain to me how the inclusion of Pacific TurboLinux's unblessed kernel patches to support clustering is any different from the non-standard kernel that ships with Redhat.
Now they must follow GPL licensing restrictions, but this doesn't legally prevent them from selling a tailored distribution which contains a mix of GPL patches and proprietary closed source driver modules... and it's not any more forked than the heavily patched kernel source that ships with Redhat Linux.
The analysts are getting too jumpy over nothing. TurboLinux has the right to make whatever changes they want to. That's the *purpose* of open source. If Linus was concerned about a code fork, then logically he would have chosen a different licence.
We should all be pleased that Linux is so flexible technically and legally that anyone who has a problem can either use Linux to solve the problem, or change Linux to solve the problem.
Using a feature of the operating system like the open source licence is no different than using any other feature of the operating system, like support for a TV Tuner card. The users will use any features of the operating system in the way that they want to, and nobody can tell them they can't.
Turbo Linux isn't forking the code, they are using one of the most powerful features of the code.
And that's my view.
If tits were wings it'd be flying around.
I just rifled off an E-mail to turbolinux yesterday re: maintenance of their patches. I was wondering if they would receive approval for their patches from Linus and if not, if they would continue to maintain their patches as patches against the kernel, not as complete kernel releases. In this way, some, if not all of their patches can be incorporated, and others can be downloaded and applied as necessary by those who want them (such as the secure linux patches at kerneli.org).
- Michael T. Babcock <homepage>
- Michael T. Babcock (Yes, I blog)
So the danger comes if Linus decides to Fork the kernel (by refusing to incorporate changes already adopted by various vendors.) It isn't inevitable that Linus will always lead the kernel releases. Maybe recognizing that is part of the evolution of Linux.
Speaking frankly, I think the fears of code forking are unfounded. Linux is very good for high-performance clustering, but here at the Linux General Store, getting high-availability clustering has been a pain in the rear. TurboLinux's kernel patches to support high-availability clustering are an easy win for Linux, and a no-brainer for Linus. TurboLinux did the Linux community a great service by adding these patches (IMO).
Finding God in a Dog
Unfortunately, one of the parties that can win is the Microsoft PR department, who has been shouting FUD about the fragmentation of Linux for quite some time. So, hopefully a kernel fork won't be necessary, since even if the fork doesn't cause the problems of fragmentation, MS will still love the opportunity to claim that it's fragmentation whether it's a bad thing or not.
Personally, I'm all for kernel forking. It's not like 8086 Linux or RTLinux are currently part of the main kernel distribution, nor should they be. They fill in special needs, rather than being something good for everyone. A clustering-optimized kernel would be similar, IMO. Clustered systems tend to be homogenous and not have any exotic hardware to support (with the exception of gigabit network cards, which are generally supported just fine by the main kernel as it is). It's a special-need kernel, not something for general consumption. As much as how every article on /. has a comment saying "Man, I'd like a Beowulf of these babies," most of the people saying that never will have a Beowulf or a need for a clustered system. (I mean, come ON, what would you, personally, use all that computing power for?)
---
"'Is not a quine' is not a quine" is a quine.
"'Is not a quine' is not a quine" is a quine.
Quine "quine?
Hmm... I've used SCO before...
I think that for most people SCO is inferior to Red Hat. Look at how much extra stuff Red Hat puts into their product, and how well it works with other stuff... Red Hat also does an amazing job of detecting hardware nowadays.
Not to say that SCO doesn't have lots of interesting things in it... there are some very nifty security model aspects that SCO has, for instance. But for people who want a web server or an smtp/pop server or a workstation, for cheap, with lots of power, I think that Red Hat provides a better solution. And I think that many customers are realizing that.
Not to mention a cooler name. :-)
-- Erich
Slashdot reader since 1997
TurboLinux is making alot of noise regarding the work they've done, meanwhile aren't they just taking an existing (very impressive) kernel patch referencing Virtual Servers and claiming it as their own?
There's an aspect of dirty PR pool going on here.
Gotta love, incidentally, more Linux bashing by SCO. Their hatred is so tangible. Then again, at least they're honest.
Overall, I hope Linus doesn't feel pressured to incorporate a technically inferior solution because somebody is attempting an ad hoc kernel power grab. We don't want people saying to Linus, "You're going to put this into the kernel because we've made it the standard." Embrace and Extend indeed.
That being said, I've heard very good things about the patch TurboLinux has appropriated without due credit. I've also heard some insanely interesting things about MOSIX, the virtual server project started in Israel and made GPL around six or eight months ago. Mosix is immensely interesting mainly because of its ability for seamless and invisible process migration--all processes, not just those written via PVM/MPI, get automagically clustered.
Very, very cool.
Comments from people more knowledgable than I about the details glossed over in this would be most appreciated.
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
This article clearly states that Turbo Linux plans to keep some chunk of their clustering technology proprietary (presumably all parts of it that operate in userland). If they don't plan on making their HA clustering work for the rest of us in any way, why should the kernel maintainers add support for their HA clustering, unless it somehow is part of an open standard?
I have no big moral problem with Turbo Linux choosing to fork the kernel. It'll be their problem if they introduce compatibility issues. People simply won't use Turbo Linux. The right to fork is an integral part of the GPL. Let the market (i.e. user choice) decide. If the features are useful, people will want them, and they will make their way into the mainline kernel. If they aren't useful to us, they won't, and TurboLinux will just have to patch every kernel release (frankly I don't care if they do, as long as they are abiding by the terms of the GPL).
Since *BSD forked, Linux HAS to, right? Since 'free' entities can't share a common vision? Bah!
At best, the code is good and Linus incorporates it as a kernel option.
At worst, it's a patch for a very specialized function, examples of which already exist:
Embedded Linux
uLinux
RT Linux
e2compr (compression for the ext2fs filesystem)
I don't see something as specialized as server clustering forcing an actual 'fork' of the Linux kernel, except as a vertical application (Like Embedded Linux).
jf
But we already HAVE that kind of fragmentation in 8086 Linux and RTLinux and likely a dozen other special-interest kernel forks, and so far I haven't seen any collapse of the Linux world because of that...
---
"'Is not a quine' is not a quine" is a quine.
"'Is not a quine' is not a quine" is a quine.
Quine "quine?
I'm surprised this is even an issue. Linux isn't NetBSD, with tight oversight and cathedral-like concentration on purity. Thisis Linux -- people are supposed to be able to contribute freely.
This isn't to say that all submitted diffs should be merged immediately, but why give up one of Linux's great strengths -- the ease of contribution.
--
Some keywords for the NSA in the Lord of the Rings universe: One Ring bind find Sauron quest Nazgul freedom
The question of weather Linus will accept these kernel patches is a matter of what is being changed. If they are architecturally sound and take the kernel in a direction that Linus wants it to go they will be incorporated, if they are just some glue for proprietary stuff that TurboLinux sells then they don't have a chance in hell.
The other question is -- could they, or would they, fork the kernel if TurboLinux doesn't get their way. The other solution is to either make due without their enhancements or port their patches to each kernel version. The second option is not too far away from what other vendors do in backporting security updates to the old, shipping, version of thier kernel (COL w/2.2.10 has patches from 2.2.12/13 in a 2.2.10 update RPM). There are also other distros that add beta or unsupported patches, like devfs (Correct me if I am wrong on this point, I don't have this personally).
What does the GPL allow? They don't own Linux, no one does, what would they be able to accomplish (barring Linus from accepting their patches)without the support of the core developers.
I guess that I have more questions than answers, GPLd software hasn't been as popular as recently and some of these issues are being tested on a large scale, for the first time. Or maybe not, the GPL has been around for many years. Maybe this kind of thing has happened before and we can just look back and learn from experience. If anyone can point out an instance I would appreciate it greatly.
Enough rambling for one post.
-- Remember: Wherever you go, there you are!
If they fork the kernel, then they have the responsibility of maintaining their new kernel and integrating new features and so forth. Fine. They have that right, as long as all the source is available. Good for them! Code forks make the linux world a better place, because they cause the best options to be produced. Plus, standard linux can steal their code (the good parts) and integrate it back into the normal kernel if they want. Good too!
However, if they don't want all that responsibility, they can release kernel patches to be applied to the standard kernel to make it work with their system. Good too. Those may be eventually integrated into the standard kernel distribution, if they're worthy.
Either way, who cares? The ONLY entity this could hurt is TurboLinux itself, for the fear of being incompatible with the standard kernel. And that's not likely anyway..
This article is FUD.
---
- Give a man a fire and he's warm for a day, but set him on fire and he's warm for the rest of his life.
The kernel is already forking, with the Red Hat patches and now Turbo Linux. We are living in a dream if we think that Linus is going to control all those vendors from doing their thing.
And now, to keep the Moderators happy: "Linux is cool, /. is cool, I hate Gill Bates".
We're also not talking about a "fork" so much as a patch to the main kernel thread. There's little chance that this patch would be allowed to diverge from the main kernel thread, as it's easier for TurboLinux to maintain it as an add-on - otherwise, they have to maintain an entire kernel rather than just a patch.
A lot of the talk about the danger of forking the Linux kernel is FUD or ignorance of the licensing issues.
Thanks
Bruce
Bruce Perens.
While polite, I though that was the whole GNU idea - take the code, do what you want, release it.
Folks, we've been here before. The forks converged. There's no reason that future forks of GPL software will not converge.
Thanks
Bruce
Bruce Perens.
that must be some new functionality I wasn't familiar with. Thanks, Computerworld!
Oh, and Take _That_, emacs!!
:)
They make it sound like someone is jumping out of an airplane on a motorcycle or something.
So what if TurboLinux forks the kernel? They will either die out or have to keep a parallel development stream whereby they keep taking mainstream kernels and patch their changes onto them. No big deal. There are nice tools for this, like CVS update -j or GNU patch. Eventually, their stuff will mature and may be accepted into the mainstream.
Forking happened before (anyone remember SLS?).
I think that for any significant feature to be added by an independent software team, forking *has* to take place. In fact, Linux is continuously sprouting many short-lived forks. Any time a hacker unpacks a kernel and does anything to it, wham, you have a tiny fork. Then when it becomes part of the stream, the fork goes away. To create a significant feature, you may have to have branch a much longer-lived fork. And to let a community of users test that feature, you *have* to release from that branch. Now crap: you are ostracized by the idiot industry journalists who will accuse you of fragmenting the OS.
Linus *can't* integrate Turbo's changes until those changes are thoroughly hammered on by Turbo users, so a fork is required. The only kinds of changes that Linus can accept casually are ones that do not impact the core codebase. For example, if someone develops a driver for hitherto unsupported device, great. The driver can only screw up kernels that are built with it, or into which it is loaded. Just mark the driver as very experimental and that's it.
The net result of the forks were that you could have a compiler that covers one purpose, but not necessarily more than one.
I do support of some R/3 code where our local group has "forked" from the standard stuff SAP AG provides; it is a bear of a job to just handle the parallel changes when we do minor "Legal Change Patch" upgrades. We've got a sizable project team in support of a major version number upgrade; the stuff that we have forked will represent a big chunk of the grief that results in that year long project.
I would consider a substantial fork of the Linux kernel to be a significantly Bad Thing.
Note that if it forks, the Turbo version may have a hard time supporting code written for the non-Turbo version. Major things that are likely forthcoming include:
- New filesystem support, including LVMs, ext3, Reiserfs, SGI's XFS
- New devices such as network cards, SCSI host adaptors, USB devices
- Further support for 64 bit architectures, and support for 64 bit structures on 32 bit architectures ( e.g. - solving such issues as the 2038 Problem and the 2GB File Size Limit Problem and the 2GB Process Size Limit and such)
Deployment of such facilities would be substantially hampered by a kernel fork.If you're not part of the solution, you're part of the precipitate.
I have a friend who works at SGI, and we were just talking the other day about how their development people have been frustrated lately about their inablility to get certain scalability-oriented bits included in the kernel. So, essentially, SGI's Linux is headed for this same sort of fragmentation for the same sort of reason.
I told 'em that if he killed Linux I'd slash his tires, but I don't think he took me seriously.
We in the community have nothing to fear but fragmentation itself. The 10,000 faces of UNIX is what originally killed it as a server operating system -- that's why I refer to Linux as being the Second Coming of UNIX so often. The really key thing is that it runs on a common platform (Intel) and it's not the mess that the commercial UNIXes evolved into during the last decade.
I don't know how to stop this from happening, only that it must be stopped.
----
Every year during my review, I just pray the words "slashdot.org" aren't mentioned.
See top... my mistake.
I've not done a fresh install of RHL since 5.1, so "perhaps they've gotten tremendously more proprietary since," but I rather doubt that.
The concern with TurboLinux customizations is if this makes TurboLinux kernels not interoperable with other kernels.
This will only matter if people adopt TurboLinux in droves; if they do their thing, producing a bad, scary forked kernel, and nobody uses it, this won't matter. It's not like the "tree in the forest;" if nobody is there using TurboLinux, nobody cares about a disused fork.
If you're not part of the solution, you're part of the precipitate.
i mean, seriously. who frickin' cares what Linus says? you have the code. don't like it? who frickin' cares, incorporate your own changes. i do, and i love it. Linus' needs are what drive kernel development, not overall needs and issues. the PCMCIA shit should teach you that, as should the lousy IP stack implementation. it's about time someone stand up to this BS development model and actually do something based on performance or whatnot in a big way. the current model of "Well, it's Linus' OS" is a surefire way to stagnate development.
jose nazario jose@biocserver.cwru.edu
The "VI" system mentioned in the article is probably one of the changes. I have never used VI under Linux, or VI with the Giganet hardware, but I wrote the original VI prototypes for Windows NT. It's a communication system that gets lower latency than the kernel TCP/IP stack by exporting some hardware registers directly to the user applications, allowing them to send and recieve network data without ever doing a kernel call. You need special hardware to do this without creating huge security holes of course! You also need an extra kernel interface to allow the user program to pin/lock some amount of virtual memory, and a special user-level communications stack. This can't be used to talk to computers across the internet because it doesn't use IP protocols. But if you have a cluster application where message latency is critical, it can give you a big performance boost.
PS - This was a much bigger benefit under Windows NT, where the system call overhead was much higher than it is under Linux. But it should still help out Linux.
Wow. VI has always been my choice for situations when I didn't want the overhead of EMACS, but I didn't know it did clustering! :) :) And who are these Giganet people? Is that like nvi or vim?
"...Is this world not a call I can screen out" --
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
I am the kernel maintainer for TurboLinux. I'd like to dispell a few myths here:
I hope this addresses some people's concerns. Don't worry, I am **very** pro-GPL and am responsible for sanity checking these choices.
Ciao!
(aka Christian Holtje docwhat@turoblinux.com>)
The Doctor What (KF6VNC)
Thanks
Bruce
Bruce Perens.
This is basically comercialisation of the Linux Virtual Server Project... it's a load balancer - much like Cisco's LocalDirector...
Now if you want real clustering, help with the Linux High-Availability Howto or go look at HP/UX's MC/ServiceGuard - or if you are forced to play with toys, MS makes NT Enterprise...
GEEK!
The real issue is how much the commercial world can pull on Linus's reins. These capabilities should be in Linux but only if it makes sense. If Linus evaluates them and they agree with his overall vision for the Linux kernel, then by all means, they should be included. If he incorporates them because he fears a code fork, he sends the message that he can be manipluated by some large entity. I look forward to seeing how this turns out.
--
*Condense fact from the vapor of nuance*
Thanks
Bruce
Bruce Perens.
If they break binary compatability with the Linux world, then they are going to be cutting themselves off from all of the applications that people want that are only available in binary form (Netscape, for instance)
If they break source compilable compatability, then they're going to have an operating system with either no applications, or they are going to have to start modifying applications themselves, and they will NEVER keep up with the rest of the world.
Either way, eventually, customers are going to become frustrated when new versions of Linux applications become available, but they can't use them because their hacked up Linux kernel won't support them.
Here's my "trailblazing" analogy.
Think of the evolution of Linux as trailblazing a new road.
In the front lines, there are people off, hacking through the brush, trying different paths. Some paths are better then others. Some people wander off on obscure paths and are never heard from again. Others find good, safe, productive paths and bring back maps and suggest that the main road run that way.
In the second line, group leaders such as Torvalds and Cox look at the trailblazers' work and decide where to lay the main road.
In the third line, millions of users follow along, driving on the nicely paved road.
They don't HAVE to drive on the big, paved road --
There's always trails that lead off the main road, but those roads have more potholes, and usually aren't maintained very well, and they're lonely roads, and if you went that way you might run out of gas and become stranded.
But there's nothing to stop someone from building a new, parallel road, and making it enticing enough that it renders the old road obsolete, much as the interstate highway system destroyed the commercial viability of old roads like Route 66.
But considering that much of the attraction of Linux is in the culture, and the freedom from propriatary code forking, I don't see this happening in the near future.
(did you notice I squeezed 2 Monty Python references into 1 post?)
Left shift 1 for e-mail...
You picked a really bad example. GCC was way behind in C++ compared to egcs. If there hadn't been a fork, we may never had gotten a decent C++ compiler. Of course, you may not like C++. But it's a widely used, important language that many open source projects depend on. In the end, of course, gcc and egcs merged back together. I can't see anything but good stuff resulting from the fork.
Stephen Molitor steve_molitor@yahoo.com
I thought the kernel had? Of course not in any way people really notice like the numerous BSDs, but I remember one poster reply once to a message of mine giving a few examples. Wish I could remember any... long time ago.
The real difference with BSD is that Berkeley released it (and under the BSDL) for anyone willing to play, and fork. They were through playing with BSD. So, BSDI, Sun, i386BSD, etc picked it up, and began coding. The free BSDs can still fork just like Linux can, its just whether there's an extreme enough reason to do it. Only OpenBSD actually forked from free BSDs, and when I read Theo's archive, core seemed stubborn and unwilling to resolve the problems. If Alan Cox was suddenly booted from the kernel team, with significant peices of code (and a direction) he wanted to add, but over and over again shoved away by Linus and the rest.. I think Mr. Cox would do something. What, I'm not sure.
Considering DOS, windows, BSDs, etc. all forked.. Linux will sometime too.
"Open Source?" - Press any key to continue
This really isnt a problem. Think about it carefully. SGI wrote 4Gig mem patches. They worked but were clunky. SGI ship them, SGI customers are happy. Siemens + SuSE write non clunky 4Gig patches. Everyone will use those and Linus endorsed them. SGI will use them too Im sure.
It hasnt broken anything. In fact one thing Linux gets right other vendors don't is we say "no" to crap code. If you dont do that you codebase turns to crap. Linux does it right, *BSD does it right.
Im not actually sure what they add. I'd need to dig over their patches. Wensong Zhang however has had this stuff working in Linux for a long time, and indeed for 2.2.x -ac I've gone that path and would do for an official 2.2 except that its a new feature so not eligible for 2.2
I know Wensongs stuff works. I know people doing production work wih it so for 2.2.x thats probably the final and absolute path. For 2.3.x it depends what Linus thinks is better.
And it's not a keyword anyway, it's an operator. Please stop misapplying terminology, it makes you look very stupid.
First the article has typos,
Carson City,Nev.-based
SCO.He said the consulting arm ofSCO is
Obviously the guy was writing this article in a hurry. Probably an intern who thinks he knows about all of this computer stuff which is just so hot these days. Do the folks at Computerworld think that online-journalism is allowed to get away with this sort of disrespectful writing.
Second, forking is the whole idea behind copyleftism. You allow people to make whatever changes to the OS they want as long as they make their changes public. That way we can see if TurboLinux has done something stupid. If it is good and is not the first high-availablity clustering kernel because they wanted to be the first, Linus will put the changes in the kernel. Linux does not benefit or get taken away from. Nothing has changed, and anyone that wishes to use TurboClustering is perfectly welcome to buy their distro. journalists should do their homework. this is not a crisis as the author makes would lead George Weiss' comments to infer. This would have been a much better article for a computer magazine if it had explained the internals of the technology annd let us decide what to do with the facts and make our own inferences as computer literate/savy/scientists (pick one) as to the implications of this new technology. This is a great technology to be available to the comunity and perhaps the reason that Sun released their source. Their clustering technology is no longer a secret. Does anyone else feel like their articles about linux and computers in general do not talk about anything interesting, just business (except for ACM, IEEE, Usenix, etc.... publications). We should be smart enough to make inferences to implications on distrobutions. Paraphrasing experts only makes confusion!
- Kill Yourself, spare us all! -
Simple answer
2.2: new feature, not going in
2.2ac: Using Wensong Zhangs code because it is
rock solid and production hardened. It needs no
proprietary tools. Several vendors already ship this code. I also know people building big web setups using it.
[www.linuxvirtualserver.org]
2.3.x is up to Linus, actually possibly to Rusty
as all of this code area has totally changed to
use netfilter.
Alan
I also remember all the confusion and all the time and energy and bandwidth wasted sorting out the confusion and incompatibilities. It was a Good Thing (or at least a Better Thing) when things got resolved, but if you really do remember the situation at the time it was going on, then I'm astounded by your nonchalance just because that incident is for the most part behind us.
When the hype dies down and people start to look at Linux with a critical eye, things like your example would be a serious black eye for any hopes of large-scale Linux acceptance. And with the commercial vultures, er vendors, entering the fray, it's more likely to happen in the future. How do you think it would bode for Linux's acceptance in the non-hobbyist community if two or three or four such forks were going on at the same time?
Cheers,
ZicoKnows@hotmail.com
Oh no! What horror! I'd hate for new, potentially better technology to be available for the open source community to choose!
I suppose that TurboLinux should just throw away their code so nobody's feelings get hurt.
OK, I'd like to thank users "tap" and "mmclure" for pointing out the obvious; that installing the kernel-2.2.12-20.src.rpm will generate our list of patches for you:
[snip for brevity]
Am I still a liar? Do these patches live in never-never land? Does this whole thread really deserve to be moderated down by several points to a 1 simply because some moderators didn't agree with its position? Isn't the point of moderation to promote factually correct and valuable discourse?
A public apology for calling me a liar would be nice, Blue.
Thanks
Bruce
Bruce Perens.
must have been a bit to tired when writing that one above... Past little grammer things... didn't mean to enfasize BSD in the list (that was the point, its not the only OS to split). heh...
BTW, since BSD and SysV were the two styles of UNIX, would you not say that if BSD split, so did System V? The code for both is still available from the archives (who holds SysV now? Last I remember was Novell letting the UNIX trademark go, though not sure what happened with SysV code.. All UNIX OSs are BSD or SysV, and UNIX-like being BSD or just.. -like. Would seem pointless to make a big deal about BSD splitting if System V did too, and they were the two design styles of UNIX, not full fledged OSs, just the building blocks.
"Open Source?" - Press any key to continue
The definition of 'distribution' (as Bruce found for us) being 'transfer from one legal entity to another'. :) it'll be interesting to see who tries to grab momentary advantage by building up a head of steam behind secret development.
And that's why a corporation can fork and have its programmers developing GPLed source under NDAs- but at the same time it means that as soon as the binaries get out to ANYBODY not legally part of the corporation, the source must follow.
I think this suggests that open betas grant full rights to recipients under the GPL, and that it is possible that closed betas may not- the exact point of concern is whether a beta tester is legally part of the corporation, or not. They would have to be part of the corporation, legally, in order to be subject to any sort of NDA over GPLed stuff. This also makes internal testing totally controllable, always insisting that the recipients be part of the corporation and under NDAs. As soon as the binaries or source get into the hands of someone who isn't part of the corporation, the source must be forthcoming and the recipient has full rights under the GPL. Not a bad compromise really
It's not difficult to foresee us getting to the point where apps work under one kernel rendition and not the other; SGI is probably just the tip of the iceburg. Wait for IBM or Sun (it could happen) or any other "big-ass server" maker to start eyeballing Linux for their own machines. It could go nuts - picture having ten variations of the Linux kernel, all running their own sets of applications. That's what forking is, and its very possibility should scare you. After all, is Linux still Linux if one version runs Lightwave and another can't, or is it just suddenly another fragmented UN*X?
----
Every year during my review, I just pray the words "slashdot.org" aren't mentioned.
The fork may have been necessary, and the eventual reintegration (or "reverse fork") that came from EGCS was also necessary.
But the initial fork displays that there were problems with GCC development that could not be reconciled at the time. And that was not a good thing.
If you're not part of the solution, you're part of the precipitate.
Hey, man, I was just refuting the setup proposed by someone else. :) You'd still want one system per CD in that case, though, and it'd still take over an hour per CD (takes 45 minutes to encode the average CD in pristine conditions on a P2-450, and then 20-30 minutes to do the burn).
---
"'Is not a quine' is not a quine" is a quine.
"'Is not a quine' is not a quine" is a quine.
Quine "quine?