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)
Not because "slashdot isn't freshmeat," but becaused judging from the outcry from unsophisticated users who updated to the latest STABLE kernel when they probably should have been sticking with vendor supplied kernels, most slashdotters either already know about the releases, or probably shouldn't.
Any newbie who trys to install 2.5.1 is in for a learning experience (especially if they use SCSI).
New drivers and the like will continue to appear, and some things will get backported from 2.5. But further 2.4 development is likely to be concentrated on bugfixes and not fiddling too much with the core code.
Should be only bugfixes for now, but I guess it's up to Marcelo.
This sig intentionally left blank.
Funny, I always thought that's what the STABLE branch was for....
It irritates me that linux developers insist on adding new "features" to "stable" kernels, rather than keeping a running development kernel year round. Things like the vm change early in the 2.4 series, and some HUGE, server breaking kernel changes should not appear in a stable kernel.
Once new features are found, and coded, they should go immediately into the development kernel, and save the stable kernel for bug fixes, driver updates, and security enhancements.
Please remember that the 2.5.x series is a development series and is NOT meant to be deployed in a stable environment. You are to expect bugs and problems with the 2.5.x series and generally it is not recommended that you install it UNLESS you can program and debug kernel stuff.
You may want to just continue upgrading on the 2.4.x series and wait until 2.6.x is stable.
-
Ever need an online dictionary?
One of the key things for 2.4 if I remeber right was SMP support. Are they going to work on improving SMP support beyond the process level in 2.5? What could one list as the 'key bullet points' for 2.5 if talking to a manager type for futures of the Linux kernal?
As a rock-in-roll Physicist once said, No matter where you go, there you are.
Just compile and install the new kernel, and keep your old one around. Put entries in LILO for both. For example I, running slack, might have an entry for "slack" being the default 2.4.16 which I most frequently use. I might then make and entry for "slacktest," being the most current 2.5.x kernel of the week. I simply direct one entry to vmlinuz (vmlinuz being my 2.4.16 kernel) and one to vmlinuz-2.5.1 (this being my newly compiled test binary).
If you wanna know where to find the FMs, www.linuxdoc.org is a good place to start.
What about this, you use /. like I do, I leave everything on in the main section, I read the headline, and if it interests me I'll read the article, if not, I can do this amazing thing, SCROLL DOWN!!!
Is this next? Why do submissions like new versions of devel-kernels make it into Slashdot at all? It's not as if most users will download this and deploy it on ANY system.
I also don't see announcements of FreeBSD beta, only RELEASES. And it should stay that way.
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.
A great many of the drivers are arch-independant. Indeed, the total architecture-dependant portion of the kernel is only 18.5% of the code size as a whole (decompressed, unbuilt; it's far less in a built kernel). Compilating the download process (making folks get both a generic and an arch-specific package) just doesn't seem worth it to me given the paucity of return, particularly considering the complication this would add to the patching process.
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 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...
Well, Linus doesn't make a roadmap; I think he feels it is counter to the Linux development methodology and would be unproductive. What gets put in the 2.5 series depends upon what patches people decide to submit.
That said, I've read that the stuff that Linus WANTS to put into the new kernel include features for NUMA machines and stuff to improve scheduling abilities for embedded systems. Both of those probably mean a higher focus on making things SMP safe, and possibly work on making the kernel more preemtible. One thing Linus has said he will make sure of is that performance on uniprocessors and small SMP's doesn't suffer much as a result of this.
Besides that, we can expect support for more devices, tons of bug-fixes, probably some more journalling filesystems, and all the other stuff that comes with Linux slowly maturing.
Even Slashdot wants to hide some things
I actually like seeing new kernel announcements on here. Same goes for other big pojects like Xfree and Mozilla. I've got better stuff to do than lurk on kernel mailing lists and check mirrors every 5 minutes to see if a new kernel's out. /. is usually the first place I hear about a new kernel release, and usually its posted even before its propagated to the mirrors I'd be checking.
Perhaps there should be a new "version" category for the more pointless new version announcements (although I wouldn't call this one exactly pointless. nothing major is new, but at least we know the new stuffs going here from now on) so people can filter articles like this instead of bitching about it every time
Can't they fix the 2.4.x bug which loves to chew up a ton of pagecache?!? Just cut that thing down...
--
# Canmephians for a better Linux Kernel
$Stalag99{"URL"}="http://stalag99.net";
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.
Like the vm changes? That was just a driver change that anyone could swap in or out of the stable 2.4 kernel, eh?
Yes the anonymous cowards are a pain but sometimes they do make a good point.
I have to support some of those old monsters. Does anyone know what the story is on the seperate driver issue? Considering the amount of effort it took to learn how to configure those boogers, I'm a little bummed that all that effort is going to waste.
political_news.c: warning: comparison is always true due to limited range of data type
Kill Smart Tags:
meta name="MSSmartTagsPreventParsing" content="TRUE"
Is this true?
Comparing it to Windows will be a moot point, since El Dorado is going to have a 40% larger code base than XP.
Since when did slashdot started announcing the DEVELOPEMENT kernel releases?! Go read LKM if you want this!
Did you read that third word in green at the top left of the page, right under "Slashdot"?
Yes, we're nerds, we care. If you aren't, go read a pop news site.
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)
I think it should be noted that this is the first 2.5.x release that actually forks away from the 2.4 (2.5.0 was just a 2.4 kernel in disguise) so this is an event... this is the first new tree since 2.3 closed.
In that sense, this is a big deal. Of course, posting all the 2.3.x announcements would be excessive.
----------------- "I have a bone to pick, and a few to break." - Refused -------------------
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
Yes, there is a point to Google caching a copy of itself -- they don't have to code in a special case for their own site.
Value(Code clarity) >= Value(Memory for one cached page)
-Justin
That's enough posting for now lads, there're trolls afoot.
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.
I'm with you on that 100%. What amazes me is that the people who take time to bitch about new kernel announcements actually expect to be taken seriously...after they spend the time to write a comment about what a waste of time it is to read a simple headline announcing a new kernel.
:)
Yeah whatever. Maybe Slashdot should just start a fund to send all the crybabies some tissue paper to blow their nose when they're done bawling about all the extra bandwidth a kernel summary takes up.
Maybe only the milestone ones...
Well, to be fair, a ton of the kernel will be re-written by 2.5.2. From what I've been reading at LKML, the block IO layer will have been re-done, and then the new kbuild will start to be integrated (Optional on supported platforms at that point). That's actually some pretty big stuff.
--Josh
There are exactly 42,935,718 letter sized sheets in a square mile.
I seem to remember that slashdot fronted many releases from the 2.1 series...
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.
Does it really hurt you that much to see people's names in the Changelog? Is your connection so slow that you think they are a waste of bandwidth?
I don't have a problem with people sticking their names in the Changelog - they've done this voluntarily and without pay, in their own time, when they could have been doing other stuff, don't you think they deserve just a little recognition? They've done a great job.
And it serves a purpose too as already pointed out - it allows you to see who was responsible for a change, so your type can be quick to blame them if feature X related to their change fails to work/crashes/panics/oopses/whatever
add another stanza to the poem we call /etc/lilo.conf
It's one of my favorites.
Spring is here. Don't believe me, look outside!
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.
Alan *never* maintained 2.4.X, he maintains 2.2.X to this day, you can even see a changelog recently involving some weird DMCA secrets withheld from the general populace (do a diff lay-Z people ;p) from 2.2.19 to 2.2.20.
;p) contains EXT3 (as does the original RH7.2 kernel modification of 2.4.7). This was considerably sooner than 2.4.15. While Alan's 2.4 work is invaluable, he was not the maintainer.
The -AC 2.4.X were a testing ground largely for his endeavors to merge as much as possible into the kernel above and beyond Linus' stable-er or more conservative (an approach which is subjective; some such as Alan see the new VM as avant guard) merging approach. I think that part of the aggressive merging going on in 2.4 with the -AC branch seeks to give RedHat the leg up on other distros with regard to the feature-laden-ness of the RedHat official kernel. For example, the RedHat 2.4.9 kernel release that is RPM-able (RPM KERNEL ARE EVIL
The maintenance of 2.4.X was handed off to Marcelo at 2.4.15 by Linus, according to "The Linux Portaloo" written by Cox sporadically, there was some confabulation regarding who would maintain 2.4. According to some recent posts, Alan fully intends on continuing his tireless and aggressive merges, but in the tie being he is, by my speculation, busy digesting the 2.5.X roadmap and rewriting SCSI drivers (:
As far as the 2.5 kernels go, try them out, complain to the right people, and make sure to love Linux as well should.
-Z
Legalize the constitution. Think for yourself question authority.
No. 2.4.15 was where Alan pushed most of his ready-for-primetime stuff to Linus, and that was the end of the -ac series for now. Alan pushes stuff straight to Marcelo now (see the changelogs), and presumably he doesn't have all that much queued up from -ac anymore.
"How can you claim that you are anti-crack, while still writing a window manager?" — Metacity README
Yup, a shiny new block device layer, supposed to scale better on big boxes. It required significant changes to all block drivers, meaning all the hardware drivers for IDE, SCSI, RAID, floppy, etc.
This is what makes 2.5.1 a "caution, do not try this at home" development kernel. The early kernels in 2.3 were pretty tame by comparison - the big breakage there (the Great Page Cache Migration) didn't happen until I think 2.3.7.
"How can you claim that you are anti-crack, while still writing a window manager?" — Metacity README
Please, restore my faith in humanity by reading it again and at least pretending to laugh if you still don't get it.
The evaluation of an action as 'practical' . . . depends on what it is that one wishes to practice.
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.
They could just deny all access from GoogleBot in their robots.txt file.
It's hard to be religious when certain people are never incinerated by bolts of lightning.