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)
Don't mod me up for this... Public service only...
;)
final:
- Al Viro: floppy_eject cleanup, mount cleanups
- Jens Axboe: bio updates
- Ingo Molnar: mempool fixes
- GOTO Masanori: Fix O_DIRECT error handling
pre11:
- Jeff Garzik: no longer support old cards in tulip driver
(see separate driver for old tulip chips)
- Pat Mochel: driverfs/device model documentation
- Ballabio Dario: update eata driver to new IO locking
- Ingo Molnar: raid resync with new bio structures (much more efficient)
and mempool_resize()
- Jens Axboe: bio queue locking
pre10:
- Jens Axboe: more bio stuff
- Ingo Molnar: mempool for bio
- Niibe Yutaka: Super-H update
pre9:
- Jeff Garzik: separate out handling of older tulip chips
- Jens Axboe: more bio stuff
- Anton Altaparmakov: NTFS 1.1.21 update
pre8:
- Greg KH: USB updates
- Jens Axboe: more bio updates
- Christoph Rohland: fix up proper shmat semantics
pre7:
- Jens Axboe: more bio fixes/cleanups/breakage
- Al Viro: superblock cleanups, boot/root mounting.
pre6:
- Jens Axboe: more bio stuff
- Coda compile fixes
- Nathan Laredo: stradis driver update
pre5:
- Patrick Mochel: driver model infrastructure, part 1
- Jens Axboe: more bio fixes, cleanups
- Andrew Morton: release locking fixes
- Al Viro: superblock/mount handling
- Kai Germaschewski: AVM Fritz!Card ISDN driver
- Christoph Hellwig: make cramfs SMP-safe.
pre4:
- Jens Axboe: fix up bio highmem breakage, more cleanups
- Greg KH: USB update
pre3:
- Al Viro: more superblock cleanups
- Jens Axboe: more patches for new block IO layer
- Christoph Hellwig: get rid of the old, long- deprecated SCSI error
handling
pre2:
- Greg KH: USB update
- Richard Gooch: refcounting for devfs
- Jens Axboe: start of new block IO layer
pre1:
- me: README references to 2.4.x -> 2.5.x
- Alexander Viro: fix unmount inode breakage, show_vfsmnt cleanup
- Jeff Garzik: fix 8139too initialization
I like you, Stuart. You're not like everyone else, here, at Slashdot.
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...
Run the latest 2.4 - or upgrade your hardware, you can get new tulip cards (the netgear FA310TX for example) for 15 bucks, Or... I'm sure there will be a patch when 2.6 comes out.
but I mean... Would it kill you to run 2.4.xx when 2.6 is out? I mean, bugfixes are still being applied to the 2.2 kernel...
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
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.
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 think the main points that were explicitely targetted in 2.5 were:
* a rewrite of the block i/o layer (i.e. how do you access your various disk drives, iirc) to remove some big single lock there that was holding back scalability.
* a rewrite of the driver model that would lead to better dealings with dynamic device configuration (ie. everything would be considered hot-plug), and to better keep track of all drivers used in a machine.
* the removal of old, deprecated code in I/O that is still hanging around.
* a better scheduler to better deal with more than 2/4 CPUs.
* the integration of ALSA (but I could be wrong, there).
The rest would be icing on the cake.
As for an official roadmap, I don't know. LWN did have a special report on the Linux Kermel Summit held earlier this year which could be considered the closest to a roadmap as can be. I think that Linus & Alan (and others, esp. IBM) basically want the Linux kernel to better scale upwards to deal more gracefully with, say, a big f**king Oracle database running on a gazillion processor mainframe.
I hope this helps.
Would you READ the release? Literally HALF of the block device drivers are broken, as is the SCSI subsystem. Someone mod this down, this guy's a retard.
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
Since it's only been one revision, it can't have destabilized that much.
2.5.1 introduces major changes to the block device layer, a rather crucial bit of code. Bugs in that code might well eat your data. In fact, it's a good idea to put the dangerous changes in early rather than in a late phase of development.
It takes as much work to destabilize a kernel as it did to stabilize it
Absolutely untrue, as any programmer knows. It takes a lot of hard work to make something stable, but it only takes a one-character change at the wrong place to destabilize the system for all users (cf. 2.4.15).
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.