DistroWatch Weekly, Issue 668, 4 July 2016

Feature Story (by Christine Hall)

Fedora 24 - It isn't for everybody, but then, it doesn't try to be



On June 23, after installing Fedora for my first ever look at the distro for this review of Fedora 24, I pinged a friend who writes about Linux seeking help for a pesky configuration problem. I was trying to get GNOME to quit demanding a password every time I walked away from the computer for five minutes or so, which I thought should be easy, but wasn't. After finding sort of a solution for the problem, I sent him another email.



"I would expect Fedora to have an easy way to deal with this," I wrote. "Actually, I find very few configuration tools in this installation of Fedora, which surprises me. This must be what you get when you have server people supervising the development of a desktop OS."



"Exactly," he pinged back with record speed. "I've never cared much for it myself. Never really found it that compelling. Arch/etc I get; Ubuntu/Mint, I also see the appeal. But Fedora and SuSE always lost me. Nothing negative about them, rather, I fail to see the appeal unless you're someone who uses these at work."



My friend had hit the nail on the head. Fedora isn't a distro for people who need to get work done, unless that work happens to involve IT. Nor is it necessarily for gamers who need a highly configurable operating system optimized for resource intensive games. Fedora 24, and I presume previous versions of the distro, is first and foremost for developers and admin types who spend their days keeping RHEL and CentOS servers up and running. It's a system by developers for developers, a conclusion you may argue with if you wish.



This isn't its reputation, however -- at least, not completely. In the forums, users write that they like it because it's a cutting edge distro with the most up to date software and with a commitment to software freedom, certainly not a distro for newbies, but great for those who want to be on the cutting edge.





Fedora 24 -- Running GNOME Shell 3.20

(full image size: 1.1MB, resolution: 1600x900 pixels)



Installation



As is my habit when looking at a new distro, after downloading via torrent I ran the live version, mainly to make sure I had a Wi-Fi connection and Internet access before attempting an install to the hard drive. Wireless connected perfectly and I verified that Internet was working by briefly opening Firefox. After closing the browser, however, I ran across one little glitch: GNOME's "Activities" button quit responding. GNOME wasn't frozen and everything else worked fine. I figured this was a live mode problem, probably connected with my hardware. It did necessitate a reboot in order to reach the installer's launcher.



Upon reboot I clicked "Install to Hard Drive" and sat back for my first look at Fedora's installer, Anaconda, in action. Fedora offers a detailed installation guide, but I chose to fly by the seat of my pants to see if the process was intuitive. I was installing onto a laptop I reserve for testing, an older System 76 Pangolin with a quad core 2.53 GHz processor and 4 GB RAM, Nothing special, but a machine that has Linux in its DNA.



The installation was reasonably straightforward and easy to understand, although I thought the partitioning tool could be a little more clear. I was able to get the job done and install Fedora alongside a small Windows partition I use once a year without having to seek online help.





Fedora 24 -- GNOME's Getting Started screen

(full image size: 645kB, resolution: 1600x900 pixels)



Running Fedora 24



Like most modern distros, Fedora doesn't install with a boatload of programs. GNOME 3.20 is the default desktop, so GNOME apps and applets are installed, including Evolution as the default email client. In addition, there's version 5.1 of LibreOffice and Firefox 47.0. Other than that, you're on your own.



Since you're reading this on DistroWatch, you probably already know that Fedora uses RPMs. After checking Fedora's documentation for the proper command and syntax, I installed GIMP from a terminal with the command " su -c 'dnf install gimp' " . After being prompted for a password, Dandified YUM (Fedora's current package manager) compiled a list of the required dependencies and asked "Is this OK [y/N]"? I typed "y", hit "enter" and waited for the download and installation. In other words, just the same as with apt or any other command line package manager.



After that, I installed the Bluefish text editor that I'm using to write this review. This time I used Software, Fedora's default graphical software installer, which I found to be intuitive and not much different from the installation tools included with other distros.



The next thing was to add RPM Fusion as a repository, since the Fedora repository doesn't contain any non-free software. This is especially necessary if you want to watch videos or listen to music, as you'll need to download and install the codecs before you can listen to your MP3s.





Fedora 24 -- Listening to musing on Rhythmbox

(full image size: 1.0MB, resolution: 1600x900 pixels)



Fedora's Breakable Linux



Unfortunately, I found it easier than expected to break things in Fedora.



On the day after I'd successfully installed programs and added RPM Fusion from the command line, both actions requiring use of the sudo command, I tried to run a command requiring sudo, only to be told "christine is not in the sudoers file." Evidently, something I'd done the day before -- I have absolutely no idea what -- had inadvertently removed me from the sudoers list.



I completed the task at hand by logging in as root, but that's not a long term solution for a variety of reasons. And because I'd never lost sudo privileges on any distro -- I didn't even know it was possible -- I had to go looking to figure out how to fix the problem. As expected, I'd need to edit a file -- "sudoers" -- so I logged in again as root and opened the file in a text editor. Alas, the file opened in "read only" mode with a message that editing sudoers required the use the visudo command. This required more searching to learn how visudo worked.



Eventually the file was edited and the use of sudo was restored, but…grrr.



Yeah, I get it. If I were a real Linux user -- meaning a sysadmin or some such -- I would have had no problem with such a simple task because I'd most likely spend time each day removing sudo rights from users whom I didn't want to try to do anything requiring root privileges. However, that doesn't begin to explain why it was so easy to accidentally remove myself from the elite group of sudoers to begin with.



I guess I should be happy I learned something.





Fedora 24 -- Updating Fedora 24 from the command line.

(full image size: 1.1MB, resolution: 1600x900 pixels)



Conclusion



If you spend your time getting your hands dirty working in IT, I'm sure you'll find much to like about Fedora 24. Also, anyone who would like to learn all of the ins and outs of running a Linux system could definitely benefit from spending some time with Fedora, as the distro will force you to learn to do many things that are made easy in some other distros.



In some ways, it's like the Linux version of a Ferrari. It's great if you have the skills, time and tools to tinker with it, but if your job isn't to keep Red Hat or CentOS servers operating smoothly and you don't particularly enjoy spending hours completing simple tasks that should be handled in a few seconds with a couple of clicks, then you might want to consider another distro.





Miscellaneous News (by Jesse Smith)

Opinion (by Jesse Smith)

Flatpak, Snap and AppImage



Over the past few months we have been hearing a lot about two new package formats, Flatpak and Snap (aka Snappy, aka snaps). These two new methods of packaging software have been getting a lot of attention, especially in the Ubuntu and Fedora communities. Both package formats attempt to make packaging easier for developers as all of an application's dependencies can be bundled in the one portable package. Both Flatpak and Snap also claim to be (in theory at least) universal. The idea here is that any distribution which provides the Snap framework will be able to run any Snap package. Likewise, any Linux distribution with the Flatpak software installed should be able to run any Flatpak package. This should make it possible for developers to make one package for their software which will run on any distribution.



Here is what the Ubuntu website has to say about their Snap technology: Developers from multiple Linux distributions and companies today announced collaboration on the Snap universal Linux package format, enabling a single binary package to work perfectly and securely on any Linux desktop, server, cloud or device. This community is working at snapcraft.io to provide a single publication mechanism for any software in any Linux environment. Please note that to separate the Snap technology and framework from the associated command line tool and the package format, I will use the following convention: The Snap technology in general will be referred to using proper case ("Snap"), the command like utility will be referenced as "snap" (with italics) and packages created for Snap will be called "snaps" or "a snap package".



Flatpak's website offers the following description of their competing technology: Distributing applications on Linux is a pain: different distributions in multiple versions, each with their own versions of libraries and packaging formats. Flatpak is here to change all that. It allows the same app to be installed on different Linux distributions, including different versions. And it has been designed from the ground up with security in mind, so that apps are isolated from each other and from the host system. Where things get complicated is figuring out which distributions support which "universal" package format. Snap is backed (almost exclusively) by Ubuntu and its community editions. Despite the Ubuntu's website claiming "multiple" Linux distributions are collaborating on supporting Snap, so far it appears as though Ubuntu and its community flavours are the only projects that offer built-in support for Snap. Meanwhile Flatpak has not enjoyed a widespread welcome either with Fedora being the only distribution to claim support for Flatpak packages at the time of writing.



I thought it would be interesting to test drive both Flatpak and Snap on Ubuntu and Fedora to see how the experiences would compare. Both Flatpak and Snap packages have been created for the latest version of LibreOffice and I wanted to see how each package format performed.



But wait! There are other package formats which claim to run universally across Linux distributions, bundling any dependencies as needed. Perhaps the most popular is AppImage, a format which has been around for years, under one name or another. AppImage, unlike Flatpak and Snap, claims to need no framework. AppImage needs no other packages or technologies to be installed. The project's website claims: Download an application, make it executable, and run! No need to install. No system libraries or system preferences are altered. Can also run in a sandbox like Firejail . Distribute your desktop Linux application in the AppImage format and win users running all common Linux distributions. Package once and run everywhere. Reach users on all major desktop distributions. This sounds a bit less complicated while offering similar sandboxing technology to what Snap and Flatpak offer, so I decided to also try running a complex application bundled as an AppImage on both Fedora and Ubuntu to see how this unsung third-party package format would compare. I could not find any AppImage bundle of LibreOffice, so I grabbed a copy of the Krita drawing application to test on both distributions. * * * * * Ubuntu 16.04 LTS



I started my experiment on Ubuntu's latest release, Ubuntu 16.04. Ubuntu 16.04 has built-in support for Snap. I found no mention of Flatpak or, as it used to be called, xdg-app. I began my trial by grabbing a development snapshot of LibreOffice. There does not appear to be any official snap for LibreOffice, leading me to follow the steps provided by the Sky From Me blog to get a third-party snap package of the productivity suite.



The LibreOffice package must be installed from the command line and was 286MB in size. The snap command line tool (which must be run with root privileges) also had to pull in 64MB of dependencies to support the LibreOffice package. I noticed that once installed, no launcher for my new copy of LibreOffice was added to Unity's dash. This means the user must install and run snaps from the command line. Attempting to run the LibreOffice snap caused my terminal session to simply hang and the productivity suite failed to start. Removing the snap after my trail could be accomplished through the snap command line utility.



As my experiment with Snap had failed, I turned to Flatpak. Ubuntu does not ship with Flatpak included by default. Searching through the distribution's repositories, I could find no mention of either xdg-app or Flatpak, preventing me from attempting to install the LibreOffice Flatpak package.



Next, I downloaded the official AppImage package from the Krita website. The Krita bundle is 76MB in size. As the AppImage documentation says, all that is required to launch an AppImage program is marking the downloaded file as executable and running it. This can be accomplished though any modern file manager by right-clicking the bundle to change its properties and then left-clicking the file to run it. The Krita application ran smoothly and with no issues on Ubuntu 16.04. When I was done with the application, removing it from the system was as simple as deleting the AppImage package I had downloaded.



It may be worth noting AppImage does not require a package to be installed in the traditional sense, merely downloaded and marked as executable. This means the user does not need to have administrator (or sudo) access to work with AppImages. Both Flatpak and Snap require admin access to install or remove applications.





Ubuntu 16.04 -- Running the Krita AppImage bundle

(full image size: 202kB, resolution: 1280x1024 pixels)

* * * * * Fedora 24



While running Ubuntu, I had failed to get two of the three package formats to run and so I turned to Fedora with hope of better results. The Fedora 24 release announcement mentioned support for Flatpak and I started there.



I found that Fedora 24 Workstation does not, in fact, include Flatpak in the default install, but the Flatpak software is available in Fedora's official repositories. This is a fairly small download, I did not catch the exact size, but installing Flatpak took just a minute of my time.



There is an official LibreOffice Flatpak package, available through the LibreOffice website. Prior to installing the package, we first need to perform several steps from the command line as the admin user. First, we need to install the GNOME security keys. Then we enable the GNOME repositories and download LibreOffice's Flatpak dependencies. This download is about 171MB. Then we can download and install the LibreOffice Flatpak, which is another 156MB download. Once these steps were completed successfully, I tried to run the new LibreOffice Flatpak, which must be done from the command line. An error message appeared and told me LibreOffice was not installed.



I went through the process again and found myself in an odd loop where, whenever I attempted to install the new LibreOffice package, I would encounter the error "LibreOffice branch fresh already installed". Attempting to run the application would report the contradicting error "not installed". In the end, despite downloading over 300MB of packages and dependencies, the LibreOffice Flatpak failed to run.



Testing Snap on Fedora was quite a short experience. Fedora 24 does not include support for Snap in the default installation. Snap is not available through the official repositories and it is not available through the RPMFusion community repositories either. This effectively blocks Fedora users from installing snaps.



Once again, I downloaded the 76MB Krita AppImage on Fedora. I was able to make the application executable with a few mouse clicks and run the application with another click. Krita performed smoothly on Fedora and, when I was done with the application, I removed it from the system by deleting the AppImage file. No elevated access was required. * * * * * Conclusions



Admittedly, both Snap and Flatpak are in relatively early stages of development. It's not fair to expect them to work perfectly or to have nice, polished graphical user interfaces. I was certainly willing to overlook a few rough edges. However, what I experienced this week with Snap and Flatpak was a disaster. A large part of this, I think, comes from (as Fedora QA Lead, Adam Williamson, pointed out) the fact no one is working together. Ubuntu wants to push Snap, but no one else seems interested. Fedora is backing Flatpak, but no one else seems to be on board with it yet. Which means, for now at least, neither of these two package formats is universal.



What made my experience more bitter this week was that not only were Flatpak and Snap not universal across distributions, the packages I tried did not even work on the distributions which claim to support them. Snap, on Ubuntu, looked promising. The snap command line utility feels a lot like apt-get and automatically handles dependencies. It might not work yet, but the concept seems viable once the edges get polished. Unfortunately, it looks as though Snap's backend (the server side of things) is proprietary and unlikely to be accepted in the larger Linux community.



Flatpak though is broken by design. Like Snap, Flatpak has a rough command line interface, but it also requires far too many steps to get it working. These steps involve installing Flatpak, then typing out long, complex commands which will immediately turn away most users. To even try to run a Flatpak application the user must import signing keys, manually install dependencies and then hope that is enough to get the application working. Further, Flatpak relies on systemd and only works in desktop sessions, preventing the package format from working on servers and in embedded environments. This makes Flatpak a non-starter in the race for universal packages.



The most frustrating thing in this situation is we already have a cross-platform package format which works. AppImage has been around for years, automatically handles dependencies, truly works across multiple distributions and does not require root/sudo access to install. AppImage requires no additional framework or libraries to be installed, there is no new package manager to learn and AppImage programs can be launched through any distribution's file manager.



In the blog post from Adam Williamson I linked to above, Williamson questions whether AppImage is secure enough. Both Flatpak and Snap have sandbox capabilities which isolate programs from the rest of the system, an important feature to have when installing software from third-parties. And Williamson raises a valid point, sandboxing is a critical feature these days and AppImage does not have sandboxing built-in. However, AppImage programs do work inside Firejail sandboxes. This secures AppImage programs with virtually no extra effort from the user, so long as they have Firejail installed. Recent versions of Firejail even guard against X display server attacks, like key logging, which makes AppImage programs protected by Firejail more secure than Snap and Flatpak packages running on X.



For now, it looks like two of the biggest names in the Linux community are going to compete with separate, incomplete "universal" package formats which will have limited cross-distro support. Meanwhile we have a working alternative that is easier to use, works across platforms and offers better security. Hopefully more distributions will turn their focus on supporting AppImage, ideally running these bundles in a sandbox, to provide a better user experience.





Torrent Corner

Weekly Torrents



Bittorrent is a great way to transfer large files, particularly open source operating system images, from one place to another. Most bittorrent clients recover from dropped connections automatically, check the integrity of files and can re-download corrupted bits of data without starting a download over from scratch. These characteristics make bittorrent well suited for distributing open source operating systems, particularly to regions where Internet connections are slow or unstable.



Many Linux and BSD projects offer bittorrent as a download option, partly for the reasons listed above and partly because bittorrent's peer-to-peer nature takes some of the strain off the project's servers. However, some projects do not offer bittorrent as a download option. There can be several reasons for excluding bittorrent as an option. Some projects do not have enough time or volunteers, some may be restricted by their web host provider's terms of service. Whatever the reason, the lack of a bittorrent option puts more strain on a distribution's bandwidth and may prevent some people from downloading their preferred open source operating system.



With this in mind, DistroWatch plans to give back to the open source community by hosting and seeding bittorrent files. For now, we are hosting a small number of distribution torrents, listed below. The list of torrents offered will be updated each week and we invite readers to e-mail us with suggestions as to which distributions we should be hosting. When you message us, please place the word "Torrent" in the subject line, make sure to include a link to the ISO file you want us to seed. To help us maintain and grow this free service, please consider making a donation.



The table below provides a list of torrents we currently host. If you do not currently have a bittorrent client capable of handling the linked files, we suggest installing either the Transmission or KTorrent bittorrent clients.



Operating System Torrent MD5 checksum antiX 16 x86 antiX-16_386-full.iso ce143475628eb37b9cec84181fbed96b Linux Mint 18 "Cinnamon" linuxmint-18-cinnamon-64bit.iso 8e9dba7e5ae538e06a13c7135bf457f2 KDE neon 20160630 neon-useredition-20160630-1018-amd64.iso 24dd0cc1b9b13d8e489a9feaaac691a6 Slackware Linux 14.2 slackware64-14.2-iso/slackware64-14.2-install-dvd.iso.txt 1d26ab5a36566655d1348657a784acb2



Archives of our previously seeded torrents may be found here. All torrents we make available here are also listed on the very useful Linux Tracker website. Thanks to Linux Tracker we are able to share the following torrent statistics.



Torrent Corner statistics:

Total torrents seeded: 211

Total data uploaded: 38.7TB

Released Last Week

Upcoming Releases and Announcements

Opinion Poll

Favourite command line shell



Most of us who run Linux, when we use the command line, we run Bash, a popular terminal shell. Bash is usually the default shell on most Linux distributions, but there are plenty of other shells with various interesting features and scripting syntax. In the BSD communities csh and tcsh are more commonly used. In addition, there are plenty of other shells, such as Fish and zsh, each which offers its own unique style.



This week we would like to know which command line shell is your favourite? Do you stick with the default shell your operating system provides or do you like to customize your command line environment?



You can see the results of our previous poll on universal package formats here. All previous poll results can be found in our poll archives. Favourite command line shell



bash: 1220 (75%) csh: 24 (1%) dash: 19 (1%) fish: 69 (4%) ksh: 35 (2%) tcsh: 49 (3%) zsh: 156 (10%) other: 46 (3%)

DistroWatch.com News