The container runtime on your desktop, by default.

Fedora Silverblue/Kinoite, openSUSE MicroOS, EndlessOS, and VanillaOS ... it certainly is an exciting time on our journey towards more reliable Linux desktops!

Each of them take different approaches to moving towards a more zero-trust/cloud-native approach to the desktop. Fedora and EndlessOS are all in on ostree, openSUSE is using a btrfs approach, and VanillaOS is using ABroot.

They all have one thing in common ... they all ship with a container runtime out of the box.

This is great for developers because having a built-in method for doing containerized development ready to go is much nicer than setting it up yourself .

If you're a normal desktop user then many of the things I'm talking about next won't apply to you, ideally you're just clicking on your icons and installing your apps via a GUI. However, you might have a long term economic interest in how developers use Linux desktops.

It's a trap

Well of course they need a container runtime, how else will we get toolbx/distrobox and get access to all the stuff we need for development? We have existing images of every distribution, which makes using and consuming distribution packages easy.

Now we can keep all the things we like about using Linux desktops but with the logical seperation and protection we need to keep our host mostly decoupled from this layer entirely. At this point in my journey I'm always in my distrobox and rarely touch the host terminal.

If you're new to using these systems but don't have a cloud background, then you might think that a container runtime is just there to run your blingy terminal!

Surprisingly, the container runtime has become a crucial component of the Linux desktop! That can be podman or docker, whatever you're into.

Unlocking the potential for the next generation

When I was learning linux a common task was to install a LAMP stack - you fired up tasksel, chose the web server task and you'd be done! Or if you have been around before tasksel existed you installed whatever combo of packages you needed. If you go to an open source conference and ask people who have been around the block where they got started, there's a good chance it was a LAMP stack on Debian in the early days of PHP and MySQL. An entire generation of folks who went on to build systems that you're probably still using today!    

Today the acceleration of technology is much faster, and one can argue that lots of that innovation is happening in open source. Consider this poor fellow:

How the hell do I learn all of this?

It's pretty common to look at the cloud native landscape and crack a joke, but we're not doing that today. Today I want to talk about how newcomers in our field are learning how to use these tools.  

The container as the primary primitive

In the old days where you could just install a handful of packages and get what you need – but things are way faster now. Old learned-on-Debian Jorge would have looked at this and come to the obvious conclusion:

Welp, someone's got to put this into Debian, let's get to work!

There are of course exceptions, but generally speaking, I can't think of a more Sisyphean task than consuming cloud native tech with traditional distributions. There's so much stuff in there too.

At the end of the day many of these projects are using more sophisticated automation tools than we did back in the LAMP-stack days. There's a pile of computers running tests and automatically publishing these tools into container registries, ready for us to consume!

We don't need to boil the ocean

By integrating the container runtime right into the default desktop experience these cloud-native-thinking distributions enable the Linux desktop to catch up to the competition. It stops being about packaging the world and instead shifts the focus on the developer experience.

Windows users have WSL, and the OSX/Docker combo has been dominating development for a while now, some might say too long. :)

Unlike Mac and Windows, we can do these things on Linux natively, without that VM layer, it's a natural fit, however, this is also the current pain point. A longtime cloud-native developer I respect said this to me at KubeCon: "I find it interesting that if you want to contribute to the latest in open source tech that you have to use a Mac, setting up Linux to do it this way is so much worse, I gave up years ago ... good luck on your impossible mission though."  

It shouldn't matter where you develop: Mac, Windows, or Linux, the thing that is being spit out at the end of the pipeline is a container.

tasksel for the Next Generation

By bringing cloud technology to the desktop we can reuse the immense amount of development effort and dollars being put into cloud and just consume it locally.

If we can give people the cloud-native developer experience that they're getting on OSX, but with the ability to run on millions and millions of more computers then who knows what the next generation will build!

Show Comments