...the -mm patchset.
8% (186 votes)
...the -ac patchset.
8% (200 votes)
...the -pac patchset.
0% (3 votes)
...the -ck patchset.
10% (244 votes)
...the -lck patchset.
0% (12 votes)
...the -cko patchset.
4% (95 votes)
...the -wolk patchset.
0% (11 votes)
...the -folk patchset.
0% (4 votes)
...the latest -bk release.
2% (49 votes)
...the -mjb patchset
0% (4 votes)
...the -wli patchset.
0% (1 vote)
...the -tiny patchset.
0% (7 votes)
...my own set of patches.
6% (153 votes)
...no patches, I like it plain vanilla.
26% (643 votes)
...whatever patches my distribution gives it to me with.
17% (429 votes)
...another patchset.
4% (105 votes)
.../dev/null
13% (315 votes)
Total votes: 2461
-ck
-ck just rocks!
-ck just rocks! : Please explain.
Hello:
saying this is good. does not do much for us. Saying WHY this is good, is really good!
/dev/null rocks too!
/dev/null rocks too!
WHY??! BECAUSE!!!
Try it: get the patch...
http://members.optusnet.com.au/ckolivas/kernel/
and you know WHY!
Reiser 4
Now if Linus would only include Reiser 4...
Reiser 4
The patchset I use is http://hvk.sourceforge.net/, this includes reiser 4 as well as -ac.
And -mm.
And -mm.
Let's not focus on merging st
Let's not focus on merging stuff in as quikly as possible. Look what happend to freebsd, this 5.x release have so much new stuff in it, it's unstable,slow, let's call it not efficient enough for real time work. Linux is heading in a good direction. Lets first improve and stablize as much as possible, add focus on entropy harvesting optimizations as last, then add new features and loop this procedure. This will give us some kick ass results. :)
- Arvind.
Unstable
Things only get unstable because either too active development and not enough testing or bad quality control.
Huoh, we don't have infinite
Huoh, we don't have infinite resources. Just too less number of testers and developers.
Good words. I think also like
Good words. I think also like you, or we are in Redmond back..
FreeBSD5 isn't any more unsta
FreeBSD5 isn't any more unstable for me than either 2.2, 2.4 or 2.6 Linicen. But Linux is faster in microbenchmarks. But everyone says they are pointless :).
I agree btw, leaving code stabilize first is a good thing.
why use -ck when theres -cko?
-cko is basically -ck with a few more patches such as reiser4, inotify (needed for stuff like beagle, and is a much better method of identifying changes to files then FAM anyway), etc. So if you want to keep up to date with technologies, cko is great, and has the added benefit of the -cko performance enchancements (not sure how well those have been benchmarked though).
-mm I always have found a bit too buggy for me.. not sure how it is now, but even at 2.6.9-mm, after a reboot, my pcmcia died on bootup..
Right now though I use the vanilla kernel, and I'm going to patch it with inotify so I can start messing with inotify again (reiser4 turned out to be a disaster for me, so not trying that again for a while).
The rest of the patchsets I have either never tried, or barely tried.
Auzy
Resonance
(An attempt at creating the first internet based Zeroconf/service sharing system)
why use -ck when theres -cko
Because it offers me nothing extra that I want? I just want the performance enhancements of -ck, and the more patches you add the more chance there is for broken builds and instability.
nitro!
nitro!
agree..
I just switched to -nitro from -cko. I used to use wolk, but it seems to be slipping in the update dept. -nitro pays more attention to game performance than the others IMHO. Half-Life 2 in Cedega is proof enough for me. :)
nitro is for ricers. It h
nitro is for ricers.
It has no QA and will, for the most part, SLOW down your system.
Don't use it unless you're trying to be 'leet'. And if you are trying to be leet, please use another operating system.
Up to date
Patched with service pack 2!
my own...
vanilla patched with vesafb-tng and CK's staircase scheduler.
The ck patch set from Con (ma
The ck patch set from Con (many thanks for your work, Con) should Linus include in the next time as an option in the config for desktop users eg, which then switch to these fine improvements, or not for other users.
The last ck patches for 2.6.9 were so stable and fast with my Fedora 3 x86_64 GNOME system.
Stable Kernel
I think changing the CPU scheduler in a stable kernel is a bad idea, there is needs to more testing with different CPU scheduler design.
Problems
Not to mention the problems reported with the staircase scheduler in game (especially wine) performance.
There are something broken in 2.6.10-ck1
I compiled it with CONFIG_PREEMPT_BKL=y and my X crashes evrey now and then and I when I run sim all the gnome-panel gets broken. 2.6.10 works fine for my.
My patches
I have vanilla with Inotify and reiser4 patches. -mm has been to unstable for me.
-mm
-mm kernel seems to be frozen for a while now.
-kj from the fine kernel jant
-kj from the fine kernel jantitors is missing.
latest applies to 2.6.10, always also referenced in #kernelnewbies,
i'm running this one.
PowerPack patchset
http://programista.org/~snaj/
Site moved to : http://yoper
Site moved to :
http://yoper.bsdnut.org/yoper/non-yoper/
or
http://camis.info/patchset/
for now :)