Slashdot Mirror
Novell Changes Enterprise Linux Kernel Mid-Stream
darthcamaro writes "Enterprise Linux kernels, from Red Hat or Novell, don't change version numbers inside of a release, right? While that has been the case for the last decade of Red Hat and Novell releases, Novell is breaking the mold with SUSE Linux Enterprise 11 service pack one. Instead of backporting new kernel features to the kernel they originally shipped with — which maintains software and hardware vendor certification — they've re-based their Linux kernel version altogether. '"There were some things that led us to update the kernel itself, which is something that we normally don't do: Neither SLES 9 or SLES 10 got a kernel update," Markus Rex, director of open platform solutions at Novell, told InternetNews.com. "But in this particular case, after deep discussion with our ISV and hardware vendors that gave us certifications, we felt in this case a kernel update was the appropriate step to take.'"
Enterprise distributions avoid kernel version upgrades for two distinct reasons: perceived stability and fixed API/ABI for third-party modules. In this case, upgrading from 2.6.27 to 2.6.32 may well improve stability, particularly since many other distributions plan to ship 2.6.32 in their next release as well. As always, any upgrade can lead to the occasional regression that enterprise customers hate, but hey, paid support means they'll get a fix. So, that just leaves API/ABI issues, hence the discussions with ISVs and such. Third-party modules keep becoming less and less important with each new kernel version, and I can readily believe that the pain of dealing with API/ABI issues no longer outweighs the benefits of new hardware support and features provided by 2.6.32.
This is unconscionable and fills me with deep, passionate rage. I can't believe a company followed a nonstandard numbering convention for one of their releases. That's the most evil think I've ever heard and it heralds the downfall of modern society.
The biggest reason why everyone froze their kernels for a major release and back ported was the create what was effectively a driver binary interface. So if a hardware vendor (Yes, I'm looking at you Nvidia) wanted to create a binary driver release for a codebase, that driver release would work for the whole period of support for that codebase. This is because Linux doesn't have a driver ABI.
So getting back to what Novell have done here...It's a hard one, I guess, if they spoke to their ISVs and they said they don't care, then it doesn't matter. If HP / Dell / Lenovo don't care either then, again, that's no problem.
I guess there is always going to be someone out there who hasn't qualified their drivers with Novell for SLES 11 and just does self certification and was expecting their release to keep working (Which was tested against the earlier release) and now has to upgrade their driver because the Linux ABI is a rapidly moving target. On the other hand, a lot of people rely on on Novell / RedHat etc for driver support and don't go back to Dell / HP / Lenovo; if there is problems they point fingers at their Linux vendor first.
Time will tell if this was a good idea or not. Personally, I'm not against it, more hardware support out of the box is better for me, if I run into a problem and have to run older hardware on an older kernel and just upgrade RPMs on my older systems then so be it. I guess that's what versioning in builds is for really isn't it?
Berny
Curiosity was framed; ignorance killed the cat. -- Author unknown
That's funny. I ran a SLES shop for 3 years and for the entire time, I had a request in to Novell to explain the minor numbering for their kernels in an attempt to keep EMC happy with updates. They put it off saying that they were trying to find a Linux Engineer there to explain. For 3 years!! I do not miss Novell. Not one bit.
We're using SLES 11 on production servers with no problems. We decided to jump straight to 11 after getting burned for being 9.4 too long and nobody in the world supports it any more.
As far as VMware Tools support on SLES 11, according to VMWare's official documentation it is:
http://www.vmware.com/pdf/osp_install_guide.pdf start on page 18
"Christ what a design! I could eat a handful of iron filings and PUKE a better emergency pump than that!"
What does this have to do with honesty ?
Red Hat is backporting the stuff their customers are demanding _and_ what they feel confident to support in a production environment _without_ breaking existing setups. That's the goal.
You don't do that by updating your complete kernel for one or two features you like to have. That would be insane.
Red Hat never promised you that 2.6.18-192.el5 has any resemblance or compatibility with the original vanilla 2.6.18. That would make your kernel ancient and not fit for newer hardware.
The whole "backporting is ugly/dishonest" comes from people that have no clue about Enterprise computing or have hidden agendas. A bit of common sense goes a long way...
The current situation is that the backporting policy basically sucks _bigtime_.
It means that new hardware isn't out of the box supported by the 'enterprise distros' and that installing ubuntu with a new kernel is a no-brainer. It also means that - especially in the case of Red Hat, the kernel is so heavily patched, that it can lead to stability problems and introduces 'unusual problems' as opposed to the vanilla kernel.
Backporting things for an old kernel and overly patching the vanilla kernel is basically saying: 'we know it better than the kernel developers'. And, sorry, that simply isn't true!
As someone being heavily involved in Linux Enterprise support since 1998, and thus shaping it too, I can only hope that this is a sign of better things to come and an abandonment of the outdated, stupid and un-enterprise policy which only makes Linux look bad.