thanks for your post and i hope i'm not being a pest, but while i know that the old_linux is something that it does create during an upgrade, can i count on that if i say put 9.1 (maybe a fresh install, thanks!) onto my 9.2 box and use a completely different area for /usr (but keep /home).

your approach is pretty much what i had in mind, i just hope 9.1 is going to be worth it as right now i'm craving the best of both worlds and i'll settle for a stable 9.1 with my limited budget. incidentally, is the 9.1 offered on mandrakes download page the full 9.1 or just a download version similiar to rc2.

http://www.mandrakelinux.com/en/ftp.php3

(oops looks like they just changed the 9.1 to 9.2 effective today, who knows maybe i've lucked out with the 9.1 i d/l'ed yesterday)

my best guess is that it might be a limited version like you found with rc2 (as in not being able to add packages).

just curious

thanks again

- perry
ps.
i found a wicked ftp site mandrake 9.x (including 9.1), slackware + others and even "corporate" packages

http://raven.cslab.vt.edu

Well the problems are pretty weird. It seems to be all over the place. Remember that those rc releases are not the real thing.

It will put the old-linux in there when you upgrade but I'm not sure if you downgrade. It may though since it is installing something it sees as different. Heck I just did a reinstall once to correct a boo boo I made, long story, and it put a entry then too. It may very well do it.

I never had 9.0 so I don't know what the difference is. I'm sure that 9.1 is better and that 9.2, the final version, will be better too.

Hopefully the 9.2 will be out soon. Right now you have to be a club member to get it I think.

Later

I'd like to see all the linux, windows, vmware, youNameIt servers post their linux uptime at www.linuxuptime.com

It would be cool to see who's server has been up the longest.

it's not cool to have a huge uptime, because an occacional reboot, is needed to make sure everything is still working as it should (even after booting).

I can't see Slackware in the poll on that website.

Why? You can see if everything is working as intended without rebooting, I would think.
But nonetheless, rebooting is needed, when the kernel is updated. Not rebooting means running an insecure kernel.

Not always, sometimes the processes are already running, and won't be restarted upon updating the system. Only on the next boot it will occure. (e.g. some libs are in use etc)

That too, but many people are reluctant to reboot inmediately after upgrading the kernel.. because it takes time to reboot etc etc.. And than forget all about it for days/months (if not turning of the system that is, e.g. colocation box).

conclusion: the more updates you did receive, over time, without rebooting in between, makes it more prone to reboot failures and hefty difficulty tackling the source of the problem (e.g. identifying the wrong update etc).
In an enterprise environment, servers are rebooted every now and then, to make sure everything runs as expected.
This also happends with backups: there are occasionally checks, with a backup restore simulation, to see if things works as expected.

It's there now.

High time. A distro poll without Slackware is no poll at all. LOL

This is not really accurate. All you have to do if you update a service is restart that service. That way it will reload anything new. I run Gentoo and I do that all the time. I once had a 242 day uptime and I updated almost everything on the system, except the kernel, with no problem. That includes services like dbus, cups, and no telling what else. If it is a GUI thing, at most, log out and log back in again. No need to reboot. This is Linux, not windoze.

for soho usage, it's less of a problem, no rebooting that is, compared to servers in the enterprise world.

If a person updates cups, dbus or similar, it doesn't matter if it is a soho or a server, just restart cups, dbus or whatever service was updated. The only exception is apache or some web server but even that doesn't require a reboot but does require you to be more precise as to timing.

If you are not able to restart a service because it would cause some sort of a outage or something, hold off on the update until you can restart it.

Basically, the only thing that requires a reboot is the kernel. And actually, enterprise servers are rebooted less than soho systems anyway. They may patch security problems but they have a lot less down time.

i did not say you NEED to reboot at all, i only said it's wise not to let the server uptime go too long without rebooting. (e.g. a year or longer even)

There are plenty of servers that have ran for years, some several years. With Linux, there is no reason to reboot unless you are booting a new kernel. If it is so wise, why do admins of servers let theirs run for years with no reboots? I'm sure the admins of those systems understand that there is no reason to do so unless they update the kernel or have a hardware issue to resolve.

My longest uptime was about 730 days (2 x 365 days and a few extra days.) I know that I had seen UPTIME at a terrifically high figure of around 700 days and then it suddenly changed to a low number of days, causing me to think that it had rebooted or compromised, when in fact it had not.

It is an interesting story, read further if you are interested ..... I can say these were my servers because I was the Unix Admin and it was my job to look after and manage the Linux Servers we had protecting the front end. I was working for a company that provided Application Hosting.

These servers were configured with TripWire and a few other logging programs that were the buzz at that time, I might have received a messaged to say that the up time had changed from about 730+ days to only a few days of uptime. So I assumed that the Machine had rebooted itself or had been compromised and rebooted and so because they were were Front Facing servers and I could see no signs of damage, so I called Red Hat Pro support which we paid a subscription fee for.

We were running a very early version of RedHat (2001 or 2002) and that version perhaps Version 5, 6 or 7 had a bug in it whereby the uptime could only count up to 2 Years (730 Days) and then it started recounting from 1 again, causing me to think that it had been reboot or compromised.

So 700 + days is the most I have seen, though we had many servers which had run for 100's of days.

I think that 700 days is pretty good for such an early version of Linux about 10 years ago.