Generic+initrd. Sometimes I compile my own kernels but I usually stick with the generic config.

The poll results astound me. My expectation was that almost everyone used "generic" (since that is after all the recommended configuration), and people like me who use "huge" were a tiny minority. While "huge" users are the minority, it's a pretty big minority!

That actually makes me feel better about using it. Having so many "huge" users out there means that it's getting tested under a variety of environments and use-cases, and any bugs would get reported back to the Slackware team. I feel more assured now that the kernel I'm using isn't hiding latent bugs which using "generic" might avoid.

1 members found this post helpful.

I used to use generic because I was under the impression that it would improve performance by a noticeable margin. However, after a comment by Pat V. stating that the -huge kernel was not the performance hit as popularly believed, I went to it, and have not been disappointed. It's easier to compile and deploy (not that the -generic was particularly hard, it's that the -huge kernel is not such a hassle). I'd say that unless one has a special needs case where a -generic kernel is called for, just use -huge and be happy!

Happy Slacking!!

2 members found this post helpful.

Generic + initrd

I use generic since that is what is recommended for everyday use from my understanding after install.

Crux and LFS both require you to build your own kernel. I use the generic ones for Debian on Bigboy and for AntiX on Littleboy upstairs.

I think RadicalDreamer is right. If there is a generic kernel, it's best to use it because all the software will have been compiled to run on that kernel. But I must admit, I get irritated by the length of time it takes to load and I dislike having to use an initrd on principle.

Actually I think most the time is taken up by udev doing it's thing. When I played with Crux (in a spare lvm lv on my slackware box) a little while ago I hand crafted an initrd with just enough to do the lvm stuff and mount root but without any udev. It booted in a few seconds. Unfortunately I no longer have it as I needed the diskspace for something else, but it was an interesting exercise. I like CRUX a lot, just not sure I could keep up with the rate of churn.

Did you keep notes? I never found a tutorial to create an initrd for Crux.

(I'm surprised you say there's a lot of churn with Crux.)

I am of a similar mind when it comes to initrd - I just don't have a need for any benefit it may offer so any cost is too much. I am curious about your endorsement of "generic" kernels since it is my (possibly mistaken) understanding that it is GCC compatibility and not kernel compatibility that is at issue - ie "all the software will have been compiled to run on that kernel" translates to "all the software is linked and somewhat locked to the GCC that compiled it".

Since I always custom build kernels, and need to for DAW work, I am unaware this presents any problem at all and have had no experience of such. Is this not true?

Well, the slackware initrd works just fine with it. I started by borrowing both the slackware initrd and kernel for CRUX, but then I started writing my own. Unfortunately No, I didn't take notes as I was just playing about.

Maybe it was just unfortunate timing, but there were an awful lot of updates most days, which was why I mentioned churn. mesa was one that stood out to me at the time as it seemed like there was a new version almost every other day.

1 members found this post helpful.

I don't even think this is a requirement. I am using the 4.9 kernel from -current in my Slackware 14.1 install without issue, and that was compiled using GCC7, and 14.1 uses GCC4 (4.8.2).

I think it really comes down to what the binaries link to. The only thing that I think would be tied to kernels is 3rd-party modules.

Thanks. That makes even more sense and you're right, had I thought more I'd have realized I have experienced this so even GCC version is not necessarily a hard obstacle.

There is a link through glibc (not gcc as far as I know) to the kernel headers against which glibc was compiled. But that doesn't affect the issue of whether you use a prebuilt kernel or a hand-rolled one. I was thinking rather of how some software expects certain kernel flags to be set, and you are not told which ones.