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.
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.
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
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.
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.
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.
Please don't moderate total falsehoods like this up - this is flamebait. Alan Cox, the actual primary code architect of the Linux Kernel, is a Red Hat employee. While RH does often ship a 'tweener' kernel, or one that is in some state of AC's patches, there is nothing at all non-standard about it. They simply ship the newest build that they have on hand at the time of pressing. They occasionally even update the kernel image during single revisions.
And, if I'm wrong, please reply with a list of drivers or patches that RH has included since, say, 4.0 or so, that weren't available as kernel.org + current AC patch.
Secondly, IMHO, SCO's CEO need a lot more fiber in his diet. You could randomly take away every other file in Red Hat's distro, ship it, and it would STILL have 'more value' than SCO.
i browse at -1 because they're funnier than you are.
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)
We are overworked as is. I will not, as TurboLinux's Kernel Maintainer (Kernel Colonel?), fork the kernel off. Having Alan Cox, and the wonderful crew in Linux-Kernel maintian the core stable kernel makes my life *much* easier.
The Cluster Module is just a module! It can be compiled in later after the kernel is done. It cannot (yet, as far as I can see) be compiled into the kernel as a non-module.
Feel free to grab the cluster module and see for yourself (You'll need to hold shift):
cluster-kernel-4.0.5-19991009.tgz
Ciao!
The Doctor What (KF6VNC)
I am the kernel maintainer for TurboLinux. Your email hasn't arrived in my mail box yet. I suspect that you sent others in my organization. Most of us are at ISPCon, so it hasn't filtered to me yet.
We have no intent of packaging and maintaining a seperate linux kernel tree. It would be too much work for no benefits.
Our kernel RPMs includes the base standard kernel tarball and additional patches. You can get all the additional patches out of the .src.rpm file. You can build a complete kernel from the .src.rpm file.
I have not put up a web-page or submitted it to Linus et al as I have not had time. Our primary concern is getting a quality product to our customers.
You may get the TurboLinux Cluster Kernel Patch here (You'll need to hold shift to download):
cluster-kernel-4.0.5-19991009.tgz
Does this answer all your questions?
Ciao!
The Doctor What (KF6VNC)
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
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.