Slashdot Mirror
Kernel 2.4.23 Released
MikeCapone writes "As if we didn't already have enough articles about Linux kernel releases, Marcelo Tosatti has released the final 2.4.23 Linux kernel. Check out the changelog at Kerneltrap."
← Back to Stories (view on slashdot.org)
Still no cryptoloop. CryptoAPI is in there. but the darn cryptoloop driver, which makes cryptoAPI actually useful isn't in there yet.
What a waste, all my USB keys and compact flash are encrypted. I guess I'll just see if OpenBSD supports my videocard yet. *sigh*
“Common sense is not so common.” — Voltaire
Was there ever a 2.5 Kernel? Did they ever do anything in that area or was that tossed into an enternal void? Just curious...
You've already been advised but let me add more weight.
:-)
You see that third number in the release? 2.4.x? It keeps going up, and the main reason for it going up is to fix bugs.
When the speed of increment slows, I can feel confident there are less bugs! Other people have suffered them, found them, and fixed them! Call me a freeloader...
Actually I have reported bugs in kernels before and got them fixed. But I don't find kernel bugs on production machines, I find them on test boxes.
Of course, if your don't care too much about stability on your box, that's fine, do what you want. But in that case, what is the point of your post?
Yours Sincerely, Michael.
Anyone else find it interesting that Intel is working on x86-64 code? Or am I reading too much into this...
len.brown:intel.com:
o [ACPI] fix x86_64 build errors
o [ACPI] fix x86_64 !CONFIG_ACPI build
o 2.4.23 build x86_64 build fixes
o x86_64 build fix from previous cset
o [ACPI] sync some i386 ACPI build fixes into x86_64 to fix !CONFIG_ACPI build
(Note some non-x86-64 changes omited from excerpt)
Wishful thinking probably.
I should not imagine even mission critical production environments sticking with 2.4 after 2.6 is released.
Nope. There is no way we will be moving to 2.6. The boxes we have running 2.4 now will be running 2.4 untill the day they die. I imagine any mission critical environments will be doing the exact same thing as we are.
With new servers you put into production, you may consider 2.6 depending on speed/feature requirements. But existing mission critical machines will never be upgraded.
Think about it, you have a machine and a system that is working. What exactly are you trying to fix? Make it faster? If it was too slow for you, you would have already bought more hardware. So, its not too slow, its been working fine and has been tested. You would have to be mad to upgrade the thing.
Mission critical boxes usually always keep the same kernel version until the day the die.
If he merged them, I would no longer have to fight my way around these two to manage to squeeze GrSecurity and FreeSwan on top, since the GrSecurity and FreeSwan crowd would have already done the work of making their patches compatible with a pre-emptive and low-latency enabled vanilla upstream source. For some reason, beleive I would not be the only one to cheer up if this happened.
Mario? Would you happen to be reading this thread and willing to explain your position in regards to this?
Software is not supposed to be about how to work around a useability issue. - Ken Barber
I have about 15 dual-processor machines with 1-2 GB that didn't work at all well with 2.4.x kernel. The memory management was simply crap. Forking a couple of copies of the program below consistently put the system into a permanent comatose state. (Search for 'kswapd problems' for discussion and ineffective patches.)
On the other hand 2.6.test11 works beautifully. For me, the 2.4 kernel is history.
int i; int k; char *j;
main(){
for (i=1;i2000000000;i*=2) {
printf("%d\n",i); fflush(stdout);
j = (char *)malloc(i);
printf("-- %d\n",j); fflush(stdout);
if (j == NULL) break;
for (k=0;ki;k++) j[k] = 1;
}
return 0;
}