Let's talk about Desktop Linux Platform Issues
CC Attribution 4.0 International:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Peter, Simon
To make Linux on the desktop successful on a level comparable to Windows and macOS, it is key to think about the Linux desktop as a core OS platform that makes certain platform stability guarantees to developers, rather than a bunch of packages distributed by a Linux distribution. As of today, there is a number of issues making the deployment of applications to the Linux desktop unnecessarily cumbersome. In this talk we will highlight real-world difficulties in using the Linux desktop platform as of today, and present some ideas on how to fix them.
 Hello, thanks for coming. I'm Simon. I would like to talk a bit about desktop Linux platform issues today. So if someone of you doesn't like people ranting on stage about stuff that's not perfect, about stuff that's broken, about stuff that's not working, please feel free, now. I do have a solution, but that's not the main topic of the talk. It's really about pointing out what we as a community should think about and the kinds of issues that I think we need to solve together if we want to make Linux a viable platform for desktop applications. So a short background about me. I have been essentially a Mac user since forever and Mac is a platform where magically stuff just works, at least used to. I'm a Linux user since around 1998-ish and I have been fascinated by Linux live CDs right from the start where you don't have to install stuff, you just boot up a live CD or later a live USB system and just can start working. Also, I'm a distro hopper, so every time I boot my system, it asks me actually which out of hundreds of distributions I have on my system I want to launch this time and I make a point out of this. Also, I've been thinking about how to package Linux applications for Linux users for quite some time. Originally, I started the project called Click. This was 2004, which over time evolved into what is App Image today. This talk is not about App Image. App Image may be part of the solution, so if you're interested in that, we have a deaf room upstairs for everyone who is interested in App Image or packaging an application as an App Image, feel free to step to come by. But here really, what are the underlying issues on the Linux platform? This is what we should discuss today, so I hope to keep my talk short so that we have lots of time for discussion in the end. Linux on the desktop really is a niche in itself. Looking at the desktop operating market share, we see it's basically all Windows and Mac. With Windows over 88% market share, Mac OS over 8%, this doesn't leave a lot for Linux, which is depending on which survey you believe somewhere between 2% and 3% as of today. Really, as an application developer, when you want to reach as many users as possible, it's obvious that you go for Windows first, Mac second, and then maybe you start thinking about Linux and if it doesn't create additional work, maybe you consider to also go for these 2% guys there. Really, this is not the worst yet, because if you look into the 2%, that's what you get. Hundreds of different distributions living in different ecosystems where you have the Debian-ish ecosystem with Ubuntu and you have the Redhead-ish with Fedora and Santos, but really, this is the family tree by now. In the traditional distribution model for applications on the Linux platform, you had to build for each of those and you had to target each of those hundreds of distributions. It doesn't stop there. For every distribution, you have different desktops and some of those desktops are actually quite opinionated as of today, how applications should be made and also, they start to have an opinion about how applications should be distributed. For example, there is elementary, great operating system, great design, great usability, but they expect people to write applications for elementary OS, which is a tiny, tiny fraction out of the tiny, tiny fraction of the market share that we just saw. Similar GNOME expects applications to be written against GNOME frameworks in a very specific way. All of those desktops have certain ideas how applications should be written for Linux and how they should be distributed, but that is a bit conflicting with the view of an actual application author. Because if you look at it this way, the answer cannot be to develop each application for each distribution and for each desktop, because if you do the multiplication, less than 3% times distro market share, less than 10% times desktop market share, it's nothing. You are not left with any users. So this led to the fact that even Linus Torwalds, who not only famously wrote the kernel, but also a dive log application, at some point stated that they are not distributing their own application for Linux. They provided binaries for Windows and for Mac, but not for Linux. And he went in public about this. He said, you don't make binaries for Linux. You would have to do it for Fedora 19 and 20 and Red Hat Enterprise. And then there is Debian with their rules. It's a mess and you don't do it. If you're interested in this on YouTube, he has a long rant. He goes on and on about this issue. So it's really worth seeing. I don't want to play it here now because language might not be suitable for all audiences, but if you're interested, great watch. So with this situation, it's really no wonder that we have no mainstream commercial applications. And I get it. Some people will say we don't need it. Fine. Your opinion, I think it would be great to also have in addition to the great open source applications, some commercial applications, you might work in a job where this is required, whatever. If I can do work on a Linux system that I would be forced to do on a Windows system, otherwise I will take the Linux system at any day. So I would be interested in seeing this kind of applications, whether I personally use it or not. So real world applications like Photoshop, there is no way they are made for each desktop. I mean, it simply won't happen, right? So even open source applications, sometimes it goes a bit differently than from how it was planned. Krita started out as a graphical application for the KDE desktop on Linux, predominantly addressing KDE users. But today it has more downloads for the Windows platform by far than for any Linux system. And if you look at other real world applications, what I tend to notice is that the applications I use on a daily basis, they are all cross-platform. They are all available on Windows, Mac and Linux. So there are famous names, Firefox, OpenOffice, Arduino, Scribus, Electron, you name it. These applications are mostly written in cross-platform graphical toolkits like Qt, some use WX Windows, some use GTK. Increasingly, we see more and more electron apps, and this comes with pros and cons, but it shows that there is a real need for something that unifies Windows, Mac and Linux. Now, as an app developer, it is really key that you have a dependable platform on which you can develop, which allows you to reach a large user base, which allows you to produce an application in a supportable way, where you know my application runs on a known infrastructure, because you want to have as little work as possible as an application author. So when you think about what a platform is, a platform is really something that builds the foundation on top of which you run your own stuff. And the large desktop environments that are successful in the market, they see themselves as platforms. Windows is a platform, Mac OS is a platform. About Linux, we will have to talk, right? And yes, there is this increasing trend that Apple and Microsoft want to push people into app stores, but if you look at the reality, that's not what users really want. And also many application developers don't really want. With Linux, we have a moving target here. And the moving target is not a good platform. Whereas here, if I compile an application on Windows, let's say seven, I can be reasonably sure that it will continue to work on Windows seven and on Windows 10. Same for Mac. You can compile an application Mac OS 10.9 and will run on all recent versions. On Linux, big question mark, because stuff can break, there are no guarantees. I mean, Apple announces years in advance, we are about to deprecate this and that and you get an early warning in the IDE if you use stuff that's deprecated and they leave it there for years before they finally remove it. This kind of thinking is in my opinion, missing on the Linux platform where you just get something that's recent today and tomorrow you get something else and you have absolutely no guarantees what you can depend on. Linux also shares this view, by the way. He really thinks breaking the user space is really a bad idea. In his kernel work, he always makes sure that nothing breaks user space, but at the same time, he notices that user space people break user space all the time. He explicitly mentions G-Lib C here as an example, but there are many, many other examples. We will see some really soon. In my opinion, breaking the user space all the time needs to stop. Now I'm not the only one to notice this issue and there are different approaches how this could be solved. One approach is to have the kernel, which has a stable interface between the kernel and user land, which Linux ensures, but then as of today, in user land, we have a completely moving target. Now, what you could do is to ignore this moving target entirely, not use anything that comes with your Linux distribution in terms of libraries and infrastructure and services, just forget about all of that, and then ship a runtime that has essentially a second operating system except for the kernel, which is defined. That is what systems like Flatpak and Snappy do. Flatpak, you get a runtime that is really that contains everything you would normally expect from an operating system minus the kernel. Snappy, the same thing here, it is usually built on some version of Ubuntu and applications now can develop against these defined runtimes. The advantage for the application author is that there is something I can trust that does not change from today to tomorrow, but the big downside of course is that I'm essentially throwing away the real operating system, the real stuff that comes with the distribution that's only used for showing the desktop essentially and applications don't make use of this. So it's a lot of duplication, but it gets worse once applications over time require different versions of those runtimes. You have a nice collection of operating systems over time. You cannot think that every application will require the same frameworks in the same versions, so this will really grow and grow over time. I think this is not the most elegant solution to the problem, and I'm always an optimist, so I'm optimistic that by bringing in discussion into the open source community, we can end up with something like a guaranteed common Linux desktop platform, because if you look at the distributions and what they are shipping, it's not so different. It's always the same stack and some of the core components that make up a typical Linux desktop system we will see in a second. So really, if you look at Ubuntu, if you look at Debian, if you look at elementary, under the hood, it's all very, very similar. For me, the key is to think about how to distribute a desktop in terms of thinking what a platform is. And a platform is something different from a traditional Linux distribution, because platforms are something that allow authors to run additional stuff on top of. That's different from trying to get something into a distribution. A Linux distribution is built for shipping everything, building it in and requires an application author to get stuff into the distribution. That's not the platform idea. The platform says I'm the platform. I guarantee you that I provide you this. Use it however you like. I don't care. All successful OSes, if you think about it, both on the desktop and also in the mobile world, are built this way. You don't try to get an application into the Android open source project normally, unless it's a very low level piece of code. You don't try to get your software into Windows. You write software for Windows. You write software for Android. And that is the platform idea. Now, distribution, people are really not working on solving this problem, because they see it differently. Usually a distribution cares about their own distribution, and that's all. But users care. I want to download an application on the day it is released, ideally directly from the application author. Application developers care, because they want to reach as many users as possible with their application without having to do a lot of work and addressing each distribution individually. And finally, I think library developers should care, but sometimes they even can't. We will see an example about this in a second. So today's distributions are not really optimized for running third party stuff that is outside of the distribution. They usually want to package world for themselves and most make no guarantees in terms of what infrastructure they provide. A somewhat extreme example here is coming straight from the Ubuntu wiki, where they say normally and preferably software should be installed using Ubuntu software center. And the whole page explains why it's a very bad idea to run anything on your operating system that is not coming from Ubuntu. I think that's wrong. This is clearly not platform thinking. There are many, many reasons why this mindset is problematic. An author may just want to ship an application as it is without caring too much about individual distributions policies. An author may want to have some control over the downloads. For example, an author may want to count the number of downloads. This doesn't work in the traditional distribution model. Or an author may want for legitimate reasons the user to pay before the user can download a software or to fill in a survey before downloading an application. Users may want to run many versions of the same app in parallel. This is also typically not possible in the way distributions manage software. You always have one version of an application and can update that. But for testing, for example, it may be very useful to be able to run as many versions as you like in parallel. And finally, a user may want to have the app in the instant it is released without having to wait before an application is backported to long term stable or Debian stable or whatever. This comes to the point that in many cases, a user may want to run software that's coming directly from an author. The distribution models should open up to be a platform that allows for this. Most other platforms do. It's usually called side loading in the mobile world. And I think this is very important as a feature for the Linux desktop as well. A key to achieving this is to constantly think about backward compatibility. I'm always a bit surprised when I see that someone writes an application and uses the latest versions of compilers and dependencies and libraries that are available. Because that in essence means that you will get into big trouble running this application on anything but the very latest operating system. And the reality is if you look out there, your users, they will be using older operating systems. Typically, if you look in the enterprise world, it can be very old systems. So in my opinion, it is always important as a developer, as an application developer to target the oldest versions of distributions that you can make your software work on. So only depend on stuff after you can be reasonably sure that everyone already has that or optionally bundle the stuff. If I absolutely need to have a version of a library that is newer than what Ubuntu long term release or Debian stable has, then I have always the option to bundle a private copy of the newer dependency to make the application run also on older systems. Now, library developers, you would think that someone who develops a library like libarchive is at their own freedom to decide the version number this library appears under in distributions, not so as of today. So this brings us into the middle of real world issues. And I've written down quite some of those. I won't go in very much into detail of each. But of course, you can download the entire talk. The URL is on each page here. The whole talk is available as a PDF if you want to dive into the details. Let's start with library file names. Libarchive is a very popular library that is installed on practically every desktop system out there. And the version is currently and has been for some time at version three. But in Ubuntu 1204, it's named libarchive.so.12. And on Ubuntu 14.04, it's named.13. On other distributions, it has totally different names. I asked the developers of Libarchive to finally decide on a version number so that I can be sure that version three is there on all the distributions. They told me they can't do anything about it. The distribution decides the version number. I mean, this is crazy. Another example, libpulse coming same game. Margia has currently version 10. But the app wants version four. Actually, it's all the same version. It's just differences based on some distribution policies. This has nothing to do with the fact that these are actually different versions. It's only about distribution packaging. So someone should decide a same system how we can ensure that the same version is named the same across all systems. We should find someone who can decide that. Library pairs, very similar. Also here, there have been efforts like the file system hierarchy standard where long time ago it was standardized where files in a Unix system should go. But as of today, distributions put libraries into different places. There will be an Ubuntu do it totally different than OpenSUSE, for example, and there are many other examples. Someone again should do a new version of the file system hierarchy to standardize this because there's absolutely no advantage in having this mess. It's just someone missing who says we do it this way. So someone should do it or take this certificates. Just look at where distributions put SSL certificates. It's crazy. Everyone has totally random locations where the same files go. So if you want to compile something that uses the certificates on all Linux systems, you have to deal with all those different locations. Again, I think there is absolutely no value in this. Someone should decide how it goes and we should just do it. Basic libraries. Again, if you compare different desktop Linux systems, you will find that the stack is extremely similar. There is a set of libraries that you will find on virtually every system. But it's just mainly and usually it would take someone to really define what the basic libraries are and ensure that they are there all the time so that we can rely on it. Glib-C is one of those libraries that are on every Linux desktop. I think this library has been under development now for tens of years, for decades. It is really mature by now. I would say it could be frozen indefinitely, only doing security fixes but not really adding symbols anymore. But still, it's being worked on all the time and I mean, Linus mentioned it. It can break from time to time. We should really think about how we can version this and have a version that everyone can rely on. Glib-C is comprised of many parts. All of this, at least on a typical Ubuntu system, comes as part of Glib-C. For a long time, I assumed, well, this is safe to assume that these libraries are there on every system. Actually, for over ten years, that was the case. Until very recently, when I found out Fedora 28 decided to just drop one of those. Libnsl.so1 used to be part of Glib-C until Fedora 27, but not anymore in Fedora 28. And guess what? There was no five-year warning period telling anyone about this. I just decided from today to tomorrow that that is how it is. So really, I think distributions should agree on what is part of the GNUoC library and what we can take for granted. Someone should do that. Freeze it. Don't fiddle with it anymore. Another example is the C++ standard library. For some weird reason, it's always adversion.so.6, even though it covers C++03, 11, 14. So it's constantly evolving what it actually is, but for some reason, it's always under the same version number, clearly not following semantic versioning or anything like that. OpenSSL. Currently, you can't really rely on OpenSSL because there are various different versions that are incompatible and that are distinguished by letters. So there is a version F and a version L, and it's really a bit messy. So we should have a way to link against OpenSSL from an application and be sure that it works. I don't want to bore you with all of the details, but really, the situation is complicated to say the least. This is from the Qt source code. So they do all kinds of weird things to check for libSSL09798 and compare what is there and then find one. So not clean. There are many, many more examples like this. Again, someone should make sane decisions, should decide how often a certain application needs to change, and then be ABI stable for a couple of years. I think something five years maybe might be reasonable to have it in the system. If you need to make changes faster than that, it would also be okay to have more than one version in the system in parallel to say, let's say 26 is part of the desktop Linux standard. Some applications want to use 28, install it in parallel. Not something most distributions do as of today. Usually you get just one version. That's it. Kerberos. If you compile an application today and your application uses curl for network access, most likely you will incur a dependency on Kerberos. Now I could ask you how many of you are actually using Kerberos. Okay, that's actually good. So something like 2% maybe. I think dependencies like these should be weak dependencies so that the other 97% in the room don't need to install it, but the 3% who want to use it can use it. As of today, the Linux system, the way libraries are handled, doesn't really allow for this, at least in an easy way. The whole graphics stack, X11, Xlib, XCB, this is also, in my opinion, basic infrastructure where I think there should be some standardization. As of today, it's uncertain which of the many X components are actually shipped everywhere, what can be taken for granted because it's really not standardized. Same goes for OpenGL and DRM. Same goes for Alsa and Pulse Audio, GTK plus and GTK, Glib. And really, all the text is, if you are interested in the details, but the story is basically always the same. It's all basic infrastructure that you will find on every system, for example, fonts and font rendering. Every system needs to render fonts. There is practically only one library that does that, named font config. So why can't we have some standardization? Why do we have to run into issues like this that some pango FT has some half bus, buffer, set cluster level, all of a sudden a symbol that was introduced out of the blue. We should really standardize this. Someone should do this. Image formats, again, the same very basic, TIF, PNG, JPEG, so every system except when it isn't. NSS, name service, switch, same game. Also here, subtle differences. They put libraries into very weird locations, sub directories. So really not easy. Same goes for our Perl regular expressions. Also on each system. Also here, the naming is totally random, the version numbers. And also if you look into the details, why this is everyone blames the other guys, but no one apparently can do anything about it, even though everyone agrees that it's a mess. Weak dependencies. We already mentioned this briefly. SE Linux and app armor are examples where some systems use these kinds of security elements, but only some systems. And as of today, I need to decide when I compile an application, whether I want to compile dependencies on those libraries in or not. I think things like that should be optional so that I can have weak dependencies that make use of SE Linux or app armor infrastructure if it is there on a system, but still work if it's not there. Now we come a bit into the area of user experience. This goes back to the beginning. If you see a platform as something that makes it easy to run stuff on top of, not just what comes with the system, but stuff that you run from the outside world, it should be easy to run that stuff. But this is actually what happens if you run an executable, an ELF file on a Linux system where the executable bit is missing. It's telling you there is no application installed for executable files. Do you want to search for an application to open this file? Makes no sense whatsoever. So actually someone from the GNOME community has made the proposal that there should be a box saying this binary file has not been marked as trusted. If you know the source of this file, running it as a program, maybe if you don't know the source of this file, running it as a program, maybe unsafe, you can then click here, trust this file, make it executable and run. This is much, much more user friendly. But again, this is just a mockup. That's not what happens today. So someone should make sure that basic operating system stuff like this is handled better. As a Linux, I don't want to dive into details here. Fuse, similar, Fuse is a mounting system for mounting file systems in user land. 95% of desktop distributions come with it, but still it's missing in 5% would be great if functionality like this could finally just be taken for granted and work everywhere. Compilers. Now I have to preface this. I'm not a compiler expert. So I can only say what I would wish would be the case. I'm not sure it's technically possible. But if I compile something today on a certain compiler, it can happen that the compiled binary has a dependency on a certain version of, for example, the lip standard C++ runtime. It would be great if there was some decoupling so that the version of the compiler used would not determine what kind of libraries go into my end product. G streamer is a basic piece of infrastructure for handling multimedia. Again, the usual mess with the file names and paths. I don't want to bore you. Wayland is the new display server. More and more distributions are shipping this now by default. And in my opinion, distributions should really make sure that existing X11 applications run just work as always without any manual additional intervention and without having to configure anything. So distributions are not entirely passive on this, especially enterprise distributions because companies actually don't want to upgrade their system all the time. Companies usually don't want to run rolling release distributions. They want to install something now and then be sure that it works for a long, long time. So Red Hat Enterprise Linux actually makes some enterprise Linux platform guarantees. And I find that very interesting. So there are different compatibility levels and the core libraries are intended to preserve binary compatibility across three consecutive major releases. Now major releases in Red Hat, something might be, hello, test, test, is it working? Should I take, okay, all right. So if you're familiar with Enterprise Linux, you know that one major release is active for a long, long time, so years and years. But now let's see what is part of that compatibility level one. It's actually not much. This is Red Hat Enterprise Linux seven. And you see this is extremely basic. Our, some of our favorites are there like lip standard C plus plus like GTK, interestingly GTK two, right? GTK developers are now talking about four, I think are developing four and are talking about five at this moment. Sorry. Right, they are aiming for the long run, which is not a bad thing, right? But maybe the desktop is more than these few libraries, right? So someone should take this to the next level by first of all, not making a distribution specific. This is only Red Hat, and I just decided that this is the set they steam the right set. This should be community driven, in my opinion. And secondly, the typical desktop stack is much more than what's shown here. So someone should really define this community wide. If that's an excellent question, we will come back to that. So GTK three at this point is still in compatibility level two, which means if you compile something with GTK three on Red Hat seven, you have no guarantee that it will still run on Red Hat eight. Now what? If I want you to take anything from this talk, it's really thinking about the Linux desktop as a platform, which means to think about it as something that we can take for granted rather than a moving target. Backward compatibility is key. And we need to think about the least common denominator that is true for most of the desktop systems out there. We need a new standard body that governs the Linux desktop platform. And the gentleman here in the first row asked exactly this question. Someone should, but who? I don't know. But an obvious choice might be Linux foundation. Right. Linux foundation these days are more interested in servers, containers, Kubernetes. So doesn't seem like they are interested in the desktop so much. Maybe XDG, the cross desktop project. I'm not sure whether it's still alive, but it's consisting mainly of desktop environment people. So GNOME, KDE people, app developers don't seem to be really represented there. Also app users don't seem to be represented there. Linux standard space was a project that went into a very similar direction. They defined what set of libraries should make up a compliant distribution. It was at back at the time consisting mainly of distro people. Also few app developers and app users. But also I don't know whether it is very active anymore. At least it seems like not too many people care. So I haven't seen so many applications that are compiled to be LSB compliant, unfortunately. So I would love to give you the definite answer on who should govern the Linux desktop platform. But I am convinced that as long as we don't find coherent leadership for the user space, as it exists in the kernel space, it's no wonder that it's a mess. Now I mentioned in the beginning there might be a partial solution. And the partial solution, at least the best I could come up with so far, is to look at the least common denominator of all the systems that we have out there by basically comparing them. And then by packaging an application in a way that only what we can take for granted on each of the target systems is used from the system and just privately bundle all the rest. In fact, that's exactly what you would do on Windows or on the Mac as well. And one project that does it is App Image. As I said, there is an App Image developer room. So if you're interested in this and maybe want to package your own application, feel free to come to the developer room and we can go into details. But with this, I would like to open the discussion. Thank you very much for the talk. This is actually stuff that keeps me literally up at night. I have more of a comment than a question. In pretty much the entirety of the talk, you say somebody needs to decide this, somebody needs to decide that. The entire reason this talk exists is because somebody got up and said, well, I'm going to do this. And somebody else decided they're going to do that. Deciding is not enough. We need somebody who, like Linus, is able to decide to put the users ahead of his convenience. Do you see this happening with any of the current structures that we have? Because pretty much everything is about the Rockstar development these days. So if you look at the kernel, the kernel is one project. It's a large project, but still it's a hierarchical project with one clear leadership. If you look at all the components that make up the Linux desktop, the user land, it is not one project. It's many projects. So I can't imagine someone to step up and have authority over all those projects, basically dictating what needs to happen. The only thing that I can imagine works is that a standard is proposed. Application developers start adopting this standard. And all of a sudden, the dynamic shifts because if then many, many users want to run applications that are written against that standard and distribution X or library Y doesn't support it, they have a bug report. I'm just a regular user and not so much of a developer, but in my opinion, it's first that there's no attention against that because there's no big money there. There's no large platform that had even in RedRest just only Keras was a service. But I think when you look at larger projects like Qt, you have a large platform that platform is compatible until the next major release. You can do your app, you can do anything. It doesn't break. In my opinion, we should have something like that that let something desktop and depend. What I want to say is when you develop an app against Qt or against KDE, what wants to develop a platform on top of Qt because Qt is not a full platform, you can just compile the app and it will run. K5 is about five, six years old and I can compile an app that's so old, started at the first release and it's compatible. So I think that's in... I have a little problem with English. No problem. I think I heard two points here. Number one, big corporations can set standards better than a community. I use Arch and the disruption always aligns with Red Hat because that's where the money lies. That's what I wanted to say. When you look at GNOME, you had the example of XTG. XTG is like the name, but mainly the stuff that happens there is said by GNOME people and GNOME people say, okay, this is okay, this is okay, but when they don't say it's okay and say that's not our opinion, they go fuck yourself. They don't... Sorry for my rude language, but that's exactly what happens when they don't want to do something. They don't want to do something. That's what I meant with application. Authors are not represented in this discussion enough. Do they develop application, but when you want to use their application without GNOME, you have to do workarounds to make it look like... Yeah, I share this. This is what I meant initially when I talked about this cross-platform applications. Of course GNOME do their own applications. Of course KDE do their own applications and they are deeply integrated into the respective desktop, but then if you look at the real world productivity applications, the larger ones, most of them are actually cross-platform. Right, if you look at the great number of electron apps, this is... What's electron and core in any of the trustable men in GNOME object papers? That's true. To your point regarding the large corporations, if we as a community don't get this desktop stuff fixed, it could well be that something like Chrome OS will do what happened in the mobile space, where you have the Linux kernel running because that's stable, that's trustable, and all the other mess gets thrown away and replaced by something that is half proprietary. I don't know whether we want that. I'd like to question the original problem assessment a little bit, because yes, it is a mess, definitely. Yes, it makes it hard to actually program universally for many distributions, but we had many initiatives you already mentioned before like LSB and so on, to unify this, they all failed. XDG brought some standardization, but it's just a tiny little bit, and it's mostly dead as well. I don't think that can be solved because there's been so many tries within the past 15 years, and the way it looks like is app image, flat pack, and so on. I think that's the way it goes now. The other mess is not going to be resolved. Your opinion to that? Well, I'm an optimist. I've been working on app image for the last 10 years, and we have tried not to work around the system, but really find the common denominator. The other two systems I mentioned, they basically gave up on the idea that there will ever be a common base, and they just put in their own full stack. That's in my opinion, giving up, and I'm not ready to give up yet. Well, it's a matter of definition, how big your base have to be. Minimulistically, it's a kernel. But that's not very useful on a desktop system. Well, okay. The gentleman in the middle, no? Thank you. So there's this big trend towards containerization. How would you set that to perspective? So it is a question, what actually container is. For some time, we even wanted to call this containerized desktop apps. The, I think one question is how much of the base system do you want to use? I would say an application should not bring the whole world with the application, which would be the typical container approach where you only use the kernel and bundle everything else. So that's question number one. I think the application should have something to rely on to not duplicate everything to have less bloat. Number two is the level of isolation between the application and the rest of the system. I'm coming from a world in which there was absolutely no separation. In fact, the first Macintosh is there weren't even users. Everything ran as route all the time. You can argue whether you want this or not. But my opinion is that at least for the desktop, if you don't trust an application and an application author, you should better not run the application at all because no matter what technical measures in terms of sandboxing you put in, if the application is malicious, I mean, it can socially engineer you. It can use loopholes in the sandboxing. So, but that's my personal opinion. I don't need a high level of sandboxing for desktop applications because I decide whom I trust and what I want to run. But then if some users want to sandbox applications to dry stuff out, fine. I think it should be optional though. I'd like to point out a fact about the Windows and how it's not really a very uniform platform where you have several runtimes. Depending on the year, the Visual Studio was produced and most applications end up bundling their own libraries. So, in Linux world, we don't even have... I mean, in Windows, you do have a couple of things which are standard, which is the Win32 API and graphics libraries. In Linux, we don't have that. And I would like to ask your opinion of how high do you think the base platform should go? What should be the components of the base thing to make Linux a viable platform? Okay, very tricky questions, not easy questions. So, when I refer to Windows and also Mac OS as typical platforms, I mean, more in spirit than in good execution. So, Windows, clearly no one has the idea that you need to get your application into Windows in order for it to be used by users. But everyone understands you have Windows and then you get the application from the author of the application and run it on top. Even though Microsoft wants to change this with the store, it seems to me like user acceptance is not that high and people actually like to use the platform with side loading, with getting stuff from outside of Microsoft. So, that's what I meant with this. It's... You're absolutely correct. Windows implementation is not particularly great at this platform idea. The second question. What do you think is necessary to make Linux? Yeah, how high should we go? Excellent question. So, I think there is obvious stuff that every desktop has to have like font rendering, like codecs for multimedia, like this display server printing. Yeah, everything that basically you will find as a dependency in each and every desktop application. That is... And that's a vague answer, I know. So, you could think about should GTK be part of this? Should Qt be part of this? I'm not 100% sure, because if you look at real world Qt applications, oftentimes they are optimized for one specific release of Qt. In this particular application, whereas in other application that you might care about is optimized for a different version of Qt. So, I think really we should have a look at what are the components that almost all applications require, and that should make up the desktop platform. Any more questions? So, maybe one question. Is it almost all? I think maybe it would be helpful if it's really just almost, because I mean there will be when there's a certain adoption of this image app or something, then there will be pressure for the distributions to align with this. And I think that's maybe a good thing, because it's really messy and to clean up some pressure, maybe a little. What's your thing, thinking about this? Yeah, that's a very good point. So, you're essentially saying as the system starts being used, there will be a dynamic that will lead distributions to comply. It's a bit of chicken and an egg problem, because if I put out an application today, I need to make sure it works. Otherwise, everyone will be frustrated, no one will use it. So, as an application author, today I can only use what is there in the distributions. And if the big mess is there, the same library under different versions, I will have to bundle this privately with my application, hence removing the need for distributions to align. So, it's really a chicken and egg situation. Have you tried to talk to the distributions to align their library names? For example, the library names are itself a back compatibility against older versions. And it's like the German name is Stoffelskreis, Devil's Circle, where you have chase you around and it doesn't change. Right. So, of course, the library naming system as it exists has some valid thoughts behind it. There is a reason why it is like it is. But I mean, intuitively, the outcome of what we have today seems wrong. If an application author cannot say this is version three of the application, and I want it named version three everywhere, then somehow the system is wrong. And I haven't found yet the right organization or person that could solve it. If anyone knows, I'm really interested in who to talk to. I think the issue is when disruptions try to patch the software too hard, when you look, for example, for end-of-patterns disruptions that patch the current very heavily because they rely so much on older versions to fix them and so on, that the software is going to modify it so much that it's not longer an upstream project. It's more like downstream modification and MX. I think it's the idea of a disruption is great, but some disruptions do it too much. Ubuntu tries to be more Ubuntu platform, not Linux distributions. It's like putting a knife against other disruptions in the back of other disruptions. And about the library name thing, that's the words where package conflict is for, where you as developer can get the right library flex while you compiler and the right include files and so on from the library name. And the developer has just to put this file in his project and the application can just use it and doesn't have to know where everything is. I think it's the common base of every library. So what you mentioned, distributions caring about their own distribution and not much else, that is what I observe as of today. But really, I think it hurts everyone because if you see it as from the perspective of someone who wants to do a cross platform application, if this already 2% market share is subdivided like today, it's just not attractive. And I think the result is that we don't see many great applications that we would see if distributions would work together more. I think they hurt each other by this behavior. I think they want to hurt because that's the systems the commercials do make things a little bit other. You could do it the same, but don't you will lose money. Well, your argument is some argument that is very common in the commercial world. So if we are talking about commercial software vendors, I would totally buy this, but this is open source. Right? This is supposed to be community. But I have friends when I tell that our community in Cologne should agree how to handle beginners. You get a mess of options and they don't want to say, as was said some time ago, we only have the idea of use it or when you don't use it, you get no help. And in the last weeks, I had an idea to do a software label activity. They had little ideas about that. But I think if you have a label by some testing system, that would be the first step that you mentioned this test should run. Put it in Python, for example. Right. So a test suite was I think it was Linux standard space, LSB. I think there were some tests that if the tests were passing, you could be sure that this application would run on all LSB compliant distributions. Unfortunately, and I don't know why that is, but unfortunately, very few application developers actually developed against the LSB standard. That's a bit puzzling to me. Maybe it was too cumbersome. Maybe they just didn't care. I don't know. But I think you're right. We should have a specification. We should have a testing suite so that if you pass the test, you are sure that it runs on all compliant distributions. In the app image project, we have something that goes into this direction. We call it app image hub where we run a set of tests against automated against every submitted application. And if it passes that test, we are at least sure as of now it runs on Ubuntu 14.04, which is an old distribution, right? But one could expand this, of course, in the sense that you just described. The responsible for the whole system since 25 years. And I think that is a wonder of Linux. And we maybe we should talk more about such a wonder. That's the advice of an old man. Thank you very much. I think we have one last question. I just want to make one statement. He just talked about the wonder of Linux Torwald. I think there's one big vulnerability here. He's just a man. He is not a god. He will die somewhere. So I think we have we have we ally on this hierarchical structure. And I think projects are vulnerable for something like this. And I mean, someone will replace them. It's just it will change not change anything. But the symbol is a great, a great strength. And we will lose it when we so much rely on one person. That's a danger, I think. Very true. So I said it in the beginning, I don't have the perfect solution, unfortunately, but I hope this talk makes you think a bit about this whole idea of a platform. And how a platform is different from what we have today in terms of Linux distributions. Again, feel free to step by the app image development room and we have flyers also here in case you're interested. Thank you very much for coming.
 Hello, thanks for coming. I'm Simon. I would like to talk a bit about desktop Linux platform  issues today. So if someone of you doesn't like people ranting on stage about stuff that's  not perfect, about stuff that's broken, about stuff that's not working, please feel free,  now. I do have a solution, but that's not the main topic of the talk. It's really about  pointing out what we as a community should think about and the kinds of issues that I  think we need to solve together if we want to make Linux a viable platform for desktop  applications. So a short background about me. I have been essentially a Mac user since  forever and Mac is a platform where magically stuff just works, at least used to. I'm a  Linux user since around 1998-ish and I have been fascinated by Linux live CDs right from  the start where you don't have to install stuff, you just boot up a live CD or later  a live USB system and just can start working. Also, I'm a distro hopper, so every time I  boot my system, it asks me actually which out of hundreds of distributions I have on  my system I want to launch this time and I make a point out of this. Also, I've been  thinking about how to package Linux applications for Linux users for quite some time. Originally,  I started the project called Click. This was 2004, which over time evolved into what is  App Image today. This talk is not about App Image. App Image may be part of the solution,  so if you're interested in that, we have a deaf room upstairs for everyone who is interested  in App Image or packaging an application as an App Image, feel free to step to come by.  But here really, what are the underlying issues on the Linux platform? This is what we should  discuss today, so I hope to keep my talk short so that we have lots of time for discussion  in the end. Linux on the desktop really is a niche in itself. Looking at the desktop  operating market share, we see it's basically all Windows and Mac. With Windows over 88%  market share, Mac OS over 8%, this doesn't leave a lot for Linux, which is depending  on which survey you believe somewhere between 2% and 3% as of today. Really, as an application  developer, when you want to reach as many users as possible, it's obvious that you go  for Windows first, Mac second, and then maybe you start thinking about Linux and if it doesn't  create additional work, maybe you consider to also go for these 2% guys there. Really,  this is not the worst yet, because if you look into the 2%, that's what you get. Hundreds  of different distributions living in different ecosystems where you have the Debian-ish  ecosystem with Ubuntu and you have the Redhead-ish with Fedora and Santos, but really, this is  the family tree by now. In the traditional distribution model for applications on the  Linux platform, you had to build for each of those and you had to target each of those  hundreds of distributions. It doesn't stop there. For every distribution, you have different  desktops and some of those desktops are actually quite opinionated as of today, how applications  should be made and also, they start to have an opinion about how applications should be  distributed. For example, there is elementary, great operating system, great design, great  usability, but they expect people to write applications for elementary OS, which is a  tiny, tiny fraction out of the tiny, tiny fraction of the market share that we just  saw. Similar GNOME expects applications to be written against GNOME frameworks in a very  specific way. All of those desktops have certain ideas how applications should be  written for Linux and how they should be distributed, but that is a bit conflicting with the view  of an actual application author. Because if you look at it this way, the answer cannot  be to develop each application for each distribution and for each desktop, because if you do the  multiplication, less than 3% times distro market share, less than 10% times desktop market  share, it's nothing. You are not left with any users. So this led to the fact that even  Linus Torwalds, who not only famously wrote the kernel, but also a dive log application,  at some point stated that they are not distributing their own application for Linux. They provided  binaries for Windows and for Mac, but not for Linux. And he went in public about this.  He said, you don't make binaries for Linux. You would have to do it for Fedora 19 and  20 and Red Hat Enterprise. And then there is Debian with their rules. It's a mess and  you don't do it. If you're interested in this on YouTube, he has a long rant. He goes on  and on about this issue. So it's really worth seeing. I don't want to play it here now because  language might not be suitable for all audiences, but if you're interested, great watch.  So with this situation, it's really no wonder that we have no mainstream commercial applications.  And I get it. Some people will say we don't need it. Fine. Your opinion, I think it would  be great to also have in addition to the great open source applications, some commercial  applications, you might work in a job where this is required, whatever. If I can do work  on a Linux system that I would be forced to do on a Windows system, otherwise I will  take the Linux system at any day. So I would be interested in seeing this kind of applications,  whether I personally use it or not. So real world applications like Photoshop, there is  no way they are made for each desktop. I mean, it simply won't happen, right? So even open  source applications, sometimes it goes a bit differently than from how it was planned.  Krita started out as a graphical application for the KDE desktop on Linux, predominantly  addressing KDE users. But today it has more downloads for the Windows platform by far  than for any Linux system. And if you look at other real world applications, what I  tend to notice is that the applications I use on a daily basis, they are all cross-platform.  They are all available on Windows, Mac and Linux. So there are famous names, Firefox,  OpenOffice, Arduino, Scribus, Electron, you name it. These applications are mostly written  in cross-platform graphical toolkits like Qt, some use WX Windows, some use GTK. Increasingly,  we see more and more electron apps, and this comes with pros and cons, but it shows that  there is a real need for something that unifies Windows, Mac and Linux. Now, as an app developer,  it is really key that you have a dependable platform on which you can develop, which allows  you to reach a large user base, which allows you to produce an application in a supportable  way, where you know my application runs on a known infrastructure, because you want to  have as little work as possible as an application author. So when you think about what a platform  is, a platform is really something that builds the foundation on top of which you run your  own stuff. And the large desktop environments that are successful in the market, they see  themselves as platforms. Windows is a platform, Mac OS is a platform. About Linux, we will  have to talk, right? And yes, there is this increasing trend that Apple and Microsoft  want to push people into app stores, but if you look at the reality, that's not what users  really want. And also many application developers don't really want. With Linux, we have a moving  target here. And the moving target is not a good platform. Whereas here, if I compile  an application on Windows, let's say seven, I can be reasonably sure that it will continue  to work on Windows seven and on Windows 10. Same for Mac. You can compile an application  Mac OS 10.9 and will run on all recent versions. On Linux, big question mark, because stuff  can break, there are no guarantees. I mean, Apple announces years in advance, we are about  to deprecate this and that and you get an early warning in the IDE if you use stuff that's  deprecated and they leave it there for years before they finally remove it. This kind of  thinking is in my opinion, missing on the Linux platform where you just get something that's  recent today and tomorrow you get something else and you have absolutely no guarantees  what you can depend on.  Linux also shares this view, by the way. He really thinks breaking the user space is really  a bad idea. In his kernel work, he always makes sure that nothing breaks user space,  but at the same time, he notices that user space people break user space all the time.  He explicitly mentions G-Lib C here as an example, but there are many, many other examples.  We will see some really soon. In my opinion, breaking the user space all the time needs  to stop.  Now I'm not the only one to notice this issue and there are different approaches how this  could be solved. One approach is to have the kernel, which has a stable interface between  the kernel and user land, which Linux ensures, but then as of today, in user land, we have  a completely moving target. Now, what you could do is to ignore this moving target entirely,  not use anything that comes with your Linux distribution in terms of libraries and infrastructure  and services, just forget about all of that, and then ship a runtime that has essentially  a second operating system except for the kernel, which is defined. That is what systems like  Flatpak and Snappy do. Flatpak, you get a runtime that is really that contains everything  you would normally expect from an operating system minus the kernel. Snappy, the same  thing here, it is usually built on some version of Ubuntu and applications now can develop  against these defined runtimes. The advantage for the application author is that there is  something I can trust that does not change from today to tomorrow, but the big downside  of course is that I'm essentially throwing away the real operating system, the real stuff  that comes with the distribution that's only used for showing the desktop essentially and  applications don't make use of this. So it's a lot of duplication, but it gets worse once  applications over time require different versions of those runtimes. You have a nice collection  of operating systems over time. You cannot think that every application will require  the same frameworks in the same versions, so this will really grow and grow over time.  I think this is not the most elegant solution to the problem, and I'm always an optimist,  so I'm optimistic that by bringing in discussion into the open source community, we can end  up with something like a guaranteed common Linux desktop platform, because if you look  at the distributions and what they are shipping, it's not so different. It's always the same  stack and some of the core components that make up a typical Linux desktop system we  will see in a second. So really, if you look at Ubuntu, if you look at Debian, if you look  at elementary, under the hood, it's all very, very similar.  For me, the key is to think about how to distribute a desktop in terms of thinking what a platform  is. And a platform is something different from a traditional Linux distribution, because  platforms are something that allow authors to run additional stuff on top of. That's  different from trying to get something into a distribution. A Linux distribution is built  for shipping everything, building it in and requires an application author to get stuff  into the distribution. That's not the platform idea. The platform says I'm the platform.  I guarantee you that I provide you this. Use it however you like. I don't care. All successful  OSes, if you think about it, both on the desktop and also in the mobile world, are built this  way. You don't try to get an application into the Android open source project normally,  unless it's a very low level piece of code. You don't try to get your software into Windows.  You write software for Windows. You write software for Android. And that is the platform  idea. Now, distribution, people are really not working on solving this problem, because  they see it differently. Usually a distribution cares about their own distribution, and that's  all. But users care. I want to download an application on the day it is released, ideally  directly from the application author. Application developers care, because they want to reach  as many users as possible with their application without having to do a lot of work and addressing  each distribution individually. And finally, I think library developers should care, but  sometimes they even can't. We will see an example about this in a second. So today's  distributions are not really optimized for running third party stuff that is outside  of the distribution. They usually want to package world for themselves and most make  no guarantees in terms of what infrastructure they provide. A somewhat extreme example here  is coming straight from the Ubuntu wiki, where they say normally and preferably software  should be installed using Ubuntu software center. And the whole page explains why it's  a very bad idea to run anything on your operating system that is not coming from Ubuntu. I think  that's wrong. This is clearly not platform thinking. There are many, many reasons why  this mindset is problematic. An author may just want to ship an application as it is  without caring too much about individual distributions policies. An author may want to have some  control over the downloads. For example, an author may want to count the number of downloads.  This doesn't work in the traditional distribution model. Or an author may want for legitimate  reasons the user to pay before the user can download a software or to fill in a survey  before downloading an application. Users may want to run many versions of the same app  in parallel. This is also typically not possible in the way distributions manage software.  You always have one version of an application and can update that. But for testing, for  example, it may be very useful to be able to run as many versions as you like in parallel.  And finally, a user may want to have the app in the instant it is released without having  to wait before an application is backported to long term stable or Debian stable or whatever.  This comes to the point that in many cases, a user may want to run software that's coming  directly from an author. The distribution models should open up to be a platform that  allows for this. Most other platforms do. It's usually called side loading in the mobile  world. And I think this is very important as a feature for the Linux desktop as well.  A key to achieving this is to constantly think about backward compatibility. I'm always a  bit surprised when I see that someone writes an application and uses the latest versions  of compilers and dependencies and libraries that are available. Because that in essence  means that you will get into big trouble running this application on anything but the very  latest operating system. And the reality is if you look out there, your users, they will  be using older operating systems. Typically, if you look in the enterprise world, it can  be very old systems. So in my opinion, it is always important as a developer, as an application  developer to target the oldest versions of distributions that you can make your software  work on. So only depend on stuff after you can be reasonably sure that everyone already  has that or optionally bundle the stuff. If I absolutely need to have a version of a  library that is newer than what Ubuntu long term release or Debian stable has, then I  have always the option to bundle a private copy of the newer dependency to make the application  run also on older systems. Now, library developers, you would think that someone who develops  a library like libarchive is at their own freedom to decide the version number this  library appears under in distributions, not so as of today. So this brings us into the  middle of real world issues. And I've written down quite some of those. I won't go in very  much into detail of each. But of course, you can download the entire talk. The URL is on  each page here. The whole talk is available as a PDF if you want to dive into the details.  Let's start with library file names. Libarchive is a very popular library that is installed  on practically every desktop system out there. And the version is currently and has been  for some time at version three. But in Ubuntu 1204, it's named libarchive.so.12. And on  Ubuntu 14.04, it's named.13. On other distributions, it has totally different names. I asked the  developers of Libarchive to finally decide on a version number so that I can be sure  that version three is there on all the distributions. They told me they can't do anything about it.  The distribution decides the version number. I mean, this is crazy. Another example, libpulse  coming same game. Margia has currently version 10. But the app wants version four. Actually,  it's all the same version. It's just differences based on some distribution policies. This  has nothing to do with the fact that these are actually different versions. It's only  about distribution packaging. So someone should decide a same system how we can ensure that  the same version is named the same across all systems. We should find someone who can  decide that. Library pairs, very similar. Also here, there have been efforts like the file  system hierarchy standard where long time ago it was standardized where files in a Unix  system should go. But as of today, distributions put libraries into different places. There  will be an Ubuntu do it totally different than OpenSUSE, for example, and there are many  other examples. Someone again should do a new version of the file system hierarchy to  standardize this because there's absolutely no advantage in having this mess. It's just  someone missing who says we do it this way. So someone should do it or take this certificates.  Just look at where distributions put SSL certificates. It's crazy. Everyone has totally random locations  where the same files go. So if you want to compile something that uses the certificates  on all Linux systems, you have to deal with all those different locations. Again, I think  there is absolutely no value in this. Someone should decide how it goes and we should just  do it. Basic libraries. Again, if you compare different desktop Linux systems, you will  find that the stack is extremely similar. There is a set of libraries that you will  find on virtually every system. But it's just mainly and usually it would take someone to  really define what the basic libraries are and ensure that they are there all the time  so that we can rely on it. Glib-C is one of those libraries that are on every Linux desktop.  I think this library has been under development now for tens of years, for decades. It is  really mature by now. I would say it could be frozen indefinitely, only doing security  fixes but not really adding symbols anymore. But still, it's being worked on all the time  and I mean, Linus mentioned it. It can break from time to time. We should really think  about how we can version this and have a version that everyone can rely on. Glib-C is comprised  of many parts. All of this, at least on a typical Ubuntu system, comes as part of Glib-C.  For a long time, I assumed, well, this is safe to assume that these libraries are there  on every system. Actually, for over ten years, that was the case. Until very recently, when  I found out Fedora 28 decided to just drop one of those. Libnsl.so1 used to be part of  Glib-C until Fedora 27, but not anymore in Fedora 28. And guess what? There was no five-year  warning period telling anyone about this. I just decided from today to tomorrow that  that is how it is. So really, I think distributions should agree on what is part of the GNUoC  library and what we can take for granted. Someone should do that. Freeze it. Don't fiddle  with it anymore. Another example is the C++ standard library. For some weird reason, it's  always adversion.so.6, even though it covers C++03, 11, 14. So it's constantly evolving  what it actually is, but for some reason, it's always under the same version number,  clearly not following semantic versioning or anything like that. OpenSSL. Currently, you  can't really rely on OpenSSL because there are various different versions that are incompatible  and that are distinguished by letters. So there is a version F and a version L, and  it's really a bit messy. So we should have a way to link against OpenSSL from an application  and be sure that it works. I don't want to bore you with all of the details, but really,  the situation is complicated to say the least. This is from the Qt source code. So they do  all kinds of weird things to check for libSSL09798 and compare what is there and then find one.  So not clean. There are many, many more examples like this. Again, someone should make sane  decisions, should decide how often a certain application needs to change, and then be ABI  stable for a couple of years. I think something five years maybe might be reasonable to have  it in the system. If you need to make changes faster than that, it would also be okay to  have more than one version in the system in parallel to say, let's say 26 is part of the  desktop Linux standard. Some applications want to use 28, install it in parallel. Not something  most distributions do as of today. Usually you get just one version. That's it. Kerberos.  If you compile an application today and your application uses curl for network access,  most likely you will incur a dependency on Kerberos. Now I could ask you how many of  you are actually using Kerberos. Okay, that's actually good. So something like 2% maybe.  I think dependencies like these should be weak dependencies so that the other 97% in  the room don't need to install it, but the 3% who want to use it can use it. As of today,  the Linux system, the way libraries are handled, doesn't really allow for this, at least in  an easy way. The whole graphics stack, X11, Xlib, XCB, this is also, in my opinion, basic  infrastructure where I think there should be some standardization. As of today, it's  uncertain which of the many X components are actually shipped everywhere, what can be taken  for granted because it's really not standardized. Same goes for OpenGL and DRM. Same goes for  Alsa and Pulse Audio, GTK plus and GTK, Glib. And really, all the text is, if you are interested  in the details, but the story is basically always the same. It's all basic infrastructure  that you will find on every system, for example, fonts and font rendering. Every system needs  to render fonts. There is practically only one library that does that, named font config.  So why can't we have some standardization? Why do we have to run into issues like this  that some pango FT has some half bus, buffer, set cluster level, all of a sudden a symbol  that was introduced out of the blue. We should really standardize this. Someone should do  this. Image formats, again, the same very basic,  TIF, PNG, JPEG, so every system except when it isn't. NSS, name service, switch, same  game. Also here, subtle differences. They put libraries into very weird locations, sub  directories. So really not easy. Same goes for our Perl regular expressions. Also on  each system. Also here, the naming is totally random, the version numbers. And also if you  look into the details, why this is everyone blames the other guys, but no one apparently  can do anything about it, even though everyone agrees that it's a mess.  Weak dependencies. We already mentioned this briefly. SE Linux and app armor are examples  where some systems use these kinds of security elements, but only some systems. And as of  today, I need to decide when I compile an application, whether I want to compile dependencies  on those libraries in or not. I think things like that should be optional so that I can  have weak dependencies that make use of SE Linux or app armor infrastructure if it is  there on a system, but still work if it's not there. Now we come a bit into the area  of user experience. This goes back to the beginning. If you see a platform as something  that makes it easy to run stuff on top of, not just what comes with the system, but stuff  that you run from the outside world, it should be easy to run that stuff. But this is actually  what happens if you run an executable, an ELF file on a Linux system where the executable  bit is missing. It's telling you there is no application installed for executable files.  Do you want to search for an application to open this file? Makes no sense whatsoever.  So actually someone from the GNOME community has made the proposal that there should be  a box saying this binary file has not been marked as trusted. If you know the source  of this file, running it as a program, maybe if you don't know the source of this file,  running it as a program, maybe unsafe, you can then click here, trust this file, make  it executable and run. This is much, much more user friendly. But again, this is just  a mockup. That's not what happens today. So someone should make sure that basic operating  system stuff like this is handled better. As a Linux, I don't want to dive into details  here. Fuse, similar, Fuse is a mounting system for mounting file systems in user land. 95%  of desktop distributions come with it, but still it's missing in 5% would be great if  functionality like this could finally just be taken for granted and work everywhere.  Compilers. Now I have to preface this. I'm not a compiler expert. So I can only say what  I would wish would be the case. I'm not sure it's technically possible. But if I compile  something today on a certain compiler, it can happen that the compiled binary has a dependency  on a certain version of, for example, the lip standard C++ runtime. It would be great  if there was some decoupling so that the version of the compiler used would not determine what  kind of libraries go into my end product. G streamer is a basic piece of infrastructure  for handling multimedia. Again, the usual mess with the file names and paths. I don't  want to bore you. Wayland is the new display server. More and more distributions are shipping  this now by default. And in my opinion, distributions should really make sure that existing X11  applications run just work as always without any manual additional intervention and without  having to configure anything. So distributions are not entirely passive on this, especially  enterprise distributions because companies actually don't want to upgrade their system  all the time. Companies usually don't want to run rolling release distributions. They  want to install something now and then be sure that it works for a long, long time. So Red Hat  Enterprise Linux actually makes some enterprise Linux platform guarantees. And I find that  very interesting. So there are different compatibility levels and the core libraries are intended  to preserve binary compatibility across three consecutive major releases. Now major releases  in Red Hat, something might be, hello, test, test, is it working? Should I take, okay, all right.  So if you're familiar with Enterprise Linux, you know that one major release  is active for a long, long time, so years and years.  But now let's see what is part of that compatibility level one. It's actually not much.  This is Red Hat Enterprise Linux seven. And you see this is extremely basic.  Our, some of our favorites are there like lip standard C plus plus like GTK, interestingly GTK  two, right? GTK developers are now talking about four, I think are developing four and are talking  about five at this moment. Sorry. Right, they are aiming for the long run, which is not a bad thing,  right? But maybe the desktop is more than these few libraries, right? So someone should take this  to the next level by first of all, not making a distribution specific. This is only Red Hat,  and I just decided that this is the set they steam the right set. This should be community  driven, in my opinion. And secondly, the typical desktop stack is much more than what's shown here.  So someone should really define this community wide.  If that's an excellent question, we will come back to that.  So GTK three at this point is still in compatibility level two, which means if you compile something  with GTK three on Red Hat seven, you have no guarantee that it will still run on Red Hat eight.  Now what? If I want you to take anything from this talk, it's really thinking about the Linux  desktop as a platform, which means to think about it as something that we can take for granted  rather than a moving target. Backward compatibility is key. And we need to think about the least  common denominator that is true for most of the desktop systems out there. We need a new standard  body that governs the Linux desktop platform. And the gentleman here in the first row asked exactly  this question. Someone should, but who? I don't know. But an obvious choice might be Linux foundation.  Right. Linux foundation these days are more interested in servers, containers, Kubernetes.  So doesn't seem like they are interested in the desktop so much. Maybe XDG, the cross desktop  project. I'm not sure whether it's still alive, but it's consisting mainly of desktop environment  people. So GNOME, KDE people, app developers don't seem to be really represented there.  Also app users don't seem to be represented there. Linux standard space was a project that went into  a very similar direction. They defined what set of libraries should make up a compliant distribution.  It was at back at the time consisting mainly of distro people. Also few app developers and app  users. But also I don't know whether it is very active anymore. At least it seems like not too many  people care. So I haven't seen so many applications that are compiled to be LSB compliant,  unfortunately. So I would love to give you the definite answer on who should govern the Linux  desktop platform. But I am convinced that as long as we don't find coherent leadership for the user  space, as it exists in the kernel space, it's no wonder that it's a mess. Now I mentioned in the  beginning there might be a partial solution. And the partial solution, at least the best I could  come up with so far, is to look at the least common denominator of all the systems that we have out  there by basically comparing them. And then by packaging an application in a way that only what  we can take for granted on each of the target systems is used from the system and just privately  bundle all the rest. In fact, that's exactly what you would do on Windows or on the Mac as well.  And one project that does it is App Image. As I said, there is an App Image developer room. So  if you're interested in this and maybe want to package your own application, feel free to come  to the developer room and we can go into details. But with this, I would like to open the discussion.  Thank you very much for the talk. This is actually stuff that keeps me literally up at night.  I have more of a comment than a question. In pretty much the entirety of the talk, you say  somebody needs to decide this, somebody needs to decide that. The entire reason this talk exists  is because somebody got up and said, well, I'm going to do this. And somebody else decided  they're going to do that. Deciding is not enough. We need somebody who, like Linus, is able to decide  to put the users ahead of his convenience. Do you see this happening with any of the current  structures that we have? Because pretty much everything is about the Rockstar development  these days. So if you look at the kernel, the kernel is one project. It's a large project,  but still it's a hierarchical project with one clear leadership. If you look at all the components  that make up the Linux desktop, the user land, it is not one project. It's many projects. So  I can't imagine someone to step up and have authority over all those projects, basically  dictating what needs to happen. The only thing that I can imagine works is that a standard is  proposed. Application developers start adopting this standard. And all of a sudden, the dynamic  shifts because if then many, many users want to run applications that are written against that  standard and distribution X or library Y doesn't support it, they have a bug report.  I'm just a regular user and not so much of a developer, but in my opinion,  it's first that there's no attention against that because there's no big money there. There's no  large platform that had even in RedRest just only Keras was a service. But I think when you look at  larger projects like Qt, you have a large platform that platform is compatible until the next major  release. You can do your app, you can do anything. It doesn't break. In my opinion, we should have  something like that that let something desktop and depend. What I want to say is when you develop  an app against Qt or against KDE, what wants to develop a platform on top of Qt because Qt is  not a full platform, you can just compile the app and it will run. K5 is about five, six years old  and I can compile an app that's so old, started at the first release and it's compatible. So I think  that's in... I have a little problem with English.  No problem. I think I heard two points here. Number one, big corporations can set standards  better than a community. I use Arch and the disruption always aligns with Red Hat because  that's where the money lies. That's what I wanted to say. When you look at GNOME, you had the example  of XTG. XTG is like the name, but mainly the stuff that happens there is said by GNOME people  and GNOME people say, okay, this is okay, this is okay, but when they don't say it's okay and  say that's not our opinion, they go fuck yourself. They don't... Sorry for my rude language, but  that's exactly what happens when they don't want to do something. They don't want to do something.  That's what I meant with application. Authors are not represented in this discussion enough.  Do they develop application, but when you want to use their application without GNOME,  you have to do workarounds to make it look like...  Yeah, I share this. This is what I meant initially when I talked about this cross-platform  applications. Of course GNOME do their own applications. Of course KDE do their own applications  and they are deeply integrated into the respective desktop, but then if you look at the real world  productivity applications, the larger ones, most of them are actually cross-platform.  Right, if you look at the great number of electron apps, this is...  What's electron and core in any of the trustable men in GNOME object papers?  That's true. To your point regarding the large corporations, if we as a community don't get  this desktop stuff fixed, it could well be that something like Chrome OS will do what happened  in the mobile space, where you have the Linux kernel running because that's stable, that's trustable,  and all the other mess gets thrown away and replaced by something that is half proprietary.  I don't know whether we want that.  I'd like to question the original problem assessment a little bit, because yes, it is a mess,  definitely. Yes, it makes it hard to actually program universally for many distributions,  but we had many initiatives you already mentioned before like LSB and so on,  to unify this, they all failed. XDG brought some standardization, but it's just a tiny little bit,  and it's mostly dead as well. I don't think that can be solved because there's been so many tries  within the past 15 years, and the way it looks like is app image, flat pack, and so on.  I think that's the way it goes now. The other mess is not going to be resolved.  Your opinion to that? Well, I'm an optimist. I've been working on app image for the last 10 years,  and we have tried not to work around the system, but really find the common denominator.  The other two systems I mentioned, they basically gave up on the idea that there will ever be a  common base, and they just put in their own full stack. That's in my opinion, giving up,  and I'm not ready to give up yet. Well, it's a matter of definition,  how big your base have to be. Minimulistically, it's a kernel.  But that's not very useful on a desktop system. Well, okay.  The gentleman in the middle, no?  Thank you. So there's this big trend towards containerization. How would you set that to  perspective? So it is a question, what actually container is. For some time, we even wanted  to call this containerized desktop apps. The, I think one question is how much of the base system  do you want to use? I would say an application should not bring the whole world with the  application, which would be the typical container approach where you only use the kernel and bundle  everything else. So that's question number one. I think the application should have something to  rely on to not duplicate everything to have less bloat. Number two is the level of isolation between  the application and the rest of the system. I'm coming from a world in which there was absolutely  no separation. In fact, the first Macintosh is there weren't even users. Everything ran as  route all the time. You can argue whether you want this or not. But my opinion is that at least  for the desktop, if you don't trust an application and an application author, you should better not  run the application at all because no matter what technical measures in terms of sandboxing you put  in, if the application is malicious, I mean, it can socially engineer you. It can use loopholes in  the sandboxing. So, but that's my personal opinion. I don't need a high level of sandboxing for  desktop applications because I decide whom I trust and what I want to run. But then if some  users want to sandbox applications to dry stuff out, fine. I think it should be optional though.  I'd like to point out a fact about the Windows and how it's not really a very uniform platform  where you have several runtimes. Depending on the year, the Visual Studio was produced and  most applications end up bundling their own libraries. So, in Linux world, we don't even have...  I mean, in Windows, you do have a couple of things which are standard, which is the Win32 API and  graphics libraries. In Linux, we don't have that. And I would like to ask your opinion of how high  do you think the base platform should go? What should be the components of the base  thing to make Linux a viable platform? Okay, very tricky questions, not easy questions.  So, when I refer to Windows and also Mac OS as typical platforms, I mean, more in spirit than  in good execution. So, Windows, clearly no one has the idea that you need to get your application  into Windows in order for it to be used by users. But everyone understands you have Windows and then  you get the application from the author of the application and run it on top. Even though Microsoft  wants to change this with the store, it seems to me like user acceptance is not that high and  people actually like to use the platform with side loading, with getting stuff from outside of  Microsoft. So, that's what I meant with this. It's... You're absolutely correct. Windows implementation  is not particularly great at this platform idea. The second question. What do you think is necessary  to make Linux? Yeah, how high should we go? Excellent question. So, I think there is obvious  stuff that every desktop has to have like font rendering, like codecs for multimedia, like  this display server printing. Yeah, everything that basically you will find as a dependency in  each and every desktop application. That is... And that's a vague answer, I know. So, you could  think about should GTK be part of this? Should Qt be part of this? I'm not 100% sure, because if  you look at real world Qt applications, oftentimes they are optimized for one specific release of Qt.  In this particular application, whereas in other application that you might care about is optimized  for a different version of Qt. So, I think really we should have a look at what are the components  that almost all applications require, and that should make up the desktop platform.  Any more questions?  So, maybe one question. Is it almost all? I think maybe it would be helpful if it's really just  almost, because I mean there will be when there's a certain adoption of this image app or something,  then there will be pressure for the distributions to align with this. And I think that's maybe a  good thing, because it's really messy and to clean up some pressure, maybe a little. What's your  thing, thinking about this? Yeah, that's a very good point. So, you're essentially saying as the  system starts being used, there will be a dynamic that will lead distributions to comply. It's a  bit of chicken and an egg problem, because if I put out an application today, I need to make sure  it works. Otherwise, everyone will be frustrated, no one will use it. So, as an application author,  today I can only use what is there in the distributions. And if the big mess is there,  the same library under different versions, I will have to bundle this privately with my  application, hence removing the need for distributions to align. So, it's really a chicken and egg situation.  Have you tried to talk to the distributions to align their library names? For example,  the library names are itself a back compatibility against older versions. And it's like the German  name is Stoffelskreis, Devil's Circle, where you have chase you around and it doesn't change.  Right. So, of course, the library naming system as it exists has some valid thoughts behind it.  There is a reason why it is like it is. But I mean, intuitively, the outcome of what we have  today seems wrong. If an application author cannot say this is version three of the application,  and I want it named version three everywhere, then somehow the system is wrong. And I haven't found  yet the right organization or person that could solve it. If anyone knows, I'm really interested  in who to talk to. I think the issue is when disruptions try to patch the software too hard,  when you look, for example, for end-of-patterns disruptions that patch the current very heavily  because they rely so much on older versions to fix them and so on, that the software is going to  modify it so much that it's not longer an upstream project. It's more like downstream  modification and MX. I think it's the idea of a disruption is great, but some disruptions do it  too much. Ubuntu tries to be more Ubuntu platform, not Linux distributions. It's like putting a knife  against other disruptions in the back of other disruptions. And about the library name thing,  that's the words where package conflict is for, where you as developer can get the right library  flex while you compiler and the right include files and so on from the library name. And the  developer has just to put this file in his project and the application can just use it and  doesn't have to know where everything is. I think it's the common base of every library.  So what you mentioned, distributions caring about their own distribution and not much else,  that is what I observe as of today. But really, I think it hurts everyone because if you see it as  from the perspective of someone who wants to do a cross platform application,  if this already 2% market share is subdivided like today, it's just not attractive. And I think  the result is that we don't see many great applications that we would see if distributions  would work together more. I think they hurt each other by this behavior. I think they want to hurt  because that's the systems the commercials do make things a little bit other. You could do it the same,  but don't you will lose money.  Well, your argument is some argument that is very common in the commercial world. So if we  are talking about commercial software vendors, I would totally buy this, but this is open source.  Right? This is supposed to be community. But I have friends when I tell that our community  in Cologne should agree how to handle beginners. You get a mess of options and they don't want to say,  as was said some time ago, we only have the idea of use it or when you don't use it, you get no help.  And in the last weeks, I had an idea to do a software label activity.  They had little ideas about that. But I think if you have a label by some  testing system, that would be the first step that you mentioned this test should run.  Put it in Python, for example. Right. So a test suite was I think it was Linux standard space,  LSB. I think there were some tests that if the tests were passing, you could be sure that this  application would run on all LSB compliant distributions. Unfortunately, and I don't know  why that is, but unfortunately, very few application developers actually developed  against the LSB standard. That's a bit puzzling to me. Maybe it was too cumbersome. Maybe they just  didn't care. I don't know. But I think you're right. We should have a specification. We should  have a testing suite so that if you pass the test, you are sure that it runs on all compliant  distributions. In the app image project, we have something that goes into this direction. We call  it app image hub where we run a set of tests against automated against every submitted application.  And if it passes that test, we are at least sure as of now it runs on Ubuntu 14.04, which is an  old distribution, right? But one could expand this, of course, in the sense that you just described.  The  responsible for the whole system since 25 years. And I think that is a wonder of Linux. And we  maybe we should talk more about such a wonder. That's the advice of an old man.  Thank you very much. I think we have one last question.  I just want to make one statement. He just talked about the wonder of  Linux Torwald. I think there's one big vulnerability here. He's just a man. He  is not a god. He will die somewhere. So I think we have we have we ally on this hierarchical  structure. And I think projects are vulnerable for something like this. And I mean,  someone will replace them. It's just it will change not change anything. But the symbol is  a great, a great strength. And we will lose it when we so much rely on one person. That's a danger,  I think. Very true. So I said it in the beginning, I don't have the perfect solution, unfortunately,  but I hope this talk makes you think a bit about this whole idea of a platform.  And how a platform is different from what we have today in terms of Linux distributions.  Again, feel free to step by the app image development room and we have flyers also here  in case you're interested. Thank you very much for coming.
2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_0_1151.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_1152_2807.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_2808_3155.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_3156_4091.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_4092_4151.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_4152_5171.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_5172_11903.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_11904_11951.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_11952_13955.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_13956_14039.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_14040_16127.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_16128_22751.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_22752_28475.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_28476_28895.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_28896_35999.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_36000_36275.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_36276_42875.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_42876_44075.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_44076_49283.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_49284_52079.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_52080_52175.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_52176_52955.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_52956_59159.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_59160_59687.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_59688_59747.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_59748_59891.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_59892_60059.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_60060_60107.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_60108_60239.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_60240_60419.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_60420_60539.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_60540_60623.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_60624_60803.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_60804_60851.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_60852_61103.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_61104_61163.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_61164_61595.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_61596_63527.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_63528_64451.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_64452_64511.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_64512_64703.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_64704_64763.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_64764_65999.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_66000_66083.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_66084_66227.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_66228_66563.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_66564_66803.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_66804_67811.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_67812_68075.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_68076_70595.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_70596_70931.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_70932_71075.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_71076_71183.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_71184_71699.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_71700_72431.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_72432_73007.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_73008_73451.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_73452_73559.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_73560_74471.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_74472_75503.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_75504_75623.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_75624_75755.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_75756_76055.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_76056_76115.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_76116_76283.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_76284_78575.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_78576_81251.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_81252_85667.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_85668_90527.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_90528_90827.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_90828_90935.png 2018_-_Let_s_talk_about_Desktop_Linux_Platform_Iss_hdRGVej3RyI_90936_90951.png