Slashdot Mirror
2.5.4 Kernel Out
Saint Aardvark writes: "Just in time for my 30th birthday, the new kernel is out...how did he know? Thanks, Linus! Change log here. I usually stick to stable stuff, but I think I'll try this for fun." Reader Scooby Snacks writes: "Be sure to use the patches and pick from the fine list of mirrors."
2.6.0 released
2.5.20 released
2.5.19 released
2.5.18 released
2.5.17 released
2.5.16 released
2.5.15 released
2.5.14 released
2.5.13 released
2.5.12 released
2.5.11 released
2.5.10 released
2.5.9 released
2.5.8 released
2.5.7 released
2.5.6 released
2.5.5 released
Expect all these articles on this site soon.
Slashdot, news for "nerds", notifying you of minor changes to the penguin!
Well, I'm still having trouble with 2.4.17 on my AMD. A couple of weeks ago it was suggested here that I should add "nopentium" to my boot parameters but after that the machine doesn't feel as fast anymore (can't understand why; it should not be noticable)
Parsing the changelog, I don't see that many changes with potential enormous impact. Should I consider trying this version because many problems are straightened out or should I wait for a next "stable" 2.4.x?
I did see something regarding AGP (which I believe to be the source of my problems, as they go away if I disable 3D support) Linus said something about a workaround for AGP problems until a real solution was found. Doesn't look very encouraging, but hey...
no sig error.
Good to see the patches, mirror list, and changelog linked to, not just the full kernel. We knew you could do it! Keep it up, guys!
See that middle number of the kernel version? Note that it is of the form 2n-1 where n>0, otherwise known as an odd number. Now, in the Linux world this means that it is a development kernel. D-E-V-E-L-O-P-M-E-N-T. In other words, extreme beta.
So, unless you wish to contribute to the kernel development or want a range of unknown problems, stick with the even middle-numbered kernels.
I've got a fever and the only prescription is more COBOL.
Not being anything remotely resembling a kernal hacker, it was great to see and compare some of the (proposed) changes between 2.4.x and the new 2.5 fork at the recent linux.conf.au. The speaker, Rusty Russell, took us through the netfilter and scheduler code (2.4.13 vs 2.5.3) and it was a real eye-opener. I don't claim to be a C wizard, but I can tell elegance when I see it, and some of the code overhauls certainly have that ring to them.
"Einstein argued that [...] God is not capricious or arbitrary. No such faith comforts the software engineer." ~ Brooks
Today there is a release of some sort in 4 kernel trees (see freshmeat.net):
2.0.40-rc2
2.2.21-pre2
2.4.18-pre7-ac3
And, of course, 2.5.4.
Granted, only one was a full revision bump, but to see updates in so many trees is neat.
XML is like violence. If it doesn't solve the problem, use more.
Moderators, this isn't a troll. Enough complaints have been made about this over time for it to be a justified request.
There are those of use who do want to read Linux stories, but don't want to know about every release of the kernel. It's not as if theres a shortage of sites that have that information.
Some of us use slashdot as a central news source. Why go around to a zillion other places, when we can just catch the announce here? Saves time.
Best Slashdot Co
The slash engine was designed? I thought it just sort of grew. Like a fungus.
A'course, I haven't actually looked at it in a few years. The first release was traumatic.
Best Slashdot Co
Sick of these minor release announcements on development branch kernels... Not because of the announcement itself, but because of all the people yelling and screaming that they don't want to know about it... Stop bitching and skip the article and move on and leave the thread clean for those that DO like to read about it and read INTERESTING comments...
7:58 - Slashdot post that new kernel is out
7:59 - "Bleeding edge" kernel hackers start downloading it
8:30 - download finally is over, start unpacking it
8:35 - ooh and ah over new features in config
8:40 - start compiling, so far so good
8:55 - kernels done, reboot
8:56 - system is as fast as ever and that leet hardware is now supported
8:59 - file system gets fscked due to some small oversight
9:00 - a large scream is heard through country
9:10 - screaming stops
9:20 - hacker finally remembers that its the 2nd #, not the 3rd that means the kernel is unstable
9:30 - i laugh
can't sleep slashdot will eat me
Check out this link. It's a list of stuff to expect in 2.5
g lad-they-do-it" stuff.
.tar archive of modules and programs to the end of the kernel image, make a basic boot, unpack the tar file to a ram-based root filesystem then everything goes from userspace. If it's true that 2.5 will move to a completely modular kernel (as Alan Cox has hinted), this would be a much friendlier system than initrd.
/proc and building one big tree with all bus:es in it. Most comments I've seen circle much around how much easier it would be to implement a proper ACPI power management system with this and that it clears up /proc.
Follow the link to the posts if you want the details and discussions, if you don't, the items and a more human-readable explaination is below:
2.5.x API change summaries
o Shouldn't matter much as far as I could tell, mostly "heads up" to people writing programs that mess with the kernel.
o Block I/O layer changes:
The goal seems to be a more generic i/o scheduler while at the same time making it more efficient.
Typical "dont-understand-exactly-what-they-are-doing-but-
o initrd / initramfs:
initramfs is intended as a replacement for initrd. The basic idea seems to be to tack a
o SCSI changes
As always?
o driver model: driverfs
Driverfs seems to aim towards merging all bus-type weirdness that lives under
o reworking major/minor system
The currrent model of drivers having major/minor numbers is going to change to allow larger numbers (and therefore, more devices). May be some hairy details involved in changing such a "standard" size. Consent seems to be that apps that depend on a specific size are broken anyway.
o USB and WireLess API changes
I don't use any of these so I haven't got much to say, anyone with more interest/info?
o kbuild and CML2
The new configuration language and makefiles, these have been discussed earlier on slashdot (see here).
There was a change to the API in this kernel release which breaks a bunch of drivers for the moment. Specifically, all drivers that allocate buffers using the kmalloc/__get_free_pages and virt_to_bus will not link. Right now, I can see atleast two groups of drivers affected: some USB, and the PCI sound drivers.
/* Copy and release all segment info associated with a VM */
/*
Even if you don't see the above problem, this kernel will not compile (atleast on most i386 systems) without the following patch:
--- linux-2.5.4/include/asm-i386/processor.h Sun Feb 10 22:00:29 2002
+++ 25/include/asm-i386/processor.h Sun Feb 10 22:21:53 2002
@@ -435,14 +435,7 @@ extern int kernel_thread(int (*fn)(void
extern void copy_segments(struct task_struct *p, struct mm_struct * mm);
extern void release_segments(struct mm_struct * mm);
-
-/*
- * Return saved PC of a blocked thread.
- */
-static inline unsigned long thread_saved_pc(struct task_struct *tsk)
-{
- return ((unsigned long *)tsk->thread->esp)[3];
-}
+extern unsigned long thread_saved_pc(struct task_struct *tsk);
unsigned long get_wchan(struct task_struct *p);
#define KSTK_EIP(tsk) (((unsigned long *)(4096+(unsigned long)(tsk)->thread_info))[1019])
--- linux-2.5.4/arch/i386/kernel/process.c Sun Feb 10 22:00:28 2002
+++ 25/arch/i386/kernel/process.c Sun Feb 10 22:26:35 2002
@@ -55,6 +55,14 @@ asmlinkage void ret_from_fork(void) __as
int hlt_counter;
+ * Return saved PC of a blocked thread.
+ */
+unsigned long thread_saved_pc(struct task_struct *tsk)
+{
+ return ((unsigned long *)tsk->thread.esp)[3];
+}
+
+/*
* Powermanagement idle function, if any..
*/
void (*pm_idle)(void);
-
-
w o r l d w i d e w e b e r