gVisor sandboxes
Containers are not exclusive to Docker. Valentine Sinitsyn shares a slightly different view of what can be done to these commodity technologies.
Universal packages are only part of the story… Valentine Sinitsyn discovers how making containers proper sandboxes helps improves the Linux kernel’s guts.
Over the past 27 years, Linux has seen many reincarnations of the “universal package manager”. Some attempts such as Autopackage are already history. Other are still alive, but nevertheless struggle to provide a viable alternative to RPM, Deb and friends. Docker and other container engines made universal packages for services a reality yet gave little-to-no support for desktop applications. But there are ongoing efforts to rectify the situation.
To dive or not to dive?
The history of computing is the history of abstractions. CPU microcode abstracts logic gates, assembler abstracts microcode, and C abstracts architecture-specific assembler. Interpreted languages such as Python abstracts silicon CPUs, web applications abstract whole operation systems. This list can be continued, but you’ve got the point.
Twenty-five years ago, programming was closer to hardware. You used inline Assembler to disable the blinking cursor. You wrote to video memory to draw shadows beneath your text-mode dialogs. Since then, the state of things in computing has changed drastically. Most modern programs rely on runtimes so their authors can concentrate on application logic rather than memory management. The kernel is buried inside these layers of abstractions. Maybe you find learning its nuts and bolts fun, maybe not. Either case, is there any sense in doing so nowadays for anyone but kernel developers?
This is similar to a concept of not needing to know how a car engine works to be able to drive it. My view is that even if you never open a gearbox or dig into the kernel, knowing their internal operation can help you to write better programs. Abstractions in computing are leaky, and while it’s safe to ignore what’s going behind the curtains 80 per cent of the time, the remaining 20 per cent is where you spend 80 per cent of your debugging efforts. You don’t have to be a kernel guru to do web development, but understanding the lower layers would prevent you from doing something they can’t easily support. Say, opening too many files in your Python code…
One is Snappy, a Ubuntu thing which we touched briefly in LXF242. Another is Fedora-baked Flatpack, which has recently released a 1.0 version. This is a milestone that marks both feature completeness and readiness for wider use, so let’s see what’s inside.
With Flatpack, application developers build a single container package which works across all major Linuxes. For large projects, such as LibreOffice, it makes pushing new versions to end-users much faster. It also has a potential for commercial software vendors.
Flatpack relies on the same set of technologies Docker uses for containers (namespaces, cgroups and seccomp, etc) that have already proven useful on the server-side. Support for the Open Container Initiative (OCI) format narrows the gap between Flatpack and containers even further.
Flatpack applications are self-contained: they don’t use anything but kernel from the host. However, it doesn’t make sense to package a complete GNOME or KDE installation with every GNOME app. Flatpack solves this with “runtimes” that an application can build upon. Internally, these filesystem trees are stacked with OSTree, which we discussed back in LXF234.
Flatpack 1.0’s changelog is quite long, but the main changes are in the ecosystem. Flathub ( https://
flathub.org), an application store that quietly launched in May 2017, is now off the Beta period. Free software heavyweights such as GIMP and LibreOffice are already there, along with Steam and Visual Studio Code. It’s yet to be seen if Flatpack will finally deliver a universal packaging solution for Linux, but it’s certainly worth an hour or so of your time looking into it.