Slashdot Mirror
Linux Kernel 2.5.1 is Out
xise writes: "The next installment in the 2.5 Linux Kernel beta series, 2.5.1 is avaliable at the usual place Linux Kernel Archives. Remember to use the mirrors. You can read the changelog here."
← Back to Stories (view on slashdot.org)
is there a way to have more than one kernel (e.g. a stable one and a development one) on the same machine and boot to one or the other
/boot, slackware is /). Then edit your lilo.conf file in /etc.
/root/bzImage25 (whatever your new kernel is called)
/dev/hda1 (or whatever you are using)
:)
/usr/doc/Linux-mini-HOWTOs on my system).
Sure is. The kernel sources will untar to different directories based on version (how 'bout that?), so no problem with overwriting your stable ".config".
Anyhoo, after building your new kernel, copy it to the same location as your current kernel, but with a different name. (on Redhat this is
Add a new section that looks like:
image =
root =
label = Linux251 (or whatever)
read-only
Save lilo.conf and run lilo. This will re-install lilo with the new settings. Of course, if you're not using lilo, then cheerfully disregard the above.
On reboot, you should be able to pick from both the old kernel and the new kernel.
As for where the FM is, check out the LILO mini-HOWTO (in
Have fun.
Folks, the kernel mirrors are not at mirrors.kernel.org.
The proper site for mirrors of the Linux Kernel is here.
Here's a quick link to those of you looking for US-based mirrors.
-dan
into unix and punk? check out unixpunx.org
There are currently a few sub-projects going on for 2.5 to improve SMP/scalability on big iron.
;-)
It seens every top-kernel developer or company has a different aproach, so its not clear which will be the one being picked (prolly a combination of patches)
IBM has a patch to do a per-cpu que of tasks, allowing better scaling of the scheduler. This causes a lot of the task scheduler to be re-written
Alan has a in-between solution with 8 que's (no matter the amount of CPU's), and a small part scheduler rewrite.
Some other ppl have different aproaches to it all, cant remember their perspective on it (check LKM archives if ur interested).
However the main point (as pointed out by alan and linus) seems to be: 99% of the linux boxes out there run only 3 concurent running tasks, so the scheduler has to remain optimized for this situation (!). The current scheduler handles this situation very well. So any updates and fixes are prolly likely to be non-intrusive to the current scheduler
The vm change was made because the original 2.4 vm was not performing adequately, and as far as I know the new vm has caused very few problems, but has much better performance. Would you prefer that we all wait 1-2 years before we can use the improved vm in a stable kernel? I'd personally rather sacrifice a few versions of the "stable" branch and get this important change in now. It would have been nice if this was caught before the 2.4 release, but as I said, the number of people running the unstable branch is tiny compared to the number running the stable. Linus has to make a kernel release sometime, he can't just sit and let the same few people test forever, and he sure as hell can't pay huge teams to test each kernel before release. If this is what you want, use the kernel that comes with your favorite distro. These have been tested in this fashion.
As far as the other "HUGE" changes, I'm not sure what you are referring to. Perhaps the addition of reiserfs and ext3fs? They were tested extensively in 2.3, not just added as an afterthought in 2.4.x. They simply were not ready until slightly after the rest of the kernel, and Linus didn't want to wait for them. Once again, should we have to wait years for journaling file systems when they were already very close to being ready? I see no problem with adding them, and if they scare you, just don't use them.
Sure, there have been "server breaking kernel changes", most particularly the umount bug in 2.4.15, but this was due to a relatively small change. These thing happen and no changes to Linus's kernel release practices will prevent them. No one is perfect, and whining about it will not change that fact.
"Any fool can make a rule, and any fool will mind it."
--Henry David Thoreau
Alan Cox no longer maintains the 2.4 kernel. He wanted to be more involved in 2.5 development and handed the job over to Marcelo Tosatti.
I suppose I'm not too threatening, presently, but wait till I start Nautilus
Actually, I'd have to disagree with the parent post. You should NOT depend on 2.5.x for everyday usage, especially on a production server. You should build it on your home machine or test box and run it for a while to help iron out the bugs. This new-fangled Open Source thing only works if the end users hold up our end of the bargain. They release early and often, and we build and test it. If it doesn't work, try to submit a bug report and help out as best you can, then you can move back to your 2.4.x kernel with a clean concience.
A sphincter says what?
From what I understand, the NTFS situation is as much a legal problem as it is a technical issue. There are several people willing to hack the NTFS code, but they're currently under NDAs with MS, and as such, can't do anything about fixing the code. However, many of those NDAs are expiring, and people are beginning to hack the filesystem so that write support actually works. As it stands, reading from an NTFS partition works, but writing requires a chkdsk when you next boot Windows, but YMMV.
Marxism is the opiate of dumbasses