Slashdot Mirror
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.
← Back to Stories (view on slashdot.org)
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!
-Billco, Fnarg.com
> 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
1 reply beneath your current threshold.
IANAKD (Kernel Developer) (but I do read the mailing list).
/usr/src/linux/main.c
IIRC, there is a potential problem with very fast (>2GHz) processors confusing the delay loop calibration.
Check out calibrate_delay in
It uses an unsigned long to count ticks. So, on a 64-bit fast processor, there's probably no problem.
On the other hand, I may be completely wrong.
It talks about a DALnet server running stable on 38.000 connections. I found this link on deamonnews a BSD site, and like them I'm quite curious about how well linux 2.4 networking works compared to the latest FreeBSD. The article is here
isn't that the true breakthru in 2.4? SMP scalability, especially the scalability of the new networking code? I'd really like to see SMP 2.4 vs. SMP 2.2 vs. SMP 2K.
Never meant half of the things I said to you. So you know, there's a half that might be true - G. Phillips
If, like me, you've been looking for a free NFS solution, you'll definitely want to try 2.4. There's really no other option at the moment if you need NFSv3 support, as well as reliable file locking (lockd on *BSD doesn't work worth a damn.) Client side NFS never worked completely correctly until 2.2.18, and as a server...I had to reboot it more than a Windows box and deal with stale NFS handles multiple times due to "soft down" situations. I've been using 2.4.0-test11 for about a month and a half now, and it has been solid. Granted, when I benchmarked it's performance against FreeBSD it got owned badly, but at least it can lock files correctly.
Bottom line, if you need a free high availability NFS server, 2.4 is a godsend. If you have the cash, I still recommend sticking with Solaris, however.
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!
Actually this is new. Previously to get PPPoE support (in a stable kernel) you had to install a kernel patch or use a client that runs in user land (e.g., rp-pppoe - which is excellent, thanks David). Now it's included in the kernel.
I agree with everything else, though. This guy needs a couple of good whacks with a cluestick.
Admit nothing, deny everything and make counter-accusations.
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 [...]
You don't even have to reach that far. Compressed video easilly grows to larger than 2 gb for any non-trivial project. For example, I used dvgrab to capture multiple small video clips[1] from my ieee1394 sony trv-900 camcorder and media converter (sony), then edited them together into a 25 minute home video. This is all using compressed DV format, which is small enough that captures work perfectly fine in realtime to ATA33 IDE drives (unlike traditional analog captures which demand much faster drives because the quantity of data is so much greater).
25 minutes of video, even in 4:1:1 or 4:2:0 compressed DV format, is way bigger than 2 GB.
My solution was to upgrade to kernel 2.4.0 (which is easy to do with Mandrake 7.2, as long as you do not compile in devfs support) with the ieee1394 fixes. I opted to use SGI's XFS filesystem (which rocks) but to get around the 2GB limit upgrading to 2.4.0 was sufficient (ext2 and reiser both worked fine for test files of about 5.5 GB in size).
[1]This is a limiting bug in dvgrab which segfaults at around 900MB, but works fine in "looping" mode with filesizes 900MB.
The Future of Human Evolution: Autonomy
and live audio events, as well. if I wanted to record several hours of audio (like a 6hour Grateful Dead marathon on my local FM radio station), I'd need much more than 2 gigs of contiguous storage.
until now, I've had to break my live music into 2gig or less segments. that sucked! now, with the limit removed, I just hit 'record' (well, I type record) then come back 6 hours later and hit ctl-c and voila - I have a large audio file that I can now cut at logical boundaries rather than physical ones.
(of course getting an audio editor to be able to read more than 2gig at a time will be tricky to find; linux is way behind the curve in this aspect; and winblows has problems (much of the time) with even 1gig audio files).
still, being able to store that much audio to disk is the first step. editing it in-place will soon follow.
--
--
"It is now safe to switch off your computer."
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.
Linux fan and Win32 developer
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.
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.
Need a Python, C++, Unix, Linux develop
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 ===========
Whilst it is true that no drive will supply a sustained 33mb/sec, this forgets the overhead inherent in the EIDE protocol itself, which can be up to 30% of the bandwidth down the EIDE bus. Also remember this is per drive too.
--
Blaming GW Bush for the Iraq war is like blaming Ronald McDonald for the poor quality of food.
I am still rather disappointed w/the problems w/AGP and DRI support in the kernel. Can't have that stuff compiled in and keep Netscape open for more than 2 mins.
.02
I am really having a lot of problems with it crashing X as well (dual heads). It may not be a problem w/2.4.0 but it seems to only have started when I upgraded the kernel.
USB is coming along but it is not yet at a point where it is useful enough for me to give it thumbs up. When my Intel Create and Share USB camera and my Cassiopeia link cradle are supported, I will jump up and down. Until then, it is just a novelty...
Just my worthless
If you're an idiot like me and know your way around Linux, but still can't get the hang of that 'new fangeld' kernel recompile thing, Linux Newbie is running a wonderful little Newbiezed Help File on How to install the 2.4.0 kernel under Rad Hat 7. Great for people who aren't yet up to the skill of 'kernel hacker'.
Hilary Rosen's speech was about her love of money and her desire to roll around naked in a pile of money.
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.
I have discovered a truly marvelous sig, unfortunately the sig limit is too small to contain i
> 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.
--
Sheesh, evil *and* a jerk. -- Jade