Slashdot Mirror
Kernel 2.2.12
DrunkenBastard writes "I just noticed that a 2.2.12 kernel was starting to appear on the kernel.org mirror I usually frequent.
" When I saw this submission, the first thing I thought was "And me with my 38 day uptime". That confirms it. I gotta go out ;)
2.2.12
uptime 10:49 hours:minutes
Only 'flamers' flame!
You should test all of your procedures regularly. This includes reading backup tapes, restoring from backup, and yes, gaaaaasp, rebooting the system. You really don't want to find out that you've got the order of things wrong in /etc/rc.d/rc3.d at 3 am, or peak load on friday. Murphy happens. Things get bit rot. Un-accessed sectors go bad. Firewall changes do things that suprise you (happend to me).
Ok, I know this is blastphemy, but you really should reboot your systems at some regular interval unless there have been *no* system changes.
I guess on a *really* static system you could get away by bringing it down to level 1, fscking, and bringing it back up, but why not just be safe and verify that everything comes up even after all the electrons get drained out.
Fire away...
-- cary
I'm an administrator running a Samba network (Linux server running as PDC) serving over 100 NT clients. We tell them not to reboot. However, after about a week or a week and a half of uptime, most of them have to be rebooted anyway because of strange errors and BSOD's. I'd say at least one or two of them BSOD's a day out of them.
These are Dell machines with all the "right" hardware in them.
Well, dialup services don't take all that much cpu out of the system.
We've got a squid proxy server that's been up for 80+ days, that's rebooted because of power problems. That server gets a lot more traffic, but I liked the higher number on this one, "for effect" or something like that.
Here it is. Our squid proxy server:
Allie:/home/edgy# uptime
9:56am up 91 days, 23 min, 8 users, load average: 2.09, 1.78, 1.72
I don't know who this is, but I have been checking the kernel list archives, and there's no mention of anything like this.
Linux isn't about vaporware, like some software companies.
I think it's 49.7 days.
-matt
I'll ignore that, other than to say I think you are too much in touch with your j key. Given the rest of your post, I can only wonder what you're doing with it.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Believe it or not, 2.2.12 seems to be one of the most stable kernels out of the 2.2.x series I've seen. Just about every single other one has had various problems, from TCP/IP memory leaks, to data corruption, to other problems.
:-)
Even the high load server we're running here that had some network flakiness was fixed when we upgraded to 2.2.12 (in hopes that this would fix these problems). It did. We're lucky.
Linux rulez, d00d! My system uptime is now almost 1000 days!
Cheers,
ZicoKnows@hotmail.com
As far as NT running and running and Linux crashing, you are not providing any evidence of your situation or any real information. You can make up anything to suit your argument.
On to the second point. Let me put this so you can understand it, AN APPLICATION SHOULD NOT BE ABLE TO CRASH THE OPERATING SYSTEM. If Windows were any good, there would be no way to crash the operating system from an application.
Funny, you have a Beta 3 machine? What applications can you run on it, anyway? I thought they threw code portability away anyway. It's probably just sitting there looking all pretty.
There are lots of security patches for Red Hat, but none that allow someone from a web page to modify your startup files using ActiveX.
Additionally, with Red Hat, you get the fixes much more often, and earlier. No need to wait 6 months for the next service pack. Also, these patches only affect certain services. If you run a tight ship, and only enable important services on the system, you don't even have to apply most of them.
And the last one is the kicker. Now you're blaming it on development environments. Well, we're getting them for Linux. So we'll be able to invalidate that argument pretty quickly.
The fact is, there are a lot of buggy Linux applications that I've seen, but none of them have brought down the system. You obviously don't know what you're talking about.
We would do that, except if they reboot every night, sometimes certain services don't start up properly. As I recall, the netlogon service wouldn't always start up reliably, so we just gave up on it, and have the people reboot as rarely as possible.
That won't be true of everyone, though. There might very well be stuff in the patch-2.1.12 file that Alan Cox missed out of his patch series, or fixes which work slightly better than the ones AC collected. For such people, I can see some value in moving to 2.2.12, especially if they don't need any of the supplementary kernel patches that I gratuitously throw in for good measure.
But I would caution, as others have, against upgrade fever. I used to suffer from this, and still have over 2 gigabytes of software upgrades I've never gotten round to installing. Many of those upgrades are probably now out-of-date, themselves. It's an exercise in futility and it's only reward for me has been frustration. I've started getting into the habit of only upgrading what I need, plus supplementary packages, libraries, interpreters and compilers. It's made my life a lot easier.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
You cannot connect linux uptime with slashdot uptime. There are many things other than the base operating system that could be causing problems.
Heck, we've got Rob's perl scripts, mysql, apache, and a multitude of other programs I'm sure.
What the NT bigots don't mention is that it's impossible to get Windows NT to do what slashdot does on the same scale out of the box, at least.
Windows makes the easy things easy. Unix makes the hard things possible.
The reason for the near hypocrisy when NT-run sites are down vs. UNIX-run sites that are down is that OS users are bigots (most of them anyway) and maintain that their OS of choice is the best in the world, half the time without really ever using anything else or having any real world experience to know what else is out there. I must agree that there are complete idiots out there who fancy themselves administrators of computing systems just because they have that level of privelege at the login screen of WinNT.
I administer both systems and while my slant is towards UNIX, we have NT servers in 6 buildings that do not crash and have, in some cases, over a year of uptime. Now granted, all they are doing is file serving and DHCP so its not exactly a sweeping stability victory for NT to say it doesn't crash on these boxes. But the secret is hardware, at least in my experience. If you buy decent hardware that is certified to work with NT, it greatly improves the stability of the OS.
Now the email server that runs on NT (Netscape Messaging Server) - thats a different story. It was done before my time but its definitely entropy in action.
My motto has always been to use what does the job best for you. For some, that may mean using NT. They will sacrifice some stability and scaleability for the (sic) "ease" of use and stupid wizards (my own bias slips through..). For others, a UNIX system does the job best. Though graphics may never see the light of day on my DNS server, I wouldn't trade BIND and the command line on it for anything NT has to offer.
KmArT
Better yet use downtime and figure it in percentages rather than time since last reboot. It'll keep you honest and not desperately grasping for 100, 1000 or 10000 days ;-> uptime.
Those who like Katz's postings, please don't flame me. I like 80% of them myself.
---
Stephen L. Palmer
http://midearth.org
Just another BOFH.
"When I saw this submission, the first thing I thought was "And me with my 38 day uptime". That confirms it. I gotta go out ;)" Sure, 2.2.12 might be out, but do you *really* need to upgrade to it? This revision might not even fix/update anything that you use. Recompiling your kernel just because a new version came out is like warez'n'hackz kiddies making sure they always have the latest 0-day. I mean, I see alot of people who just recompile simply so they get a new spiffy version number. Well, if you ask me, it's a sad addiction to recompile if the changelog doesn't effect you. It's sad to see /. promoting such behaviour with comments as quoted above.
Well, there is a significant difference between scheduled downtime and downtime.
With scheduled downtime, users are notified of the impending change, and can prepare for it, and stop using the system for the few minutes that it's down.
Unscheduled downtime, on the other hand, as with crashes of the server operating system, makes people lose work, and can last for a long time, since the administrators may be nowhere near the system.
So, I think even from a user standpoint, scheduled downtime is much more acceptable.
Heh. Heh.
Uptime on a dialup SERVER being used quite extensively here:
$ uptime
6:12am up 145 days, 9:48, 3 users, load average: 0.00, 0.00, 0.00
{grin}
You are so full of it.
If Windows NT requires an administrator that REALLY knows what they're doing in order to get a stable system, then why bother using NT, when you can get a stable Linux box without all of that? With Linux, you at least have a lot more flexibility.
I don't get it anymore. First, the NT apologists say that NT is easy enough for anyone to administer. Then they excuse NT's instability by saying you need an expert administrator to have a stable system. So, which is it?
Linux is probably the easiest way to get a stable system.
Uhm, isn't it good practice to always wait a while before upgrading kernels?
Features and optimizations are not just thrown in there. I think it has something to do with the extensive testing you get when you release a kernel, versus when you just get to test it.
You should always wait before upgrading a server box.
Actually, there are now release notes written by Alan Cox for every stable kernel release. You can go see the Release notes over where Alan's written them. I rather like this, saves waiting for Myrdraal.
If we didn't know the guy using winders as a server that crashes every 3 or 4 days. Or our mom and pop using windows asking you to fix AOL becuase it crashed windows, again!, we wouldn't be stuck up on uptimes. Blame it on windows you must brag about up times!!! And when you see a winders users yell at them and tell them:
"It is becuase of people like you that use a crappy os that I feel the need to take pride in how long my computer is up without a reboot!! DAMN YOU!!! DAMN YOU TO HELL!!"
And start flinging brunt copy of linux at them. Aim for the eyes or head, it hurts more. Then sit down, chill, and run "top" and watch your uptime go up and be happy that you don't have to reboot to change the ip on your nic!!!
MarNuke
Sound like too much work to me. I'm speculating that 90% of the users would be just as happy if someone wrote a utility to set the uptime and produced a website carefully detailing why "setting your uptime after installing a new kernel should not be considered cheating".
So you want online kernel upgrades? Sounds like something we do with our systems at work: At EMC, we will upgrade the OS that runs inside our storage systems while the system is online and processing I/Os. (I haven't worked on the code that does the online upgrades, however.)
It's not easy to do, but it can be done.
The tricky part is not the replacing of the kernel code with new code, but migrating between changed data structures at the same time. In theory, you could do it with the facilities in place now:
1) Build the new kernel.
2) Build a program that understands all the differences in kernel data structures.
3) Load the new kernel into memory, but at a different address from the running kernel.
4) Load the translation program as a loadable module--it will need to do several steps:
a) suspend interrupts
b) translate the data strucutres
c) relocate the new kernel to the proper place in memory (possibly using VM tricks)
d) enable interrupts
e) clean up any junk from the old kernel that is no longer in use
f) transfer control to the new kernel
5) Unload the upgrade program
That would be a pain to code, but in theory is possible. For most applications, though, rebooting is acceptable. I doubt that anyone will code online kernel upgrades anytime soon.
I believe the figure of uptime is how well computers can do when on for long periods of time. When you reboot you reinitialize the state of the hardware as well as software so any problems like memory leakage, fs corruption, etc stops when you reboot.
If you can keep your computer on for long periods of time without rebooting not only means you have a good OS it may also show the skill of the administrator. Not to say you are a bad administrator when you reboot.
The problem with using uptime as a bragging right is that it is not much to brag about when we talk about workstations. It is important to upgrade the hardware and kernels of workstations so reboots may be frequent depending on the type of user. For "static" mission critical severs uptime is a very important figure that is worth bragging about. If your server does a very limited set of functions day-in and day-out you want to keep you computers up as long as possible.