| |||||||||||||
|
| |||||||||||||
The Linux Kernel's Fuzzy Future (InformationWeek)The Linux Kernel's Fuzzy Future (InformationWeek)Posted Dec 6, 2004 18:42 UTC (Mon) by allesfresser (subscriber, #216)In reply to: The Linux Kernel's Fuzzy Future (InformationWeek) by iabervon Parent article: The Linux Kernel's Fuzzy Future (InformationWeek)
I've been puzzled for a long time, (and this is no intended slight to you, iabervon, just an quizzical observation) that many people say it's impossible to run with a vanilla kernel.org kernel. I've *never* run a distribution-provided kernel--always a kernel.org variety--and have never had any problems with stability or dysfunctionality. I'm currently running vanilla 2.6.9 on all three of my machines at home and one at work, and they run like a charm. There's a mix of old and new hardware (Epia 600, Athlon 600, P4 2.6 and P4 1.0) and it doesn't seem to make any difference--the kernel just chugs right along. I'm running Slackware on all of them. I've run things this way since around 1.3.57, I believe... so I've had a while to observe... :-)
Am I just extremely lucky or is there something I'm missing?
(Log in to post comments)
The Linux Kernel's Fuzzy Future (InformationWeek) Posted Dec 6, 2004 18:57 UTC (Mon) by emkey (guest, #144) [Link] I've had fairly good luck with the generic kernel in the past. And in some cases I've encountered bugs in vendor kernels that didn't exist in the generic kernel.
In theory vendor kernels should be better since they likely do more formalized testing. In practice I doubt there is a huge amount of difference.
The Linux Kernel's Fuzzy Future (InformationWeek) Posted Dec 6, 2004 19:04 UTC (Mon) by maceto (guest, #16498) [Link] hehe you might have a point :-) it has something to do with the user, but I have to say there have been issues with the 2.6 series. And a more tested kernel (debian/redhat/suse) is more TESTED than a vanilla one and might have some bugs fixed, however there are called new/experimential stuff in the kernel and "non -essential/-server stuff" that one can ( yes it`s possible!) leave out...
The Linux Kernel's Fuzzy Future (InformationWeek) Posted Dec 6, 2004 21:49 UTC (Mon) by iabervon (subscriber, #722) [Link] Now that there's better communication and flow of patches into the kernel, the bugs fixed in a distro kernel will probably be also fixed in the vanilla kernel from the same time (which will be a later version than the basis of the distro kernel). The issue is the rate at which bugs which affect the function of features already in the kernel are added. It has seemed that almost all of the regressions have been caught quickly, were necessary evils to fix a more serious problem quickly, or involve uncovering BIOS bugs.
The Linux Kernel's Fuzzy Future (InformationWeek) Posted Dec 6, 2004 19:16 UTC (Mon) by iabervon (subscriber, #722) [Link] I've actually personally run only kernel.org kernels on my computers, although I've run distro kernels on all the computers that weren't my own. My experience is that kernel.org kernels rarely have problems, and I've never had any problem I couldn't solve by getting the latest kernel.org kernel. I actually ran 2.4.0 and 2.6.0 for at least a few months when each of these came out.
I believe the reason to use a distro kernel (back when it mattered) was that development kernels were frequently very broken, but stable kernels didn't support new stuff. It's plausible that, when Red Hat released their first 2.4 kernel which supported NTPL, that was a more stable kernel than the 2.5 kernel which was current at the time. So the argument is really that there are some kernel.org kernels which don't run (very true, especially in early 2.5), and that some distro customers want features not in any working kernel.org kernel at some point in time.
The Linux Kernel's Fuzzy Future (InformationWeek) Posted Dec 7, 2004 1:59 UTC (Tue) by error27 (subscriber, #8346) [Link] Slackware and Debian etc use more stock kernels than RedHat and SuSE.
I've seen tons of problems where people upgraded to a non-RH kernel. For example, storView broke because Apache broke because it was compiled specifically for one kernel. Or RPM stops working unless you look up on google that you need to export a shell variable. Or stuff uses feature that are in RH 2.4.18 kernel but are not included in the 2.4.20 stock kernel.
The point is that if you move to a stock kernel you might be downgrading even if the number is higher. Downgrading is a pain. If you downgrade from an SE kernel to a kernel from half a year ago then you get fs corruption.
The Linux Kernel's Fuzzy Future (InformationWeek) Posted Dec 7, 2004 6:13 UTC (Tue) by wolfrider (guest, #3105) [Link] --The only time I've seen problems when attempting to run a "vanilla" kernel.org kernel on a "Linux system" is with the Red Hat distro.
(Granted, it's been a few years since I even *touched* a RH box - but when they released a CD [~1998? 1999?] where you couldn't even **recompile the kernel** successfully with the **default software** after installation, I swore off RH forever... And switched to SuSE 7.3.)
--I've had good luck with SuSE, and even better luck with Debian (Knoppix.)
The Linux Kernel's Fuzzy Future (InformationWeek) Posted Dec 7, 2004 19:04 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link] the issue is that major standard kernel version changes useually require tool updates (2.4 to 2.6 involves changes to proc, modules, etc earlier versions had more changes)
if the vendor kernel is 2.4+200 patches implementing additional features then the toolset that is included with that kernel may be somewhere in between what 2.4 and 2.6 need and may not work with either a 2.4 kernel or a 2.6 kernel
RedHat has been the worst case example of this historicly (or at least the most visable) and preventing that is one reason why the 2.6 development is happening the way it is.
|
|
||||||||||||