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
, 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.
<sub>Note: I will elaborate on this on a further edit to this article. Stay tuned if you're interested.</sub>
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 `chroot`ed 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 `/proc`.
A few advancements and implementations were built during the mid noughties, such as
, 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 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:
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.
: developed by Canonical and pre-installed in Ubuntu.
: 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.
: 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?
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
, 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.
Under the hood, Electron is little more than a Node application running on a trimmed down instance of the Chromium web browser. This makes the development of local desktop applications no different than that of their web counterparts. A HTML/CSS frontend and Node and JavaScript for everything else. Simple and accessible.
Two years later, Facebook took this concept and applied it to the mobile space, and the result was a spin-off of their massively successful React JavaScript framework, christened [React Native]()https://facebook.github.io/react-native/. Skype, Airbnb, Instagram and Facebook's own mobile app eventually adopted this framework. The argument for React Native does indeed sound compelling:
Are you telling me that I can write a single application using just JavaScript and the Electron API we all know and love, and then I'll be able to ship it to all Android and iOS devices alike with minimum effort? Sign me up for that!
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:
For the end user this is very good too because
/assets/images/article/2016/3_3.png
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
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...
Depends, obviously!
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.
---
<sub>† 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.</sub>
