Software virtualisation and sandboxing have been concepts familiar to software engineers since the venerable IBM mainframe era, the 60’s. Fast forward a few decades and now anyone can tap into the increasingly larger pool of power their own home computers offer to run virtual computers inside their own physical device. A decade ago, thanks to the widespread use of ridiculously powerful servers, virtualisation at a massive scale became a reality which gave birth to cloud computing as we understand it today. Amazon were the first ones to realise this and seize the opportunity to lead the way in this burgeoning industry, when they launched Amazon Web Services and started renting out any masses of computer power that was so cheap for them to obtain. The idea was genius and revolutionary. Soon enough others followed suit, finding greater (Google, Digital Ocean) or smaller (Salesforce) success.
In 2013 things were going to take another interesting turn as Docker Inc., formerly known as dotCloud, released Docker, once an internal product they used as a tool to facilitate their in-house cloud infrastructure, as an open platform everybody could use to deploy their own systems in a repeatable, secure and highly efficient manner. Nowadays, Docker forms the backbone of most of the Internet’s backend server infrastructure and has become the de facto microservice paradigm.
Containers conveniently encase a trimmed down version of an operating system alongside any number of userland applications and libraries necessary to support the runtime environment of a particular application. This allows us to run software in a completely isolated environment where it can be supplied with the right versions of the dependencies it requires without affecting the host environment. Just like that, library versioning and mutating ABIs become a problem of the past, how great is that? This has been a much celebrated advancement in the cloud computing sphere but left some people wondering, what about the desktop?
With all of these recent developments further fuelling the explosive growth of the Web 2.0, mobile apps and “the cloud” in general, we’ve seen traditional user-facing desktop applications take a backseat position in the modern software landscape, as fewer and fewer developers find it an attractive choice to bring their software products to their end users, and with good reason. Nonetheless, some of us certainly wondered if the level of portability and simplicity this shift in paradigms pioneered by the cloud engineering industry couldn’t be somehow replicated offline. That was the question. Several people in the Linux world stepped up with an answer.
The Year of the Linux Desktop Starts With a Single Desktop
But first, a bit of history
Note: I will elaborate on this on a further edit to this article. Stay tuned if you’re interested.
Like virtualisation, application sandboxing is an old concept that has not been revisited until fairly recently. The first implementation appeared in FreeBSD 4 in the form of “jails”: processes running under a
chrooted root tree which have a virtualised view of the system’s resources, provided by the underlying operating system. This includes networking and pseudo-filesystems such as
A few advancements and implementations were built during the mid noughties, such as Glick, released in 2007 by Alexander Larsson, a core contributor to GNOME, who would also go on to develop Flatpak, of which we’ll talk about soon, a few years later. Google also implemented sandboxing capabilities into their Chrome browser to increase its stability and security. Every web page was now strictly confined to the virtual limits of its tab. Code running inside a tab was no longer able to access resources beyond the scope of the isolated process it ran in. Furthermore, if a given web page got stuck in an endless loop or hung up in any other way, it wouldn’t be able to infect all the other tabs running alongside it. You could attribute this to the fact every page was now being run in a process, not to the concept of sandboxing itself, but forking out a new process every time a new separate browsing session was open certainly enabled this idea.
Some years later, Lennart Poettering, the man behind systemd, also wrote about this topic in 2014. It was around this time when the first implementations of the idea he had described came to existence, in the name of packaged apps.
Packaged apps in Linux
Packaged apps borrow several design goals from Docker itself as, put simply, they’re standalone, self-contained software applications, bundled in with all of the libraries and configuration files they need to run in a single, transparent runtime context. They provide the following benefits:
- Download and run: all it takes to use a packaged app is an address to get it from and a mouse (or keyboard) to launch it.
- Security: packaged apps run in isolation inside their host and as such have no visibility of anything beyond their predefined runtime boundaries.†
- Consistent environment across distros: Ubuntu 14.04, Fedora 26, Arch Linux, Debian 9, neither the distro nor the release matter. It will run just the same!
- Seamless upgrades and no dependency hell: as your application is bundled in with all of its dependencies, it can be upgraded without touching a single file in the host operating system. Furthermore, packaged apps will never interfere or be affected by dependencies they share with other applications installed in your system.
- Language-agnostic: Python, C, Go, .NET Core… you can make a packaged app with almost any language or framework.
As you’ll have probably realised by now, packaged apps bring to the table a set of advantages akin to what containers do. This new way of distributing software to the desktop userbase can save a lot of time and headaches both to developers and users alike, as applications can be used as easily as they can be developed and distributed. Most of the middle-men (i.e. package maintainers) are removed from the picture and the people building the application can be certain their product will run the same in their end users’ machines as it did in their dev boxes at the time they decided to release it.
As with anything in the Linux world, every time something new comes up, everyone wants to make their own flavour of it. In this case I will briefly talk about the three major software bundling systems I know about.
- Snappy: developed by Canonical and pre-installed in Ubuntu.
- Flatpak: developed by the GNOME team (mainly Lars Andersson), Red Hat soon adopted this as their preferred bundle system. A notable application supplied as a Flatpak is Inkscape, the vector graphics editing tool.
- AppImage: another take at the packaged app problem, designed to be simple and lightweight both for the end user and the developer. Krita (digital painting, similar to Adobe Photoshop) and Tusk (an Evernote client) are a couple of examples of software that are distributed in this format that I can name off the top of my head.
Both Snappy and Flatpak provide software repositories you can browse to discover and install new bundles. If you use Flatpatk, visit http://flatpak.org/apps.html or, if you use Snappy, just run
snap find <pkgname> from your command line.
It is true having so many different software bundling implementations kind of defeats their purpose, as end users may find their favourite applications are not packaged for the bundle system they’ve got installed and thus will have to keep track of what apps are provided by what system. Still, thanks to these technologies, application portability across Linux distributions is now a tangible goal and the platform developers decide to target becomes less of a moving target. Better ship your app both as a Flatpak and a Snap than deploy it and maintain its DEB, RPM, AUR and Slackware packages, no?
This is all well and good for us Linux users, but what about Windows and macOS?
Universal Desktop Applications
The Linux folks may have been busy working on a number of powerful frameworks to standardise the distribution of software applications across their heterogeneous userbase but this approach is useless to everyone else. Furthermore, all the major implementations of the packaged app concept are not completely “plug and play”, as they still require the user to install a number of packages and runtimes which, I dare say, don’t make for the best no-frills experience.
Here is where the folks over at GitHub step into the picture when, in 2013, they unveiled Electron, a new application development framework built with total portability in mind.
Write a single app, deploy it everywhere.
The idea was compelling. Indeed, this concept worked so well that soon after major players in the industry started deploying their desktop software as Electron apps. Microsoft did with Visual Studio Code, and many others joined them, like Slack, WordPress, Discord, and naturally GitHub with their own text editor, Atom.
This new wave of Electron-like apps or, as I have taken to call them, embedded-browser applications, have positively disrupted the dwindling native desktop application ecosystem. Finally, the operating system barriers can be lifted and Windows, macOS and Linux users alike can share the same codebase. For the application developers this means a few good things:
- Faster release cycles as there is almost no overhead in adapting the final binaries to every supported platform
- Less, simpler code to maintain: no more hacky shell scripts, no need to write Autoconf, cmake
- Fewer platform-specific bugs to squash
- Single framework to learn: before Electron came about, releasing the same application on all major operating systems would mean writing most of it from scratch for every platform you want it to run on: C#/VB.NET on Windows, Objective-C/Swift on macOS, and if the devs were kind enough to not forsake Linux completely, perhaps some awful-looking GTK+ app for us.
For the end user this is very good too because
- It’s simple: they’re able to simply download the application and start using it immediately.
- They can upgrade their software whenever they want, fully knowing it won’t break something else
- OS lock-in is reduced, as the same application is able to run just the same across Windows, macOS and Linux.
I guess languages like Java and Python would come close to offering a decent degree of cross-compatibility between OSs, although this would still require the end user to install and update a JRE or Python runtime to run them. And even so, these cross-platform apps don’t have the nicest GUIs…
However, not everything is as good as all I may have led you to believe. Embedded-browser apps like these come with their own set of caveats which I’ll briefly consider in the next couple of paragraphs.
For starters, there’s the fact that they’re not native desktop applications in the truest sense of the word: they’re merely web applications running on a web browser which is in turn chucked into a native OS window. This means your system will have to allocate resources both to the application in question and to the browser engine pulling the strings from behind.
Embedded-browser applications like Slack have certainly made headlines due to their appalling use of system memory. Things can indeed get a bit bloated at times…
- How do you mean?, you ask. Let’s have a look.
Spotify Linux desktop application memory usage as output by
smem (memory is output in KB):
# smem -t -P spotify PID User Command Swap USS PSS RSS 11919 root sudo smem -t -P spotify 0 1892 2466 9744 11920 root python /bin/smem -t -P spot 0 6260 6804 10688 16551 liam /usr/lib64/spotify-client/s 0 440 14038 50792 16569 liam /usr/lib64/spotify-client/s 0 20088 36736 92024 16533 liam /usr/lib64/spotify-client/s 0 116192 138060 191008 16583 liam /usr/lib64/spotify-client/s 0 571512 589078 625048 ------------------------------------------------------------------------------- 6 2 0 716384 787182 979304
If my first grade maths are correct, that’s almost a gigabyte. Not bad, eh? Let’s do another one, for laughs’ sake. This is a glance at Atom’s memory usage at the time of writing this article (brand-new install, no plug-ins and just a couple of Markdown files open with their respective preview windows).
# smem -t -P atom-beta PID User Command Swap USS PSS RSS 11807 liam /bin/bash /usr/bin/atom-bet 0 300 658 1880 12153 root sudo smem -t -P atom-beta 0 1880 2460 9916 11819 liam /usr/share/atom-beta/atom - 0 856 6028 31296 11864 liam /usr/share/atom-beta/atom - 0 18592 28644 74052 12154 root python /bin/smem -t -P atom 0 31224 31764 35584 12057 liam /usr/share/atom-beta/atom - 0 99776 138058 216784 11810 liam /usr/share/atom-beta/atom - 0 190776 225688 313544 11890 liam /usr/share/atom-beta/atom - 0 1640300 1681404 1771060 ------------------------------------------------------------------------------- 8 2 0 1983704 2114704 2454116
That’s coming dangerously close to 2.5GB of RAM (with or without
smem’s entries on the table). Talk about Visual Studio being bloated…
So which is best then?
Electron simplifies development costs as well as the learning curve for your developers, which need to keep on top of fewer technologies and platform gotchas in order to reach the widest desktop audience possible. However, it is evident, no matter how fast the V8 engine gets, applications compiled to run natively on your end users’ system will always have the upper hand in terms of responsiveness and usage of system resources. This is a trade-off you need to consider: what’s most important to you, speed or portability? To the folks behind Spotify or Slack the answer is simple: hardware is very cheap nowadays, and most people have sufficient CPU and RAM to spare to cushion the impact these two-headed apps has on their systems.
Nevertheless, if speed or access to system-specific features is a must for you, and you happen to be a Linux software developer, perhaps you’d prefer to stick with whichever framework or language you use and simply deploy your application as a snap, a flatpak or an AppImage bundle.
† Packaged apps definitely offer a higher degree of security than a normal application running directly on your system would, as they run on a highly constrained environment, but even though I can’t find any literature at the moment to prove otherwise, I would handle them with the same care I would use with a non-packaged application.