It has nothing to do with the kernel. If you upgrade your operating system, all the supporting software is upgraded (think libraries). I am assuming you upgraded to slackware-current. This means you need to rebuild any binaries that required older libraries so that they work with the new libraries on your system. The old libraries no longer exist on your system.

EDIT:
For Slackware, you should only need to rebuild 3rd party software from places like SlackBuilds.org. Meaning, anything that isn't included in the official Slackware distribution.

mralk3 pretty much covered it. The other softwares you mentioned are all a part of Slackware, so Pat and team try to make sure that anything that needs recompiling after libraries change is done. They don't always get everything, and we noticed after the massive upgrade in April that some people were running into issues with certain programs. This is why -current isn't recommended for most users. It's always a good idea after a major update to check all your 3rd-party programs (like Chromium), and if they don't work, recompile or grab the latest package (at least in the case of Eric's builds -- since he is a core Slackware developer, he is usually pretty quick about updating his -current 3rd-party packages when updates require them.

As he said, this has nothing to do with the kernel, but all the other programs on your computer. You can upgrade the kernel as much as you want, with little to no effect on compiled programs. Upgraded kernels are mainly beneficial for hardware support, since that is an ongoing process. The 3.18 kernel introduced features (hardware h264 decoding) for my 7 year old graphics card, but installing that kernel won't stop any of my other programs from working.

Thanks....yes I get it now....

Patrick also says in an overall perspective that he does not presuppose how people will use his system and I choose to dismiss initrd. While omitting it is somewhat more complex for the User/Admin we are the ones with the brains so we rightfully IMHO should handle complexity so that our system builds do not. Obviously now, when I said "complexity" I was referring to the system mechanics. I don't consider compiling a kernel to be all that complex or troublesome and what's more important, high;y desirable for several reasons one of which being kicking initrd to the curb as apparently Alien Bob does or did as of this date Compiling Custom Kernels

If one never even sees the kernel config options how can one truly know Linux? More to the point since the default kernel is conservative in order to be "one size fits all" how can one so easily dismiss advantages on solid, modern hardware such as low latency and aggressive timing, required for machines purposed to multimedia work such as DAWs and Video Editing but a sweet boost for any purpose by not crippling good hardware to the lowest common denominator? Owning your machine on such a fundamental level takes around an hour, two at the most the first time... a small price to pay for such potent benefits IMO.

@enorbet: I see a misunderstanding or a confusion here.

PV's recommendation is actually to use a generic kernel over a huge one "as shipped" (that is actually an installation kernel).

This advice is implicitly addressed to users who don't feel the need to compile a kernel.

Of course that doesn't mean that a generic kernel should be preferred over a custom one.

But obviously Pat & team don't want to loose to their time answering support requests or bug reports to just find out that the issue is due to a misconfiguration, aka a PEBKAC case.

thanks...i saw it here...need to recompile chromium at home...and had already removed firefox package before..

so here's my impression on it, on PV stating of using generic kernel but he surely was comparing that to the huge kernel with respect to new users and older hardware into consideration...so kind of like say a step down in complexity...but custom kernel would beat it anytime....to go through the options and tweak your system to your own would be ultimate but fairly bit complex for the new users(need to understand the options for starters....)...so once they dwell into generic kernels then the next step is custom kernels the final pit shall we say?

in short:
simple -> intermediate -> expert
ie
huge -> generic -> custom (kernel)

@enorbet, I have no doubt that a custom kernel compiled to your machine is better than using the generic one shipped by Pat (if done properly). However, you may not see kernel compiling complex, but for someone who is just being introduced to Slack or someone who has never delved into kernel compiling, the first time is quite complex. In that case, it is much easier to create an initrd and use the sane defaults that Pat has set for the generic Slackware kernel. Once they're more familiar with the system and their needs, then they can look into kernel compiling. Back when I started with Slackware (somewhere in the 10.x timeframe), I had to do about a dozen kernel compiles over the course of a week so I could get my wireless working. I ran into a lot of kernel panics and other unexplained (at the time) issues. Once you're familiar with the process, of course it doesn't seem complex, but the first time you run make menuconfig and you're greated with the multitude of options, it can be very intimidating. Plus, depending on what you use your computer for, the gains seen in compiling a custom kernel for your machine may not lead to any real-world noticeable performance boost (many people won't notice if KDE launches a half second earlier or firefox opens up 100ms sooner).

Not everyone who uses Linux or Slackware wants to "truly know Linux", and this certainly shouldn't be a requirement. Plenty of people are happy using Windows without using regedit, just as plenty of people using OSX have probably never opened up the command prompt. Not everyone using Linux wants to be a sysadmin or a tinkerer. There may be many reasons people decided to switch to Linux, and we shouldn't assume it is so they can "know Linux". Hopefully that desire comes along later, but I'll still be welcoming to anyone who doesn't.

@nitecrawler, I agree. Once you start feeling comfortable with the system, it might be worth looking into compiling a custom kernel, but don't feel any rush to do this. While there can be some performance benefits, for most users, it probably isn't anything they'd notice without a stopwatch. The only reason I'm running a custom kernel on my machine is because the 3.18 kernel added new features to my video card that I wanted to take advantage of. Prior to that, I was plenty happy with the generic kernel, but I downloaded the source and dug through all the options and started from a 3.10.17 config since Pat didn't provide a config for 3.18 at the time. I don't do much that would see a tangible benefit from a custom compile, and once Pat made a 3.18 config available in testing/ on -current (this was before he made it the primary kernel for -current), I just switched to his config and didn't change many options and recompiled the kernel. Sure, if I unselected a ton of unneeded modules, my compile would've been much faster, and I might've seen some minor improvements in boot time, but it wasn't worth it to dig through all those options just for some minor increases. But kernel compiling is definitely a good learning experience, and once you feel comfortable to try it, I would highly recommend it just to learn how to do it.

While I agree that compiling a custom kernel can be a daunting task to the absolute beginner, I do not agree that it is any more difficult than learning any other task. Think back to the first time you booted up any operating system. It may have been Windows, or it may have been a Mac, or even Linux. The simple task of hitting the power button and watching the system start up is daunting to the absolute beginner computer user. Comparing one task to another and defining them based on difficulty is all relative. Sure, the first time is daunting, but that doesn't mean it has to be difficult.

If you like to dive right into new things without research, then you will find yourself in a difficult situation. This is the case for any task, be it learning to use Linux, or learning to play baseball. In this case, if you read the documentation you will bypass any assumed difficulty. If you get stuck, ask questions. It also helps to understand how search engines work so that you can most effectively use them to find the right information for your situation.

Should you compile a custom kernel? It really depends on how you intend to use your system. It also depends on if the stock kernel provides all the necessary features for your use case. However, I do not think that you should assume building a custom kernel is any more difficult than any other new task you have tackled in the past. I also do not think that building a custom kernel is a requirement for every Linux user.

I personally do what bassmadrigal does with the testing kernel config. I make a few changes to tailor it to my system. I do not go through the config and disable every setting I don't need. Sure, disabling unused modules is optimal. Doing so mostly just speeds up boot time and lowers memory consumption. I have in the past disabled all unused modules. How much did it speed up my boot time and lower memory usage? No clue. The difference is dismal.

My apologies if I seemed too forceful. It was certainly not my intention to assume everyone should be compiling a custom kernel. It was my intention to simply point out that it is an option with many benefits, even if only for the learning experience, but on solid, modern hardware many, if not most, users will feel it. IMHO as long as one learns to retain a working kernel in his bootloader there is no danger of a system that won't boot.... only one boot option that may not and even fixing that is beneficial if only in pride and confidence. It is common to feel as if one is playing with fire until one just bites the bullet and does it. The install disk rescue boot option is so good I really wonder why more distros don't have such a simple and powerful option. Chalk one up to PV's Baby.

The above linked Alien Bob page is an excellent walk-through. It is possible, using "make oldconfig" to simply handle the new stuff that pops up (which in most cases since it didn't exist before is not crucial to a working kernel so defaults are most often fine by a huge margin) and never even see the important options. I'd suggest that anyone using that method (or even on a working kernel you don't intend to modify by committing the config) to follow Alien Bob's instructions to run "make xconfig" just so you can see all 3 columns at the same time to get a glimpse of "what's under the hood". The 3rd column is the Help Section which explains a good deal about what that specific option does and why it is selected so. Some are as simple as "if you don't have a radio ham card it is safe to say "no" or "module" here".

In summary, if you are not motivated to dig deeper that is perfectly fine. If you are, don't be scared. It's not the bogey man most worry it is as long as you research and use safe practices like keeping your old kernel viable in your bootloader. Don't delete anything till your certain you no longer need it especially with hard drive space so abundant and cheap compared to a full Slack install unlikely to hit even 5% on most machines.

Two hours of my finite lifetime is worth it if I value the resulting payoff enough.

It used to make a large enough difference that it was worth it to me. Now, not so much, since a lot of the kernel parameters are tweakable via module options and entries in the /proc/ filesystem. But that's me and my system, not you and yours. De gustatibus non disputandum.

Let me step in in the hope to bring some more confusion.

I lost interest in going through each and every option long ago, but have to admit that as a remedy against insomnia it can be as efficient, less costly and less dangerous than medicines.

De gustatibus non disputandum? This is debatable. As said Paul Valéry in Rhumbs: « Il faut disputer des goûts et des couleurs. D'abord parce que toute dispute se réduit à cette espèce, et qu'il faut que l'on dispute. ».

Other than that I recently upgraded my kernel to 3.10.84 doing "zcat /proc/config.gz > .config; make oldconfig; make localmodconfig" then very few further tweaking.

Rationale:

• Configuration takes just a few minutes.
• Compilation is as fast as it can be.
• Resulting system is reasonably fast.
• Further upgrade in the 3.10 series will be as fast as this one.
• The kernel and modules stay small, that's good if you don't have a lot of RAM and space on disk.

Caveat emptor: only loaded kernel modules will be compiled so:

• Don't forget to first plug in all kind of removable devices you plan to use (one at a time hopefully as the module won't be removed as the device is), mount all partitions, etc. not to loose the support of your stuff. But having to rebuild and install some modules is also a learning experience
• Of course you'll have to rebuild out of tree modules like for VMs or proprietary video ones, but that's not specific to this target.
• To avoid the hassle of making an in initrd[1], don't forget to built the driver for the root's (/) file system in the kernel.

Have fun!

[1]and forgetting to mention it in lilo.conf and/or to run lilo after that...

2 members found this post helpful.

u can bet i'd give it a go...for the know how and learning experience...and with enough slack docs and a great team here to support you can be sure there will be very less roadblocks....