bigpod

you can use whatever base image you want lets say ubuntu:latest (i dont like alpine) and normaly base images tend to include a lot of stuff that doesnt have any place in container think why do i need a tool for ext4 managment inside contianer makes no sense ok for production throw it out thats what docker-slim does and gets rid of vulnarabilities in programs that are not used by your program by simply getting rid of them

its all about UX, if you have an environment that has lots of menus and settings something even bios had to control certien aspects of your system like virtualization support and such you would like to have good UX, because of that UEFI was created. Now if you wanted to do that from OS you can but you need a technology many people hate and want to remove from their systems and hardware called Management Engine. Yes this is the purpose of ME allow changing of UEFI settings from either the OS of machine itself or changing of UEFI settings from another machine without requirement of IPMI(idrac iLo and simular implementations) and rebooting to get to it. Implementation of some sort of ME allows you to overclock your CPU from OS. So AMD has some sort of ME(of course its not called ME since that is just name of intel implementation) as well(how wide in functionality is another question) so do GPUs.

honestly at some point we should think about deprecating old code old stuff and i think 10 years might not be such a bad number, of course good deprecation policy would tell you for few releases before that something will get removed but its linux so even if they said we are removing BIOS support in fedora 40 everyone would cry

also it takes about same amount of code to boot BIOS and UEFI

while fedora defenetly is not my cup of tea, first thing i do when i get a new system(desktop or laptop) is disable legacy bios/CSM whatever it is labeled as. This is to prevent mirriad of issus BIOS brings including its horrible MBR. GPT is million times better and for someone who dual boots on many machines (and has a drive with 14 different operating systems as a test) to all you legacy BIOS and MBR fans MBR doesnt cut it and is cause of many headaches if you dual boot.

Remember how some people have had issues with windows destroying booting of linux that is due to MBR being a useless piece of antiquated software and breaking. It wasnt windows's fault its just that its update utility had to overwrite a part of MBR and since MBR was already basically a house of cards all you had to do to break it is have a little mishap and your linux boot is gone (it was same on other side just less people were crying about it because well they blamed windows for breaking itself)

while in theory possible it would require a whole lot of change.

Also like kyle said apt and alike(all current package managers) cant generaly deal on file per file, basis package is as is all files included, so this would require a new package manager(or old one) with packages being a single file with no dependancies for specific package. This would require new base images if we used dockerfiles and you would need to know every library every binary your program needs. While on other hand leaving in all the cruft some copy in like READMEs LICENSE files and so on.

Benefit of docker-slim is that it is in many ways just a line in your already predefined CI/CD pipeline, therefore its just another step likely just working with already preexisting technologies you might use in your pipeline.

you cannot use snap inside a docker or any other OCI container, first of all snap is a containerised package as well so it doesnt make much sense but what is more important it requires SystemD and as far as i know if systemd isnt PID 1 snap deamon wont run and its CLI will output it cant run.

basicly what docker-slim does it basicly checks what your program is opening/ using(using simular system as strace) and what it does open/use is then copied to a new image. And how can get those kinds of numbers, basicly it removes parts of rootFS that are not required which is basicly your base images standard files like /etc /home /usr /root..., it also removes all development dependancies, source code and other cruft you might have copied in for use during build or simular.

you can use --include-shell to inclue a shell. but my recommendation is always keep a non-slimmed image somewhere so you can refer to it and some debugging can be done in either, also that allows you to use something like slim.ai's(company behind docker-slim) web based SaaS features which allow you to see the differences between 2 images and see the file system in nice web base file tree. some bugs may stem from removing what is necessary for app to work(sometimes caused by not loading a library during "slimming" process) for those types of errors you need to know how your app runs more then anything. it a tradeoff