2.4 vs 2.6 Linux Kernel Shootout

FyRE666 writes "Infoworld are currently running an interesting comparison of the 2.4 series kernel against the new 2.6 release on Xeon, Opteron and Itanium CPUs with some surprising benchmark results for common server-related tasks. Basically the new scheduler helps the 2.6 kernel to cream the old 2.4: Samba tests showing up to 73% speed increases, MySQL showing up to 29% and Apache serving dynamic content up to 47% faster!"

Comments

Error

[popa]

tried to get this in before you posted it... but dynamic only went up 22% for apache.... static went up 47%

And SCO shows...

[Black Parrot]

...a stunning 129% increase on SPEClawsuit!

Okay, so that's with the latest and greatest..

[spitefulcrow]

But how much of an improvement does it get on older hardware and/or software packages?

drugs are bad

[POds]

Okay, who's been feeding 2.6 speed?

Re:drugs are bad

[Rosco P. Coltrane]

Okay, who's been feeding 2.6 speed?

IBM, according to SCO.

May try it then

[Anonymous Coward]

I was wondering about upgrading to 2.6 from 2.4 with XFS on my box, with the improvements to SCSI support and the CPU speed ups it sounds promising :D

Then again BSD is very nice on the same hardware. Wonder how 2.6 linux & (free)BSD compare for those tasks.

Re:May try it then

[anthonyrcalgary]

Try them both to see which one is faster/you like more. And don't listen to anyone who tells you not to try the alternatives, they're probably zealots.

Don't let my sig fool you, I like Gentoo better on the desktop. It's just that little bit more convenient to get the latest everything.

Some stuff I can tell you:

• With ULE enabled on FreeBSD 5.2, I can't tell the difference. No formal benchmarks, but I did everything I could to expose stuff that might annoy me later on. Dragging windows around really fast with "display content in moving windows" on and music playing. The sort of thing that would bring Linux 2.4 to its knees easily
• FreeBSD 5.2 has some annoying things. Like you've got to manually enable the drivers for sound devices and USB mice. And you've got to recompile the kernel to get ext2 support. It's pretty easy and well documented, but you can't just install and have a working system with no additional work.
• Gentoo didn't (for me) have any major issues. I mean, compile times can be a bitch, but you'll be doing that on FreeBSD eventually too.
• FreeBSD can do some really nifty stuff that Linux can't. Like jails.

My advice is to wait until FreeBSD 5 hits STABLE and Linux 2.6 matures a little bit, install both, and see what's more fun.

Impressive

[mgv]

These are impressive improvements.

Its actuallly hard to believe that there is that much more improvement to be gained - it will leave the microsoft servers even further behind as I don't think that they are improving their kernel that fast.

One question:

Does this mean that we can see improvements in low end systems for desktop use, or is the benefit only for servers. Because if this helps low end machines, it extends further the number of machines that can move from (say) win 98 to a real OS, whose hardware has long been abandoned by microsoft.

Michael

Re:Impressive

[JebusIsLord]

well i know the preemtive and low-latency changes (while available as patches to 2.4) are included in 2.6, and make a significant difference to GUI responsiveness.

Re:Impressive

[zmooc]

I can now watch divx on my pII-233 with it. Xmms never skips and X remains useable under high loads. It's an incredibly huge difference to 2.4. But I only noticed when I had to go back to 2.4.22 to try out openmosix. It was absolutely annoyingly slow compared to 2.6.

Re:Impressive

[Serveert]

The pre-emptible kernel(you must enable this, it's off by default) will blow your mind when using a GUI. It is beyond impressive, it's like you're neo and you can see the mouse pointer before it gets to where you move your mouse.

You can grep your hard drive many times yet still browse the web with no slow down.

Linux in cache?

[SHEENmaster]

What I'd like to see is Linux that could run entirely within cache on the higher end chips. Even dated UltraSparcII chips can have up to 8M/cache. That's 64M in an 8-way box, allowing for some truly awe-inspiring performance on mathematical problems if RAM is ignored.

I haven't looked into sparc assembly enough to know if this is possible.

Re:Linux in cache?

[ParisTG]

Caching is controlled completely by the CPU, transparent of the programmer.

Assuming that the kernel is the only code running, and it is small enough to fit into cache, then it will get there eventually.

However, it would make no sense to keep the entire kernel in cache, since most of that code isn't used most of the time. Also, application software is running at the same time, which needs to be cached as well.

In other words, just trust the CPU. It knows what it's doing :).

Re:Linux in cache?

[runderwo]

Caching is controlled completely by the CPU, transparent of the programmer.

Only in some designs. Architectures like MIPS allow for both a cache-coherent or non-cache-coherent design. In a non-cache-coherent design, the cache is not transparent, and the kernel programmer is responsible for cache management; marking pages as dirty, flushing cache, etc. These designs are significantly more difficult to program and are present on some SGI machines, making porting to those machines a significant task.

Theoretically, higher performance can be achieved in a non-cache-coherent design, since the programmer would ostensibly know more about which data is most frequently used on his system and be able to customize his kernel for that. Also, it requires less glue logic on the board. However, the intent may be thwarted if the programmer doesn't have all the documentation (or skills) necessary to make efficient use of a software controlled cache.

Re:Linux in cache?

[lars_stefan_axelsson]

Caching is controlled completely by the CPU, transparent of the programmer.

Not really true these days. Some architectures do have an explicit 'cache preload' instruction, such as the SPARC V9 and the ARM9E to mention two. These allow the programmer to preload a D-cache line before it is needed.

As the speed of the CPU has increased much faster than the speed of main memory (and hence increasing the relative cost of a cache mis), compiler based techniques to emit cache preload instructions in advance, before the data is actually needed, has been the subject of some research in the past 7-8 years. The main reason to do it is software, instead of hardware, is that the compiler have a greater knowledge of the layout of the entire task, as it can 'look ahead' in the source code. The main disadvantage is that any static analysis, of course won't have access to dynamic (run time) data about the program as it is running.

If you wish to go further, you could do worse than to start with my former colleague Magnus Karlsson's PhD thesis on the subject:

Magnus Karlsson: "Data Prefetching Techniques Targeting Single and a Network of Processing Nodes". Ph. D. thesis, Department of Computer Engineering, Chalmers University of Technology, December 1999.

And of course as always, Google and citeseer is your friend.

In other words, just trust the CPU. It knows what it's doing :).

Well, actually, it doesn't these days... :-) Trust the compiler instead :-) (Yeah, right).

My thoughts...

[big_groo]

I haven't noticed *any* differences on the desktop. ALSA is nice, kernel config is easier, but other than that...nothing noteworthy over 2.4.19 (my last kernel). Am I missing something? Oh, and I *still* can't get my USB mic to work (help!).

Slackware with Dropline, btw. I do notice that Java tends to take up 250MB of RAM every once in a while while running Firebird. I didn't have that problem with 2.x.x.

Re:My thoughts...

[pacman on prozac]

My thoughts were, wow, much faster. I'm now running 2.6 on all my desktop machines and it flies. They "seem" much more responsive with 2.6 than 2.4, especially under load.

The initial boot time to load the kernel seems to have massively dropped although I could be imagining that.

The new build system in 2.6 definately rocks, forgot to compile something important in? No need to wait for * to recompile anymore, just the vital parts are re-done.

Re:My thoughts...

[echeslack]

I don't notice any real speedups, but I do not really notice updatedb running anymore. Actually that's not entirely true, I just notice it a lot less. Many times it will run and I won't notice it. The mouse used to start getting all sticky when I had too much disk activity. Now it *mostly* runs smoothly.

Re:My thoughts...

[owlstead]

No, you aren't missing something. Applications will still run as they did, except when they are heavily multithreaded. Starting up something CPU-cycle expensive and typing in open office might give you an idea.

But all in all, it's the kernel. End users should be nicely unaware of it. Don't expect any fireworks to go off, most of the time you notice a kernel you will have hoped you didn't :).

Re:My thoughts...

[shadowbearer]

Ditto here. I've been running the -test kernels on the faster machine since summer, so I can't remember just how much difference there was. I do know it was noticeable, tho. In particular setiathome used to noticeably slow the machine; now I don't even notice whether it's running or not. *grin* 2.6 definitely WU'ed me there *grin*

On the laptop I just compiled 2.6.1 for, however, (a 200mhz DEC HiNote) the speed increases are huge. You're not imagining the boot time drop - it's easily twice as fast on the laptop as 2.4.20 was. The GUI is also noticeably more responsive.

The new build system is great, especially on a slow machine :) Kudos to the kernel people, and thanks!

SB

2.6 on server?

[black666]

Those benchmarks are nice, but who runs kernel 2.6 on production servers that need every speed they can get? It will be a few more 2.6.x releases until I consider running one of my servers with a 2.6 kernel.

Re:2.6 on server?

[1000StonedMonkeys]

Well, yes, but it's a safe bet that the speed improvements in 2.6.0 won't disappear in later versions of the kernel.

NTFS Read/write support?

[lawpoop]

The chart on the first page says that 2.6 supports read and write for NTFS. Is this really the case? Does anyone trust NTFS writing if it's in the kernel?

Re:NTFS Read/write support?

[jensend]

The native ntfs driver supports writing only if the write operation wouldn't disturb any of the metadata- that is, you can't create or delete any files but you can safely overwrite a file if you don't change its size. This is more useful than it sounds at first- you can use a loopback file on the ntfs partition for anything you want.

Re:NTFS Read/write support?

[damiam]

The Captive project uses Wine technology to natively load the Windows NTFS driver. It's not quite as good as native, but it might fit your needs.

It's shame, really.

[Anonymous Coward]

It's not Linux 2.6.x, it's SCO/Linux 2.6.1.

Also notable....

[haggar]

..is the parformance of the Opteron. Looks like Linux 2.6.x and Opteron are a great combo. Okay, I admit, I was a bit skeptical regarding Linux 2.6, but it seems it might actually deliver.

I'm looking forward for Solaris + Opteron servers. Should be another interesting combo, performance wise. For one, Solaris 9 has some fantastic scheduling for multiprocessor machines. Additionally, it has been implemented in 64 bit for many years.

Re:Also notable....

[Doomdark]

I'm looking forward for Solaris + Opteron servers. Should be another interesting combo, performance wise. For one, Solaris 9 has some fantastic scheduling for multiprocessor machines. Additionally, it has been implemented in 64 bit for many years.

One potential concern, though, is that while there has been Solaris for x86 for a while, it's not really its main platform... so it's bit like waiting for 2.4.6 kernel on, say, Sparc systems. So I'm wondering if Solaris design of scheduling (and other kernel parts) takes some advantage of Sparc processor's design, that wouldn't map nicely into Opteron? In future this should get better (since Sun is now allied with AMD), but Solaris 9 was written probably well before x86 was seen as strategic platform for Sun.

Re:Also notable....

[paitre]

Sun is doing an Opteron-optimized build of Solaris, but don't expect it in the short term.
That's about all I can say ATM, but it -is- on the way...

Re:Where's the distros

[MarcQuadra]

Wow, you need to quit bitching. 2.6 will be in the distros 'when they're ready', do you remember all the really broken 2.4.x stuff? It was REALLY bad press for folks who COULDN'T UNMOUNT DRIVES safely.

Let the ubernerds self-build 2.6 systems for a while and work out more bugs. If you want it you can have it, but mass-distribution before we even hit 2.6.2 might be a BIG mistake.

Good to know that.

[nefele]

So if I use the new and improved herbal 2.6 kernel my processing power will be UP TO 150% BIGGER and my UPTIME will be 200% LONGER!!
And it's only $699 a box! ;-)

Time for some more FAIR benchmarks

[haruchai]

I'd like to see how Linux 2.6 stacks up against Windows Server 2003 now. This time, let's have Microsoft and Redhat or some other Linux gurus go head to head.
One of the good things of benchmarking at an early stage is that it may expose some hard to find weaknesses, much like the first Mindcraft tests exposed a kernel limitation which hampered Apache's performance.

Tests

[Sir Pallas]

I guess it's important to ask the following question: was 2.4 ever designed to run on those kinds of processors? I mean, the O(1) scheduler is a pretty cool, processor independant change; but was 2.6 designed with specific optimizations for newer processors (and newer instructions) in mind? I'd be interested to see benchmarks from old hardware -- i.e., stuff like I've got sitting around. (If only I had a bit more time. Maybe I can borrow some cycles from 2.6 Linux boxen.)

Re:I can't believe these results

[JumboMessiah]

Actually, it wouldn't suprise me if this is correct. If you notice, he was reading the 500MB file while a continuous streaming write was going on in the background. On 2.4.x, a write streamout will kill read performance drastically. Mostly due to the way the I/O scheduler schedules the read. Which, most of the time, is to stash it at the end of the writes.

The two new I/O schedulers in 2.6.x help to resolve this. For more info, check here.

backports

[POds]

for those who dont know, you've been able to get a back port of 2.6 on woody for the last month (almost).

so go get it, and tell me how it will effect my surfing, emailing, mp3ing and general userish behavour on my P2 400 128RAM...

Go on, get to it! :)

Re:backports

[shadowbearer]

I just compiled 2.6.1 for my 200mhz laptop (Debian unstable) and the speed increase - especially at boot and for Fluxbox - was very, very noticeable, particularly for cpu intensive apps.

I haven't noticed any breakage - not yet - the machine has only been up for 4 days running 2.6.1. But so far it's great :)

BTW I used the kernel source from debian, not the backport.

A question for anyone out there with a Digital HiNote 7xx series laptop; any idea which sound chip it uses, and how to set up sound? Google hasn't been very informative. (Not a 2.6 problem, I can't figure out which driver to use; most people seem to be using old SB compatibility, but I can't make it work :( TIA )

SB

Benchmark against vendor kernels?

[salimma]

No self-respecting large Linux distributor would ship a vanilla 2.4 kernel (well, SuSE does, but as an option, and not pre-compiled). The O(1) scheduler which AFAICT makes quite a large performance difference, has been available since RH9, IIRC, and presumably its contemporaries adopted it back then as well.

So it's not such a big leap for real users. Mind you, still a big improvement - especially for interactive use, and also considering that there are so many patches for 2.4 that are now integrated into 2.6, lessening compatibility worries (try patching Red Hat's pre-FC1 2.4 kernel source).

Real world vs. fanboy fantasies

[Anonymous Coward]

I am what most people would consider a highly trained technical professional. Unlike most people who spout off at this site, I have the certificates to prove this, and furthermore they're issued by the biggest software company in existence.

I know how to tell facts from marketing fluff. Now, here are the facts as they're found by SEVERAL INDEPENDENT RESEARCH INSTITUTES:

Expenses for file-server workloads under Windows, compared to LinuxOS:

• Staffing expenses were 33.5% better.
  
• Training costs were 32.3% better.
  

They compared Microsofts IIS to the Linux 7.0 webserver. For Windows, the cost was only:

• $40.25 per megabit of throughput per second.
  
• $1.79 per peak request per second.
  

Application development and support costs for Windows compared to an opensores solution like J2EE:

• 28.2% less for large enterprises.
  
• 25.0% less for medium organizations.
  

A full Windows installation, compared to installing Linux, on an Enterprise Server boxen:

• Is nearly three hours faster.
  
• Requires 77% fewer steps.
  

Compared to the best known opensores webserver "Red Hat", Microsoft IIS:

• Has 276% better peak performance for static transactions.
  
• Has 63% better peak performance for dynamic content.
  

These are hard numbers and 100% FACTS! There are several more where these came from.

Who do you think we professionals trust more?
Reliable companies with tried and tested products, or that bedroom coder Thorwalds who publicly admits that he is in fact A HACKER???

--
Copyright (c) 2004 Mike Bouma, MCSE, MCDST, MS Office Specialist

Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.2
or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
Texts. A copy of the license is included in the section entitled "GNU
Free Documentation License".

Re:Real world vs. fanboy fantasies

[mabinogi]

Its my experience that "highly trained technical professionals" would have enough real world experience to know the sort of crap code that can come out of any company...no matter how much money you throw at it, and that there's nothing inherently better about a product that costs money. In fact, it's been my experience that the more you pay for something, the crappier it is *cough*legato*cough*

Also, professional you may be (as in you get payed to do it), but you have very little professionalism if you have to resort to using terms like "open sores", not to mention the fact that you haven't got a clue what you're talking about due to your use of terms like "the Linux 7.0 webserver", "LinuxOS", and reference to RedHat as a web server, as well as referring to J2EE as an open source product, instead of the specification implemented by many proprietry application servers by companies such as IBM, Oracle, Borland and BEA.

I'm not even sure why I'm replying to this...it might as well have been generated by a script...

Re:Real world vs. fanboy fantasies

[Cobron]

Sarcasm just goes WAY over your head, doesn't it?

Re:Who cares? OS X kicks both.

[be-fan]

Actually the OS X kernel is about half as fast in lmbench (UNIX benchmark) as Linux 2.4. The OS X kernel is really antiquated. Much of it is 4.4BSD and Mach code. The GUI is modern, but the guts are ancient.

This can mean two things...

[SharpFang]

Maybe one of them, maybe both...

1) The new kernel is really very good.

2) The old kernel is really very bad.

Really, if such huge increase was possible, there must have been a lot of room for it. If you face a really well written program, you have a hard time to speed it up by 5%. If you can speed it up by 50% without loss in other domains, it must have been seriously flawed.

Yeah, mod me flamebait. But first think if I'm really wrong.

Re:This can mean two things...

[natmsincome.com]

Most of it has to do with the algorithms. For example I can write a really optimized bubble search but if you write an un optimized quick sort it will still be faster than my optimized bubble search. That being said any newbie programmer can do a bubble search but you have to know what you're doing to do a quick/merge sort.

So while 2.4 wasn't using the best solutions it was better than nothing. It's always better to have bad working code than great code that doesn't work. Hurd is a great example. It may be batter but it doesn't work (well enough for me anyway) yet so who cares.

IDE is another example. If I remember correctly 2.2 didn't have DMA support but it worked adding DMA makes it much faster but it would have made it more unstable if they added it at the beginning.

The last thing that you have to remember is that lots of the changes were taking advantage of features in the newer hardware. If you ran the same test on 486 you wouldn't get the same results as you'd have different bottlenecks. In another 10 years we'll get the same thing again. The might make it so that the bus to the memory is as faster as the level 2 cache on the CPU. If they do that they'll have to make big changes to the OS to get rid of the new bottle necks and you'd increase the speed by another 50% or maybe even 100%

Anyway that's enough ranting.

Re:This can mean two things...

[be-fan]

A kernel is much more complex than a single program. A program usually does one thing, and once you've optimized that, that's all there really is. In contrast, a kernel does all sorts of things. 2.2 was good for small-scale servers. 2.4 was good for mid-range servers. 2.6 is good for larger servers and desktop machines. 2.8 is supposed to get improvements to make it better on desktops and on huge NUMA machines. Linux has always been a fast kernel for what it did, its just that its doing a lot more today than it did a few years ago.

Re:This can mean two things...

[iabervon]

The old kernel had a lot of room for improvement on the systems they tested; but that's primarily due to the fact that the systems are substantially newer than the 2.4 series. A 2 GB dual Xeon system running 2.4 isn't going to use the processors efficiently (hyperthreading, imprecise locks), and isn't going to deal with the memory effectively. It was in part to take advantage of the availablity of such systems that the changes for 2.6 were made.

New conditions require new optimizations and new designs; a good program optimized for a set of inputs which are common at one time may be really inefficient at handling inputs that become common later. Sure, you can make a program that's good for both sorts of input, but it doesn't make sense to try to do so until someone actually has such an input to test with.

Naked eye test

[Zordas]

Yesterday I started a new Gentoo install with the 2.6.1 kernel. I used GCC 3.3.2 and glibc 2.3.2 with NPTL support. I have to admit, the naked eye can see a major diferance with the new kernel. With my XP computer and the new gentoo install (exact same computers .. P4 512MB) I ran a simple boot up and lanch a web browser test. And supprise supprise, Gnome is screamming fast. I had already booted and opened up mozilla 1.6 befor xp was even done booting! Also, simple stuff like opening up email, browsing, etc. is all noticable faster than XP. Soo... before I get slammed by the XP folks.. my XP box was also a clean install. (yes, I have no life!) I am happy to say I am one step closer to completely weening myself off of windows XP.

ahem...

[Apreche]

2.4 is the old and busted
2.6 is the new hotness

Re:Mystical Mozilla Speed Increases...

[Garg]

Sure, it's right there in the kernel:

if (strcmp(username,"ltorvalds")==0) {
gooseMozilla();
}

Garg

Re:interesting hardware comp

[Rob Riggs]

does it seem that the opteron smokes the itanium2 and xeon? this can't bode well for intel.

The comparisons won't make much real-world sense until the evaluation is done using Intel's compiler for the Itanium tests. The GNU compiler is just not up to snuff at optimizing for Itanium's EPIC instruction set.

I would like to see Intel contribute Itanium optimizations to GNU, but I doubt this will happen since they sell a competing product.

How does this compare to the BSDs?

[FFFish]

THIS IS NOT AN INVITATION TO A FLAME WAR.

Does anyone have factual comparisons of a reasonably-tweaked Linux (2.6 kernel) with a reasonably-tweaked [x]BSD (whatever kernel)?

Re:How does this compare to the BSDs?

[tarm]

Try this link.

It's an excellent comparison.

Singing to the Choir.

[tealover]

I wonder what the response would be if someone posted similar numbers about Microsoft's next OS. I'm sure they'd find creative ways to diminish the results.

One thing I've learned is not to take tech writers too seriously. Most of them are writers for a reason.

did I hear JOKE?

[tasinet]

i dont know if it's been posted already but check this. Aint no joke mister.

The root of all evil

[clasher]

Donald Knuth said "Premature optimization is the root of all evil"

Therefore I assume #1 is much more likely than #2.

It would seem as though the 2.4 focussed on getting a number of feature in the kernel while the 2.6 series allowed the developers to work towards making those new feature faster. Programming a new feature from scratch while also aiming to optimize it for speed can often lead to buggy code. Optimized code is rarely as straightforward and easy to debug as a more general (but slower) algorithm. When it comes to something as important as a kernel I'd much rather have clean, clear code which can later be optimized than a confusing kludge meant to squeeze out the last little bit of processing power.

Just my humble opinion

Re:RPM for Fedora (Yum) ??

[inode_buddha]

ftp ://ftp.dc.aleron.net/pub/linux/fedora/linux/core/d evelopment

Re:interesting hardware comp

[Hoser McMoose]

The hardware specifications weren't very complete, but from what I can see from IBM's x335 configuration they were using the no-L3 cache Xeons. A 3.2GHz Xeon with 1MB of L3 cache could easily boost the performance 10-20% over a 3.06GHz Xeon with no L3. Of course, the Opteron could still end up leading in a lot of the tests. What's more, the Opteron seems to really come into it's own in 4-processor configurations, where the Xeon scales poorly. In short, the Opteron is a heck of a good chip.

Where this really looks bad for Intel though is with their Itanium systems. Assuming that those 1.5GHz I2 processors are of the 6MB L3 cache variety, this is Intel's top-end chips. The servers probably won't have the performance of HP or SGI's I2 servers (IBM doesn't care much for the Itanium so they don't invest nearly as much time and effort in the designs as HP or SGI do), the chip still looks pretty weak.

Intel's saving grace here may be that the Itanium line of chips are VERY dependant on a good compiler, and chances are that these applications were compiled with GCC. Using Intel's ICC instead probably would boost performance by a noticeable margin, though a number of applications still won't compile with ICC from what I understand.

Re:RPM for Fedora (Yum) ??

[Anonymous Coward]

http://people.redhat.com/arjanv/2.6/readme.txt

Re:2.4 versus 2.6: file system performance?

[Debian Troll's Best]

Thanks for the suggestions hdparm, but since I posted my original comment my colleagues and I have decided on taking a hardware-oriented approach to solve our problem. Specifically, this will involve careful removal of the outer metal shell of each of the Seagate Cheetah SCSI hard drives from our RAID1+0 setup and making a few changes to the internal structure of the drive to effectively 'overclock' the hard drives. Let me explain

Stock Seagate Cheetahs use a fairly standard aluminium drive shaft, much like the one in a consumer grade piece of rubbish. We are replacing each of these with a carbon propeller shaft and light-weight fly wheel, which will increase initial acceleration of the drive platters, and will allow them to spin at a maximum speed of 17,500rpm versus the standard 10,000rpm. This should see our rate of apt-get transactions improve dramatically. But that's not all. As any good CPU overclocker knows, 'lapping' the contact surface of their heatsink will remove microscopic imperfections and result in a closer contact between heatsink and CPU. We too will be 'lapping' each hard drive platter. Of course this is dangerous to the platters, so we are always sure to use a fresh Kleenex each time. Once the platters are lapped, we can alter the suspension and damping characteristics of the read/write heads, making them float even closer to the platter and resulting in sportier turn-in, less body roll and more predictable handling even when dealing with 'rough' packages such as Troll Tech's Qt libraries which still have an aura of 'non-free' about them.

Finally we short-circuit resistor A24-J, which amazingly unlocks a special 'developers' mode of the hard drive, and firmware commands may be directly inputted using a text editor. We have developed a set of SCSI firmware routines which recognise the apt-get and .deb file formats even at the lowest level of hardware, offering stellar apt-get-goodness. Using a customised version of apt-get implemented in a mix of x86 assembler and Python (for the performance critical parts), apt-get is now able to bypass the Linux kernel, PC BIOS and the SCSI controller card, and communicate with the hard drive mechanics directly. This adds approximately an extra 60% to overall performance, to say nothing of the improvement in overall reliability and robustness.

We feel that these modifications will result in a drive array that will provide a superior platform for high-throughput enterprise level apt-get package management, regardless of filesystem. In fact we have very little choice about filesystem, since the lapping procedure with the Kleenex irreversibly etches tracks and sectors onto the drive surface. No need to worry about 5% of the drive being wasted on superuser-only space after a reformat! Now, I realise that these types of hardware mods may not be in the reach of all Debian users out there. I'm happy to discuss this further with the community if necessary. I am also creating a HOW-TO, which will be distributed via apt-get mirrors in the form of an 'info' document (man pages are filled with inaccuracies due to the inherently lossy compression techniques used in their production. RMS was really onto something with info!!!).

I look forward to the GNU/community's feedback.

Re:Requirements?

[The One KEA]

Check the Changes file in the kernel source. Basically any modern distro like Fedora Core 1, Mandrake 9.2, SuSE 9, Gentoo, Debian-unstable or whatever can all compile and boot 2.6 kernels without any real problems.

from the bang-bang dept.

[HalliS]

This is what the 2.4. kernel had to say about this:

Bang bang it shot me down
Bang bang I hit the ground
Bang bang that awful sound
Bang bang my brother shot me down

I was 2.4 and he was 2.6
We rode on horses made of sticks
He wore black and I wore white
He could always win the fight
...

Yeah, I know it's pretty crappy, but it's past my bedtime and I'm tired ^_^