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.
Well it sounds like they should have checked with him first now...eh? Well, regardless more good steps in making this powerful OS even more powerful with clustering. Good Job.
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)
This can be no good Linux Fragmentation, first we heard rumors and predictions, now we see the first hints of it. The way linux works, anybody can do anything with it, so TurboLinux has the right to do whatever they want with it. The danger is in fragmentation. I think the best way to handle this is for Linus and the head kernel hackers to sit down with peoples at TurboLinux and try to come up with a solution. Turbolinux should at least give the hackers time to look at their code and evaluate it. The clustering code will probably get better with a team of hackers worldwide looking at it!!!
-----Transmission Complete----- If you want to email me...Don't
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
Even if it doesn't make it into the main kernel, it's open source, it's supported by a vendor, so what's the problem? Every time a new "main branch" kernel comes out, the TurboLinux people can make their same changes to it that they did to previous versions. And if the code they're modifying to do it doesn't change much between kernel versions, it will be trivial for them. If somebody rips out and re-writes the stuff they're based on, then they have a problem - but anybody who cares about clustering in the open source community will be able to help them.
The next Cmdr Taco duplicate will be ready soon, but subscribers can beat the rush and see it early!
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 will probably be already said by the time this is posted, but I really have a problem with a major linux vendor producing closed source software. I am not against binary only products for linux per say, but these should be third party in my opinion. What they should do is form a seperate division that sells addon linux software that is closed source which any linux company can then use and resell. For example, I see nothing wrong with Redhat selling Motif along with their product. Just my 2 cents.
First, this is not a 'danger' to the linux community. I will continue to support OSS whenever possible, and more importantly, I will continue to use the tools that work for me.
If they want to start pushing their own linux kernel, as opposed to just providnig patches to the current kernels, that's fine. They won't get the benefit of all the new services we add to the linux kernel.
If it is too difficult to provide patches against that standard kernel, then perhaps it should be a separate branch, if some of the core architecture changes.
I must say, however, that if someone is working on clustering/high availability software for Linux and is willing to GPL it (which they must be, if they want to distribute), then we should ABSOLUTELY support it!
1) Will media types and pseudo media types ever understand the differences between ``public domain'' and ``copylefted software''? This is, of course, unless I'm just kidding myself into thinking that the GNU General Public License is, well, a license.
2) Doug Michels.. is a gimp? If you think that is some sort of unfounded flame, you should really consider reading that interview. He's a complete and utter tool. Few people are that lost.. hee hee hee.. He must be living on a totally different fscking planet. =P
~ Kish
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).
Does anybody know what they are changing?
(another flavor of kernel support for cluster wide resoures/pids/etc. or something?)
The article basically said nothing about what their system does to make it better/different than any existing clustering setup.
dv
"There's no secret. You just press the accelerator to the floor and keep turning left." -- Bill Vukovich
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
Is there really any reason the changes would become a part of the main kernel if the rest of it is closed. I think part of the problem is that if it changes things in ways that slowdown a nonclustered kernel it won't make it, and if it doesn't should Linus incorporate the changes when the Userspace clustering software won't be open, so it won't be able to be used by the free software community as a whole?
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
I think this is an outstanding step for the market. Any new development that add functionality, to Linux is, in my opnion, a step in the right direction. I also tend to believe that if this all works out and is becomes an in demand feature that Linus will incorporate clustering into his kernel. After all, everyone working together to make better software is what Linux is all about.
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".
Users that choose to use TurboLinux should be made aware of the fact that these aren't 'official' kernel patches though. But as long as TurboLinux doesn't have to make an 'unofficial' kernel patch for every major kernel release I'd think that we'd be fine.
If the technology is cool enough to drive sales for TurboLinux anyway then more than likely it will be added into the basic kernel distribution wether TurboLinux or somebody else does it. Just because TurboLinux is showing us the way doesn't mean they have to provide the only solution.
Given enough market demand this will be included into Linux, otherwise it will take the back seat and get done when somebody is bored enough or wants an interesting project.
This space for sale
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.
This could be a very dangerous situation. If LT doesn't incorporate this (provided it is a superior technology) then there will be a fork...
I, personally, don't know why the core kernel team wouldn't incorporate it if it isn't superior technology.
As for Sun taking flak for partially closing the technology... They should make the APIs known and allow a OSS version of the user space software to develop. Hopefully this will come out to benifit all users.
some karma... and kinda lukewarm about it.
Well... from what I have seen posted all around so far of late.... it seems prudent to wait to hear from Linus on his decision regarding the high availability clustering technology that TurboLinux have created. If TurboLinux do release the code regarding that code, and Linus do accept it, then all much better for all of us.
:)
So... let wait and see til we hear from Linus or Alan Cox regarding that technology. But it would be good uses to have that feature added into the kernel. Speaking of that...what up with Beowolf Clustering technology? I have not seen that being incorporated into the Kernel and only been released and available from Redhat as Extreme Linux if I remember. Correct me that if I am wrong on that part.
But anyhow... go and bug Linus and Alan Cox and pressure TurboLinux to contribute the entire code for the HA Clustering technology to the Kernel source tree so we can take a shot at it and improve it if needed to make it better than it is right now. That is the whole point of the Open Source Movement... for everyone to contribute to it and improve on it to make it better instead of closed source like Microsoft NT currently is which is downright buggy. Heck.. it trips up and dies when you try to poke at it with a stick.
-- Amazing how the Internet still humms along.... -- Dispite all the flaws of Micro$oft in their software!
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!!
:)
In many ways Linux has already forked (I know the kernel hasnt) but with the numerous distributions and what not. I can understand different visions and forking of an OS like BSD has... I cannot understand the numerous distributions of linux. To me, it makes things a mess and there really needs to be more of a standard. (Packages and what not) but as it has been proven before, trying to settle on that causes massive amounts of arguing and flame wars. This reply is not intended to do that, just expressing my frustration with the lack of more standards and better orginization in the Linux world.
whoever said this is "unusual" obviously doesn't know what they're talking about. linux has "forked", more or less, many times, almost always ending up included in linus's tree. examples: RTlinux, mklinux, the L4 port, redhat has including kernel patches (if you want to count that), and most archs are forked to a certain degree (ie, not always synced to linus, and especially when they're first developed).
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.
Surely if TurboLinux et al have done their design correctly it should be possible to patch any kernel source with this code as the overall design is not going to radically change.
Any sufficiently advanced man is indistinguishable from God
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.
Here we have the usual characters, SCO and D.H Brown. Both brothers to Mephistopheles and both seeming to do soemthing they have never done before, oh god, support linux? And that too in a potention fork? This does reek of a certain vain story does it not? How do you make the kingdom fall? you infect it, ofcourse.
And such infections as a bastard child, would most surly help sour the apples. Think of much to do about nothing, (Dude!).
And ofcourse there are those, who say that better things could happen from such a fork. But has that always been true? Somewhat.. there are certain benifts and certain uncertanties associtated with forking.
Then comes the question of clustering, why does, Turbo Linux ppl want their clusting solution to be part of the the official Linux kernel? There are serveral such solutions that predates. Those never wanted to be part of the kernel (for a good reason too). Were these people set up from the beiging to fork? And notice when they announced this, just when a kernel freeze was in place. How convientinet and how easy can they fork now. But wouldnt just a patch help? I'm sure that's was ExtremeLinux, BeuWolf does.
And thus,
To fork or not to fork, that is the question..
--
If it came across that I was agreeing, I was not. My point was that if they (turbo linux) were sharing the view points of the analysts, in that they feared there may be a fork... then they should have submitted their changes to Linus first. But yes... I agree with you, that is the whole idea of GNU. So again, I say good job, and good luck to them.
See top... my mistake.
... is it another Microsoft ActiveFUD (TM) post?
Clueless is OK. Most journalists are.
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.
Remember where "Gartner kiss of death" came from?
IDG == FUD
IDG == FUD
IDG == FUD
IDG == FUD
IDG == FUD
IDG == FUD
IDG == FUD
--More--(0%)
Since 2.3 has been feature frozen for a while now, so by rights it wont be in 2.4.
There are plenty of usefull feature waiting to get into the kernel.
For example new style RAID (v0.9) and the big ISDN
patches. These features have been standing in line waiting to get in, and are more usefull to the general public than kernel support for a proprietry userland program(if thats what it is).
But i have faith in the powers to be, they kernel maintainers do what they think is right for the kernel one way or the other. I dont think this attempted threat of a fork will sway theyre decision whatsoever.
"Linus' needs are what drive kernel development, not overall needs and issues."
Well I sure want to have 'needs' like those...
As for the PCMCIA and IP implementations, I dunno: did you actually do better and got your changes rejected?
JM
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)
Someone moderated that down as "Troll"???
Bruce Perens.
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.
I don't really see what the problem here is. It's not like people that are going to be going this route and paying all this money for this level of performance are going to expect to download the Netscape RPM from redhat.com and have it install cleanly. Obviously things like these clustering technologies are going to be used in places where custom software is going to be written to take advantage of the technology. In the end, the company that forks over all the dough to create such a technology is going to be the one hurting if they then decide to go back to a "standard vanilla" Linux-clone.
The more diversity the better. This can better serve the market for people that need the clustering technologies, not for joe-blow hobbyist... More Linux around the better...
www.jackasscritics.com
However, these other distributions serve specilized areas for OS' and still are free! They don't charge money for a proprietary implementation.
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*
1). Makes for a bigger kernel with proprietary hooks for somebodies proprietary s/w pkg that is way to expensive. 2). Forking means their kernel has the patch and thus trying to run the clustering s/w pkg on Redhat that may not have it won't work. In the end I have to buy the solution from them which will be eventually very expensive. 3). What if I want proprietary solution from Caldera, and one from Turbolinux but run it on Redhat. 4). What about upgrades to this s/w pkg and backwards compatibility. 5). I tried downloading the Asian language support s/w from Turbolinux's anon site. Guess what! you have to pay for it and can't get access to the directories where it is at, only the basic kernel stuff. 6). Partner with a company who will perform cost analysis/benefit, management and provide recommendations on technology will be biased since it the *only* recommendation that SCO will make is for you to get their s/w pkgs and only use Linux as a foot in the door. 7). Ever think about how a small company like Turbolinux can come up with a Clustering solution so fast? It more likely is a relabled SCO product being sold under the linux name. I'm sure they are getting a percentage cut from each Turbocluster sale. This sure seems strange to me. Thus in reality it is just SCO's proprietary clustering s/w.
Left shift 1 for e-mail...
This would be nothing new... there already are several different "forks" of the linux kernel (RT-Linux, uCLinux, ELKS, etc.)
There are some things that make sense to be included in the mainline kernel, but there are also specialty things that have no place there. Linus is a fair person when it comes to these things. I've never known him to reject things that are of general benefit.
Every one on the planet doesn't need HA or clustering, but there could be cases made to support adding it to the base kernel much like SMP (albeit of growing use) and RAID support. Things that make drastic alterations to the kernel would generally be split off as a specialty.
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.
I'm scared, very scared. With Turbo linux having such a large market share in Japan, a split of linux efforts can only be detrimental to the overall success of linux. Great feature, but I feel it is selfish of Turbo linux to not consult with Linus first before making such a move. So the code wars begin.
This was/is an inevitablility when you get commerical companies involved. Even if they would make their changes open sourced, if they want to solve a particular problem to make their product worth more, then they won't really care about what Linus says. Linux has gotten to much attention for a earnings consious company to care about one man. The consumers would have to insure that this doesn't happend by not buying or supporting the company.
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
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.
It's factually correct and the author has rebutted all claims to the contrary.
I don't read any flame baiting in the message.
It's completely on topic.
It certainly wasn't redundant.
What is wrong with this moderators, do you dislike the content? That's NOT a good excuse!
Xlib
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! -
Remember a while back, when DOSEMU needed a special kernel hack to get all the features ?
Linus wouldn't put their hack into the kernel because he found the patch a bit dangerous. The patch later on became a special module, and later on again is wai incorporated into the kernel.
The same thing will happend this time.
The other tactic to GPL (or another opensource licence) the old version is also a well known tactic. Look at ghostscript and DOOM.
So don't be afraid. This is good for Linux.
Is this bad? Yes. I do not care what anyone say, people can say that forking is not bad and so on, but it is very easy to learn from history. Look at the BSD's. Imagine if there was just only one BSD instead of 1000 of them... If Turbo Linux forks, chances are that other companies that want money will add a thing or two to the kernel, and fork off a new Linux based set. Then they will proceed to tell you that their own is better. Before you know, Linux is fighting Linux. The Linux community needs to stick together, the various distrubtion sets is alarming already. I mean, if TurboLinux forks off a new kernel base, will other vendors take turbolinux modify it and soon, have various distribtutions of Turbo Linux. Hrm, so what if this happens, and in a few years we have 5 different Linux bases, each with 10 different distribtution. Will redhat then have, redhat linux, redhat turbolinux, and such? Another reason this is horrible is because SCO is involved, everyone here should remember how SCO has been spreading FUD about Linux. Is this a company we can trust? I think not! This is bad
------ Curiosity killed the cat. {satisfaction brought it back | it didn't die ignorant | lack of it is killing mankind
Sounds similar to how the kernel level MPI stuff for linux works ...
... if this does what you say I think it's a great stride forward for distributd computing on Linux.
The TCP/IP stack for clustered computing has long been a pet hate of mine
"There's no secret. You just press the accelerator to the floor and keep turning left." -- Bill Vukovich
Back in the early 90's, there was almost non-stop talk about how fragmentation was going to kill UNIX. ZD pronounced UNIX dead at least a dozen times. But when UNIX vendors began to cooperate, all of a sudden they dropped it. POSIX wasn't interesting news, so they moved on to something else. UNIX still isn't dead, and MS is still trying to produce an OS capable of competing with it.
A code fork will never kill Linux; in the end, it can only improve it.
TedC
"I have an idea, let's give away the code to make us look better" -Steve Jobs on OS 10
"Steve, we have to give the code away." -anon consultant
"I know I just came up with that idea, I'm brilliant!!!" -Steve's reponse
I have never been impressed with the garbage that flows forth from the pages of computerworld. I had a Free subscription to it back in '94, and realized their bias back then. I've never read a magazine that was so blatant in coloring the "truth" to fit the desires of their advertisers. My business partner finally started "Misplacing" the magazine before it made it to the office from the post office, because I would get so infuriated every single week upon reading it....
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
Linux runs SCO binaries. :)
'Analysts' make their money off of text bites, and fear mongering. Ignore them, return to your coding, and you'll be a lot happier. I know I am. M.
The altogether-too-many versions of Linux out there are already a big concern for some people; for instance, on the perl5-porters list there has been a rather large thread about telling one linux from another, due to differences in what works and what does not. So far, it's proving rather difficult indeed to sort out what all the versions are.
What would really do service to the community is for the various distributions to get their act together and work on some common method of identifying exactly what is being run. As a side effect, this would also make dealing with forks easier.
Bruce Perens is going to run out of karma!! The horror!!!
Yeah. Right.
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.
What is ths gibberish about Steve Jobs? The Apple bashers amaze me in their ability to bash Apple in a thread totally unrelated to the MacOS or Apple. Grow up, people.
I think the best way to handle this is for Linus and the head kernel hackers to sit down with peoples at TurboLinux and try to come up with a solution. Turbolinux should at least give the hackers time to look at their code and evaluate it.
You make it sound like there's some sort of confrontation going on, with Linus refusing the patches and them "threatening" to go ahead and do their own thing anyway, forking if necessary, etc. I don't see anything like that in the article, though. The only real news that I see is that they have made a modified kernel with improvements for high-availability clustering. The rest seems to be at most speculation that if Linus were to reject the patches, then a fork would be created. Are you sure you aren't trying to resolve a non-existent situation?
This is sort of an extension of the article's own cluelessness, such as where it says
But what really stands out about TurboLinux's approach to the market is its effort to provide high-end software that alters the Linux operating system itself.
as if nobody else has ever submitted a kernel patch before. I'm no authority, but it seems that at most, the difference here is the magnitude of the modifications they have made, which would be only a quantitative difference, not qualitative one. I also don't see how this is taking Linux in a "new direction" -- it's just new pwople doing it.
David Gould
David Gould
main(i){putchar(340056100>>(i-1)*5&31|!!(i<6)<< 6)&&main(++i);}
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.
Please moderate this down.
Shouldn't it be:
(equal (+ (clueless (sandal seeking) journalist) (* 2 (clueless analyst) (sco in game)) (trouble for (turbo linux)))
-- NoWonder of WonderWorks/OmegaProject
(sandal seeking)journalist
ROTFLMAO
SCO could screw up an anvil with a rubber mallet... Hey didn't SCO once say that Linux was coded by a bunch of punk kids ? & I never knew why they called freeware skunkware, I take great umbrage at that.
There was already a feature freeze in place in the 2.3.x branch getting ready for the 2.4 release. It is highly unlikely that such a radical and large patch will be accepted, no matter the benefits. i.e. look to the ISDN patches that never made it into 2.2 and most likely will not rear it's ugly head in 2.4 either. As for other comments on XFS, Reiserfs, ext3... those won't make it into 2.4 either... look to the 2.6 release for all the features you are drooling for.... I believe LVM has some prelim support in 2.4 tho.
Although there are already nearly 200 comments so it's unlikely this'll ever get seen, I feel the need to point something out.
What leapt out at me was not the modifications PHT made to the kernel, but that their application-level support for these facilities would not be open. I mean, assuming PHT's clustering implementation doesn't suck, I can't imagine Linus rejecting it. Clustering of this kind is something that, AFAIK, we don't have AT ALL right now, so any contribution of it ought to be welcomed. But what good does kernel-level clustering do if you have no way of taking advantage of it from userspace? I can't very well enjoy the bttv video capture driver without xawtv et al. I couldn't take advantage of kernel support for filesystems without "mount", could I? PHT is going to submit their kernel changes to Linus for approval and that's great, but until the userspace support software is open this whole thing will make me nervous.
I'm a TurboLinux user myself, and I nearly hopped over to LinuxMall to order a SuSE CD when I heard about this. I understand that if PHT releases the code for TurboClusterD, it can then be incorporated into other distros thus lessening the incentive to buy from PHT. But I believe that the anti-proprietary backlash from the community could very well cancel out any gains they may make from being the sole provider of TurboClusterD. However, my worries have partially been put to rest by reading a comment posted by the TL kernel maintainer (moderated up to 5, shouldn't be hard to find) saying that their plan is to open up TurboClusterD in the not-tooooooo-distant future. Still, I think that bringing out the applications OSS along with the kernel changes is not only ideologically Right(tm), but could turn enough linux-using heads, idealist or otherwise, to get PHT better recognition and support in markets other than Asia (where it dominates, as SuSE does in Europe and RH does in US).
Please, PHT, open TurboClusterD!!!
MoNsTeR
I think if it defeats the whole open source concept people will shy away form it. I don't purchase any software to run ony my companies Linux servers if it's specific to a certain distribution, or a certain kernel. (I mean, requiring a kernel newer than X is ok, but if they're just going to provide .o files that will only insmod a specific kernel - forget it.) If you're going for a proprietary solution you might as well go for MC/Service Guard or something similar. I mean, you know HP isn't going anywhere, and that's the whole reason you spend^H^H^H^H^Hwaste that kind of money on a commercial system.
Well, how does TurboLinux differ from the situation above? Well...
- TurboLinux figured out from the *beginning* that it was to their advantage to release their module under GPL. Caldera's distribution went through several revisions before they decided to make the source code available.
- The size modification to the kernel is smaller! NKFS was 2940 lines of code, IP_CS is 2781 lines of code
- IP_CS is better broken up into approx 60 functions whereas NKFS is only broken into approx 50 functions.
- The header files for NKFS has only two lines of comment explaining the purpose of the data structures. The IP_CS header file has comments next to every variable and function defined.
- The NDS browser uses RSA code which is under patent and US export control which means that Caldera probably will never release the entire source code (if any) of the program which uses the NKFS module. TurboLinux has indicated that as newer versions of the cluster server daemon comes out that they will release the source code to the older versions.
- NKFS has never been a part of the offical kernel source distribution and Caldera has never indicated that they will try to submit it for being included. IP_CS is also presently not part of the offical kernel source distribution but TurboLinux appears to be interested in submitting it for being included in future major versions of the kernel.
- The November 1999 Linux Journal lists Caldera's website as having had approx 10,000 visits whereas TurboLinux was listed as having less than 2,000. It seems clear that Caldera has five times the influce in pushing a prioritary fork.
Based on what I have seen, if TurboLinux's handling of the IP_CS module was going to create a major kernel fork, then Caldera should have created such a situation long ago. Yet, history has shown that the main kernel distribution still has popularity even when competting with close source additives. The fact that Caldera has knowledgebase calls sbout using NKFS with kernel newer than they support is a good indication that users are willing to push vendors of prioritary additions to support the offical kernel rather than allowing the vendor dictate an alternative kernel. I think history has already spoken on this specific "fork fear" and it is a large strech to take TurboLinux's activities as the start of such a fork.So why are we getting so upset over the fact that George Weiss of Gartner Group Inc. has "fork fears"?! Isn't this the same G. Weiss that in January had fears about the "chaotic nature of the [Linux] market." He goes on to state "... best practices would entail putting in place practices to discourage, if not ban, code hacking when using Linux." Does this guy really understand Linux? The fact is that being able to code hack linux is one of it's biggest advantages. Another advantage is the growing number of non-standard modules. For example: you get better performce with INN v2 if you have rawfs, your not going to get far on the network with a Madge token ring card unless you have loaded the non-standard Madge kernel module driver and if you want to really fork from standard kernel method just put a distribution together based around the results of the GGI Project or RTLinux. Non-standard kernel patches and modules have been around for a long time and IP_CS is no different. History has shown that the main Linux kernel can survive this "problem." So, hand a spoon to Mr Weiss' "fork fears" and enjoy what TurboLinux is providing under GPL.
These guys never learn. Well the maintainer already spoke here. And clearly show that the story is one more of those Massive Media dreaming myths.
However there is an important point that he left out. This hype around TurboLinux seems not to have nothing to do with any Linux flavour...
The article's hype goes not much around technical aspects but about Linus "being forced" to introduce property software. It sounds much like an ultimatum. Well written btw. However for the managers but not for the techies. Any cluster expert may see how stupid the article goes by.
Well I'm a cluster expert. At least in the area I work I have to deal with 4-5 types of cluster realizations. As far as I know there are several more that don't go with the madness of the system we have here. Btw TurboLinux is one of them. Not because it is bad but because there are several technical problems to use it in the architecture we have here.
Now the problem. Why the Hell this guy says Turbolinux should go into the kernel? And why not PVM, MPI, MOSIX, Bewoulf's metamorphoses and several others I heard of? Besides 2.3 kernel seems to be showing some glimpses of one more cluster realization. So let's put the question... Why not? Because WE ARE NOT WINDOWS DAMN! Because we need a working system and not a bucket of flowers with the label "DON'T BREATH! DON'T SMOKE! DON'T SHAKE! DON'T TOUCH!" Because if Linux turns up to this side, then it will be DON'T BUY! Even if it is given for free... I don't need a "fully do it for you, in 234 flavours and 500Mb of property code" I need working code in a damn network with a quite restricted set of resources. I don't have 80 *(PIII dual processor + 20Gb HDD + 256Mb RAM) for playing "proprietary" W2K.
Don't use a jukebox, CD-R's on multiple machines in the Beowulf. Then you can burn CD's on the systems once they are done ripping.
Woohoo! Can you say 'pirate shop'? (peewee herman laugh)
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
Seems like things need to be clarified there - I've been using RH since their 4.0 release - and i've always downloaded the latest official kernel and customized it for my machine (smaller size, modules).
I've never had problems with the init scripts and "my" kernels. Now I'm using the RH 6.1 release with "my" kernel and while the init script spits out a warning, everything still works ok.
If you have trouble applying standard kernel patches to RH kernel source, install their kernel source RPM, apply your patch and then apply their patches.
In the end these little forks in the kernel source amount to very little difference in the overall kernel. 99.99% (if not 100%) of the apps still work on forked kernels. The main addition seems to be drivers just to support new hardware.
In my opinion little forks are actually quite healthy, as it keeps the development process moving along quickly. But to journalists used to seeing products from one company and only that one company makes modifications to their product,
something like multiple forks alarms them, just because it is different. They write about it from their point of view (read: spreading FUD) not understanding the dynamics behind the open source method of development.
Perhaps we should educate the masses about about the fork phenomena. Little forks are good (example: Linux and the AC patches). Big forks are bad (example: the pathetic BSD wars). However even big forks can be good sometimes, as was the case with gcc/egcs. I'm sure there's a goldmine here in explaining the dynamics of forking.
You have insulted gimpkind everywhere!
In-house animation rendering. Several of us are working on animation software for generating animated movies out of home without the need for Crays and SGI machines that companies like Disney or ILM can afford.
Perens' "tend to converge" & "A lot of the talk" are weasel-words. There probably true, but that doesn't mean there isn't a reasonable fear of GPLed code forking. There are plenty of examples. If someone put out a 10$ Linux boxed OS with a wonderful installer, super sys.admin. system, easy-to-use packaging system and half the kernel code replaced, you can bet there'd be one quick fork between the plain users and the die-hard hackers. The three major *BSDs (not necessarily other BSDs) are more open than Linux and they forked; had they been GPLed, the forking forces would have been just the same.
Big company forks kernel with secret and necessary modules; sells for 10 $ driving Red Hat stock value to 3 $. Linus claims Trademark rights and gets judge to stop Big company from calling their OS Linux. Note: I've read that the Linux trademark is being (IIRC, by Linux International) enforced so that it doesn't loose trademark status (which it should never have been given a couple years ago, since it had been in general use for years, IMO). More FUD: How long to you suppose Linus can live in Silicon Valley amongst the thousands of millionaires and not decide to make some big bucks off his trademark?
Okay, here's the most likely course of action for Turbocluster patches once they get submitted. If the patches (which, admittedly, I've yet to read) are just cryptic "hooks" used by proprietary Turbocluster software, then I am very certain they don't have a snowball's chance in hell of making it into the stock kernel. If they are a well-designed architectural extension for clustering, then Linus may accept them. Or he may propose some changes, some people may modify the patches, some minor modification may be accepted. TurboLinux will find it much easier to make small changes to their product to fit the accepted version than to maintain a separate kernel. So we might end up with a very well-designed clustering architecture in the kernel with no open source tools. Great! So now anyone who desires can use proprietary tools, while others of us can write open source clustering tools for Linux. In either case, the kernel architecture is open source (has to be to be a kernel patch) and all of Linux benefits from a good, open source clustering architecture in the kernel. The only risk of a "fork" is in the time between a proposed patch and when Linux and others are comfortable enough with the patches to include them. During that time, use of Turbocluster will mostly be testing in a few situations, which will make things that much more stable when a clustering architecture gets included in the kernel. Nothing to be afraid of either way.
void main() {while(1) {malloc(1000); fork();}}
any admin who has the slightest idea what he or she is doing will have already put in restrictions to prevent forkbombs from causing probems. If..
oh, wait, we're talking about forking the kernel source, not fork()? Wha? Who cares? Isn't the point of open source that if Turbolinux wants to improve the kernel how they see fit, they can? Won't it all be compatible anyway? If this kind of thing worries you, you ought to be crusading to have the support for PPC and other "alternative" hardware types brought into the main part of the kernel tree.
"there is no spoon.."
For those readers with short attention spans, I'll summarize:
TurboLinux has no intention of forking. He says its far too much work.
The userland stuff is probably going to be open-sourced with the next release
Now I'm sure everyone has much more important things to do, like updating their much beloved and witty diary entries *cough* Alan *cough* (oh, and maybe those kernel whatchamadoos...)
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
The Asian Language support in TurboLinux isn't completely free software. It includes OMRON's Wnn6 and a Japanese Dictionary CD ROM.
Well, I'll certainly meet you halfway on it. I do apologize for calling you a liar, but I still stand on that grounds that what RH does (shipping a tweener kernel) is very different from what the article implied TL was doing - shipping a kernel with additional code specifiacally designed to 'add value.'
:) Funny how that works out.
I did, however, state in all of my posts that I was referring to stock kernel + the AC patches, which I think you've proven for me. In any case, it's late, and this thread is old, and we're both right, and we're both wrong.
And, yes, _I_ was wrong, and yes, to reiterate, _I_ do apologize.
--
blue
i browse at -1 because they're funnier than you are.
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.
c'mon, Hemos, stop and count to ten, and maybe ask someone else before you post the story. Don't just repeat what you read in the article - you should know better than to think that the mainstream media could actually understand this and report it properly. instead of getting everyone in a panic about the kernel being forked, why not post a story about what kind of idiot would write this article, because we all know that the kernel is GPL, and forks are very unlikely (if it's a good patch, why wouldn't Linus paste it in?)
Schrodinger's cat is either dead or really pissed off...
The Resgister story, with more info :-
http://www.theregister.co.uk/991028-000002.html
Any sufficiently advanced man is indistinguishable from God
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.
I hate to fuel this debate even further, but let me quote docwhat (docwhat+nospam@gerf.org) who posted a followup elsewhere who claims to be a Red Hat employee (re: same thread) :
Our kernel has different slightly different goal, and has different patches. We want our kernel to be stable of course, but we include (naturally) our cluster support, IBM ServeRAID, drivers for companies that we have agreements, etc.
To me, this indicates that Red Hat are 'adding value' exactly the same as TL.
The biggest turn-off for me to do with TL's modifications is that the software to utilise the features costs money, but the kernel modules will probably be eventually freely distributable with the kernel. What's the point? They may as well keep it with the software and apply kernel modules during installation of the software, it's not going to be any benefit to everyone else unless someone is going to code a free replacement for the front end software using the same kernel modules? Seems about the only reason why it would be worth introducing into the stock kernel.