Would you to the dist-upgrade command in the first week this is released?
Submitted by Nelson_Y on Sun 15 Feb 2009
| Yes, I am confident that this will work perfectly! |
   38% | 832 votes |
| Yes, I will do - but I do not advice you if you are not expert Admininstrator ! |
12% | 276 votes |
| Yes, but only if the software I will use were tested by myself, and I am sure it works ! |
6% | 144 votes |
| No, better wait a couple of days. |
8% | 177 votes |
| No, better wait for some weeks. |
16% | 367 votes |
| No, better reinstall the system from 'zero'. |
7% | 168 votes |
| No, better wait some months. |
4% | 101 votes |
| No, 4.0r6 is stable and will remain 'stable' for at least a year yet. |
5% | 115 votes |
| Total 2183 votes |
Debian seems almost indestructible if you stay with the official packages.
[ Parent ]
The Windows Registry does seem to be a fragile beast, with little reputable documentation on how to fix it safely in the public domain. There are lots of myths and cults surrounding the Registry though...!
I sometimes find that the Windows approach of "reinstall to fix" mentality does seem to be leaking into Linux. Distros popular with new users fleeing from Windows appear to bring this "reinstall to fix" approach with them. A cynic would say it's because it's easier to reinstall than it is to understand the problem and fix it, giving the benefit of the doubt you could say it's not possible to fix on Windows so the user doesn't realise it is probably fixable on Linux.
I must confess that other than messing with my experimental first installs of Debian, I've never needed to reinstall Debian to fix a problem, nor do I reinstall package - unless I've manually screwed up package...
Stable does indeed seem to be bullet-proof and the upgrades do just work.
--
"It's Not Magic, It's Work"
Adam
[ Parent ]
The Windows Registry does seem to be a fragile beastYes, and I wonder if the gconf system isn't following the same path. That's so far from the UNIX style!
[ Parent ]
A binary configuration database or registry isn't such a bad idea, if it's very fast, very robust and easy to use, as long as there is some way of easily maintaining and repairing it. So you can say something like etc-recompile and it rebuilds a binary database for you of all your normal text files in the /etc directory. However it would require that all the applications to be changed to use the new configuration engine - so I doubt it will ever happen.
The problem with the Microsoft registry is that it's unreliable with no easy way to maintain. Also overtime it also gets bloated and slow as it becomes "fragmented". It's probably not a good example of the concept.
--
"It's Not Magic, It's Work"
Adam
[ Parent ]
My worries are about gconf, which is not binary (thus does not gain in speed) and not so easy to maintain, so it reaches none of the objectives that you outlined in your post. Instead I often find it clogged with unused keys inherited from older version of some software, sometimes remnants of the gconf-to-gconf2 transition.
[ Parent ]
[ Parent ]
I dist-upgraded the VMs without much trouble. However, when I did `aptitude upgrade` on the Xen hypervisor it was still holding several packages back. I then foolishly did a dist-upgrade anyway.
I then had a system with a version of Xen that depended heavily on Python 2.4, but also had now upgraded to Python 2.5. In addition, to find out about that problem, I had to roll back to the previous kernel, the newest one with Xen wouldn't even boot (on my Dell PowerEdge 600SC mini-tower).
Finally I had to rescue the whole thing using Knoppix and bare metal restore over the network. This was my dev machine, and I basically had to rsync (over ssh) my matching production machine's OS installation over the network and nuke the mess I had made on my dev dom0. I then restored key files like /etc/fstab, /etc/udev/rules.d/, /etc/hostname, /etc/hosts, and so on.
Amazingly, I got it all working again. If you don't have 100% coverage of every single file in your backups or a matching dom0 installation you can use as the basis of a new installation, I would leave those packages held back and not be as aggressive as I was.
I still love Debian and Xen. The fact that you can do a bare metal restore of an entirely different operating system installation securely from a running server 2500 miles away is a testament to Linux. Still, it's nicer to just run the updates and not have such excitement.
[ Parent ]
[ Parent ]
Thank you to all of those involved with creating such a great distribution, I am thrilled to be a user.
[ Parent ]
[ Send Message | View Utumno's Scratchpad | View Weblogs ]
On my desktop , I haven't reinstalled since early Sarge. dist-upgrade has always worked for me.
[ Parent ]
The upgrade from Etch to Lenny is much simpler and smoother than Sarge to Etch. (That was complicated by the transition from hotplug to udev).
If you're not already running Lenny, I see no reason not to upgrade today. A 22-month development and testing cycle ought to be enough.
[ Parent ]
[ Parent ]
So what you actually did was upgrading from lenny (former testing) to squeeze (current testing). Isn't it?
[ Parent ]
Ahem.
[ Parent ]
Both seem to work on Athlon and i386.
[ Parent ]
[ Parent ]
[ Parent ]
paquin
[ Parent ]
[ Parent ]
[ Parent ]
[ Parent ]
Depends on the bug - but someone does look at each of them and make the decision "live with it", or "fix it", hence the "<Release Name>-ignore" tags.
One has to appreciate that all general purpose operating systems (except perhaps some safety critical ones) release with a lot of "release critical bugs" or equivalent issues.
Lenny has had a substantially lower release critical bug count than Etch since around January 2008, at some point one has to make the call that Lenny is simply better.
Release critical can include non-technical issues, such as failure to comply with DFSG. DFSG issues often occur in all released versions of the same software, Linux being the controversial case. Or issues that affect a package on one architecture.
[ Parent ]
Almost everything came up roses. The only problem I had was with ucarp. Had to tweak some things to get that working again.
[ Parent ]
[ Parent ]
I used before apache 1.3 and php4. It was problem, and some work to use apache2 and php5.
When I upgraded, the installer erased user "spamd" from /etc/passwd, and after the exim4 (with spamassassin) did not start. I had add user "spamd" again manualy.
Anything was nice.
By
Totyi
[ Parent ]
[ Parent ]
[ Parent ]
The only problem I had was my bnx2 network card not working on a Xen host (see http://techblog.procurios.nl/k/news/view/16583/14863/ for my story)
Still, I started the least critical server. Testing our applications first, then working my way up to essential mission critical servers.
[ Parent ]
I had many servers which are still running with the exact same kernel+exact same packages what I configured them with at the first time. For this hobbylinux community here it m8 be hard to understand what production version of OS/Software means. If you don't have _reason_ to change something you won't.
And about my desktop installs, I had the same debian install for 4 years what I just upgraded constantly, then have the same ubuntu install since 3 years.
[ Parent ]
I don't like remote upgrades when I don't at least have a key to the building, or someone who can get in there and be my eyes.
[ Parent ]
Think I'd be pretty confident on workstations and possibly the office servers though
[ Parent ]
Peter
[ Parent ]
[ Parent ]
[ Parent ]
[ Send Message | View Weblogs ]
I upgraded and everything when in okay. I'm happy.
What goes wrong with operating systems that mean that they need periodic reinstalls and upgrades are impossible? At work last week the Windows admins were talking about reinstalling a server because it was broken, what's scary is that pretty much nothing has happened to it in years - it's not as if it has a lot of users or lots of applications being added or removed. How can it go so badly wrong just by running? I know it's not just a Windows problems, lots of Linux users seem to reinstall all the time - why?
--
"It's Not Magic, It's Work"
Adam
[ Parent ]