| DistroWatch Weekly
|DistroWatch Weekly, Issue 616, 29 June 2015
Welcome to this year's 26th issue of DistroWatch Weekly!
One of the great things about open source software is the way developers can take existing code and tailor it to work in new ways or on different platforms. This week we look at customized projects and operating systems being adjusted to suit specific needs. We begin with a review of MidnightBSD, a fork of the FreeBSD project designed with the desktop in mind. We also follow up last week's review of Raspbian with quick look at what it is like to run FreeBSD on the Raspberry Pi computer. In our News section this week we explore utilities for customizing Fedora Workstation, talk about funding Debian developers are receiving to improve reproducible builds and talk about Linux's new file system encryption technology. We also share information about an upcoming openSUSE release with the code name "42" and report on Johnathan Riddell leaving the Kubuntu Community Council. Plus we share a list of torrents we are seeding this week and supply a list of the distributions released last week. In our Opinion Poll we ask whether our readers run 32-bit or 64-bit systems and why. We wish you all a fantastic week and happy reading!
|Feature Story (by Jesse Smith)
Running BSD on the desktop with MidnightBSD 0.6
FreeBSD is a fine operating system to run on servers and some people feel the characteristics which make FreeBSD suitable for servers (conservative updates, stability, performance) also make the operating system a good choice for desktop computers. Or, at least, FreeBSD could be a good desktop operating system with a few tweaks. That is the premise behind MidnightBSD, a desktop-oriented project that forked from FreeBSD. "MidnightBSD was forked from FreeBSD 6.1 beta. The system was forked to allow us to customize and integrate the environment including the ports and system configuration. We wish for the system to appeal to beginners as well as more experienced BSD users. Many operating systems are under active development; with MidnightBSD, we wish to focus on optimization and usability improvements for desktop users."
The most recent release of MidnightBSD, version 0.6, focuses primarily on fixing bugs and patching security flaws. The latest release also ships with a new version of the mport package manager utility. MidnightBSD's mport package manager is used to manipulate the operating system's third-party software, in much the same way FreeBSD's pkg utility manages third-party packages. MidnightBSD 0.6 is available in 32-bit and 64-bit x86 builds. The installation ISO we download is approximately 765MB in size. On the download page there is a link to live discs which would allow users to test the operating system's desktop environment, however the link to live media downloads is broken.
Booting from MidnightBSD's installation media brings up a text menu asking if we would like to launch the project's system installer or drop to a command line shell. Taking the install option walks us through a number of text screens where we are asked to type in information or make selections from menus. We are first asked if we would like to change our keyboard's layout and then we are asked to set a hostname for our computer. The next screen asks us to select which packages we wish to have installed. These packages include documentation, games, 32-bit compatibility libraries, mport and the operating system's source code. The following screen asks if we would like to manually partition our hard drive or if the installer should automatically partition it for us. I tried the automated partitioning option and found it offered a default layout with three GPT partitions (a GPT boot partition, a root partition formatted with UFS and swap space). We can change our partitions after the installer has made its suggestions before any alterations are made to our disk. The installer copies its files to our hard drive before asking some additional questions. We are asked to create a password for the root account, configure our network interface and select our time zone from a list of locations. The following screen asks us which background services the operating system should run - with the options including network time synchronization, a mouse daemon, powerd for power management and the OpenSSH secure shell service. We can then optionally create as many user accounts as we like. When we are done the installer asks us to reboot the computer.
The first time we boot into our new copy of MidnightBSD we are presented with a text console where we are asked two questions. The first prompt asks if we would like to submit our computer to a BSD statistics tracking website. The second prompt asks if we wish to enable a graphical user interface. I answered negative to the first question and affirmative to the second. MidnightBSD then downloaded several packages and, a few minutes later, presented me with a login prompt.
One of the first things I wanted to do was transition from a text console to a graphical user interface. Getting to a graphical desktop proved to be somewhat difficult as most of the X display server packages were not installed. (Which does make me wonder what MidnightBSD was installing after I requested a graphical interface be put into place.) I turned to the mport utility in order to download and install the X display server and a display manager.. MidnightBSD does not use its parent's pkg repositories or ports tree. Instead, MidnightBSD uses what appears to be a modified fork of the FreeBSD ports collection, compiled into binary packages. The mport package manager works in a similar manner to pkg or apt-get, allowing us to search for, install and upgrade software on our system. The mport repository appears to be fairly small, a quick estimate places its size at less than 5,000 packages compared with FreeBSD's 24,000 ports.
Using mport, I was able to locate and download Xorg packages. However, with the packages installed and the display server services enabled, I still was not able to launch a graphical interface. Since the MidnightBSD website has very little documentation, I ended up following the instructions provided by FreeBSD's Handbook to get the X display server running. At this point I was able to launch a graphical interface and get a few terminal windows open. Unfortunately, I still did not have a proper desktop, just a bare bones window manager, and closing a window would usually cause the entire graphical interface to crash, returning me to the text console. I performed searches of the mport software repository, looking for a desktop environment, but I was unable to find packages for KDE, GNOME, Xfce or LXDE.
At this point in my experiment, I decided to give up on getting a full featured desktop environment running and turned my attention to experimenting with the operating system's command line. I found MidnightBSD was fairly light on memory. The operating system used about 20MB of active memory and 75MB of wired memory. The operating system required about 1.5GB of disk space with the X display server installed. MidnightBSD ships with the standard collection of UNIX command line tools and two compilers (Clang and GCC). When working from the command line, MidnightBSD was stable and worked quickly. At least MidnightBSD worked well in a VirtualBox virtual machine, the operating system was unable to boot on my desktop computer.
Earlier I mentioned we can install and update third-party software using MidnightBSD's mport package manager. The mport program works quickly and well. However, so far as I could tell, mport is designed to work on third-party software only and does not appear to offer updates to the base operating system. This concerned me as the project's website contains many security notices, but I could not find any instructions for patching known vulnerabilities. MidnightBSD does not ship with a copy of FreeBSD's freebsd-update utility and the documentation on the project's website does not cover performing software upgrades. FreeBSD includes update instructions in their security advisories, but MidnightBSD's advisories do not appear to have any specific instructions for keeping the system up to date. I suspect that checking out new copies of the MidnightBSD source code may be required for keeping up to date with patches and we may need to build and install patches from the source code, but I cannot find confirmation of this on MidnightBSD's website. During my hunt for information on dealing with security updates I found the project's website has a number of broken links, preventing the user from accessing documentation, live discs and information on past releases.
I found using MidnightBSD strange. While the low level tools and general environment felt familiar to me as a FreeBSD user, there were frequently pieces of the experience missing. MidnightBSD has virtually none of FreeBSD's extensive documentation, which may not have been a problem when the project originally forked from FreeBSD, but now MidnightBSD has diverged enough that it really should have its own Handbook. MidnightBSD offers some of the same ports as its parent, but has fallen about 20,000 packages behind. Further, according to the MidnightBSD website, the project aims to provide a beginner friendly, desktop-oriented operating system, similar to FreeBSD. However, from my experiences this past week, it seems as though MidnightBSD lags behind GhostBSD, PC-BSD and even FreeBSD in providing a newcomer friendly platform. A few years ago tools like mport might have been quite welcome to FreeBSD users, but now pkg fills that role in the FreeBSD community. In short, I feel that MidnightBSD, while it began with promise and admirable goals, has fallen behind in technology, user experience and documentation.
* * * * *
Hardware used in this review
My physical test equipment for this review was a desktop HP Pavilon p6 Series with the following specifications:
- Processor: Dual-core 2.8GHz AMD A4-3420 APU
- Storage: 500GB Hitachi hard drive
- Memory: 6GB of RAM
- Networking: Realtek RTL8111 wired network card
- Display: AMD Radeon HD 6410D video card
|Miscellaneous News (by Jesse Smith)
Customizing Fedora, Debian gains sponsorship for reproducible builds, Linux's ext4 file system to get built in encryption, openSUSE unveils "42" and Johnathan Riddell leaves the Kubuntu Council
The Fedora distribution is an interesting platform that is
always shipping new software and integrating new technologies. While Fedora is a
fun testing ground for new software, the distribution is not the easiest to set
up and desktop users often need to perform extra configuration steps
post-installation. As the Open Content & Software Magazine reports, "Fedora ships with free software only, by default, which means that some of the common, popular stuff many people use will not be available by default. Proprietary solutions like Adobe Flash, MP3 codecs, Steam, Skype, and whole bunch of other programs will not be in the repos, and you will need to take some extra steps to get them. This little guide should make your life
easier in that regard." The article goes on to explore various utilities available that facilitate installing third-party software and customizing the Fedora distribution.
* * * * *
We have talked before about the Debian project's quest to
builds and how this can improve security and trust with regards to the
distribution's packages. The Debian project announced last week that the Core Infrastructure Initiative will sponsor two of its developers to continue their work on reproducible builds. "The Core Infrastructure Initiative announced today that they will support two Debian Developers, Holger Levsen and Jeremy Bobbio, with $200,000 to advance their Debian work in reproducible builds and to collaborate more closely with other distributions such as Fedora, Ubuntu, OpenWrt to benefit from this effort. The Core Infrastructure Initiative (CII) was established in 2014 to fortify the security of key open source projects. This initiative is funded by more than 20 companies and managed by The Linux Foundation." Further information on Debian's goals for reproducible builds can be found in the announcement.
* * * * *
File system encryption is often something that is added on to an existing file system, acting as a separate layer of functionality, rather than a built-in feature of the file system itself. Often times complexity and performance concerns prevent data encryption from being a core component of a file system. Linux users will soon be able to use a file system with built in encryption via ext4. "Encryption in ext4 is a per-directory-tree affair. One starts by setting an encryption policy for a given directory, which must be empty at the time; that policy includes a master key used for all files and directories stored below the target directory. Each individual file is encrypted with its own key, which is derived from the master key and a per-file random nonce value (which is stored in an extended attribute attached to the file's inode). File names and symbolic links are also encrypted." Additional information on how encryption will work on ext4 and its benefits over other forms of encryption, such as eCryptfs, are covered in this LWN article.
* * * * *
The openSUSE project is working on a new version of their popular distribution and the new release is expected to be a departure from the openSUSE releases of the past few years. The new version, code named "42", will be aligned more closely with SUSE Linux Enterprise releases and service packs. The openSUSE blog explains: "Some people might be perplexed over the next regular release, but rather than bikeshedding the name over the next few months, for the moment, we will call it openSUSE 42 after its project name in the Open Build Service. And we are going to explain the roadmap for this regular release. openSUSE 42 is scheduled to be released around SUSECon, which is in Amsterdam this year from November 2 - 6. Unlike old releases, future releases of `42' are expected to align with the releases of SLE service packs and major releases. `There are about 2,000 packages in openSUSE 42 right now,' said Stephan `Coolo' Kulow, release manager. Of course, many more are expected. openSUSE 42 will be a long-term type release with enduring updates and maintenance commitments by the community and SUSE." A development snapshot is expected to be released soon in order to give openSUSE users a chance to test "42" and provide feedback.
* * * * *
Back at the beginning of June we mentioned that the Ubuntu Community Council had ordered Johnathan Riddell to vacate his Kubuntu leadership roles, including his position on the Kubuntu Community Council. At the time the demand appeared to come out of the blue and the Kubuntu Community Council voted to keep Riddell in his position while the matter was explored further. Last week Laura Czajkowski, a member of the Ubuntu Community Council, announced a resolution has been reached. "After much public controversy, the Ubuntu Community Council and Kubuntu
Council have met with Mark Shuttleworth and Jonathan Riddell to chart a path forward. Jonathan Riddell has removed his membership in ~kubuntu-council as the Community Council required, and the Fridge post has been removed as the Kubuntu Council requested. Provisions are being made to better handle cases where there is a potential conflict of interest for a member of the CC. We have mutually agreed that KDE is important to Ubuntu, and the Kubuntu Council believes that Ubuntu is important to the KDE community as well. Therefore we have a basis to work together on putting out a lovely Wily release. We recognize that there are honest and strong feelings about both the things that led up to the current controversy and the way that resolution of it was handled. Despite that, we would all like to move forward as best we can for the betterment of the Ubuntu project, including Kubuntu."
|Rapid Review (by Jesse Smith)
FreeBSD on a Raspberry Pi 2
Last week I shared my experience of running the Raspbian distribution on a Raspberry Pi computer. A number of people asked how the experience compares to running one of the BSD operating systems on a Pi and so I decided to load FreeBSD onto my tiny Pi computer.
Before diving into my experiment with FreeBSD on the Pi, I think it is important to note that FreeBSD is just now getting support for the Raspberry Pi 2. The wiki page for FreeBSD's status on the Pi has been changing quickly. In fact, the week I purchased my Raspberry Pi 2, virtually no features were reported to work on the device. A week or so later, most of the feature matrix changed from red to green, indicating most of the Pi's hardware would work with FreeBSD. I think it is also worth mentioning there are no images of FreeBSD's stable (10.x) branch for the Raspberry Pi 2. There are stable releases for the earlier Raspberry Pi machines, but not the most recent hardware. People who want to use FreeBSD on a Raspberry Pi 2 need to download an image of FreeBSD 11, the development branch of FreeBSD. Running the development (aka Current) branch of FreeBSD may lead to some regressions or unstable behaviour. In short, FreeBSD on the Raspberry Pi 2 is highly experimental and likely to be unstable, use it at your own risk.
The compressed image file we download for the Pi is 93MB in size. Once the image is decompressed it expands to 1024MB. We can transfer the image to a microSD card and use it to boot the Raspberry Pi. The first time I booted the Pi with FreeBSD I did so in a headless environment where the Pi was only accessible via a network connection. The Pi came on-line and I could connect to its OpenSSH service, but I was unable to login and I could not find a username/password combination in the documentation. I eventually found out the FreeBSD image has a root account only and it has no password. The image also disables remote root login attempts. This means we need to hook the Pi up to a monitor and keyboard, create a new user account and then we will be able to login remotely. Something else I noticed early on was that FreeBSD turns off the Pi's external "power on" light when it boots. This makes it appear as though the Pi has been deactivated, but it is, in fact, still running. Raspbian, by contrast, leaves the light on to let us know the Pi is working.
I attached a monitor and keyboard to the Pi. FreeBSD boots to a text console where we can login as the root user. We can then explore the operating system, create new user accounts and access the Internet since FreeBSD kindly enables networking by default. Unlike Raspbian, which offers a desktop interface, FreeBSD keeps its environment to a minimum and grants us a command line interface only. FreeBSD's minimal environment (it runs only a dozen processes, including our login shell) offers us a very lightweight operating system. FreeBSD uses a mere 5MB of active memory and about 90MB of wired memory. The operating system takes up about 500MB of space on the SD card.
Since most people will probably want to use additional software on their Pi computers, I went looking for software I could install on FreeBSD. Here I ran into a few problems. The first is that there is no official FreeBSD package repository for ARM devices such as the Raspberry Pi. A few people have set up unofficial repositories, but those need to be located through forums or mailing lists. I'm a bit wary of enabling third-party repositories so I decided to download the FreeBSD ports collection which would enable me to build software from its source code. At first I tried to use the portsnap command to download the ports collection. The portsnap tool reported the port meta data it found on the server was not correct and it refused to download the ports collection for me.
Instead I manually downloaded an archive containing a snapshot of the FreeBSD ports collection, unpacked it and accessed ports that way. Building ports worked passably well. Building software, especially larger packages, on a Raspberry Pi can be time consuming. The Pi has a relatively slow processor and little memory so most ports will take a good deal longer to build on the Pi than on a modern desktop or server. Still, it seems most ports will build and run, given enough time.
At this point I had a basic FreeBSD system that appeared to be stable. I could build some additional software for the Pi and all the normal command line tools were working for me. Though the Pi is not a fast machine, the minimal FreeBSD operating system was responsive. I was using less than 100MB of memory (the Pi provides 1024MB of RAM) and my average system load was typically under 0.2.
When I experimented with Raspbian on the Pi I added support for ZFS, an advanced file system capable of managing snapshots and vast amounts of storage. Since ZFS is available natively as a part of the FreeBSD operating system I decided to mount my external hard drive which was acting as a ZFS storage volume. Here is where things got difficult.
As it happens, while ZFS is available on the x86 build of FreeBSD, ZFS is not available to people using the ARM image of the operating system. ZFS support must be added manually*. Once I compiled the necessary ZFS modules and enabled them in my configuration, I was able to mount my external drive and access the storage pool I had created under Raspbian. With ZFS running, FreeBSD's memory usage remained mostly unchanged, with the operating system using a total of 160MB of RAM.
At this point my experience turned from difficult to weird. I found, for example, that I could copy one file at a time from the UFS formatted SD card to my ZFS volume, or one file from my ZFS volume to my UFS formatted partition. However, attempting to copy multiple files, say five or more at a time, across devices using the cp command would cause the operating system to crash. At one point I unpacked the ports collection on my ZFS volume and found that I could read and access all the files, until I ran the make command in any port. Attempting to run make would fail and render the port's Makefile unreadable. The file was still there and still the same size, but its data was unreadable. The Makefiles I clobbered in this fashion could be restored by simply unmounting and remounting the ZFS volume.
At first I thought these problems might be caused by an incompatibility between the Raspbian implementation of ZFS and FreeBSD's implementation. I found another hard drive and used FreeBSD to set up a new ZFS volume on the second hard disk. The same issues persisted with the operating system crashing while copying multiple files across file system boundaries and Makefiles becoming unreadable when accessed by the make command. As before, unmounting and remounting the drive caused clobbered files to be restored to their normal condition.
I eventually gave up getting ZFS to work on FreeBSD's ARM port. However, other than the trouble I experienced with ZFS, I found FreeBSD worked well on the Raspberry Pi. The images being built for the Raspberry Pi 2 are still quite experimental and changing each month, but the latest snapshot (at time of writing) works well for most things. Video, networking and compiling all work. The system is stable when only accessing UFS partitions and tasks complete quickly.
What I generally found during my time running FreeBSD on the Pi was the technology was generally sound, but the documentation is currently sparse. Trying to find even basic bits of information such as the default login credentials resulted in a trip to the FreeBSD forums in search of answers. It is my hope that, before FreeBSD 11 is released, the Pi port will gain additional documentation. I also hope the project creates an official ARM repository as, at the moment, compiling ports from source code is a time consuming task. In short, the base operating system works well, the foundation is in place, but the Raspberry Pi branch of FreeBSD is still in the early stages and does not yet have infrastructure in place on par with the x86 branch of the project.
* * * * *
* Adding ZFS support to FreeBSD's Raspberry Pi port is not well documented and I had to visit a few different forums and mailing lists to piece together what I would need to add (and enable) ZFS modules on my Pi. Most of the documentation and discussions revolved around older versions of FreeBSD from before ZFS was made a part of the base system on x86 architectures. To assist others who may want to experiment with ZFS support on ARM-powered machines I have put together the steps I performed to build ZFS modules.
First, we need to download the FreeBSD ports collection.
Next we need to unpack the ports and build the Subversion package.
With Subversion installed we next need to use Subversion to download the latest version of the kernel source code. There are a few ways to do this, but I found it expeditious to download all of FreeBSD's source code and proceed from there.
tar xzf /root/ports.tar.gz
The next thing we need to do is build three modules: opensolaris, zlib and zfs.
svn co https://svn0.us-west.freebsd.org/base/head/
The modules are now installed, but not yet enabled. To enable the ZFS module we need to add the following text to the /etc/rc.conf file. We can do this using the vi text editor.
cp opensolaris.k* /boot/kernel
cp zlib.k* /boot/kernel
cp zfs.k* /boot/kernel
At this point we can either reboot the operating system to load the ZFS module, or manually load it ourselves using the following command:
At this point commands such as zpool and zfs should work and enable us to create, mount and snapshot ZFS storage pools.
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 distributions that do not offer a bittorrent option themselves. 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 and please make sure the project you are recommending does not already host its own torrents. We want to primarily help distributions and users who do not already have a torrent option. 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: 77
- Total downloads completed: 44,042
- Total data uploaded: 8.1TB
|Released Last Week
Chris Buechler has announced the release of pfSense 2.2.3, a security and bug-fix update of the specialist operating system designed for firewalls and routers, based on FreeBSD: "pfSense software version 2.2.3 release is now available, bringing a number of bug fixes and some security updates. Security fixes: multiple XSS vulnerabilities in the pfSense WebGUI, the complete list of affected pages and fields is large and all are listed in the linked SA; multiple OpenSSL vulnerabilities (including Logjam). The bug fixes and changes in this release are detailed here. As always, you can upgrade from any previous version straight to 2.2.3. For those already running any 2.2x version, this is a low-risk upgrade. This is a high-priority upgrade for those using IPsec on 2.2x versions. For those on 2.1.x or earlier versions, there are a number of significant changes which may impact you. Pay close attention to the 2.2 upgrade notes for the details." Here is the brief release announcement.
The developers of SparkyLinux, a distribution based on Debian's Testing branch (also know as Debian "Stretch"), have announced the availability of a new release. SparkyLinux 4.0 ships with version 4.0.5 of the Linux kernel, offers package compatibility with Debian "Stretch" and can be installed on machines featuring UEFI. "[The] 32-bit edition of SparkyLinux features Linux kernel i586 non-PAE. If you would like to install i686-pae kernel, you can do it via Sparky APTus-> Install tab-> Install i686-PAE Kernel. Just remember to refresh package list before. Starting from Sparky 4.0, the live images offer support for installing the system on 32-bit machines with UEFI motherboard. As an addition, all the traditional 'grub-efi' files have been removed from the live ISO images and replaced by our own, custom 'efi.img' files built by MoroS using his custom script." SparkyLinux is presently available in five different desktop editions (LXDE, LXQt, KDE, MATE and Xfce). Further information can be found in the project's release announcement.
VectorLinux 7.1 -- Running the LXDE desktop
(full image size: 2.6MB, resolution: 1280x1024 pixels)
It took quite a while to build, but finally it's here - the brand new VectorLinux 7.1. A Slackware-derived distribution with Xfce and without systemd. From the release announcement: "The VectorLinux team is proud to announce the final release of VectorLinux 7.1. This release is the culmination of years of work to make our distro the standard which all others hope to achieve. We have successfully developed an easy-to-use installer that can be used in both GUI and text modes depending on the hardware involved. It requires very little user intervention to achieve a successful installation of the system. We have completely automated our internal package system so that all packages are constantly up-to-date and patched as necessary. The system is available both in 32-bit and 64-bit variants and features the latest linux 3.18.16 LTS kernel. We use the latest Xfce as our GUI desktop with Fluxbox as an alternative. The repository contains the bigger systems like KDE and thousands of other programs easily installed through the tried and trusted gslapt/slaptget package installer."
* * * * *
Development, unannounced and minor bug-fix releases
|Upcoming Releases and Announcements
Summary of expected upcoming releases
32-bit vs 64-bit
Last week, one of our readers asked if we would run a poll on 32-bit vs 64-bit computing. Several distributions have decided to support 64-bit computers exclusively in the past few years. However, it is common to see posts on support forums asking where users can find 32-bit installation media, so there are clearly still people who continue to use 32-bit operating systems. Our question this week is: Do you use 32-bit operating systems exclusively, a mixture of 32-bit and 64-bit systems or have you gone 64-bit exclusively? If you do still use 32-bit distributions, please tell us why in the comments section.
You can see the results of last week's poll on distro-hopping frequency here.
My OSes are (32- vs 64-bit)
|32-bit only: ||397 (12%)|
| A mix of 32-bit and 64-bit: ||1226 (38%)|
| 64-bit only: ||1346 (42%)|
| 64-bit x86 and 32-bit ARM: ||232 (7%)|
| Other: ||10 (0%)|
Expanding search capabilities
We often receive suggestions for ways we can improve DistroWatch and this past week we implemented a few of the more popular ideas. Specifically, one of the things we did was add a new category to our Search page. When performing simple or advanced searches it is now possible to find distributions based on which packaging format the operating system uses. At the moment we support searching for distributions which use RPM, Debian packages, Pacman, Portage and TGZ files. We plan to fine tune the searches over time to include more formats and specific package managers, such as DNF, APT and PKG-NG. If you happen to find an error in our package management data or would like to help us improve our coverage of package managers in distributions, please e-mail Jesse and put "Package Management" in the subject line.
The second feature we have added is a new sidebar widget on our front page. Some readers pointed out they would like to have quick access to new distributions being added to our waiting list. The new widget, called "New To Waiting List", appears about halfway down the main page and displays the most recent projects added to our waiting list.
Finally, when performing searches from the top bar (where it says "Type Distribution Name"), our system now displays both distributions in our database and distributions on our waiting list. We know some distributions sit on our waiting list for a long time and we want to make those projects easier to find for people who want to try something new.
We have more planned and will post updates as new features and data are added to our system.
* * * * *
Distributions added to waiting list
- Clear Linux. The Clear Linux Project for Intel architecture is a distribution built for various cloud use cases.
* * * * *
DistroWatch database summary
* * * * *
This concludes this week's issue of DistroWatch Weekly. The next instalment will be published on Monday, 6 July 2015. To contact the authors please send email to:
- Jesse Smith (feedback, questions and suggestions: distribution reviews, questions and answers, tips and tricks)
- Ladislav Bodnar (feedback, questions, suggestions and corrections: news, donations, distribution submissions, comments)
If you've enjoyed this week's issue of DistroWatch Weekly, please consider sending us a tip.
(Tips this week: 0, value: US$0.00)
|Linux Foundation Training
|• Issue 785 (2018-10-15): Reborn OS 2018.09, Nitrux 1.0.15, swapping hard drives between computers, feren OS tries KDE spin, power savings coming to Linux|
|• Issue 784 (2018-10-08): Hamara 2.1, improving manual pages, UBports gets VoIP app, Fedora testing power saving feature|
|• Issue 783 (2018-10-01): Quirky 8.6, setting up dual booting with Ubuntu and FreeBSD, Lubuntu switching to LXQt, Mint works on performance improvements|
|• Issue 782 (2018-09-24): Bodhi Linux 5.0.0, Elive 3.0.0, Solus publishes ISO refresh, UBports invites feedback, Linux Torvalds plans temporary vacation|
|• Issue 781 (2018-09-17): Linux Mint 3 "Debian Edition", file systems for SSDs, MX makes installing Flatpaks easier, Arch team answers questions, Mageia reaches EOL|
|• Issue 780 (2018-09-10): Netrunner 2018.08 Rolling, Fedora improves language support, how to customize Kali Linux, finding the right video drivers|
|• Issue 779 (2018-09-03): Redcore 1806, keeping ISO downloads safe from tampering, Lubuntu makes Calamares more flexible, Ubuntu improves GNOME performance|
|• Issue 778 (2018-08-27): GuixSD 0.15.0, ReactOS 0.4.9, Steam supports Windows games on Linux, Haiku plans for beta, merging disk partitions|
|• Issue 777 (2018-08-20): YunoHost 220.127.116.11, limiting process resource usage, converting file systems on Fedora, Debian turns 25, Lubuntu migrating to Wayland|
|• Issue 776 (2018-08-13): NomadBSD 1.1, Maximum storage limits on Linux, openSUSE extends life for 42.3, updates to the Librem 5 phone interface|
|• Issue 775 (2018-08-06): Secure-K OS 18.5, Linux is about choice, Korora tests community spin, elementary OS hires developer, ReactOS boots on Btrfs|
|• Issue 774 (2018-07-30): Ubuntu MATE & Ubuntu Budgie 18.04, upgrading software from source, Lubuntu shifts focus, NetBSD changes support policy|
|• Issue 773 (2018-07-23): Peppermint OS 9, types of security used by different projects, Mint reacts to bugs in core packages, Slackware turns 25|
|• Issue 772 (2018-07-16): Hyperbola GNU/Linux-libre 0.2.4, UBports running desktop applications, OpenBSD auto-joins wi-fi networks, boot environments and zedenv|
|• Issue 771 (2018-07-09): Linux Lite 4.0, checking CPUs for bugs, configuring GRUB, Mint upgrade instructions, SUSE acquired by EQT|
|• Issue 770 (2018-07-02): Linux Mint 19, Solus polishes desktop experience, MintBox Mini 2, changes to Fedora's installer|
|• Issue 769 (2018-06-25): BunsenLabs Helium, counting Ubuntu users, UBports upgrading to 16.04, Fedora CoreOS, FreeBSD turns 25|
|• Issue 768 (2018-06-18): Devuan 2.0.0, using pkgsrc to manage software, the NOVA filesystem, OpenBSD handles successful cron output|
|• Issue 767 (2018-06-11): Android-x86 7.1-r1, transferring files over OpenSSH with pipes, LFS with Debian package management, Haiku ports LibreOffice|
|• Issue 766 (2018-06-04): openSUSE 15, overview of file system links, Manjaro updates Pamac, ReactOS builds itself, Bodhi closes forums|
|• Issue 765 (2018-05-28): Pop!_OS 18.04, gathering system information, Haiku unifying ARM builds, Solus resumes control of Budgie|
|• Issue 764 (2018-05-21): DragonFly BSD 5.2.0, Tails works on persistent packages, Ubuntu plans new features, finding services affected by an update|
|• Issue 763 (2018-05-14): Fedora 28, Debian compatibility coming to Chrome OS, malware found in some Snaps, Debian's many flavours|
|• Issue 762 (2018-05-07): TrueOS 18.03, live upgrading Raspbian, Mint plans future releases, HardenedBSD to switch back to OpenSSL|
|• Issue 761 (2018-04-30): Ubuntu 18.04, accessing ZFS snapshots, UBports to run on Librem 5 phones, Slackware makes PulseAudio optional|
|• Issue 760 (2018-04-23): Chakra 2017.10, using systemd to hide files, Netrunner's ARM edition, Debian 10 roadmap, Microsoft develops Linux-based OS|
|• Issue 759 (2018-04-16): Neptune 5.0, building containers with Red Hat, antiX introduces Sid edition, fixing filenames on the command line|
|• Issue 758 (2018-04-09): Sortix 1.0, openSUSE's Transactional Updates, Fedora phasing out Python 2, locating portable packages|
|• Issue 757 (2018-04-02): Gatter Linux 0.8, the UNIX and Linux System Administration Handbook, Red Hat turns 25, super long term support kernels|
|• Issue 756 (2018-03-26): NuTyX 10.0, Neptune supplies Debian users with Plasma 5.12, SolydXK on a Raspberry Pi, SysV init development|
|• Issue 755 (2018-03-19): Learning with ArchMerge and Linux Academy, Librem 5 runs Plasma Mobile, Cinnamon gets performance boost|
|• Issue 754 (2018-03-12): Reviewing Sabayon and Antergos, the growing Linux kernel, BSDs getting CPU bug fixes, Manjaro builds for ARM devices|
|• Issue 753 (2018-03-05): Enso OS 0.2, KDE Plasma 5.12 features, MX Linux prepares new features, interview with MidnightBSD's founder|
|• Issue 752 (2018-02-26): OviOS 2.31, performing off-line upgrades, elementary OS's new installer, UBports gets test devices, Redcore team improves security|
|• Issue 751 (2018-02-19): DietPi 6.1, testing KDE's Plasma Mobile, Nitrux packages AppImage in default install, Solus experiments with Wayland|
|• Issue 750 (2018-02-12): Solus 3, getting Deb packages upstream to Debian, NetBSD security update, elementary OS explores AppCentre changes|
|• Issue 749 (2018-02-05): Freespire 3 and Linspire 7.0, misunderstandings about Wayland, Xorg and Mir, Korora slows release schedule, Red Hat purchases CoreOS|
|• Issue 748 (2018-01-29): siduction 2018.1.0, SolydXK 32-bit editions, building an Ubuntu robot, desktop-friendly Debian options|
|• Issue 747 (2018-01-22): Ubuntu MATE 17.10, recovering open files, creating a new distribution, KDE focusing on Wayland features|
|• Issue 746 (2018-01-15): deepin 15.5, openSUSE's YaST improvements, new Ubuntu 17.10 media, details on Spectre and Meltdown bugs|
|• Issue 745 (2018-01-08): GhostBSD 11.1, Linspire and Freespire return, wide-spread CPU bugs patched, adding AppImage launchers to the application menu|
|• Issue 744 (2018-01-01): MX Linux 17, Ubuntu pulls media over BIOS bug, PureOS gets endorsed by the FSF, openSUSE plays with kernel boot splash screens|
|• Issue 743 (2017-12-18): Daphile 17.09, tools for rescuing files, Fedora Modular Server delayed, Sparky adds ARM support, Slax to better support wireless networking|
|• Issue 742 (2017-12-11): heads 0.3.1, improvements coming to Tails, Void tutorials, Ubuntu phasing out Python 2, manipulating images from the command line|
|• Issue 741 (2017-12-04): Pop!_OS 17.10, openSUSE Tumbleweed snapshots, installing Q4OS on a Windows partition, using the at command|
|• Issue 740 (2017-11-27): Artix Linux, Unity spin of Ubuntu, Nitrux swaps Snaps for AppImage, getting better battery life on Linux|
|• Issue 739 (2017-11-20): Fedora 27, cross-distro software ports, Ubuntu on Samsung phones, Red Hat supports ARM, Parabola continues 32-bit support|
|• Issue 738 (2017-11-13): SparkyLinux 5.1, rumours about spyware, Slax considers init software, Arch drops 32-bit packages, overview of LineageOS|
|• Issue 737 (2017-11-06): BeeFree OS 18.1.2, quick tips to fix common problems, Slax returning, Solus plans MATE and software management improvements|
|• Issue 736 (2017-10-30): Ubuntu 17.10, "what if" security questions, Linux Mint to support Flatpak, NetBSD kernel memory protection|
|• Issue 735 (2017-10-23): ArchLabs Minimo, building software with Ravenports, WPA security patch, Parabola creates OpenRC spin|
|• Issue 734 (2017-10-16): Star 1.0.1, running the Linux-libre kernel, Ubuntu MATE experiments with snaps, Debian releases new install media, Purism reaches funding goal|
|• Full list of all issues|
|Random Distribution |
rPath Linux was a Linux distribution built with the new Conary distributed software management system. Conary was designed, based on many years of Linux software packaging and distribution development experience, to automate many of the tasks that have made it difficult to build Linux distributions. rPath's mission was to provide system software that was easily tailored to suit unique application needs. rPath Linux, built with the Conary distributed software management system, was not only a distribution in its own right, but also a base technology explicitly designed to enable you to create purpose-built operating system images using the rBuilder Online technology.