Why update the kernel?

[Moat]

Its also hard to make general statements or measurements as to what will be better as there are factors other than the kernel involved.

Absolutely - understood. It's just a subjective impression of my (actually quite limited) experiences so far. It would be neat to compare some objective performance data between different kernels running beneath the otherwise same OS.

One thing is sure is that you ARE free to fiddle and tweak if you have the urge... I guess that keeps many of us here instead of getting bored on windows.

Puppy being so small and easy to backup makes it a great, educational, "fiddle and tweak" OS, IMO. I've been having a ball tweaking/breaking/fixing things - and gaining useful knowledge along the way.

Bob

[puppyluvr]

Hello,
For me, since I have a single core machine, I build 1000hz kernels.
Much "snappier" for single core, but not good for multicore machines.

[mikeb]

Very Happy Hello,
For me, since I have a single core machine, I build 1000hz kernels.
Much "snappier" for single core, but not good for multicore machines.

Definately a case of best tool for the job... the word compromise comes to mind. If you build for your own needs then much tweaking is to be had but making a general realease has to consider a wide pool of users.

mike

[amigo]

There are about 1,000 new submissions of code which are added to the kernel source -every day. A good bit of that code is bugfixes and the rest is code for new functionality or hardware support. Every single line of the new code *and* the bugfix code potentially has new bugs, or regressions -which means that something that used to work no longer does. This is aside from intentional deprecations of old features/drivers, etc which also occurs constantly.

Picking the right kernel version and patch level is critical and cannot be done by a single person -but there are plenty of folks out there lending their experience and one can find many workable versions -even multiple kernel versions for a single release. And of course, any user can always use a much newer kernel and modules than that the distro was released with. It is not as flexible if you want to run an older kernel as the released glibc controls how old a kernel it can be run with.

My advice is, if a certain kernel and modules work well for you, then stick with it. Most security vulnerabilities in the kernel do not affect non-server system setups, and when they do and are fixed in the current kernel cycle, there are often backports to several long term service versions of the kernel.

If you are always trying out the very latest hardware, then you'll need to experiment with very recent kernels to get the best out of the hardware -but your choice has already shown you to be adventurous, so learn to configure and compile kernels. You don't have to run a complete different OS to use a range of kernel versions.