 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) |
|
|
|
 bc1qxes3k2wq3uqzr074tkwwjmwfe63z70gwzfu4lx  lnurl1dp68gurn8ghj7ampd3kx2ar0veekzar0wd5xjtnrdakj7tnhv4kxctttdehhwm30d3h82unvwqhhxarpw3jkc7tzw4ex6cfexyfua2nr  86fA3qPTeQtNb2k1vLwEQaAp3XxkvvvXt69gSG5LGunXXikK9koPWZaRQgfFPBPWhMgXjPjccy9LA9xRFchPWQAnPvxh5Le paypal.me/distrowatchweekly • patreon.com/distrowatch |
|
| Extended Lifecycle Support by TuxCare |
|
|
|
| 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 1100 (2024-12-09): Oreon 9.3, differences in speed, IPFire's new appliance, Fedora Asahi Remix gets new video drivers, openSUSE Leap Micro updated, Redox OS running Redox OS |
| • Issue 1099 (2024-12-02): AnduinOS 1.0.1, measuring RAM usage, SUSE continues rebranding efforts, UBports prepares for next major version, Murena offering non-NFC phone |
| • Issue 1098 (2024-11-25): Linux Lite 7.2, backing up specific folders, Murena and Fairphone partner in fair trade deal, Arch installer gets new text interface, Ubuntu security tool patched |
| • Issue 1097 (2024-11-18): Chimera Linux vs Chimera OS, choosing between AlmaLinux and Debian, Fedora elevates KDE spin to an edition, Fedora previews new installer, KDE testing its own distro, Qubes-style isolation coming to FreeBSD |
| • Issue 1096 (2024-11-11): Bazzite 40, Playtron OS Alpha 1, Tucana Linux 3.1, detecting Screen sessions, Redox imports COSMIC software centre, FreeBSD booting on the PinePhone Pro, LXQt supports Wayland window managers |
| • Issue 1095 (2024-11-04): Fedora 41 Kinoite, transferring applications between computers, openSUSE Tumbleweed receives multiple upgrades, Ubuntu testing compiler optimizations, Mint partners with Framework |
| • Issue 1094 (2024-10-28): DebLight OS 1, backing up crontab, AlmaLinux introduces Litten branch, openSUSE unveils refreshed look, Ubuntu turns 20
| | • Issue 1093 (2024-10-21): Kubuntu 24.10, atomic vs immutable distributions, Debian upgrading Perl packages, UBports adding VoLTE support, Android to gain native GNU/Linux application support |
| • Issue 1092 (2024-10-14): FunOS 24.04.1, a home directory inside a file, work starts of openSUSE Leap 16.0, improvements in Haiku, KDE neon upgrades its base |
| • Issue 1091 (2024-10-07): Redox OS 0.9.0, Unified package management vs universal package formats, Redox begins RISC-V port, Mint polishes interface, Qubes certifies new laptop |
| • Issue 1090 (2024-09-30): Rhino Linux 2024.2, commercial distros with alternative desktops, Valve seeks to improve Wayland performance, HardenedBSD parterns with Protectli, Tails merges with Tor Project, Quantum Leap partners with the FreeBSD Foundation |
| • Issue 1089 (2024-09-23): Expirion 6.0, openKylin 2.0, managing configuration files, the future of Linux development, fixing bugs in Haiku, Slackware packages dracut |
| • Issue 1088 (2024-09-16): PorteuX 1.6, migrating from Windows 10 to which Linux distro, making NetBSD immutable, AlmaLinux offers hardware certification, Mint updates old APT tools |
| • Issue 1087 (2024-09-09): COSMIC desktop, running cron jobs at variable times, UBports highlights new apps, HardenedBSD offers work around for FreeBSD change, Debian considers how to cull old packages, systemd ported to musl |
| • Issue 1086 (2024-09-02): Vanilla OS 2, command line tips for simple tasks, FreeBSD receives investment from STF, openSUSE Tumbleweed update can break network connections, Debian refreshes media |
| • Issue 1085 (2024-08-26): Nobara 40, OpenMandriva 24.07 "ROME", distros which include source code, FreeBSD publishes quarterly report, Microsoft updates breaks Linux in dual-boot environments |
| • Issue 1084 (2024-08-19): Liya 2.0, dual boot with encryption, Haiku introduces performance improvements, Gentoo dropping IA-64, Redcore merges major upgrade |
| • Issue 1083 (2024-08-12): TrueNAS 24.04.2 "SCALE", Linux distros for smartphones, Redox OS introduces web server, PipeWire exposes battery drain on Linux, Canonical updates kernel version policy |
| • Issue 1082 (2024-08-05): Linux Mint 22, taking snapshots of UFS on FreeBSD, openSUSE updates Tumbleweed and Aeon, Debian creates Tiny QA Tasks, Manjaro testing immutable images |
| • Issue 1081 (2024-07-29): SysLinuxOS 12.4, OpenBSD gain hardware acceleration, Slackware changes kernel naming, Mint publishes upgrade instructions |
| • Issue 1080 (2024-07-22): Running GNU/Linux on Android with Andronix, protecting network services, Solus dropping AppArmor and Snap, openSUSE Aeon Desktop gaining full disk encryption, SUSE asks openSUSE to change its branding |
| • Issue 1079 (2024-07-15): Ubuntu Core 24, hiding files on Linux, Fedora dropping X11 packages on Workstation, Red Hat phasing out GRUB, new OpenSSH vulnerability, FreeBSD speeds up release cycle, UBports testing new first-run wizard |
| • Issue 1078 (2024-07-08): Changing init software, server machines running desktop environments, OpenSSH vulnerability patched, Peppermint launches new edition, HardenedBSD updates ports |
| • Issue 1077 (2024-07-01): The Unity and Lomiri interfaces, different distros for different tasks, Ubuntu plans to run Wayland on NVIDIA cards, openSUSE updates Leap Micro, Debian releases refreshed media, UBports gaining contact synchronisation, FreeDOS celebrates its 30th anniversary |
| • Issue 1076 (2024-06-24): openSUSE 15.6, what makes Linux unique, SUSE Liberty Linux to support CentOS Linux 7, SLE receives 19 years of support, openSUSE testing Leap Micro edition |
| • Issue 1075 (2024-06-17): Redox OS, X11 and Wayland on the BSDs, AlmaLinux releases Pi build, Canonical announces RISC-V laptop with Ubuntu, key changes in systemd |
| • Issue 1074 (2024-06-10): Endless OS 6.0.0, distros with init diversity, Mint to filter unverified Flatpaks, Debian adds systemd-boot options, Redox adopts COSMIC desktop, OpenSSH gains new security features |
| • Issue 1073 (2024-06-03): LXQt 2.0.0, an overview of Linux desktop environments, Canonical partners with Milk-V, openSUSE introduces new features in Aeon Desktop, Fedora mirrors see rise in traffic, Wayland adds OpenBSD support |
| • Issue 1072 (2024-05-27): Manjaro 24.0, comparing init software, OpenBSD ports Plasma 6, Arch community debates mirror requirements, ThinOS to upgrade its FreeBSD core |
| • Issue 1071 (2024-05-20): Archcraft 2024.04.06, common command line mistakes, ReactOS imports WINE improvements, Haiku makes adjusting themes easier, NetBSD takes a stand against code generated by chatbots |
| • Issue 1070 (2024-05-13): Damn Small Linux 2024, hiding kernel messages during boot, Red Hat offers AI edition, new web browser for UBports, Fedora Asahi Remix 40 released, Qubes extends support for version 4.1 |
| • Issue 1069 (2024-05-06): Ubuntu 24.04, installing packages in alternative locations, systemd creates sudo alternative, Mint encourages XApps collaboration, FreeBSD publishes quarterly update |
| • Issue 1068 (2024-04-29): Fedora 40, transforming one distro into another, Debian elects new Project Leader, Red Hat extends support cycle, Emmabuntus adds accessibility features, Canonical's new security features |
| • Issue 1067 (2024-04-22): LocalSend for transferring files, detecting supported CPU architecure levels, new visual design for APT, Fedora and openSUSE working on reproducible builds, LXQt released, AlmaLinux re-adds hardware support |
| • Issue 1066 (2024-04-15): Fun projects to do with the Raspberry Pi and PinePhone, installing new software on fixed-release distributions, improving GNOME Terminal performance, Mint testing new repository mirrors, Gentoo becomes a Software In the Public Interest project |
| • Issue 1065 (2024-04-08): Dr.Parted Live 24.03, answering questions about the xz exploit, Linux Mint to ship HWE kernel, AlmaLinux patches flaw ahead of upstream Red Hat, Calculate changes release model |
| • Issue 1064 (2024-04-01): NixOS 23.11, the status of Hurd, liblzma compromised upstream, FreeBSD Foundation focuses on improving wireless networking, Ubuntu Pro offers 12 years of support |
| • Issue 1063 (2024-03-25): Redcore Linux 2401, how slowly can a rolling release update, Debian starts new Project Leader election, Red Hat creating new NVIDIA driver, Snap store hit with more malware |
| • Issue 1062 (2024-03-18): KDE neon 20240304, changing file permissions, Canonical turns 20, Pop!_OS creates new software centre, openSUSE packages Plasma 6 |
| • Issue 1061 (2024-03-11): Using a PinePhone as a workstation, restarting background services on a schedule, NixBSD ports Nix to FreeBSD, Fedora packaging COSMIC, postmarketOS to adopt systemd, Linux Mint replacing HexChat |
| • Issue 1060 (2024-03-04): AV Linux MX-23.1, bootstrapping a network connection, key OpenBSD features, Qubes certifies new hardware, LXQt and Plasma migrate to Qt 6 |
| • Issue 1059 (2024-02-26): Warp Terminal, navigating manual pages, malware found in the Snap store, Red Hat considering CPU requirement update, UBports organizes ongoing work |
| • Issue 1058 (2024-02-19): Drauger OS 7.6, how much disk space to allocate, System76 prepares to launch COSMIC desktop, UBports changes its version scheme, TrueNAS to offer faster deduplication |
| • Issue 1057 (2024-02-12): Adelie Linux 1.0 Beta, rolling release vs fixed for a smoother experience, Debian working on 2038 bug, elementary OS to split applications from base system updates, Fedora announces Atomic Desktops |
| • Issue 1056 (2024-02-05): wattOS R13, the various write speeds of ISO writing tools, DSL returns, Mint faces Wayland challenges, HardenedBSD blocks foreign USB devices, Gentoo publishes new repository, Linux distros patch glibc flaw |
| • Issue 1055 (2024-01-29): CNIX OS 231204, distributions patching packages the most, Gentoo team presents ongoing work, UBports introduces connectivity and battery improvements, interview with Haiku developer |
| • Issue 1054 (2024-01-22): Solus 4.5, comparing dd and cp when writing ISO files, openSUSE plans new major Leap version, XeroLinux shutting down, HardenedBSD changes its build schedule |
| • Issue 1053 (2024-01-15): Linux AI voice assistants, some distributions running hotter than others, UBports talks about coming changes, Qubes certifies StarBook laptops, Asahi Linux improves energy savings |
| • Issue 1052 (2024-01-08): OpenMandriva Lx 5.0, keeping shell commands running when theterminal closes, Mint upgrades Edge kernel, Vanilla OS plans big changes, Canonical working to make Snap more cross-platform |
| • Issue 1051 (2024-01-01): Favourite distros of 2023, reloading shell settings, Asahi Linux releases Fedora remix, Gentoo offers binary packages, openSUSE provides full disk encryption |
| • Issue 1050 (2023-12-18): rlxos 2023.11, renaming files and opening terminal windows in specific directories, TrueNAS publishes ZFS fixes, Debian publishes delayed install media, Haiku polishes desktop experience |
| • Issue 1049 (2023-12-11): Lernstick 12, alternatives to WINE, openSUSE updates its branding, Mint unveils new features, Lubuntu team plans for 24.04 |
| • Issue 1048 (2023-12-04): openSUSE MicroOS, the transition from X11 to Wayland, Red Hat phasing out X11 packages, UBports making mobile development easier |
| • Issue 1047 (2023-11-27): GhostBSD 23.10.1, Why Linux uses swap when memory is free, Ubuntu Budgie may benefit from Wayland work in Xfce, early issues with FreeBSD 14.0 |
| • Issue 1046 (2023-11-20): Slackel 7.7 "Openbox", restricting CPU usage, Haiku improves font handling and software centre performance, Canonical launches MicroCloud |
| • 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.
|
| Random Distribution | 
Linuxfx
Linuxfx is a Brazilian Linux distribution based on Ubuntu. It ships with an intuitive Cinnamon desktop user interface designed to facilitate migration of users from Windows. It includes a video management system called Sentinela, a computer vision software with video analytics and software for access control (facial recognition and automatic number plate recognition), object detection, gender, age and mood detection. Other features of the distribution include a new personal assistant, a WX theme for desktop and system applications, and compatibility with software written for Windows (.exe and .msi) through a Wine port. Following the release of Linuxfx 10.6 the distribution became a commercial offering.
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.
|
|
• 
• 
• 
• 
• 
• 
• 
