| DistroWatch Weekly
|DistroWatch Weekly, Issue 663, 30 May 2016
Welcome to this year's 22nd issue of DistroWatch Weekly!
All operating systems that used a fixed release model (rather than a rolling release model) eventually reach the end of their supported lives and no longer receive security updates. When that happens (or ideally before it happens) the system should be upgraded to a supported version of the operating system. Sometimes that upgrade process happens smoothly and other times the user can run into all sorts of unexpected quirks. This week, in our Feature Story, we explore what it is like to perform live upgrades on some popular open source operating systems. In the News section we discuss changes coming to Ubuntu MATE and a debate over a new systemd feature. Plus we cover the Oracle vs Google API legal case and talk about updated wireless network drivers in DragonFlyBSD. In place of a Questions and Answers column this week we celebrate DistroWatch's 15th anniversary. Read on to learn some of the statistics behind DistroWatch and the features we are working on. Then we share the distributions released last week and provide a list of the torrents we are seeding. We made some updates to the website last week and we share those changes below. Plus we are pleased to welcome GeckoLinux as the newest distribution to be added to our database. We wish you all a fantastic week and happy reading!
Listen to the Podcast edition of this week's DistroWatch Weekly in OGG (38MB) and MP3 (52MB) formats
|Feature Story (by Jesse Smith)
Comparing live version upgrade methods
When I review a distribution I always begin by performing a fresh installation of the operating system. This gives the latest version of the project a chance to stand on its own without complications. However, many of us do not perform fresh installations on our operating systems each time we want to upgrade to the latest release. Some of us, in order to preserve settings or installed packages, prefer to upgrade our existing operating system without starting over from scratch. This week I decided to take five open source operating systems through an upgrade process from their penultimate release to their latest version.
During my series of experiments with Debian, Fedora, FreeBSD, openSUSE and Ubuntu, I focused on four important characteristics of the upgrade process:
With each distribution, I installed the previous release, added a few packages and changed some settings. Then I updated all the packages installed on the system before following the distribution's documentation to upgrade to the project's latest version. Following the upgrade, I checked to see if my settings and package selection had survived the upgrade process.
- Is the upgrade process well documented and is that documentation easy to find?
- Is performing this upgrade process something that should be easy for new users to understand and perform? For example, can it be done through a GUI or by executing one program on the command line?
- Were there any complications, extra steps or errors to be worked around?
- Did the upgrade process ultimately work?
I would like to acknowledge up front that this trial explores a risky approach to upgrading an operating system. Most modern systems provide two ways to upgrade an existing installation: off-line and live. The off-line approach involves downloading new installation media, taking the system off-line and running an upgrade process from the installation media. This is generally considered relatively safe, if a bit inconvenient since it means we need to take the computer off-line and download new installation media. This week I explored running live upgrades which means the system stays on-line and only downloads packages which are needed to perform the upgrade. This is a bit more risky, but means we don't need to stop working on the system while the upgrade happens and we do not need to burn a new installation DVD. I am the type of person who wants to keep the system up and running during an upgrade, I want to keep working while packages are being updated in the background and that was what I was testing this week.
* * * * *
Ubuntu 15.10 to 16.04
I decided to begin my trial with Ubuntu, starting with the Desktop edition of Ubuntu 15.10 and upgrading it to the latest long term support release, Ubuntu 16.04. The distribution's release notes include basic instructions for upgrading the distribution across major versions. The instructions point out that while we can upgrade interim versions of Ubuntu (those which are not long term support releases) at any time, people who wish to jump from Ubuntu 14.04 LTS to 16.04 LTS need to wait a few months. The jump from 14.04 to 16.04 needs to wait until the distribution pushes out an update release, specifically version 16.04.1. This means people making the jump between long term support releases wait a few extra months, but gain additional stability and bug fixes when they do finally perform the upgrade.
There are detailed upgrade instructions in the Ubuntu wiki which provide us with a variety of ways to upgrade our version of the operating system. The wiki covers upgrading through the graphical user interface and via the command line. For some reason the wiki also covers an extra, unsupported "Debian way of upgrading" though it hardly seems necessary.
In practise, most people probably will not need to read any instructions in order to upgrade Ubuntu. When we launch the distribution's graphical update manager, the application checks for package updates. If none are found, the update manager will check for new versions of the operating system and give us the option of upgrading to the new release. Clicking the button to start the upgrade shows us some release notes and, when we confirm we wish to continue, the update manager downloads the new release. We are shown progress information while the new packages are downloaded and installed and our configuration is updated.
The upgrade process on Ubuntu is pleasantly easy, requiring just a few mouse clicks and it uses the same update manager people are likely running every week to obtain security updates. In my trial, the whole upgrade process took about three hours and I was able to use the distribution while the update manager was working. All that was required on my part was a couple of mouse clicks and to reboot the computer when the update manager had finished its work.
Following the reboot, Ubuntu 16.04 ran smoothly, my settings were maintained and everything worked as expected. From a technical point of view, I would give Ubuntu five stars out of five for a quick and easy upgrade process. The wiki could be streamlined a little, removing unsupported upgrade methods, but otherwise everything went beautifully.
* * * * *
Fedora 22 to 23
The next distribution on my list was Fedora and I decided to upgrade Fedora 22 Workstation to version 23. (Fedora 24 will be released shortly after this article is published, but the upgrade process between versions does not appear to be changing for the upcoming release.) Fedora provides multiple methods for upgrading through the project's wiki. Available upgrade methods include the recommended approach that uses a DNF package manager plugin and there is an alternative upgrade method which uses plain DNF. Yet another method that is talked about can be used on Fedora's Atomic Host edition. I decided to stick with the recommended approach with DNF's system-upgrade plugin.
I found Fedora's documentation to be fairly straight forward. We do need to use the command line, but we can pretty much just copy and paste a few commands from the Fedora wiki into the GNOME desktop's virtual terminal in order to perform the upgrade. The process involves us updating existing packages, rebooting, installing the DNF system-upgrade plugin, running the plugin and rebooting the computer. When we reboot, the upgrade process automatically installs the new packages during the boot process, before we get to a login screen. The system will then reboot itself automatically and, if all went well, we will be running the latest version of Fedora.
During my trial, the upgrade process (from installing the system-upgrade plugin to running my new copy of Fedora 23) took approximately four hours. The upgrade completed successfully and, though it required some command line work and two reboots, went smoothly. In the end, I was running Fedora 23, the system was stable and my settings survived the upgrade process.
In a way, I feel Fedora is cheating a little as we need to take the system off-line and boot into a special upgrade process that prevents us from using the computer during the final stage of the upgrade. This makes the Fedora upgrade a hybrid of off-line and live methods. Still, it worked and the off-line portion of the upgrade required relatively little time.
* * * * *
Debian 7 to 8 (Wheezy to Jessie)
The next project on my list was Debian and it was my plan to upgrade from Debian 7 "Wheezy" to Debian 8 "Jessie". The documentation for upgrading Debian from one major version to another was a little harder to find. Debian was the only project in my trial where going to the project's documentation page and searching for "upgrade version" did not give me the information I wanted. With a little digging, I found the upgrade instructions in The Debian Administrator's Handbook. Once the documentation was found, some of it was, to my eyes, vague. For instance, one step tells us: "You might want to add suggested packages or deselect packages which are only recommended and known not to be useful. In any case, the front-end should come up with a scenario ending in a coherent and up-to-date Jessie system." Which seems like a roundabout way of saying we may wish to remove any packages we do not need.
What I took away from the documentation was that we need to manually edit our APT configuration files to point to the latest Stable release of Debian, then refresh the package database. Following that, we need to perform a minor upgrade, followed by a full upgrade. This puts Debian in the middle as far as complexity is concerned. Manually editing all of our APT repositories files correctly is probably something we should do after backing up those files, just to be safe. One line of the documentation detailing this practise concerned me, specifically the part which reads: "If the [repository configuration] file only contains references to Stable rather than explicit codenames [like Wheezy], the change isn't even required, since Stable always refers to the latest released version of Debian." This gave me pause as I hope most people do not take this to mean they should use "Stable" in place of the current version of Debian. Doing so may cause problems when the next version of Debian is released.
I performed a vanilla installation of Debian, taking all the default packages and settings. Following the installation, I found APT's repository files only included the update (security) repositories and I was unable to install additional software. I fixed this and then updated the system so I was running the latest packages in the Wheezy branch. Then I followed the documentation and tried to launch Synaptic. At this point I discovered the Synaptic graphical front-end for package management was not installed on my system. I decided to drop to the command line and use the apt command line utility to perform the instructions in the Administrator's Handbook, only to find apt was not installed either. The documentation should probably mention installing these items is required before suggesting we use them.
In the end, I installed apt, updated my repository information, performed a minor upgrade, rebooted and then performed the full upgrade. Each step in the process went smoothly and, in total, the upgrade required about three hours. While my new Debian 8 installation worked well, I noted there were several big changes to the default desktop environment, GNOME. Debian releases generally happen about once every two years, resulting in a relatively long life cycle and this means applications tend to change a lot between Stable versions of Debian.
On the technical side of things, Debian requires a bit more know-how and manual work than Ubuntu or Fedora. However, in the end, I was able to upgrade Debian while continuing to use the system. My big issue with Debian is not with the technical aspects of the upgrade process, but rather the documentation. Perhaps it is just me, but I found the documentation to be vague, relatively hard to find (compared to the other projects in this trial) and the Handbook refers to running software not available following a default installation.
* * * * *
openSUSE 13.2 to 42.1 Leap
openSUSE was the last of the Linux distributions on my list of projects to upgrade. The documentation on the project's website includes a section on upgrading across major versions, including openSUSE 13.2 to 42.1 "Leap". The openSUSE documentation was definitely the most complex of the projects included in this trial. Not only does openSUSE require people performing live upgrades use the command line, but the documentation suggests using long sed commands and switching init runlevels, something none of the other projects required. In all, there are about four pages of documentation to read through and we are walked through switching repositories, changing runlevels, removing and then re-adding community repositories.
The first problem I ran into was updating openSUSE 13.2 as the graphical update manager refused to work. I traced this problem back to PackageKit, which would lock the package database and refuse to terminate. With the PackageKit process manually terminated, I updated my openSUSE 13.2 system and rebooted. Then I updated my repository information, imported the new 42.1 Leap security keys, refreshed my repositories and began the upgrade. The zypper command line package manager immediately ran into package conflicts and entered an endless loop where it would ask (over and over) if I wanted to skip, retry or cancel the current operation. After dozens of these repeated prompts, I aborted the upgrade.
Earlier I mentioned that I did some customization to each operating system prior to performing an upgrade in order to see if my changes would survive a live upgrade. In an effort to be fair, I attempted an upgrade of openSUSE using only the default settings. My installation was performed from the recommended full DVD, no third-party or community repositories were added and no additional software or configuration changes were made to the system. The upgrade still failed immediately following the zypper upgrade command.
openSUSE stood out in my trial as the only operating system to fail to upgrade successfully. The distribution also stood out as having some of the most complex documentation.
* * * * *
FreeBSD 9 to 10
To round out my experiment, I decided to finish with a non-Linux operating system, specifically FreeBSD. The FreeBSD operating system has one significant advantage when it comes to performing upgrades, specifically the way in which the core of the operating system is separated from the software which runs on it. The core of the FreeBSD system is fairly small and tends to be conservative when it comes to introducing new features. Meanwhile, the third-party software packages (or ports) which run on FreeBSD are updated constantly, and separately. This means, during the supported life of a FreeBSD release, we mostly just update the packages which run on the operating system while the core remains static. When we upgrade the base system, we are upgrading a small core of software without the need to alter the programs which run on top of the core as they are already up to date.
The process for updating FreeBSD is covered in depth in the FreeBSD Handbook. One multi-page section deals specifically with upgrading the core operating system across major versions. There are several steps listed in the Handbook, but they are generally straight forward. One of the few problems I spotted was that we need to provide the command line update manager with the name of the release to which we are upgrading. The name, in this case, is usually the version number of the new release, followed by "-RELEASE". For example, upgrading from FreeBSD 9.3 to version 10.0 requires we run "freebsd-update -r 10.0-RELEASE upgrade".
In total, there are four commands we need to run in order to upgrade FreeBSD across versions, five commands if we include a final reboot to make sure everything is in place and working correctly. The commands are listed in the project's Handbook and I found the upgrade process happens just as it is documented. As we just need to upgrade the core of the operating system, the process is fairly quick, taking around ten minutes in my trial.
I ran into just one quirk during the FreeBSD upgrade process that gave me pause and made me think upgrading FreeBSD would not go smoothly with less experienced users. During the initial stage of the upgrade process, FreeBSD downloads a new version of the operating system and then compares the configuration files we currently have in place against the new versions of the configuration files. When any difference is discovered, we are asked to manually edit a mash-up of the two files, removing the unwanted pieces and saving the pieces of the configuration we wish to keep.
Performing this comparison of combined configuration files and deleting the unwanted parts was not a fun experience and I have performed upgrades of FreeBSD multiple times in the past. The process is messy, not particularly clear on why things are changing across versions and it is easy to miss symbols the FreeBSD upgrade process introduces which can cause errors when the system boots. To make matters worse, if we spot an error and want to go back to fix it, we need to abort the upgrade and start over. The upgrade process is not long, but it's not the sort of thing one wants to repeat due to hitting one wrong key.
In the end, my upgrade of FreeBSD was successful and did not take long. The process is well documented, but requires a good deal of manual work from the command line. It is one of those tasks that an experienced FreeBSD admin can probably zip through in five to ten minutes, but newcomers are going to see the multiple command line steps (plus the manual editing of configuration files) and probably decide it will be easier to perform a fresh installation.
Operating systems are, at the end of the day, tools for us to use. Different tools tend to be used to perform different tasks and are designed differently. I mention this because while the Ubuntu Desktop upgrade process involves a few mouse clicks and very little effort (making it quite appealing), Ubuntu's method would not suit someone running a Debian or FreeBSD server. Those operating systems are intended for different environments and so none of the projects mentioned in this trial lend themselves to direct "apples-to-apples" comparisons.
That being said, each project had very different approaches to achieving (approximately) the same task. As mentioned above, with Ubuntu the user doesn't even need documentation. The usual update manager will simply tell the user a new version is available and perform the upgrade with virtually no action required from the user, other than to confirm the upgrade should happen. This approach was welcome and it worked very well.
Fedora's approach was relatively easy and well documented. While some command line work was involved, I suspect anyone who can set up Fedora Workstation to begin with will probably find performing a live upgrade fairly straight forward. I think the same can be said for FreeBSD. The FreeBSD upgrade process is well documented and involves about the same number of steps as Fedora's process. Where FreeBSD really shines is the time required. While the fastest Linux upgrades took about three hours, FreeBSD only needs to upgrade the core of the operating system and this can be accomplished in about ten minutes.
For me, the Debian and openSUSE upgrades were a bit disappointing. Debian mostly due to the documentation, though the manual editing of all the APT .list files added a cumbersome step to the process. However, I will say Debian's upgrade process did work and went relatively quickly. The openSUSE upgrade was troublesome from start to finish with long, complex documentation, a misbehaving PackageKit process and, in the end, the upgrade failed.
|Miscellaneous News (by Jesse Smith)
Ubuntu MATE's progress, Debian users debate systemd change, Android's use of Java APIs legally fair use and updated wi-fi drivers in DragonFlyBSD
Martin Wimpress has posted a detailed report on the work going into Ubuntu MATE, particularly the upcoming 16.10 version that will be launched this October. Some of the key changes involve migrating from the GTK2 library to GTK3. "Some of the old libraries that MATE GTK2+ depends on are unmaintained, deprecated and being removed from many distributions. In order for MATE to remain relevant, the move the GTK3+ is essential. HiDPI, is going to be a thing. Really, it is. With MATE 1.14 built against GTK3+ we have initial HiDPI support working."
In order to explore the potential of snap packages, some of Ubuntu MATE's desktop components will packaged as snaps to see what works and what does not. Wimpress was quick to point out that traditional .deb packages will still be used and available. The new snaps will be provided alongside the classic .deb packages as a technology preview. Additional details can be found in the report.
* * * * *
The systemd project tends to stir up debate with each new feature it implements. One of the most recent changes to systemd (available in version 230), forces user processes to terminate when the user logs out. On some systems, such behaviour makes sense and effectively cleans up misbehaving processes when the user leaves. However, many administrators and developers rely on processes continuing to run to perform tests, backups or other tasks after they log off. Guus Sliepen summed up the concerns of the latter group quite nicely in a Debian bug report: It is now indeed the case that any background processes that were still running are killed automatically when the user logs out of a session, whether it was a desktop session, a VT session, or when you SSHed into a machine. Now you can no longer expect a long running background processes to continue after logging out. I believe this breaks the expectations of many users. For example, you can no longer start a screen or tmux session, log out, and expect to come back to it. For this reason, I think it is a bad decision on the part of the systemd maintainers to enable this feature by default, and it should rather be disabled by default in Debian." A similar discussion is taking place on a Fedora mailing list. The new default systemd behaviour can be disabled (either by distributions or system administrators) by editing the logind configuration file.
* * * * *
Though the legal case between Google and Oracle over the use of Java APIs was not directly linked to any open source distributions, the case was significant in that its ruling could have impacted virtually all open source distributions and languages. The trial, in which Oracle claimed the popular Android operating system infringed on Oracle's copyright of Java, focused on whether APIs (a blueprint for languages and systems) could be copyrighted.
The jury in the Oracle vs Google trial declared that while it may be possible to copyright APIs, Google's use of APIs in Android were protected under "fair use" and therefore Oracle's case was dismissed. This is good news, not only for fans of Android, but any open source developers who rely on APIs to create systems which are compatible with each other. Ars Technica offered details on the verdict: "Google's win somewhat softens the blow to software developers who previously thought programming language APIs were free to use. It's still the case that APIs can be protected by copyright under the law of at least one appeals court. However, the first high-profile attempt to control APIs with copyright law has now been stymied by a 'fair use' defence."
* * * * *
The DragonFlyBSD project recently performed a large update to its operating system's wireless drivers. Many wireless drivers have been updated and the interface for interacting with wireless networks has been simplified. A post on DragonFly Digest shares the details: "Matthew Dillon and Adrian Chadd have updated the wi-fi setup in DragonFly, incorporating Adrian's FreeBSD changes (and merging back some of Matt's from DragonFly). This affects the ath, rum, iwm, iwn, run, bwn, urtwn, wi, ral, iwi, ndis, and wpi drivers. The 'an' driver has been removed, too. I'm not going to even try to link to all the commits. If you're on DragonFly master and are using one of these devices, now is the time to update and try. Note that this removes the separate network interface that's specific to the device and creates only a wlanX device. Update: Matt reminded me that at least half the work came from Imre Vadasz; I missed it because I was only looking at the commit email names - mea culpa."
* * * * *
These and other news stories can be found on our Headlines page.
DistroWatch turns 15
We are pleased to announce that DistroWatch will reach a milestone this week. On Tuesday, May 31st, DistroWatch will be 15 years old. This website, which began as a small table reporting on the key features and package versions for just five Linux distributions, has grown a lot over the past decade and a half. In celebration, we would like to share some of the statistics behind this website.
Over the past 15 years there have been 663 issues of DistroWatch Weekly. These issues include 237 Questions & Answer columns and 34 Tips articles. At the time of writing we have announced 4,926 stable release announcements on our front page, along with an additional 2,855 development releases.
At present, we have a total of 815 open source operating systems in our database, 279 of those are presently active. There are 238 more projects on our waiting list. We also track 224 upstream open source projects. To date we have package listings on 4,075 different versions of open source operating systems.
The front page of DistroWatch receives around 130,000 visits per day, though the number tends to vary a bit depending on how many new releases are coming out that week. Busy days have seen the number of visits top 190,000.
The DistroWatch website has been hosted by two different operating systems over the years. We started on Debian, migrated to FreeBSD and are now back on Debian 7 "Wheezy". I guess you could say we like sticking with stable systems that are not going to surprise us. The website and databases take up approximately 24GB of disk space in total. Of that 24GB, screen shots account for 2.6GB and approximately 134MB consists of issues of DistroWatch Weekly.
Starting in 2004, DistroWatch began donating money to open source projects as a way of giving back to the community. Over the past 12 years this site has donated $45,275 USD to various open source projects and distributions. We quite literally could not do what we do without those projects.
Where do we go from here? Well, we have been adding new features and resources lately, trying to make the information we have more accessible. For instance, we have added a page that links people to hardware that works with Linux and the BSDs. This year we also added a glossary and a frequently asked questions page (both of which are still growing). Earlier this year we set up our Headlines page where we post distribution news and upstream package releases. DistroWatch now supports secure HTTPS connections and we have been optimizing our page load times. We are in the process of organizing our waiting list to make it easier for us to evaluate and cover new projects faster. We hope to have IPv6 support enabled later this year and we plan to make it easier to find distributions which offer popular features such as UEFI support. Searching for specific versions of packages will also be improving in the coming months.
There is a to-do list we keep (which currently has about a dozen reader suggestions on it) and we are always open to considering new ideas. So please e-mail and let us know what you think would benefit DistroWatch readers. If you'd like to lend a hand, please visit our contributing page and get involved.
We have a lot of fun exploring open source operating systems with you. The world of open source software is only getting bigger and more interesting and we plan to keep reporting on new developments for many years to come.
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.
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: 198
- Total data uploaded: 36.5TB
|Released Last Week
Tiny Core Linux 7.1
Tiny Core Linux 7.1, an updated release from the distribution project that develops a highly minimalist (but extensible) Linux-based operating system, has been released. This version brings an update to the BusyBox software utility and several minor enhancements and bug fixes: "Team Tiny Core is proud to announce the release of Core 7.1. Changelog for 7.1: BusyBox updated to 1.24.2; BusyBox syslogd buffer size increase to 512; tc-config - move syslog after hostname; mountables.sh - move the rebuildfstab call to mnttool; tc-config - put syslogd -L after -R. Also in conjunction with the above in Xprogs: mnttool - refresh automatically; mnttool - move rebuildfstab call here from mountables.sh." Here is the brief release announcement. The Tiny Core project provides installable ISO images for both the x86 and the x86_64 platforms.
Johnny Hughes has announced the release of CentOS 6.8, a community distribution which is built using the source code of Red Hat Enterprise Linux. The new release features a number of important changes, including depreciated drivers and packages as well as new features. "CentOS Linux 6.8 is derived from source code released by Red Hat, Inc. for Red Hat Enterprise Linux 6.8. All upstream variants have been placed into one combined repository to make it easier for end users. Workstation, server, and minimal installs can all be done from our combined repository. All of our testing is only done against this combined distribution. There are many fundamental changes in this release, compared with the past CentOS Linux 6 releases, and we highly recommend everyone study the upstream release notes as well as the upstream technical notes about the changes and how they might impact your installation." The release announcement and release notes detail all the changes in CentOS 6.8.
BackBox Linux 4.6
Raffaele Forte has announced the release of BackBox Linux 4.6, a new version of the project's Ubuntu-based distribution containing a large collection of security tools designed for penetration testing and forensic analysis: "The BackBox team is pleased to announce the last of 4.x minor releases - BackBox Linux 4.6. In this release we have fixed some minor bugs, configured Ruby 2.2 as the default Ruby, updated the base system and tools. What's new? Updated Linux kernel 4.2; updated Ruby 2.2; updated hacking tools - Beef, dirsearch, Metasploit, OpenVAS, SE Toolkit, Volatility, WPScan, wxHexEditor and YARA. System requirements: 32-bit or 64-bit processor; 512 MB of system memory (RAM); 10 GB of disk space for installation; fraphics card capable of 800×600 resolution; DVD-ROM drive or USB port (3 GB)." Here is the brief release announcement with upgrade instructions.
BackBox 4.6 -- The default desktop and application menu
(full image size: 1.0MB, resolution: 1280x1024 pixels)
Gentoo Linux 20160514
The Gentoo project has announced the release of Gentoo Linux 20160514, a comprehensive live DVD image featuring KDE Plasma as the default desktop. This release comes with UEFI support, ZFS on Linux and writable file system on the DVD: "Gentoo Linux is proud to announce the availability of a new live DVD, code-named 'Choice Edition', to celebrate the continued collaboration between Gentoo users and developers. The live DVD is available in two flavors - a hybrid x86/x86_64 version, and an x86_64 multilib version. The x86-amd64-32ul ISO image will work on 32-bit x86 or 64-bit x86_64. If CPU architecture is x86, then boot with the default 'gentoo' kernel. If the architectures is amd64, boot with the 'gentoo64' kernel. The amd64-multilib ISO image is for x86_64 CPUs only and will not boot on x86 CPUs. The live DVD features a superb list of packages: Linux kernel 4.5, X.Org Server 1.18.3, Plasma 5.6.2, Firefox 45.0.1, LibreOffice 5.1.2, GIMP 2.9.2, Blender 2.72b, Chromium 50.0.2661.75...." Read the release announcement for more information.
Soren Jacobsen has announced the release of NetBSD 7.0.1, the first bug-fix and security update of the project's 7.x release branch: "The NetBSD project is pleased to announce NetBSD 7.0.1, the first security/bug-fix update of the NetBSD 7.0 release branch. It represents a selected subset of fixes deemed important for security or stability reasons. If you are running an earlier release of NetBSD, we strongly suggest updating to 7.0.1." This brief release announcement was published on the NetBSD blog, with a detailed changelog provided in the release notes. Some of the technical changes include: "Add wip.pkgsrc.org to ssh_known_hosts; void 'vnconfig -l' infinite loop with netbsd-6 or older userland; avoid a crash when mounting an ados file system; avoid a panic when unplugging a mounted umass(4) device; don't leak garbage from the kernel stack on sleep(0) and equivalents; fix ARM1136 function selection...." This NetBSD release is available for 54 processor architectures.
* * * * *
Development, unannounced and minor bug-fix releases
|Upcoming Releases and Announcements
Summary of expected upcoming releases
How long should hardware be supported?
An article published by Linux Voice asks the question How long do you think hardware should get software updates? It is an interesting topic as some devices seem to become obsolete as soon as they are sold. Meanwhile, ask anyone who still runs a computer with a 32-bit x86 CPU and they will tell you the importance of supporting older hardware and designs.
Should hardware continue to be supported in the Linux kernel -- adding to the amount of code which must be maintained -- for as long as people continue to own the devices or should we consider older hardware unimportant after a certain amount of time?
This week we would like to know how long do you think older hardware architectures should continue to be supported by the kernel developers? Is five years long enough, a decade, for ever? Feel free to chime in with your reasons in the comments.
You can see the results of our previous poll on self-hosting network services here. All previous poll results can be found in our poll archives.
How long should hardware be supported?
|As long as the hardware is sold: ||50 (2%)|
| As long as the hardware is sold plus five years: ||388 (18%)|
| As long as the hardware is sold plus ten years: ||715 (34%)|
| As long as the hardware is sold plus twenty years: ||217 (10%)|
| As long as anyone continues to use the hardware: ||568 (27%)|
| For ever: ||180 (8%)|
Finding news, checksums and ZFS support
This past week we made some minor changes to the information pages for each distribution. If you visit any distribution's information page, like Debian's, the third section down is called Recent Related News and Releases. Traditionally, this section has contained links to recent release announcements for the project. We have expanded it so this section now also includes links to news stories.
Some people have mentioned that the list of release announcements in the aforementioned section did not make it clear that download links and checksums could be found in the linked release announcements. We have updated the description of the section to make this more clear.
Another change we have made it making it easier to find news stories about a specific distribution on our Headlines page. When viewing one news story about a distribution, under the story a link labeled More headlines from this project will appear. Clicking that link will bring up all recent news stories which mention the distribution. We hope this will make it easier to stay up to date with the distributions which interest you.
Finally, it has been pointed out that searching for distributions that include the ZFS module will return results which do not include operating systems that have ZFS built in. This means Linux distributions that feature a ZFS add-on module, like Antergos, would appear in searches for ZFS support, but FreeBSD would not as FreeBSD natively supports the file system. This has been fixed so operating systems with native ZFS support show up in searches for ZFS.
* * * * *
Distributions added to the database
GeckoLinux is a Linux spin based on the openSUSE distribution, with a focus on polish and out-of-the-box usability on the desktop. The distribution features many desktop editions which can be installed from live discs. Some patent encumbered open source software is included in GeckoLinux which is not available in the default installation of openSUSE.
GeckoLinux 421.160511.0 -- Running the Cinnamon desktop
(full image size: 1.1MB, resolution: 1280x1024 pixels)
* * * * *
DistroWatch database summary
* * * * *
This concludes this week's issue of DistroWatch Weekly. The next instalment will be published on Monday, 6 June 2016. To contact the authors please send e-mail to:
- Jesse Smith (feedback, questions and suggestions: distribution reviews/submissions, questions and answers, tips and tricks)
- Ladislav Bodnar (feedback, questions, donations, comments)
- Bruce Patterson (podcast)
If you've enjoyed this week's issue of DistroWatch Weekly, please consider sending us a tip.
(Tips this week: 0, value: US$0.00)
|Linux Foundation Training
|• Issue 776 (2018-08-13): NomadBSD 1.1, Maximum storage limits on Linux, openSUSE extends life for 42.3, updates to the Librem 5 phone interface|
|• Issue 775 (2018-08-06): Secure-K OS 18.5, Linux is about choice, Korora tests community spin, elementary OS hires developer, ReactOS boots on Btrfs|
|• Issue 774 (2018-07-30): Ubuntu MATE & Ubuntu Budgie 18.04, upgrading software from source, Lubuntu shifts focus, NetBSD changes support policy|
|• Issue 773 (2018-07-23): Peppermint OS 9, types of security used by different projects, Mint reacts to bugs in core packages, Slackware turns 25|
|• Issue 772 (2018-07-16): Hyperbola GNU/Linux-libre 0.2.4, UBports running desktop applications, OpenBSD auto-joins wi-fi networks, boot environments and zedenv|
|• Issue 771 (2018-07-09): Linux Lite 4.0, checking CPUs for bugs, configuring GRUB, Mint upgrade instructions, SUSE acquired by EQT|
|• Issue 770 (2018-07-02): Linux Mint 19, Solus polishes desktop experience, MintBox Mini 2, changes to Fedora's installer|
|• Issue 769 (2018-06-25): BunsenLabs Helium, counting Ubuntu users, UBports upgrading to 16.04, Fedora CoreOS, FreeBSD turns 25|
|• Issue 768 (2018-06-18): Devuan 2.0.0, using pkgsrc to manage software, the NOVA filesystem, OpenBSD handles successful cron output|
|• Issue 767 (2018-06-11): Android-x86 7.1-r1, transferring files over OpenSSH with pipes, LFS with Debian package management, Haiku ports LibreOffice|
|• Issue 766 (2018-06-04): openSUSE 15, overview of file system links, Manjaro updates Pamac, ReactOS builds itself, Bodhi closes forums|
|• Issue 765 (2018-05-28): Pop!_OS 18.04, gathering system information, Haiku unifying ARM builds, Solus resumes control of Budgie|
|• Issue 764 (2018-05-21): DragonFly BSD 5.2.0, Tails works on persistent packages, Ubuntu plans new features, finding services affected by an update|
|• Issue 763 (2018-05-14): Fedora 28, Debian compatibility coming to Chrome OS, malware found in some Snaps, Debian's many flavours|
|• Issue 762 (2018-05-07): TrueOS 18.03, live upgrading Raspbian, Mint plans future releases, HardenedBSD to switch back to OpenSSL|
|• Issue 761 (2018-04-30): Ubuntu 18.04, accessing ZFS snapshots, UBports to run on Librem 5 phones, Slackware makes PulseAudio optional|
|• Issue 760 (2018-04-23): Chakra 2017.10, using systemd to hide files, Netrunner's ARM edition, Debian 10 roadmap, Microsoft develops Linux-based OS|
|• Issue 759 (2018-04-16): Neptune 5.0, building containers with Red Hat, antiX introduces Sid edition, fixing filenames on the command line|
|• Issue 758 (2018-04-09): Sortix 1.0, openSUSE's Transactional Updates, Fedora phasing out Python 2, locating portable packages|
|• Issue 757 (2018-04-02): Gatter Linux 0.8, the UNIX and Linux System Administration Handbook, Red Hat turns 25, super long term support kernels|
|• Issue 756 (2018-03-26): NuTyX 10.0, Neptune supplies Debian users with Plasma 5.12, SolydXK on a Raspberry Pi, SysV init development|
|• Issue 755 (2018-03-19): Learning with ArchMerge and Linux Academy, Librem 5 runs Plasma Mobile, Cinnamon gets performance boost|
|• Issue 754 (2018-03-12): Reviewing Sabayon and Antergos, the growing Linux kernel, BSDs getting CPU bug fixes, Manjaro builds for ARM devices|
|• Issue 753 (2018-03-05): Enso OS 0.2, KDE Plasma 5.12 features, MX Linux prepares new features, interview with MidnightBSD's founder|
|• Issue 752 (2018-02-26): OviOS 2.31, performing off-line upgrades, elementary OS's new installer, UBports gets test devices, Redcore team improves security|
|• Issue 751 (2018-02-19): DietPi 6.1, testing KDE's Plasma Mobile, Nitrux packages AppImage in default install, Solus experiments with Wayland|
|• Issue 750 (2018-02-12): Solus 3, getting Deb packages upstream to Debian, NetBSD security update, elementary OS explores AppCentre changes|
|• Issue 749 (2018-02-05): Freespire 3 and Linspire 7.0, misunderstandings about Wayland, Xorg and Mir, Korora slows release schedule, Red Hat purchases CoreOS|
|• Issue 748 (2018-01-29): siduction 2018.1.0, SolydXK 32-bit editions, building an Ubuntu robot, desktop-friendly Debian options|
|• Issue 747 (2018-01-22): Ubuntu MATE 17.10, recovering open files, creating a new distribution, KDE focusing on Wayland features|
|• Issue 746 (2018-01-15): deepin 15.5, openSUSE's YaST improvements, new Ubuntu 17.10 media, details on Spectre and Meltdown bugs|
|• Issue 745 (2018-01-08): GhostBSD 11.1, Linspire and Freespire return, wide-spread CPU bugs patched, adding AppImage launchers to the application menu|
|• Issue 744 (2018-01-01): MX Linux 17, Ubuntu pulls media over BIOS bug, PureOS gets endorsed by the FSF, openSUSE plays with kernel boot splash screens|
|• Issue 743 (2017-12-18): Daphile 17.09, tools for rescuing files, Fedora Modular Server delayed, Sparky adds ARM support, Slax to better support wireless networking|
|• Issue 742 (2017-12-11): heads 0.3.1, improvements coming to Tails, Void tutorials, Ubuntu phasing out Python 2, manipulating images from the command line|
|• Issue 741 (2017-12-04): Pop!_OS 17.10, openSUSE Tumbleweed snapshots, installing Q4OS on a Windows partition, using the at command|
|• Issue 740 (2017-11-27): Artix Linux, Unity spin of Ubuntu, Nitrux swaps Snaps for AppImage, getting better battery life on Linux|
|• Issue 739 (2017-11-20): Fedora 27, cross-distro software ports, Ubuntu on Samsung phones, Red Hat supports ARM, Parabola continues 32-bit support|
|• Issue 738 (2017-11-13): SparkyLinux 5.1, rumours about spyware, Slax considers init software, Arch drops 32-bit packages, overview of LineageOS|
|• Issue 737 (2017-11-06): BeeFree OS 18.1.2, quick tips to fix common problems, Slax returning, Solus plans MATE and software management improvements|
|• Issue 736 (2017-10-30): Ubuntu 17.10, "what if" security questions, Linux Mint to support Flatpak, NetBSD kernel memory protection|
|• Issue 735 (2017-10-23): ArchLabs Minimo, building software with Ravenports, WPA security patch, Parabola creates OpenRC spin|
|• Issue 734 (2017-10-16): Star 1.0.1, running the Linux-libre kernel, Ubuntu MATE experiments with snaps, Debian releases new install media, Purism reaches funding goal|
|• Issue 733 (2017-10-09): KaOS 2017.09, 32-bit prematurely obsoleted, Qubes security features, IPFire updates Apache|
|• Issue 732 (2017-10-02): ClonOS, reducing Snap package size, Ubuntu dropping 32-bit Desktop, partitioning disks for ZFS|
|• Issue 731 (2017-09-25): BackSlash Linux Olaf, W3C adding DRM to web standards, Wayland support arrives in Mir, Debian experimenting with AppArmor|
|• Issue 730 (2017-09-18): Mageia 6, running a completely free OS, HAMMER2 file system in DragonFly BSD's installer, Manjaro to ship pre-installed on laptops|
|• Issue 729 (2017-09-11): Parabola GNU/Linux-libre, running Plex Media Server on a Raspberry Pi, Tails feature roadmap, a cross-platform ports build system|
|• Issue 728 (2017-09-04): Nitrux 1.0.2, SUSE creates new community repository, remote desktop tools for GNOME on Wayland, using Void source packages|
|• Issue 727 (2017-08-28): Cucumber Linux 1.0, using Flatpak vs Snap, GNOME previews Settings panel, SUSE reaffirms commitment to Btrfs|
|• Issue 726 (2017-08-21): Redcore Linux 1706, Solus adds Snap support, KaOS getting hardened kernel, rolling releases and BSD|
|• Issue 725 (2017-08-14): openSUSE 42.3, Debian considers Flatpak for backports, changes coming to Ubuntu 17.10, the state of gaming on Linux|
|• Full list of all issues|
|Random Distribution |
Basilisk (formerly known as RPM Live CD) was a Linux live CD based on Fedora Core. The CD image was a workstation with KDE, GNOME, Office, Internet/network and other applications, as well as servers and services to integrate into a LAN workgroup or domain.