For example, I’m using Debian, and I think we could learn a thing or two from Mint about how to make it “friendlier” for new users. I often see Mint recommended to new users, but rarely Debian, which has a goal to be “the universal operating system”.
I also think we could learn website design from… looks at notes …everyone else.
You mention that their kernel is bloated, would you mind sharing how you measure it compared to other kernels. Such as their kernel vs something more trimmed down. Is it a storage space savings or memory? I’ve never really considered the weight of a kernel when considering different distros so if you have some method I’d love to try and compare what I’m running.
I have no comparisons as I think all distros ship the complete monolithic kernel. Of course specific IOT devices or Android ship a very much smaller kernel.
Building the kernel is not that hard, as you have
kernel-develwhich has all the sources.You can use
make menuconfigand see what all is enabled (as far as I understood this) and change stuff before compiling.Monolithic kernels are pretty bad, see this excerpt of the interview with Jeremy Soller on RedoxOS.
So I dont mind memory or even less storage space, as the kernel poorly is not relevant at all here. I just care about keeping the root binary with access to all my stuff as small as possible.
I would love a system that detects the used hardware and then builds the correct small kernel for it. There are experiments making the CentOS LTS kernel work on Fedora, which would prevent many recompilations.
Yeah. Some myth that it’s hard to do is not why we end up with monolithic kernels. Like any case where you find yourself thinking “it doesn’t look that hard; I could do that easily”, it’s either harder than it looks or it’s done a certain way for an entirely different reason you haven’t figured out.
You should learn that reason.
There are many steps that need to be followed, I didnt have the time yet but it is possible. You need to sign the modules and kernel, package as an RPM, sign that maybe etc. Its not as easy if you do it right but also not very hard.
If you don’t mind me asking, then how do you know the kernel they use is bloated compared to any other kernel? A vast majority of the device-list stuff is loaded only when that device is detected with kernel modules. You aren’t actually running everything from the entire kernel, it just has support for the devices if it does detect them. which is basically the functionality you are asking for, ad-hoc device modules.
Monolithic kernels aren’t “bad”. That’s subjective. Monolithic kernels have measurable and significant performance benefits, over micro kernels. You also gain a massive complexity reduction. Micro kernels, historically, have not been very successful, e.g. Hurd, because that complexity management is extremely difficult. Not impossible, but so far kernel development has favored monolithic kernels not without reason.
If what you say is actually that easy, why wouldn’t all distro’s just do that during the install, and during updates with their package managers? I believe you could do this in Gentoo, but I don’t know if it has measurable benefits beyond what performance tuning for your specific CPU arch would give you. Since none of those devices you aren’t running are consuming any resources beyond the storage space of the kernel.
“Their kernel is bloated” :D I dont compare with anything, as a linux distros job is pretty much to make me forget other ways to get “the linux stuff” because they are so good.
(Imagine how good Linux support would be if everyone would be on the same distro family like Fedora rawhide/stable/oldstable/centos-stream/almalinux;rockylinux;rhel.)
If that is true, and if the kernel will never load anything not needed for my device, then I am fine with it.
I see how monolithic is less complex and also a huge performance benefit over having the handshake between userspace and kernel space all the time (a meta dev on #techovertea talked about that).
But I would still want to debloat the kernel from unused code, as it is there somewhere and may get activated and used (why would you blocklist kernel modules otherwise?)
Also compiling for x86_64-v4 would probably improve speed, and it is rediculous to have the entire distro built for 20 years old hardware, neglecting all the improvements from over a decade.
Here is an alternative Piped link(s):
this excerpt of the interview with Jeremy Soller on RedoxOS
Piped is a privacy-respecting open-source alternative frontend to YouTube.
I’m open-source; check me out at GitHub.