 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!
Content:
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:
- 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?
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.
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.
Conclusions
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 Statistics |
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.
|
| 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.
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.
CentOS 6.8
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.
NetBSD 7.0.1
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
|
| Opinion Poll |
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%) |
|
|
| DistroWatch.com News |
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
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)
|
|
| Tip Jar |
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) |
|
|
|
 bc1qtede6f7adcce4kjpgx0e5j68wwgtdxrek2qvc4  lnurl1dp68gurn8ghj7ampd3kx2ar0veekzar0wd5xjtnrdakj7tnhv4kxctttdehhwm30d3h82unvwqhhxarpw3jkc7tzw4ex6cfexyfua2nr  86fA3qPTeQtNb2k1vLwEQaAp3XxkvvvXt69gSG5LGunXXikK9koPWZaRQgfFPBPWhMgXjPjccy9LA9xRFchPWQAnPvxh5Le paypal.me/distrowatchweekly • patreon.com/distrowatch |
|
| Linux Foundation Training |
|
|
| TUXEDO |
TUXEDO Computers - Linux Hardware in a tailor made suite
Choose from a wide range of laptops and PCs in various sizes and shapes at TUXEDOComputers.com. Every machine comes pre-installed and ready-to-run with Linux. Full 24 months of warranty and lifetime support included!
Learn more about our full service package and all benefits from buying at TUXEDO.
|
| Archives |
| • Issue 1046 (2023-11-20): Slackel 7.7 "Openbox", restricting CPU usage, Haiku improves font handling and software centre performance, Canonical launches MicroCloud |
| • Issue 1045 (2023-11-13): Fedora 39, how to trust software packages, ReactOS booting with UEFI, elementary OS plans to default to Wayland, Mir gaining ability to split work across video cards |
| • Issue 1044 (2023-11-06): Porteus 5.01, disabling IPv6, applications unique to a Linux distro, Linux merges bcachefs, OpenELA makes source packages available |
| • Issue 1043 (2023-10-30): Murena Two with privacy switches, where old files go when packages are updated, UBports on Volla phones, Mint testing Cinnamon on Wayland, Peppermint releases ARM build |
| • Issue 1042 (2023-10-23): Ubuntu Cinnamon compared with Linux Mint, extending battery life on Linux, Debian resumes /usr merge, Canonical publishes fixed install media |
| • Issue 1041 (2023-10-16): FydeOS 17.0, Dr.Parted 23.09, changing UIDs, Fedora partners with Slimbook, GNOME phasing out X11 sessions, Ubuntu revokes 23.10 install media |
| • Issue 1040 (2023-10-09): CROWZ 5.0, changing the location of default directories, Linux Mint updates its Edge edition, Murena crowdfunding new privacy phone, Debian publishes new install media |
| • Issue 1039 (2023-10-02): Zenwalk Current, finding the duration of media files, Peppermint OS tries out new edition, COSMIC gains new features, Canonical reports on security incident in Snap store |
| • Issue 1038 (2023-09-25): Mageia 9, trouble-shooting launchers, running desktop Linux in the cloud, New documentation for Nix, Linux phasing out ReiserFS, GNU celebrates 40 years |
| • Issue 1037 (2023-09-18): Bodhi Linux 7.0.0, finding specific distros and unified package managemnt, Zevenet replaced by two new forks, openSUSE introduces Slowroll branch, Fedora considering dropping Plasma X11 session |
| • Issue 1036 (2023-09-11): SDesk 2023.08.12, hiding command line passwords, openSUSE shares contributor survery results, Ubuntu plans seamless disk encryption, GNOME 45 to break extension compatibility |
| • Issue 1035 (2023-09-04): Debian GNU/Hurd 2023, PCLinuxOS 2023.07, do home users need a firewall, AlmaLinux introduces new repositories, Rocky Linux commits to RHEL compatibility, NetBSD machine runs unattended for nine years, Armbian runs wallpaper contest |
| • Issue 1034 (2023-08-28): Void 20230628, types of memory usage, FreeBSD receives port of Linux NVIDIA driver, Fedora plans improved theme handling for Qt applications, Canonical's plans for Ubuntu |
| • Issue 1033 (2023-08-21): MiniOS 20230606, system user accounts, how Red Hat clones are moving forward, Haiku improves WINE performance, Debian turns 30 |
| • Issue 1032 (2023-08-14): MX Linux 23, positioning new windows on the desktop, Linux Containers adopts LXD fork, Oracle, SUSE, and CIQ form OpenELA |
| • Issue 1031 (2023-08-07): Peppermint OS 2023-07-01, preventing a file from being changed, Asahi Linux partners with Fedora, Linux Mint plans new releases |
| • Issue 1030 (2023-07-31): Solus 4.4, Linux Mint 21.2, Debian introduces RISC-V support, Ubuntu patches custom kernel bugs, FreeBSD imports OpenSSL 3 |
| • Issue 1029 (2023-07-24): Running Murena on the Fairphone 4, Flatpak vs Snap sandboxing technologies, Redox OS plans to borrow Linux drivers to expand hardware support, Debian updates Bookworm media |
| • Issue 1028 (2023-07-17): KDE Connect; Oracle, SUSE, and AlmaLinux repsond to Red Hat's source code policy change, KaOS issues media fix, Slackware turns 30; security and immutable distributions |
| • Issue 1027 (2023-07-10): Crystal Linux 2023-03-16, StartOS (embassyOS 0.3.4.2), changing options on a mounted filesystem, Murena launches Fairphone 4 in North America, Fedora debates telemetry for desktop team |
| • Issue 1026 (2023-07-03): Kumander Linux 1.0, Red Hat changing its approach to sharing source code, TrueNAS offers SMB Multichannel, Zorin OS introduces upgrade utility |
| • Issue 1025 (2023-06-26): KaOS with Plasma 6, information which can leak from desktop environments, Red Hat closes door on sharing RHEL source code, SUSE introduces new security features |
| • Issue 1024 (2023-06-19): Debian 12, a safer way to use dd, Debian releases GNU/Hurd 2023, Ubuntu 22.10 nears its end of life, FreeBSD turns 30 |
| • Issue 1023 (2023-06-12): openSUSE 15.5 Leap, the differences between independent distributions, openSUSE lengthens Leap life, Murena offers new phone for North America |
| • Issue 1022 (2023-06-05): GetFreeOS 2023.05.01, Slint 15.0-3, Liya N4Si, cleaning up crowded directories, Ubuntu plans Snap-based variant, Red Hat dropping LireOffice RPM packages |
| • Issue 1021 (2023-05-29): rlxos GNU/Linux, colours in command line output, an overview of Void's unique features, how to use awk, Microsoft publishes a Linux distro |
| • Issue 1020 (2023-05-22): UBports 20.04, finding another machine's IP address, finding distros with a specific kernel, Debian prepares for Bookworm |
| • Issue 1019 (2023-05-15): Rhino Linux (Beta), checking which applications reply on a package, NethServer reborn, System76 improving application responsiveness |
| • Issue 1018 (2023-05-08): Fedora 38, finding relevant manual pages, merging audio files, Fedora plans new immutable edition, Mint works to fix Secure Boot issues |
| • Issue 1017 (2023-05-01): Xubuntu 23.04, Debian elects Project Leaders and updates media, systemd to speed up restarts, Guix System offering ground-up source builds, where package managers install files |
| • Issue 1016 (2023-04-24): Qubes OS 4.1.2, tracking bandwidth usage, Solus resuming development, FreeBSD publishes status report, KaOS offers preview of Plasma 6 |
| • Issue 1015 (2023-04-17): Manjaro Linux 22.0, Trisquel GNU/Linux 11.0, Arch Linux powering PINE64 tablets, Ubuntu offering live patching on HWE kernels, gaining compression on ex4 |
| • Issue 1014 (2023-04-10): Quick looks at carbonOS, LibreELEC, and Kodi, Mint polishes themes, Fedora rolls out more encryption plans, elementary OS improves sideloading experience |
| • Issue 1013 (2023-04-03): Alpine Linux 3.17.2, printing manual pages, Ubuntu Cinnamon becomes official flavour, Endeavour OS plans for new installer, HardenedBSD plans for outage |
| • Issue 1012 (2023-03-27): siduction 22.1.1, protecting privacy from proprietary applications, GNOME team shares new features, Canonical updates Ubuntu 20.04, politics and the Linux kernel |
| • Issue 1011 (2023-03-20): Serpent OS, Security Onion 2.3, Gentoo Live, replacing the scp utility, openSUSE sees surge in downloads, Debian runs elction with one candidate |
| • Issue 1010 (2023-03-13): blendOS 2023.01.26, keeping track of which files a package installs, improved network widget coming to elementary OS, Vanilla OS changes its base distro |
| • Issue 1009 (2023-03-06): Nemo Mobile and the PinePhone, matching the performance of one distro on another, Linux Mint adds performance boosts and security, custom Ubuntu and Debian builds through Cubic |
| • Issue 1008 (2023-02-27): elementary OS 7.0, the benefits of boot environments, Purism offers lapdock for Librem 5, Ubuntu community flavours directed to drop Flatpak support for Snap |
| • Issue 1007 (2023-02-20): helloSystem 0.8.0, underrated distributions, Solus team working to repair their website, SUSE testing Micro edition, Canonical publishes real-time edition of Ubuntu 22.04 |
| • Issue 1006 (2023-02-13): Playing music with UBports on a PinePhone, quick command line and shell scripting questions, Fedora expands third-party software support, Vanilla OS adds Nix package support |
| • Issue 1005 (2023-02-06): NuTyX 22.12.0 running CDE, user identification numbers, Pop!_OS shares COSMIC progress, Mint makes keyboard and mouse options more accessible |
| • Issue 1004 (2023-01-30): OpenMandriva ROME, checking the health of a disk, Debian adopting OpenSnitch, FreeBSD publishes status report |
| • Issue 1003 (2023-01-23): risiOS 37, mixing package types, Fedora seeks installer feedback, Sparky offers easier persistence with USB writer |
| • Issue 1002 (2023-01-16): Vanilla OS 22.10, Nobara Project 37, verifying torrent downloads, Haiku improvements, HAMMER2 being ports to NetBSD |
| • Issue 1001 (2023-01-09): Arch Linux, Ubuntu tests new system installer, porting KDE software to OpenBSD, verifying files copied properly |
| • Issue 1000 (2023-01-02): Our favourite projects of all time, Fedora trying out unified kernel images and trying to speed up shutdowns, Slackware tests new kernel, detecting what is taking up disk space |
| • Issue 999 (2022-12-19): Favourite distributions of 2022, Fedora plans Budgie spin, UBports releasing security patches for 16.04, Haiku working on new ports |
| • Issue 998 (2022-12-12): OpenBSD 7.2, Asahi Linux enages video hardware acceleration on Apple ARM computers, Manjaro drops proprietary codecs from Mesa package |
| • Issue 997 (2022-12-05): CachyOS 221023 and AgarimOS, working with filenames which contain special characters, elementary OS team fixes delta updates, new features coming to Xfce |
| • Issue 996 (2022-11-28): Void 20221001, remotely shutting down a machine, complex aliases, Fedora tests new web-based installer, Refox OS running on real hardware |
| • Issue 995 (2022-11-21): Fedora 37, swap files vs swap partitions, Unity running on Arch, UBports seeks testers, Murena adds support for more devices |
| • Issue 994 (2022-11-14): Redcore Linux 2201, changing the terminal font size, Fedora plans Phosh spin, openSUSE publishes on-line manual pages, disabling Snap auto-updates |
| • Issue 993 (2022-11-07): Static Linux, working with just a kernel, Mint streamlines Flatpak management, updates coming to elementary OS |
| • Full list of all issues |
| Star Labs |
Star Labs - Laptops built for Linux.
View our range including the highly anticipated StarFighter. Available with coreboot open-source firmware and a choice of Ubuntu, elementary, Manjaro and more. Visit Star Labs for information, to buy and get support.
|
| Shells.com |
Your own personal Linux computer in the cloud, available on any device. Supported operating systems include Android, Debian, Fedora, KDE neon, Kubuntu, Linux Mint, Manjaro and Ubuntu, ready in minutes.
Starting at US$4.95 per month, 7-day money-back guarantee
|
| Random Distribution | 
Rhino Linux
Rhino Linux is an Ubuntu-based distribution which offers a rolling-release upgrade approach. The distribution uses a customised Xfce desktop environment. Rhino features a custom meta package manager which unifies Deb, Pacstall and Flatpak software management.
Status: Active
|
| TUXEDO |
TUXEDO Computers - Linux Hardware in a tailor made suite
Choose from a wide range of laptops and PCs in various sizes and shapes at TUXEDOComputers.com. Every machine comes pre-installed and ready-to-run with Linux. Full 24 months of warranty and lifetime support included!
Learn more about our full service package and all benefits from buying at TUXEDO.
|
| Star Labs |
Star Labs - Laptops built for Linux.
View our range including the highly anticipated StarFighter. Available with coreboot open-source firmware and a choice of Ubuntu, elementary, Manjaro and more. Visit Star Labs for information, to buy and get support.
|
|
• 
• 
• 
• 
• 
• 
• 
