2.2 vs 2.4

bevo wrote to us with a shoot-out review of kernel 2.2 vs 2.4. It covers what's been updated, some benchmarks, and also has a good page on how to compile your own kernel, including modules recommendation and such.

Comments

Good Fnarg! that article is so full of shit.

[billcopc]

I don't get it.. this guy sounds like Steve Ballmer on pot.

In addition to this robust filesystem support, the 2 GB file size limit has also been done away with -- although I don't know exactly who has 2 GB files sitting around on their platters

How clueless can this guy be ? If someone went to such great lengths to defeat the 2gb limit, then I'm pretty sure it's because it's been a problem for a while. Uncompressed video comes to mind, where a reasonable clip bucket can contain well over 10gb of data. Databases also get pretty huge when you start collection data from the web (search engines perhaps, or DoubleClick stats). Next.

Also, at the speed processors are progressing at (we're already at 1.5 GHz), the 2 GHz mark is coming soon -- something Linux 2.4 adds support for.

Ok, will someone tell me how the hell you add support for speed ? Ok so 8 years ago we had a problem with Turbo Pascal's timing loop overflowing, and they all learned to never write such stupid timing code ever again. What could possibly work on my p3-850 that won't work on a 2ghz cpu (besides CGA Pong) ? Software doesn't need to know the speed of the supporting cpu, it just needs to do its thing as fast as it can, and wait if absolutely necessary. Timing is important in code (especially games), speed is not. Speed is merely a byproduct of time.

Linux 2.4 adds support for Wireless LAN devices and also includes PPPoE within the kernel itself

Funny, I thought anyone could include PPPoE in the kernel when configuring it for a recompile. Perhaps he could have mentioned that it was enhanced and tweaked, but saying it's included in the kernel is like saying your brand new car comes with a steering wheel. Du-uh!

Well that's about all I could squeeze out of that one page of blab. Have a great kernel!

Re:2.4 Rocks

[f5426]

> As far as using it as a server, 2.4 is FAST. Much faster than 2.2. Our SCSI RAID goes about 3x faster and NFS goes twice as fast (over gigabit ethernet).

Rotfl. So does it means that 2.2 sucked despite all the claims that it was a server-class OS ?

I used 2.0 and 2.2 for a loooong time. A lot of things sucked badly (overall, it sucked less then the NT4 boxes I rhad), but I generally got bashed when pointing those suckage. Now, it is pollitically correct to talk about shortcomings of 2.2 ? (As long as I don't point any 2.4 problem...)

Cheers,

--fred

My take on 2.4.0

[mike_diack]

I've tried 2.4.0 for a while now and am loving it
with one exception:
I can't get the joystick support working for
my Gravis Xterminator in my SB PCI 128.

I can get it fine under 2.2.17, 2.2.18 and 2.2.19
pre, but not 2.4.0 (xmame just ain't the same
without it!)

But otherwise it's lovely.... It is discernably
faster in use than 2.2.18(ish) which itself
is discernably quicker than the early 2.2.x
series.

Fluffy article - memory management?

[Omnifarious]

This article is almost completely useless. It tries hard to pretend to have hard technical data and all it has is fluff. I don't understand how anybody could've seriously written that piece and expected it to actually help anybody understand anything.

While all of these new updates are fine and dandy, the inner-workings on Linux are the things that probably need the most updating. Yes, Linux is working its way up, but its way of doing many things are a rather abstract way at times or often very close to that of its older brother UNIX. One rather non-standard way Linux handled memory was an old UNIX way, which is very obviously proprietary. Linux is now in the future of memory and works in a more standards-compliant way of doing things -- which is what Linux is all about if you ask me. Although, Linux still remains compatible with the old UNIX-style way of managing memory, just as it does with the new controversial filesystem, DevFS.

What did that paragraph actually tell you? Almost nothing. Some vague hand waving about memory management with no specifics at all. Irritating!

I'm actually seriously interested in what kinds of changes were made to the VM subsystem. I know that's what held up the kernel for several months, and I want to know what was done.

Re:More to installing 2.4?

[Ateocinico]

I have the same problems with linux-2.4.0 and
the reason can be found in archive:
linux-2.4.0/Documentation/Changes
There states that newer versions of system utilities need to be upgraded.
The list of minimal versions for some packages
is this:

(copied from the Changes file)
============ begin ==========

o Gnu C 2.91.66
o Gnu make 3.77
o binutils 2.9.1.0.25
o util-linux 2.10o
o modutils 2.4.0
o e2fsprogs 1.19
o pcmcia-cs 3.1.21
o PPP 2.4.0
o isdn4k-utils 3.1beta7

============ end ===========

Re:Good Fnarg! that article is so full of shit.

[Royster]

A speed issue would be a delay loop overflow, but anyone still using counter-based delay loops should sit down with a game developer and learn about more robust throttling methods. Every decent computer architecture has a system clock that can be used to accurately measure time in tiny increments.

You've seen the BogoMIPS reported in a Linux kernel boot? That measure is reported when the kernel calibrates a certain timing loop which it uses for microsecond delays. There are some *very* good reasons why the kernel still uses timing loops not the least of which is that the gettimeofday() syscall is much too slow for the kernel to use for this purpose.

Believe me, the kernel developers know what they are doing. If you doubt that, spend some time reading the archives of the kernel development list or the weekly Kernel Traffic summary.

Re:USB

[Black Parrot]

> Can anyone comment on what to expect from either that or why I shouldn't worry that we'll get everything supported 'in house' despite proprietary device vendors?

I can't really answer your question, but I wanted to make the suggestion that if vendors of proprietary devices only support Windows, the solution is not to switch to Windows, but rather to use something else and forego their devices just to spite them.

If we give up and just go with the flow, we are essentially rewarding the behavior that we want to change. That isn't the recipe for success.

I recognize that not all vendors will ever provide open source drivers, but we could at least expect drivers for OS OSes.

In principle I don't object to closed-source drivers, but with the proliferation of spyware and other badbehaviorware, I'm getting to the point that I don't really want to run anything closed on my systems. However, it might be better to postpone that battle for now, and concentrate on getting drivers, open or closed, for alternative OSes.

On the bright side, I notice that Linux 2.4 supports I2O, which if I understand correctly is a protocol for OS-independent drivers. If we could get vendors to ship I2O drivers with all their nifty toys, Linuxers (and others) would be in as good a shape as Windowsers as far as device support is concerned. And it should be in vendors' best interest to ship I2O drivers, because that would let them maintain one driver and sell everywhere, rather than limiting themselves to a single market or having to maintain multiple drivers for multiple OSes.

Of course, with Windows running on 90% of the world's desktops, some vendors may not think that their slice of the remaining 10% is worth bothering with. There's an unfortunate focus on the mainstream in commerce these days.

And of course, MS may be subsidizing some of them a la OEM agreements, with an explicit or tacit agreement that they will only support Windows. If that turns out to be the case, that's all the more reason to shop elsewhere.

--