Sunday, 31 January 2016

The future of "Minimal Linux Live"

Minimal Linux Live has been around for 1.5 years and it became a very popular project with 130+ stars in GitHub. I've been using BusyBox statically linked with glibc and as a result the DNS functionality doesn't work. As a consequence, the whole network functionality doesn't work as expected and it's not really usable. That's due to a very old architectural issue with glibc and also due to the fact that static linking is highly discouraged when glibc is involved. So, you can build your own minimalistic Linux OS but it won't have network support.

"Minimal Linux Live" with network support
"Minimal Linux Live" with experimental
network support
Over the past few months I've been analysing the possible approaches to fix this issue. The most promising approach was to switch glibc with musl. However, I hit an unexpected issue - musl's header files are conflicting with linux's header files. And since I rely on vanilla sources downloaded from the official websites, the only option I had was to fix the headers manually.

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!


  1. This comment has been removed by the author.

  2. can host your builds, been unable to contact you

    1. Thank you! If you'd like to contact me, please visit my LinkedIn profile and drop me a message!


Note: only a member of this blog may post a comment.