<br><br><div class="gmail_quote">On Fri, Jul 1, 2011 at 10:28 AM, James Sumners <span dir="ltr"><<a href="mailto:james.sumners@gmail.com">james.sumners@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
I disagree with the assertion that stability comes with the cost of<br>
doing a fresh install every release. I've been upgrading Debian<br>
release-to-release since Slink with not one single stability problem.<br>
Of course there is planning involved and things change drastically.<br>
But that's why the upgrade process includes notices and prompts with<br>
diff access. You still have to do your homework, but you don't have to<br>
pretend it's 1975.<br>
<br clear="all"></blockquote><div>I have found the stability to be more related to the admin sanity than the OS :-) If I have a known baseline that works BEFORE I transition my old application, I know that after the transition the errors are because of the application and not the underlying OS.<br>
<br>I have a system I upgraded from fedora release to fedora release. The only bare install was when the system was brand new. What I learned from doing that process is :<br><br>1. eventually config files MUST be changed to match the new reality of an upgraded binary<br>
2. all upgrades require _work_. <br>3. compared to the RHEL/CEntOS system I also ran, the rolling upgrades cost me more time over the life of the machine in upgrade work than the similar lifespan of a RHEL machine with a major upgrade (I did several RHEL5>RHEL5 transitions.).<br>
<br></div></div>Stability is not guaranteed with a fresh install on a major upgrade. What does happen is a decrease in the number of variables the admin must consider when any system change causes instability. Additionally, a new installation affords a fallback option in the event of a failure event after the migration. That is a stability issue not of application but of service.<br>
<br>Additionally, from a professional admin standpoint, I find it to be bad practice to be upgrading a production system to a new set of libs. By definition, a production system is not eligible for an upgrade. It is only allowed security and bug fix patches. To perform an OS upgrade is to change a production system into a test system which must then pass QA before becoming. So from that standpoint, it doesn't matter if a particular OS support rolling upgrades or not, the professional admin best practices are to put new code on new system, test, QA, promote to production, verify again and then roll old production machine to test status for the next cycle.<br>
-- <br>-- <br>James P. Kinney III<br><br>As long as the general population is passive, apathetic, diverted to
consumerism or hatred of the vulnerable, then the powerful can do as
they please, and those who survive will be left to contemplate the
outcome.<br>- <i><i><i><i>2011 Noam Chomsky<br><br><a href="http://heretothereideas.blogspot.com/" target="_blank">http://heretothereideas.blogspot.com/</a><br></i></i></i></i><br>