Very simple:
Compile ext3 into your kernel (make sure it's not a module, if you want to use it for your root file system).
Do a "tune2fs -j/dev/hdaX".
Reboot.
That's it.
The help for the kernel option tells you which version of the ext2progrs you'll need (at least 1.20 ?).
For those who have tried ext3 in 2.4.15:
Make sure you have reset the journaling flag on your filesystems, because your older kernel will not mount an unclean ext3 volume.
Do a "tune2fs -O ^has_journal/dev/whatever".
Are 5% speedup noticable ?
on
KDE 2.2.2
·
· Score: 2, Interesting
My general rule of thumb ist that a speedup below 30% for GUI applications isn't noticed by the user.
I don't really buy the argument that having many, many applications means that there is no shortage.
Think of the music recording industry: There are thousands of local bands with a lot of experience and most of them are turned down by the record companies. They still put out CDs by somebody who is already a star.
There might be a few who deserve a chance, but I'm glad they spare me all those who could be "trained".
That fix works nicely, but I prefer not to modify the kernel file, and inserted the code in bridge.c in/usr/lib/vmware/modules/sources/vmnet.tar (right below the include of linux/skbuff.h).
For reverse engineering like this I'd recommend SNiFF+.
It will read and analyse even code that can't be compiled right now. Works with C++, Java, Perl etc.
Slashdot Mirror
Very simple: /dev/hdaX".
Compile ext3 into your kernel (make sure it's not a module, if you want to use it for your root file system).
Do a "tune2fs -j
Reboot.
That's it.
The help for the kernel option tells you which version of the ext2progrs you'll need (at least 1.20 ?).
For those who have tried ext3 in 2.4.15:
/dev/whatever".
Make sure you have reset the journaling flag on your filesystems, because your older kernel will not mount an unclean ext3 volume.
Do a "tune2fs -O ^has_journal
My general rule of thumb ist that a speedup below 30% for GUI applications isn't noticed by the user.
Did anyone try KDE 2.2.2, yet ?
That is exactly my experience.
Using gzip reduces the amount of data and since sending the data is what takes up time, the server is free much earlier with gzip.
Having less concurrent Apache threads saves a lot of cycles.
I don't really buy the argument that having many, many applications means that there is no shortage.
Think of the music recording industry: There are thousands of local bands with a lot of experience and most of them are turned down by the record companies. They still put out CDs by somebody who is already a star.
There might be a few who deserve a chance, but I'm glad they spare me all those who could be "trained".
2.47 breaks the compilation of the vmware modules. If you need them, wait for an update from vmware until upgrading.
We allocate half of a monthly salary for training per year. So far it has worked out pretty well.
Take a look at http://www.willamowius.de/eiffel.html for a free IDE for Eiffel (actually a conversion of a C++ IDE).
That fix works nicely, but I prefer not to modify the kernel file, and inserted the code in bridge.c in /usr/lib/vmware/modules/sources/vmnet.tar (right below the include of linux/skbuff.h).
Beware: vmware 2.03 doesn't compile under Linux 2.4.4.
For reverse engineering like this I'd recommend SNiFF+. It will read and analyse even code that can't be compiled right now. Works with C++, Java, Perl etc.