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
99% of the linux boxes out there run only 3 concurent running tasks, so the scheduler has to remain optimized for this situation
:-P
Interesting. But could this measurement be simplified to the point of being off base? A large percentage of these machines are webservers sitting idle so what do they care about scheduler optimizations? Same thoughts for single process number cruching ray tracing server farms. Shouldn't the focus be optimizing tasks that will benifit from being optimized? I know we have a few boxes that just run Java apps. I bet they would benifit from a new scheduler if the machine were a 4 way. So what are the bulk of these 99 out of 100 machines doing? They're not desktops.
Also, what prevents Kernel developers from optimizing the scheduler for a Kernel development workstation
I just finally got version 2.0.34 to not make my toaster oven radiate green antimatter. I've heard that 2.4.15-pre14 has this feature built in if I remount my disks enough without syncing and doing lots of little changes to my filesystem - I guess it'd be a bit unorthodox to use that method to make my toaster stop, but it should theoretically work. Does the 2.5 series have this problem solved?
I kind of got frustrated after trying to patch it for a while, and just let it eat stuff before I finally made myself fix it, but when I sent in the patch, he said it was too big and obfuscated (I'm not quite sure what he meant - BettyLuJane could read it fine if I held her head on for her), but now I have to try all over again? 2.1 or 2.2 I think I could get done before it starts eating the sofa again, but 2.5? It'd eat all the way through the safety systems on all my Acme stuff, and I don't want that to happen again.
I mean, 2.5 just sounds really big. Does it mean I have to use real names for my variables instead of just my favorite letters? Also, I don't think my toaster liked gcc. It said something about being incompatible with M$ PROPRIETARY ANTIMATTER-GENERATING TOASTER's. I still don't know where that came from, but it all went away when I rewrote the kernel in Visual Basic 2.0+.
Well, thank you for your time. If you have any suggestions (or if you want to send me a new toaster - I can't really afford a new one quite yet), my email is gheiste.strauss@mickeymouse.com.
P.S. If it does fix the antimatter problem, does that mean I don't have to worry about it destroying the city anymore? (these guys in suits wouldn't take me seriously when I told them I couldn't figure out what was going on, and they let me go after a couple of years, but I don't like them anymore - they aren't as polite as they used to be)
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
Ok, this is a development kernel, so you shouldn't just jump in as if it were a stable release. But keep in mind that this is only 2.5.1, where 2.5.0 == 2.4.15, a stable kernel. Since it's only been one revision, it can't have destabilized that much.
A quick primer on kernel engineering might help. You know how the 2.4.x series solidified release by excruciating release? Well, the 2.5.x series is the same, only in reverse. It takes as much work to destabilize a kernel as it did to stabilize it, so don't expect crashes and corruption right away. In fact, just as a few 2.4.x releases were regressions, 2.5.1 might even be stabler than 2.5.0. That would be an accident, though, and the developers try to prevent it.
To the Slashdot editors: You can dispense only so much over-caution before the readers decide you're crying wolf. As a community, we need to save up our restraint for the real hour of need, when the siren song of exotic new features lures even the most stolid administrator from the doldrums of predictable stability, into the roiling churn of highly evolved breakage. I would recommend toning down the warnings for now, and becoming progressively more shrill as the kernel hits its maximal instability.
The evaluation of an action as 'practical' . . . depends on what it is that one wishes to practice.
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
I very much doubt we are going to see EVERY 2.5.x release on the front page
... err ... 6473?
You're new here aren't you, number
Mmmmmmm
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?
You must have an awfully short memory.
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
This is mainly because FreeBSD does not assign flashy version numbers to their betas, only to releases. For a current beta, grab the FreeBSD-current distribution, and you're up to date. If you don't know how to do that, then it's not for you anyway.
They don't advertize that, and I think it's a good idea not to do so, because it saves a lot of end users a lot of trouble. There's an extra section in the FreeBSD manual saying that the -current distribution is not "a fast-track to getting pre-release bits because you heard there is some cool new feature in there and you want to be the first on your block to have it", and that sums it up quite well. Better than assigning 5.0.7b1-BETA and waiting for end user complaints to pour in, anyway.
There is absolutely no reason to panic.