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
The core kernel will remain stable, new drivers will be added where they have no effect on the rest of the kernel - so its the users choice if they want the new drivers or not.
One of these days the ACs will get a clue ....
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
There was a kernel summit about 2.5. I've also heard that they are working on lower latency (either through preemption or breaking up long no-preempt regions) and integrating ALSA.
A deep unwavering belief is a sure sign you're missing something...
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
A lot of people seem to be complaining that Slashdot doesn't need to announce a development release... I think that its only being announced because its the first release of 2.5. Kind of like saying "hey, its started, just thought you'd crazy ones would like to know!" I very much doubt we are going to see EVERY 2.5.x release on the front page.
And if you are one of those complaining... c'mon... grow up. Like it *really* killed you to read one extra headline.
This is a development kernel. It's not beta. Beta generally means "feature-complete, but not fully tested". It's not alpha, because alpha usually means "mostly complete". Development means "not complete at all".
Our company just started on the next release of our software, so I feel a bit "in tune" with where the kernel developers are at.
The beginning of a new release should be the place where you make all the hard choices and break things. Then you start putting the pieces together, and if you broke the right stuff for the right reasons, it will be better (but probably less stable) than before. Gradually, you add more and more features, but they don't tend to break things as badly. Finally, you stop adding features, and work on polish.
This is a development kernel, and things are broken because smart people decided to break them. Don't think it's beta. It's not.
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?
I noticed mention of an upgrade to NTFS in the changelogs. I realize it can be argued as a non issue, but is there any real effort to stablize NTFS read/write? At work we're locked in to using W2k domain controllers, and have W2k in a few other places as well. Samba bridges the gap through the network, but in some cases directly mounting an NTFS partition would prove extremely useful. Or is this a non issue?
I'm against picketing, but I don't know how to show it.
You must have an awfully short memory.
XFS and JFS supposed to be merged into the kernel? I saw a post a while back on Slashdot that claimed Linus wanted IBM/SGI/etc to wait for 2.5. Well 2.5 is here...
So the 64000 Euro question is... when are we getting ACL support? I've heard the IBM solution was good, but required a lot of kernel patches -- but that's what development kernels are all about!
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.
BSD kernel development and Linux kernel development seem to be examples of two very different paradigms[1]
FreeBSD[2] kernel development, bug tracking and fixing appear to be very formal, resulting in a rather sedate evolution. Linux versions of the same thing, although every bit as centralised as BSD projects (or even more so, because Linus decides what goes into the release), appears to be much less formal--I can find no Linux equivalent of FreeBSD's bug tracking system.
The FreeBSD project does also appear to have more rigid project management. It's also much more of a single entity, too. Whereas the Linux kernel project is distinct from the distributions that use it, typically a BSD project includes management of everything from kernel development through package management to documentation, promotion and distribution of source media.
[1] Sorry for dumping the p-word on you without warning there, but I think it's merited in this case [G,D&R].
[2] Taking FreeBSD as an example of a BSD project.