Nick Holland schrieb:
There are a lot of measures to how the upgrade process works out. Here are SOME: 1) Frequency (i.e., how often do you need to do upgrades) 2) Difficulty (how much human work is involved) 3) Ugency (when an upgrade is needed, how important is it that it is done *NOW*) 4) Downtime (when you do the upgrade, do you need to do it at 3:00am, or can you do it during production hours?) 5) Flexibility (what cute tricks can you do to make the process simpler, safer, easier, etc.)
I agree. Furthermore, one has to distinguish between upgrades of an entire OS release level and patching a running system. The latter is not an issue here since any OS needs patching all the time. Well, they may differ in frequency etc. again, but the differences are negligible.
Yes, OpenBSD had new releases every six months, and only supports a previous release with patches for one past release, so your frequency is going to be higher. So, at the outside, you are looking at an upgrade
Ok, that is the key issue here. Upgrading a firewall which has not much software installed at all, which even runs in a HA environemnt etc. is really not a big thing.
But think of applications servers that run all weired kind of things ... it is a nightmare to upgrade those every half a year (not speaking of *patching* - only saying that since some posts seem to treat patching and OS upgrade similarly).
Anyway...look at the whole picture, not just how often you have to do upgrades. Remember: there are reasons we don't support old releases very long -- in addition to the work required, there is the fundemental "moving forward" philosophy of OpenBSD. With every release, they try to make the OS more secure and more correct. Not only does pushing stuff back to old releases take time and effort, but some stuff just won't go easily. The malloc(3) upgrades were a huge improvement to security, but pushing them back to 3.6 or before isn't going to happen. We don't want you to think that because you run 3.5-stable, that you are as safe or as reliable as you are if you are running -current.
For those application server beasts mentioned earlier one is not necessarily interested in getting 'new features', even if they made the system more secure. I would not even expect backporting - just deliver patches for security relevant issues, so that one can keep the system running for 2-3 years.
Lifecycle has to be part of your planning -- if you can push off a "problem" for two years, you may just hope it isn't your problem then and never deal with it. If you know that every six months to a year you should upgrade, and put that into your planning now, overall your life will be easier.
Hm. In my case it will be definitely *my* problem and I can now choose how often I would like to have it ;)
One main reason why companies are interested in 'enterprise products' of vendors like Redhat and SuSE etc. is the five (!) year lifecycle (at least with SuSE, don't know with RH). That means you buy your hardware, install the OS, patch five years and toss the systems afterwards. That keeps TCO pretty low compared to a (technically much better) system that I need to reinstall/upgrade 10 times during that period, don't you think?
There is one thing I still don't understand. What effort is it to deliver patches (not backports) longer than just a few month - given that the overall amount of patches per release is low with OpenBSD anyway... let's say you have four security relevant patches per release, then you had 20 in 2.5 years ...
Well, I am not a programmer, therefore I may not see the effort. Thanks for your comments! -- Stephan A. Rickauer ---------------------------- Institut f|r Neuroinformatik Universitdt / ETH Z|rich Winterthurerstriasse 190 CH-8057 Z|rich Tel: +41 44 635 30 50 Sek: +41 44 635 30 52 Fax: +41 44 635 30 53 http://www.ini.ethz.ch ----------------------------
