(old)Puppy Linux Discussion Forum

Hello,
jrb explains here how to update the kernel in a puppy version. For my education, can someone please explain why I would want to do that? What is different from one kernel to another? Thanks!

Support for new hardware has been added and bugs have been fixed. Larger hw support is main thing. Support for new graphics, chips, multimedia apps, dvb-dvc-tuners, wireless, whatever you can connect to the comp.

The newer the desktop and especially laptop, the more you benefit from newer kernel.

If you dont have unmet needs, dont update. Which aint broken, dont fix it.

Wognath wrote:Hello,
jrb explains here how to update the kernel in a puppy version. For my education, can someone please explain why I would want to do that? What is different from one kernel to another? Thanks!

Newer drivers or modules/better compatibality with newer hardware. So instead of replacing all components like with a newer puppy release (ie. modules, newer versions of programmes, etc.) only the newer modules/drivers will be replaced. There is a bit of silliness to it, I must agree. It will be better just to use a later Puppy if newer hardware requires.

The idea of building drivers and keeping a kernel version for a while tends to be used in other distros like suse.
Tempestuous does a jood job of building drivers for existing pups.
I updated alsa in one pup thanks to Patriot.
Otherwise there is a general idea that hardware support is limited to a specific kernel version when in fact the changes are to do with core kernel system functions and the drivers just happen to be the ones around at the time of the build/release.

Mike

Hello,
Well, for example, pae kernels enable >4gb ram.
Newer kernels mean newer driver support, embedded features, etc..
Smp, timer hz, tickless, rt.
I believe uefi support is next.

The only fly in the ointment is kernel mode setting for video...this has tied to a certain extent kernel to xorg to video hardware.

I also built the full recent release video4linux set on a 2.6.24 kernel not that long ago so giving support for recent webcams, TV cards and so on to a 5 year old kernel.

mike

Thought I would reply to myself.... I get less abuse that way

Actually the only time I have changed kernels was 1....missing features due to being too cut down (SMP, IDE/SATA) and 2...bugs . Both appeared to be errors or omisions in the build config rather than a need for a version change.
In the case of 2 there was inability to use a range of wifi drivers, excessive cpu usage burning audio CD's and a hard system lockup when sharing a FAT partition over NFS....all cured with a build 3 minor versions older.
With hardware changes I just built the driver(s).

As someone pointed out a while ago on here a kernel change is the equivalent of a new release of windows and/or a service pack. Chasing the holy grail of a golden kernel that will support every piece of hardware ever made for an IBM PC does seem a bit of a curious challenge. Microsoft sit there with an NT kernel bought and paid for that apart from the early days only seem to have superficial changes in order to obsolete their previous releases. Bugs and bluescreens are in the domain of drivers most of which are the responsibility of those who make the hardware. Quite a different model but one that has had an empire built on it inspite of some howling software blunders.

I like progress but am not a fan of chasing the wind.... me legs are too short for that

mike

pemasu wrote:If you dont have unmet needs, dont update. Which aint broken, dont fix it.

Wisely said.
Specially if you consider that newer kernels may not support older hardware (check kernel list for drop support) or introduce bugs (check kernel list for regression) and that older puppies (4.x and early 5.x) may not support newer kernels.

Thanks for the informative replies.

Is it at all possible that these newer kernels have had some underlying code cleaned up, resulting in greater overall efficiency/speed? As a newbie/hobbyist/hack who's been distro-hopping for the past two years, it just seems to me that many of the newer releases I've tried with later kernels (like, say, about 3.8.x-ish and above...?) tend to feel smoother/snappier and appear to be a bit less CPU intensive as well (memory... not so much). No hard data to back that up, but it sure seems that way - enough so that I'm considering playing around with updating the kernel on one of my Puppies, just to see...

Moat wrote:Is it at all possible that these newer kernels have had some underlying code cleaned up, resulting in greater overall efficiency/speed? As a newbie/hobbyist/hack who's been distro-hopping for the past two years, it just seems to me that many of the newer releases I've tried with later kernels (like, say, about 3.8.x-ish and above...?) tend to feel smoother/snappier and appear to be a bit less CPU intensive as well (memory... not so much). No hard data to back that up, but it sure seems that way - enough so that I'm considering playing around with updating the kernel on one of my Puppies, just to see...

I suppose it comes down to personal experience. Puppy 412 is working best for me.

Its a mixed bag... there could be inprovements in cpu and other hardware handling , memory management.... especially if it involves recent technical changes. As a crude example kernels from puppy 4 apparently cannot use more than 2 cores and Lucid was set to 4. But we could be talking of utilising new instructions, pipelining tweaks, better memory management.... so yes there could well be an element of that going on. You also may be benefitting from the distro having improved its user space binaries ..eg udev or streamlined its wrapper scripts.

When I tried slax 7 for example up to reaching kde4 desktop it was faster compared to 6... as far as I could tell its was a combination of all 3. It also had some horrible kernel bugs and was a no go on some machines too so we won't go there

So for core system handling on a recent machine there could be a benefit..if you need support on an older machine for a wifi dongle then build a driver.

mike

mikeb wrote: So for core system handling on a recent machine there could be a benefit..

Hmm... interestingly (well... for me anyways ) all of my experience has been on older, dual-core Intel machines (vintage 2003-2006). So it seems possible that there may be a benefit to running a later kernel on some older hardware, as well. Some... maybe...

I yesterday downloaded PeeBee's LxPup-13.11-s-pae (kernel 3.10.5) - will have to give that a spin on this older hardware!

Bob

good question, added to wiki
http://puppylinux.org/wikka/Kernel

This a good question which tends to bring in a large number of answers
A similar enquiry of what determines which machine will be faster had similar results.
Hi moat....
Dual core has been supported in puppy since 4.xx so generally you are covered.
Its also hard to make general statements or measurements as to what will be better as there are factors other than the kernel involved. Also who wants to spend the time changing one section of a distro at a time to determine whats makes a difference...ok some do just that but changes happen so fast your weeks of testing become old news before you get to type them up...or it seems that way.

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.

mike

mikeb wrote: 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.

mikeb wrote: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

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.

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

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.