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.
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).
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.
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.
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)
Thanks
Bruce
Bruce Perens.
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)
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.
So, since Alan Cox works for Redhat it's OK for Redhat to ship modified kernel source, but not OK for Pacific HI-TEC?
This is Free Software, as long as the patches comply with the licensing terms of the Linux kernel the distributers of TurboLinux have every right to ship a modified GPL kernel source, just as they have every right to ship a distribution which contains proprietary closed source drivers bundled as binary modules.
You can't call the GPL'd patches included with either Redhat or TurboLinux innapropriate because that complies with the GPL. And you can't call the proprietary kernel modules innapropriate (even though Redhat doesn't ship proprietary kernel modules with it's distribution) becuase Linus has made quite clear that he accepts the legality of priprietary binary kernel modules.
So, how is this different from Redhat, or any other distribution vendor? And how am I baiting flames with my statements?
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)
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.
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.
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
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.
No, since Alan Cox is one of the three core contributors to the linux kernel, since he regularly supplies updates, and since he is the person who puts together the kernel that Red Hat ships, it is ok for them to ship whatever the hell they want to - it IS the linux kernel. That would make a great piece of Red Hat Trivia - name all of AC's changes to the kernel shipped by Red Hat that Linus later nixed. I'm sure there are at least 1 or 2.
You insinuated that they were shipping extensions, modifications, or additions to the kernel that are not part of the 'stock' linux kernel, and that is false. Their CONFIGURATION of said kernel is quite different from what Linus or Alan choose to post, ie, the default configuration, but I know you're much too smart to be confusing configuration with code - at least, I've had enough respect for your posts in the past to hope so.
I'm insinuating nothing of the sort, I'm stating it outright. All you have to do is run a make config on the RH6.1 2.2.12-20 kernel which is supplied with the distribution against a make config from a stock 2.2.12 which has been blessed by Linus and diff the comparing
_I_ am not calling anything anything, other than calling you on crack - show me these 'patches' that Red Hat ships. The TL patches are really that, patches that apply against a base stable or devel release of the kernel. This is an extension of the existing kernel. Red Hat supplies, to my knowledge, no such patches. They supply a kernel, a stock linux kernel, usually a branch of the stable release. There are no PVM extensions, there are no scalability extensions. I think you might be confusing the fact that they, by default, enable almost every single driver available to be built as a module, with them including extra code. They supply those modules because they are needed at install time to interface with the customer's hardware.
Now who's baiting flames? Like I said, as long as it meets the guidelines of GPL licensing, it's perfectly legal! Free Software isn't about whether you like it that I can include my own GPL'd code in your distribution, it's about FREEDOM to modify your and my code as I see fit! Pacific Hi-Tec isn't even skirting the laws here, unlike Corel with their previous beta Corel Linux program, they are releasing a set of GPL'd patches and some proprietary kernel modules... all actions of which Linus has made perfectly clear in the past he supports.
See above for how it's different, and you're baiting flames by making completely false claims. A lie, to me, is always flame bait.
I didn't lie in the first post, and I still don't see a single person who has pointed out even a factual error! I'm perfectly happy to be corrected with factual mistakes, but to call me a liar simply because I wrote a seemingly unpopular truth really stretches your point. And I note that since moderators have chosen to moderate this down to the cruft, nobody cares anyway. Still, Damn rude on your part.
Cheers!
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.