Slashdot Mirror
Linux Kernel 2.4.21 Released
An anonymous reader writes "After > 6 months of waiting, 2.4.21 is here. Lots of cleanups, and a patch which gives a MAJOR boost to the 'feel' of the system under heavy disk IO, especially on IDE systems. As usual, available from your local kernel.org mirror or ftp.COUNTRYCODE.kernel.org/pub/linux/kernel/v2.4/! Tidbit: 'Current bandwidth utilization 131.72 Mbit/s '." See the Changelog for new stuff.
Now to attempt to get it before it's slashdotted.
I was seriously starting to think the 2.4 series was dead in preparation for 2.6.0. The ChangeLog is impressive though.
Phathead
I wonder if they are planning on an official BitTorrent.
The IT section color scheme sucks.
Oh man! My 286 just finished compiling 2.4.20!
or
Oh man! I was downloading at 4000 K/sec before this story showed up. Thanks a lot Slashdot!
Random is the New Order.
Instead of downloading the entire kernel, download just the patch file if you are running the previous version. Then patch your source tree using:
/usr/src/linux /blah/patch-2.4.21.bz2|patch -p1
cd
bzcat
make oldconfig
Im in charge of keeping production servers up to date. Im using a 2.4.20-rc7.
should I go up tp 2.4.21
How often should I build the new kernels for production servers (should I even be using 2.4? ie, stick with 2.2)
Thanks for the Help!
Sigs are dangerous coy things
SCO won't be offering this new kernel for existing Caldera Linux users then?
Ha, I'm glad I have a life, unlike you losers! Knock yourselves out compiling the newest kernel; I'll be out having a blast with my girlfriend in my Porsche.
(Okay, okay; I'm sitting at home in my underpants reloading slashdot to see if new stories are posted. I'll go download it now.)
when our AIX licenses expire today.
$ cd /path/to/kernel :)
$ make menuconfig # Replace menuconfig with xconfig if you want
-Select the options you need in your kernel and save it
$ make dep bzImage
-Look in arch//boot/ for the bzImage file
-Install it for your favourite bootloader (grub/lilo) and reboot machine
-gloat
There is no patch for stupidity
Visit my blog
$ cp linux-2.4.20/.config linux-2.4.21/
$ cd linux-2.4.21
$ make oldconfig
But does it run linux?
In Soviet Russia, beowulf clusters imagine YOU!
Hoping RH pushes updated kernels for RH9. Piss-poor IDE disk performance is my one big gripe with my Linux boxen at the moment; whole machine feels like shit when something heavy is running the disk in the background. :(
All joking aside, I was in the middle of compiling 2.4.20 when I saw this article...
Man, can't a guy download a kernel via FTP without a bunch of armed dudes storming the place? Those SCO guys just don't know when to give it up.
Please help metamoderate.
When there's a compelling reason to upgrade. Those fall into two categories:
Any other reason is superfluous, especially for a server machine.
The kernel config writes a .config file in the source root. Use that. If you patch rather than grabbing completely new sources, you won't even need to worry about copying that file around (unless you do a make mrproper, which you probably don't need to do unless stuff starts breaking during compile).
Years ago, back when the kernel was being updated nearly every other week rather than once every few months (2.0/2.2 time frame), I would always download the very latest kernel and compile that. Coincidentally, I was also learning Linux at the time, so I didn't mind spending time on stuff like that, and I was in school which meant a lot more free time. These days, my only linux box is a server, so unless there's a security fix I'm inclined to just leave the box alone. It's certainly easer not to upgrade than it is to upgrade.
Wait, recompile my kernel on Friday the 13th? I think not ....
KARMA TAG! You're it.
Um, can I get mine without the SCO code, please? That Darrell McBride is a scary man:
That a new kernel comes out on Friday the 13th.
From the Release notes:
> o [Bluetooth] Use very short disconnect timeout for SCO connections.
> o [Bluetooth] Kill incoming SCO connection when SCO socket is closed.
> o [Bluetooth] Support for SCO (voice) over HCI USB
Are these the lines SCO's bitching about?
Sounded more like laziness than cluelessness/newbie-ism to me. If the person was smart enough to get a release candidate kernel onto his server, he's either smart enough to figure out if he wants/needs to update to the actual release or he's using a distro and should ask them for an updated package that is known to work with their other packages.
I do not have a signature
If the following are true, then the high CPU usage is expected:
-You have an IDE CD burner
-You are using IDE-SCSI emulation
-You are burning a CD with a blocksize other than 2048 (such as redbook audio, or (S)VCD, etc..)
If the above are all true, the ide-scsi emulation reverts to PIO mode. Supposedly this will be fixed for 2.6
From the Release notes:
> o [Bluetooth] Use very short disconnect timeout for SCO connections.
> o [Bluetooth] Kill incoming SCO connection when SCO socket is closed.
> o [Bluetooth] Support for SCO (voice) over HCI USB
Are these the lines SCO's bitching about?
Nope. SCO in the bluetooth world means Synchronous Connection Oriented link.
Used mostly with bluetooth wireless handsfree devices.
signatures pending - ansa@kos.to - (dont mail there)
Your writing on a Linux machine now?
Yippie! 2.4.21 is finally here! :) (I got it about an hour before the /. story showed up.)
:)
:) I'm going to try to get Slackware running on it. :)
They now have Opteron support in there.. I knew it was in the pre, I was just wondering if the new kernel or the rest of my hardware would show up first. I have everything for a dual Opteron system, except the processors and case. I'm so anxious, I'm going to burst.
( ) 386
( ) 486
( ) 586/K5/5x86/6x86/6x86MX
( ) Pentium-Classic
( ) Pentium-MMX
( ) Pentium-Pro/Celeron/Pentium-II
( ) Pentium-III/Celeron(Coppermine)
( ) Pentium-4
( ) K6/K6-II/K6-III
( ) Athlon/Duron/K7
(X) Opteron/Athlon64/Hammer/K8
( ) Elan
( ) Crusoe
( ) Winchip-C6
( ) Winchip-2
( ) Winchip-2A/Winchip-3
( ) CyrixIII/VIA-C3
( ) VIA-C3-2
I'm going to be a compiling fool when the rest of the parts show up.
Serious? Seriousness is well above my pay grade.
He could be running a 386 emulator on his 286.
;)
Or maybe he's cross-compiling.
Or...
Shut up
http://osiris.978.org/~brianr/torrent/linux-2.4.21 .torrent
- Removed offending SCO source code.
- Replaced offending SCO source code with ASCII art of a middle finger.
Why would anyone download multiple Debian CDs before installing? That just doesn't make sense. The most you should download is a 150 meg bootable CDROM image, then let the rest of the packages you want come over HTTP when you choose to install them.
Debian prides itself on an enormous amount of packages... nearly twice as many, counting bytes, as RedHat provides. To attempt to download "a copy of Debian" is wrong and wasteful. The fun of Debian comes in when you decide, on the spur of the moment, to try some exotic free software program and can apt-get it in a much less time that it would take to even figure out the name of the RPM you'd need to install on a "normal" Linux system.
Even if the desired install computer doesn't have fast internet access, burning 7 CDs is excessive. There probabably won't even be 2 CDs worth of packages you really want to install. Of the top ten largest packages in Debian, six of them are only desirable for hardcore software developers.
Just finished reviewing the ChangeLog. Did anything not get touched this time? Good lord, there are arcnet patches in here.
Also, when does Alan Cox sleep? Prehaps he's a new form of undead with an affinity for coding? Maybe he has cloned himself a few times? Alan, however you're doing it, we appreciate all of your hard work. Now go take a nice, long nap.
the no
Yes, I have heard of the great "apt-get" and will definitely exercise it a bit.
Even if you install packages from CD-Rom, you'll use the same interface as if you were getting it live from HTTP. The only difference is that it'll prompt you to insert the right disc first... and since most packages are small, it'll often take more time for you to find the disc than to just get it from the server.
You didn't mention if you had downloaded the stable or testing Debian... testing is generally prefered, because it's not as painfully obselete. If you value stability, "stable" is good of course. But if you want to have fun and experiment, then newer is better. And if you're using "testing", then you'll probably want to keep up with changes made after the CDs were burnt. Debian "testing" CD-Roms go obselete really fast.
I don't know why you have a problem with the naming of RPMs. I find that it is usually the same as the program or package name.
RPM names also contain at least the version string, and often an indication of which architecture the software will run on. Sometimes supported OS versions are mixed in too. For example, when I tried to install a package on a Red Hat system, I had to download that RPM. Then go to install it, and find out I needed multiple other RPMs first, which need even more RPMs to work.
The point of apt-get is you, the installing user, never even see the *.deb file that the package actually comes in. The hunt for dependencies is completely hidden from you.
Of course, RedHat users can optionally run apt-get themselves, but that's not formally supported by the distribution developer.
I won't go into the whole problem of not getting *.deb files for new, bleeding edge software. It's an accepted fact that Debian users who wish to try something brand-new will be compiling it themselves.
If you do then you should also get Jeff Garzik's new sata as scsi stack patch and use that.