Uh... 68M is the directory size? There's two kernels in there.

Stock: 7.7M kernel + 37M initrd = 44.7M
Custom: 5.3M kernel + 14M initrd = 19.3M

Anyone excited by that may also want to check out TinyCoreLinux.

Thanks I got it.
Yes, you have defined everything correctly.

Regareds.

Stock: 7.7M kernel + 37M initrd = 44.7M
Custom: 5.3M kernel + 14M initrd = 19.3M

Anyone excited by that may also want to check out TinyCoreLinux.

Glad to welcome you!
I'm sorry, I don't quite understand what 68 mb you're talking about.

Regards.

Holy cow! That's amazing.

For me, it's almost like deciphering hieroglyphs. Kdif helps, indicating the boundary in the files, and the

mrproper

command, which returns the source codes to their original state.

This is my final version for Dedalus (vmlinuz-6.1.55-s205, initrd.img-6.1.55-s205)

 uly_e@AA:/boot$ ls -lh
total 68M
-rw-r--r-- 1 root root 254K Jul 27 20:28 config-6.1.0-10-amd64
-rw-r--r-- 1 root root 178K Oct 26 13:33 config-6.1.55-s205
drwxr-xr-x 6 root root 4.0K Oct 26 19:26 grub
-rw-r--r-- 1 root root  37M Oct  8 21:52 initrd.img-6.1.0-10-amd64
-rw-r--r-- 1 root root  14M Oct 26 17:02 initrd.img-6.1.55-s205
-rw-r--r-- 1 root root   83 Jul 27 20:28 System.map-6.1.0-10-amd64
-rw-r--r-- 1 root root 3.0M Oct 26 13:33 System.map-6.1.55-s205
-rw-r--r-- 1 root root 7.7M Jul 27 20:28 vmlinuz-6.1.0-10-amd64
-rw-r--r-- 1 root root 5.3M Oct 26 13:33 vmlinuz-6.1.55-s205
uly_e@AA:/boot$ uname -a
Linux AA 6.1.55-s205 #1 SMP PREEMPT Thu Oct 26 16:33:50 EEST 2023 x86_64 GNU/Linux
uly_e@AA:/boot$

MAKEFLAGS='HOSTCC=gcc-13 CC=gcc-13' make -j7 menuconfig bindeb-pkg

One can remove drivers for hardware not used and filesystems and protocols not used and speed up the build process considerably. (One slow machine gets its kernel rebuilt without netfilter support to reduce the build process significantly).

If something breaks, one can still have alternative kernels to boot into and report problems to the maintainers.

What I was thinking was that the system would be nimbler.

A.

In my experience a smaller system devoid almost entirely of unneeded cruft is FAR nimbler and faster, I have gone so far as to test this assumption thoroughly in the past on multiple machines and I assure you it is so, though the effect is far more noticeable on older machines with lower specs.

I used to know a guy who was way into Gentoo, and he always said I would never know what real speed was until I built a Gentoo system for a specific machine.

Too much work though, lol, for this lazy ol country boy.

BTW, thanks to everyone in this thread, this is a very interesting topic for me, have never compiled a custom kernel before but I think i'd like to give it a go in the future. I do love a small fast system. Have to spend some time today converting SVG icons into PNG's on some new programs i'm using, SVG's really bog down the main menu when you use icons in addition to the program name in a lower spec machine.

In my opinion, unneeded modules don't harm the system, just take up space on disk. I even do think (never did) that they can be deleted without issues if you know what you are doing.

Agree.
The question is different - the size of the kernel and the unnecessary code in it. For example, support for Intel and AMD platforms is built into the kernel. It is clear that for a particular computer one of them is redundant. Etc...

Regards.

Right.

Yes, that was not a problem.
What I was thinking was that the system would be nimbler.

Thank you both for your input.
It would seem that I'll keep using the standard kernel.

Best,

A.

... because eventually the kernel will have more unneeded modules than needed ones.

In my opinion, unneeded modules don't harm the system, just take up space on disk. I even do think (never did) that they can be deleted without issues if you know what you are doing.

Would it also be the same for minor ones?
eg: 4.9x -> 4.9y?

Yes, you'll have to rebuild.
The versions are different, here in "news" you can see the changes

https://tracker.debian.org/pkg/linux

Regards.

I see ...
I understand that this would be for a major update.
eg: 4.9 -> 5.0

Would it also be the same for minor ones?
eg: 4.9x -> 4.9y?

Only thought about it for the reasons in my OP.
Tailored to the specific hardware in my box because eventually the kernel will have more unneeded modules than needed ones.

Thank you both for your input.

Best,

A.

My main doubt with respect to that is the eventual updating/upgrading of the kernel.

Nowadays distibutions kernels boast all the range of modules ready to install, so I don't see why a custom kernel is required anymore. Last time I did I was still young

Anyway, sometimes you need to compile your kernel tailored to your hardware at hand. As aluma said, you have to answer a lot of questions, but only if you configure from scratch. You can shortcut using a config file to start with. When upgrading, use your own config file again to recompile.

It was not much trouble, and it was trendy when I did. ¡YMMV!

Hello!
Yes, when updating the kernel you need to compile a new one. Therefore, if a standard kernel is sufficient for your tasks, there is no point in compiling.
The most time-consuming task is the initial editing. There are more than 5000 lines in the file, about the same number of questions that need to be answered correctly.
Then it’s easier, just use this configuration file of yours.
My “couch surfer” Lenovo s205 is AMD 300/4Gb, even a slight improvement with a custom kernel is noticeable. Well, kind of fun...

Regards.

I have many times thought about the possibility/convenience/need of doing such a thing but always came up, for some reason or other, short of arguments.
Not that I did not have enough of them, what I did not and do not have is previous experience or time.

I also adhere to the if it works, leave it be philosophy.
But being a stubborn tinkerer, I have a rather bad track record on that account.

My box is a Sun MS Ultra 24 WS with an Intel Q9550+16Gb RAM, SLI SAS1068E SAS controller and a pair of Nvidia Quadro FX580 cards to drive three 19" monitors, two of them Samsung SyncMaster 940N. There is also an Adaptec 2940UW SCSI controller for my Umax S-6E scanner and a PCIe USB 3.0 PCIe card.

All the hardware listed above is ranked as old or ancient (depending on who is talking) but my take is that if it works as expected, it is neither old nor ancient.
Look at the Voyager probe ...

That said, I expect that save some event that kills the mb, I should not need to undertake any hardware upgrading, save maybe the SAS controller and drives which are SAS-1/3.0 Gbit/s a couple of years from now when I can justify getting that hardware because of a good bargain.

But I see that at some point in the future, an always fast approaching horizon in IT, it may be a good idea to churn out a slimmed down/monolithic/dedicated kernel for my box, with just what its hardware needs to run.

My main doubt with respect to that is the eventual updating/upgrading of the kernel.

How does that work? Does the kernel have to be compiled everytime?

I'd appreciate some insight into this aspect of the kernel building issue.

Thanks in advance.

Best,

A.