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
After seeing so many posts on the preemptible patch being including into Linus' tree, I would have thought that everyone would be dying to try the first dev release with it incoporated. Give it test drive and see if that is really a useful feature.
Or does everyone here REALLY run Win XP ??
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
Those are the first two big questions about /. posting : shortly to be followed by "Is there any sence/reasoning behind how things are rated?"
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
They extrude a new one every few days - what great big new feature does 2.5.4 provide that we should all care about?
Or is slashdot just desperate for news on Monday morning?
- A.P.
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
I'm glad to see a change Log that I can understand!.
I's detailed and clear.
I'm from Argentina: Tango, Asado, Mate, Gaucho, Maradona, YPF
Dave's wife has name Nina, she is Polish and she uses account on similarly named computer (pierdol.ninka.net) to post the news. So you see the real email on real computer named so in DNS. And the p**** word means in Polish the same as in Russion.
For me, this really is not funny.
The changelog for the kernel-v2.5.4 contains a
few patches posted from "davem@pizda.ninka.net"
In Russian the word "ninka" is a female name
while the word "pizda" is a very dirty slang for a female genitals. To a Russian this email address sounds very offending!
You know Linus cannot be proficient in all world languages. Therefore some ethics on the side of
Linux contributors is very much appreciated.
+Leo+
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).
Details can be found here. The isos can be downloaded from here and all bug reports can be discussed here.
Very few 'really ugly' bugs have been found in the first beta, and we have been able to concentrate on hardware recognition, improving the *drake* tools, and updating the packages. For more details about what has changed since the beta1, and what should be tested, please wait for the articles in the "test this" serial.
You, my friend, are a Troll...
:-)
I'm not a prophet or a stone-age man,
I'm just a mortal with potential of a super man.
Although most people use the term 'Linux' for the operating System as a whole it really only the name of the Kernel. Would we call it 'Hurd' if we ran it with a hurd-Kernel? No, we probably talk about 'Linux with a Hurd-kernel' or somesuch, which is funny enough (maybe it should be 'GNU/Hurd' or just 'GNU' then). In that light (Linux being really just the name of the kernel) news about new kernelversions are very appropriate under this topic, what more interesting could there be under the 'Linux' topic, than something about a new Version of 'Linux'?
...). The term 'Linux-kernel' is redundant, and thus really not a good topic.
So if we want to keep the terms right (and those who always complain about the use of the term hacker in a wrong context know we should) maybe there should be another topic 'GNU/Linux' or 'LinuxOS' (and also 'LinuxAPPS'?) to comfort those who want to read about Linux, but not about the kernel (so actually not about 'Linux'
I also wonder, how one can be interested in Operating systems based on the Linux kernel, without being interested in the development of the kernel itself (especially the unstable versions, since there is much more happening), and for a lot of readers the 'new kernel' news is the place to discuss these developments. So if you want to vent your complaints, that hardware x isn't supported, why patch y didn't make it in, express your happiness that z works now (z preferably being the VM), or just have a question these stories are the place to go. The kernel is the thing that all those LinuxOSes, LinuxDevices and whatnot have in common, and if you're interested in Linux on your Palm, or maybe in your coffee-machine, then you should be interested in the kerneldevelopment, since without a kernel allowing to be shrinked down to that size it's just not possible. If you're interested in 'Linux' running on big iron, like n-Processor machines, well, it's really the kernel and its development that makes it possible.
And finally, if you're really not interested in kernel development, it's not that hard to spot, that a story is about the new kernel, just ignore it, and be happy, these storys are there, because if they weren't people would just post things about new kernel developments in other Linux-stories (even if slightly offtopic).
--
"By the way if anyone here is in advertising or marketing... kill yourself." -- Bill Hicks
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
It may not be "Justice wins over Microsoft" but its still a notable event.
Top Most Bizarre/Disturbing Error Messages
If I was you (but i'm not) I would use Linux with a slightly dated yet powerful machine. Like - a year old or so. Good performance, and most bugs in the drivers have been ironed out. Looking through the list of supported hardware is also a good idea before ordering a machine or any other piece of hardware for that matter.
Then again, you can always use w2k or xp. Sadly, there are more drivers available there.
Stop the brainwash
This will fix it... at least it did for me ;-)
Don't quote me on this.
I run an AMD Athlon with an AGP4x video card on 2.4.17 with no issues whatsoever. I also compiled the kernel as an Athlon which is not affected by the issue. Gentoo describes the bug in kernels running on Athlons that were compiled for Pentiums. Pentiums builds enable 'extended paging', where the issue resides. In short: compile your kernel as an Athlon (which you should do anyway) and you will not have issues.
Are both klogd and syslogd running? Make sure they are, and I think klogd needs to be started after syslogd. I had this problem for a while until I discovered klogd wasn't running (or at least not talking to syslogd: restarting both fixed the problem).
Bill - aka taniwha
--
Leave others their otherness. -- Aratak
If you download and compile a kernel for your machine, you compile for your CPU. Why would you not take advantage of processor-specific optimizations? Do you compile for the least common denominator on your own machine? Did you read the parent? Is he not compiling for his own machine?
Looks like your no longer namecalling, so at least thats good. Perhaps you can tell my why I run 2.4.17 with an Athlon T-Bird 800 using AGP 4x? Hmm? Hint: I compiled my CPU for Athlon, which as the link I provided in my first post clearly states, was never where the issue resided. Thanks for being rude, but it wasn't needed.
The slash engine was designed? I thought it just sort of grew. Like a fungus.
Like some other software out there. I qoute:
"Software "Design" is like a religion - too much of it makes you inflexibly and unpopular."
- Linus Torvalds
My Karma: ran over your Dogma
StrawberryFrog
How much OSS software works the way it was designed at the beginning?
Isn't the point that future redesigns of the software are based upon the users' needs and that they can directly affect the process? In this sense, it sort of organically grows very much like a fungus.
Wasn't it Steve Balmer who said that Linux springs up "organically" as competition? Is this not one of the big strengths of OSS?
LedgerSMB: Open source Accounting/ERP
Notice the line explaining the kernel configuration? I do not compile as Pentium* therefore I do not have this issue. Nor does anyone else who follows in my footsteps. Shows over. Nothing to see here.
Why you threw a hissy originally is beyond me... especially over something as trivial as this argument. Go to
A new scheduler that improves interactive performance+preemptible kernel and other improvements.
This should make 2.5/2.6 "feel" much faster.
Facts:
1.) This is an Athlon bug in handling 4M pages when dealing with Intel's extended-paging.
2.) This bug becomes apparent when using Pentium-class optimizations in the kernel.
3.) I never said this was not an Athlon bug.
4.) You *will not* have this issue if you do not compile as a Pentium.
5.) Calm down and stop acting like a child/children.
Last year, didn't they talk about a raw filesystem mode that skipped the kernel buffering to allow databases to have raw unbuffered access to the hard drives?
And I seem to vaguely recall hearing about a new kind of IP mode to allow a single server to host tens of thousands of connections in a much more efficient manner than TCP allows. This would be useful for instant messanger and peer to peer clients.
Anyone know anymore about either of these two projects? If I remember it right it was from an article about the top Linux people getting together at a linux world and having a couple of days of meetings.
-- Never make a general statement.