3.10.17 is getting a little long in the tooth. IMO it is worthwhile building the latest 3.10.y kernel, even if you build it using Pat's stock 'generic' kernel config file and make no other changes to it. I'm not suggesting one should build every 3.10.y that comes along, but I believe it prudent to catch-up every once in a while.

2 members found this post helpful.

Thanks for all the replies. And yeah, I'm only really messing around for educational purposes.

I'll accept something like 'not particularly' as a solution here. I'll probably play with kernels still. Nothing will come from sitting around on my desktop waiting to be an expert, right?

Check out AlienBOB's wiki on how to build the kernel. I always just do some minor changes like Preemption model. I change it to Desktop. I've also started disabling the kernel debug as it could potentially make your kernel faster, but I don't have any concrete numbers to back that up.

A generic kernel is fine, and Pat's is top-notch....HOWEVER as he states, he does not impose his views by assuming he knows what users wish to do with their PCs. If you are building a DAW, or even merely heavily involved with multimedia, including gaming, there is very definitely advantage to be had in creating a low-latency and/or realtime kernel. "Huge" and "Generic" in Slackware's case are not just cute names, but rather functionally descriptive. Choose according to your taste, jobs, and skillset. "One man's meat......"

1 members found this post helpful.

This may be useful:
http://docs.slackware.com/howtos:sla...git_repository

A "localmodconfig" kernel can be a pain in the arse, especially when introducing new devices. Unless you're really low on RAM building smaller kernels has little benefit. (being faster to build is the greatest benefit IMO)

localyesconfig kernels can be a bugger to get working on some hardware - I've always had trouble with framebuffer/display devices.

I've also had USB HID problems with both types of kernel and had to use an initrd anyway (no idea why).

I like the generic kernel and just base my kernels off that one with minimal changes.
It's good to experiment though.

I update my kernel regularly, so I need it to be stripped down. It's not that difficult, but is time-consuming. I'm not gonna stop doing just because of that tho. I set aside a few hours and do it once per system and maybe a bit when changing major kernel versions.

I update my kernel with each release,.. but it isn't time consuming anymore. I mean, I use the previous settings from the previous kernel, then look at the new CONFIG options and enable or ignore them.

The original config took a long time, but each new config might take me 10m to fly through.

You can get a well-working Linux install without compiling your own kernel. You can get an excellent-working Linux install only by compiling your own kernel.

It is an advanced task, but you don't necessarily need to know exactly what you are doing, you can get by with just having an idea of what you are doing without knowing in-depth. Although damaging your hardware cannot be excluded for legal disclaimer purposes, it is very rare. I've been compiling my own kernels for years, initially not knowing exactly what I was doing, and never had any hardware issues due to this.

It is a learning process, and fear is what keeps most people from learning (more than just computers). I have no fear, and I have learned a lot. The more you learn/understand the less you fear. If you don't face your fears and dive in, you'll be doomed to a life of fear and ignorance. Definitely worth it to dive in and learn.

EDIT:
It would be worthwhile to know how to recover the system in case the kernel doesn't boot. You should probably keep a known good kernel around and have a boot entry for it. If you forgot to do that, you can always boot the Slackware install disk, install the kernel and configure lilo, NO need for full re-install.

Indeed.

2 members found this post helpful.

He he yeah. I get most of this and, while I do have regular questions, the links are almost always what's guiding me through whatever process when I ask. I planned on sticking to -current, and was trying to devise a reasonable way to keep from screwing up my boot beyond my ability to mount/repair. Experience has been a great teacher, but mostly I've learned how much trouble it all is. That aside, I haven't been completely wowed by the recent version of someapp since I've been at it. I think that I figured out what I needed to know. Stick with the stable upgrades and go through it annually or some such.