Latest response

Ksplice recently has been bought out by Oracle.  Oracle has mention that it will not support Red Hat Debian or Suse.  Will Red Hat offer there own version of ksplice?  Will Red Hat support ksplice once it is installed on Red Hat linux?


Thanks in Advance!




Red Hat is continuing to evaluate ksplice and other means to provide a live patching solution. Red Hat has not yet validated a scaleable support infrastructure for such a solution. This is ongoing - stay tuned...



Red Hat, Inc.

Beauty of companies buying up things like MySql, PostGres, Java and Ksplice are that, the worst they can do is change the licensing terms of future code-releases. All release prior to that license change remain subject to the old licensing model. So, it's easy enough for the community to fork the code and keep the fork under open licensing. Given the hostility of Oracle with regard to intellectual property and OpenSource, and the value of the OpenSource products they've been acuqiring, Oracle's caused a number of things to fork. Ksplice reasonably should be one of them.

However Oracle now owns the Ksplice patents. That is not something the community can fork.



And that's where it gets interesting. While patents define who retains the rights to sell a given piece of intellectual property, the license determines under what terms those "sales" are made. Licenses, unless specifically defined otherwise, are in perpetuity. While you can change the licensing moving forward, you can't retroactively change the terms of the licensing. The existing code base - and associated "concepts" - was released under an open license. Oracle would have a difficult time trying to put the genie back in the bottle through litigation, particularly if such litigation were ever undertaken against an entity with sufficiently deep pockets (e.g. GOOG or IBM) or such an entity decided to join the fight. Given the nature of such a capability, it's reasonable to expect that a deep-pocketed entity would attempt to find a way to ensure their own ability to make use of the capability (by litigating to keep existing licensing meaningfully valid).

This topic has been quiet for a long time now, has there been any movement?  

Chuck, my original comment above still holds today - there are still outstanding business issues, but also significant technical and supportability risks if this was included today.


Unfortunately, there's no easy answer here since there are many things that would need to be resolved in order for this to be included.



Red Hat, Inc.



Not to continue hounding you on this topic, but do you think that in the foreseeable future (i.e. within the next few years) we're likely to see this functionality introduced by RHEL? I realize the significant effort involved in implementing such functionality, but in high-availability, business critical computing environments, if an enterprise has any desire to maintain their systems and keep current with patches, a solution like this is desperately needed. Granted there's the option of failing over, patching, failing over, patching and on and on, but given the frequency with which kernel updates are released, the old system of failover/patch/reboot is simply not a sustainable model.


Do you have any suggestions for a better patching solution to be employed in enterprise environments in the absence of a tool like Ksplice?


What sort of best practices do you and others employ for patching your systems?

Jeremy, this isn't hounding at all - many of our customers have the same question, and hopefully they are looking at this thread for more information.


As you probably already know, Red Hat has been aware of Ksplice technology for some time.  We have also received inquiries about not only the availability of Ksplice for RHEL, but also concerns about the maturity, security, and support of the technology, as well as concern over creating a fork from the mainstream Linux kernel.  Overall, Ksplice is still in an early state with respect to its acceptance within the upstream community.  Furthermore, while Ksplice certainly demonstrates a technical feasibility, most customers we support do not undertake patching live operating systems – especially the kernel.


In terms of live system patching, we don't recommend an alternative to Ksplice because live splicing of patches is not an approach we suggest taking today.  Red Hat monitors many projects, and we will continue to monitor this technology area (including Ksplice) as we would for any other community-supported project.  When these projects (including Ksplice) reach a level of maturity that we believe warrants inclusion into the RHEL distribution, we'll consider it.  Unfortunately, it's always impossible to predict if that process will take six months, or six years.  Industry best practices for patching vary, but they generally include robust roll-out procedures that adhere to rigorous upfront testing, strictly managed upgrade timeframes, and even testing new software within a production mirror environment prior to rollout.


I hope this helps a bit more than my previous posts. :-)





Red Hat, Inc.

Anyone already has some experience using the 30days trial of ksplice for RHEL5&6?



(it also doesn't mention you can stay on RHEL5&6 after the trial, hmmm....)