this post was submitted on 04 May 2026
25 points (100.0% liked)

Linux

17355 readers
49 users here now

Welcome to c/linux!

Welcome to our thriving Linux community! Whether you're a seasoned Linux enthusiast or just starting your journey, we're excited to have you here. Explore, learn, and collaborate with like-minded individuals who share a passion for open-source software and the endless possibilities it offers. Together, let's dive into the world of Linux and embrace the power of freedom, customization, and innovation. Enjoy your stay and feel free to join the vibrant discussions that await you!

Rules:

  1. Stay on topic: Posts and discussions should be related to Linux, open source software, and related technologies.

  2. Be respectful: Treat fellow community members with respect and courtesy.

  3. Quality over quantity: Share informative and thought-provoking content.

  4. No spam or self-promotion: Avoid excessive self-promotion or spamming.

  5. No NSFW adult content

  6. Follow general lemmy guidelines.

founded 2 years ago
MODERATORS
 

Up until the early 2000s I used to compile my own kernel, carefully selecting only the options that I needed.

Then I realised that I wasn't saving memory, because almost everything was a module anyway.

Is there any actual benefit to using a custom kernel on consumer hardware that's supported by the stock kernels?

top 7 comments
sorted by: hot top controversial new old
[–] Kazumara@discuss.tchncs.de 6 points 44 minutes ago* (last edited 38 minutes ago) (1 children)

Primarily if you want some functionality that isn't mainlined, or isn't released as stable yet.

Like hibernate in lockdown mode, or out of tree drivers, or maybe something new coming up in the emulation support world like NTSync, though I think that last example was mainlined by now.

[–] henfredemars@infosec.pub 3 points 29 minutes ago

Woah, I didn’t know they were working on those features. Thanks for sharing!

[–] CameronDev@programming.dev 13 points 1 hour ago

You could compile with -march=native to get an optimised build, but its unlikely to show any benefit outside benchmarks.

[–] henfredemars@infosec.pub 3 points 34 minutes ago* (last edited 28 minutes ago)

Normal user? Extremely rarely would you need to build the kernel. Distributions design their options to fit most use cases, and you’ve observed the extensibility through modules. The kernel itself has moved towards runtime configurable options for your convenience over time, such as with

PREEMPT_DYNAMIC

Where in the past changing the preemption model would require a recompile. Ultimately, this is a good thing; it makes your life easier and you can get better support for a common kernel if you need to debug.

It does happen though if you need special hardware or if you’re picky about specific kernel features. For example, I’ve used kernels that don’t have built-in support for memory compression. Need is a subjective term, and I felt that was a configuration option that I needed because a memory upgrade was not an option. I would argue there was a point to that effort. Considering that you phrase your question as asking about normal users, then no, I would say that’s rarely beneficial, might actually be disadvantageous because you won’t receive as much help debugging problems from your distribution, and generally you can achieve your goals by tuning runtime kernel parameters anyway.

[–] eksb@programming.dev 1 points 20 minutes ago

The only time I have compiled a kernel in the last 10 years was to bisect to determine what change introduced a bug affecting my particular hardware combination.

[–] onlinepersona@programming.dev 3 points 1 hour ago

In all my time with Linux, I have never once recompiled. I'd go as far to say as it is never necessary for a normo to do it.

Not really unless you need a specific optimization or module that isn't available otherwise. Most distros make distribution of external modules available via package manager, and most of the optimizations you would want to enabke can be turns on or off elsewhere as feature flags.