|
|
Subscribe / Log in / New account

Ksplice and CentOS

Ksplice and CentOS

Posted Jul 27, 2011 13:26 UTC (Wed) by dsommers (subscriber, #55274)
Parent article: Ksplice and CentOS

CentOS is by all means a project with great visions, and they have managed to provide a good distribution. But from the CentOS 6.0 and CentOS 5.6, their updates fell like rocks. It took twice as long for CentOS 5.6 to come out compared to earlier releases, CentOS 6 needed something like 8 months to be released. Now they have to manage to get the 5.7 and 6.1 releases out. This is not a flame invite on their release cycle. This is the hard facts [1].

So how will CentOS be able to provide ksplice updates *in addition* to their pending updates? And especially if they try to provide this for 6.x kernels, where there are no patch-by-patch files to work with.

I honestly believe CentOS should rather focus now on getting their current supported releases updated and improve their working methods to make releases go more smoothly before looking at something like ksplice.

Seriously! ScientificLinux have until now managed to complete there 6.0, 5.6 and 6.1_rc1, with a pending 6.1 release within the coming couple of weeks (or even earlier). CentOS have barely managed to get 6.0 out-the-door, with 5.6 a bit earlier. On their announce-list there is not much CentOS 6 updates by now [2], even though ScientificLinux have had several updates [3].

Unless CentOS manages to improve their update processes, to make them more efficient, I have not faith in CentOS being able to support ksplice in addition. It's a great goal, but I don't believe it's currently possible.

Why so harsh? I consider ksplice a poor-man's cluster solution, for users who don't have a cluster to work with. If you have services which needs to be running 24/7, you don't do that on a single box, you have a cluster where you can boot each node individually in the mean time. And such sites who can afford proper clusters, most likely can afford RHEL or OEL.

ksplice is great for short term highly critical updates, to fix an exploit instantly and to get the proper fixed kernel booted when the maintenance window appears. If CentOS continues to be slow at their kernel updates to start with, there is little benefit of having ksplice to start with. This can be twisted, if CentOS manages to get ksplice updates released quicker than normal kernel updates. But in that case, I would claim their priorities is not really well aligned with the vast majority of their users.

[1] http://en.wikipedia.org/wiki/CentOS#Release_history
[2] http://thread.gmane.org/gmane.linux.centos.announce/
[3] http://listserv.fnal.gov/scripts/wa.exe?A1=ind1107&L=... (Look for SL6.x subjects)


to post comments

Ksplice and CentOS

Posted Jul 29, 2011 2:25 UTC (Fri) by sciurus (guest, #58832) [Link] (1 responses)

In fairness to CentOS, despite the problems they certainly have they got version 5.6 out the door much sooner than Scientific Linux did. Prioritizing it over version 6.0 was the right choice.

http://www.standalone-sysadmin.com/~matt/centos-sl-delays...

Ksplice and CentOS

Posted Jul 29, 2011 13:08 UTC (Fri) by dag- (guest, #30207) [Link]

Still you cannot claim that 3 months without security updates is a splendid achievement. So the original commenter is correct in the assessment that there's more merit in improving the release of security updates than forking new exciting projects. Timely security updates affect more users than a working ksplice (as that's only kernel related).

Unfortunately, CentOS makes it quite obvious that they don't plan to open up the CentOS rebuild effort, so we officially don't know what caused the 5.6 release to slip 3 months, or the 6.0 release to be 8 months behind. (QA had been waiting for several weeks before anything was there to QA, and even then known fixes were slow to materialize).

http://lists.centos.org/pipermail/centos/2011-May/111670....

Having only 3 people know how to do and perform this rebuild effort is a liability, not just for getting security releases out the door.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds