Slashdot Mirror
2.4, The Kernel and Forking
darthcamaro writes "We all assume that the kernel is the kernel that is maintained by kernel.org and that Linux won't fork the way UNIX did..right? There's a great story at internetnews.com about the SuSe CTO taking issue with Red Hat backporting features of the 2.6 Kernel into its own version of the 2.4 kernel. "I think it's a mistake, I think it's a big mistake," he said. "It's a big mistake because of one reason, this work is not going to be supported by the open source community because it's not interesting anymore because everyone else is working on 2.6."
My read on this is a thinly veiled attack on Red Hat for 'forking' the kernel.
The article also give a bit of background on SuSe's recent decision to GPL their setup tool YAST, which they hope other distros will adopt too."
You're moderated as funny, but it makes the point I was going to make. The venders routinely do not ship with a vanilla kernel. I do not believe that RedHat/Fedora is not alone in shipping with a heavily patched and customized kernel. It's hardly forking, it's just the way they package up the kernel.
before 2.6 existed, their 2.4.x kernels looked WAY more like 2.5.x kernels. I always thought this was dangerous, as what they were effectively doing was dressing up "alpha" 2.5.x code as "stable" 2.4.x code and letting it run riot on people's production servers.
Everyone I know *hates* Redhat, but they seem to be a serious player in terms of persuading the rest of the world that linux is important! I run Redhat 9 on my laptop. It installed without hassle, it runs pretty well. And at the time I liked it cos my knowlege of linux was as big as the file I've attatched to this post:
Red Hat Enterprise Linux is pretty much the standard at this point for electronic design automation (EDA) tools. This means that it will be used in the design of most chips produced this year and in the next several years. It's 2.4 based, and will remain so for some time.
If datacentres and hosting companies are deploying this widely, then you can be sure that there are many sysadmins out there who are creeping up the learning curve and are unaware of precisely what they run on or what it means (2.6 kernel performance with MySql should prompt many to upgrade, but it doesn't).
So the 2.4 kernel is far more widely deployed than you may initially suspect. This is where Red Hat are making their money and why it matters to use.
The fear is that a version of Oracle will come out that depends on 2.6-ish kernel features but doesn't actually work on 2.6 proper (i.e. it has dependencies on 2.4-era semantics). At that point, the only way to run Oracle -- no matter your toolchain -- is to use the Redhat kernel.
--Dan
Are the people sticking with 2.4 the sort that need two years of meetings and proposals before they're allowed to bump a version number? (I don't see that back-porting mods is less risky.)
One line blog. I hear that they're called Twitters now.
# diff base.c base.c.original
1417c1417
real_parent; p != &init_task; p = p->real_parent)
---
> for (p = current->p_opptr; p != &init_task; p = p->p_opptr)
It seems that RedHat's testing methods weren't so good, and they neglected to see that certain things had had their names changed. Since they didn't test their kernel, it made it difficult to track down that particular error when trying to recompile the kernel.
libertarianswag.com
Was that different or are they the most recent victims of marketing doublespeak?
ich bin der musikant
mit taschenrechner in der hand
kraftwerk
As a happy user of a 2.4 kernel with backported
features from 2.6, I love the fact that Red Hat
went the extra mile to provide this feature.
We have been using NPTL extensively in the Mono
debugger. Without it, it would be much harder
to write the debugger for Mono.
Miguel.
If you have a problem and you bring it to the kernel hacker who made the subsystem you're using, it's really very difficult for them to support Red Hat's thread. Generally they just say to look to the vanilla 2.6 kernel.
Bruce
Bruce Perens.
LinuxPPC is merged back in periodically too. Hence the reason that forks of Linux don't have the effect forks of Unix did. They're not all hiding their work from each other, and they're all allowed and willing to take the good from another fork and incorporate it into their own trees. Even if they don't, users are free to if they wish. Forking can be healthy in a free software environment.
You want some examples of open source forks? How about ssh -> openssh? X11 -> Xfree86? Xfree86 -> Xorg? emacs -> xemacs? BSD -> FreeBSD/NetBSD/OpenBSD. There's probably thousands of packages out there that have forked for whatever reason (usually political) and are open source.
Personally, I think this issue of Red Hat shipping a custom kernel is a non-issue -- they've been doing this since beginning, and so does everybody else. I guess technically it does qualify as a fork, but forks are not inherently bad.
I work for the Dept of Defense. 3 years after I say we should go Linux, the shop has abandoned Windoze for our production (web, jakarta, Oracle) sites. Before we were running OpenBSD for firewalls and such but I was FT then and we could get away with patching and recompiling stuff.
.29. They backport the changes to .26 and leave all their package information, banners, the whole kit-kaboodle the SAME! Just a very minor build number gets cranked. Not even the Changelog bothers to specify what CVN was addressed or that it's even a security update. Ditto OpenSSL, Mod_SSL and everything else. The *ONLY* way I have of confirming the security patch is there is to download the SRPM and diff it against .29 and see if it's there.
Now that I'm off-site and PT the responsible thing was to use a package system that was commercially supported. Enter Redhat. We run v2.1AS and v3ES/WS.
This backporting stuff in kernel-land is nothing. It's WAY WORSE when it's userland stuff. eg. Apache. RedHat updates to 1.3.29 because of a security bug but they don't actually upgrade to
Naturally all the security check software is looking at banners and falls all over itself giving me warnings about vulnerable software when I know it's all patched. It makes a lot of work for me when our network minders run probes against our boxes and come up with all the errors and they run screaming to the dept heads with "hundreds of vulnerabilities!" and I have to go PROVE my boxes are up to date.
THANKS a FREAKIN' LOT Redhat!!! How come the rest of your enterprise customers haven't tarred and feathered you over this STUPID practice? Track the damn source revisions, would you? It's one thing to want to provide "stability" but point releases are just that, fixes for broken features or security updates. The damn package should be clearly labeled 1.3.29 everywhere. It's one thing to force customers to go from 1.3 family to say 1.4 family (yes, I know, doesn't exist) and I can appreciate not being put down that path, but the current setup is just a disaster.
According to my machines I'm runing OpenSSL 0.6.9b though the code is actually 9m.
OK, so I sit here and read many postings about why OSS Java would be a "good thing", and then I run across something like this.
I have to say, the uproar over this doesn't make any of the "oh, it'll be fine" arguments that pro-OSS Java folks have been throwing around sound all that great.
I mean, if the Linux kernel itself has this happening to it, what sort of chance does Java have from preventing it, if it goes OSS?
yet anothing redhat kernel war? don't get me wrong, but I never liked redhats patchparty really much. there gcc 2.96 compiler used to segfault the hell out of my redhat distro, and the kernel itself was the biggest patch pile I have ever seen in my entire live. I never was never succesful in compiling it. (not to mention compiling non-kernel.org modules.) there "performence" patches also gave me lots of trouble with more advanced code. (wine emulator anyone?) in short: I hope this fork will be soon forgotten, and redhat will spend its time in sending patches to linus for inclusion in the linux 2.6 kernel instead.
This is something the SuSE does as well. And so will IBM - just wait until a patch they write for mainframes isn't accepted by linus for some reason.
So suse's yast is gpl and is 'inviting others to join in'? Its about freakin time! They have no right to talk about wether other people should gpl thiers or not. Redhat's has ALWAYS been opensource and it was one of the main reasons for me to choose Redhat over Suse (if I want a non-gpl server I can always use sun, or bsd).
Also, Redhat's 'forked' 2.4 is the reason companies pay Redhat big bucks! That way buisnesses can get some important functionality (like ntpl, which is a huge leap for threaded applciations) while keeping away from the other, not-so-stable features, and not having to upgrade the whole kernel. Sheesh, this sounds more like a flame then anything else...
The guy mentions problems with support from Debian, hardware and software.
I fail to see what's wrong with Debian and hardware. As for software, the only problem is proprietary software like Oracle. Which is non-SQL compliant, expensive and bloated anyway.
Leandro Guimarães Faria Corcete DUTRA
DA, DBA, SysAdmin, Data Modeller
GNU Project, Debian GNU/Lin
More to that point, Linus now has a Power Mac G5 so the mainline sources for Linux has to be kept up todate.
No kidding. SuSE has a history of shipping kernels with ALSA sound drivers instead of the standard OSS drivers. Yet no other company complained when SuSE wasn't shipping plain vanilla kernels.
> Personally I feel it's a big mistake. Linux 2.6.x is stable now, so
> use it. It's also much faster.
2.6 wasn't here last summer when RHEL3 was being built. But RH wanted several of the features for the new version, since it was going to be around for five years and all that jazz.
RHEL4 is looking like it will be 2.6 based, but they are adding in SELINUX. RedHat is usually out near the bleeding edge, but just far enough back that they don't get cut up too bad.
Democrat delenda est
The article didn't argue that nobody had the right to fork anything or that the GPL wasn't about freedom.
He merely said it wasn't a good idea to be backporting. Freedom also includes having opinions on the choices people make.
I love when someone criticizes something, and people jump on it claiming, "but they have the RIGHT to do that!" Nobody was saying they didn't have the right--they were just criticizing the choice they made with that right. Free opinion, man.
I think Slashdot holds a lot of responsibility in this case for publishing unverified sources like the Qt article (and others).
I might say that Slashdot also bears a lot of responsbility for publishing a summary that miscasts the SuSE CEO's argument -- he's more concerned about an extreme level of backporting (and discouraging adoption of 2.6 to stay on 2.4 with backported features) than about backporting in general. SuSE backports stuff too.
Not sure if I agree with him or not, but that's a separate issue.
DNA just wants to be free...
I always favored Red Hat over all other distros for a very long time. I tried Debian, Slackware, and Mandrake, but always found myself back with Red Hat. Not to long ago, I upgraded to an AMD64 CPU and heard that SuSE 9 for AMD64 was the best for that platform and gave it a shot. I liked it so much that I went with SuSE on my other systems. Recently, our company FINALLY started to replace some Sun systems with Linux machines and RH Enterprise was the chosen distro. So far, I am very satisfied with RH EL and see nothing wrong with backporting features.
Its not like they're closing the source to the kernel and preventing others from either removing them or copying them. In my opinion this is a non-story.
"The words of the prophets are written on the Slashdot walls."
I had a problem trying to get RH9 to work on an Athlon64 system a few months ago. I downloaded the vanilla 2.6 kernel as I've done with other distros, followed the directions and did everything I was supposed to, and then it wouldn't compile, needed special extensions to work with RH... then X was screwed for some reason. In general RH9 is just not made for the 2.6 kernel. I didn't try the 2.4 vanilla kernel because I didn't think it would add the functionality I needed.
-JemUnfortunately I may have made it all a little too easy to use and install, as they eventually made me redundant.
Going from 2.4 to 2.6 worked great on Debian and Gentoo, but they automatically download the proper extras for you whereas RedHat only distributes single RPMs for everything. I see where my mistakes were, but the problem lies with RedHat and the way they distribute software. RH9 is really not meant to be upgraded; it is designed to be replaced by RHEL.
-Jem