Linus Torvalds: Backporting Is A Good Thing

darthcamaro writes "Looks like we don't need to speculate on what Linus' opinion is on backporting. Internetnews.com is running a story this morning that includes Linus' comments on the issue which was a /. topic yesterday. When asked by e-mail to comment for internetnews.com, Torvalds wrote: 'I think it makes sense from a company standpoint to basically "cherry-pick" stuff from the development version that they feel is important to their customers. And in that sense I think the back-porting is actually a very good thing.'"

Comments

Personally, I find it underrated

[(1337) God]

I'm glad someone prominent like L Torvalds is voicing pro-support of this.

It's vividely overlooked by pros!

So does this become the party line?

[Anonymous Coward]

A lot of people stated they didn't like the idea of back porting. How many of you have changed now that Linus has stated his favor?

Re:So does this become the party line?

[Anonymous Coward]

it was already the party line (go back and look at the messages in the last thread this was discussed). Nothing needs to change.

Re:So does this become the party line?

[marick]

Which discussion were you reading? Seriously, I read the previous discussion, and it seemed to me that most people appreciated backporting.

Re:So does this become the party line?

[YOU LIKEWISE FAIL IT]

Hell no. Somewhat tangentially, I was having this discussion the other day with someone:

A machine I work on had been upgraded to 2.4.21-pre5, and I was a bit pissy because anything < -pre6 has the ptrace priv escalation flaw.

It turned out that he was using some kind of kerazy Debian kernel with the fix backported. Without eventually finding him and asking him this, I had no way to know this, because: I wasn't allowed to test it and see if it worked ( I don't know PPC shellcode anyway ), The upgrader had not left his source tree or a changelog handy, the kernel didn't have any indicitative flags in its name, he hadn't installed it from a package.

Now, of course, you should be able to do anything you like, which includes cherry picking features into old releases, but in my opinion, this can create a lot of confusion. It'd be really embarassing if the software you wrote only worked on your customised kernel if you didn't know it had been customised.

Version numbers allow us to identify the patch level and feature set of a piece of software and we use them to specify minimum requirements for packages. I think at the very least, if you're going to backport stuff, change the version number somehow ( private fork ) - your patched software and the original can no longer be treated as the same entity.

Ok, er, rant off. My point is that people not in favour of backports usually have some kind of reason for it, even if it's a crappy one like mine, and you'd need to convince me that my reasoning is bad before I'd drop the point.

Re:So does this become the party line?

[Surazal]

Something like this happened to me once. It was a comical chain of events, and admittedly the most embarrassing moment of my early career in things Unix-related.

I was charged with upgrading a kernel, remotely, over the weekend, at a customer site. I did so, and I even remembered to ask first if there was anything special I should consider before going through with the task. No, just use the old configuration file, upgrade and let her rip.

Ok, while I was kinda nervous about doing this, I felt balls-ey enough to do it anyways. I took the proper precautions. I reconfigured lilo to boot off the copied off old kernel by typing in "emergency" at the lilo prompt. Worse case scenario, I could call in, ask the local operator to walk over to the machine, hit Ctrl-Alt-Del, type "emergency" at the promt, and all would be well. Remember the words "worst case scenario".

It happened. All went well during compilation, and I went ahead and hit "shutdown -r now" at the root prompt over my ssh connection. The connection was subsequently reset by peer. Ok, I expected that. I'll go grab a beer and wait for the ping to start responding again.

I waited, waited... um, okay it's still not responding over the internet. Okay, where's that number... um, where did I put that number?

You can see where this goes from here.

Two hours later, I had no way of reaching the operator. The number I had in hand disappeared somewhere, and I had no idea where it went. To this day, I have no idea where I put that little slip of paper. Did it get folded into the infinite nooks that existed in my old, torn up wallet? Did it go to the same place where half of a good number of pairs of socks have disappeared to over the years? Where, where, where, where, where?

Fortunately, all ended well. They had our number at least, and I apologized, gave them the emergency procedure, and everything was working again. Hooray for the forces of good!

To this day, my heart still skips a beat whenever I reboot a server remotely.

------

P.S. as it turned out I wasn't told that the kernel module for the network card being used wasn't officially supported by the official Linux kernel at the time, and that needed to be downloaded separately and recompiled along with the new kernel. It did boot successfully. It just did so without network support. D'oh!

Re:So does this become the party line?

[psychosis]

You're 100% justified in your frustration with the case you detailed, but the fault lies with your kernel developer/upgrader's kernel compile process.
The whole mess would have been avoided if he had set the EXTRAVERSION variable in the kernel's Makefile to something meaningful (i.e. make the kernel version 2.4.21-pre5_custom_04apr04) and posted his specific notes on that kernel someplace where all can find them (I can personally recommend an internal Wiki for this - it works wonders).
Also, if you release software after testing it on only one kernel, methinks there are some testing procedures to be beefed up!

Don't knock backports for their own sake - knock those who misuse them. (Upside the back of the head, preferably.)

Re:So does this become the party line?

[Snoopy77]

It seems like the main problem with backporting is the lack of documentation of the backport rather than the backport itself.

Re:So does this become the party line?

[Anonymous Coward]

I hate backports. It's like getting an enima.

Re:So does this become the party line?

[JWSmythe]

Been there, done that. :)

Well, with our own machines. We have a standing rule, the person that hoses a kernel upgrade is the one that gets to drive down to the colo and fix it. Needless to say, we practice on the machine that are in the nearest colo first, before we do the distant remote ones. No one wants to foot the bill of flying from Florida to New York to fix a mistake they made. :)

(fingers crossed) we've never hosed a machine too terribly far away. A few times we've forgotten to put in the network driver for particular cards, especially on odd-ball machines.

On a late-night "we have to have this server up *NOW*" install, I built out the server, threw the kernel together (on the console), and drove the machine to the colo. I plugged it in, and turned it on, with the assumption everything was right (usually at about 2am) to get home and find it isn't on the network. An hour and another kernel compile later, it's working. :)

Pretty much, our distant remote machines are very redundant, so if we hose one, it's not a big deal. If we hose 5, well someone is in for a plane ride.

It's usually worth taking the plane ride anyways, there's usually something non-urgent that's waiting to be done that can be done while we're there.

We did have an urgent one-task plane ride once. One of the facilites we're in had a brown-out. When the power came back, our connectivity didn't. The switch was unhappy. The colo's site tech tried resetting it, but that did nothing for us, so someone (me) took a plane ride carrying a switch and laptop. 20 minutes in the colo, 2 hours in taxi's, and 8 hours on planes before I go t home. That was a long night. Exhausted, I did get to have breakfast in the McDonalds in Times Square though (stopped by to see someone before they went to work).

Re:So does this become the party line?

[mtvsucks]

i'm fairly sure that lilo has somesorta lilo -R command or somthing that will try rebooting once wiht a new config. and if it fails wiht the new config it falls back to the old. if you had anotehr computer hooked up to the machine you are upgrading's ups you could just kill the power the the machine you were upgrading with a new kernel and then you could start over.

Re:So does this become the party line?

[RajivSLK]

Wow. You just describe our situation to a T.

In an ideal world a remote kernel install would go something like this:

1) Complie & install new kernel image.
2) Reboot Fails
3) Remotely power cycle.
4) Lilo/Grub detects failed boot attempt and loads known good kernel
5) Re-compile & install kernel properly this time
6) Reboot

A procedure like that would probably save countless plane flights/car trips.

Re:So does this become the party line?

[caluml]

How many of you have changed now that Linus has stated his favor?

Leenus, he's just zis guy, you know...

Re:So does this become the party line?

[Anonymous Coward]

if it fails wiht the new config it falls back to the old

And how is it going to do that when it gets to a kernel panic stage, for example it can't mount the root partition? You're hosed.

Re:So does this become the party line?

[moon-monster]

Yep. Lilo -R configname makes it reboot into 'configname' on the next reboot only. - I do this every time I upgrade the kernel on a remote machine.

I *also* set up a cron job to reboot the machine every 20 minutes or so, so if something happens like it comes up without networking, it'll reboot back into the old kernel in 20 min. If it comes up, I can kill the cron job and remove the entry for the old kernel.

Saved my life more than once. Particularly on those pesky cheap co-lo boxes where you have to pay someone to reboot it for you.

Re:So does this become the party line?

[Anonymous Coward]

Yeah. A procedure like that was added to Windows NT about ten years ago. CRAZY!

Re:So does this become the party line?

[Anonymous Coward]

"Well, with our own machines. We have a standing rule, the person that hoses a kernel upgrade is the one that gets to drive down to the colo and fix it."

And lo, there is the reason why I don't, nay refuse, to drive.

Re:So does this become the party line?

[minus9]

You recompile your Windows NT kernel?

Re:So does this become the party line?

[Sri Lumpa]

I view things the opposite way than you WRT security fixes.

Each time there is a security fix they issue a new kernel version 2.4.x -> 2.4.(x+1) but I think that there should be an additional number to represent security fixes so that you can have a new version without the security flaw but with the same functionality (hence, less chances to have things break).

Ideally we should have the feature set and the implementation numbers be different.

The feature set would evolve with a new minor number for each feature set change and a new major number for each incompatible change (remove functionality). The middle version number would still denote unstable feature sets vs stable feature sets (unstable ones changing much more) but would not denote the stability of the code.

The implementation number would target a feature set version and reflect the degree of completed implementation and code stability of the implementation vis-a-vis that feature set.

For example when they release Linux 2.6.6 instead of just having that number you would have: .The feature set number: Linux 2.6.6 .The actual implementation for that feature set: Linux RI for 2.6.6 - v1.0.0 (RI being Reference Implementation).

And if there is a security flaw you release Linux RI for 2.6.6 - v1.0.1 Instead of Linux 2.6.7.

If the only way to correct the flaw is by changing some interface then you have to issue Linux 2.6.7 with Linux RI for 2.6.7 - v1.0.0 and deprecate Linux 2.6.6.

That way you can update your system while changing the minimum and not adding new code unnecessarily (after all isn't that one of the problems with Windows Service Packs?).

I'm sure this scheme can be tweaked or has already been proposed (libtool version numbers???) but what good is it if it is not used?

Re:So does this become the party line?

[sjames]

4) Lilo/Grub detects failed boot attempt and loads known good kernel

That's a good idea for a Lilo/Grub feature, possibly with some sort of watchdog. The watchdog would need to be quite a comprehensive one to deal with network problems, so perhaps just stick with remote powercycle.

The closest now is a combination of remote serial console and remote powercycle.

Re:So does this become the party line?

[ajs]

Development-stable vs. production-stable.

I keep pointing this out on Slashdot, and for some reason people keep missing it: What comes out of the Linux Kernel Developers is a development release. Just like any development release structure of sufficient size, they have several working branches and several stable branches, but that doesn't mean that what you get from a "stable branch" is a valid production release.

When a vendor releases a Linux system, I expect their kernel to be a valid production release. That is, they are going to support that release for some specified period of time, and it's not going to change in incompatible ways. Take a look at the history of 2.0, 2.2, 2.4 and you'll see large numbers of incompatible changes (scheduling, filesystems, etc.), but they're compatible changes FROM THE DEVELOPER'S STANDPOINT. They don't change API's, but they might make your production installation behave radically differently.

I expect, e.g., Red Hat to release a 2.2.x kernel and continue to support it by back-porting security updates and critical bug-fixes, but otherwise LEAVE IT ALONE. They've not always done this, and part of that is that Linux is still in the late stages of an early adopter market (i.e. the market size is still growing in a logarithmic pattern). I can understand that, but in the future, I expect Red Hat Enterprise Linux 20.0 and Red Hat Enterprise Linux 20.45 to differ very slightly, and possibly be separated by 5 or 10 YEARS. That leaves no room for kernel-of-the-year upgrades.

So, back to the point: backports are fine, as long as it's the developers doing the backporting. If vendors start picking up those backports just because they can, I have a problem with that. I also have a problem with a vendor that releases a kernel version that has been out less than a year....

Re:So does this become the party line?

[ckaminski]

APC and others are now selling TCP/IP based KVM's that can help mitigate some problems. APC even has power switches that you can remotely reboot. I'm sure there are security concerns, but they're designing half the hardware for these colo's, and remote management is an important thing for some clients. Not every colo has 24x7 access that's easy to use of doesn't depend on that guy in your IT department who just went on a 3 week African safari.

Re:So does this become the party line?

[JWSmythe]

That does sound like a good idea. I wonder how they'd implement it? What's the difference between rebooting because someone upgraded the kernel and failed, and someone smacking the machine with their APC MasterSwitch because someone did something stupid.

Something I would like is if there was an "only next boot" option in Lili. Maybe there is, but I've never seen it. Do something like this:

shutdown -r now --try-image=NewKernel

If it works, you change lilo.conf to use this new kernel, if it doesn't, next time it boots, it comes back with the last kernel.

I'd think it would be a pain to implement the other way. I wouldn't think there's a good way for lilo/grub to know if everything came up successfully. I've seen network drivers that allow assigning IP's, but they don't actually work for connectivity. I can't remember which one it was off-hand, but I've seen it happen. Or more likely, in a multiple NIC environment, the wrong card comes up as eth0, which doesn't have a network cable on it.

Re:So does this become the party line?

[JWSmythe]

Shut up and get back to work. I don't care if there's a time difference between our offices, you're suppose to be working, not reading /. :)

Re:So does this become the party line?

[parnasus]

One thing I would add to this scenario to incorporate flacky network cards or configuration is some type of lock file, like /etc/nologin, and a cron job entry which looks for this file. You would run the shutdown command line above, machine comes up (maybe) with the file set (/etc/try-image exists), and cron job wakes up an hour later to see if it's still there. If the file still exists, it forces a normal reboot to clear the one time boot. If it isn't there, the administrator must have logged on to remove the file.

Re:So does this become the party line?

[iabervon]

Really, any patch that gets put into a kernel which gets distributed in binary form should modify the version string to indicate that it's there. I personally think the security fixes should never change the main version number, but should be distributed in the form of a patch (or a set of patches) that applies to every kernel version that had the issue and that adds something to the version string to indicate that it fixed it. Security fixes should be released already backported to previous versions, which both avoids the issue of what you do with current testing changes and also deals with issues of people who can't use the latest version.

Re:So does this become the party line?

[Anonymous Coward]

A lot of people stated they didn't like the idea of back porting. How many of you have changed now that Linus has stated his favor?

Maybe people weren't planning on making up their mind until they found out if they could have Linus back port them. They probably didn't want to do anything so intimate with any old Linux user.

Re:So does this become the party line?

[Anonymous Coward]

So all backports are a bad thing because this one sysadmin didn't keep a ChangeLog (or other documentation)? Maybe the problem isn't the backport itself but rather the lack of documentation.

With deb there is usually a README included with the patched kernel source that states exactly what patches have been applied.

Re:So does this become the party line?

[Reducer2001]

We use HP Remote Insight Boards on our servers. It lets you control the server (keyboard, mouse, CD-ROM, floppy, power) completely independant of the OS. I can't tell you how much time it has saved me being able to reboot our machines from the comfort of my living room.

Re:So does this become the party line?

[welsh git]

> there is a security flaw you release Linux RI for 2.6.6 - v1.0.1 Instead of Linux 2.6.7.
> If the only way to correct the flaw is by changing some interface then you have to
> issue Linux 2.6.7 with Linux RI for 2.6.7 - v1.0.0 and deprecate Linux 2.6.6.
>
> That way you can update your system while changing the minimum and not adding
> new code unnecessarily (after all isn't that one of the problems with Windows
> Service Packs?).

FreeBSD has that already - security fixes are applied to the RELENG branch of a RELEASED version.

You can track a released version (e.g. 4.4-RELEASE) and then track RELENG_4.4 for security patches.

As described here

Re:So does this become the party line?

[Bombcar]

lilo -r

is what you want.

Re:So does this become the party line?

[shadowbearer]

Is there some way to have a machine reboot on kernel error into a known good config automagically even if it's been up for a long time?

SB

As long as it doesnt b0rk my boxen..

[SCSi]

Then more power to them. My fear is always that development/new stuff backported to a "stable" kernel is going to cause system unstability and weird stuff.

Having a list of what exactly is backported would be optimal, that way when device X b0rks after 3 months of uptime, you know its possibly related to the newest version of that rock "stable" kernel you put into production.

Re:As long as it doesnt b0rk my boxen..

[Lehk228]

well if you switch kernels and a device fails you should at least suspect the new kernel

Re:As long as it doesnt b0rk my boxen..

[GlassHeart]

My fear is always that development/new stuff backported to a "stable" kernel is going to cause system unstability and weird stuff.

The problem is that Linux serves three major customers: developers, desktops, and servers. The developers are well-served by the odd-numbered development branch. The servers need a rock solid branch, but tend to have very little need to support new hardware, so they should be happy with the even-numbered branch. The desktops still need stability, but also have to work with new hardware. Since the kernel developers don't have a formal process for this demographic, it's up to the distro maintainers to backport changes from the cutting edge.

This is not a good thing, though. If each desktop Linux distro picks a slightly different subset of features to backport, desktop Linux can become even more fractured than the Gnome/KDE division. If they can manage to work together, it might be better to establish a new common branch between the two traditional ones.

Re:As long as it doesnt b0rk my boxen..

[Anonymous Coward]

That's incompelete because the original story was about RHEL, which is for heavly-loaded servers (and has the new threading and other 2.6 features backported). I don't think anyone really cares about backporting drivers (eg SATA).

A bigger problem is that the even numbers from Linus really aren't "stable", in the commercial sense. The early versions aren't bug-free enough and the later versions change too much. Furthermore, Linus' timing isn't the same as RedHat's. Linus doesn't care about 5-year support contracts, so they can't use his tree.

Re:As long as it doesnt b0rk my boxen..

[Jungle guy]

Kernel patches generally won't cause software incompatibility. These "fractures" are generally caused by system libraries, most notably the glibc. New versions of the GCC can also be a major source of headaches.

Re:As long as it doesnt b0rk my boxen..

[stor]

I don't think anyone really cares about backporting drivers (eg SATA).

Oh really?

http://www.ussg.iu.edu/hypermail/linux/kernel/04 04 .2/0019.html :)

This is for the *official* branch, not a fork but it has obviously been requested (and is happening).

Cheers
Stor

It really is a good thing

[Rosco P. Coltrane]

When 2.4 wasn't stable, I was glad to take advantage of USB with my 2.2 kernels using the 2.2.16 USB backport (no longer available from linux-usb.org apparently).

Re:It really is a good thing

[zootread]

I agree, it really is a good thing. And a lot of distros patch their kernels so this really is no big deal.

HAPPY 420!!!!

Re:It really is a good thing

[EmbeddedJanitor]

One really GoodThing about backporting (or any porting for that matter) is that it beats up on the code in a different way. This is likely to help flush out bugs.

The Linux kernel is forked anyway

[gevmage]

My understanding of people's main complaint about the backporting that companies were doing was that it forks kernel development.

But that's nothing new. The kernel has forks in it anyway. The PowerPC kernel, for instance, exists as its own set of patches to the main kernel tree. Linux can't be everything to everyone so this is an inevitable development.

I think that's the point of open-sourcing your code. If someone else can write a better (more appropriate) one, more power to them!

Re:The Linux kernel is forked anyway

[kbmccarty]

The PowerPC kernel, for instance, exists as its own set of patches to the main kernel tree.

<pedantic>

Actually Linus switched to using an Apple laptop sometime fairly recently, so as of about 2.6.3, the PowerPC kernel is identical to the vanilla kernel tree.

</pedantic>

Re:The Linux kernel is forked anyway

[Anonymous Coward]

Please, please tell me that the last time you updated your web page was 1997.

Otherwise...

Backporting has proven...

[chipster]

...to be very valuable at my company - especially for the servers we have that are connected to SAN with Emulex HBA's. Without backporting, we'd spend lots of time hacking the kernels ourselves - which is fun and all - but not when project owners want their environments built yesterday.

However, for my own personal systems, I don't favor backporting over a kernel upgrade.

Quit idolizing Linus Torvalds

[Anonymous Coward]

Come on guys, stop looking for what Linus has to say to make up your mind, it's ridiculous. Although I think he is right most of the time, many Linux users and developers seem to take his word for some Sacred Truth and that's annoying ! Striving for an alternative OS while letting yourselves be sheparded by some high-tech guru is quite paradoxal...

Re:Quit idolizing Linus Torvalds

[Eberlin]

But Linus is so cool, how can we NOT?

Seriously, though, I do believe that not everything Linus says should be doctrine and I'm sure he's been proven wrong a few times. However, this whole Linux thing is still his. I know, I know, it belongs to the world and the GPL and the one-true-communist society...but at the heart of it, Linux belongs to Linus. If nothing else, give the man his due respect.

Oh, and there's no use posting anonymously, Mr. Stallman -- yer just pissy 'cause nobody wants to hear you sing your hacker song anymore. :)

Re:Quit idolizing Linus Torvalds

[Anonymous Coward]

Linus is the LInux G-d - especially the kernel - he decides what goes. His word is the gospel truth. Praise be to Linus for he is GOOD.

Re:Quit idolizing Linus Torvalds

[xoran99]

People seek leadership. It's simply a part of human nature. I can understand where people might develop a "What Linus says goes" mentality when he's already done so much.

Re:Quit idolizing Linus Torvalds

[Laser Lou]

Come on guys, stop looking for what Linus has to say to make up your mind, it's ridiculous. Although I think he is right most of the time, many Linux users and developers seem to take his word for some Sacred Truth and that's annoying ! Striving for an alternative OS while letting yourselves be sheparded by some high-tech guru is quite paradoxal...

I bet you're not Catholic.

Re:Quit idolizing Linus Torvalds

[Saeger]

People seek leadership. It's simply a part of human nature.

Eh. And then there's the mutants like me who reject all authority and don't get the celebrity thing.

--

Re:Quit idolizing Linus Torvalds

[Anonymous Coward]

You're not a mutant, you're just in the group that rebels against everything popular. There are millions out there that are just like you.

I don't know which group is more annoying.

Re:Quit idolizing Linus Torvalds

[Laser Lou]

That comment is quite offensive.

Much of my family are Catholics, and they could out reason, out free think, and out qualify you any day of the week.

What's your real agenda in saying such a thing pipsqueak?

You took my comment the wrong way. Gosh, I defend Catholicism sometimes before others, even though I'm a Lutheran. The previous poster seemed to reject any concept of leadership or authority, so I expressed a foregone conclusion that he doesn't believe in papal infalliability.

Re:Quit idolizing Linus Torvalds

[kasperd]

I'm sure he's been proven wrong a few times.

Once (according to the FAQ).

Re:Quit idolizing Linus Torvalds

[Magickcat]

It wasn't quite as simple as mere leadership or authority, the original poster rejected blindly following authority. So by inference, the opposite of blindly following authority, must therefore not be a Catholic.

Nonethless, I'm sorry if I interpreted you incorrectly. Just to note, a great deal of Irish Catholic clergy and lay people that I know take the Pope and the relatively recent Doctrine of Papal Infallability with a huge pinch of salt.

Re:Quit idolizing Linus Torvalds

[Anonymous Coward]

How topical. Linus says cherry-pick dev changes, you say cherry-pick religious doctrines.

Re:Quit idolizing Linus Torvalds

[the_thunderbird]

But still Linus says so! So it must be right!!! Even if he was proved wrong, he must still be right! Like Microsoft, they always say they are right, but they are always wrong. So what you are saying is Linus is probably wrong... But that would mean he is right? My head hurts now.....

Re:Quit idolizing Linus Torvalds

[fitten]

Giving someone respect for what he/she has done is certainly a good thing. Extrapolating that respect into idolatry isn't. Don't let someone else form your opinions for you.

Re:Quit idolizing Linus Torvalds

[Anonymous Coward]

Why don't you give Stallman is due credit then?

Re:Quit idolizing Linus Torvalds

[sp00j]

Surely you jest!

Every time Linus farts, 1001 Linux fan-boys are there to analyze the substance of said statement...

Re:Quit idolizing Linus Torvalds

[blahfern]

However, this whole Linux thing is still his.
I believe it is technically GNU/Linux

SCO fixes

[the MaD HuNGaRIaN]

Then perhaps someone should back-port the fixes that remove the SCO code.

(ducks to avoid flying objects)

Re:SCO fixes

[boarder8925]

Then perhaps someone should back-port the fixes that remove the SCO code.

"And in other news, SCO has just announced a $699 license fee to mock them."

Re:SCO fixes

[Rosco P. Coltrane]

Here's the fix:

cd /usr/src/linux/
echo "" > ./sco_ip.patch
patch -p1 < ./sco_ip.patch

Do this and you'll have a kernel free of any SCO code.

Re:SCO fixes

[Anonymous Coward]

OK... this needs to be modded up.. honestly the funniest SCO joke I have heard in a while. I'm still laughing as I'm writing this and the other people in the lab must think I'm insane.

Re:SCO fixes

[ReelOddeeo]

You're presuming that there is some SCO code to actually remove from the kernel. It remains to be seen if it is so.

Re:SCO fixes

[the MaD HuNGaRIaN]

Dude....are you serious? 'Cuz I wasn't.

Thank God others got the joke too--hence +4 Funny (was +5 until some assclown marked it as redundant, even though it was 100% original humor.)

Backporting a Good Thing (TM)

[Eberlin]

The argument against backporting is that a lot of wasted time/effort goes to something that could've been taken care of by upgrading to the latest/greatest kernel.

The practicality here is that not everyone needs to upgrade to the latest kernel. Some production systems are stable enough as is and don't need the upgrade. Some may even become unstable as they get upgraded. Thus if some features are needed from the newer versions, backporting allows people to utilize just the features they need.

All part of that Open Source GPL Free as in Freedom thing. Even for those who consider it a waste of time and effort, those are things that the GPL entitles anyone to put effort into. Those who are adamantly against such wasted manpower should probably consider visiting SourceForge for a coronary.

Re:Backporting a Good Thing (TM)

[Anonymous Coward]

Technicalty you don't put TM in brackets, and legaly (C) or (c) carries no weight of notice. You must use the actual word copyright or © and you can use ® only when the trademark is actually registered or it has no weight either and won't be considered a notice of trademark. So Bobtech® is not a valid trademark notfication if Bobtech isn't actually a registered trademark but Bobtech TM is.

Have fun

Re:Backporting a Good Thing (TM)

[Anonymous Coward]

Duly noted. Thanks.

FWIW, I believe you've just given IBM the only loophole they need to get out of that SCO debacle. :)

Suse

[augustz]

Very few vendors ship a TOTALLY plain kernel. I'm not sure why Suse makes such a big deal of theirs (if they even do ship a clean one, hard to beleive).

The power of the GPL is that you can never truly fork the way Unix was forked. If Suse wanted to be compatible with redhats kernel, they can easily cherry pick the changes necessary, and redistribute them themselves.

All very intresting coming from a company that had a propriatary installer. As far as I know RedHat has shipped everything open source for a very long time now.

Re:Suse

[Anonymous Coward]

sorry thats wrong.

the BSD's started from common ground, but they are now incompatible (in the sense that code cant just be easily applied)

Re:Suse

[Anonymous Coward]

BSD is still around? I remember using that on the VAX in college. I thought Bill Joy killed it or something. Oh well, I feel old.

Re:Suse

[justins]

Very few vendors ship a TOTALLY plain kernel. I'm not sure why Suse makes such a big deal of theirs (if they even do ship a clean one, hard to beleive).

They don't, not at all. Somehow I suspect that Novell CTO either:
1. Said something that makes more sense in context
2. Was speaking too generally and regrets what he said

Actually he probably regrets it either way. :)

Re:Suse

[ImpTech]

Umm... the BSD's use, :shock:, the BSD license! That proves nothing with regard to GPL'd Linux. Even so, there's nothing stopping the BSDs from becoming compatible if they want to, all the code is there. They just philosophically decided to go off in different directions. When acutual UNIX was forked back in the day, it was with proprietary implementations, which means no going back. RedHat can't try to force SuSe out of the market with kernel patches, because theres nothing stopping Suse from applying those same patches if they want.

Re:Suse

[Anonymous Coward]

YaST is now GPL.

Re:Suse

[MobyTurbo]

sorry thats wrong. the BSD's started from common ground, but they are now incompatible (in the sense that code cant just be easily applied)

When he said "Unix(tm) was forked" he probably didn't mean BSD, which is not Unix(tm) anymore, he probably meant the Unix wars of the 80s, where a myrid of firms made SysV commercial Unixes that were all incompatable with each other. This fragmentation persists in the trible memory and makes Unix hackers wary of any forks.

(The BSDs do just fine even with forks, I'm running DragonFly, which is a fork of FreeBSD. (Though it's nearly completely compatable with FreeBSD.)

Microsoft does it too sometimes

[Rosco P. Coltrane]

Microsoft too sometimes care to backport things. For example, IPP support in XP has been backported to Windows 95 and Windows 98 after many requests from companies like Brother and from users.

Unlike what Linus advocates though, Microsoft doesn't do that routinely and users have to bitch and moan pretty bad to get what they need.

No.

[DAldredge]

We tried, but seeing how Linus likes to keep a low profile and NEVER gives out his email address to anyone, we where unable to.

Perhaps one day people will be able to understand his thoughts and passions but, sadly, today isn't that day.

Re:No.

[siliconoddity]

I also have the poor man's home phone number. Thinking of a 3way call with him and Darl.

Re:No.

[DAldredge]

Damn, I bet just about 500 people will make you their /. friend tonight just because of that. :->

Re:No.

[siliconoddity]

Haha, and I'm here primarily as a troll too. Check out my site.

The beauty of Open Source.

[ron_ivi]

We don't need a consensus. If RedHat has the means to support backports and the customers who want them, more power to them. If Debian Stable picks only the security patches and has an audience who likes that, awesome.

People seem to think of forking as bad. I think of it as "market research" -- whichever distro has the "best" philosophy will get the most users and/or customers (not necessarily the same thing - hense "best" was in quotes).

Re:The beauty of Open Source.

[GlassHeart]

People seem to think of forking as bad.

First of all, speaking as a professional software developer, forking is bad. Forking inevitably involves extra work integrating changes from branch to branch, and can be justified only by some technical or business need. Forking also multiplies testing requirements.

I think we're talking about unnecessary forking as bad. For example, if vendor R backports features A, B, C, and D, while vendor S backports features A, C, D, and E, and vendor D backports features A, B, and E, writing software that'll work on "Linux" can already become complicated. In my example, you can only count on feature A being present, despite the collective effort of distros to backport 5 features 11 times!

The Linux software market, particularly on the desktop, is small enough as it is. If the market demand for backporting comes mainly from the desktop, then it might be better to establish a common "desktop branch" somewhere between the development and stable branches.

Re:The beauty of Open Source.

[dmaxwell]

The kernel doesn't make much difference as far as binary compatibility goes. Very few binaries directly interact with the kernel. Going from a 2.4 to 2.6 kernel didn't cause a single piece of software I use to quit functioning. Neither did going from 2.2 to 2.4. I once dropped a RedHat kernel onto a Mandrake machine. Everything worked.

Now the userland libraries on the other hand....

Re:The beauty of Open Source.

[Anonymous Coward]

You get the same problem if people upgrade their kernels, and nobody advocates stopping people from doing that.

Re:The beauty of Open Source.

[sw155kn1f3]

Whoa. You fail to differentiate between forking and branching.
Branching is done all the time, look how mozilla is being developed.
And yes, modding kernel IS branching, in every sense, since you submit patches, which are being incorporated into the main tree by kernel maintainers.
Ever managed to work with modern versioning systems? Even half-assed CVS supports it nice, and bitkeeper is very good at it since supports distributed repositories.

Re:The beauty of Open Source.

[theLOUDroom]

First of all, speaking as a professional software developer, forking is bad.

See this is the problem, you're thinking about it as a professional software developer. You imagine a development team and a product, it's not like that.

Forking inevitably involves extra work integrating changes from branch to branch, and can be justified only by some technical or business need.

And what if I want to do something to satisfy my own intellectual curiousity? Is someone supposed to stop me from doing it "for the good of Linux"?

Certain ways of thinking just don't apply to the want Linux is done. A lot of the work is done by hobbiests who CHOOSE to work on what they are interested in.

If I decide to backport USB support to some ancient kernel, it doesn't mean that I'm taking away man-hours that would have otherwise gone towards the development of the 2.6 kernel.

Linux has become a software marketplace of ideas. If people like Redhat's idea, they'll use it. If they don't they won't. If their approach starts causing significant software compatibility problems, then I expect they'll notice and act accordingly to fix the problem, or people will switch distros.

In the end, the best choice will most likely win and choice will not have been arbitrarily limited.

Re:The beauty of Open Source.

[Anonymous Coward]

"If I decide to backport ... to some ancient kernel, it doesn't mean that I'm taking away man-hours that would have otherwise gone towards the development of the 2.6 kernel."

Good point! Backporting a patch is a number of things...

Training of a new Kernel Hacker on good design practices - since he's working with a patch that's already been accepted.

Longer life (stability) for the old kernel, leading to a longer support cycle for Linux

Heck, I think _every_ new kernel hacker (windows and linux alike)'s first project should be a backport, so people don't use their n00bie learning mistakes on the real kernel, but rather learn from a working patch done by someone experienced.

Re:The beauty of Open Source.

[Anonymous Coward]

Well, to name an important piece of software that went haywire for me, gdb could not debug anything usefull, because of the new posix threads thing.

Re:The beauty of Open Source.

[Anonymous Coward]

But usually, in any distribution, kernel version x.y.z has at least all features of vanilla x.y.z (plus some additional features). So you can always count on having them. If distributions used only vanilla, how would the situation be different?

But you do not usually count on kernel features like you described. If you need a feature, you test if it is present, not just check kernel version. As Linux is a mature kernel, all common features are always there, so you will need to check only if you do something very kernel related (like firewalling, QoS, utilities to support special hardware, filesystem utilities...). You would have to check anyway, because many people are likely to run even vanilla kernels that do not support the feature you need.

Re:The beauty of Open Source.

[drinkypoo]

First of all, speaking as a professional software developer, forking is bad. Forking inevitably involves extra work integrating changes from branch to branch, and can be justified only by some technical or business need.

Instead, speak as a free and open source developer. Forking is good, because it leads to development which otherwise would never have occurred. The "extra work" reconciling the two branches later is a real issue, but since there would be nothing to reconcile without a fork, it seems clearly justifiable to me.

After all, Linus isn't going to just take any and all patches from people and stuff them in the kernel. Neither are other kernel maintainers. Just making your own patches is a form of forking, until such a time as you get your patches accepted into the main tree, they are merged, and then you start working with the resulting code - at which time you are forking again.

Re:The beauty of Open Source.

[sjames]

Further, the patches are all available to anyone who wants to apply them. I frequently fold in a sort of regular patchset consisting of some of the vendor patches and my own. When I use the extra features, I know very well that I am introducing a dependancy that a vanilla kernel won't meet.

Hopefully, developers consider those dependancies carefully and either provide for backwards compatibility (perhaps with reduced functionality) using ifdefs or know that what they are doing is some sort of niche and have good enough reasons that people in that niche will install the patches.

In practice, even without kernel mods, some projects that are (or should be) coinsidered of wide interest have many arcane dependancies on the very latest and greatest (buggy and changing daily) development libraries. Those projects either don't get widely adopted till the development branches of the libraries go stable, get fixed to use more stable APIs (possibly by being forked), ore die out and get replaced by something with more sane dependancies.

In the case of 2.6 features backported to 2.4, it's fairly likely that the final fix will be widespread adoption of the 2.6 kernel. The backports open the possability that people who require non-mainstream 2.4 kernel mods will be able to use new features from 2.6 while forward porting the other mods to 2.6.

Another good use is to provide for a clean forward migration. This is particularly true if/when the new kernel breaks system tools by supporting only a newer API. Backport the new API, then migrate the tools to it while keeping the system up and running well and maintaining the important fallback position of simply delaying the upgrade to 2.6 till an unexpected kink with the new API can be worked out.

It may introduce a bit of chaos, but overall, it reduces the pain of deprecating APIs without resorting to the far worse practice of never depricating an API that needs to go away.

Re:why the fuck should we care

[Anonymous Coward]

His skills are on the hello world level anyway

Actually no, his skills are much below the "hello world level". Pretty much right under the libc6 layer in fact.

You, on the other hand, seem like you couldn't even pass a urine test...

So says God!

[Code Dark]

Well, we all know that Linus is God, and whatever he says goes... right? Well, perhaps not. Although I definitely appreciate his programming skills, and the wonderful donation to society that we know as Linux, I don't think that I agree with him on this issue. Blasphemy?

Re:So says God!

[zoloto]

Well, his comments are GPL'd, so you can take his comments, use them to your pleasure, change them, and/or edit them completely so they are now your own code^H^H^H^H words.

So I believe he'd give a nod of approval.

Re:So says God!

[Zoko Siman]

If you are going to say something, at least tell us why. It's one thing to get on your soap box, it's another to defend yourself and explain on your soap box.

Re:So says God!

[Anonymous Coward]

Uh, yeah. Think whatever you want. (Whoever modded this insightful, realize that he essentially said only that he does not agree with a certain pretty-trivial opinion.)

I'm curious as to why you don't agree with him or, rather, what you have against backporting?

Re:So says God!

[NonSequor]

No one seriously thinks that Linus is always right. He's just good at getting people to cooperate with him even when he is wrong. And that is something of a virtue in itself.

Re:So says God!

[Code Dark]

The main point that I was making was that Linus is just another OS guy on this issue. The reason I disagree with him is because although Open Source, by definition, is meant to be modified and used freely, to change things too much takes away standard. The Operating System wars are raging as it is, and instability amongst Linux could destroy it's fighting chance. But that's just me, right?

Re:So says God!

[Anonymous Coward]

At least get your metaphor right:

Jesus = Linus (the saviour)
God = RMS (the creator)

As much as i hate religion and the "freesource is a religion" trolls, I've got to admit its an interesting parallel.

Welcome to Open Source

[Anonymous Coward]

What are people bitching about? It's OPEN SOURCE. Redhat has made a business decision to backport functionality/fixes to an older kernel. They feel their customers need those fixes/features and they're supporting their customers. They're also making those fixes/features available to anyone else who wants to download them.

You don't want them? FINE. Download and build a vanilla kernel at any time. It only takes a few minutes. Talk about a tempest in a teapot....

Re:Welcome to Open Source

[deathguppie]

vannilla works fine on my Gentoo, of course it's not quite as zippy

Re:Welcome to Open Source

[HiThere]

Now if I were metamoderating this (the parent), what should I do. It's clearly a troll, rather than flamebait. OTOH, I don't want to say that it was improperly dinged. Decisions, decisions.

Well, now that I've posted, I won't have that problem. This time.

BackPorting is a bad thing in general, but ...

[CrackHappy]

can be good in specific instances.

I believe Linus touched on this point pretty eloquently.

The basic issue that I believe is the root of the problem is that at the end of the day, the majority of Linux users and developers are generally in synch and moving along at a brisk pace, while the backported and modified kernels are effectively not supported except by the specific vendor that created the fork. This basically will always either lock the customer in or make it more difficult to integrate new features if the customer wishes to switch vendors. This is like turning forks into a mini Windows.

Just my $.02

Re:BackPorting is a bad thing in general, but ...

[Knetzar]

Couldn't the customer just upgrade to the newer kernel and then use any vendor? If a customer needs a feature (and has the money or man-power), the customer is going to get it one way or another.

Re:BackPorting is a bad thing in general, but ...

[CrackHappy]

That's true, but at what expense? Let's say the vendor that a customer is using goes out of business and has done some significant backporting and customization of their kernel. Some of the vendor's applications depend upon this and thus would need some modification to make it work with a vanilla kernel. At that point, there could be significant cost to the customer.

I know that it's a hypothetical situation, but I see it every day at work. The vendor that we are using has built their software and applications in such a way that we cannot migrate any of our applications off of Microsoft platforms because of very specific tie-ins to SQL Server, IIS, and Windows 2000.

The data could move just fine, but all the business logic would be toast.

I just can see this kind of thing happening with a forked and backported kernel. I don't think it is anywhere near as likely, but something to consider.

Re:BackPorting is a bad thing in general, but ...

[tweek]

You've obviously, as most of slashdot it seems, have never heard the two words "supported configuration".

Let me explain. We're running a DB2/WAS installation. We bought all the hardware from IBM down to the IBM branded FC cards and FC switches. We then purchased several RHAS2.1 licenses for this installation.

Why? Enterprise. Pure and simple. We need immediate support from IBM and they have a very specific list of "supported configurations". Deviate and they won't touch you.

RedHat backporting fixes has only been a problem when certain drivers check for a SPECIFIC subrelease in the kernel. This happened with the IBM 3582 LTO robot we have.

RedHat AS2.1 uses kernel 2.4.9 but is constantly backporting security fixes. They rev the kernel RPMS like so:

2.4.9-e25summit, 2.4.9-e38summit and so on. Most driver vendors I've worked with check for RHAS 2.1 running kernel 2.4.9 and leave it at that. For some reason the blasted tape library drive checked for a specific rev number. I can't even download the kernel from RedHat or anywhere on the web that the stupid developer built the kernel against. At some point I was forced to cpio the rpm and force load the tape library driver just to get the damn thing loaded. Guess what? As I expected it worked just fine.

RedHat and SuSe and the gangs that backport do it for a very good reason. They have a kernel that hardware vendors build against. The backports go through some SERIOUS review to make sure they don't break anything existing. This also keeps the kernel version number they check for the same.

Re:BackPorting is a bad thing in general, but ...

[HiThere]

Well, you wait a year, and then move on to the next new stable kernel. That will have all the backported fixes in it.

Of course, if you are depending on a closed source application, then you may be out of luck, and stuck at the current kernel version forever. That can be the price of a frozen application. (OTOH, I'm still running Alpha Centuari, and the last time I checked CivCTP still worked on my Debian unstable. So it ain't necessarily so.)

You have, however, pointed to one of the reasons that I have largely switched over to open source applications. It may not do all you want, but you can depend on it. (And if you care enough, you can either fix it yourself, hire someone to fix it, or request help from the project. [You may not get the help...but that's true if you ask any developer. Just TRY asking MS!])

I have to disagree on a few grounds

[Alan Hicks]

While I don't believe that back-porting security fixes, or even new features is a major danger to forking an open source project (be it the kernel or something else doesn't matter), I do find it a danger as a sysadmin.

Often times I've had to administer an older RedHat linux machine that may be running a version two or more years out of date. A vulnerability comes up in a service that hasn't been patched in God knows when, and I have to fix the hole. The security advisory says version a.b.c is vulnerable and that I should upgrade to a.b.d or a.e.X. So I log onto that machine and check to see what version it's running and I see:

a.b.c-g

So is a.b.c-g vulnerable or not? Did RedHat back-port something from the a.e.X branch that fixes this? Now I have to dig through some RedHat mailing lists which I may not be subscribed to to find out. Now I know for a fact that when I see an a.b.c-h version for download from RedHat's site, that I've need to upgrade.

But what if it's the other way around?

What if I hear about a vulnerability in version a.e.X of that same software, but that the a.b.X version is safe. Did the vendor back-port some vulnerable bit of code from a.e.X into their a.b.c-g binaries? How am I to know?

Back-porting things like this makes it hell on a sysadmin who then has to subscribe to lots of different mailing lists, particularly if you're running different distributions.

Re:I have to disagree on a few grounds

[Anonymous Coward]

The easy answer is to assume the fix hasn't been backported unless the vendor explicitly says it has. Even then, I personally would upgrade to the "latest" version and eliminate all doubt (at least until the next vulnerability is discovered).

Re:I have to disagree on a few grounds

[Alan Hicks]

The easy answer is to assume the fix hasn't been backported unless the vendor explicitly says it has. Even then, I personally would upgrade to the "latest" version and eliminate all doubt

I typically do just that, but it isn't always as easy as it should be. RPM based distributions (of which RedHat by definition is) tend to have obscure, hard to trace dependencies in their packages. Compiling from known good source downloaded from the software project's FTP site isn't always the best solution, particularly if you've let other system updates lapse.

Case in point. I came across a RedHat machine running a vulnerable version of OpenSSH. It was no longer being supported by RedHat, so I downloaded the latest release of OpenSSH Portable. The configure script complained that zlib was old and possibly insecure. This means I had to go in an compile a new zlib, and then make sure everything worked properly when linked with the new zlib. But now, my entire RPM tree is completely hosed. I might as well not even have RPM, since nearly every damn thing relies on zlib.

In checking RedHat's FTP sites, they had apparently also back-ported security fixes to the older version of zlib (IIRC), which of course meant OpenSSH would have still complained when I re-compiled, but I could be modestly sure it wouldn't be vulnerable, or could I?

Of course practicies like that enventually force you upgrade your machine to a new version at some point in time, or hose the RPM database by compiling all new updates and their dependencies from source.

Thank God and Patrick for Slackware, where these problems are few and far between, and typically MUCH easier to resolve.

Re:I have to disagree on a few grounds

[c0d3m4n]

My easy answer is simply to not use RPM. It's just not up-to-speed with Slack's package manager, Debian's package manager, Gentoo's portage system, or Arch Linux's pacman/abs thing, so let's just forget RPM ever happened and give a nice, old school, slightly obnoxious 'Long live .tar.gz!' cheer, and know that it just doesn't get any geekier than that!

Re:I have to disagree on a few grounds

[DA-MAN]

So is a.b.c-g vulnerable or not? Did RedHat back-port something from the a.e.X branch that fixes this? Now I have to dig through some RedHat mailing lists which I may not be subscribed to to find out. Now I know for a fact that when I see an a.b.c-h version for download from RedHat's site, that I've need to upgrade

That's what the errata pages are for. One quick stop at redhat.com/errata will answer all your questions.

What if I hear about a vulnerability in version a.e.X of that same software, but that the a.b.X version is safe. Did the vendor back-port some vulnerable bit of code from a.e.X into their a.b.c-g binaries? How am I to know?

Again, errata pages

Back-porting things like this makes it hell on a sysadmin who then has to subscribe to lots of different mailing lists, particularly if you're running different distributions.

Let's just think about Apache as an example. Say a bug comes out in Apache 1.3.26, theres a fix in 1.3.29. Now let's say that you also bought an apache mod ala Chilisoft to handle ASP, but it only works with 1.3.26. Would you feel good about RH updating to 1.3.29, instead of moving over those 2 or 3 lines that fix some buffer overflow in some .c file on an older version?

In addition there are open source modules. Imagine a problem with Apache 1.3.26 so RH puts out a fix for 1.3.29 in addition you'd have to release errata for php + all it's modules, mod_ssl, mod_perl, mod_python, and more...

Backporting is the best way to run a stable and secure system. Micro changes to known good subsystems. In fact if you notice, Debian Stable is secure and stable because of the backporting of fixes and those releases last for decades.

Re:I have to disagree on a few grounds

[Pros_n_Cons]

try "rpm -q --changelog |more" If you know what is vuln you will see the changes there.

Re:I have to disagree on a few grounds

[wobblie]

Red Hat apparently takes the errata pages down for distros that are no longer supported. This is a real PITA and is just unforgivable, I dealt with this the other day, trying to figure out whether a RH 7.3 box was vulnerable or not. The only errata i could find was for RH9 and the enterprise series. If you can tell me where the errata pages are for older versions I'll shit a brick, 'cause they don't seem to be indexed by the search engine and if they're there, they're buried somewhere.

Debian is just so much easier and are so much more polite to their users. Not to mention they keep up with advisories much better than RH.

Re:I have to disagree on a few grounds

[DA-MAN]

If you can tell me where the errata pages are for older versions I'll shit a brick, 'cause they don't seem to be indexed by the search engine and if they're there, they're buried somewhere.

Well, let's see.... At the very end of Red Hat's Errata Page you will see the following text:

Advisories for unsupported products

Errata that have been previously released for unsupported and End of Life Products are also available.

In that text, there is a link to this URL:
http://www.redhat.com/security/archives.html

So get to shittin.....

Re:I have to disagree on a few grounds

[Alan Hicks]

Let's just think about Apache as an example. Say a bug comes out in Apache 1.3.26, theres a fix in 1.3.29. Now let's say that you also bought an apache mod ala Chilisoft to handle ASP, but it only works with 1.3.26. Would you feel good about RH updating to 1.3.29, instead of moving over those 2 or 3 lines that fix some buffer overflow in some .c file on an older version?

First of all, we're not talking about previously back-ported security fixes. Distributions don't tend to ship an older version of an application with back-ported security fixes from a later release; they release the latest "stable" with back-ported "features" from the development release.

Second of all, in your Apache example, I'm sure that the vast majority of apache users haven't done this. I have no numbers to back-up my position at this time, but I'd say that far and away the most (maybe 90%) of people aren't running any other software taht will only interface with an older stable version. Most of the time you can just upgrade it and the plugin is none the wiser. Of course, if that's not the case, you have no choice but to backport. Still, I would rather be the one making that call, not the distribution. I am no great C programmer, but I can read it well enough and move the few lines that are changed in something.c and recompile. In short, if it's going to be backported I want to be the one doing the backporting.

Re:I have to disagree on a few grounds

[DA-MAN]

First of all, we're not talking about previously back-ported security fixes. Distributions don't tend to ship an older version of an application with back-ported security fixes from a later release; they release the latest "stable" with back-ported "features" from the development release.

The parent poster was posting about how he hated security backports because he can't tell whether he was vulnerable or not from his security scanner. I was commenting on that. He's saying that he'll find a box with apache 1.3.26-39, and not know whether he's vulnerable for something that hit 1.3.26.

Second of all, in your Apache example, I'm sure that the vast majority of apache users haven't done this. I have no numbers to back-up my position at this time, but I'd say that far and away the most (maybe 90%) of people aren't running any other software taht will only interface with an older stable version. Most of the time you can just upgrade it and the plugin is none the wiser.

The chilisoft plugin, ok...but this would also mean recompiling all packages that are a part of apache as well (the mod_*'s). Why rebuild php, mod_perl, mod_ssl when there is only a bug in apache? Doesn't make much sense, it just means more things that can go wrong.

Of course, if that's not the case, you have no choice but to backport. Still, I would rather be the one making that call, not the distribution. I am no great C programmer, but I can read it well enough and move the few lines that are changed in something.c and recompile. In short, if it's going to be backported I want to be the one doing the backporting.

Go for it. No one is forcing you to use any updates that the vendor puts out. That's the beauty of open source. :)

I guess we agree to disagree

Re:why the fuck should we care

[Anonymous Coward]

haha BURN!

YOU FAIL IT

[Anonymous Coward]

Done & done.

SuSe's CTO on backporting:

[Anonymous Coward]

He says Linus Torvalds is wrong.
As much as I respect Linus, I would much rather go with the word of a successful CTO than an unemployed code zealot.

Re:SuSe's CTO on backporting:

[mattyrobinson69]

unemployed code zealot?

doesn't linus work for OSDL?

Re:SuSe's CTO on backporting:

[kelnos]

while i won't argue with your premise (it's debatable), i will with your "facts." torvalds is indeed employed (getting paid to work in linux, IIRC), and out of all the major figures in the OSS arena, he's one of the last i'd ever label a zealot.

Linus is the human voice of the kernel

[darthcamaro]

Way too many voices from anonymous cowards in this discussion dissing Linus. Linus is the voice of the Linus kernel. Period. Sure many,many others contribute, but it's his original creation. He holds the copywrite to the name Linux so he has the 'EARNED' right to the authoritative voice. Nuff said.

Re:Linus is the human voice of the kernel

[Anonymous Coward]

Actually, it's Copyright from a spelling standpoint. But actually Linux is a TradeMark and not a copyright.

Re:Linus is the human voice of the kernel

[Anonymous Coward]

You missed the point. We're not dissing Linus, we're dissing the SlashMob idiots who blindly worship everything the man says.

Re:Linus is the human voice of the kernel

[geminidomino]

He holds the copywrite to the name Linux so he has the 'EARNED' right to the authoritative voice. Nuff said.

One could say that, since he GPLed that creation, he waived the right to be an "Authoritative" voice. Nothing stops me (except for my refusal to touch GPLed code) or Redhat/Slackware/Joe Hacker from implementing something that Linus is dead set against, and he can't do a thing about it.

Re:Linus is the human voice of the kernel

[Kynde]

One could say that, since he GPLed that creation, he waived the right to be an "Authoritative" voice. Nothing stops me (except for my refusal to touch GPLed code) or Redhat/Slackware/Joe Hacker from implementing something that Linus is dead set against, and he can't do a thing about it.

Not quite. Having GPLed it and as others have contributed to it he no longer holds the entire copyright for linux kernel, that's true. But he owns the trademark for the name linux. So he is in every possible way still the authorative voice for the linux kernel. He may choose to merge your changes to his tree or not and there's little you can do about that.

Don't like it? Feel free to fork it. But the Linux kernel is still under his command, your fork may be called whatever suits you best and you may do whatever want with it within the rights that GPL has granted you.

Wow, four

[Anonymous Coward]

"The basic issue"
"I believe"
"root of the problem"
"at the end of the day"

At the beginning of one sentence, you used four of the most overused means of beginning a sentence that I know of - impressive!

Re:Wow, four

[CrackHappy]

Oh gawd, you're right.

I've been consumed by the corporate lingo machine. Comes from talking to the CEO too much.

Re:Wow, four

[golgotha007]

well if that's the case, then you need to throw in a few 'move forwards' in there.

i deal with several companies in the states, and email from their CTO and CEO's are always peppered with 'moving forward' and 'move forward'.

it drives me insane! when Darl McBride kept telling open source folks shit like, 'yes, i know you're all concerned with weather or not our IP is in the kernel, but let's just move forward.'

how freakin assinine is that?

Re:Wow, four

[Anonymous Coward]

Weather in the kernel? That could be bad.

Yeah, well...

[big_groo]

Slashdot seems to agree with Perens...

Uh, Linus' email IS out there

[bach37]

Never read any kernel changelogs, eh? Look at the very last line on this one.
I'd say Linus is very open, especially posting his open letters to SCO awhile back.

Re:Uh, Linus' email IS out there

[DAldredge]

Joke in response to parent post.

Suckers!

[Anonymous Coward]

I love it when all the Linux drones bitch and moan as they follow Torvalds down the primrose path. Now us Mac users, for instance, think diff...hold on...Steve's doing another keynote...be right back...

TRFA - instead of going for the big headline

[Magickcat]

Linus' opinion appears to be much more balanced than your selected excerpts and comments portray. The article is quite even handed, and you appear to have completely misrepresented or perhaps misunderstood the complex ideas in it.

His final comments are in fact: "So you win some, you lose some, so far I suspect it's been mostly positive."

Here are some extracts from the article that illustrate this in a more even handed light:
"And even Torvalds' support of the practice comes with some caveats. "There are parts of it that worry me logistically," Torvalds wrote in the e-mail to internetnews.com. "What usually ends up happening is that the back-ported patches aren't being very cleanly maintained, and that ends up making it harder for people to do a good job of maintaining a coherent base for the stable kernel." "

"Although kernel 'coherency' is a victim of backported features, according to Torvalds, its impact is not long lived. "That lack of 'coherency' makes long-term maintenance harder (and is probably why the SuSE people aren't thrilled, because it also makes it harder to keep different trees reasonably well in sync)," Torvalds continued."

""But as long as the long-term goal ends up to drop the old stable kernel in favour of the development kernel anyway, the pain is likely to be fairly temporary.""

Bruce Perens also contributes some fairly even handed comments:
"However, Bruce Perens, a former Debian Project Leader and author of the Open Source Definition, wasn't as quick to compliment Red Hat.

"In a public post, Perens wrote, "I have a large customer who refuses to run Red Hat's kernel even when they run Red Hat's distribution. And it's just for the reason that [SUSE] talks about. The kernel is so far diverged from the main thread of Linux that it's a dead-end, and there's no hope of getting it supported from anyone but Red Hat. I don't know if they meant it as a lock-in play, but it works out that way. And my customer doesn't have patience for Red Hat's support.""

"Despite his comments, Perens told internetnews.com he didn't think the issue was that big a deal and hoped the community wouldn't over-react."

Re:TRFA - instead of going for the big headline

[Anonymous Coward]

Again, you see Perens FUDding RedHat without disclosing that he is competing with them in the enterprise support business. How "even handed" of him.

Re:TRFA - instead of going for the big headline

[Magickcat]

Well, perhaps you also missed when it says in the article:
"I don't know if they meant it as a lock-in play, but it works out that way. And my customer doesn't have patience for Red Hat's support.""

"Despite his comments, Perens told internetnews.com he didn't think the issue was that big a deal and hoped the community wouldn't over-react."

So he did in fact state that he has customers, and that they don't want support from Redhat, but are instead his customers.

Re:TRFA - instead of going for the big headline

[Anonymous Coward]

In the context of the comment, he should have been identified as the person behind UserLinux. Period. End of Story.

If some Joe Blow (who happened to work at Sun) said the same thing, you guys would be ballistic.

Re:Some things that I love:

[Anonymous Coward]

You forgot your praise for SCO and the RIAA/MPAA. Do you support the actions of these groups?

Seems everybody agrees now...

[greppling]

...so while I am not completely against lots of forking, it seems worthwile to reexplain the problems with it:

The more standardized the installed Linux kernels around the world are, the easier it is for application developers to develop and test for all Linux platforms. Why do you think don't we have an Oracle certification for Debian? Because the debian vanilla kernel is different enough from the RedHat kernel that all their testing is invalidated. Also, remember that there is not even a standardized way to test whether a certain feature is available way in an installed kernel.

I think Linus Torvalds himself is always underestimating the importance of his vanilla kernel. His claim is always that it is not very important for a patch to be "in", as everyone who needs it can apply it himself. But as a matter of fact, it doesn't make sense to make an application dependent on a kernel feature, unless this feature is part of the vanilla kernel. Or unless you are willing to develop for "RedHat only", at which point the /. crowd will certainly cry foul.

The other point is, of course, that many forks imply a diversion of kernel development resources. For the record, one of the reasons Andrew Morton has given for accepting the 4G/4G patch into -mm is that he is aware that distributions will need it anyway, and he doesn't want to have distribution kernels diverge from vanilla as quickly as in 2.4. (Actually, now that objrmap is in -mm, it might not be necessary any more.)

I salute you, sir

[Anonymous Coward]

I'll just have to be quicker the next time an opportunity for an anal sex joke comes along. Be forewarned.

Kick ASS!

[ol2o]

To be honest, I feel that this is a good thing. While Linux has constantly has been pushing to make sure that everything plays nice with the newest hardware/software/airware, this stands firmly in the vein that created it to be the solution that it is today for development, servers, and a choice for the common person. Hats off (fuck is that a pun?) Linus, the tortist catches the rabbit once again.

GPL gives you choice

[richard_za]

GPL gives the right to fork/backport the code, nobody is forcing you to use a forked/backported kernel. If your current installation is stable and you only need that feature - what is stopping you?

Re:True story...

[Anonymous Coward]

I can believe it. I heard reports that Linus left a floater at the last LinuxWorld Convention.

Re:Uh, Linus' [Oops]

[bach37]

Ah! My bad, I'm a little slow.

TIME

[RoadkillBunny]

Speaking of Linus Torvalds, he is one of the 100 men that made a impact in the current edition of TIME (Canadian Edition).

Re:True story...

[Anonymous Coward]

Not only that, but Linus Torvalds touched my junk liberally. He strapped me into the rack in his office and couldn't keep his offensive hands off my "kernel". I couldn't believe what the fuck was going on. I told Linus that the FSF would simply not approve of a GNU contributor touching an Open Source developer for free (as in beer).

This is great

[ErichTheWebGuy]

Personally, I prefer backporting. I see no reason for me to upgrade my installations of kernel 2.4.x, etc. when the system runs just fine. It adds a lot of value to Linux if (at the very least) patches are backported for at least 2 or 3 major revisions. Look at the outcry when our pals in Redmond said no more Win98 support. That only underscores the need for packporting and supporting software for an extended period after the last "official" release.

Go Linus!

Re:This is great

[Anonymous Coward]

Uhh, the difference is you have to PAY to upgrade to a new version of windows.

With Linux you do not.

Free your mind from that proprietary closed source mode of thought my friend.

(also may I ask: If it runs fine why do you need backports for?)

We aren't talking about backporting fixes here, they are talking about backporting ENTIRE FEATURES...i.e DUPLICATING EFFORT.

Anyways, try to think...thanks...

Obligatory

[cpu_fusion]

Looks like we don't need to speculate [..]

You must be new here...

Re:Who cares about Mr Thorwaldes?

[DarkSarin]

You sir, are on (or more) of several things:

*Very new here.
*Very brave--this usually is posted as AC
*Very stupid (note that this is not exclusive of other options.
*A troll (also not exclusive).
*porting balls of steel the size of a semi truck.
*trying to be funny. I really hope this is what it is, because you are going to get flamed.

BTW, care to provide links and or sources? (in case you aren't trying to be funny.

Yup

[ErichTheWebGuy]

As far as I know RedHat has shipped everything open source for a very long time now.

Yea, RedHat ships everything GPL (or compatible) with the exception of their artwork. I installed Fedora last week for the first time (had been running mdk 9) and it's great. It's stable, runs great, highly configurable, etc. And, it seems to me to be among the "freer" of the distros.

I was SOOO irritated at RedHat stripping mp3 support at first, until I read why they did it. I gladly bit the bullet (and downloaded the patch for xmms ;-)

Re:Yup

[DA-MAN]

Yea, RedHat ships everything GPL (or compatible) with the exception of their artwork.

try rpm -qi redhat-artwork and you'll see the following:

Name: redhat-artwork
License: GPL
Description: redhat-artwork contains the themes and icons that make up the Red Hat default look and feel.

Re:Yup

[Trepalium]

Red Hat's "Bluecurve" is a trademark. There are plenty of copies of Red Hat's artwork out there, but they just can't call it Bluecurve (Debian, for example, has a theme called lighthouseblue).

Re:Yup

[Anonymous Coward]

That is a bit weird though, given that the GPL is a software license. It's not very easy to apply to artwork.

Re:True story...

[Anonymous Coward]

Linus is just being environmentally conscious by saving water.

At my house we only flush the toilet after it's full. Our waterbill was $2.41 last month.

Re:Some things that I love:

[Anonymous Coward]

Well, I like SCO just because they piss off people that annoy me. I don't care if they are right or not.

The RIAA and MPAA have never done anything wrong to me. I pay them money, they give me music or movies. Its very natural.

Forking is almost always ugly

[spagetti_code]

I worked on a unix product in the late 80's early 90s. We supported 35 different variants/versions of Unix. Each one had a set of #defines throughout the code dealing with slight variations in libraries, in tools, in compilers and so on.

When we ported to a new version of unix, we had scripts that would compile test programs for each of 100s of known features that differentiated these unii (plural of unix?). Results of the test programs would auto-create the config program.

It was a nightmare, one that I have not had to deal with as much in the Windows world. (re-reads sentence, sighs, puts on flame suit). It was one of the early strengths highlighted by the MS marketing dept ("There is only one windows, but hundreds of unixes").

I was hoping Linux wouldn't go down that path. Just the thought of YAST vs RPM etc gives me the willies. Forks can only lead the distros further apart.

Re:Forking is almost always ugly

[Anonymous Coward]

unii (plural of unix?)

unices

Re:Forking is almost always ugly

[zsau]

Plural of Latinate English words ending in -ix is either -ixes (native) or -ices (pronounced 'iseez') e.g. matrix -> matrixes/matrices, appendix -> appendixes/appendices. I would therefore suggest Unices if you refuse to touch Unixes.

There's a handful of words ending in -ice that were backformed from plurals in -ices, the correct singular of which was -ix. Therefore, a generic word for 'Unix' could be 'Unice' (Youness). (Unfortunately I can't remember the examples I was given.)

Re:Forking is almost always ugly

[Anonymous Coward]

God I hate your stupid sig

Re:Forking is almost always ugly

[sw155kn1f3]

> When we ported to a new version of unix, we had scripts that would compile test programs for each of 100s of known features that differentiated these unii (plural of unix?). Results of the test programs would auto-create the config program

LOL man :) You just described GNU autoconf.
What's wrong with it ?

Re:Forking is almost always ugly

[meanroy]

Dude,

It's survival of the fittest.

This shit is jus tools to do job!

May the best tool win!

Damn bubba, get a clue.

( my rate:90% trol
the second 90% info.)

oh, software huh.

Re:Forking is almost always ugly

[Anonymous Coward]

LOL man :) You just described GNU autoconf.

He said "late 80s, early 90s". Maybe it didn't exist in a usable form back then.

Re:Forking is almost always ugly

[sw155kn1f3]

Sure it didn't exists.
My point is that it's normal to do such sort of things in order for software to be cross-platform. And has always been done.
Everything has its price, nothing to do with it.

Re:Forking is almost always ugly

[zBoD]

What about boxe -> boxen? Where does that come from? I think I've seen "Unixen" somewhere.

BoD

Re:Forking is almost always ugly

[zsau]

Generalisation of ox -> oxen. -en is descended from an Old English pluralisation, specifically ofthe weak declensions (if 's (apostrophe-s) hadn't been generalised for possessive, you would talk of 'an oxen horns' and 'many oxen horns' as well). It's retained more use in Dutch and German. Unii, though, is an obvious attempt at looking Latinate, so I chose Unices.

MOD PARENT UP

[Anonymous Coward]

It should be under guidelines:
If you dont get a joke, don't mod it down.
That was hilarious

Welcome

[Anonymous Coward]

You're pretty good, but your extra-heavy emphasis on Microsoft is too unbelievable. Every working techie with more than a year of experience knows that Microsoft products aren't the best tools for the job when it comes to many things, which is why the company doesn't have many followers. So, cut back on the pro-Microsoft fluff a little and you can do some real damage (both in the karma whore department AND the flamebaiting).

Other than that, troll on brother, nice to have you aboard.

Re:Who cares about Mr Thorwaldes?

[Anonymous Coward]

I get it... a Linux fanatic posts like a Windows fanatic, makes some idiotic rant, and in the process makes Windows look worse.

How insightful of you!

You were joking, right?

Slackware uses the vanilla kernel ...

[Anonymous Coward]

... in something like 98% of all cases. The nice think about that is that there is never any problem with just grabbing the latest kernel from kernel.org and installing it. It *always* just works since there are no additional vendor supplied patches to think about.
I like it that way.

Just Like This

[SomeOtherGuy]

The freedom and power to backport, sideport, crossport, etc...Is the reason why the Linux kernel is now running on everything from Tosters and Parking meters to Rocket Ships and Space Stations. How can that be a bad thing? Millions of devices are running on this stuff...how cool is that?

What Does Open Source Mean to You?

[Anonymous Coward]

The semantical definition of open source is the key. Is LINUX trying to be UNIX? Is LINUX bound by UNIX's history? No! LINUX is free, its open. Its punk rock. I think that's what I like the most. You can do whatever you want with whatever you want and its all good, as long as you follow the GPL, or whichever license.

People get all freaked out on the Red Hat corporate stance (myself sometimes included). But in reality, comparing Red Hat with Microsoft just does not work. I mean, there are so many open source options, and I don't think Linus is close to selling out to Red Hat.

Focus on the fact that LINUX is free. There will always be some dork, even me if I must, who will throw together a distribution for those less inclined to compiling things themselves.

Sorry for the rant.

Re:Who cares about Mr Thorwaldes?

[Anonymous Coward]

Go back to MSNews, er, I mean, OSNews... :-)

Re:Who cares about Mr Thorwaldes?

[Anonymous Coward]

come on; don't you recognise satire?

Re: likes to spin

[Anonymous Coward]

Spin2K

Re:Who cares about Mr Thorwaldes?

[Aquafort]

At times a bit heavy handed but saved by a few flashes of brilliance like "an Enterprise Server boxen." Damn! That slays me!

Re:backport

[Anonymous Coward]

So.....why am i supposed to know that ?

Re:True story...

[JWSmythe]

If some guy was stalking me in a IHOP, following me into the bathroom, makeing an effort to sit in the next stall, and paying that much attention to my bathroom activities, my main motivation would be to leave the bathroom quickly too. If he forgot to flush, so be it, some freak was following him around. Stop stalking the man.

If you're such a great Windows lover, go stalk Bill Gates instead. But, you may not see him in a IHOP.

Re:Who cares about Mr Thorwaldes?

[JWSmythe]

Ah cut him a break. He's busy admiring the MCSE cert on his wall. "Microsoft is great, for only a few thousand dollars, they made me a certified engineer." :)

I have my CCNA hanging on the wall, and stacks of Linux, Solaris, general *nix, Cisco, general networking, and programming books (many languages). The well worn books are my certification. The Perl reference books have visible marks where I thumb through the pages frequently. His books look like they just came out of a book store.

Source of Bruce Perens Comment

[tkittel]

From the article:

>> However, Bruce Perens, a former Debian Project Leader and author of the Open Source Definition, wasn't as quick to compliment Red Hat.

In a public post, Perens wrote, "I have a large customer who... <<

The public post mentioned was actually this Slashdot comment here.

Work vs. Home

[miffo.swe]

I think many of those who complain about backporting doesnt have to manage many servers as i have to. When i have installed and made the things sparkle i dont want to be forced to upgrade. I want my servers to last some time to keep my work load down. Constant upgrading and installation takes valuable time that i doesnt have away. I suspect RedHat backports for preciely those reasons, too keep the upgrade threadmill at bay. Look at how many poeple still uses NT, last i saw some statistics it was something like 60% still on NT. I presume upgrading those servers would demand much work and labour from the admins.

We dont want a similar situation for linux users, that they dont upgrade because of possible hassle. Backporting ease upgrading while you still get access to new features.

At home its a whole different matter for us who love to tinker at our free time. I use gentoo of that very reason. I want the latest and gratest at home but damnit not at work.

Re:True story...

[sageo]

If it's brown flush it down if it's yellow let it mellow letting the brown float is just wrong, but if i flushed every time i pissed with the ammount of drinks i have a day, i'd be paying almost as much for water as i am for broadband!

Re:Who cares about Mr Thorwaldes?

[Tore S B]

I have the certificates to prove this, and furthermore they're issued by the biggest software company in existence.

That proves nothing. Actually, it may speak negatively about your skills. I passed an MCSE at age 12, and I sucked at age 12. I was a huge newb who thought that hackers were bad people etc. Reading your post, so do you. Unfortunately, I doubt you have the convenient excuse of being 12.

These are hard numbers and 100% FACTS! There are several more where these came from.

Oh, boo-hoo. Not to mention, these results were all from independent Microsoft examinations.

...Reliable companies with tried and tested products, or that bedroom coder Thorwalds who publicly admits that he is in fact A HACKER???

Since WHEN has Windows been EITHER reliable or tried and tested? Microsoft is a commercial company, making commercial products, for profit - - That Bedroom Hacker made brilliant pieces of code, that have been peer-reviewed by people who are not interested in profit, but software as an art.(And Linus isn't driving a BMW Z3 for nothing! ;)

I know, I know... Feeding the trolls..

This sounds serious

[Anonymous Coward]

Take a sick day, spend all day browsing Slashdot, and call me in the morning.

--Dr. A. Coward

This _has_ to be a joke!

[Reverant]

Last time I heard Linus Torvalds saying something good about something other than his own work was...that's funny! I don't think he has _ever_ done such a thing. I guess there's a first time for everything huh?

MFC

[Anonymous Coward]

Torvalds wrote: 'I think it makes sense from a company standpoint to basically "cherry-pick" stuff from the development version that they feel is important to their customers.

FreeBSD has been back-porting stuff from their development branch (CURRENT) into their STABLE branch (which is where FreeBSD releases are forked from) for years. They even have their own TLA for it, "MFC" == Merged From Current. Makes STABLE... well,... stable. Very stable. And secure.

Re:Who cares about Mr Thorwaldes?

[Anonymous Coward]

You may want to scroll back a bit -- I think you forgot to post a serious reply to a couple of the earlier obvious trolls.

Open Source

[Anonymous Coward]

This is the whole essence of Open Source after all!

Re:Who cares about Mr Thorwaldes?

[Short Circuit]

My favorite one was when he compared against "Linux 7.0"

I smile every time I see that.

Checkpoint & Trend Micro come to mind.

[Erik_]

The Checkpoint NG and the ServerProtect from TrendMicro come to mind... they are VERY specific on which kernel you run :-(

here's why I do and don't

[painehope]

( note : we're a redhat/fedora shop )

at work :

1) on our cluster, because every redhat kernel we've run had some problem, either w/ performance or stability. I'm sure if I took the time to compile it w/ all the correct .config options, stripped out a lot of the crap we don't need, etc., it would probably run just fine - but w/out the functionality that redhat's patches give you. So I take vanilla kernels, patch in what I need ( it's a lot easier to add patches and figure out what breaks, than to remove patches and then figure out what may or may not be causing the problem ), twist it up w/ whatever compiler is currently recommended, and we're good to go.

2) on our desktops and servers, the redhat kernel is almost always the way to go, and the only thing we ever add is the Nvidia drivers.

for my personal use, it depends. One workstation is running Fedora Core 2 test2 w/ a kernel.org 2.6.5 kernel, since I had issues w/ the out-of-box kernel + Nvidia drivers, other workstations are running Redhat 9 w/ the stock kernels, etc. It just all depends.

As far as back-porting features making a mongrel or a "dead-end" out of the kernel, the first thing I thought when I heard the SUSE head spouting that off, was "blow me". That's so much hot air it ain't even funny. Like the world will end if you ship a custom kernel to your customers w/ features that wouldn't be available `til later. Do you think development will end because Redhat backports NPTL? Oh shit, in that case I better stop patching drivers, adding the perfctr patches, etc. or else I'll be killing Linux. Linus, forgive me.

Re:Who cares about Mr Thorwaldes?

[orasio]

The Perl reference books have visible marks where I thumb through the pages frequently.

Damn! whatever happened to washing your hands?

Re:Who cares about Mr Thorwaldes?

[JWSmythe]

Don't worry, I wash my hands frequently. But years of thumbing through a book, and it'll show wear.

Re:Who cares about Mr Thorwaldes?

[orasio]

It sounded funny in my head, maybe I will have to tune my sarcarm-o-tronic device a little lower, sorry.

Re:Who cares about Mr Thorwaldes?

[JWSmythe]

Nah, just set it to verbose. :)

Re:Sounds like Cisco's new version numbering

[skidv]

Reminds me of Cisco's new version numbering scheme announced earlier this month.

Re:Who cares about Mr Thorwaldes?

[DarkSarin]

sure I do. But it wasn't quite definite enough. I even note this possibility. It's just that I thought the troll-hunters (mods) might have broken their sarcasm meters, and wanted to give them something to think about.

Re:Sounds like Cisco's new version numbering

[Sri Lumpa]

Iread it seriously (although I thought there were many fields of dubious use)until:

"So the new simplified version number would become

00:00:0C:02:12:00:04:00
00:FF:00:FF:00:FF:00:FF
53:58:41:00:00:44:55:48
00:00:00:FF:00:FF:FF:FF "

Then I looked further and:

"Remember, this is all effective immediately, April 1, 2004."

Thanks for the laugh.

Quick solution to remote kernel compile issues

[Grax]

Configure a serial console to a nearby machine.
I use either partner machines (a pair of machines that control each other's serial consoles) or I set up a serial console machine with a large number of serial ports that I use to control their consoles.

This way you can do all manner of wild dangerous stuff remotely and greatly reduce your chances of having to run down to the colo. As long as the system boots without crashing and can access the serial port you're in.

And also make sure you have the number to the colo operator but you know about that already.