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)
No, in this case it makes sense. It's more of a motherboard chipset thing than a video card thing. AGP lets you transfer large amounts of texture memory (or something like that) over the AGP bus, using main memory as texture memory. You can't do that without changing the kernel (or writing a module). It's not a graphics library issue.
As far as I can tell, AGP support has been in the kernel (as part of the PCI driver) since at least version 2.0.34, dated 1998-07-04. So it's been in there for at least a year and a half. Whatever problems you're having with your webcam, it should have nothing to do with "missing" AGP support.
----
----
Open mind, insert foot.
The original poster was complaining about AGP support because he wanted to use his Webcam. Digital cameras give simple 2D images, since when does this require kernel-level GART support?
----
----
Open mind, insert foot.
For all of you that say AGP cards work in the kernel already, that's only half true. The Utah GLX has a kernel module that lets you use all the nifty fast memory transfers over the AGP interface. Sure the kernels can run AGP video cards, but this makes them much faster (or so I understand). The patch was already merged into the 2.3 kernels, but not the 2.2 ones. You can get it from the project's CVS server.
Was the error something about an "event" variable? They changed that in the fs code to like global_event.
:) I guess the usual caveats when not dealing with the real author of something like this apply. But I've been up for almost three hours now with it (and several weeks in the 14pre kernels), and all filesystems are working just peachy.
I made up a patch based on 2.2.14pre18. It applies and compiles cleanly with this final 2.2.14. I took out some of the kdb stuff, because well, I don't care about debugging it.
mount /dev/whatever /mnt /mnt/journal.dat /mnt /dev/whatever /mnt -t ext3 -o journal=
/etc/fstab and put an appropriate entry for the mount point and set it to ext3. Hmm, I forget now what the kernel parameter was to do this for the root partition. Ah well, I guess you'll just have to wait for their site to come back, or find a mirror. Maybe Google has it cached...
dd if=/dev/zero of=/mnt/journal.dat
ls -i
umount
mount
The -o journal= is only needed the first time. Afterwards just edit
It is not a difficult task to patch/configure/compile/replace a kernel, but the sequence of tasks is rather exactly.
What you state is indeed true, _however_...
Most newbies, in the US, at least, run RedHat.
RH, like the majority of distros, does not ship
stock kernel sources.
This can cause some parts of a patch to fail.
Not necessarily fatally, but certainly enough
to be disquieting to a newbie. I would suggest
either downloading the full sources _or_
waiting for RH to release an updated kernel rpm.
The former being the preferred method.
Patches are a good thing once you have
pristine sources to run them on.
Supermount isn't integrated into 2.2.14, however I have the patch mirrored here:
http://www.fargocity.co m/~ccondit/supermount-2.2.14-1.patch
This has been modified from the original supermount patch to patch cleanly on 2.2.14-final (md.c failed before).
The power outages seem to win...
A few weeks ago I went into work to find the local paper with a front page article stating the utility company of this small town was going to upgrade the substations. I had a spare car battery hooked to the UPS and thought it would ride through. Uh huh... looking at the logs, it looked like the battery was a half an hour shy of the four hours of no power.
They were a big problem around 2.2.10, were claimed to be fixed in 2.2.11, but happenened for me and a few others as late as 2.2.12. Hopefully they're all ironed out by now.
--
I think there is a world market for maybe five personal web logs.
I saw on Kernel Traffic that there were some freaky filesystem corruption problems in the 2.2.x series... and I think I may have experienced this. Anyone know if this has been nailed down yet?
----
Checklist posted earlier was for 2.3.x -> 2.4
:)
This article was about the 2.2.14 release.
----
To either fix bugs, or to gain features
is that something you need to do a lot?
not unless you need to fix a bug, or gain a feature. :)
if your system is running ok, do you still need to upgrade?
See above.
I'm not actually planning on doing it, as I'm not proficient enough to recompile and replace a kernel yet, but I need to know how soon I have to try and take this step. :)
You should look at the kernel HOWTO at www.linuxdoc.org/HOWTO - it's a bit daunting at first, but it's really not that difficult. The main reason to recompile your kernel is to tailor it exactly to your needs, removing all the cruft that doesn't apply to your system. Plus, as someone said, you'll never be a real Linux user until you do.
----
Let me get this straight; you think somebody will replace your kernel with whatever they want, reboot, and the uptime will be your tipoff?
And you think this hypothetical hacker will be savvy enough to code holes into the kernel (as opposed to into the utilities, such as login, which authenticate users), but won't be savvy enough to fake the uptime?
Uhm, sure, yeah, that'll happen. You'll be warned of it by the monkeys flying out of my butt.
Yes, in that extremely bizarre contrived case, it would be a security hole. However, if we're assuming the attacker can replace the kernel with one of this choosing, *EVERY* Unix-like OS has that hole. They have the hole now.
If your system is that owned, you shouldn't be trusting what any piece of software on it tells you, not even the BIOS if you're flash upgradeable.
We do all we can to fix bugs, but we can't fix them unless people report them (ok, we do sometimes when we stumble over silly code by accident, when doing rehauling of code or when having little else to do, but those cases are not in majority.)
linux-kernel@vger.rutgers.edu is the place where you report your problems. Good luck!
AGP? Methinks you mean USB...
Boy, your face must be red right about now
Wouldn't it be possible to make a VM that boots the new kernel, then copies itself into the older kernels memory space?
:-)
Yes I guess that would work. The main problem would be getting hold of the other kernel's memory - you wouldn't have to do any copying at all, but you have to get the memory from somewhere. Presumeably you'd be running under VMWare, or better, an open source vm os, and there would be some kind of api for sharing memory among the various client os's. You'd use that to recover the memory from the halted os. Then figure out how to hot-swap your VM os and you're done.
Life's a bitch but somebody's gotta do it.
Wouldn't it be possible to make a VM that boots the new kernel, then copies itself into the older kernels memory space? That way, supposing everything went smoothly, no reboot would be needed? Just curious if that's a possibility or not? it'd have to be handled in the kernel, so as to allow itself to be overwritten... Memory protection seems like it would be a hassel for anything but SW inside the kernel to accomplish that.
but some stuff is still broke (for my set-up, anyhow).
I don't think that checklist posted earlier was completed.
*sigh* i guess that'll be worked out in the 'ac' patches...
KernelNotes.org has changelists and things but hasn't been updated for 2.2.14 yet.
It's good for a home system, average for a server. It's almost painful to have to reboot a box with over 110 days of update just to put it on a UPS...
Measure the uptime in terms of processor speed, so having a faster processor so you can reboot faster is less of an advantage...
AGP is supported in the stable kernel since many moons, my friend - why don't you check it again.
I agree that you should never perform a necessary upgrade just to preserve an uptime value, but I strongly disagree with your claim that a long uptime is meaningless.
A long uptime on an active system is proof that the system doesn't have significant resource leaks. The same logic applies to systems that don't require frequent disk "defragmentation", etc.
Resource leaks, by themselves, aren't dangerous other than the fact that they force you to reboot the system to recover the lost resources... but they are excellent indicators of the overall quality of the software. In my experience, all program with significant resource leaks have *always* had an unusually large number of other bugs... and the times that someone has tried to eliminate the leaks just to shut up their noisy boss they ended up fixing a large number of unrelated bugs.
Note I did not say that they "found" those bugs - many of the bugs were due to wild pointers that simply disappeared once the programmer took care to properly manage their resources. IMHO, the second most powerful bug-finding strategy, after fixing all warnings issued by the compiler, is elimination of resource leaks.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
1 44 days, 04:36:04 | Linux 2.2.9 Sat Aug 21 18:58:10 1999
:-)
-> 2 39 days, 20:21:28 | Linux 2.2.13 Thu Nov 25 19:50:22 1999
So, you see, I am a mere 5 days from beating my 2.2.9 record (at which point I rebooted to use a upgraded kernel), when they go and release 2.2.14. Those bastards.
Ah well, since devfs for 2.2.14 isn't out yet (AFAIK), it'll be a while before I go and upgrade
(Linus PLEASE put Devfs in 2.4)
---
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
Up that number by five or so. (We've got at least that many /. readers here) I've got two of them thirty feet from me. I won't get to play with them as intimatly as I'd like to, (I'm the 'low-end' guy, and we're only holding them for resale) but they won't leave without a 'Runs Linux' sticker over the shrink wrap.
I really wish someone would port Linux to one of the older rev AS/400's.. I've had a few chances to snag one off of a scrap deal, but w/ no OS they're useless to me..
.sig: Now legally binding!
I've got a couple of boxes with MediaGX processors that I bought for $50 a piece...not as good of a deal as I'd originally thought considerring how f*cked up they are. I know Alan Cox has done some work with MediaGX processors to deal with some of the problems. One of the Linux Grrls gave me a pretty specific explanation of the problem (Thanks Kira :) Now I'm wondering if there will be better support in the 2.4 kernel.
The 2.2 kernel boots and runs fine until I try to do something radical like startx. 2.3 however, detects that it's a MediaGX at boot up, but locks up after 'checking the hlt instruction.'
numb
Wow, I can't believe that Tom Christiansen actually posted stuff about this.
If you'll follow the link that he gave to Computer, you'll see that Dr. Daniel Cooke is listed as one of the guys that wrote the article interviewing Ken. As I said in a previous post, Dr. Cooke received permission from Computer and Bell Labs to show SPUUG (South Plains Unix User Group; Texas Tech's little group that I coordinate) an unreleased video of him interviewing Ken in person. Alot of different material than that in the printed version.
Also, Dr. Cooke mentioned to me several times that he received QUITE a bit of flame from the Linux community when that stuff that Ken said was printed, even though he was just the one who wrote it up for Computer.
Again, I can't believe Tom actually posted about this stuff. Wow. Let me just say that backward: woW.
-Will the Chill
Creator of RPerl, Scouter, Juggler, Mormon, Perl Monger, Serial Entrepreneur, Aspiring Astrophysicist, Community Organiz
Sure :) :) :) ;-) ;-)
Course not, I just typed it because I thougt you guys wouldn't know what Holland is if I didn't mention tulips and wooden shoos
If you ever visit the Netherlands, don't be surprised to see 0.000001% of the population with wooden shoos and 500 others types of flowers in the flower-shops
I've never really tasted flowers, but some people say they are great. I personally prefer steak with french fries
Thank you for your reply, it now is perfectly clear to me that Americans (or wherever you're from) just beleave anything a foreigner says
--
If code was hard to write, it should be hard to read
One very important thing in 2.2.14 is telephony support.
:-(
This could be an area were Linux could really shine. Telephony is all about reliability and can be very price sensitive, especially when you are trying to put together systems for small companies.
I should know, I work for a company producing exactly these kind of systems, unfortunately on NT
For more details see this article on LinuxTelephony.
from the way i see the linux kernel, as long as your video card works good for u, the kernel doesn't need to mess with the video card alot, leave that to the grahics libraries to do, that's why u don't see much of anything in the kernel configuration about graphics, about the only thing i think the kernel might have to do with agp is provide access to that stuff to other progs, but isn't htat why there's graphics libraries?? i'm no kernel or linux expert tho, so this is just what i think, more than likely not the real facts.
Look at Bobby Fischer's anti-semitism, or Einstein's belief in the solid state universe, etc.
Someday Linus will be 50 or 60 and he'll say that the hot new idea is a piece of crap.
It seems to me that people are first anonymous, then we find out about them from some great accomplishment(s), and then they become yesterday's news when the environment that created them changes.
If his comments about Linux being worse as a firewall than Windows are actually attributable to him, then it is obvious, at least on this topic, he is walking, breathing anachronism.
Finish Human Genome Project. Opensource DNA. Figure out what it does. Improve it. Lather. Rinse. Repeat.
When does AGP get put into the stable kernel? and is the unstable one any good. I WANT MY WEBCAM =)
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.
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.
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