On 1 July 2011 02:06, Brian K. White <brian@aljex.com> wrote:
On 6/30/2011 6:56 PM, Adam Tauno Williams wrote:
On Thu, 2011-06-30 at 18:34 -0400, Brian K. White wrote:
As one who has to maintain a bunch of boxes and has to spend a lot of time devising atomated procedures and training non-admins who never the less have to do adminly stuff because I cannot always be available, every backwards incompatible change, every change in default behavior, every thing that breaks because of little or no testing prior to making it part of the official system costs me lots of time I and my employer and my customers would rather I be spending doing other new stuff rather than just playing keep-up-with-suse just to maintain what I already had.
How does turning off updates on a given box or all boxes adress anything I said? Updates do not cause os version upgrades, and nothing changes too radically within a given version for the life of that version.
For example how does turning off updates address the fact that on a given piece of hardware, it was possible to install 10.3 successfully using only the normal installer onto a fully software raid setup, and have it create a working grub that actually booted and worked, yet on later versions the exact same setup on the exact same hardware didn't work and the only way to get the box running was to jump to another vc or ssh session and manually edit grub files and/or manually create the mdadm arrays before that.
How does turning off updates address the fact that the repair-system and boot-installed-system options disappeared from the installer?
Hey I know those are hard things to do. What's damning is that openSUSE used to do them and now doesn't, or tries but now fails a lot more often. Things like that were part of what made SUSE stand out in the first place.
Then there is the long standing difficulty of using a serial console. Several hard coded assumptions in openSUSE are broken for a serial console but whatever who uses those? So on all my boxes I have to be careful to uninstall and taboo all the gfxboot and splashy stuff before allowing it to boot the first time.
vga=normal which I already had was being ignored and after some googling I find out about the new nomodeset or i915.modeset=0 This is new, active behavior that's on-by-default and broke a box that worked fine on the previous version.
So I start off having sympathy with what you said. But may be you ought to consider, things you can do to minimise the issues, apart from the obvious switching to SLED/SLES for longer term support. But 10.3 was horrible release for me initially, I had huge number of problems to sort and it was months before it became stable & super solid. My honest impression is 12.1 M2 is far more solid & useable than any of the GM releases I've tried; I think things really are getting better & more mature. Requiring redundant features to be on install DVD, when you can use a System Rescue, or build your own Live CD/DVD is not rational. Suggestions * Don't track the latest release on production systems, until they're solid for you. 11.3 works well, actually 11.1 & 11.2 plus Evergreen do to * Use Auto Yast to get rid of the boot gimmicks. Even lilo is still there and useable. * Use Kiwi or SuSE Studio to allow test of hardware with Live DVD before upgrades, similarly repair of systems * Actually read the Release Notes, things like nomodeset=0 are well explained * Software RAID is easy enough to configure, post install, if you plan for it. Given all the testing required to proof against single disk or controller failure, a pro sysadmin ought to cope with building software RAID themselves, it allows installing into a degenerate mirror for example * Don't work on Live Production machines, roll out a new server, then upgrade the old one after the new is "signed off" The possibilities for well tested transitions have never been better. Plan for them by dual booting and try out "zypper dup", with a suitably configured proxy as an installation & update cache it should fly. If you don't want improvements, or problems of early adoption use an old supported release on production and pay for it! If you use a community release in production, it's wise to test things like milestones, so you can point out overlooked downsides in new features and hopefully influence developers before it's too late (adding /usr "hooks" into udev for example). If there weren't changes, then there'd not be a need for skilled sysadmins, so it's in our interest to embrace and enthuse about them! Regards Rob -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org