| DistroWatch Weekly
|DistroWatch Weekly, Issue 581, 20 October 2014
Welcome to this year's 42nd issue of DistroWatch Weekly! The world of technology changes at a remarkable rate and, in this rapid stream of progress it can be difficult to know how to stay secure. This week we turn our attention to the Qubes OS project which has an interesting approach to keeping our computers secure and our information private. This week we continue our discussion on rolling-release distributions and their reliability. Find out below which distributions are running smoothly and which ones are experiencing problems. Another rolling-release, SparkyLinux, is also in the spotlight in a first impressions review this week. Read on to find out how the Debian-based project performs. In the News section this week we share graphics improvements coming to Fedora via new drivers and to Kubuntu through the KDE desktop. We also share the highlights of FreeBSD's quarterly status report and talk about Debian's massive archive of packages and how the project plans to store the growing mountain of data. Plus, we discuss Debian's debate over whether to allow users to choose their preferred init system. As usual, we bring you the distribution releases of the past week and look forward to fun, new releases to come. We wish you all a fantastic week and happy reading!
|Feature Story (by Jesse Smith)
Since my time with Qubes was cut quite short I turned my attention to another project. SparkyLinux 3.5 was released a few weeks ago and I thought the Debian-based distribution looked interesting. According to the project's website, "SparkyLinux is a lightweight, fast and simple Linux distribution designed for both old and new computers featuring customized Enlightenment and LXDE desktops. It has been built on the "testing" branch of Debian GNU/Linux. SparkyLinux is available for i486 and x86_64 machines." SparkyLinux (hereafter referred to as Sparky) is available in several editions. At the time of writing there are 32-bit and 64-bit builds of LXDE, Enlightenment, MATE, Razor-qt, Xfce, Openbox and JWM editions. I opted to download the 64-bit build of the MATE edition of SparkyLinux. The ISO file we download is approximately 1.5 GB in size.
Booting from the SparkyLinux media brings up a menu where we can choose to run a live desktop environment with one of several languages. Once we select our preferred language we are brought to the MATE desktop environment. At the top of the display we find the application menu along with two menus for accessing directories and system settings. At the bottom of the screen we find a quick launch bar filled with popular open source applications. Over to the right side of the display we find a panel showing system status information. This panel displays network activity, memory usage statistics, current CPU usage and a short list of running processes. The wallpaper and, in fact, most of the controls and icons are drawn in shades of grey. As everything appeared to be working properly I turned my attention to the project's system installer.
SparkyLinux' graphical system installer appears to be the same one used by Linux Mint Debian Edition. We are walked thought a series of screens where we are asked to select our preferred language from a list, pick our time zone from a map of the world and we are asked to confirm our keyboard's layout. The next screen asks us to create a user account for ourselves. Next the installer offers to automatically set up disk partitions for us. By default SparkyLinux will create two partitions, one for our operating system and another for swap space. We can choose, at this time, to click a button to launch the GParted partition manager. Using GParted we can arrange our disk the way we like and then return to SparkyLinux' installer. Back on the partition management screen we are asked to click on partitions to assign them mount points, such as "/" and "/home". Next, we are asked to confirm whether we would like to install a boot loader on our computer and, assuming we do want a new boot loader, we are asked where it should be placed. The system installer then shows us what actions it will take and waits for us to confirm before it begins copying files to our hard drive. Once the installer has finished setting up SparkyLinux on our computer we are asked to reboot the machine.
Booting our new copy of SparkyLinux brings up a graphical login screen. Like the rest of the distribution the login screen is decorated in grey. Signing into our user account brings us back to the MATE desktop. Upon logging in I found there was no welcome screen or other pop-ups. Apart from the Conky status panel on the right side of the screen, the MATE desktop remains calm and empty. In the upper-right corner of the display I noticed an icon which I suspected indicated the availability of software updates. Clicking on this icon gives us the option of either opening the Synaptic package manager or opening a program called APTus.
SparkyLinux 3.5 - managing software packages with APTus
(full image size: 861kB, screen resolution 1280x1024 pixels)
APTus is a simple graphical front end to package management which focuses on providing users with an easy way to update software, fix broken packages and clear the package cache. The APTus window is divided into tabs, each tab containing modules of similar functionality. For example, there are tabs for accessing update features, repair features, adding new packages and removing unwanted software. I found APTus did a nice job as far as gathering new updates was concerned. Adding or removing packages is a bit less user friendly as trying to add/remove a package requires typing in the name of the package we wish to manipulate. APTus does not display lists of available packages and this makes it better suited to general actions, such as updating all software or clearing the cache of stale files. I used APTus mostly for performing updates and found that it worked well enough. Whenever we perform an action from APTus's interface a new terminal window opens and we see the appropriate APT command executed in command line fashion. When the action completes we are returned to the APTus window.
While APTus has its uses, I found the Synaptic graphical package manager was usually my preferred tool for managing software. Synaptic presents a fairly simple interface where we are shown an alphabetical list of available software packages. Clicking a checkbox next to a package allows us to install, remove or upgrade the package. Synaptic works quickly and allows us to create batches of actions to perform. SparkyLinux pulls much of its software from the Debian Testing repositories. The project also maintains its own repository for some custom items. Digging through the APT configuration files I found SparkyLinux has the ability to pull software from a number of third-party repositories, including one maintained by Google, another for PlayOnLinux and there are some personal package archives (PPA) too. These third-party repositories were disabled on my system, but could be activated to provide additional applications. The first day I used SparkyLinux there were 237 software packages which could be upgraded and these totalled 250 MB in size. All packages downloaded and installed without any problems.
SparkyLinux ships with a collection of useful software. Included in the distribution are the Iceweasel web browser (with an accompanying Flash player), the Pidgin instant messaging client, the Transmission bittorrent client, the XChat IRC client and the gFTP file transfer application. The LibreOffice productivity suite is installed for us along with a document viewer, the Camorama webcam viewer, the GNU Image Manipulation Program and a collection of small games. The distribution provides users with the Exaile audio player, the VLC multimedia player and a YouTube video browser. We are also given a collection of media codecs which allow us to play a wide range of multimedia files. SparkyLinux ships with the Xfburn optical disc burning application, the Midnight Commander terminal file manager, a system monitor and the Caja graphical file manager.
SparkyLinux further provides an archive manager, a text editor and a virtual calculator. The MATE desktop comes with a Control Centre application which acts as a hub for configuring the desktop and parts of the underlying operating system. The distribution provides Network Manager to help us get on-line. SparkyLinux additionally ships with a virtual keyboard, the WINE compatibility software that allows us to run Windows applications, Java and the GNU Compiler Collection. I found SparkyLinux ships with the 3.14 version of the Linux kernel and the distribution runs an e-mail server in the background.
SparkyLinux 3.5 - working with system services
(full image size: 302kB, screen resolution 1280x1024 pixels)
While most applications ran very well for me, I had mixed results while working with the project's Control Centre. Many modules of the Control Centre, those which dealt with the look and feel of the MATE desktop, worked well. I could change the desktop's appearance and alter which programs were launched when I logged in, for example. On the other hand, modules which handled the underlying operating system usually would not work. For instance, the user account manager, the services manager and Synaptic would not launch from the Control Centre. The systemd services manager front end would load and display the status of services, but I could not start/stop services or even refresh the list of running services.
Likewise the Device Driver Manager refused to load, claiming it could not be run from live media (though at this time I was running my local copy of SparkyLinux). I suspect the problem lies in the fact the modules which did not work all required administrative rights. My regular user account did not have admin access and the modules in the Control Centre do not prompt for the administrator's password when they are launched. This meant I either had to login as root to perform administrative tasks or manipulate SparkyLinux from the command line where I could use the su command to gain administrative access.
I tried running SparkyLinux on a physical desktop computer and in a VirtualBox virtual machine. In both environments the distribution performed well. The MATE desktop was very responsive and the distribution performed actions quickly. I found MATE looked quite bland with the default theme, but I was able to add a splash of colour through the distribution's Control Centre. SparkyLinux does not require a lot of resources and I found the distribution could run the MATE desktop with 270MB of RAM. When running on physical hardware SparkyLinux properly detected my screen resolution, sound worked out of the box and networking was set up automatically. When running in the virtual environment SparkyLinux provided similar, good results and good performance.
SparkyLinux 3.5 - changing the look of the MATE desktop
(full image size: 733kB, screen resolution 1280x1024 pixels)
About halfway through my week with the distribution I downloaded a second round of updates. The next time I booted into SparkyLinux I noticed the login screen's background was blank, a plain black instead of shades of grey. When I logged in I noticed several problems. There was no top panel on the MATE desktop, there was no quick-launch panel available and no application menu. The wallpaper had changed to a sort of rainbow pattern. I opened a virtual terminal by right-clicking on the desktop and found SparkyLinux was thrashing my hard drive and the MATE-panel process was taking up all available CPU cycles.
I killed the MATE-panel process and CPU usage returned to normal, but my desktop was still empty and decorated with odd colours. When I attempted to run MATE-panel from the command line a message appeared indicating the package was probably broken and that I could run a command to restore functionality. The provided command did not exist on my system and searches in the software repositories did not find a match. I also found my window manager no longer worked and running any graphical applications caused windows to pile up in the upper-left corner of the screen. After a time of trying to find a solution I decided I had reached the limit of what most users could be expected to attempt and brought my trial to an end.
Despite my time with SparkyLinux coming to an early close I found a good deal to recommend the distribution. SparkyLinux is easy to install, thanks to a pleasant graphical system installer. The distribution features a responsive desktop environment, it boots quickly and properly handled my hardware. SparkyLinux features relatively low resource usage and ships with a good selection of quality open source applications.
On the other hand I ran into several issues while playing with SparkyLinux. Many of the Control Centre modules did not work, probably because they did not prompt for administrator access. This means users must make the choice between logging into a graphical environment as root (not a recommended practice) or we need to manage the operating system from the command line, a practice that will turn off many users. The default desktop environment, with its heavy usage of grey, struck me as depressing. That's just my opinion and some people might like the plain grey theme, but I quickly decorated the desktop in more festive colours. Mostly though my concern with SparkyLinux is that an update broke my desktop after just three days. SparkyLinux' parent distribution, Debian Testing, has a well earned reputation for stability and I was surprised to see a package break, especially this close to Debian's upcoming feature freeze.
SparkyLinux 3.5 - typing with the on-screen keyboard
(full image size: 231kB, screen resolution 1280x1024 pixels)
All in all, SparkyLinux does some things well. It is fast and friendly in most aspects. However, some problems with admin modules and the distribution's style of package management will probably turn away novice Linux users. SparkyLinux may be a good choice for people who want to play with Debian Testing and run a lightweight desktop. All of SparkyLinux' editions feature low-resource desktop environments and I suspect the distribution will suit people running on older hardware, so long as they don't mind keeping up with a rolling repository of software.
* * * * *
Qubes OS 2
Several people wrote to me a few weeks ago and asked if I would review Qubes OS. The Qubes project recently released version 2 of their security-oriented operating system and I was happy to give this unusual project a try. Qubes runs Linux software, but it is not exactly a Linux distribution. As the project's website states "If you really want to call it a distribution, then it's more of a Xen distribution than a Linux one. But Qubes is much more than just Xen packaging. It has its own VM management infrastructure, with support for template VMs, centralized VM updating, etc. It also has a very unique GUI virtualization infrastructure."
The Qubes project implements what is called "security by isolation". There are a few different approaches to security in operating systems. Some projects, such as OpenBSD, attempt to create clean, bug-free code which is difficult to exploit. Attempting to avoid problems using high quality code and good design is called "security by correctness". Other projects attempt to hide details of their inner workings (often by not sharing their source code) and this is called "security by obscurity". What Qubes does is attempt to separate components into different containers. The idea behind the isolation approach is that modern operating systems contain many components and these components are often complex. It is not realistic then to assume every component can be properly audited to make sure it works correctly and cannot be compromised. Rather than try to make sure all of the thousands of components running on our computers work correctly and are secure themselves, Qubes isolates these components so that one misbehaving (or compromised) application is not a threat to the rest of the system or our data.
Using Qubes we can set up different security zones and the idea is applications and data stay within these zones. We might use one zone for banking and buying items on-line, another zone for playing games or casual web browsing and a third zone for work. Keeping our activities compartmentalized prevents our casual web browsing from placing our confidential work information at risk. It might be easiest to think of each zone as a lightweight virtual machine, a separate quarantined area.
I feel it is important to note Qubes is only available as a 64-bit build for x86 machines and Qubes does not strive to be a multi-user operating system. "Qubes does not pretend to be a multi-user system. Qubes assumes that the user who controls Dom0 controls the whole system. It would be very difficult to securely implement multi-user support."
The download for Qubes is approximately 3 GB in size. Booting from this media brought up a menu offering to either launch the installer or test the media and then launch the installer. Once the media check has completed we are brought to a text console where I was told the operating system could not launch the X display server. Instead the text-based version of the Anaconda system installer launches and shows us a hub menu. We access each node of the hub one at a time, providing information to the installer. Some items we are asked to provide include the time zone, the location of the source media (an ISO file, DVD or network location).
We are asked which hard drive to install Qubes on and whether to use available free space or take over a portion of the disk. We can choose to install Qubes on a standard partition, a LVM volume or using Btrfs. We are also asked to create a password for our administrative user account and create a regular user account for ourselves. When this information had been entered and I chose to proceed the installer crashed and offered to send a bug report. I went back through the installer a few more times, taking different install options. I tried different partition layouts, a different desktop environment (Xfce and KDE are available) and I tried installing Qubes on a second machine. In each case the system installer crashed before it could finish copying its files to my hard drive.
Qubes carries an interesting idea, one which I suspect is fairly practical. With modern, complex operating systems it does not make sense to assume all the programs we run will be secure and unexploitable. Nor does it make sense to think vulnerabilities can hide from today's exploit kits. Isolating processes, sandboxing applications and limiting access seem to be the most reasonable approaches to security today. For that reason I quite admire what Qubes is trying to do. I'm sorry to say I have not been able to get Qubes running in my test environments, either on physical hardware or in a virtual machine.
* * * * *
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.8 GHz AMD A4-3420 APU
- Storage: 500 GB Hitachi hard drive
- Memory: 6 GB of RAM
- Networking: Realtek RTL8111 wired network card
- Display: AMD Radeon HD 6410D video card
|Miscellaneous News (by Jesse Smith and Ladislav Bodnar)
Fedora gets updated graphics software, FreeBSD shares quarterly report, Kubuntu supplies demo of KDE's Plasma 5.1, Debian's package archive finds new home, compiling Android ROMs, sneak peak at OpenBSD 5.6
With the release of Fedora 21 planned for later this year, the developers are eager to share some of the improvements coming to the Red Hat sponsored project. A post on Fedora Magazine shares some of the improvements coming to Fedora's graphics software. Fedora includes support for several additional video cards, logging X output via systemd, improved power management and multi-GPU laptops. From the article: "Mesa is a collection of open source libraries that implement the OpenGL API, and also contains the 3D drivers for Fedora. Mesa in Fedora 21 is updated to version 10.3 (Fedora 20 shipped version 9.2.3) This updated version of Mesa provides support for OpenGL 3.3 for many cards, including: NVIDIA GeForce 8 and newer, AMD Radeon HD2000 and newer, and the Intel HD Graphics featured in the Ivybridge and Haswell chipsets."
* * * * *
The FreeBSD project released its quarterly status report last week. The FreeBSD developers have certainly been busy and the report covers a great deal of information. Key elements include the status of the bhyve hypervisor, booting with UEFI support, running FreeBSD on boards with ARM processors and various desktop environments. The report also highlights new documentation added to the FreeBSD Handbook, including chapters on ezjail and working with ZFS storage pools.
* * * * *
Last week we shared a report of GNOME's progress in supporting Wayland. This week we share the KDE project's progress in supporting Wayland and other advancements. KDE's Plasma 5.1 was launched recently and it comes with several new features: "Those travelling regularly will enjoy better support for time zones in the panel's clock, while those staying at home a revamped clipboard manager, allowing you to easily get at your past clipboard's content. The Breeze widget style is now also available for Qt4-based applications, leading to greater consistency across applications. The work to support Wayland as display server for Plasma is still ongoing, with improved, but not complete support in 5.1. Changes throughout many default components improve accessibility for visually impaired users by adding support for screen readers and improved keyboard navigation. Aside from the visual improvements and the work on features, the focus of this release lies also on stability and performance improvements." The announcement includes links to Kubuntu ISO images which include snapshots of the new Plasma release.
* * * * *
Have you ever wanted to compile an Android ROM right on your desktop machine, but didn't know how to accomplish the task? Well, things have become a lot easier thanks to some interesting work by Nathan Fry who emailed DistroWatch last week: "I'd like to submit my project - Builduntu. It's a preconfigured compiling environment for Android ROMs. I felt there was a disconnect between the skill level required to set up Linux and that needed to start compiling ROMs from source, so I created both a virtual machine and a customized ISO image." The Builduntu install disc is a customised build of the Ubuntu 14.04 release: "Builduntu is a custom branch of the Ubuntu operating system, based on my guide here for preparing Ubuntu 14.04 to compile Android ROMs from source. It includes everything you need to sync with the repository of your choice (Cyanogenmod, AOKP, AOSP, etc) and start building." A Builduntu virtual machine which provides a way of compiling Android ROMs on Linux, Windows and OS X is also available.
* * * * *
The Debian GNU/Linux distribution is one of the largest open source projects in the world and also one of the oldest. With numerous branches, multiple repositories, thousands of packages and many ports, Debian requires a great deal of storage space. According to this post on the project's website, Debian's archive grows at a rate of about 5 TB per year. For a not for profit project, that represents a lot of storage space and a lot of bandwidth. Luca Filipozzi, a core member of the Debian system administration team says: "There are thousands of Debian software packages on the snapshot platform. It contains twenty years of history captured in a single place. If developers don't have a local repository available, they can easily find an old version from years ago, which makes the archive a valuable asset to them. But to have it all available online on a global base is a big request for most hosting providers." Enter LeaseWeb, a hosting provider who says Debian installs make up about a quarter of their client base and they want to support the popular Debian distribution. LeaseWeb has offered to host Debian's growing archive, free of charge, for at least three years.
Earlier this year the Debian distribution made the choice to adopt systemd as the new init software for Debian GNU/Linux. The choice to change init software was a controversial one and, while it appears systemd is going to stay the default for Debian, some developers are pushing to keep alternative options alive. Ian Jackson has put forward a proposal in which he calls for freedom of choice. He writes: "Debian has decided (via the technical committee) to change its default init system for the next release. The technical committee decided not to decide about the question of "coupling" i.e. whether other packages in Debian may depend on a particular init system. This GR seeks to preserve the freedom of our users now to select an init system of their choice, and the project's freedom to select a different init system in the future." While some Debian developers support the proposal, others are concerned that introducing new changes will throw off Debian's schedule and upcoming feature freeze.
* * * * *
Finally, a link to a sneak peak at the upcoming release of OpenBSD 5.6 (scheduled for arrival on 1 November), courtesy of OpenBSD developer Lawrence Teo: "OpenBSD 5.6 is of course the first OpenBSD release with LibreSSL, the now-famous fork of the OpenSSL library. But while LibreSSL is an important milestone for OpenBSD, there are many other things in the OpenBSD 5.6 release that warrant attention as well. The developers are still busy preparing the OpenBSD 5.6 release notes. Meanwhile, if you're curious about what's new in OpenBSD 5.6, you can get a sneak peek from various places on the Internet if you know where to look! I would like to highlight three places in particular. The first place to look at is the big list of changes between OpenBSD 5.5 and 5.6 that has been painstakingly compiled by Brett Mahar throughout the development cycle. I think Brett does an amazing job of collating all this information together for every release! I have no idea how he manages to go through every source-changes@ post to produce this list so consistently."
|Rolling-release trial (by Jesse Smith)
Rolling-release experiment - week two
My trial with rolling-release distributions got off to a good start last week. Granted, there were some minor quirks early on. For example, I noticed right away PCLinuxOS was going to need more than the recommended 10GB of hard drive space for a prolonged trial and performed a re-install on my first day to give the distribution more disk space. I had a desktop panel disappear briefly on my copy of PC-BSD and I had to modify my initial configuration of Arch Linux a little to get it to connect to the Internet. Still, nothing went badly, nothing outright broke during the initial stages of my trial to see how these rolling-release distributions would function. One week in, it was time to upgrade all five distributions and see how each one performed. Here is what happened:
* * * * *
The first operating system in my trial to be updated was PC-BSD. I booted up the machine and immediately took note of the fact an icon in the system tray indicated software updates were available. I opened the update manager and it did its own check for updates. The update manager soon told me it could find no new packages and my system was declared up to date.
I was a bit puzzled at the system tray icon telling me one thing while the update manager said another. After manually taking a snapshot of my current file system using PC-BSD's boot manager, I turned to the command line. Using the pkg command line package manager, I checked for updates and found a total of 100 new packages were waiting for me, totalling 200MB in size. I'm not sure why pkg saw these while the update manager did not, but I attempted to download the entire lot. Most packages updated cleanly, but several packages relating to the operating system's Linux compatibility layer would not install. As it turned out, PC-BSD recently updated their Linux compatibility software, transitioning from using Fedora 10 to CentOS 6 as their foundation. This caused some conflicts during the upgrade process.
I soon found this post in the PC-BSD development mailing list which explained how to properly upgrade from the Fedora-based packages to the CentOS-based packages. The instructions provided worked for me with no problems and I soon had a fully up to date PC-BSD Edge system. After a reboot, I checked to make sure all my applications were working properly and found no problems had developed following the upgrade.
* * * * *
Debian GNU/Linux "Sid"
The next project on my list was Debian GNU/Linux "Sid". I booted into Debian and, using the apt-get command line package manager, discovered 142 packages were waiting for me, totalling 189MB in size. The waiting packages downloaded quickly and installed cleanly. I made sure I could still boot into the system and that my applications continued to work and found Debian continued to perform without any problems.
I had similar experiences with both PCLinuxOS and Arch Linux this week. When I fired up PCLinuxOS and opened the Synaptic package manager I found just two new packages waiting for me, their size coming to 1MB in total. Synaptic downloaded both packages and these updates had no visible affect on my installation of PCLinuxOS.
My experience with updating Arch Linux was about the same. Using Arch's pacman command-line package manager, I found just ten new updates waiting for me, totalling 20 MB in size. The pacman utility downloaded these updates and applied them with no problems. My Arch installation continued to work as before.
* * * * *
Of the upgrades I performed this week, I had the most trouble with openSUSE "Factory". When I launched openSUSE and went into the YaST control panel my check for new packages showed no updates were available. Closing YaST, I turned to the zypper command line package manager. The zypper program reported it could not perform any actions on packages as PackageKit had locked the package database. The zypper program offered to close PackageKit for me, but when I asked zypper to terminate PackageKit I was told PackageKit could not be made to close. I went back into YaST and went into the services manager. The services manager showed PackageKit was not running and, in fact, PackageKit was shown as being disabled. Finally, I turned to the command line and manually forced the PackageKit process to terminate.
After PackageKit was out of the way, zypper was able to create a file system snapshot for me and download the available updates. There were 1,463 updated packages waiting for me in Factory's repositories, just five days after my previous upgrade had been performed. These updates totalled 1.25 GB in size. I got about halfway through the upgrade process when zypper reported it could not continue as it had run out of disk space. Originally, I had set up openSUSE on a 8 GB partition, usually enough for a fixed-point release. However, the operating system required around 5 GB and the upgrade process would need at least 4 GB on top of that.
Luckily, openSUSE defaults to using the Btr file system and it is beautifully easy to add a new storage device to systems running Btrfs. With a second 8GB disk handed to openSUSE, zypper was able to resume its upgrade process. Once the upgrade had finished, a few hours later, I found I could still login to KDE and my applications still worked. There were a few changes to the way openSUSE looked. There were new icons on the desktop for launching Firefox, LibreOffice, for bringing up hardware information and for accessing on-line help. Some icons in the system tray also looked different after the upgrade. Still, in the end, everything worked.
* * * * *
While most of the operating systems in my trial upgraded without serious problems this week, there were two minor issues. One was that the update managers of both PC-BSD and openSUSE failed to recognize available updates and forced me to switch to working from the command line. This is a relatively minor issue. What I am quickly finding though is rolling-release operating systems require a good deal more hard drive space than fixed point releases. In most of my week-long trials I provide operating systems with 8 GB of disk space and this supplies them with enough space for the operating system and swap space. However, in my trial with rolling-releases I've had to re-install PCLinuxOS on a 16 GB partition as 10 GB just was not enough.
PC-BSD recommends at least 50 GB to function on an on-going basis (though PC-BSD has only used about 6 GB to date) and I am finding openSUSE requires at least 10 GB of space, just for the first wave of updates. I suspect once file system snapshots begin to accumulate, the space requirements of openSUSE and PC-BSD will grow. Originally, I installed Arch on a 8GB partition and that drive threatens to overflow if I don't regularly clean its cache. Only Debian, so far, has maintained a small footprint, requiring less than 4 GB of hard disk space.
|Released Last Week
Scientific Linux 7.0
Pat Riehecky has announced the release of Scientific Linux 7.0, a distribution compiled from the source code for Red Hat Enterprise Linux 7: "Scientific Linux 7.0 x86_64 released." Scientific Linux differs from Red Hat Enterprise Linux and CentOS in that the project enhances the system with extra software applications and utilities: "elrepo-release - this package contains the ELRepo driver yum repo and GPG key; epel-release - this package contains the EPEL driver yum repo and GPG key; OpenAFS - this package contains the OpenAFS driver and client utilities; SL_gdm_no_user_list - this package will disable the GDM user list in the chooser; SL_enable_serialconsole - will setup a serial console for login; SL_no_colorls - will disable the automatic colorized ls output; sl-bookmarks - replaces redhat-bookmarks and removes upstream branding...." Read the brief release announcement and check out the more detailed release notes for further information.
Scientific Linux 7.0 - the project's first stable release in the 7.x series
(full image size: 623kB, screen resolution 1280x1024 pixels)
Red Hat Enterprise Linux 6.6
Red Hat, Inc. has announced the release of Red Hat Enterprise Linux (RHEL) 6.6, the sixth update in the 6.x series of Red Hat's enterprise-class Linux distribution: "The Red Hat Enterprise Linux team is pleased to announce the release of Red Hat Enterprise Linux 6.6, the latest version of our Red Hat Enterprise Linux 6 platform. With the release of Red Hat Enterprise Linux 6.6, we continue to refine the stable and secure Red Hat Enterprise Linux 6 platform which provides a reliable foundation for mission-critical systems across industries and regions. Red Hat Enterprise Linux 6.6 delivers a variety of improvements that provide increased system performance across physical, virtual, and cloud environments. These optimizations and tuning improvements include: kernel locking improvements to allow for more efficient CPU utilization on large NUMA systems...." Read the release announcement and consult the comprehensive release notes for further information.
IPFire 2.15 Core 84
Michael Tremer has announced the release of IPFire 2.15 Core 84, a new stable release of the specialist distribution designed for firewalls: "This is the official release announcement for IPFire 2.15 Core Update 84. This is a release that fixes some security issues in the GNU Bash package which are commonly known as 'Shellshock' and it comes with more fixes and minor feature enhancements. As you may have already seen on the news, the Shellshock issues made more people look into the code of the default shell of many *nix systems. Those people found many more programming errors and provided fixes for them which have been applied in this release. IPFire is now shipping GNU Bash 4.3.30 and the companion library readline in version 6.3. There have been some denial of service issues in the Squid web proxy which have been fixed in release 3.4.8. Those are of minor severity only and quite possibly cannot be exploited to inject code. The firewall got a couple of new features which I explained in detail in a post on the IPFire planet." Read the rest of the release announcement for a more detailed changelog.
Peter Manev has announced the release of SELKS 1.0, the inaugural version from the project developing a specialist Debian-based distribution that ships with a variety of pre-configured network security management tools: "Stamus Networks is proud to announce the availability of the SELKS 1.0 stable release. SELKS is both live and installable network security management ISO image, based on Debian GNU/Linux, implementing and focusing on a complete and ready-to-use Suricata IDS/IPS ecosystem with its own graphic rule manager. SELKS is comprised of the following major components: Suricata IDPS, Elasticsearch, Logstash, Kibana and Scirius. It offers proven, powerful, innovative and scalable open-source multi-threading technologies in a bundle. SELKS 1.0 comes with 10 pre-installed Kibana IDS/NSM dashboards. They cover analysis of the Suricata alerts and events with per-protocol dashboards (Alerts, HTTP, Flow, SSH, TLS, DNS)." Read the full release announcement for more details and screenshots.
SELKS 1.0 - a Debian-based distribution with network security tools
(full image size: 246kB, screen resolution 1280x1024 pixels)
Tails 1.2 has been released. Tails is a Debian-based live distribution developed with the goal of preserving privacy and anonymity of users on the Internet. From the release announcement: "Tails, The Amnesic Incognito Live System, version 1.2, is out. This release fixes numerous security issues and all users must upgrade as soon as possible. Major new features: install (most of) the Tor browser, replacing our previous Iceweasel-based browser, the version installed is from TBB 4.0 and is based on Firefox 31.2.0esr, this fixes the POODLE vulnerability; upgrade Tor to 0.2.5.8-rc; confine several important applications with AppArmor. Bug fixes: install Linux kernel 3.16.5. Minor improvements: upgrade I2P to 0.9.15 and isolate I2P traffic from the Tor Browser by adding a dedicated I2P Browser, also, start I2P automatically upon network connection, when the i2p boot option is added; make it clear that TrueCrypt will be removed in Tails 1.2.1 and document how to open TrueCrypt volumes with cryptsetup."
Arnault Perret has announced the release of HandyLinux 1.7, a novice-friendly distribution that features an intuitive start menu with application launchers and Internet bookmarks - based on the stable Debian GNU/Linux 7.0. According to the release announcement (in French only, even though the distribution supports English besides the default French language) the major change in this release is the replacement of Google's Chromium browser with GNU Iceweasel. The HandyMenu application, the distribution's main feature, has been upgraded to version 2.3; it sees the Facebook button is gone, replaced by a link to Framasoft's free services. Some of the other items in the changelog include: redesign of the browser's start page; addition of gpart and Yelp; clean-up of documentation files; addition of "social launchers" for direct access to popular social sites; addition of the Diaspora launcher; software updates to Debian 7.7.
HandyLinux 1.7 - a Debian-based distribution featuring the HandyMenu launcher
(full image size: 676kB, screen resolution 1280x1024 pixels)
* * * * *
Development, unannounced and minor bug-fix releases
|Upcoming Releases and Announcements
Summary of expected upcoming releases
Distributions added to database|
* * * * *
Distributions added to waiting list
- Community Linux. Community Linux is a live desktop distribution designed to be run from USB thumb drives.
- Cumulus Linux. Cumulus Linux is a networking focused Linux distribution based on Debian and it offers the entirety of the Linux experience on networking hardware.
* * * * *
DistroWatch database summary
* * * * *
This concludes this week's issue of DistroWatch Weekly. The next instalment will be published on Monday, 27 October 2014. 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)
- Bruce Patterson (feedback and suggestions: podcast edition)
|Linux Foundation Training
|Reader Comments • Jump to last comment
1 • Hard drive space (by salparadise on 2014-10-20 09:30:20 GMT from United Kingdom) |
I had Slackware installed on a 20GB partition. It takes up about 5-6GB 'out of the box'. However, I noticed that whilst running a series of slackbuild scripts to add stuff to the install, that I quickly ran out of space and had to purge /tmp to get the space back. Currently using a 30GFB partition and so far, everything has been OK. It helps to save a copy of the resultant .tgz packages to somewhere safe so they can be installed without having to build them again on subsequent installs.
2 • Sparky Review (by Anna Merikin on 2014-10-20 09:44:39 GMT from United States)
Great review! Sparky behaved exactly the same for me: on the first update, the OS failed to recognize or activate (no lights) my network card. Without it, of course, no fix could be downloaded.
Sparky seems to break on some updates.
3 • Arch installation and network (by awa on 2014-10-20 10:32:25 GMT from Spain)
One thing on the Arch network issue: did you configure network again once you chrooted after base system installation?
According to the beginner's guide you have to do this.
4 • Re:Debian init drama (by cykodrone on 2014-10-20 11:39:23 GMT from Canada)
Now I'm getting confused (which isn't too hard to do, lol), so are individual packages supposed to be developer maintained to support both major inits or is Debian going to tailor two diff install disks? In other words, Debian after developer tweaking to suit both inits for two diff systems/installers or is that pain in the rear developer onus? My head is spinning.
Off topic, I dumped a certain proprietary OS over 4 years ago, now I dumped two major hardware vendors cuz of their 'tudes towards Linux and their prices. I just built me an octi-core beast, running Debian stable (with bpo cheating) on a dual SSD 6GB/s ('SATA3') Raid 0, I benched it, I now have read speeds of 1.1GB/s and write of over 600MB/s.
5 • Rolling releases review (by Robert Schiele on 2014-10-20 12:47:16 GMT from United States)
Back when Jesse wrote that he was going to begin his experiment of testing rolling releases, I posted here to point out that Debian Testing is NOT a rolling release, that it is not offered as such (and has never been), and that breakages in it (per Debian) are not only to be expected from time to time but may even occur with some frequency as Testing has never been intended to be run by casual users at all--certainly not on a production machine.
Then today in Jesse's update on his experiment, I saw this quote "SparkyLinux' parent distribution, Debian Testing, has a well earned reputation for stability..." and I thought I would have another try. No, Debian Testing does NOT have a reputation (well earned or otherwise) for stability. Nothing could be further from the truth; in fact, quite the opposite is true. Debian's Stable release (currently "Wheezy") is indeed rock-solid stable as Debian's releases have always been. That's why the Stable branch is all that is ever given an official release. It's also why Stable is called Stable, and why Testing is called Testing. Duh. Go figure.
I love reading Jesse's posts, and clearly he knows more about Gnu/Linux and other free software distros than many people. Why he can't seem to grasp this, as posted above, I cannot understand. Is it that he simply refuses to understand, because the truth doesn't suit his own agenda? Call me a crotchety old duffer if you like. I am. But I've noticed increasingly over the years that all too many younger people seem to think they can create their own personal reality, their own personal world, if you prefer, by simply claiming that such-and-such is so, all facts and evidence to the contrary. I can only think that that is what is going on here. Go out and buy yourself a cheap old clunker of a used car with the idea that it will somehow fly you to Mars. Stick to that belief no matter what, and see what happens. IMHO, that is what is happening here.
6 • Debian vs. Systemd (by Microlinux on 2014-10-20 13:04:16 GMT from France)
Now it starts to get interesting: http://debianfork.org/
7 • re 6 (by cornelius on 2014-10-20 13:37:07 GMT from Canada)
It's not Debian vs. Systemd. It's actually Debian featuring Systemd.
What's the big deal about it? A lot of forks happen for no good reason all the time. It's typical for Linux.
8 • a (by a on 2014-10-20 15:01:47 GMT from France)
Thanks for the link Microlinux! If they fork debian it could be my next distro. I haven’t found any good distro without systemd :(.
9 • debian fork (by salparadise on 2014-10-20 15:30:06 GMT from United Kingdom)
Now this is seriously good news. And it will send a message that few will be able to ignore - that systemd is garbage, its developers are spoiled children and its presence threatens Linux in a way that is not going to be tolerated.
10 • How controversy encourages evolution (by Bill Savoie on 2014-10-20 15:41:29 GMT from United States)
Jesse gave us his impressions from his Linux History, of another distribution (Sparky). He did not test the main branch (main edition – lightweight & fast LXDE desktop) or the second branch (Enlightenment) but one of the newer branches (MATE). Therefore we can all figure out that some of the integration is not as polished as it might have been with LXDE. That being said, in the past 5 years I have not tried many different Linux versions. Mostly I spend time with OpenSuse. But I did enjoy his drive through the Linux country that is called Sparky.
The idea of 'rolling release' is a tricky one. It means different things to different people. For some it means no gate keeping, no interlocking board of review. which might just make the idea of release less daunting to the developers. It might also mean getting more unsuspecting testers engaged. (Ouch) A developer might not have 5 different computers to test with, so bugs get pushed out to a little hardware market. If you have a computer with an odd assortment of interfaces, you might need to actually become a developer to make your system work well.
All this innovation, given freely by developers, creates pressure of those who wish the world were absolutely simple and unchanging. This is good and necessary for the rest of us, who look for empowerment and are willing to be engaged in bring about change. This tension is called life. We can no more take it out of Linux, than we can give up electricity. Remember electricity was once DC and AC was considered too dangerous. Now we have both. Linux has both stable and innovation.
Perhaps it feels strange to build a 'rolling release' upon a 'stable release'. The critical path might require more operator awareness, picking the right interfaces, and being willing to work through configuration issues online. Perhaps it feels strange, but then in time you might see the efficiency that it provides. This 'rolling release' is somewhat painful to the user, but a worthwhile efficiency improvement to the development process. That efficiency will trickle down to the user, and it is actually empowering.
Pain and Ouch are part of life. They don't last very long if you work to improve your software skills and are willing to spend some time communicating with others on the Internet.
The older I get, the more I enjoy Linux, and the people who want to go there and hang out. Thanks Distrowatch for allowing us to meet beyond our little preferences, beyond our little circle of people who think like we do.
Controversy encourages evolution, and we are all going there together. Even the 'Ouch' as a purpose.
11 • Sparky (by marame on 2014-10-20 16:54:49 GMT from Finland)
I have Sparky Linux Mate/XFCE on a old Compaq D310 and it is working very good. XFCE is better in reliability. Not having those problems but in Makulu Linux (Debian testing) in HP DC7600 SFF after upgrade I got black screen with only cursor. The problem is on MDM (Mint Display Manager) update and switching to LightDM helps, maybe works in Sparky Mate too. (http://makululinux.com/forums/topic/makulu-blackout/).
12 • #8 (by Microlinux on 2014-10-20 17:44:50 GMT from France)
@a: Slackware doesn't have SystemD, and it's very nice. Been using it since 2001.
13 • @11 (by jaws222 on 2014-10-20 20:19:53 GMT from United States)
"The problem is on MDM (Mint Display Manager) update and switching to LightDM helps, maybe works in Sparky Mate too"
I had the same issue this weekend with Point Linux Mate. I was able to login to the terminal and run updates but no gui. Tried Startx - no luck (not recognized). My solution was to install XFCE desktop and now I'm back in business.
14 • Debian fork (by Tacklebeery on 2014-10-20 21:54:41 GMT from Canada)
If Debian coninues with systemd, I'm "outta there" as it were. I agree with most of the arguments put forward by the systemd haters that can be found on the link posted in comment #6 and the links provided by that website. I agree with the Unix philosophy well beyond the systemd philosophy.
15 • a (by a on 2014-10-20 22:05:31 GMT from France)
@Microlinux, I’ve quickly tried Salix but didn’t like it much due to missing pieces of Xfce and missing keymaps. I’ll try Slackware to see if it’s better.
There’s also Funtoo, but installing some packages takes so much time! I’d need a faster processor at least.
16 • a (by a on 2014-10-20 22:08:43 GMT from France)
Oh, and PCLinuxOS. I had trouble running it in VirtualBox but it’s now working; I’ll have to check it further.
17 • @11 & 13 Black screen with curser (by Rev_Don on 2014-10-20 22:31:09 GMT from United States)
"The problem is on MDM (Mint Display Manager) update and switching to LightDM helps, maybe works in Sparky Mate too"
A friend of mine ran into this with Kubunut 14.04 last week. We spent several hours trying to figure it out. I had him install XFCE from a terminal to be able to get a GUI. He ended up blowing away Kubuntu and replaced it with Kwheezy which so far hasn't had any problems. Not sure it was the same underlying problem, but the symptoms were the same.
18 • @17 (by jaws222 on 2014-10-20 22:40:18 GMT from United States)
' I had him install XFCE from a terminal to be able to get a GUI"
If he still wants the KDE effects he can enter kwin --replace in the terminal. That's usually how I run XFCE.
19 • a (by a on 2014-10-20 22:58:53 GMT from France)
Oh well, Slackware also doesn’t have the bépo keymap and is thus impossible to install, because there is no graphical installer.
20 • @18 KDE/XFCE (by Rev_Don on 2014-10-20 23:48:06 GMT from United States)
"If he still wants the KDE effects he can enter kwin --replace in the terminal. That's usually how I run XFCE."
Thanks for that. He is now running Kwheezy after blowing away Kubuntu and it's running fine. Kwheezy uses KDE, not XFCE. He only installed XFCE long enough to recover some files and to see if we could fix the problem with Kubuntu. While XFCE is a fine DE (and my second favorite after Mate), he prefers KDE. And yes, he does use some of the Kwin effects.
21 • Qubes, OpenSUSE (by pekael on 2014-10-21 00:53:00 GMT from Poland)
Regarding to Qubes OS - try booting with different (older) kernel versions, the installer provides several.
When it comes to SuSE, it may be also BTRFS issue with snapper-made snapshots:
22 • Arch Evo/Lution installer (by jg on 2014-10-21 00:55:37 GMT from Poland)
After reading last week's comments, I downloaded and installed the easy Arch installer from the project's page at http://www.evolutionlinux.com/. Distrohopping from 2003, I always dreamed of a solid, stable distro with the latest, cutting (not bleeding) edge packages. I tried to install Arch several times before, but the results were either not fruitfull or very, very shortlived. This time, however, in 30 minutes I installed Arch KDE in VBox (3.5 GB RAM) on Kubuntu 14.04. I still cannot believe it is real - I install new packages, uninstall some other and so far, everything works. Applied updates 2 times - still running. I'm sure, when installing Kubuntu 14.10 I will also try to install Arch on my thinkpad. Many thanks, Distrowatch, for all the good work over the years and a BIG THANKYOU to the Evo/Lution team!
23 • Qubes OS 2.0 (by Erich Friesen on 2014-10-21 00:59:08 GMT from United States)
I've tested Qubes on several machines, and never had any issues.The laptops I've used have been Think Pads, and the desktops were Intel.
The distro/OS is really polished in the 2.0 edition. I would recommend 8 G of RAM, as there is a big overhead for the VM's.
24 • @20 (by jaws222 on 2014-10-21 01:17:39 GMT from United States)
I was actually able to get Mate back by doing the following:
1, Installed xdm from synaptic
2. ran dpkg-reconfigure xdm and chose lightdm
3. restarted and lightdm appeared - logged in as usual and Mate was back
25 • ComLin RPM-based (by Fossilizing Dinosaur on 2014-10-21 01:58:35 GMT from United States)
Community_Linux (aka ComLin) "...works like any other RPM-based Linux. It is sourced from CENTOS 6.3..."
26 • Debian fork (by Paraquat on 2014-10-21 02:26:21 GMT from Taiwan)
Wow, this is indeed good news.A heap of thanks to those Microlinux (#6) for mentioning this, as I was unaware.
I detest the execrable systemd, and I am getting all set to switch to FreeBSD as soon as version 10.1 gets released (mid November I guess). But if Debian forks, I will at least keep a Debian installation in one partition. I really don't want to abandon Linux for FreeBSD, but I am not willing to have the systemd virus on my computer.
27 • debain fork (by linuxista on 2014-10-21 02:40:29 GMT from United States)
@6 The manifesto states in part: "The current leadership of the project is heavily influenced by GNOME developers and too much inclined to consider desktop needs as crucial to the project, despite the fact that the majority of Debian users are tech-savvy system administrators."
Can this really be true?
28 • @27 (by Paraquat on 2014-10-21 03:07:26 GMT from Taiwan)
"@6 The manifesto states in part: "The current leadership of the project is heavily influenced by GNOME developers and too much inclined to consider desktop needs as crucial to the project, despite the fact that the majority of Debian users are tech-savvy system administrators."
Can this really be true?"
I doubt it's true. Who actually said that?
Anyway, I can't claim to be a tech-savvy system administrator, but I'm tech-savvy enough as a Linux user (16 years experience) to understand why I don't want systemd. Don't have time enough right now to rehash the entire debate, but I plan to write an article about it soon.
Of course, most of us have probably heard more of this debate than we ever wanted to already. Unfortunately, nothing has been resolved. So we opponents of Systemd/Linux have got to start making plans about how we are going to cope. For some that means switching to Slackware or Gentoon, for others FreeBSD. But it would be nice if we could claw Debian back from the brink.
29 • Slackware keymaps (by salparadise on 2014-10-21 04:23:21 GMT from United Kingdom)
@a - this might help.
30 • @28 FreeSlacktoo, lol (by cykodrone on 2014-10-21 11:04:52 GMT from Canada)
I'll give Jessie (the upcoming official "stable" release") a chance, but at the first whiff of stinky full diaper smell from systemd, I'm off to FreeSlacktoo land. It means learning new commands, etc, but who cares, I had to learn Debian commands, I can do it again with a diff distro. Just sayin. Basically if systemd does suck in Jessie, then it'll suck in other distros using it too.
31 • Sparky Linux (by J. Jay Thomas on 2014-10-21 12:29:03 GMT from United States)
Good review. The problems you had are problem in the 'Mate DE, (some distros hack around these better than others), especially high CPU usage and the panel. The 'sparky system tools' again are caused by unstable (from release to release) 'mate-system-tools' package, installing the 'gnome-system-tools' package makes them work. Try 'Sparky XFCE or lxde spins (change system tools used thou) and you'll have a totally different experience.
32 • Evo/Lution (by Terence on 2014-10-21 12:48:51 GMT from United States)
I'm with you on the Arch installer they have created. I downloaded it, threw it onto my USB drive and away I went. Lord, they simplified installation, though it's still a bit hinky in parts, and added some cool options to boot. What kernel you want? Bam done. What desktop you want? Bam done. The only sticking point I still run into is when it first boots and tries to download the core, community, etc. updates. Until I actually designate what country I am in, and choose servers local to me, it sometimes get bogged down and errors out. But that could be because I'm in China and China don't play nice.
33 • Systemd conspiracy ;-) (by KI on 2014-10-21 13:33:25 GMT from Belgium)
I have always advocated for unifying the Linux landscape. For me, it is clear that the purpose of systemd is enforcing unification creating a universal administrative interface for every Linux system.
Per se, this is not a bad thing. The problem is that it is being imposed upon us by spreading an obscure, poorly documented, chunk of code without explicitly declaring the final goal.
34 • @33 - Systemd conspiracy (by Pierre on 2014-10-21 14:43:08 GMT from Germany)
It's exactly what I think, too.
But as long as systemd does on my system what it is supposed to do I will not complain too much.
Nevertheless I am honestly thinking about the move to FreeBSD or PC-BSD. GhostBSD is worth a test run as well.
Maybe this way the *BSDs will get the attention they deserve now. FreeBSD seems to be quite clean in it's implementation. And ZFS looks like it's a better choice in comparison to Btrfs although I am using Btrfs on openSUSE since 12.3 without a single problem.
35 • SparkyLinux (by dhinds on 2014-10-21 21:25:25 GMT from Mexico)
I use Sparky Openbox on this Desktop Machine. I began with Mate and liked it but had problems with the need to be root (as mentioned here). LXDE is the major DE for Parvoo, Sparky's Developer and of course LXDE's window manager is Openbox. I myself run a number of XFCE apps, including the xfce4-panel and everything runs just fine. Sparky is one of the best distros based on Debian Testing, imo.
36 • 96 dodge grand caravan (by dhinds on 2014-10-21 21:28:59 GMT from Mexico)
I meant to say I don't use the wbar dock (but rather the xfce4-panel) or the Sparky desktop background and changing them is easy to do.
37 • Arch Upgrades in RAM Are Best Way (by Arch Watcher 402563 on 2014-10-21 21:43:16 GMT from United States)
Notice good Arch packages
(1) pacmanlogviewer ('plv' at console)
Retention of pkgs is wasted space and thrashing. Upgrades can run in RAM which is faster anyhow. Cache disappears at reboot, or clears by hand or by timer. Pacaur cleans itself so you can upgrade with an easy shell alias for this one-liner.
pacaur -Syu && pacman -Scc && sync && plv
Mods for RAM-only Arch upgrades:
tmpfs /var/log tmpfs defaults,gid=100,mode=0777,size=50M 0 0
tmpfs /var/cache tmpfs defaults,size=150M 0 0
d /tmp/pacman-cache 0755 root root 1d
d /var/cache/pkgfile 0775 root users 1d
f /var/log/pacman.log 0664 root users -
# /etc/pacman.conf [options] section
CacheDir = /tmp/pacman-cache
# /etc/xdg/pacaur/config uncomment
38 • security methods (by J Bro on 2014-10-22 01:04:37 GMT from Australia)
"There are a few different approaches to security in operating systems: "security by isolation", "security by correctness", "security by obscurity"."
Well described Jesse. Each undoubtedly has its own advantages and weaknesses. Probably the best security solution would be a mixture of all methods.
The Isolation method primarily prevents malware / hackers from getting total control over the computer. The devs think that that's all you need and don't value other approaches. But it doesn't necessarily have the best perimeter defences to prevent access in the first place - like limiting remote login, denying hosts, stopping unneeded services, closing unused ports, a comprehensive firewall, etc. That's where the isolation-only approach is flawed.
39 • security methods (by Fossilizing Dinosaur on 2014-10-22 01:13:05 GMT from United States)
And then there's security designed by Marketing: "What's your email address? What's your phone number? What's your fax number? What's your cell phone number? What's your smartphone number? ..."
40 • Too much rhetoric (by :wq on 2014-10-22 02:18:47 GMT from United States)
I have no problem with people forking projects or starting new, potentially competing, projects, though many will end up dying off (Northfield/Norwood come to mind here), no matter the reasoning, as long as it's done honestly, with no intentional misattributions, misrepresentations, or verbal embellishments used to bolster the cause. Whether people assume good or bad faith veers off into subjectivity, and is beyond the scope of this post. What gets old is the childish language on all sides, such as "cancerd", "Poettering OS", etc. It's the same immaturity that fuels "M$" and "Windoze" comments. It doesn't matter the "discussion", it could be BSDs and Linux compared, Clang and GCC compared, AMD, NVIDIA and Intel compared, etc, invariably it ends being around 10% cogent opinions and 90% hell-raising static, again, on all sides. I will admit that, while often depressing, the crisis of the hour occasionally makes for amusing bedfellows, as, in the particular case of systemd reaction, I have witnessed some people on other sites who tirelessly bashed the BSDs now suddenly singing their praises, which isn't bad, as #34 said, the BSDs deserve more attention, it's just sad in these aforementioned cases that it took systemd hatred to foment BSD love, which makes me wonder how fickle that attention will be.
The Debian Project will have its GR vote, parties like debianfork.org will proceed as they choose in response to the vote, and other software communities will continue to plan how they approach technologies, both in idealistic and pragmatic terms, but enough with the pettiness.
41 • @40 (by kernelKurtz on 2014-10-22 06:05:41 GMT from Romania)
Got your non-petty cogent opinion right here yo.
42 • @40 Since YOU brought it up... (by cykodrone on 2014-10-22 11:47:38 GMT from Canada)
You forgot one, 'Windhose', it vacuums money from your wallet or purse, lol, been there, done that, the TCO is ridiculous, monetarily and maintenance time spent, time is money too.
How about "poop or get off the Poettering"? OK, bad joke. :D
And since you brought up hardware vendors too, I was avoiding identifying them in an earlier post, Intel has cheesed me off for several reasons (CPU unique identifier, I haven't forgot that, and prices), so has Nvidia, they have been stubborn with FOSS until only recently, hence Linus' well publicized rant (I love Linus, he's hilarious, in a good way), so I built an AMD FX-8350 and stuck a Radeon card in it. But that's just me, I vote with my wallet and principals.
43 • @37 Arch Upgrades in RAM Are Best Way (by Kazlu on 2014-10-22 12:00:01 GMT from France)
I wouldn't recommend to mount /var/cache in RAM. Like you said, it clears the cache at reboot time, especially the pacman cache. So if you happen to have a problem with a particular package update on your computer, if you don't have the package corrresponding to the previous verison still in your cache, which would allow you to downgrade the package until the next update, you're screwed. Given the fast rolling pace of Arch Linux, keeping some older versions of packages is safer.
This is a compromise between speed and safety: it's up to the user do decide where to put the cursor. The Arch way.
44 • systemd and Debian (by Pierre on 2014-10-22 12:11:52 GMT from Germany)
I read a lot about systemd the last couple of days. I already started to dislike it at the point where they started to take control over more and more basic system components like for example networking. Now it seems they even want to replace the virtual terminal system(s) etc...
Enough is enough.
There has to be an end to what a single daemon should be able to have control over and access to and systemd has already way too much power over the Linux system.
Additionally I started to dislike it's developers for thinking they would know every answer to every (not even asked) question.
Maybe I should really reconsider my upgrade to openSUSE 13.2 when it's released and start using PC-BSD or even plain FreeBSD.
Debian GNU/kFreeBSD could be worth a look as well. Maybe it's even the best compromise between Debian GNU userland software and the FreeBSD kernel with it's unique feature set like ZFS, Jails etc.
Additionally Debian should really revaluate their switch to systemd for their Linux based OS and go with OpenRC or some other good option instead. This would make maintaining the GNU/kFreeBSD port easier as well.
45 • Sparky Linux. Better alternatives. (by hotdiggettydog on 2014-10-22 19:24:35 GMT from Canada)
Good review on Sparky.
I've tried every release of Sparky and found it lacking. I suspect its a 12 year old's project.
Try Lite, Handy, and Lxle instead.
I've been running Lite and a clone in Virtualbox for different purposes and it has been superb. This is on a Mint host.
If I have to reinstall any operating systems in the near future it will be Lite. Not only great for older machines but fantastic on new hardware.
46 • @43 Arch Upgrades in RAM Are Best Way (by Arch Watcher 402563 on 2014-10-22 20:59:56 GMT from United States)
@43 Re "if you don't have the package ... in your cache, which would allow you to downgrade ... you're screwed"
No, you are fine. I have run /var/cache in RAM for years, no problem. The claimed need is very rare but in any event, two other ways to downgrade exist.
(1) Use a third-party repo offering old packages, see Arch Wiki.
(2) Use Arch Build System (ABS). This method I think best.
Now on speed/safety, here it's a fallacy. Thrashing a disk with multi-GB of largely unused cache and risking disk-full, or blowing SSD cell life, makes a bigger threat than esoteric needs for package reversion perhaps once each few years, achievable by two independent cacheless methods.
47 • Security comparison (by D Sis on 2014-10-23 02:43:19 GMT from Australia)
Hey Jesse, maybe after you finish the rolling release test, you could do a comparison of distros using a different security method. It could give people a good heads-up on security. (P.S. I think Qubes is meant more for laptops than desktops.)
48 • @46 Arch Upgrades in RAM Are Best Way (by Kazlu on 2014-10-23 11:08:30 GMT from France)
Your first method is using third-party repo, not always a good idea. The second is fine, you should indeed get anything you want, although it would probably be more time-consuming (and I'm not talking about time needed for compilation, but about time needed for looking for information).
My suggestion would be to keep a few versions (something around 2-5 versions) of each packages and to clean the older ones with paccache in order to keep the cache size reasonable. That way you could even downgrade if your problem cost you your internet connection (ok, I admit, this must be very, very rare!). I find this easier to do, but since that's a subjective argument I will put forward another: with that method if something breaks you can revert to a version you *know* worked well enough before the problem, instead of trying something new. But you were right when you said that contributes to ruin an SSD's life, that has to be taken into consideration. Although the fact of using a rolling-release distro on a SSD itself can be discussed from that point of view.
Anyway, those solutions all have their good and bad points, good to hear different opinions, thanks for sharing them.
49 • @ 43 (by AleCon on 2014-10-23 15:24:54 GMT from Italy)
update system (pacman -Syu) reboot, check if everything is fine, then clean cache with pacman -Sc
safe( r) and easy (ier), my 0.02$
50 • About systemd (by alex.theoto on 2014-10-23 17:21:01 GMT from Greece)
Well, I see many arguments about systemd.
I believe that technology must move on. But people don't like changes.
I use Debian Sid and I understand that systemd makes system faster. Even I haven't learn how to control systemd, I think that it is matter of time to learn it just as I learned init and 'service' command.
I have some freezes here and there on gnome-shell and I don't know how to restart the session even when I type 'systemctl reload gdm...' [I don't remember the command], but I reboot the computer and I'm fine.
It's like desktop environment's war... Some like KDE, some like GNOME and so on...
This is the magic on Linux. You have many options to choose. It's up to you.
I think that Linux user have to be flexible. For example, if someone use only KDE and go to another computer witch have only lxde, he must be flexible to operate it.
51 • Evo/Lution (by SB on 2014-10-23 17:37:10 GMT from United Kingdom)
.32 You set up your countries mirrorlist during the installation.
52 • @50 Diminishing choices (by cykodrone on 2014-10-23 21:31:16 GMT from Canada)
You said "This is the magic on Linux. You have many options to choose. It's up to you."
That's the problem, systemd should be a CHOICE, not forced down anybody's throat. People are up in arms because of ambiguity and not explained blobs of code, this is out of step with the GNU philosophy. Personally I'll try it, I'm the type to give anything a chance, but any hiccups or fails that can't be easily fixed and it's gone, and so am I from any distro that uses it, that includes my donation dollars as well.
53 • @48 Arch Upgrades in RAM Are Best Way (by Arch Watcher 402563 on 2014-10-23 22:40:54 GMT from United States)
@48 The problem with this whole thread is its entirely false impression that anybody ever reverts. It's an esoteric, rare need. Cache is deadwood.
Any reversion need passes within days (from my experience). So it's just as simple to remove a package and wait a week. Then reinstall it from repos.
That ABS vid shows a trivial changing of version number. There is no information to seek. It's already in the source files.
Most reversion needs are kernel-related, so everyone should install 'linux-lts' along with mainline 'linux'. Then if 'linux' fails, LTS will work.
You can also boot an Arch installer ISO (dd'd to USB stick), and chroot from there for package fiddling on your main disk.
Third-party repos are fine and underutilized. They are more reliable than using AUR to get the same packages. I recommend xyne and arcanisrepo with its GUIs for netctl.
54 • systemd (by dawn on 2014-10-24 01:15:59 GMT from Canada)
systemd, the new userland kernel?
55 • 52 • @50 Diminishing choices (by Ika on 2014-10-24 02:36:50 GMT from Spain)
"That's the problem, systemd should be a CHOICE, not forced down anybody's throat. People are up in arms because of ambiguity and not explained blobs of code, this is out of step with the GNU philosophy."
+1! Good things are never imposed. Only the bad ones are,
56 • Debugging Distros (by Fossilizing Dinosaur on 2014-10-24 04:53:56 GMT from United States)
DebIan-Testing, Fedora, Arch - aren't these the right place to drop paradigm-changing complex code desperately needing debugging like Gnome3 and systemd? Surely it's not in DebIan-Stable yet, is it?
57 • Zoubuntu (by G Savage on 2014-10-24 12:57:47 GMT from Canada)
I'll give the Ubuntu people one thing, they're masters at marketing. They've taken the "different desktop makes a new distro" to a whole new level. Good on them.
58 • @56 - Debugging Distros (by Rev_Don on 2014-10-24 14:38:21 GMT from United States)
"DebIan-Testing, Fedora, Arch - aren't these the right place to drop paradigm-changing complex code desperately needing debugging like Gnome3 and systemd? Surely it's not in DebIan-Stable yet, is it?"
It will be in the next release. Jesse will have systemd by default. That won't preclude anyone from switching to other init systems. And that is the part that gets lost in all of the rhetoric, they aren't imposing it on anyone as the only choice, only as the default choice just like a distros default choice of desktop, browser, music player, etc. If you don't like what is included in the default install you are free to change it to something of you liking.
Instead of all of systemd is the end of the world and the sky is falling wailing we need people talking about how the individual can change to something else. That would be a better use of time, resources, and bandwidth.
The only thing that will kill systemd is systemd itself, and that will only happen when enough distros have used it long enough to be able to determine that it isn't working as well as they thought it would. The only way that will happen is if they actually ship it.
59 • systemd (by anticapitalista on 2014-10-24 15:09:31 GMT from Greece)
#58 The issue isn't whether Jessie defaults to systemd or not, but to what extent yiu can use software without systemd. For example, try running network manager without systemd on Jessie. Or hplip-gui for HP printers.
60 • systemd (by linuxista on 2014-10-24 18:16:53 GMT from United States)
I've used systemd on Arch and Manjaro for years now, and I've never had any systemd specific issues. Ever. Lost in all the complaints is that a team of developers has put a lot of work and talent into creating a very significant piece of open source software. I for one thank them for their efforts. I also see a lot of complaints about whether or not systemd works based on whether it works in Debian testing. Those are two different questions. Systemd has worked very well in other distros for years. Debian devs and users will have to take responsibility for their own ability to implement it. It seems other init options will remain in the Linux ecosystem, and people will have another basis for choosing one distro over another. Doesn't Slackware still use LILO? And maybe this is a positive outcome for the BSDs. The more popular Linux gets, the more attractive they might become in any case as an antivirus/anti-malware strategy.
61 • So is the way with most distros. (by Garon on 2014-10-24 19:01:08 GMT from United States)
I've tried to stop responding to trollish comments but yours really puzzles me. How many distros do you see that are based on Ubuntu. Sorry but that was just a strange comment.
Finally some good common sense comments. Thank you.
62 • 60 • systemd - by linuxista (by MiRa on 2014-10-24 20:03:21 GMT from Spain)
"a team of developers has put a lot of work and talent into creating a very significant piece of open source software.!
Is it really an "open source" software?
63 • systemd (by linuxista on 2014-10-25 06:27:37 GMT from United States)
@62 Of course it is. Do you think Debian, of all distros, would have adopted it if it weren't? I think the confusion is all the complaints about it not being as accessible to intervention on the fly because it's compiled into binaries instead of being plain text scripts. (Somebody correct me if I've got this wrong; I'm not an expert.)
64 • Zorin (by Marcito Polito on 2014-10-26 16:41:59 GMT from United States)
Well what do you know, I'm stuck. And that's fine.
I've just realized Zorin has been running on the hard drive of this machine for several months now. I do have other distros on flash drives (Extix, PCLinuxOS and Knoppix, etc) but I've still been in the habito of replacing my hard drive distro by distro hopping a couple of times per year, most often between PCLOS and Mint.
Hm. Well okay. That is. Er.. Well yes it's the "it just works" thing, I suppose. *shrug*
65 • Next Weeks Take a peek (by timbuk2 on 2014-10-26 17:45:14 GMT from Germany)
The GhostBSD project is a desktop oriented operating system which uses FreeBSD as a base. The project's website sums up GhostBSD by saying, "GhostBSD is built on top of the FreeBSD project. However, being a GTK desktop oriented OS, GhostBSD takes the FreeBSD system and pre-configures the most common software choices, fine-tunes the selection of applications for optimal performance, and provides an intuitive work environment without the need for extensive additional configuration."
GhostBSD 4.0 is available in just one edition as of the time of writing and this edition ships with the MATE desktop environment. I found GhostBSD is available in 32-bit and 64-bit builds for the x86 hardware architecture and the project offers separate downloads for people using optical media and USB thumb drives. I chose to download the 64-bit build for USB drives and found the image file was 1.2GB in size.
Booting from the GhostBSD media brings us to the MATE desktop. The background is a soft shade of blue and the theme features bright icons and dark borders. On the desktop is an icon for launching the project's system installer. Shortly after logging in a window appears offering to switch our desktop to one of three different layouts. The available options are Classic, Enlightenment or Purity. Clicking these options alters the layout of the MATE desktop, moving the application menu, task switcher and optional quick-launch bar. The window that allows us to change the desktop's layout stays open after we make our selection and we can experiment with the three layouts as long as we like.
66 • rest (by laberababer on 2014-10-26 17:46:52 GMT from Germany)
GhostBSD's graphical system installer appears to be unique to the project. The application starts by asking us to select our preferred language from a short list of European languages. We are then asked to select our keyboard's layout from a list and then we are asked to find our time zone in another list. Next, we come to disk partitioning and we are given the choice of manually dividing up our hard drive or handing over the entire drive to GhostBSD. The first time through I tried manual partitioning. I found the installer's partition manager a bit awkward and I was unable to find a way to re-size partitions. I also found it strange that a deleted partition would result in a block of free space that could not be reclaimed. There is a guided option on the manual partitioning screen that will make suggestions for us.
The first time through I created a root partition and swap space. When I attempted to proceed the installer claimed I had not created a root partition, though one was displayed on the screen. I took the guided option next which created almost an identical arrangement and moved to the next stage. I feel it worth mentioning GhostBSD's installer does not support ZFS, though the underlying FreeBSD operating system does. GhostBSD only supports UFS and extended features of UFS. The installer then asks us to set a password on the root account and we have the option of installing a boot loader. We are next asked to create a user account for ourselves. The system installer then begins copying its files to the local hard drive. The first time I went through the installer it failed, though the reason the installation process failed was not clear. I went back through the installer, this time giving it access to my entire hard drive and the installation completed cleanly. Once the installer finishes its work we are asked to reboot the computer.
GhostBSD boots to a graphical login screen with an attractive, wavy blue background. Signing into the account we created at install time brings us back to the MATE desktop in whichever layout we selected for it while we were using the live media. Or at least that is what happened when I ran GhostBSD in VirtualBox. I tried getting GhostBSD to run on my desktop computer and, when working directly with the physical hardware, GhostBSD would not boot. Even when asked to run in safe mode GhostBSD wouldn't start on my desktop machine. In the virtual environment GhostBSD would boot, but I found the operating system wouldn't take full advantage of my display's resolution, even with VirtualBox's guest add-ons in place. This was in interesting contrast to PC-BSD 10.0.3 which I installed a few weeks previous to this trial. While I had to select an alternative video driver for PC-BSD, the operating system would run on this same hardware. On the other hand, while PC-BSD consumed a great deal of my host operating system's CPU cycles while running inside VirtualBox, I found GhostBSD required very little of my CPU's resources when it was run as a VirtualBox guest. I also found GhostBSD required relatively little memory, using just 160MB of active memory when logged into the MATE desktop environment.
GhostBSD ships with a small, but useful collection of desktop applications. We can find the Firefox web browser in the application menu along with the XChat IRC client, the Pidgin instant messaging software, the Thunderbird e-mail client and the Transmission bittorrent software. The LibreOffice productivity suite is installed for us along with an image viewer, a document viewer and the Shotwell photo manager. GhostBSD features the Cheese webcam utility and the Xfburn optical disc burning software. I found MPlayer was available for playing videos and the Exaile audio player is included too. GhostBSD ships with popular multimedia codecs, allowing us to play most media files out of the box. There is, however, no Flash support by default. Digging through the application menu further we find an archive manager, calculator, text editor and system monitor. The Midnight Commander file manager is installed for us too. Network Manager is included with GhostBSD and the operating system includes the FreeBSD 10.0 kernel and command line utilities.
GhostBSD uses the pkg command line package manager for updating software and for installing or removing packages. GhostBSD pulls software from the FreeBSD package repositories. Adding or removing packages worked well for me, but I ran into trouble when it came time to upgrade existing packages. Shortly after I installed GhostBSD I found 219 upgrades waiting in the repositories and these totalled 411MB in size. The package manager downloaded and installed these items for me without any problems, but when I rebooted the machine, I was dropped at a text console login screen. I was no longer able to launch the X display software and I could not get back to a graphical login screen. After trying to boot in safe graphics mode and trying to manually correct the problem with X I re-installed GhostBSD. The operating system worked well for me again until I performed another software update a few days later. Once again, installing updates disabled X, reducing GhostBSD to a command line only operating system.
Going into this review I truly wanted to like GhostBSD. I like what they are trying to do and I appreciate the idea of providing the world with an easy, home user, desktop oriented flavour of FreeBSD. While PC-BSD aims at businesses and workstations more than home users and PC-BSD is exclusive to 64-bit machines and offers every desktop environment under the sun, I feel there is a place for a streamlined, one-desktop, lightweight operating system built on the foundation of FreeBSD. GhostBSD is working with a good idea and strives to fill a niche that is mostly uncontested these days.
Unfortunately, I ran into several problems with this release of GhostBSD. The installer gave me some problems when I tried to manually partition my disk and I ran into some errors when I didn't take the automated partitioning option. Like PC-BSD, the GhostBSD operating system had trouble working with my video card. Unlike PC-BSD, I found GhostBSD didn't have an easy work around and that meant I spent all my time with the operating system running it in a virtual machine. To top it off, upgrading the operating system caused the graphical user interface to stop working, which was a frustrating turn of events.
Number of Comments: 66
Display mode: DWW Only • Comments Only • Both DWW and Comments
|• Issue 843 (2019-12-02): Obarun 2019.11.02, Bluestar 5.3.6, using special characters on the command line, Fedora plans to disable empty passwords, FreeBSD's quarterly status report|
|• Issue 842 (2019-11-25): SolydXK 10, System Adminstration Ethics book review, Debian continues init diversity debate, Google upstreaming Android kernel patches|
|• Issue 841 (2019-11-18): Emmabuntus DE3-1.00, changing keys in a keyboard layout, Debian phasing out Python 2 and voting on init diversity, Slackware gets unofficial updated live media|
|• Issue 840 (2019-11-11): Fedora 31, monitoring user activity, Fedora working to improve Python performance, FreeBSD gets faster networking|
|• Issue 839 (2019-11-04): MX 19, manipulating PDFs, Ubuntu plans features for 20.04, Fedora 29 nears EOL, Netrunner drops Manjaro-based edition|
|• Issue 838 (2019-10-28): Xubuntu 19.10, how init and service managers work together, DragonFly BSD provides emergency mode for HAMMER, Xfce team plans 4.16|
|• Issue 837 (2019-10-21): CentOS 8.0-1905, Trident finds a new base, Debian plans firewall changes, 15 years of Fedora, how to merge directories|
|• Issue 836 (2019-10-14): Archman 2019.09, Haiku improves ARM support, Project Trident shifting base OS, Unix turns 50|
|• Issue 835 (2019-10-07): Isotop, Mazon OS and, KduxOS, examples of using the find command, Mint's System Reports becomes proactive, Solus updates its desktops|
|• Issue 834 (2019-09-30): FreedomBox "Buster", CentOS gains a rolling release, Librem 5 phones shipping, Redcore updates its package manager|
|• Issue 833 (2019-09-23): Redcore Linux 1908, why Linux distros are free, Ubuntu making list of 32-bit software to keep, Richard M Stallman steps down from FSF leadership|
|• Issue 832 (2019-09-16): BlackWeb 1.2, checking for Wayland session and applications, Fedora to use nftables in firewalld, OpenBSD disables DoH in Firefox|
|• Issue 831 (2019-09-09): Adélie Linux 1.0 beta, using ffmpeg, awk and renice, Mint and elementary improvements, PureOS and Manjaro updates|
|• Issue 930 (2019-09-02): deepin 15.11, working with AppArmor profiles, elementary OS gets new greeter, exFAT support coming to Linux kernel|
|• Issue 829 (2019-08-26): EndeavourOS 2019.07.15, Drauger OS 7.4.1, finding the licenses of kernel modules, NetBSD gets Wayland application, GhostBSD changes base repo|
|• Issue 828 (2019-08-19): AcademiX 2.2, concerns with non-free firmware, UBports working on Unity8, Fedora unveils new EPEL channel, FreeBSD phasing out GCC|
|• Issue 827 (2019-08-12): Q4OS, finding files on the disk, Ubuntu works on ZFS, Haiku improves performance, OSDisc shutting down|
|• Issue 826 (2019-08-05): Quick looks at Resilient, PrimeOS, and BlueLight, flagship distros for desktops,Manjaro introduces new package manager|
|• Issue 825 (2019-07-29): Endless OS 3.6, UBports 16.04, gNewSense maintainer stepping down, Fedora developrs discuss optimizations, Project Trident launches stable branch|
|• Issue 824 (2019-07-22): Hexagon OS 1.0, Mageia publishes updated media, Fedora unveils Fedora CoreOS, managing disk usage with quotas|
|• Issue 823 (2019-07-15): Debian 10, finding 32-bit packages on a 64-bit system, Will Cooke discusses Ubuntu's desktop, IBM finalizes purchase of Red Hat|
|• Issue 822 (2019-07-08): Mageia 7, running development branches of distros, Mint team considers Snap, UBports to address Google account access|
|• Issue 821 (2019-07-01): OpenMandriva 4.0, Ubuntu's plan for 32-bit packages, Fedora Workstation improvements, DragonFly BSD's smaller kernel memory|
|• Issue 820 (2019-06-24): Clear Linux and Guix System 1.0.1, running Android applications using Anbox, Zorin partners with Star Labs, Red Hat explains networking bug, Ubuntu considers no longer updating 32-bit packages|
|• Issue 819 (2019-06-17): OS108 and Venom, renaming multiple files, checking live USB integrity, working with Fedora's Modularity, Ubuntu replacing Chromium package with snap|
|• Issue 818 (2019-06-10): openSUSE 15.1, improving boot times, FreeBSD's status report, DragonFly BSD reduces install media size|
|• Issue 817 (2019-06-03): Manjaro 18.0.4, Ubuntu Security Podcast, new Linux laptops from Dell and System76, Entroware Apollo|
|• Issue 816 (2019-05-27): Red Hat Enterprise Linux 8.0, creating firewall rules, Antergos shuts down, Matthew Miller answers questions about Fedora|
|• Issue 815 (2019-05-20): Sabayon 19.03, Clear Linux's developer features, Red Hat explains MDS flaws, an overview of mobile distro options|
|• Issue 814 (2019-05-13): Fedora 30, distributions publish Firefox fixes, CentOS publishes roadmap to 8.0, Debian plans to use Wayland by default|
|• Issue 813 (2019-05-06): ROSA R11, MX seeks help with systemd-shim, FreeBSD tests unified package management, interview with Gael Duval|
|• Issue 812 (2019-04-29): Ubuntu MATE 19.04, setting up a SOCKS web proxy, Scientific Linux discontinued, Red Hat takes over Java LTS support|
|• Issue 811 (2019-04-22): Alpine 3.9.2, rsync examples, Ubuntu working on ZFS support, Debian elects new Project Leader, Obarun releases S6 tools|
|• Issue 810 (2019-04-15): SolydXK 201902, Bedrock Linux 0.7.2, Fedora phasing out Python 2, NetBSD gets virtual machine monitor|
|• Issue 809 (2019-04-08): PCLinuxOS 2019.02, installing Falkon and problems with portable packages, Mint offers daily build previews, Ubuntu speeds up Snap packages|
|• Issue 808 (2019-04-01): Solus 4.0, security benefits and drawbacks to using a live distro, Gentoo gets GNOME ports working without systemd, Redox OS update|
|• Issue 807 (2019-03-25): Pardus 17.5, finding out which user changed a file, new Budgie features, a tool for browsing FreeBSD's sysctl values|
|• Issue 806 (2019-03-18): Kubuntu vs KDE neon, Nitrux's znx, notes on Debian's election, SUSE becomes an independent entity|
|• Issue 805 (2019-03-11): EasyOS 1.0, managing background services, Devuan team debates machine ID file, Ubuntu Studio works to remain an Ubuntu Community Edition|
|• Issue 804 (2019-03-04): Condres OS 19.02, securely erasing hard drives, new UBports devices coming in 2019, Devuan to host first conference|
|• Issue 803 (2019-02-25): Septor 2019, preventing windows from stealing focus, NetBSD and Nitrux experiment with virtual machines, pfSense upgrading to FreeBSD 12 base|
|• Issue 802 (2019-02-18): Slontoo 18.07.1, NetBSD tests newer compiler, Fedora packaging Deepin desktop, changes in Ubuntu Studio|
|• Issue 801 (2019-02-11): Project Trident 18.12, the meaning of status symbols in top, FreeBSD Foundation lists ongoing projects, Plasma Mobile team answers questions|
|• Issue 800 (2019-02-04): FreeNAS 11.2, using Ubuntu Studio software as an add-on, Nitrux developing znx, matching operating systems to file systems|
|• Issue 799 (2019-01-28): KaOS 2018.12, Linux Basics For Hackers, Debian 10 enters freeze, Ubuntu publishes new version for IoT devices|
|• Issue 798 (2019-01-21): Sculpt OS 18.09, picking a location for swap space, Solus team plans ahead, Fedora trying to get a better user count|
|• Issue 797 (2019-01-14): Reborn OS 2018.11.28, TinyPaw-Linux 1.3, dealing with processes which make the desktop unresponsive, Debian testing Secure Boot support|
|• Issue 796 (2019-01-07): FreeBSD 12.0, Peppermint releases ISO update, picking the best distro of 2018, roundtable interview with Debian, Fedora and elementary developers|
|• Issue 795 (2018-12-24): Running a Pinebook, interview with Bedrock founder, Alpine being ported to RISC-V, Librem 5 dev-kits shipped|
|• Issue 794 (2018-12-17): Void 20181111, avoiding software bloat, improvements to HAMMER2, getting application overview in GNOME Shell|
|• Issue 793 (2018-12-10): openSUSE Tumbleweed, finding non-free packages, Debian migrates to usrmerge, Hyperbola gets FSF approval|
|• Issue 792 (2018-1203): GhostBSD 18.10, when to use swap space, DragonFly BSD's wireless support, Fedora planning to pause development schedule|
|• Issue 791 (2018-11-26): Haiku R1 Beta1, default passwords on live media, Slax and Kodachi update their media, dual booting DragonFly BSD on EFI|
|• Full list of all issues|
Star Labs - Laptops built for Linux.
View our range including the Star Lite, Star LabTop and more. Available with a choice of Ubuntu, Linux Mint or Zorin OS pre-installed with many more distributions supported. Visit Star Labs for information, to buy and get support.
|Random Distribution |
Rails Live CD
Rails Live CD was a specialist distribution providing a pre-configured and fully operating Ruby on Rails development environment on a bootable CD. The distribution was derived from PCLinuxOS.