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.
(a) Turn off updates; just apply them at maintenance windows. There really is no need to "keep up" if things are working well. Test and deploy, don't deploy-as-test.
(b) As someone who primarily admins CentOS [the most boring distro ever] and Windows servers.... get over it. This will *always* be true to some extent. Systems change, you need to adapt to those changes.
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. And I had fun the other day when a new box crashed during boot every time until I discovered the wonderful new KMS trying to touch my video card that doesn't even have anything connected to it. 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. Of course everyone wants their video card diddled with early in the boot process, of course it should be in there by default unless you go out of your way to disable it. And then once booted, as has been the case since I don't know when but at least 10.0, (I have older boxes, I just wasn't using serial consoles then) something somewhere in bashrc keeps going out of it's way to make a bonehead assumption about the size of my screen based on the value of $TERM and the tty device name!!! So, certain yast screens are actually broken, missing buttons and controls and displays because LINES & COLUMNS keeps getting set to 80x24 when those screens need at least that missing 25th line, let alone the fact that I'm usually on a 132x50 terminal. Not only should such assumptions never be made, they certainly shouldn't be overridden if I manually SET them. Even when I set them and readonly them, still some things are broken. Sometimes my terminals window size gets set to 80x25 by some ansi codes and I have to reset the terminal to clear that, even while LINES & COLUMNS are readonly set to 132x50. It's so stupid that I have to fight against that while I'm trying to deal with some sort of emergency that required me to use the console at all, and forget trying to explain this to any other employees. "if the array doesn't start up because of a crash or power loss, here's how you access the console ... oh yeah it always does that ahh there's not really a fix you just have to ignore that junk and try to navigate the garbled screen anyways... " Completely professional. -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org