Slashdot Log In
Linux 2.5.2 Kernel Released
Posted by
Hemos
on Tue Jan 15, 2002 07:53 AM
from the go-and-compile dept.
from the go-and-compile dept.
valdis writes "Amazing.. it's been out over 3 hours and not discussed to death. Well, maybe there's not as many bleeding-edge crazies out there. But if there are, here's what's new. You can get it at the usual place, but please use the mirrors if you can."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Bah (Score:2, Funny)
Re:Bah (Score:2, Funny)
(also kidding)
Re:Bah (Score:2, Funny)
Re:Bah (Score:5, Funny)
Parent
Re:Bah (Score:3, Insightful)
Re:Bah (Score:3, Interesting)
It's goofball losers like the 2 folks who modded me a Troll that make the Linux environment so difficult to break into for Linux newbies like myself. Get off your uber-elete soapbox and have a laugh.
Off topic? Sure. Mod me down. I got the karma to burn.
USB (Score:5, Interesting)
Sounds rather interesting. I've had some issues with my Rio 800 MP3 player with many 2.4 kernels, perhaps it's more stable now? Also great that the kernel guys are working on 2.0 support.
Ciryon
So... (Score:4, Funny)
Mirrors (Score:5, Informative)
Re:Mirrors (Score:2, Interesting)
Hmm. Considering their bandwith utilization right now is only 40Mb/s (out of 100) I don't think it's a huge issue. And this while being Slashdotted too.
I wish I had that kind of bandwidth :-).
Or maybe... (Score:5, Interesting)
Or maybe most of us are at work and are working on (relatively) stable workstations that we can't tinker with. I'm not a kernel hacker myself (I wait until a distro comes out with a new stable kernel and all the trimmings) but I can imagine that kernel traffic probably peaks after business hours.
Re:Or maybe... (Score:2, Flamebait)
Not everybody is at work, and although the US has a large number of the
My point is that you should be a little less US centric when contemplating something like Linux.
Same old same old
gus
Re:Or maybe... (Score:5, Funny)
Parent
New Scheduler (Score:2, Informative)
I believe there was some discussion of integrating Ingo's patch with the preemptive patch, should be good for everyone.
A link to his discussion http://kt.zork.net/kernel-traffic/latest.html#4 [zork.net] on Kernel Traffic.
Re:New Scheduler (Score:3, Informative)
Definitely - but you probably won't notice much difference on most machines - his scheduler was intended to address problems particularly with huge systems. A mere 1-CPU or 2-CPU machine isn't going to see the real benefits.
Which isn't to say the patch is worthless on anything less than 4 CPUs - apparently it beats the old scheduler on all benchmarks. But for most of us, scheduling doesn't take a lot of CPU anyway.
Re: benefits for UP and SMP machines (Score:2, Informative)
But you are absolutely correct in that the scheduler improvements will be more apparent and dramatic on 4 and 8-way machines because of the elimination of the global run queue. Each CPU gets its own run queue and processes will only bounce around when other cpu's are idle. We finally have a scheduler that will work on enterprise class machines.
Re:New Scheduler (Score:2)
I have a larger linux render farm and the machines are almost always at a +90% cpu utilization. The renderer is one master process and two children processes. All the systems are dual proc. The processes can and will run the system short on memory (1 or 2 GB systems) and sometimes it will hit swap, but this we try hard to avoid.
Will this new scheduler help such a system. I don't have a ton of processes to run, just a few hefty ones.
-tim
With the major restrucuturing finished for now... (Score:2)
Re:With the major restrucuturing finished for now. (Score:2)
Signal problems fixed - changelog (Score:2, Interesting)
Jakub Jelinek: fix Linux/x86 confusion about arg passing of "save_v86_state" and "do_signal"
Seems somehow appropriate. (the confusion, I mean... :) Anyways, what a bunch of prolific hackers. Some of these guys had changes or patches in nearly every pre version.
The changelog could be a bit more verbose, but otoh, perhaps these kind of descriptions are more thought-inspiring.
Updates to OSS drivers (Score:4, Insightful)
Re:Updates to OSS drivers (Score:2)
ALSA audio quality (Score:2)
It could just be linear versus logarithmic mixer settings, but that's not a sound quality issue.
If that were the case, you would just need to start turning up the volume at the mixer rather than turning up the pot on your headphone cord or your external speaker amp -- both of which will introduce additional "hiss".
Otherwise, this smacks of "psychosomatic bug" to me.
How to compile a standalone module? (Score:2)
It seemed that whenever I wanted to compile a module for some new driver, I would also have to recompile the entire kernel, otherwise the two wouldn't interract correctly (yes, I'm being vague. I think I would get messages about symbols, but it's been a while).
So, is there a way to compile a single module to run with a kernel that has already been built?
And what exactly does MODVERSIONS do?
Re:How to compile a standalone module? (Score:2, Informative)
after you configure the kernel, changeing it ONLY
by adding build as module, from something that was not buildt at all. then do a make modules ; make modules_install
this will make only the modules. nothing else.
Re:How to compile a standalone module? (Score:2)
This mechanism can be switched off in the kernelconfig (something about versioning symbolnames, quite early), or you could compile the module with the correct command-line to do symbol-versioning (AFAIR the version-header-files are made during make dep), if you do a ls -a in some path, where you compiled modules, you'll find hidden files containing the command-line that was used, maybe a 'make xxx.o' will do the job too).
2.5.2 is new, but what is coming? (Score:2)
Re:Cool (Score:5, Informative)
Linux Kernel Mailing List FAQ (a must read before submitting bugs or oopses) [tux.org]
Good site about kernel hacking (not just for newbies either) [kernelnewbies.org]
Parent
Re:Development is News? (Score:2, Insightful)
Re:Development is News? (Score:5, Insightful)
Reading LKML has been one of the most enlightening experiences. Following the conversations, reports, complaints and rants you can really piece together a very lucid picture of the very complex nature of large open-source projects. The whole process of kernel development demonstrates why open-source works; how hundreds, if not thousands, of people scattered accross the globe can work on a project; how cooperating with fierce competition produces results.
Some days it's like going to the pub and discussing politics. Other days its a horse track where betting takes place on patches. Still, other days its a battlefield where someone has to prove that he can match wits with his adversaries who are also hacking the kernel. Linux kernel development shows that when you embrace all those human traits (competitiveness, arrogance, violence, love, friendship, shame, curiosity, idolitry, desire, hate, intelligence, stupidity, humor, spite, disgust, altruism), and apply them in the appropriate places at the appropriate times you can achieve much more than if you listened to what you were supposed to do. Like all of life it is a seathing, organic process that becomes what it becomes through relentless change and its ability to fulfill a particular niche. The chemestry is the drive of the hacker; the elements are the lines of code: a primordial soup of abstract ideas.
Just a couple of my thoughts at 5:00am.
Parent
Well, it is significant. (Score:2, Informative)
This story is significant because this kernel is really the first tangible departure from the 2.4 branch. Initial USB 2, a very improved scheduler, and other improvements a changelog would do a better job than I of documenting.
Like it or not, these types of changes are significant. Things like schedulers and IO end up being the reason Big Iron companies choose OSes. If Linux is getting there, I personally want to know. If you don't, hey... just move on.
Re:Hardware support (Score:4, Insightful)
Parent
Re:Hardware support (Score:4, Interesting)
There's huge amounts of discussion going on in the lkml (Linux Kernel Mailing List) right now the autoconfiguration tool.
Parent
Re:Hardware support (Score:3, Informative)
Instead of bitching around in message forums with your 24.6k modem connection, why don't you spend the time researching what works under linux and what doesn't. Maybe you would have found that there are card readers for every digital film format (compact flash, smartmedia, memorystick, sd etc) that work under linux.
Or maybe, if you can afford "the outrageous price" for the HP printer, you can afford a win32 CD and perhaps then _you_ could do something more than "practice networking skills and use the internet! Whopity-friggin doo!". Or even a mac (which are not expensive compared to a PC. definetly not -especially the imacs).
"I'll do everything within my power, be it donating money to carrying your kids to soccer practice, if you folks will just start writing drivers!"
How about stop bitching and be thankful to the people that _have_ written the million lines of code (including drivers) that make linux usable and enjoyable for us. Oh and start running windows. I have a feeling you two will get along just fine.
There's a journalism gap (Score:2, Insightful)
Then as a customer I would buy hardware with that logo. If there are enough customers like me (and it probably doesn't take many), then at least a few vendors would become interested in qualifying for that logo.
Right now the market pressure of open-source customers is inchoate. It's also diluted, because a lot of people just work around the lack of vendor specs and get something to sort of work anyways (such as Lucent winmodems).
gphoto is a step in the right direction. They list the camera vendors that publish specs. When I bought a digital camera, I made sure to buy from one of those vendors.
Re:Hardware support (Score:2, Interesting)
When I purchased my Hercules Game Theater XP, there wasn't any Linux support. Yes, there was a CS46xx module, but it didn't work with the GTXP. I read the source and found Thomas Woller's email address and fired him off an email. Before I knew it I was asked what I would like supported from my device and asked to write up some information for Thomas to present to Cirrus Logic. Emails started to fly and Thomas started to send me drivers to test on my machine, which I would test and send him back my results. I was being placed into mailings with Thomas and many other developers including Alan Cox. It really was an amazing experience and gives you the true meaning of Open Source.
For a small part of time I was making a difference. I was taking what I needed but also giving it to thousands of others. Now there is a little part of me in every Linux kernel. I did not have to be a big programmer, just needed to contribute.
Re:Hardware support (Score:2, Insightful)
In many cases, the hardware manufacturer doesn't care about Linux support and refuses to release hardware specs to Linux driver/kernel/whatever developers (or anyone else except other hardware manufacturers who turn their chips to cards and so on). So, if your plea is directed at the hardware manufacturers, it makes sense. However, in most cases there is nothing most developers of Linux can do, so you may be barking up the wrong tree.
I remember when Creative finally released the first open source Linux drivers for the SB Live. Shortly after that, Alan Cox popped up, did some Linuxification to the drivers, and since then (more or less), the SB Live has been supported by the official kernel.
On the other hand, my Conexant [conexant.com] HCF modem is still unsupported, although we may see some drivers soon. In theory. Conexant has refused any co-operation (to the best of my knowledge) with open source developers.
Re:Hardware support (Score:2)
;)
Re:Honestly.. (Score:4, Insightful)
That gets pointed out so often that I'm doubtful about making yet anothe r reply to this, but...
First off we're dealing with a 2.5.x release here, the whole 2.5.x is a developement branch, which is not meant for normal users, it's for those developing or otherwise interested in hacking the kernel.
Secondly even for stable branches (2.2.X and 2.4.X and 2.6.X one day) it is recommended that normal users stick to vendor provided kernels. For example the RedHat released 2.4.9-13 is still a valid kernel. It contains a lot of fixes that came to linux kernele main tree after the 2.4.9.
The sad mishaps with 2.4.10 et al happened because at that time the 2.4.x branch were still the developement branch. The problems with those releases didn't involve those that used distribution kernels, only those that were either adventureous enough to try the cutting-edge stuff or mistaken into believing that every 2.4.x release was to be taken as the stable-release for the normal users.
Want stability? Stick to distribution kernels. Want to toy around and hopefully learn something while adventuring with a developement kernel? Head over to www.kernelnewbies.org and rtfm....
This is not a question of getting the latest and the finest, because for normal users the latest distribution kernel released is the finest in every practical sense. (either that or you might concider changing our distribution preference)
(and by a normal user I'm referring to a user not particularly interested in developing or otherwise hacking the kernel)
Parent
Re:Communication barrier (Score:2, Informative)
Re:After UDMA stopped working........ I am waiting (Score:2)
Which either means the 2.4 drivers are buggy ... or ... the 2.2 drivers aren't reporting your CRC errors.
Re:After UDMA stopped working........ I am waiting (Score:2)
Which either means the 2.4 drivers are buggy ... or ... the 2.2 drivers aren't reporting your CRC errors.
It's (probably) the latter; the 2.4 drivers report CRC errors caused during transmission along the IDE cables. You've (probably) always had the problem, now you know about it and should fix it (hint: start by buying some good quality IDE cables...)
--
Re:or.. (Score:4, Funny)
My primary desktop machine, which runs Linux just fine, is a Pentium 166 with 128MB of RAM. Will Windows XP run OK on this, or would I have to go out and spend money to buy a new computer? (Having already spent money to buy Windows XP.)
Oh yeah, I also have an original 3c905 Ethernet card (not 3c905B). Is that still supported in Windows XP? I ask because Windows 2000 no longer supports the 3c590, which is a similar (but even older) model.
Parent
Re:or.. (Score:2)
Perhaps a second mainstream branch should be started, linux-deprecated or something. Once hardware has been out of production for five years, move it out of the main kernel. The person that wants to set up a P120 gateway can, while allowing the newer kernels to stay fully up-to-date with much less legacy code in them.
Re:or.. (Score:2, Informative)
Drivers are pretty self-contained. The only problem with supporting old hardware is that when you change an API you need to edit all the old driver files. But if you happen to forget one, and it quits working, life goes on - until a user who has the proper hardware complains, at which time the driver is updated.
The model works quite well.
Now occasionally a single driver will keep getting extended until it supports a wide range of similar hardware, and at some point, the developers split it into an "old hw" driver and a "new hw" driver, possibly with some overlap. This happened a long time ago with the NCR 53c8xx driver, and more recently with the Tulip driver.
It's called "Linux-2.2" or "Linux-2.0". Both are still being maintained, by Alan Cox and David Weinehall respectively.
Re:or.. (Score:2, Informative)
...but 2.4 still includes support for all that legacy stuff.
Re:or.. (Score:3, Funny)
Also, I couldn't find the source code to ntoskrnl.exe. Nor the C compiler, for that matter. How am I supposed to use the system to solve problems if I can't compile and install software on my system? How do developers write and compile any code?
Re:O(1) Scheduler? (Score:5, Informative)
http://people.redhat.com/mingo/O(1)-scheduler/ [redhat.com]
I must say that after using it for a few days, I'm impressed. It totally changes the characteristics of multiprocess servers like Apache and PostgreSQL under high load. For example, I've run ApacheBench against a mod_perl script that queries a pgsql database, in the new scheduler I get a mean response time that is N*1.05*concurrency with a standard deviation of less than 1% of the mean. In the old scheduler I'd get a mean that is N*1.07*concurrency with a sd of up to 75% of the mean. So in other words you get essentially the same throughput with both schedulers (O(1) appears slightly faster in my limited testing). But what's more important is that in the O(1) scheduler everyone is treated equally - they all get served in 1.05*N*concurrency, no more, no less -- while with the old scheduler some requests get a response that's 1*N and others get a response all the way up to 4*N*concurrency.
IMHO, it's better to give everyone an equal level of service than to randomly favor one group of users over another.
Parent
Re:O(1) Scheduler? (Score:3, Informative)
According to the change log [kernel.org] ingo's scheduler changes _are_ integrated.
Re:O(1) Scheduler? (Score:2)