Slashdot Mirror
Linux Kernel 2.2.14
So everyone and their unkle wrote in to tell us that Linux 2.2.14 has officially been released. If your uptime isn't to sacred to ya, it may be worth upgrading. You know where to get the good stuff if ya need it.
← Back to Stories (view on slashdot.org)
Two ways:
/usr/src/linux
/usr/src (or wherever your patches are)
/usr/src/linux/scripts/patch-kernel to apply all patches in the current directory)
cd into
patch -p1 (for both two patches)
or, easier and automated:
cd into
us.kernel.org doesn't have it, but tux.org does. It's a 1.3 meg patch.
---
Another non-functioning site was "uncertainty.microsoft.com." The purpose of that site was not known. -- MSNBC 10-26-1999 on MS crack
--
# Canmephians for a better Linux Kernel
$Stalag99{"URL"}="http://stalag99.net";
I've said it before, and I'll say it again; what we need in order to put a stop to this whole stupid argument for all time is a writeable /proc/uptime.
Let people fudge their damn uptime and all the BS will stop.
When it comes to the experimental patches, everything depend on the hardware you have. I've been running v2.3.xx kernels on my trustworthy IBM PS/2 9556slc2 (SCSI) without troubles (apart from having to patch the ibmmca.c scsi-driver in an ugly way) whatsoever, others report lots of trouble.
v2.3 is good, no doubt about that; lots of new interesting stuff, but it isn't feature-complete; lots of stuff that works in v2.2 is broken for v2.3, such as some of the filesystems, etc (but as long as ext2 and fat works, I'm all happy), and the pre-patches are sometimes hard to get to compile.
Finally, more often than not, at least some platform is broken. Sparc seem to have had most problems, but they were fixed up just a while ago, if I'm not all wrong.
If you have important data on your disk or need 24/7 uptime, use v2.2.14. If you don't fall into any of those categories, and have any hardware not supported in v2.2.xx, try out v2.3; it'll be a nice experience, and we need all the bug- testers we can find.
Good luck!
What you should remember is, that if you suspect file-corruption, please send a bug-report and a careful description (hardware, kernel-version, etc.) to linux-kernel@vger.rutgers.edu. More often than not, such reports can be of great help to us when we try to find bugs. This of course applies to other kernel-related bugs too (hangs, etc.)
Remember that the stream of mail to most kernel- hackers is huge, so if you just send them personal mail, simply procmail it away. You never know for sure. Always send to linux-kernel@vger.rutgers.edu (My, this must be the 3rd or 4th time I write that eddy here on Slashdot today...) as well. Others may be experiencing the same problems.
Remember, without bug-reports we don't know about the bugs...
The changelist will be appearing here at some point in the future.
:)
Hopefully soon
æeee!
The kernel is so out of date that any random script kiddie can grab an exploit or buffer overflow from bugtraq and root the system, obviously not a Good Thing if your computer is running any sort of critical task.
I think you missed something important. remote and local exploits come from userland programs. bind, pop3d, etc. The kernel might have DOS problems, but AKAIK there are no remote root exploits for the linux kernel itself.
Christopher McCrory "The guy that keeps the servers running" chrismcc@gmail.com http://www.pricegrabber.com
Yes, NFS is better in 2.2.14. That's why I am running 2.2.14pre14 on our production boxes - I rely on NFS much.
From what I have read, 2.2.13 fixed all that pretty well.
I haven't followed up on that recently though, so I may be wrong..
Blessed are the pessimists, for they have made backups.
2.2.13 had odd IDE corruption issues. I like having to not worry about my IDE drive corruptioning itself...
:-)
On another note, they also made the memory buffer hash table more efficient. I also like speed
---
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
It's called respect. I have a very high amount of respect for Rob, and others like him. The very simple fact that many geeks today aren't able to find suitable role-models in their everyday lives will lend this argument even more credibility. I will accept, to a certain extent, Rob's posts to be pretty authoratative. I've read /. for years, and am able to honestly say that I agree w/ pretty much everything the guy posts. Is it so bad that I happen to share roughly the same opinions w/ someone who is substantially more noteworthy than myself? It's not always about being a follower, you know...
-Will the Chill
Creator of RPerl, Scouter, Juggler, Mormon, Perl Monger, Serial Entrepreneur, Aspiring Astrophysicist, Community Organiz
-Superiority of an operating system
-Ability to administer a computer
-Programing skill
-"Eliteness/coolness"
Let us take this point by point:
Superiority - You are correct. I've had Windows NT and even 95 boxes up for months at a time.
Administration ability - depends on the circumstances. I have a colocated web server that I have been working on quite heavily since I installed it, and I haven't been within 30 miles of it since it was turned on 50 days ago. Uptime is currently at 50 days.
Programming skill - has nothing to do with uptime
Eliteness/coolness - while not quite the same thing, I am very close to closing a business deal with someone that I have been trying to get to sign on with me for months. In the end, it was the uptime that mattered. Or, more specifically, the fact that the machine didn't flinch during a live load test (real content, real users, no simulations) with this person present. The uptime is like a victory -- you can point to it frequently, and then show someone your logs to prove that your machine can do what you say.
Uptime == bragging rights in some circumstances.
Ok, I admit, I submitted. It could be the fact that I'm from Holland (nope, not Michigan, just that little country somewhere in europe where they wear wooden shoes and eat tulips ;) and I don't understand the expression. ;)
AFAIK my uncle doesn't even know where the powerswich of his son's computer is, so I don't think he submitted a post about a new kernel
--
If code was hard to write, it should be hard to read
How many Linux kernel bugs have there been that allowed users to gain root access? How many were fixed between 2.2.13 and 2.2.14?
:)
Some high-availability (am I using the right term there?) systems actually have uptime requirements (such as "we can only be offline for ten minutes every month") that make it risky to upgrade with every new kernel. Particularly since new kernels can introduce new bugs.
My point is that it can be irresponsible to upgrade without knowing what the upgrade does, just as it can be irresponsible to not upgrade.
All that aside, not everyone is running mission critical servers. Some people use their computers for fun, and long uptimes can be a source of amusement.
I personally have two systems with long uptimes, and I will not be upgrading them. They're non-critical systems, and not worth messing with. Besides, I like to see how long it's been since the last power failure.
I remember Alan saying at one point that he was considering adding the current ext3 sources into the kernel. Anyone know if he's done this yet, or will that be going into the 2.3 tree?
On the other hand, for a visible machine with a static IP address, hosting web pages or other advertised services, you have to keep ahead of the script kiddies. But not all machines are in that category, far from it.
Have a look at IBM's homepage and search around for some information on them. They have BANDWIDTH.
This is at least cool, if nothing else. Now if just anyone could port Linux to VAX, things would be chilling.
Now that win2000 is supposedly comming out, and it supposedly needs fewer reboots, Linux uptime counters are going to have much more competition. Therefore, I call for hot-swapable kernels! I do not want to stop what I am doing, just to upgrade (or down-grade) my operating system! I want an uptime measured in decades!
Old kernels are still important, for several reasons:
1) they are well tested
2) the C library for that kernel is well tested
3) the programs for that library are well tested
the importance of this can't be overemphasized. There are a lot of situations where it's much more important to work with a known quantity than to get the ultimate bit of performance or flexibility.
It's worth noting that one of the most damning complaints against Microsoft as an "enterprise class" OS & application suite is the fact that they have repeatedly demonstrated a cavalier attitude towards making big changes in a way that forces users to upgrade everything to fix a single bug in the kernel (e.g., Win95->Win98) or application (e.g., Office file formats).
That's why Linux, and all real enterprise-ready OSes, allow fairly independent maintenance paths for all major versions of the kernels/libraries/applications. It's a bit more work for the developer, but it's criticial when you're talking about systems which *must* remain up. (E.g., if a hospital's systems go down due to an unexpected bug in an upgraded OS, patients may die. If an airline's systems go down due to an unexpected bug, they can lose millions of dollars in lost bookings and contractual penalties for delays.)
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
I wouldn't be able to get anywhere near it. It would be /.'d to capacity. A total of maybe a foot difference between the height of the bridge and the pile of geeks next to it.
Visit me on #weirdness on the Galaxynet.
FYI - if you want the changelog for 2.2.14, just look at the last 2.2.pre14 kernel changelogs. Linuxtoday has a copy here:
http://linuxtoday.com/story.php3?sn=14481
It is a fairly long list of things. The S/390 port is there. Some nice-sounding bugfixes are there, so I'll probably recompile tonight. Also, supposedly it should now compile fine with gcc 2.95.
Off course not all systems run under the same conditions; windows computers are probably more often turned off at night than VMS systems, SunOS is usually used on high-end hardware while Linux often runs on crappy hardware and OpenBSD-systems probably have better admins than Linux-systems (no offense, but most unix-newbies tend to use Linux, not *BSD). But still I dare say that the uptime is a real good measurement for the stability of an operating system.
Apart from that I agree with the fact that one should not fail to upgrade because one wants to get the highest uptime possible. On the other hand, people shouldn't upgrade when there's no need to; if there are no new features/fixes in the new kernel which apply to your system, don't upgrade :)
Check http://www.uptimes.net for a list of uptimes per OS. There are about 500 hosts in the list, so it ought to give a rather clear view of the situation.
0x or or snor perron?!
[...time passes...]
Alright, here you go. Read this, which I got from IEEE Computer Magazine:
Delving deeper, we have this article by Eric Raymond in Linux Today, in which he clarifies what Ken said, as follows: The really bad news, of course, is that Ken was wrong about the volatile and irrational reaction by the members of the Linux community against those who cast aspersions on the current state of apotheosis of Linux--or of the FSF, for that matter. This kind of thing most certainly does happen, as all here can doubtless attest. So much for the good old days."If your uptime isn't to sacred to ya, it may be worth upgrading."
Uptime should *never* be sacred to any computer user in the sense that preserving a high uptime should not preclude one from installing a neccessary software or hardward upgrade. What is important is that an operating system has the ability to run stably and for extended periods of time such that the use of the computer is not impaired. I've known quite a few users who claim ridiculously high uptimes (ie. > 1 year). The kernel is so out of date that any random script kiddie can grab an exploit or buffer overflow from bugtraq and root the system, obviously not a Good Thing if your computer is running any sort of critical task.
Uptime is just that: a measure of how much time has elapsed since the last reboot of the system. It does not measure any of the following things:
-Superiority of an operating system
-Ability to administer a computer
-Programing skill
-"Eliteness/coolness", whatever that is