|"Minimal Linux Live" with experimental|
I did that and it worked. I even started preparing the source for official release (link). Then I thought it's worth to check what will happen if I switch to the latest kernel, BusyBox and musl all at the same time. Well, it simply didn't work. I found out that the newer kernel headers are even more incompatible than the headers from the previous version. As a result I had to rework the headers again.
The core issue is that since the open source community is not centralized, pretty much all major software pieces have their own vision about the header compatibility. That's why all major Linux OS distributions maintain their own header patches for the most used open source pieces, most notably the kernel. And that's why when you use your Linux OS as system development machine it all works fine - the OS maintainers (Ubuntu, Red Hat, etc.) have spent tremendous efforts to make all software pieces work together at source code level, including the headers.
And that's exactly where MLL's problems begin. If I stick to musl then I need to provide header patches for the musl/kernel headers that I used in this particular combination. This is doable but it's very time consuming task. Also, there is one significant drawback - MLL is highly customizable and the users can specify their own kernel/musl versions to use. Guess what - in this case there is a big chance that the provided header patch won't work. So, I'll be providing scripts which work fine, just don't touch them because they might no longer work. :)
I tried to switch to dynamically linked glibc but the default glibc installation after default compilation is ~70MB and I still haven't figured which pieces I don't need (work in progress). And in this case I have another technical issue - the boot process hangs with kernel panic, most probably because I'm not providing the correct "so" libraries (work in progress). That was the main reason to switch to static linking at first place.
I also tried to switch glibc with uclibc but first of all this project is not actively maintained and second of all it is not actively maintained. Moreover, if you decide to use uclibc, you may as well directly try Buildroot. The last time I checked this project was using uclibc.
Buildroot is a really good and fast way to build your own embedded Linux OS from scratch. It is so much more powerful compared to "Minimal Linux Live". The only drawback is that it is also much more complicated and it doesn't come with "step-by-step" build tutorial. When I started working on MLL one of my goals was to provide really good documentation of the whole build process. I honestly believe that The DAO of Minimal Linux Live is the best educational resource you can find online. It is better even compared to Linux From Scratch, because LFS describes the build process for a fully blown desktop OS while MLL focuses on the minimalistic approach. If you need just the basic stuff, then my documentation is exactly what you need! :)
Another way to end up with minimalistic Linux based OS is to use Aboriginal Liux. The author of the project uses approach very similar to my approach and he also provides *a lot* of source/header patches. You can try it, it's fun!
So what's the future of "Minimal Linux Live"? I believe I've done my job really well and there is no immediate need to "upgrade" the project further. The more I change it, the more it will look like LFS, Buildroot or Aboriginal. I have already provided "proof of concept" network solution (check the link I've provided above) and all Linux gurus can try to make it more generic than it is now.
If I ever have the time to think of a really nice solution for the network which fits the MLL philosophy of using vanilla sources, I'll release another version. Until then - feel free to read the documentation and learn the basics of building your own minimalistic OS entirely from scratch, entirely from source code!
May the source be with you!