{"id":3009,"date":"2017-07-22T18:04:30","date_gmt":"2017-07-22T16:04:30","guid":{"rendered":"https:\/\/vizZzion.org\/blog\/?p=3009"},"modified":"2017-07-22T18:04:30","modified_gmt":"2017-07-22T16:04:30","slug":"software-from-the-source","status":"publish","type":"post","link":"https:\/\/vizZzion.org\/blog\/2017\/07\/software-from-the-source\/","title":{"rendered":"Software from the Source"},"content":{"rendered":"<p><em>In this article, I am outlining an idea for an improved process of deploying software to Linux systems. It combined advantages of traditional, package mangement based systems with containerized software through systems such as Flatpak, Snap, or AppImage. An improved process allows us to make software deployment more efficient across the whole Free software community, have better supported software on users systems and allow for better quality at the same time.<\/em><\/p>\n<p><figure id=\"attachment_2967\" aria-describedby=\"caption-attachment-2967\" style=\"width: 400px\" class=\"wp-caption alignright\"><a href=\"https:\/\/vizZzion.org\/blog\/wp-content\/uploads\/2017\/05\/IMG_20170506_163506.jpg\"><img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/vizZzion.org\/blog\/wp-content\/uploads\/2017\/05\/IMG_20170506_163506-400x300.jpg\" alt=\"Where we are going\" width=\"400\" height=\"300\" class=\"size-medium wp-image-2967\" srcset=\"https:\/\/vizZzion.org\/blog\/wp-content\/uploads\/2017\/05\/IMG_20170506_163506-400x300.jpg 400w, https:\/\/vizZzion.org\/blog\/wp-content\/uploads\/2017\/05\/IMG_20170506_163506-768x576.jpg 768w, https:\/\/vizZzion.org\/blog\/wp-content\/uploads\/2017\/05\/IMG_20170506_163506-1024x768.jpg 1024w, https:\/\/vizZzion.org\/blog\/wp-content\/uploads\/2017\/05\/IMG_20170506_163506-300x225.jpg 300w\" sizes=\"auto, (max-width: 400px) 100vw, 400px\" \/><\/a><figcaption id=\"caption-attachment-2967\" class=\"wp-caption-text\">Where we are going<\/figcaption><\/figure>In today&#8217;s Linux and Free software ecosystems, users usually receive all their software from one source. It usually means that software is well integrated with the system, can be tested in combination with each other and support comes from a single vendor. Compared to systems, in which single software packages are downloaded from their individual vendors and then installed manually, this has huge advantages, as it makes it easy to get updates for everything installed on your system with a single command. The base system and the software comes from the same hands and can be tested as a whole. This ease of upgrading is almost mind-boggling to people who are used to a Windows world, where you&#8217;d download 20 .exe installer files post-OS-install and have to update them individually, a hugely time-consuming process and at time outright dangerous as software easily gets out of date.<\/p>\n<p><figure id=\"attachment_3030\" aria-describedby=\"caption-attachment-3030\" style=\"width: 400px\" class=\"wp-caption alignright\"><a href=\"https:\/\/vizZzion.org\/blog\/wp-content\/uploads\/2017\/07\/sfts-0.png\"><img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/vizZzion.org\/blog\/wp-content\/uploads\/2017\/07\/sfts-0-400x367.png\" alt=\"Traditional model of software deployment\" width=\"400\" height=\"367\" class=\"size-medium wp-image-3030\" srcset=\"https:\/\/vizZzion.org\/blog\/wp-content\/uploads\/2017\/07\/sfts-0-400x367.png 400w, https:\/\/vizZzion.org\/blog\/wp-content\/uploads\/2017\/07\/sfts-0-300x275.png 300w, https:\/\/vizZzion.org\/blog\/wp-content\/uploads\/2017\/07\/sfts-0.png 444w\" sizes=\"auto, (max-width: 400px) 100vw, 400px\" \/><\/a><figcaption id=\"caption-attachment-3030\" class=\"wp-caption-text\">Traditional model of software deployment<\/figcaption><\/figure>There are also downsides to how we handle software deployment and installation currently, most of them revolve around update cycles. There is always a middle man who decides when and what to upgrade. This results in applications getting out of date, which is bad in reality and leads to a number of problems, as security and bug fixes are not making it to users in a timely fashion,<\/p>\n<ul>\n<li>It&#8217;s not unusual that software installed on a &#8220;supported&#8221; Linux system is outdated and not at all supported upstream anymore on the day it reaches the user. Worse, policies employed by distributions (or more generally, operating system vendors) will prevent some software packages from ever getting an update other than the most critical security fix within the whole support cycle.<\/li>\n<li>Software out in the wild with its problems isn&#8217;t supported upstream, bug reports reaching the upstream developers are often invalid and have been fixed in newer versions, or users are asked to test the latest version, which most of the time isn&#8217;t available for their OS &#8212; this makes it harder to address problems with the software and it&#8217;s frustrating for both, users and developers.<\/li>\n<li>Even if bugs are fixed in a timely fashion, the likelihood of users of traditional distributions actually receiving these updates without manually installing them is small, especially if users are not aware of it.<\/li>\n<li>Packaging software for a variety of different distributions is a huge waste of time. While this can be automated to some extent, it&#8217;s still less than ideal as work is duplicated, packaging bugs do happen simply because distribution packagers do not fully understand how a specific piece of software is built and best deployed (there&#8217;s a wide variety of software after all) and software stacks aren&#8217;t often well-aligned. (More on that later!)<\/li>\n<li>Support cycles differ, leading to two problems:\n<li>Distros need to guarantee support for software they didn&#8217;t produce<\/li>\n<li>Developers are not sure how much value there is in shipping a release and subsequent bugfix releases, since it takes usually at least months until many users upgrade their OS and receive the new version.<\/li>\n<li>Related to that, it can take a long time until a user confirms a bug fix.<\/li>\n<\/li>\n<li>There is only a small number of distributions who can package every single piece of useful software available. This essentially limits the user&#8217;s choice because his niche distro of choice may simply not have all needed software available.<\/li>\n<\/ul>\n<h2>The value of downstreams<\/h2>\n<p>One argument that has been made is that downstreams do important work, too. An example for that legal or licensing problems are often found during reviews at SUSE, one of KDE&#8217;s downstream partners. These are often fed back to KDE&#8217;s developers where the problems can be fixed and be made part of upstream. This doesn&#8217;t have to change at all, in fact, with a quicker deployment process, we&#8217;re actually able to ship these fixes quicker to users. Likewise, QA that currently happens downstream should actually shift more to upstream so fixes get integrated and deployed quicker.<\/p>\n<p>One big problem that we are currently facing is the variety of software stacks our downstreams use. An example that often bites us is that Linux distributions are combining applications with different versions of Qt. This is not only problematic on desktop form-factors, but has been a significant problem on mobile as well. Running an application against the same version of Qt that developers developed or tested it against means fewer bugs due to a smaller matrix of software stacks, resulting in less user-visible bugs.<\/p>\n<p>In short: <em>We&#8217;d be better off if work happening downstream happens more upstream, anyway.<\/em><\/p>\n<h2>Upstream as software distributor<\/h2>\n<p><figure id=\"attachment_3029\" aria-describedby=\"caption-attachment-3029\" style=\"width: 400px\" class=\"wp-caption alignright\"><a href=\"https:\/\/vizZzion.org\/blog\/wp-content\/uploads\/2017\/07\/sfts-1.png\"><img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/vizZzion.org\/blog\/wp-content\/uploads\/2017\/07\/sfts-1-400x167.png\" alt=\"Software directly from its source\" width=\"400\" height=\"167\" class=\"size-medium wp-image-3029\" srcset=\"https:\/\/vizZzion.org\/blog\/wp-content\/uploads\/2017\/07\/sfts-1-400x167.png 400w, https:\/\/vizZzion.org\/blog\/wp-content\/uploads\/2017\/07\/sfts-1-300x125.png 300w, https:\/\/vizZzion.org\/blog\/wp-content\/uploads\/2017\/07\/sfts-1.png 712w\" sizes=\"auto, (max-width: 400px) 100vw, 400px\" \/><\/a><figcaption id=\"caption-attachment-3029\" class=\"wp-caption-text\">Software directly from its source<\/figcaption><\/figure>So, what&#8217;s the idea? Let me explain what I have in mind. This is a bit of a radical idea, but given my above train of thoughts, it may well solve a whole range of problems that I&#8217;ve explained.<\/p>\n<p>Linux distributors supply a base system, but most of the UI layers, so the user-visible parts come from downstream KDE (or other vendors, but let&#8217;s assume KDE for now). The user gets to run a stable base that boots a system that supports all his hardware and gets updated according to the user&#8217;s flavor, but the apps and relevant libraries come from upstream KDE, are maintained, tested and deployed from there. For many of the applications, the middle-man is cut out.<\/p>\n<p>This leads to<\/p>\n<ul>\n<li>vastly reduced packaging efforts of distros as apps are only packaged once, not once per distro.<\/li>\n<li>much, much shorter delays until a bug fix reaches the user<\/li>\n<li>stacks that are carefully put together by those that know the apps&#8217; requirements best<\/li>\n<\/ul>\n<p>Granted, for a large part of the user&#8217;s system that stays relatively static, the current way of using packaged software works just fine. What I&#8217;m talking about are the bits and pieces that the users relies on for her productivity, the apps that are fast moving, where fixes are more critical to the user&#8217;s productivity, or simply where the user wants to stay more up to date.<\/p>\n<h2>Containerization allows systemic improvements<\/h2>\n<p>In practice, this can be done by making containerized applications more easily available to the users. Discover, Plasma&#8217;s software center, can allow the user to install software directly supplied by KDE and allow to keep it up to date. Users can pick where to get software from, but distros can make smart choices for users as well. Leaner distros could even entirely rely on KDE (or other upstreams) shipping applications and fully concentrate on the base system and advancing that part.<\/p>\n<p>Luckily, containerization technologies now allow us to rethink how we supply users with our software and provide opportunities to let native apps on Linux systems catch up with much shorter deployment cycles and less variety in the stack, resulting in higher quality software on our users&#8217; systems.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>In this article, I am outlining an idea for an improved process of deploying software to Linux systems. It combined advantages of traditional, package mangement based systems with containerized software through systems such as Flatpak, Snap, or AppImage. An improved process allows us to make software deployment more efficient across the whole Free software community,&hellip; <a class=\"more-link\" href=\"https:\/\/vizZzion.org\/blog\/2017\/07\/software-from-the-source\/\">Continue reading <span class=\"screen-reader-text\">Software from the Source<\/span> <span class=\"meta-nav\" aria-hidden=\"true\">&rarr;<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[22,29,25,28,32,35],"tags":[],"class_list":["post-3009","post","type-post","status-publish","format-standard","hentry","category-english","category-kde","category-linux","category-mobile","category-plasma","category-qt"],"_links":{"self":[{"href":"https:\/\/vizZzion.org\/blog\/wp-json\/wp\/v2\/posts\/3009","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/vizZzion.org\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/vizZzion.org\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/vizZzion.org\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/vizZzion.org\/blog\/wp-json\/wp\/v2\/comments?post=3009"}],"version-history":[{"count":18,"href":"https:\/\/vizZzion.org\/blog\/wp-json\/wp\/v2\/posts\/3009\/revisions"}],"predecessor-version":[{"id":3040,"href":"https:\/\/vizZzion.org\/blog\/wp-json\/wp\/v2\/posts\/3009\/revisions\/3040"}],"wp:attachment":[{"href":"https:\/\/vizZzion.org\/blog\/wp-json\/wp\/v2\/media?parent=3009"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/vizZzion.org\/blog\/wp-json\/wp\/v2\/categories?post=3009"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/vizZzion.org\/blog\/wp-json\/wp\/v2\/tags?post=3009"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}