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."
Is anybody really still paying attention to RedHat's 2.4 offerings? Does it look like they'll keep up the backporting practice?
- To err is human; but to really screw up, you need a computer
News at 11.
-- MartinG To mail me: echo kewyjlcxyzvjfxbqwh | tr bcefhjklqvwxyz
Does anyone here still use Red Hat?
There are tons of kernel patchsets out there. some (ck-sources for example) include 2.6 code as well.
Working on 2.4 is like working on an old Dodge Dart. For collectors and enthusiasts only.
thisnukes4u.net
Since when is it OK to develop a new kernel and abandon one that many users are still betting on?
2.4 can have new things added to it, there's now law that says it can't.
And if the 2.4 maintainers have found some good additions, well, all the better for users of 2.4
I don't know the meaning of the word 'don't' - J
Why is this really interesting? Open Source / Free software is designed for forking. Why dont they just call it "RedHat kernel" or something?
RedHat has been backporting patches forever. That doesn't make it a fork any more than the actual kernel forks. Look at the LinuxPPC tree for an example of a real fork. Look at rtLinux, uClinux, and all the other actual kernel forks before crying wolf.
Kernel forks don't kill the kernel.
Things have always been this way. None of the major distributors ship a pure Linus kernel, including SUSE. Everyone includes patches. Backporting 2.6 features helps everyone because it subjects those features to more testing, meaning that 2.6 will be better as a result.
Red Hat has more kernel hackers than anyone else, which means that they have the ability to support kernels with more hacks. So what SUSE is really saying is "How dare Red Hat use its competitive advantage?"
Finally, it's not true that "everyone else is working on 2.6". People in the "open source community" are still maintaining 2.2, remember. Future 2.4 releases may well include some of the backported stuff developed by Red Hat and others.
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.
How many times have we argued this issue? At this point it has been resolved hundreds of times here on Slashdot, and many thousands of times in editorial write-ups elsewhere.
YOU CANNOT FORK OPEN-SOURCE CODE, people can do whatever the hell they want to with it, including back-porting features... BECAUSE YOU HAVE TO SHARE THE SOURCE.
What is so complicated about that? The entire concept of a "FORK" requires secret proprietary source code and copyrighted functions and pantented methods.
... What happens when the Linux kernel starts spooning? We will never see him again, because he will be spending all his time with his new girlfriend. That is until she kicks him to the curb, and he comes crawling back looking for his old friends again.
You know you have all seen this happen a million times before.
Red Hat's applying a few patches.
.config files are compatible (i.e. make oldconfig). The config/menuconfig/xconfig interfaces are the same. Red Hat's kernels track kernel.org version numbers, but just apply extra patches.
I use Red Hat's distribution.
I don't, however, use their kernel; instead, I use a kernel.org kernel that I compile myself.
The fact that this isn't just possible, but is easily (i.e. drop-in) possible, indicates that There Is No Problem Here.
The kernel is binary compatible. The
This is not a "fork" of the kernel in any meaningful way.
STOP . AMERICA . NOW
Redhat is supporting a kernel they've used for some time now, by backporting patches. What's the big deal? *Lots* of people are going to be running 2.4.x for a long time, and having vendor support still available is great. We should be supportive of Redhat here.
The worst thing they could do is drop support for 2.4.x entirely and mandate everyone upgrades to 2.6.x. Why make such a major change to something that works?
The whole Goatse thing is all about backporting, I think.
I *might* agree with the CTO of SUSE if Red Hat backported features, but didn't support them. Yet that is not the case. Red Hat promises a 5 year support for their Enterprise Linux releases, and I'm willing to pay for such a support. For my company's systems, I don't need to stay on the edge of new features, tools and other improvements. I NEED a stable operating system, requirering low change management (expect for security issues).
Redhat backporting features into 2.4 for their own customers is a win for everyone and yet another victory for open source. Case closed.
This is insane. What is the GPL about if not the freedom for an individual or business to make changes to the kernel and distribute those changes? If Linus wanted to maintain a single point of control, which is what this guy is indirectly advocating, he would have used a different license.
This is a very dangerous attitude from a company that is supposed to be steeped in the GPL. "Work it our way or don't work it" is not an attitude that helps the open source movement. "Let a thousand flowers bloom" should be the theme.
Sounds to me like SuSe is upset that they will have to either duplicate this work or use Red Hat's work in order to stay competitive.
"It is our blasphemy which has made us great, and will sustain us, and which the gods secretly admire in us." - Zelazny
And I'm willing to pay for the long-term support of my company's systems.
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
# 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
But is this testing in a different context or enviroment -- i.e., of a patch or feature in 2.4 instead of 2.6 -- useful? More precisely, is such testing as useful as the testing of the patch or feature in the enviroment for which it was designed, i.e., 2.6?
Only Women Bleed (Sex, Sharia remix)
If there's one thing I learned from Magic: the Gathering it's that Forking will never make you any friends. It's also illegal and banned under type II rules. Just like a Red Hat deck...always stacking, full of burn, and ready to screw over the entire community with a 20 point forked Fireball...
Wise men say, "Forgiveness is divine, but never pay full price for late pizza."
Was that different or are they the most recent victims of marketing doublespeak?
ich bin der musikant
mit taschenrechner in der hand
kraftwerk
This is a pretty important point - If we expect Linux to continue getting mainstream application support, then we need to make sure that all distros can compete.
This just goes to show that SUSE is relying on a full steam ahead adoption of any new version rather than a more carefully planned transition between versions. I still run 2.4 (conversion is set for a couple of months from now) and appreciate backported stable features. Providing the latest and greatest is a good thing I guess if you are a in this individually or as a hobby, but I'm not interested in upgrading until a product matures and I have regression tested everything. SUSE seems to not understand that, which would disqualify it for me as an enterprise vendor.
Sig under construction since 1998.
Memo
To: Suse CTO
From: Concerned FS user
Hey dude, don't start being a dickwad to other FREE SOFTWARE companies.
If you attack other FREE SOFTWARE companies for no reason other than marketing expect me to blacklist you from my future purchases.
...what happens when the Linux kernel starts spooning? We will never see him again, as he will be spending all his time with his new "girlfriend". That is until she kicks him to the curb, and he comes crawling back looking for his old friends again. You know you have all seen this happen a million times before.
Fork off!
(Yep. That was 10 seconds of your life you won't get back again).
Norman Cook's Ode to Sl
There 2.4 kernel has support for lmsensors, which is not in 2.4 default. They have support for more drivers to. So what. Redhat will support these features if they put them in their kernel. They have to, especially since there new business modle is selling redhat OS for a pretty penny.
I would think that Fedora would just make their system 2.6 asnd 2.4 compatible when Fedora core 2 comes out.
I've had issues with Redhat doing things like this in the past, and you can still use the default kernel with Redhat, you just have to know what you are doing.
SuSE has their own kernel too. They are just upset cause they didn't think of it first. Some people will not want to upgrade to 2.6 because of its newness, but they will want the features. If these can be ported back, and supported by Redhat then what is the big deal? Its open source people and as long as Redhat gives the source code away also they are well within their rights under the GPL. Remeber the GPL says something about "use and modify as long as you give the source ...". They always have done this and always will. So what!
Only 'flamers' flame!
Does slashdot hate my posts?
Xinetd wasn't just something that Red Hat threw together to upset you -- it was a well tested, established package that they decided Red Hat would benefit from.
And Red Hat didn't just put the x in there -- it was there long before Red Hat existed :)
I'd see this mostly as SuSe posturing.
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?
First of all, some of us assume "the kernel" is /kernel/genunix or something else, because we're working on Solaris or something. (There's one assumption on you're part that was unspoken: we're not all Linux users.) Secondly, I don't assume the kernel will never fork. Forking has often been very productive for Free Software programs, and the right to fork is one of the most valuable incentives for development. The kernel has forked all the time (remember the -ac tree from Alan Cox? how about uCLinux?), and that's a good thing.
So your explicit assumptions that "we" "all" have, that the kernel will never fork, are wrong, as well as your implicit assumptions that we all use Linux and that forking is a bad thing. Thus I'm not sure what the big deal is.
Secession is the right of all sentient beings.
My company sells product to large enterprises, and most of them run one of the RedHat expensive-support options. We've seen few instances of other commercial or custom distributions.
For a list of the 2.6 features that have and have not been back-ported into 2.4 for the current RH Enterprise Linux release, look here.
But is this testing in a different context or enviroment -- i.e., of a patch or feature in 2.4 instead of 2.6 -- useful? More precisely, is such testing as useful as the testing of the patch or feature in the enviroment for which it was designed, i.e., 2.6?
I'd think it's more useful to test it in 2.4 as well as 2.6 rather than only testing in 2.6. Sure, it's more work (work that RedHat is willing to do) but it may turn up bugs in conditions that do not occur in 2.6 yet (or not reproducibly, etc.)
SCO employee? Check out the bounty
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.
It sounds as though someone took the time to backport it through the babelfish translation engine a few times.
This is one of the things that makes debian's stable tree live up to it's name. It isn't a bug in opensource, it's a feature. Now, of course, this puts additional pressure on debian to ensure that their stable branch continues to work as expected considering that the stable software is patched in a way that's unique to debian. But if they want to do that, good for them. It's up to their users to decide if this is a good practice. And historically, it's been an excellent practice.
Is SuSe saying that they don't do this? Are they saying that if you're using a piece of software that they distribute that's slightly older than current and a patch comes out for current, that they won't patch the old software? If so, that leaves SuSe customers with a horrible choice:
I wouldn't think that'd be good for business. legacy piece of software on their distro, and a patch for a current version comes out, that they won't support it? I would think that'd be bad for business.
Key to financial independence: Spend less than you earn. Save and invest the difference. Do it for a long time.
In the grandparent's defense, they did say none of the major distributors.
i moderated you overrated instead of underrated by accident, so i'm just posting this to void my moderation ;)
kernel-2.4.20-30.9.i386.rpm contains LOTS of non-mainline patches.
And this is not new. Redhat's kernel packages have always had LOADS of backports. For example, 2.5.x NPTL into 2.4, and 2.4 USB updates into 2.2. Personally I feel it's a big mistake. Linux 2.6.x is stable now, so use it. It's also much faster. But whatever, it doesn't affect me because I have a choice. (It's not like this is Windows we're talking about here).
I'm currently running linux-2.6.6-rc1 and doing just fine ;-)
Both Red Hat and SuSE have been backporting fixes into older kernel versions and shipping 'older' versions of kernels is primarily due to stability requirements.
Distributions elect to use a given kernel version every once in a while. By not keeping up to date with the latest kernel.org tree, they gain the advantage that their codebase is much slower moving and they are less likely to have new bugs introduced from outside sources. Doing so also gives them the ability to accrue intimate knowledge of the inner workings of that specific kernel revision.
As distributions support a kernel, new bugs, vulnerabilities, hardware incompatibilities, and scalability issues arise. By selectively culling those single bits and pieces and patching their supported kernel, they are able to easily test the fixes without the larger risk of regressing in other areas.
At first, this practice may appear to make the distributions look 'unfriendly' towards the opensource development nature of the Linux kernel, however this is far from the truth. As issues arise in the distro-supported kernel, fixes are also created which are later pushed upstream to the Linux kernel proper (as long as they aren't considered gross hacks that is).
In essence, distributions settling on supporting specific kernel versions and patching them is very much in the open source spirit. OSS has the advantage that you may use any code drop you want, and if you fix something, the neighborly thing to do is to share the fix (which under certain license is enforced by law under some conditions).
I thought this falls right into Redhats plan all along. They said when they introduced that fedora thing that the redhat release wasn't going to be cutting edge anymore, it was going to be tried and true stable.
It just goes to show that redhat is offering stability and usability not cutting edge. I think this is a valid marketing arguement especially when people have been recently saying things like linux is always in a state of development. PHB's that were convinced to use linux and settled onto redhat would look at installing a feature as installing another program verses updateing or upgradeing kernels to another os level.
In other words, they need the flexability to do that while bugs get worked out of the 2.6 kernel. Once the new kernels reach a level of depenability thay are shooting for, it would make sence to switch. It is mostly about marketing not circomventing the development proccess.
--spelling is a sign of me actually caring
emerge vanilla-sources
Overrated / Underrated : Moderation
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.
I run xxxinetd on all my systems for that extra flavor.
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?
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.
Folks,
2.4 Kernals are still being widely used in applications that are doing real work for real world applications. Just because the bleeding edge is well into 2.6 doesn't mean the rest of us who have better things to do besides compile kernals on a nightly basis need to upgrade. A lot of applications require stability, long periods of time that you can't make major changes so as to not upset the development or even production envionment.
RedHat is just trying to keep their Enterprise customers happy and patched with security fixes and some minor feature enhancements. Like it or not, they are a real company and have to make real $$ which means they have to listen to their customers who pay that $$$. The customers can't or won't upgrade to the new 2.6 kernals right away, they need to bring it in-house, test and redo their programs that are running production databases, programs,etc.
Hell, RedHat 8.0 to RedHat 9.0 is painful enough for most folks. Now going to RedHat Enterprise or SUSE or Mandrake..etc. That's painful, read expensive in time and money.
Get over yourselves.. I can compile customer kernals, but frankly I have a lot more better things to do with my time. RedHat knows this..and they're helping their customers do the job of actually getting business done.
I'm thinking of starting the process of going to a 2.6 based distro probably sometime in the Fall. This means it probably won't be in any production server until after New Years at the earliest.
-=TekMage
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...
Doesn't SCO only claim ownership of later kernels? I thought that the 2.4 branch was not something they claimed they owned, thus by supporting and using 2.4, one sets themselves free of the pains of worrying about the impending knock at their door by SCO and their lawyers!
Help Brendan pay off his student loans
I was going to use Debian after getting pissed off with the awful mess of RPM's and having to install apt-rpm.
Of course when i went to get it I couldn't cause they were still down after being cracked, so I plumped for gentoo. The victim PC was a Dual Xeon so the stage 1 took very little time, and it's a lovely way to do thing. I almost went back to BSD except for it's not quite sorted SMP support
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
Why are these guys backstabbing each other? There's so much of the Windows and Unix market to take over even in the server space, and of course on the enterprise deskop is a huge market segment that linux has a decent shot at breaking through, so it would make a lot more sense and would be beneficial to both of them if they co-operated rather than fighting with each other.
Enterprise customers are generally very careful about making significant upgrades to their servers. Security patches and application fixes are expected, but a new kernel throws them into a huge process of integration, compatibility, and stability testing that they don't want to be forced into. The same thing applies to application vendors.
So, RedHat backports desired pieces from the 2.6 kernel, so they can give their customers a more manageable update process.
While fast paced updates are great from the hobbyist perspective, enterprise customers have a whole different set of prioritites. This is one of the big things they touted for the RH Enterprise Edition.. it is supposed to have a more manageable update process, sticking with the same core kernel for longer periods of time to ease support and management.
wow... i wish i didn't have a job. then i could post longer than 2 fragmented sentences as a reply.
...Also supplies a kernel-linus package as an option.
anyone still use Oracle?
Suse Linux 9.0 had features backported from the 2.6 kernel so what are they complaining about?
Yes, bring on the flames. I can feel their warmth already.
Year 2052:
Linux Fork #97533 becomes self-aware.
Year 2152:
Linux Fork #339268 runs for president of the U.S.A "I have a solution to any problem".
Will code a sig generator for food
RedHat explain it here, and as a paying user of RHES3.0 in an enterprise environment, I think this is a good approach for them to have. The features they have left out feel to me to be the more risky sounding things that aren't essential like the new IO sub-system and scheduler tuning, while the things they have taken seem to be more applicable to the apps they may expect users to run e.g. O(1) scheduler, native POSIX library and Huge TLBFS
Interestingly on their page they also list 2.6 as not having Hyperthreading support, while their 2.4 does.
-- Mike
RedHat backports 2.6 features (actually they'd be 2.5 features) to provide the most powerful kernel that they can support (i.e. make it run stable). If RedHat was planning on taking 2.4 and moving in a different direction that would be a fork and it would be a problem. But RedHat has already announced that RHEL 4 will use the 2.6 kernel. Any vendor who builds an app that depends on backport patches and won't run on 2.4 or 2.6 vanilla is just plain stupid. Yeah, it can be done, heck you can lock yourself into pretty much any platform you want as a developer, but why? RedHat has made it clear that 2.6 is the future. That's good enough for me
Is it just me, or does Novell really have a problem with the images of these two companies? It seems to me they're trying to give the impression that Ximian and SuSE are in competition....
First that weird article about adopting QT across the board, now this. And I'm sure I'm forgetting some other such issues too. It gives me the impression that SuSE people and Ximian people have never even had a conversation with each other.
... have you tried any of those audits against a test machine running FC2 (whatever RC it is now, haven't looked) to see if you get similar warnings?
And if I understand this correctly, the code works fine for you,but you just get a lot of what in essence are false positives with the auditing?
heh, if so, treat it as a training feature, keep them boys on their toes!
This isn't a back-port of 2.6 features to 2.4; it's a defeaturing of 2.6 to emulate 2.4.
At least, that's my perspective on it.
Whether RedHat marketing understands the Arrow of Time is a question only they can answer.
...fork it all to hell.
Considering the fact that you obviously don't know much about databases I'll save the fuel.
I'm surprised that someone from an opensource-supporting company would sling FUD like that. This statement sounds something an old-school business practitioner would say to sell their product and discredit their competition.
First of all, forking is not a bad thing per se. In fact, it sometimes leads to better code. In this case, Red Hat is not doing anything divisive. They're merely maintaining their old code.
As for interfering with standardization, RedHat has done nothing but push for standardizing on the latest stable code to come out. They pushed gcc 3 back when people were bullish about it. They pushed for kernel 2.4 when people were saying nothing's wrong with 2.2. Even now in their Fedora product, they're pushing 2.6 early in the game.
If anything, they're bringing the 2.4 crowd slowly into the 2.6 world by backporting features.
Who is this CTO of SuSE? Sounds old-school to me.
That said, I also noticed that there were no quotes in the article from Juergen Geck. I've become wary of news articles that try to capitalize on sensationalizing news stories. Perhaps this is just the author's interpration, eh?
Yes, redhat backported tons of code from development 2.5 series, and later from 2.6, into their 2.4 kernels. And as far as I am concerned, it was a good thing. For example, for a long time RedHat kernel supported USB2 hard disks reliably, while stock and -ac kernels would hang after transferring few hundred megabytes. USB1 worked fine, USB2 would hang the machine. Yes, I could move to 2.5 kernels, but I don't want to. I want a stable kernel on a production system. And I'm not moving to 2.6 yet for the same reason, too many changes. Just the last version changed the API and broke all drivers except the in-tree ones. But RedHat ports most of the stuff I want back into their kernel, so I don't have to choose between not having the features I want and getting more features than I bargained for.
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.
We've used forking RedHat here for quite a while, but things just keep getting more and more forked up. If this doesn't forking stop soon, we're going to switch to some other, less forked-up distro.
Interested in a Flash-based MAME front end? Visit mame.danzbb.com
sorry, but i thought that is what the gpl is about. if they release the source, BFD. i still sometimes go back to older versions of redhat and mandrake because they are better for older harware. in fact, long story short, at my old school, the mac lab had a hard time with its internet connections. so, i just put a router in between, and had the OS 9 clients use that. took pressure off the G4 server (not runnin OS X). but, to do so, i had to scrounge up a P120 32MB ram. kernel 2.2 runs great on old hardware, plus, i had set up lots of experieince setting up ipchains, but had to download old version of RH. so, i scrounge for an old iso to download (mirrors.usc.edu). so, who the fsck cares. it there's demand for 2.4 fine. it's calld the GPL.
My problem? I was perfectly gruntled, until some numbnuts came by and dissed me.
i had set up lots of experieince setting up ipchains
i'm home sick. it should be:
i had set up lots of routers and have experience setting up ipchains
My problem? I was perfectly gruntled, until some numbnuts came by and dissed me.
That RedHat's backports and modifications are also *feeding* the 2.6 vanilla source. Just take a look at the Changelogs sometime and see how many @redhat.com's there are. RedHat does not apply any propriety patches to their kernel, all patches are made available for possible inclusion in a future vanilla release and many of them make it. Not to mention the testing the they provide for these patches. I hold RedHat directly responsible (alongside Linus, IBM and others) for the current state of the Linux kernel, it rocks!
This is not new by any stretch. Redhat has been dicking with the kernel and almost every package they ship for nearly a decade (possibly longer.) That's why it has always been a matter of policy on my part to build my own kernel from the "blessed" tree the instant a redhat machine is installed. Never, EVER, use the hacked-to-hell Redhat kernel. Kernel developers will generally ignore your bug reports, and redhat will ignore them too without a support contract.
To be "stable", that is in principle new functions are not added to 2.4 but to 2.6 or 2.7 now that 2.6 has been released).
Some backporting in a very limited fashion is not a problem, but if it gets too extensive, then what is the point? To keep 2.4 stable while added lots of new stuff from 2.6 takes a great deal of care and effort. Effort better spent in making 2.6 just as stable as 2.4, so that everyone is profiting from it and we all can move on and up to 2.6.
This custom backporting IMO is work spent by Red Hat which, instead, does not at all benefit the community. For the same money they could work on 2.6 instead, then move their customers to 2.6 sooner and everyone would benefit.
Have you tried to get RH9 working with a 2.6 kernel? It's a pain in the ass.
the word is "kernel" you illiterate cumbubble
but y'know what? forking is manageable. unix systems interoperate. programs can be written mostly-portably. it could be better, but it could be a hell of a lot worse. forking isn't fatal.
i speak for myself and those who like what i say.
$ cat /etc/redhat-release
Red Hat Linux release 9 (Shrike)
$
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
... but this isn't new... RedHat's been doing backports for a long time. IIRC, they backported features from 2.4 into 2.2. Not that I necessarily like that idea. I haven't used RedHat for several years now. I prefer to use slackware and gentoo these days.
I thought Slashdot was reporting a new pr0n film. Kind of surprising hehe..
contains the kernel-blahblah.src.rpm. The vanilla sources are in there and end up in /usr/src/redhat/SOURCES after installing.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
so I guess it falls to me.
Whats the forking problem?
I think you underestimate just how much I just dont care.
You don't have to take my word for it. There are plenty of posts already that claim there is compatibility between distributed RPMs and the vanillia kernel found straight from places like kernel.org.
So where is the lock in? You can choose to abandon the prepackaged (and tested) build and build your own version of the 2.4 on your RHE system. You just have to patch it by hand when you come across a piece of software that needs a kernel feature. If this isn't what FOSS is supposed to give customers I don't know what FOSS is supposed to be doing for buisnesses!
It would be one thing if Red Hat was just dumping kernels out there but this is far from the truth. They back port and support it. This is entirely misleading: it isn't forking but kernel customizing.
One cannot fork unless the upstream kernel is will not contain the backported functionality... Redhat claims they verify that the backports are accepted upstream before they backport. However, managing this could be complicated.
So is Mono development done on RHEL? or did Ximian just swipe the GPL'ed Red Hat 2.4 kernel and use it in their custom build of SuSe Enterprise?
..i'm pretty sure that SuSE have backported ACPI features from 2.6 in their 2.4 series..
Pot's 'n' kettles, etc..
Due to the changes in RedHat, I was thinking of switching from RedHat to SUSE. But with idiotic BS like this, I think I'm gonna just go to Fedora.
OS X has none of these problems. It has better applications, way MORE applications, a solid, American backed corporation that employs professional AMERICAN programmers, and the hardware simply cannot be beat. By comparison, Linux offers shaky code, written by god-knows-who (russians, chinese, el-cheapo by-the-dozen indian "programmers" taking away our jobs), a piss poor selection of poorly written applications, and a very questionable legal basis (the linux kernel apparently has been copied almost entirely from the original Unix code base). Why do people waste their time with Linux, when OS X is here and available?
Gentoo has vanilla 2.4 and 2.6 kernels.
THEY ARE NOT KERNALS.
They are kernels.
That someone who can supposedly compile their own kernel doesn't even know how to spell kernel (and don't cry typo, because you did it twice), is just embarassing.
Sorry, my damn Microsoft spell check screwed me again. :)
err...
How quaint. I say we go sporking instead. That's where future is.
Well, yes and no.
Patrick Volkerding's notes on building the Linux kernel for Slackware says:See the URL for Patrick's procedures on how he builds the kernel.
maybe its just used on one machine to help with the debugger.
I'm sure alot of developers for RH, SuSe, Mandrake use windows for certain tasks. Jeez some people are so uptight, everything is a PR battle.
OMFG linus got caught at linux world using fedora on his laptop! fuck!
RH CEO said windows is better for grandma! blasphemy!
Miguel develops a piece of mono on RH! Holy Shit!
This whole article is a PR battle infact. RedHat developed A LOT of 2.6 features so thier hackers know what NPTL is inside and out. its not a fork as it compiled fine with everything except you had to export LD assume kernel 2.5 to get wine working correctly. I'm not sure about other distros but wine always breaks on red hat, i think they hate the idea of emulating windows instead of developing for linux.
this kind of clusterfuck sends windows users screaming
SuSE has continually moved towards a more closed clunky system since it's inception. Every distro relies on custom updates, software, and methods to utilise the best performance and ease of use. But it is no other company other than SuSE that doesn't release ISO's for distrobution (the most popular method of disemination). I really can't see the people at SuSE becomming angry with the folks over at RedHAT. RedHAT is has increasingly catered to the open source community by releasing and helping out the Fedora project. While SuSE has pushed more money into commercial development and usability in their commercial releases....not saying either one is better but neither one deserves scorn.
So much for a kinder friendlier Novell who wants to play nice with the community. I guess at least we are on notice how Suse plans to gain more marketshare.
Smart move. Hype your just recently GPL'd app against a company who has been Open Sourcing their entire OS for years and make THEM seem like the bad guy. Bravo.
If you wanna get rich, you know that payback is a bitch
It's not trivial, but it's not all that hard either. After all, the Red Hat file structure hasn't changed and each version of Red Hat or Fedora Core is closely related to the last.
;-)
/dev/psaux to /dev/input/mice, but this is now well-documented (i.e. search for "kernel 2.6 mouse" in google and you'll get the same answer).
I'm using kernel-2.6.3-1.116 (from Fedora Core) in RH9. Here's how to do it:
1. Download a 2.6.x kernel RPM from the Fedora repository. Try to install in in RH9 with rpm -U. You'll get a list of failed dependencies.
2. Download the needed/depended-upon RPMs from the same Fedora repository.
3. rpm -U *.rpm.
4. Reboot.
I think I had to download/upgrade maybe a total 12 packages or so to get a 2.6.x kernel package to install into Red Hat 9. Then, once I had confirmed that I had a working 2.6.x-ready system, I proceeded to immediately download vanilla 2.6.5 and roll my own.
The only speed bumps that I ran into were:
1. The X config, in which I had to change my mouse from
2. My own hack-ugly kludge to sr_mod.c to enable my USB DVD-RAM drive no longer works in 2.6.x. I haven't yet dug into sr_mod.c to fix it in 2.6. But most people won't have this problem (i.e. their own patches that will need to be rewritten).
STOP . AMERICA . NOW
The fact that RH back-ports or heavily modifies the packages it ships does not bother me as much as how half-ass they do it and the dependencies it makes. I was disappointed to discover that when the Blue-curve'd KDE for RH9, the broke the screensaver/lock screen functionality. Now, dealing with RH AS 3.0, I have discovered that neither the 2.4 or 2.6 versions of the Intermezzo file system work with RHEL AS 3.0. Reverting to a standard 2.4 breaks several distro programs that are compiled to use the new thread model such as RPM. Also, upgrading to a standard 2.6 kernel has undesirable effects and is also not supported which defeats the purpose of going with an "enterprise" distro. I hope they ship a 2.6 based RHEL by around Oct/Nov because I'm not prepaired to have to deal with over a year of RHEL 3's limbo of not being a true 2.4 or 2.6 kernel.
Fedora uses -mregparm=3 but doesn't set CONFIG_REGPARM in the /boot/config-xxxx file which means that binary only driver and modules that (like our OSS sound drivers or ATI's drivers or NVidia's drivers or VMWare or Win4Lin) drivers have no way of knowing they are running on a REGPARM kernel or a standard kernel. Check out Fedora's griplist on REGPARM and NVidia. BTW, NVidia works perfectly with REGPARM and the vanilla 2.6.5 kernel from kernel.org.
CONFIG_REGPARM is marked *EXPERIMENTAL* and if you get the vanilla 2.6.5 kernel from www.kernel.org it's disabled by default.
When will the kernel developers quit making arbitrary changes?. Andrew Morton.....are you reading this?.
If CONFIG_REGPARM is beneficial, just don't make it an option and force everybody to use it or if it's flakey, don't use it at all and move it to Linux 2.7 - for crying out loud Linux 2.6 is supposed to be a STABLE branch.
As for SuSE griping about Redhat, SuSE do you remember when you guys added CONFIG_4GB and other non-standard stuff in Linux 2.4?. This caused all kinds of problems for memory maps. You still compile your kernels with CONFIG_MODVERSIONS disabled. Get with the plan ok?
I am an avid SuSE users. SuSE rules!
SuSE however, has also back-ported a number of features from later kernels. like the i2c stuff from 2.5 in SuSE 9.0
He is right in that it makes it much more dificult to deviate from stock install
Hope they can take some of their own medicine
A friend will come and bail you out of jail, a true friend will be sitting next to you saying, "damn that was fun!"
...I mean who the fork do they think they are, anyway?
Of course there are quotes from Juergen Geck in the article dumbass. Who the fuck do you think the article is about anyway? He's quoted top to bottom in the piece..learn to read before you spew shit out of your damned mouth asshole. SCO-Lovers be damned
Some of us would also argue that you can't run MySQL instead of Oracle. Postgres is a better option in this case.
The way to corrupt a youth is to teach him to hold in higher value them who think alike than those who think differently
= 9J =
Admit it, you know nothing about the Linux kernel, you've never even cd'd to /usr/src/linux/kernel.
...damn, all this time I've been running 0.13.