Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Ksplice



In my experience, everything that goes into production gets vetted in a test environment first.  That's not just in-house code.  It includes kernel and library updates, middleware updates, configuration changes, literally every change to production goes through testing first.  One never knows what a minor change will do until it is tested.  Ksplice is actually detrimental to patch deployment in this type of environment.  QA will need to run tests against both a stock+Kspliced system and a cleanly booted system with patches installed.  Using Ksplice means doubling the time or resources needed to test and vet a change.

So, at least in my book, the jury isn't out.  The judge threw the case out after the opening arguments.

--Rich P.









BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org