| DistroWatch Weekly
|DistroWatch Weekly, Issue 797, 14 January 2019
Welcome to this year's 2nd issue of DistroWatch Weekly!
Two hurdles Linux faces when trying to gain more mainstream appeal on desktop systems are support for more gaming titles and support from hardware retailers. This week we are happy to share good news on both of these fronts. In our News section we first look at the Debian team working on improving Secure Boot support on their distribution. Then we talk about Ubuntu and Ubuntu MATE being shipped on new all-in-one (AIO) devices and discuss increasing support for Linux in Valve's Steam store. In our Feature Story this week we take an early look at two projects on our waiting list Reborn OS and TinyPaw-Linux and share what makes these distributions interesting. Plus we offer tips on how to deal with an unresponsive desktop environment. In our Opinion Poll we ask what tools our readers use to keep their systems running smoothly when rogue processes try to gobble up more resources than they should. As usual, we share the distribution releases of the past week and provide a list of the torrents we are seeding. We wish you all a fantastic week and happy reading!
Listen to the Podcast edition of this week's DistroWatch Weekly in OGG (14MB) and MP3 (10MB) formats.
|Feature Story (by Jesse Smith)
Reborn OS 2018.11.28
Reborn OS is a distribution from the Antergos and Arch Linux family of distributions. Like Antergos, Reborn uses the Cnchi system installer and provides a wide range of desktop environments and extra features we can enable at install time. Reborn's website mentions the project offers support for running Android applications through the Anbox compatibility software, works with Flatpaks, and can run the Mycroft personal desktop assistant.
I had previously tried Reborn OS back in October of 2018 and gave up trying to install the distribution because Cnchi kept running into problems downloading packages, telling me it had run into "error: 0". Since failure to download packages during the installation rendered it impossible to set up Reborn, I had to abandon the project.
Shortly after my truncated review appeared, one of the Reborn developers got in touch and reported that the problem with Cnchi had been fixed and invited me to try the distribution again. I gave the project a few months (and updated releases) to mature and then decided to give Reborn another test drive.
The Reborn ISO file is a 1.6GB download. Booting from the media brings up the Budgie desktop environment and shows us a welcome window. The welcome window appears to be borrowed from Antergos and displays buttons which will provide us with information. Some buttons link to the project's on-line source code repository, others offer to show us available software, another gives us a quick overview of the operating system.
Using the welcome window I ran into my first problem with Reborn. Clicking some of the buttons caused the operating system to lock up. For example, browsing the software list caused the system to freeze, necessitating a reboot. When I clicked on the source repository link, the Firefox browser opened, displayed the page and then the system locked up, again forcing a hard reset of the computer.
Reborn OS 2018.11.28 -- Reborn's welcome screen
(full image size:668kB, resolution: 1366x768 pixels)
At this point I decided to stop exploring the live desktop and jumped into the Cnchi installer. The installer runs in a graphical window and feels similar in most respects to Ubuntu's Ubiquity installer or the Calamares installer. We are asked to select our preferred language from a list, select our country and select our time zone from a map. We are asked to confirm our keyboard's layout and then shown a list of available desktops. We can only choose one desktop to install, but the list of options is long and includes Budgie, Cinnamon, Enlightenment, GNOME, i3, KDE Plasma, LXQt, MATE, Openbox, Pantheon and Xfce. There is also one called "Windows interface", but its description does not say what technology is used to present the Windows-like view.
The installer next asks which features we would like to enable. Options include accessibility packages, system maintenance, AUR support, Bluetooth, Chromium, Firefox, LibreOffice, Mycroft, printing support, WINE, VLC and Spotify. The list goes on. I kept my selection short, sticking to some common desktop applications like LibreOffice, a web browser and Mycroft. Cnchi then asks if we want to let it sort its list of package mirrors or manually select mirrors. I took the recommended automated sort.
Partitioning comes next with the option of using guided or manual partitioning. I went with the manual option, and then had to wait as the installer told me it needed to finish sorting its mirror list before I could partition the drive. Once the mirrors are sorted, partitioning is straight forward and pleasantly streamlined. Finally, we are asked to provide a username and password for an account and the installer goes to work downloading and installing packages, over 700 packages in my case.
After waiting for about half an hour, Cnchi finally reported "Can't install necessary packages" and displayed the infamous error 0. Unfortunately there is no way to recover. The installer closes without telling us which package caused the problem, or giving us a chance to proceed anyway, or giving us the option to try another mirror. The installer closes and we are left to try again from step one. The project's documentation says we can try to work around the issue by manually editing the package list to remove the offending package, but that is difficult given there were over 700 packages to go through and Cnchi does not give us a clue as to which one caused the problem.
I ended up trying Reborn OS in a VirtualBox machine and on my laptop. In both cases I quickly ran into a dead end with the distribution. This was frustrating as it means that, despite the assurances of the developers that the system should now be reliable, the installer issue has not been fixed. If anything, it seems new stability issues have crept in since the last time I used the distribution.
I have been told the Reborn team is working on their own installer to replace Cnchi. Hopefully the new installer (which has not appeared yet at the time of writing) will make setting up the operating system more straight forward.
* * * * *
Next on my list of projects to try was one I had not downloaded before: TinyPaw-Linux. The distribution's website describes the project as "an extremely lightweight and portable WiFi pen-testing distro. One that wasn't bloated with non-essential tools and features and that could actually boot, run and perform from CD or USB."
TinyPaw is based on Tiny Core Linux. While the project has a tiny parent and began as a relatively small distro, it has grown quickly in size. Version 1.0 was published in December 2017 and was 294MB in size. Version 1.3 was launched in October 2018 and was a 740MB download. I suspect the extra weight was introduced through new packages and WiFi testing tools.
The latest version appears to be based on Tiny Core Linux 9.0. Booting from the project's live media loads the distribution into RAM, making it highly responsive. At least it does if the distribution completes the boot process. I began by running TinyPaw on a laptop and, though the system started its boot sequence and was able to load modules into memory, it then locked up, unable to get to its graphical interface and unresponsive to keyboard input.
I switched to trying TinyPaw in a VirtualBox environment and had better luck. The distribution booted into a minimal graphical environment which carries a strong red on black theme. A panel at the bottom of the screen holds quick-launch buttons for various WiFi tools, network scanners, a settings panel and a lightweight web browser called Fifth. There are also launchers for a virtual terminal, a text editor and the PCManFM file manager.
TinyPaw-Linux 1.3 -- The Fifth web browser and TinyPaw's settings panel
(full image size: 155kB, resolution: 1024x768 pixels)
Right-clicking on the desktop brings up an application menu which helpfully organizes tools into categories. This makes it easier to quickly find networking tools as opposed to password crackers or scanners.
I played around with a handful of the included utilities and found most of them worked. This allowed me to scan the network, try to brute force passwords and collect network traffic. Some tools did not work though. One would open a blank window that closed after a few seconds, one of the password crackers reported it was missing dependencies and refused to run. For the most part, TinyPaw gave me functioning tools, but occasionally one would fail or simply not run.
A bigger issue I ran into is that TinyPaw includes no manual pages and no local documentation for the tools it features. This means if we don't know what an application does, or we know what it does but want to learn how to use a command line parameter, we need to go on-line and search for the answer. This introduced a series of speed bumps into my trial since anytime I wanted to use a new tool I had to open a web browser, search for the tool, go to its website, hope the utility had on-line documentation and read that. This is quite a bit slower than just opening a local manual page.
A positive side-effect of having such a trim distribution (one without documentation and a full featured desktop environment) is the whole distribution only requires about 300MB of RAM. And it appears as though the distribution runs entirely from within memory, making programs open very quickly.
I had mixed feelings using TinyPaw-Linux. On the one hand, it does ship with some useful penetration testing tools and the platform is small and fast. However, the lack of local documentation and my inability to get the distribution to boot on physical hardware made it impractical for most scenarios in which I would want to use such a tool.
|Miscellaneous News (by Jesse Smith)
Debian tests Secure Boot, Ubuntu shipping on Entroware AIO, most highly popular Steam games run on Linux
The Debian team is experimenting with booting their distribution on machines with Secure Boot enabled. Secure Boot strives to prevent the user from booting into compromised environments by checking for signed low-level components. This poses some challenges for Linux users who may have unsigned or custom kernels. People interested in helping Debian work out the bugs in their Secure Boot solution can follow the instructions in the project's wiki.
* * * * *
Entroware is a computer manufacturer in the United Kingdom which sells personal computers and servers with Linux pre-installed. The company has unveiled a new all-in-one (AIO) system called Ares PC that ships with the customer's choice of Ubuntu or Ubuntu MATE. Forbes comments: "The baseline Ares starts at £739 (about 824 Euros) and includes a 24-inch 1080p matte display with built-in speakers, Intel Core-i3 8100 at 3.6GHz, 8GB of RAM clocked at 2400MHz, a 120GB SSD loaded with your choice of Ubuntu or Ubuntu MATE and a 3 year warranty. From there you can tinker with several upgrade options, stretching all the way to the fully-loaded £2689 Ares. Considering the size, it can pack a pretty considerable punch with a 6-core, 4.6GHz Intel Core-i7 8700, 32GB of RAM, and a 2TB NVMe SSD plus an additional 4TB SSD drive. You can also bundle an additional monitor, but it doesn't look like Entroware offers a 4K display option." Further details can be found on the Entroware website.
* * * * *
Linux gamers should be pleased to learn that more and more popular gaming titles are becoming available. The GamingOnLinux website took a look at the most popular titles on Steam and discovered over half of the top 250 offer support for Linux. "Overall, out of the 250 most highly rated titles on Steam as reviewed by users, 132 of them have official Linux support. Compared with Mac which has 156, we're not far off there at all. Let's just remember how small the Linux gaming platform is compared to Windows, over 50% there really is impressive."
* * * * *
These and other news stories can be found on our Headlines page.
|Questions and Answers (by Jesse Smith)
Dealing with an unresponsive desktop
Purging-pop-ups asks: Earlier this year I switched to using Linux, specifically Ubuntu for my computing needs. I am running a background job that requires a lot of CPU, like 100% all the time, and it is making my desktop virtually unusable. Input is slow and I keep seeing pop-ups telling me "This application is not responding - close or wait?" Why does having just one big background process bring Linux to its knees and what can I do to fix this?
DistroWatch answers: Welcome to the Linux community, I'm glad you could join us. There are a number of ideas and issues to explore in this situation so first let's take a look at the surface of the problem and then we will explore some possible underlying causes and solutions.
It sounds like what is happening is your one CPU-intensive process is using all the available resources and it is slowing down everything else, including the desktop environment. When the desktop is starved for resources, applications are not processing input quickly enough to appear "alive". When this happens, the system thinks the program might have crashed and offers to get rid of it. In this case, the applications are not actually crashing, they are just too resource hungry to respond.
Part of the issue here is that Linux tends to favour overall work performance over responsiveness. In other words, Linux will try to accomplish as many things as possible in a given amount of time, rather than making dealing with new input and generating a response its priority. This is ideal for servers and number crunching workstations, but not so great for people using the desktop under heavy load. There are ways to change the way Linux schedules tasks to try to get a more responsive user interface, but it is a technical path to walk and tends to involve re-compiling the kernel, and I think there are probably easier ways to address this situation.
Without the specifications of the computer and information on the processes (and constraints) the system is running under, the best course of action is hard to predict. However, I do have a handful of suggestions for situations like this that will hopefully help.
First, you mentioned the system is running Ubuntu, which suggests either the GNOME Shell or Unity desktop is being used. Both of these desktops use 3-D effects which require support from the video card to draw smoothly. Having a video driver that does not perform well puts more work on the CPU to make up the difference and can bring even modern machines to their knees. This typically happens if your machine is running an AMD or NVIDIA card. Almost all the reports I encounter from people saying Ubuntu runs too slowly or their desktop is not responsive can be traced back to a driver issue. Run the Software & Updates application and click on the Additional Drivers tab. This will show alternative drivers which may work better with your video card.
Second, it sounds like this background task is not being polite and gobbling up all the CPU resources it can find. This is going to slow down any system and is not ideal for a desktop machine. Ideally it would be nice to run such a heavy process on its own, dedicated machine, but if that is not possible, we can force the process to act in a more polite manner.
There are tools, called nice, renice and ionice, which will allow a program to run at full speed, but force it to stay out of the way when another program wants to work. This is done by lowering the heavy process's priority. When nothing else is happening on the system, the process can work as hard as it wants, but its reduced priority means other programs (like desktop applications) can interrupt its work.
We have talked about how to adjust the priority of programs previously in an earlier Tips and Tricks article.
A third possibility is the big background process is not only consuming a lot of CPU, it is also consuming memory. When too much memory is used up, the operating system dumps some memory out to swap space, which then needs to be read back when a program wants to use it. You can run the free command to check memory consumption.
If the computer's memory is full and it is starting to use swap space to make room for the heavy process, then there are only so many things you can do. You can run fewer applications and services, or add more RAM to the system.
Finally, so far as I know, there is no way to disable the pop-up which says a task has stopped responding. At least not without editing and re-compiling the window manager. However, you could try switching to a lighter desktop. Assuming you are running either Unity or GNOME on Ubuntu, these are relatively heavy desktops. Since you are running a CPU-heavy process, I think it makes sense to trim as much of the software as possible on this system. Installing a lighter desktop, such as Xfce or LXDE, will free up more CPU and memory for the heavier program.
* * * * *
Additional answers can be found in our Questions and Answers archive.
|Released Last Week
Funtoo Linux 1.3
Daniel Robbins has announced the release of Funtoo Linux 1.3. Funtoo, a variant of Gentoo Linux, is an distribution that builds packages automatically from the source code. It was launched in 2009, shortly after Robbins left Gentoo Linux, a project he had founded in 2000. Version 1.3 brings a deprecation of "multilib" support, among other changes: "The ability for 64-bit versions of Funtoo Linux to run legacy 32-bit applications has been deprecated, so that Funtoo Linux for 64-bit CPUs is now 64-bit only, what we used to offer as a separate "pure64" build. This was done because 32-bit support was originally created as a stop-gap measure 15 years ago to allow for a seamless transition to 64-bit computing, and we believe the time has come to shed this ongoing maintenance burden and focus efforts that have historically been spent on 32-bit compatibility in other areas." Read the release announcement and release notes for more information. The Funtoo project does not provide bootable live or installation ISO images; users are instead directed towards the Gentoo-based SystemRescueCd to initiate any new installation. Optimised builds (or "stages") are available for various AMD and Intel processors, as well as the ARM and ARM64 architectures and Raspberry Pi and ODROID single-board computers - visit the project's "Subarches" page for a complete list.
Qubes OS 4.0.1
Marek Marczykowski-Górecki has announced the release of Qubes OS 4.0.1, an updated version of the project's security-focused Linux distribution which allows users to "compartmentalise" computing tasks into isolated compartments called qubes. This new release is mostly a bug-fix and security update and is recommended for all new Qubes installations: "We are pleased to announce the release of Qubes 4.0.1. This is the first stable point release of Qubes 4.0. It includes many updates over the initial 4.0 release, in particular: all 4.0 dom0 updates to date, including a lot of bug fixes and improvements for GUI tools; Fedora 29 TemplateVM; Debian 9 TemplateVM; Whonix 14 Gateway and Workstation TemplateVMs; Linux kernel 4.14. If you're currently using an up-to-date Qubes 4.0 installation (including updated Fedora 29, Debian 9, and Whonix 14 templates), then your system is already equivalent to a Qubes 4.0.1 installation. No action is needed. Similarly, if you're currently using a Qubes 4.0.1 release candidate and you've followed the standard procedure for keeping it up-to-date, then your system is equivalent to a 4.0.1 stable installation." Read the rest of the release announcement for additional information.
Clonezilla Live 2.6.0-37
Steven Shiau has announced the release of Clonezilla Live 2.6.0-37. Clonezilla Live provides tools for backing up, restoring and copying disk images and disk partitions either locally or across the network. The project's latest version includes several updates and fixes. "The underlying GNU/Linux operating system was upgraded. This release is based on the Debian 'Sid' repository as of 2019-01-08). Linux kernel has been updated to 4.19.13; Partclone to 0.3.12; ldmtool and haveged packages have been added; cURL has been added; NetworkManager has been added so that users can use 'nmtui' to configure network if necessary, especially for WiFi; making unknown fs as 'dd' and the image name for partition like sda3.dd-img.aa is now legacy - it has been replaced by sda3.dd-ptcl-img.lzma.aa; rewrite the same mechanism in ocs-onthefly; in addition to massive-deployment mode, the interactive-client mode was added so that lite server can provide the ability to enter interactive mode of Clonezilla Live in client; let live-build 20180618 handle uEFI boot, so ocs-put-signed-grub2-efi-bldr and ocs-gen-grub2-efi-bldr are deprecated." Further details can be found in the release announcement.
* * * * *
Development, unannounced and minor bug-fix releases
The table below provides a list of torrents DistroWatch is currently seeding. If you do not have a bittorrent client capable of handling the linked files, we suggest installing either the Transmission or KTorrent bittorrent clients.
Archives of our previously seeded torrents may be found in our Torrent Archive. We also maintain a Torrents RSS feed for people who wish to have open source torrents delivered to them. To share your own open source torrents of Linux and BSD projects, please visit our Upload Torrents page.
Torrent Corner statistics:
- Total torrents seeded: 1,197
- Total data uploaded: 23.3TB
|Upcoming Releases and Announcements
Summary of expected upcoming releases
Tools to keep processes in line
Sometimes processes use more resources than they should, interferring with the smooth operation of the rest of the system. When this happens there are several tools a system administrator can use to prevent these runaway processes from having a negative impact. We would like to know which process taming tools our readers use.
You can see the results of our previous poll on running distributions for a long time in last week's edition. All previous poll results can be found in our poll archives.
DistroWatch database summary
* * * * *
This concludes this week's issue of DistroWatch Weekly. The next instalment will be published on Monday, 21 January 2019. Past articles and reviews can be found through our Article Search page. To contact the authors please send e-mail to:
- Jesse Smith (feedback, questions and suggestions: distribution reviews/submissions, questions and answers, tips and tricks)
- Ladislav Bodnar (feedback, questions, donations, comments)
- Bruce Patterson (podcast)
|Linux Foundation Training
|Reader Comments • Jump to last comment
1 • Processes and System Down - systemd. (by Modus Operandi on 2019-01-14 00:30:42 GMT from United States) |
"Sometimes processes use more resources than they should, interferring with the smooth operation of the rest of the system. "
- They (processes!?!) always do, as usual.
As we already know by now,
systemd means system DOWN as three more serious vulnerabilities found.
- CVE-2018-16864 and CVE-2018-16865, two memory corruptions
- CVE-2018-16866, an information leak (an out-of-bounds read).
I am too nice to keep at least one of my finger always on power-off button.
I never take computing too seriously.
2 • Processes and System Down (by mmphosis on 2019-01-14 01:44:54 GMT from Canada)
Tools to keep processes in line -- I choose Other: "Ideally it would be nice to run such a heavy process on its own, dedicated machine" This what I do.
I am also finding Ubuntu less and less desirable as there are a lot of things installed and running that I do not want installed and running. I am looking at you systemd. There are some cron jobs that I have removed because I don't need them to run, but I shouldn't have to do this. I do like Void Linux, some of the other rolling release Linuxes, and leaner distributions -- as long as they work. I've also been considering Linux From Scratch but that is a lot of work with the advantage of knowing what you've built and installed.
Ubuntu crashed today, reboot, unknown what caused the problem -- makes me think about Void Linux again. On the other hand, there are lots of applications in Ubuntu that work seemlessly with little to no configurating. Configurating is annoying, I shouldn't have to do this.
3 • Dealing with Run-away Processes (by Bruce Fowler on 2019-01-14 03:07:11 GMT from United States)
I run "conky" in a bar at the bottom of my screen. If resource consumption is getting excessive, I use "top" to find the offending process and "kill" to stop it. If the desktop is locked up, then I try to open a text terminal "CTL-ALT F2" and go from there. The power switch is a last resort. This situation does not occur very often in normal desktop use, Linux is much more dependable than certain other commercial OS's.
4 • Chnchi (by linuxista on 2019-01-14 03:13:58 GMT from United States)
>I have been told the Reborn team is working on their own installer to replace Cnchi.
Great idea. Antergos' installer has failed me every time I've tried it.
5 • Processes (by Trihexagonal on 2019-01-14 03:59:52 GMT from United States)
I keep a terminal open with top running at all times on my BSD boxen so I can keep an eye on processes.
6 • Freezings and slugginess (by Alburgheiro on 2019-01-14 05:25:51 GMT from Russia)
It is hard to tell what is the cause of an unresponsive desktop without having more information.
In my own experience:
- If the desktop becomes completely unresponsive needing a hard reboot, the most likely cause is the graphics card drivers or a hardware issue. You can try different driver versions and also check if the card is overheating. Disabling all the desktop effects and/or switching to a lighter desktop environment is also worth trying. If a notebook, it may be a problem with the fan or with the thermal paste.
- If the desktop becomes sluggish but not entirely unresponsive (and you are not running calculations on your GPU) it is often a problem of the system switching to swap memory (namely if it resides on a spinning drive). You may want to check whether this is the case and tune the swappiness parameter. If that is not enough, you may need to consider upgrading your RAM.
- In my experience, it is less usual that the cause is a CPU-hungry application, unless if your resources are very limited or the code is not very good. In that case, you may want to tune the allocated resources or niceness, as explained, or just switch to another software.
- Finally, you should be aware of the fact that certain Trojans and websites may be using your CPU/GPU to mine cryptocurrency or the like.
7 • Tools:other (by Saladin on 2019-01-14 08:04:22 GMT from United Kingdom)
Jesse's "Finally..." - another DT (Xfce) has always worked for me and meets the K.I.S.S. principle.
8 • Gaming on Linux (by Muvori on 2019-01-14 09:23:27 GMT from Netherlands)
Over 50% of popular Steam games are natively supported, but due to the recent Steam Play update, which included Proton (Wine), you can run almost all games on Linux! Way more than you can play on MacOS at least.
9 • Desktop freezing question (by Dxvid on 2019-01-14 09:29:12 GMT from Sweden)
Sometimes my desktop freezes (KDE on X with official Nvidia drivers), and I often find it has to do with a background process related to HDD/SSD background maintenance using up 100% of 1 or 2 of the 8 vCPU cores, so 50% or 100% of one real CPU core. Htop/top/KSysGuard will report CPU-usage for a process of around 12,5% to 25% and at this time the desktop can get frozen but not always. Freezing can vary from 0,5 seconds to around 10-15 seconds and can happen maybe once or twice per month per computer. Swap is never used, and there's always plenty of available RAM memory.
Does anyone know if this is because the desktop is waiting for the SSD/HDD to become available or if Linux and/or X and/or KDE isn't smart enough to use the other CPU cores that are available?
My guess is that X or KDE is waiting in a queue to be able to access the SSD/HDD and that the cron jobs doing various types of disk maintenance have higher priority, but how can I check for sure what's really causing the problem? Is there a log file or other file I can check afterwards to find what caused the problem? I'm not talking about logging process CPU or I/O usage, but instead logging of errors/warnings and/or wait time and/or cause of the freezing.
There's no difference if the system disk is a SSD or HDD (storage disks are always HDD), it can happen on any machine but not regularly. Most likely it happens if a problem is found and fixed in the background on one of the disks, but that's just my guess.
If a machine doesn't have a desktop environment, it's much more difficult to notice a freeze but it might happen even on servers. Sometimes whether it's Ubuntu or OpenSUSE a server's SSH will become unresponsive for a few seconds, and maybe it has the same root cause, but it's not as easy to know as there can be internet related problems causing SSH to become unresponsive, or virtualization problems. I've never experienced freezing or unresponsiveness on SLES whether using Gnome with X or SSH, but I don't know if it's because of luck or less load or less disk problems or "better" distro.
10 • 2 mmphosis - Processes and System Down (by EarlyBird on 2019-01-14 11:08:42 GMT from Canada)
2 mmphosis - Re: "I've also been considering Linux From Scratch but that is a lot of work with the advantage of knowing what you've built and installed"
You might want to look at the Nutyx distro. It is based on LFS and BLFS. I haven't had a chance to try it yet, but from description, looks like a good starting point that might meet your criteria.
11 • Cnchi (by Eureka on 2019-01-14 11:18:19 GMT from Switzerland)
Cnchi is the worst installer I had to use. It always failed to install Antergos on real hardware and installed once in VM. For this reason I gave up trying Antergos and I will not try Reborn OS. I really do not understand those distro developers who are putting the end user in front of a bad installer. It is just so unrespectful. This gives a very bad, unprofessional image of Linux.
12 • @1,2,3,5,6,7,9 Desktop (or computer) freezing. (by Greg Zeng on 2019-01-14 11:22:09 GMT from United Kingdom)
Glad to see reality now, with its real life troubles. Any computer operating system is NOT always fun, if it slows or stops itself. More operating systems need real-time monitoring for abusive processes. HTOP is not supplied with many standard systems. If it is supplied, the Linux operating system cannot easily be configured for user access.
Similarly my preferred real time monitor is GKRELLM. Seems that few if any Linux user know how to configure this essential program. The correct "GUI" needed to KILL bad run-away processes is HTOP. Both Linux applications suffer from poor understanding of the necessity & importance. Only in the PCLOS operating system is GKRELLM given some more attention than the default settings. Even in PCLOS however, GKRELLM is not properly installed, by default. Linux has yet to create the equivalent to Windows' "Process Lasso", which combines real-time monitor, automatic process moderation and easy killing-taming of runaway processes.
Hopefully the newest Linux kernels released by "The Linux Foundation" better handle multi-process
CPU's. Reports (Twitter) on server performance with the 4.20 kernel appear quicker operations, & less resource hogging. The promised Linux Kernel 5.0, due in several weeks, should hopefully handle true multi-process hardware soon.
13 • Why would you have not seen this subject 5 years ago?... (by R. Cain on 2019-01-14 12:21:02 GMT from United States)
The answer is contained in one word:
14 • conjecture (by Trihexagonal on 2019-01-14 13:21:39 GMT from United States)
@12 I have used Gkrellm since 2002 and it is pictured in every one of my screenshots. I have a page of them on my site and many in the FreeBSD forums.
I usually keep two terminals open at all times. One to work from and use if I need to become root and another terminal open to work from my use account if I'm root in the first.
I keep the second running top at all other times to keep an eye on processes since it's already open.
15 • Reborn OS (by Pat Menendez on 2019-01-14 02:53:16 GMT from Canada)
I'm sorry to hear you had trouble. I've run Reborn OS for a year. XFCE, LXQT, and Plasma. Other than the bugs and windoze inspiration (bugs, missing pieces) inherent in Plasma this is the fastest, most stable, most responsive distro I have ever run. 8th gen i5 8600K @ 4.7 GHz, Nvidia, 8th gen i3 8350K @ 4.4 GHz, Nvidia, 2nd gen i5 2550K @ 4.4 GHz. Radeon. A year ago when I built the two 8th gen systems reborn OS ran by far the best and most stable of any distro I tried. Most wouldn't even boot the DVD or wouldn't install. They just couldn't handle all 8th gen hardware. The original LXQT installation on the i3 is still working 100%. My cousin is really impressed and loves Reborn OS I installed on his i3. The 8th gen i5 started LXQT and a couple months ago I "upgraded" to Plasma. LXQT is more stable and reliable than Plasma! I prefer the look of QT but will probably go back to LXQT. My years old unsupported KDE-4 is still more reliable and does what I want to do more and better than Plasma.
16 • Tools (by Argent on 2019-01-14 20:25:42 GMT from United States)
Many have commented on systemd as the culprit for man issues. Not a boogie man person but there are open ports on a systemd machine in idle while not so in non-systemd machine. Have tested many distributions both systemd and systemd-free and yes the CPU behaves strangely. Like the CPU fans running on high with no applications open and there are open ports according to a conky I use for testing or to monitor processes.
Systemd distributions will be very much like Windows in the next couple of years.
17 • Tools (by R. Cain on 2019-01-14 21:27:04 GMT from United States)
"Ubuntu refuses to reboot - what now?”
"... this is another instance that shows the limited usefulness of the systemd framework..."
"...a little more understanding into the chaos that is the Linux boot sequence post init [i.e., since sysvinit was abandoned in favor of 'systemd']...
"Systemd – Progress Through Complexity"
"...Except we’re going to talk about something that is clearly not progress. Systemd..."
"...System V and init are probably not ready to be [relegated] to history, especially not when Systemd is the current proposed alternative. It simply does not have what it takes to be the superior functional and evolutionary replacement..."
18 • Tools (by Rooster12 on 2019-01-14 22:05:35 GMT from United States)
@ 16 Argent: Systemd distributon are about 20% larger than a non-systemd distribution, there could be embedded applications using those ports. No expert but find the phenomena a bit strange because have pondered in the past what the issues were causing me to replace perfectly good PC components like HHD, CPU and video card driving to eliminate the issues.
A systemd-free distribution works without much of the strangeness, especially open ports at idle as you mentioned.
19 • non-systemd distros (by Jordan on 2019-01-14 23:23:59 GMT from United States)
Made me look...
20 • Tools to keep processes in line (by John on 2019-01-15 01:34:49 GMT from Canada)
I use nice/renice, but what I found is nice does not 'slow things down' as I would like. So to prevent CPU temperature spiking I will kick of a script that does something like this:
kill -STOP pid
sleep "so many seconds"
kill -CONT pid
sleep "so many seconds"
inside a loop as long as the pid is active. I do this when time is not an issue, plus it will keep the CPU from running hot 100% of the time.
I have something like this running right now and it has been running for a while.
21 • @16-Tools; Systemd distributions will be very much like Windows... (by R. Cain on 2019-01-15 01:52:37 GMT from United States)
"Upgraded Ubuntu 18.04 suddenly boots slowly? Read this."--
"...After the successful upgrade, I noticed a super-slow boot on the Lenovo system...The time to reach the desktop went from an okay 60-seconds to a horrendous 4-minute mark..."
"...Systemd is not a friendly thing - in fact, it makes system troubleshooting much more difficult than it should be, because it's a tool designed by someone who doesn't really do system troubleshooting....Like weapons designed by bureaucrats..."
"Modern software development is cancer"--
"...a very much similar platter of emotions erupted in my being while fiddling with systemd and trying to solve problems that were created by, guess, systemd, a complicated pile of code with no other purpose other than to be a complicated pile of code..."
"...Then, suddenly, we have this new binary diarrhea...for the past five years, this unstable, half-baked, undebuggable nonsense is the backbone of most Linux distros...has also affected the stability of the user space, the very thing it should never have touched...all problems with the quality of the Linux desktop nicely coincide with the introduction of systemd...for no good reason than trying to reach the level of stability, maturity and functionality that we had half a decade ago. Someone landed themselves a lot of monthly pay checks by writing complex code to solve a problem that did not exist..."
22 • @18 :Tools (by R. Cain on 2019-01-15 02:30:35 GMT from United States)
"...Systemd distributon[s] are about __20% larger__ than a non-systemd distribution..."
Mint Linux 17.3, DistroWatch's 'at-one-time' #1 distribution, and rated the very best of ALL Linux distributions--of any type--going into 2017, was a non-'systemd' distribution, with a download size of 1400 MB. It is STILL considered to be one of the very best of all Mint distributions.
Mint Linux 18.3, Mint's next new and improved most stable 'systemd' version was an 1800 MB download; an increase of over 28% over version 17.3,'was riddled with bugs--some of which have not been addressed to this day--and which started Mint's long, slow slide out of DistroWatch's 1st place which continues to this day.
@ 18 --This is the only distribution on which I have data, but this certainly bears out your "...20% larger..." statement.
23 • Extreme slowness after an upgrade (by RJA on 2019-01-15 02:34:59 GMT from United States)
@21, the hard drive, especially if it's a Seagate Momentus, is a suspect. HDD failure can have similar symptoms!
If it's a laptop, the HDD is very much a suspect. Especially appearing to craw at PIO speeds for no good reason.
24 • persistent processes (by greenpossum on 2019-01-15 03:31:57 GMT from Australia)
How can I get rid of whinges about systemd on DW? SIGBORED doesn't seem to work. ;) ;)
25 • systemd (by edcoolio on 2019-01-15 05:00:46 GMT from United States)
@24, Spot on. I have been wondering the same thing. DW anti-systemd spam defender??
As for tools to keep processes in line, I found the article helpful. Immediately after a distro installation, I disable all background applications/services/ports/etc on a distro which are not needed for my purposes. Then, it is just a matter of hunting down rogue processes using htop.
I believe the QA this week unintentionally raises a good point. I am of the opinion that memory use is a good starting-point of how light a distribution can be in its default state. However, memory use alone is not always an accurate indicator of responsiveness in comparison to other distros.
To be specific, a distro may have very light RAM usage in default configuration while simultaneously containing a process that hogs CPU/GPU cycles. A comparison chart would be most useful.
I would really like to see a review chart that quantifies CPU/GPU usage of distros that are 64 bit "heavy" and "light" categories. Additionally, a 32 bit "light" category should also be included. These comparisons can be made while idle and also while running a modern browser in both a weak internal and dedicated graphics environment.
Sounds like a ton of work, but man, it would be cool.
Well written QA, review, and poll.
26 • whinging (by Gary W on 2019-01-15 06:11:15 GMT from Australia)
@24 The exit is nearby, under your keyboard.
Whinges about systemd are on-topic (IMHO). Meta-whinges are not.
27 • @26 (by greenpossum on 2019-01-15 07:07:49 GMT from Australia)
It's boring to those of us who have learnt to work well with both init systems, both for work and for personal use. Always easier to blame the software than a lack of willingness to learn. But there are lots of distros for the SysVinit crowd so what's the problem?
28 • @25, Here's a start (by Angel on 2019-01-15 08:14:40 GMT from Philippines)
All running on a Gigabyte Mini desktop, i5-7200U, 240 GB SSD, 8GB RAM.
Idle: cpu 3%, Proc 194, Mem 476MB. With Firefox: cpu 5%, Proc 198, Mem 1GB
Idle: cpu 2%, Proc: 182, Mem: 406MB. With Firefox: cpu 5%, Proc 187, Mem 1.2
Idle: cpu 3%, Proc 142, Mem 455. With Firefox: cpu 5% Proc 145, Mem 1.05GB
As you can see, little difference between them.
29 • What might be eating memory in Gnome shell then? (by Akoy on 2019-01-15 11:28:42 GMT from United Kingdom)
KDE, XFCE idles at quite low memory, while Gnome eats a lot, nearly 1GB. What might be eating that memory at idle in Gnome?
30 • systemd (by Jordan on 2019-01-15 17:20:48 GMT from United States)
The systemd discussion is back. It's been a while.
I can't be a voice of reason in this.. I see compelling notions and real info about systemd and non-systemd distros. All I can offer is that link I posted above as to non-systemd distros out there:
Most of you very savvy people in this discussion have them memorized, I'm sure.
Linux, as always, is about choices. We can hash out how we feel about this or that aspect of linux distros, but, in the end, we can all do something that Windows people cannot do: we can make choices that fall into place with our feelings about those linux differences.
31 • @27: (by dragonmouth on 2019-01-15 23:03:39 GMT from United States)
Bully for you for having learned how to work well with systemd! Thousands of other Linux users have learned also and that is precisely why they are able to point out the faults and problems of systemd. Even though tens of millions of users have learned to "work well" with the most widely used O/S in the world does not change the fact that Windows has severe problems and it is their that familiarity that allows the users to recognize that fact.
You need to get your head out of the sand and realize that systemd is not some Sacred Cow that cannot be criticized and/or that it is The Greatest Thing Since Sliced Bread.
32 • @31 (by mandog on 2019-01-16 03:02:37 GMT from Peru)
I really think its people with mind sets like you that need to get their heads out the sand,
systemd is fine boots faster than sysV 30secs systemd 15secs for gnome3.gnome also starts at 380-400 mb on a real linux system that embraced systemd not a half cocked Debian/Ubuntu effort.
Now if you really want to talk inits, simplicity, and boot speed, then you need to talk runit or S6. But i suppose that is beyond the realms of the DW expert commentators.
33 • @32 Mandog re inits (by Newby on 2019-01-16 03:25:28 GMT from Canada)
Actually, would REALLY appreciate it if you could expound upon runit and S6. Have seen references to runit being used with some distros (don't recall which; maybe some embedded apps?); not at all familiar with S6.
Could you, or perhaps anyone else here, discuss the relative merits, differences, and setup of runit and S6 vs sysvint? Links to examples/tutorials would be useful as well.
(Not interested at all in systemd, because it completely breaks philosophy of being an editable text file, and tries to take on more than just be a simple init).
34 • In *my* day (by CS on 2019-01-16 04:19:28 GMT from United States)
In *my* day we didn't have any of this fancy systemd crap! We kept all our init logic in /etc/rc and we loved it! You snot nosed little punks can't deal with a little spaghetti code? Go get yourself a real computer! One that runs at 40 MHz with 8 MB of RAM! Now that's a real system. None of this complex crap they're churning out these days.
And don't even get me started on this software bloat! 1.8 GB? Christ sake! 1.8 GB of SSD costs almost $0.16! In my day you could buy a 3 bedroom house for less! What are you whippersnappers doing with all that crap anyhows???
35 • @32 - boot times (by Hoos on 2019-01-16 07:14:31 GMT from Singapore)
Surely the systemd debate is more than about boot times. But I won't go down that road.
Manjaro XFCE (systemd) and MX (sysV, also XFCE) both have similar bootup times on my machine, around 15 secs on different partitions of the same HDD. This is from grub menu to lightdm login screen.
In fact, I recall timing and posting in DWW at least a year ago that I thought the MX bootup was slightly faster, being around 10+ secs. But what's a few seconds? I don't hold it against either distro.
On a separate SSD install (same computer), MX's bootup time is 5 secs.
36 • Systemd (by Alburgheiro on 2019-01-16 07:40:58 GMT from Russia)
Systemd is not just an init system. It is a huge user-space wrapper around the kernel that aims at controlling most, if not all, administrative functions of your operating system. A huge binary blob growing bigger and bigger by the hour, it will soon be the most important piece of software within a Linux distro, right after the kernel. The final goal may be even to replace the Linux kernel with a Systemd fork.
So, if there are bugs, performance or security issues within systemd, it is a very serious matter that needs to be discussed. Here or elsewhere.
37 • @36 SystemD (by Angel on 2019-01-16 10:28:32 GMT from Philippines)
I'm sure a discussion on the pluses and minuses of systemD is warranted and could be interesting, a constructive discussion, that is. It is not, however, constructive to spout negative generalities, most of which were read somewhere and accepted as credo ("It's a cancer." "It's this or that evil thing.") with no specifics of the poster's own experience and knowledge. No disagreement is to be brooked. Read your own post. It's the same generalization I've read many times, in almost the same exact words, here and elsewhere. There are some posters on this forum whose views on the subject would merit attention and respect: anticapitalista (antiX, MX) for one, Mandog, et al. But those leading the charge seem to be the shouters of emptiness.
38 • @31 SystemD, (by Rupert A. on 2019-01-16 11:56:10 GMT from Canada)
Hah! "Head-in-the-Sand versus Chicken Little" might make a good X-Men epic, or maybe a pro-wrestling match, but it helps no one here with inits now, does it?
39 • @# 30 and # 38 systemD - system Dislike it, (by Donnie Disklikedit on 2019-01-16 19:27:10 GMT from Canada)
@ # 30
link to non-systemd is memorized by heart now.
@ # 38
At least I am the only one here who like systemd, even if system(s) dislikes it (i mean systemd). I like it because I always install systemd distros on the system(s) from people which I really do not like as a maintenance guy.
In this way, systemd performs the great, at least for me even though system itself does not like it and starts puking.
40 • a more comprehensive list (by tim on 2019-01-17 02:26:33 GMT from United States)
wiki contains a much more comprehensive list than the one linked earllier (and "memorized"?)
41 • @33 runit (by mandog on 2019-01-17 02:51:40 GMT from Peru)
I'm not at home for a few weeks runit is used by void linux I think since 2008 its very light and fast will give very fast boot times, services need to be set by the user as with openrc, this for me gives better user control like the original arch bsd scripts its about simple.
S6 is a continuation of runit a gives really improved boot times and slightly better control.
I feel I must just clear one very large myth on systemd the rubbish that is posted here consistently about non human readable systemd, that is total garbage posted by fools kidding themselves. Just open a terminal systemctl is the key command so systemctl failed will list all fails loading the kernel last boot, humanly readable for any user no reams of unwanted info to wade though and all in simple terms.
That is not to say I prefer systemd I use mainly openrc and S6 but I don't find it the monster it is made out to be when implemented correctly In fact it is easier to use and diagnose with systemd.
42 • Systemd (by Alburgheiro on 2019-01-17 04:28:00 GMT from Russia)
What you need to consider is that not all the people using Linux-based distros are hobbyists or distro-hoppers.
Some people actually use Linux for work.Like, for instance, machine learning and other kinds of resource-hungry tasks.
Those people do not care about boot times. For those people, a Desktop Environment is just some kind of convenient/necessary evil.
Those people tend to prefer systems that are transparent, fully customizable, predictable, secure and stable. Systems that do not get on your way or decide what is best for you.
Unfortunately, systemd is the exact opposite to all that. So, from the point of view of the number-crunching community, the widespread adoption of messy blobs such as systemd by all the major Linux distribution is a woeful disgrace.
I do not care how well it works for you, for me it is just a superfluous waste of my valuable resources and a source of instability, unpredictability and security breaches. It represents t
he despotic Windowsisation of Linux "for our own good".
We understand you, desktop people, because we also use desktops and we notice Linux' deficiencies on that domain. Can you please make the effort to understand us? We need no-nonsense mainstream distros.
Finally, consider this, distro developers, Linux will never be hegemonic for the casual/office desktop user, but it will be hegemonic for the ever-growing scientific/number crunching/machine learning communities. We are the future of Linux. We matter.
43 • @41 mandog re init systems (by newby on 2019-01-17 05:27:16 GMT from Canada)
Thanks for reply. Understand issuing systemctl from terminal will bring up info. But doesn't systemd REPLACE the /etc/rc text-based scripts with a binary, in which case you can't use a text editor (hence need for systemctl)?
Come to think of it, suppose I could actually test this by downloading a live systemd distro, and see if it still uses /etc/rc scripts, or if that has been replaced with a non-text editable binary.
Being new at this, was trying to understand/visualize startup sequence and difference for the various schemes (sysintv, openrc,runit.s6, etc). Some linux books from library only discussed /etc/rc scripts. That's why was looking online for step-by-step direct comparison of each scheme.
As you indicated, found many opinions, but no specific "this is what happens, and these are the consequences. Perhaps I need better search terms skills.
Also thanks for reference to Void.
44 • @43, init systems Void, Artix (by Angel on 2019-01-17 06:26:31 GMT from Philippines)
Mandog didn't mention Artix Linux, an Arch-based little distro with openrc or runit. Easy install, can be downloaded with LXQT or just a base to finish yourself. I've tried both on Virtualbox. Nice. Void ran well on Vbox live, but did not boot to a DE after install. Have to try it again when I have time.
45 • @44 - Void (by Hoos on 2019-01-17 07:46:27 GMT from Singapore)
"Void ran well on Vbox live, but did not boot to a DE after install"
Depends how you initiated the install.
To install with the DE you were running on the live system, you need to choose "local install" instead of "from local network":
See the notice here: https://voidlinux.org/download/
This will install all included packages "as is" from the iso to your computer, no matter how old the packages are.
If you install from local network, you'll get the most updated packages but only in respect of a minimal, no-DE installation.
46 • systemd (by Jesse on 2019-01-17 12:50:23 GMT from Canada)
@43: >> "Understand issuing systemctl from terminal will bring up info. But doesn't systemd REPLACE the /etc/rc text-based scripts with a binary, in which case you can't use a text editor "
Not exactly. systemd replaces traditional rc scripts with unit files. The unit files are short, simple text files which describe what a systemd unit does, what it relies on and what it provides. It's basically the same information you find in an rc script's LSB header section. A systemd unit file is actually easier to read (and edit) than most rc scripts because it's short and to the point.
The logic of building dependency data, tracking processes and otherwise manging the services is kept in the systemd binary. This is the part that is "hidden" from the user. Or at least hidden in the sense you'd need to know C programming and have a lot of spare time to go through systemd's source code to learn what was going on behind the scenes. With script-based init systems, like sysvinit, that logic is more open as it is built into the scripts and link names.
Note, I may be biased here as I maintain sysvinit, but I think this is an objective comparision.
47 • Fractured Linux will fracture. (by Topper on 2019-01-17 20:46:17 GMT from Germany)
The systemd argument still goes round.
All I want to know is why change what was working for what isn't, besides is disliked. And you can ask that on "Wayland" instead of Xorg too, besides all the GUIs that just change for sake of change.
48 • @46 systemd (by Dan on 2019-01-17 21:04:33 GMT from Israel)
I'm a long-time Linux user and know a lot about the community and everything (though, for various reasons, unfortunately, I'm no longer using Linux on my personal computer at all and haven't read DistroWatch in about 2 years or something, but I saw this discussion and this is something that I *must* bring up).
I'm running a private dedicated server at my home running the latest Debian. I must say that systemd with its unit files is a huge time saver, and also, the unit files allow to easily enable various security features of the Linux kernel and enforce them (such as capabilities, seccomp) and other stuff (such as PrivateTmp, all of the Protect* and Restrict* directives). The only commands I have to remember in a systemd-based system are 'systemctl' and 'journalctl' and that's all. From my experience with systemd, it is the fastest to shutdown the system. I have read http://0pointer.de/blog/projects/the-biggest-myths.html and I believe this article still largely holds today. And also, I read (a long time ago) https://github.com/systemd/systemd/issues/6237 and some other security issue that was brought up to the creator of systemd, Lennart Poettering - he seems to be sincere and logical IMHO.
I understand why some people might not like systemd, but in my opinion systemd gets too much hate, much more than it should get. I don't know the reason, maybe ignorance, maybe because it _potentially_ diverges from the Unix philosophy (that is debatable, and still there is no proof (as far as I know) that the Unix philosophy is necessarily and objectively right or better than any other philosophy), or maybe because I'm missing something important. But in my opinion systemd is better than any other init program (not to say all the other inits are necessarily bad), and people largely irrationally berate it and go mad over it and create websites that call to boycott it.
49 • @48: (by dragonmouth on 2019-01-17 21:12:20 GMT from United States)
" in my opinion systemd gets too much hate, much more than it should get"
That's what Window Fans say about Windows. :-)
50 • @46 (by Justin on 2019-01-17 22:10:04 GMT from United States)
I agree with what Jesse said. I tried tuning the boot times on a runit system (Artix actually) and eventually gave up when I realized how painful it was to do manual dependency work on scripts not written with that in mind. I needed to replace runit's init method. Stage 2 is actually slow because it basically lists the init.d directory and calls all scripts in series--easily 1s overhead per call on my system (per bootchart). I added a single script that called all the init scripts at once with '&', but then the dependency problems showed up, and I painstakingly started sorting them out. Eventually I realized this is what systemd (and Arch) actually was offering me, and I switched to that. In a VM, my systemd version booted much faster, but on the real hardware neither init system made more difference, but having that dependency sorting already managed for me was nice. After this experience, I'm a bit more accepting as I know which tool to use for which situations. That is the great part about Linux--I can manage what I want to manage and learn along the way. It also helped to learn that "systemd" is poorly named and should be called "systemd-init". The "systemd" project has the same name and is like other meta-projects that house a lot of consistent applications together (I'm thinking KDE, LXDE, etc.).
I wonder if similar conversations of binary opacity like this happened with package managers. You used to manage your own dependencies, and tools like apt came along that did it for you. I love that resolution, but thankfully distros like Slackware and LFS let you do this yourself if you really want to.
51 • init scripts (by Jesse on 2019-01-17 22:34:08 GMT from Canada)
@50: For what it is worth, I don't play with runit much so I can't comment on your struggles with it, but SysV init does include tools for automatically working out run-time dependencies between scripts and the ability to start jobs in parallel. That way you don't need to fiddle with working out what needs to be run in which order.
52 • boot times (by Gary W on 2019-01-18 03:12:31 GMT from Australia)
I can't follow the chatter about boot times. Uptime for my home machines is typically weeks (and then only for freezes, subsystem failures, or new kernels). The fleet I administer at work records uptimes in months.
Why is saving a few seconds, or even a few minutes, worthy of consideration? Unless people are booting their machines 20 times a day. Too much like another OS for me!
53 • @52 Re: boot times (by Rev_Don on 2019-01-18 04:32:47 GMT from United States)
Not everyone is in the same situation you are. I work with a lot of Non Profits and Churches. The majority of their computers are only used one or two days a week (sometimes only an hour at a time) so they do not leave them on 24/7/365. Boot times are definitely important to them as the last thing they want is to have a volunteer pop in to do their work and have to waste time waiting for a slow booting computer. Many of them have old, outdated systems that they can't afford to replace so if I can tweak them to boot and run faster it matters.
I know it might seem illogical to you, but when someone only has an hour (or even less) available in their busy schedule to come in and do their work every minute matters to them.
Now I understand that boot times may not mean anything to some people, but that doesn't mean it doesn't to some.
54 • Re: boot times (by Gary W on 2019-01-18 06:06:41 GMT from Australia)
Guilty as charged. I can't remember the last time I used a computer for an hour, then turned it off.
Perhaps I'm a bad example. I only meant that boot time is hardly a compelling feature for most...
55 • How to strip-out systemd services from loading? (by sysD Stripper on 2019-01-18 06:38:07 GMT from Canada)
It seems like there are lot systemd pro-fans here.
I can appreciate if any one of you can point the direction at least one of the followings:
1) stripping out systemd to boot system less than 6 seconds. My current boot time with stripped sysVinit 5.865 sec. I can still take-out 3.21sec from hw-testing.
2) To disable drivers from loading and remove them permanently from system. For example PRO Network Driver,
I have better replacemnt with Super 5G Network Driver.
Any help pointing the right direction is aprreciated.
56 • Just forget about shutdown time. (by sysD Stripper on 2019-01-18 06:49:44 GMT from Canada)
Just forget about shutdown time.
2.88 sec without any application running from command to power-off.
It of cource varies with multiple application to terminate them.
57 • @28 (by edcoolio on 2019-01-18 06:52:14 GMT from United States)
Thanks for the information, it is very much appreciated!
I do some builds for non-profits and the same information on single core computers (Pentium M, Pentium 4 w/o HT, Pentium 4 w/ HT) would help greatly. In addition, I'm trying to figure out if the effort of installing a dedicated graphics card helps as well. My testing has been inconclusive.
Basically, I'm looking for a snappy distro that would run on these boxes with a modern Chromium browser. No PAE overhead necessary. I put a cheap $15 SSD in all of these boxes (plus cheap IDE to SSD adapters) and max out the RAM. They are still quite useful and plenty quick enough, but I'm always looking to get any edge I can in regards to speed.
Currently, Bodhi is a clear winner in that department. Very snappy and easy for the users.
However, the search continues!
58 • @53 Boot times (by Alburgheiro on 2019-01-18 09:46:18 GMT from Russia
OK, in that situation boot times might matter if you are comparing a few seconds to a few minutes. But that's not the case. People here are talking of differences of a few seconds. Besides, it is not like you need to be staring at the screen while the computer boots. You can always go and make yourself a cup of tea or flirt with some parishioners.
My computer, for instance, takes some 30 seconds to boot. Most of it happens before actually getting to the boot manager (Grub) because it is checking whether or not it should boot from the network, checking the RAM (it takes a while when you have a lot), etc. So the init system is irrelevant there. Then, when the OS is actually booting, I have noticed little difference between SysV, systemd and OpenRC. If anything, the later is faster.
Then you still need to log in and wait until your desktop environment is ready. If you DE is light this happens pretty fast, if it is heavy or Windows it can take a while (way more than the init itself). There, again, the init system is irrelevant.
In summary, the init system influences only 1 out of 3 stages in the booting process.
Finally, systemd is not an init system, it is a large software suite which includes an init system, among a growing number of other tools:
59 • @57, old hardware (by Angel on 2019-01-18 10:42:34 GMT from Philippines)
Bodhi is a pretty distro, but I've never learned to like Enlightenment. Don't know If you have tried antiX. Idles about 66MB and has a usable and flexible UI . Firefox will shoot it up to 300MB with no tabs open, but you can always do better with Chromium (204MB) or Midori.
That's seriously old stuff you are using. Computers are rather expensive where I am, but I can still find core 2 duo units here for a price that would make spending $16 for a graphics card seem an extravagance. Long time since I left the land of the disposable, but I'm sure on eBay and other venues you can do quite a bit better. (Just seen online: FAST Hp Gaming Computer PC Nvidia GT1030 Windows 10 i5 3.1Ghz 8Gb 500G WiFi HDMI- $39.99)
I do quite a few PCs here for students, schools, etc. and I draw the line somewhere after 2006. DDR2 memory is hard to find, DDR2 memory also, even desktop units are getting rare. So, DDR3 and no need to adapt to SATA. Mostly laptops, which is what I generally need, selling for the equivalent of maybe $60 to 100. I stick with generic Intel, AMD only if a really good unit and price. No netbooks, also no Celerons, Atoms or Centrinos. Capable of running most Distros and even Windows 10. XFCE nostly with LXDE if needed.
60 • @59 Old Hardware (by eamonnb on 2019-01-18 14:40:10 GMT from United Kingdom)
I have dabbled with installing linux on single core laptops form a decade or so ago. Antix is the best one I have found for that use case. There are other well known contenders out there but Antix for me performs as well as that level of hardware allows.I would also pitch for Pale Moon as a browser. Its not perfect but it is fast and I've been able to watch Youtube videos in full screen mode albeit on lowered resolution.
61 • Reborn OS - hash not match (by Artur C on 2019-01-18 16:22:19 GMT from Poland)
If suggesting of installing Reborn OS it is good to mention that newest iso downloaded from official site don't match hashes from theirs website.
I would not trust OS that image hash is wrong...
And if saying about problems with Cnchi - it is in most cases problem with bad mirrors. I don't know why Antergos and Reborn OS devs wont fix this by correcting mirrors.
Any way there is a solution i fount in Antergos wiki that seems to work in most cases:
And again - i do not understand why they wont add at least a simple script that will automatically do the job, but if someone has trouble with installer and really want to try those distros then there's a solution that can help.
62 • @60, old hardware, Pale Moon (by Angel on 2019-01-18 17:04:34 GMT from Philippines)
I mostly use Chrome/Chromium on my own systems. Firefox has gotten fat and slow, so I keep it only for some continuing and necessary tasks. I transfer the .mozilla folder to any new install, and my settings remain the same over the years. Pale Moon is fine, but Opera is just as light on resources and has some advantages. If one is really short on resources, Midori is hard to beat.
63 • @55 (by Justin on 2019-01-18 18:08:13 GMT from United States)
@55: One thing to realize with systemd is that it makes everything a service, even things that aren't traditionally so. I think the rationale is that you can see that your limitation is a slow piece of hardware (e.g., your drive enumerating) and that fixing software won't help. If you don't know already, you can start with systemd-analyze, systemd-analyze blame, and systemd-analyze critical-chain to figure out what is worth optimizing. You can also get bootchart-like output by setting the boot init to systemd-bootchart (it may be a separate package on your distro). To enable/disable services, you use systemctl . The syntax is a bit different from sysVinit and openrc, but it's not that different and you'll adjust. There are several online resources that can help you here.
To disable drivers, you'll need to blacklist them with modprobe, which is independent of systemd, if you can't uninstall them with your distro's package manager.
64 • Init Systems (by Newby on 2019-01-18 18:20:06 GMT from Canada)
@44 Angel Thanks for mentioning Artix X
@45 Hoos Thanks for pointing out to use "local install" on Void
@46 & 51 Jesse and 48 Dan and 50 Justin: The info contained in those specific replies really went a long way to clearing up a lot of confusion on my part. Hugely appreciated! Can now finally understand where there may be a good case for systemd in some cases. For MY purposes, Slack-based script styles still appear to be the best solution (be it Slackware, Salix, Zenwalk, etc.). But at least I can now understand the use-case for systemd.
Left wondering how much of a problem it would be for systemd distros, to offer a choice on installation? That way, the components of systemd would be available right off the install media, but if undesired, one could fall back on the trusty old-style scripts without having to install the whole framework. Would certainly cut back on need for extra distros as well as eliminating another source of "flame wars". Then again, might not be practical. I see that even Linux-from-Scratch is now provided in both systemd and non-systemd versions.......
65 • init choice (by Jesse on 2019-01-18 18:43:07 GMT from Canada)
@64: "Left wondering how much of a problem it would be for systemd distros, to offer a choice on installation?"
It would be pretty tricky. Not because it is hard to swap out just one init system for another. In most cases this is relatively straight forward and just involves un-installing one package and installing another. The tricky part, for systemd distros, is there are so many packages now that use systemd as a dependency. If your distro uses Snaps then removing systemd breaks your portable packages. If you use a login module from systemd, swapping init systems breaks that. If your desktop links to systemd components, switching init systems breaks your desktop environment. You get the idea.
With most init systems, very few components rely on init so you can swap them fairly easily. But systemd has grown into such a large collection of dependencies that if you remove it then large parts of the operating system no longer work. To fix this you need to have alternative components for logind, fewer (or alternative) desktop packages, alternative portable packages, etc. This is why projects like Devuan are such a big effort.
66 • Old Computers (by edcoolio on 2019-01-18 21:28:44 GMT from United States)
Firstly, I want to thank you all for the information /suggestions.
The latest Enlightenment seems pretty good and is a huge improvement, but I hear you. I used to use Lubuntu for this, but it has become a bloated mess. They are dropping 32 bit support, so for the sake of planning, it has become of no use. It is most unfortunate. I've even stopped using it for my personal equipment as being light was their only advantage.
I like antiX, but in my experience, there seems to be more training necessary for an elderly Windows/Mac user than Bodhi. Again, with a solid 2 GB of RAM on these machines, I'm not concerned with RAM as it has never been a problem for this use. In fact, one of the first things I do is change swappiness to 1, and never had any pauses/thrashing issues.
I standardize on Chromium because so many people are married to Google. Again, it is just easier and more useful for this specific case.
I guess the issue is a follows: The cost for all of this is about $16 per computer, laptop or desktop, which is the SSD plus adapter if needed. The video cards/extra ram/mass storage (to store an image and home drives for multiple user) all costs nothing. Core 2 Duo's, Quads, i5 gen1, etc. do occasionally become available and are given the same treatment, but we still need more computers than we have.
The price limit is about $20 per unit, and I can at least re-use the SSD's as quicker machines become available, which makes all the difference in the world. An SSD on a Core 2 Duo with 3-4GB RAM easily runs Windows 10/MX and Chrome while as snappy/quick as a brand new machine.
I'm with you - I would love to draw the line, but we make do with what we have. In the USA, kids and parents have all the new and fast stuff while the elderly have the leftovers from when people finally get around to cleaning their garages... unfortunately.
While I like Midori, there are just too many broken websites when using it. Google strikes again.
Thank you again. The opinions and information is all very much appreciated.
67 • @64 init choice (by Angel on 2019-01-19 01:03:02 GMT from Philippines)
Not an init expert here, but MX Linux offers you a choice at boot, with systemD optional, although not recommended. Tried it on my copy and it boots fine.
68 • @66, old computers (by Angel on 2019-01-19 04:51:32 GMT from Philippines)
Don't know how much you can do on Linux or what your old folks require. I'm sitting in God's waiting room myself. Don't know how long since you tried but I find antiX default rox-jwm GUI as mostly as capable as LXDE. But not to worry, the damn thing is like a Swiss army knife. you can install LXDE with a few keystrokes or from Synaptic and it will idle under 100MB. XFCE also, right now on Virtualbox, htop shows 105MB at idle. Get a lighter browser than FF and you've got a pretty light system. Better yet, add and remove what you wish, then use the tools provided to make your own customized ISO.
69 • @66, old computers (by Angel on 2019-01-19 04:59:46 GMT from Philippines)
Just adding: Most of my work has been and is on Windows and such. I run Linux on my everyday units, and dabble a bit out of curiosity, so I'm no Linux wizard. But there are many people out there who will take you step by step, in writing or on YouTube. All it takes is a search. That's how I've learned a lot of things.
70 • init choice (by Newby on 2019-01-19 07:00:10 GMT from Canada)
So this leads to the question of why, in a systemd based OS, so many components suddenly rely on systemd, when with all the other inits, you can easily swap them out.
Referring to "Running Linux" (which I think is considered a standard reference?):
"init is a general-purpose program that spawns new processes and restarts certain programs when they exit"
"init is also responsible for running a number of programs and scripts when the system boots. Everything init does is controlled by the file /etc/inittab"
In looking for info about other startup schemes, came across a link that took me to the busybox page. At the bottom of that page, was a link to "init_vs_runsv". This seems to be related to, or maybe based on runit. My head is still reeling from trying to digest that explanation.
Getting back to systemd, I'm guessing that in order to control everything, it's mutated into some kind of monster that has it's fingers everywhere? Maybe in trying to learn linux, I'm trying to learn a little too much too soon. When my "fried" brain cells recover, will have to have a look at the systemd version of the Linux from Scratch book. Not sure what horrors will be encountered therein.
Anyway, thanks to all who answered. At least here I've been getting some comprehensible answers without having to become some kind of linux guru.
71 • init systems differences (by Jordan on 2019-01-19 13:48:22 GMT from United States)
This week's discussion on systemd vs all others has delivered more digestible information for me than I can remember from other (often flame war) discussions here. Jesse's remarks above seem to wrap it all up.
And systemd proliferates as if it is just fine and is thumbing its nose at the other systems, begging the questions about what's so terrible about an efficient init file/script set that is working with the entire schema as opposed to just portions of it?
Some linux users want more control and feel that systemd is taking that control away. Okay: the list of non-systemd distros beckons.
Meanwhile, this page of remarks is copy/pasted to my notepad for info put in a way better than any wiki I've tried to understand.
72 • @70 Newby: (by dragonmouth on 2019-01-19 14:13:41 GMT from United States)
Systemd is not solely to blame. Application developers are also to blame because applications have to be written specifically to hook into and work with systemd. IOW, they write their apps to depend on systemd.
73 • systemd journal (by Dan on 2019-01-19 14:37:47 GMT from Israel)
@48 To continue what I wrote before:
"[...] journalctl normally expects the default root to be used, so you actually need to use --root or --file flags [...] The location of logs and the naming convention is counter-intuitive. To access the logs I needed to cd into: /run/media/liveuser//var/log/journal// Then, here, you have user and system logs, labeled user-@.journal and system@.journal [...] After I located the logs, realized they were not accessible as text files, and used journalctl with the --file option [...]"
He should have just used the --directory or --root flags of journalctl instead of needlessly ranting. This would have eliminated the need to grope through all the randomly named directories.
Also, Lennart explains the reasoning behind using a binary journal here:
"Journal files are mostly append-only files. We keep adding to the end as we go, only updating minimal indexes and bookkeeping in the front earlier parts of the files. These files are rotated (rotation = renamed and replaced by a new one) [...] when we find the files to be corrupted. As soon as they rotate they are entirely read-only, never modified again. [...] our strategy to rotate-on-corruption is the safest thing we can do, as we make sure that the internal corruption is frozen in time, and not attempted to be "fixed" by a tool, that might end up making things worse. [...] of course, having corrupted files isn't great, and we should make sure the files even when corrupted stay as accessible as possible. Hence: the code that reads the journal files is actually written in a way that tries to make the best of corrupted files, and tries to read of them as much as possible, with the the [sic] subset of the file that is still valid. We do this implicitly on every access. Hence: journalctl implicitly does on read what a theoretical journal file fsck tool would do, but without actually making this persistent. This logic also has a major benefit: as our reader gets better and learns to deal with more types of corruptions you immediately benefit of it, even for old files!"
In my opinion, this is certainly better than having the journal be stored in plain text. This is somewhat similar to the copy-on-write technique used in advanced filesystems (Btrfs, ZFS, and the like) to make the data resilient, except that this works in any filesystem, even if the user doesn't have Btrfs or ZFS as their filesystem.
74 • Old Computers and Elderly (by edcoolio on 2019-01-19 18:22:38 GMT from United States)
Your point of view is greatly appreciated.
It was so much easier with Lubuntu because it would look and act like windows. Tweak the GUI, remove unneeded processes, remaster, done. Bodhi is much the same way, but quicker and less tweaking.
antiX has definitely been on my short list for some time, but it would require (as you noted) a bit of doing to get it up to "Windowish" standards. I think I'll make that my next project.
Unfortunately, like I said before, Chromium is a must. I am simply limited in this regard.
Everyone is either tied to Google or their adult children are. The most useful thing Google gives is a functional connection between the elderly and their adult children.
Now, I'm not talking about Facebook or other social media garbage. I mean the useful stuff. Phone numbers, addresses, and most important: the calendar. The connectivity of the calendar is one of the first things I teach simply because important appointments (healthcare, etc.) can be mirrored on the adult children's phones.
It is just easier for everyone. Kids can update their parents calendar, the elderly can update their own calendar so the kids can see. I have taught them how doctors offices can just send the schedule via e-mail so they just hand a printed card with their name and address. They know when/if they will be visited, when are their appointments, ride scheduling, the whole nine-yards.
I really appreciate the insight.
75 • init systems (by Newby on 2019-01-19 19:18:05 GMT from Canada)
Okay, I may be in waaay over my head here, but think I might actually understand some of your explanation. It and related links were most informative. Guess if "experts" have trouble gleaming systemd's intricacies, at least I don't have to be embarrassed by my lack of experience.
So now I am left wondering, if we are talking journaling and file corruption, is this not the job of the filing system? Surely, if that is a concern, choosing ZFS or BTRFS would seem to make more sense, than having an init system perform this function?
Now left wondering how much of a problem file corruption is on a modern system, and if paying extra for parity checking memory helps? Would imagine this could be a big problem for databases dealing with huge amounts of financial, medical, or legal data. Again, seems counterintuitive that what started off as a "modern" init, is trying to solve problems related to filesystem.
Also, seem to recall previous posts here related to problems with BTRFS handling of RAID in some cases as the reason Redhat stopped development work on it.
In reading now outdated paper (as opposed to ebooks) linux books for beginners, have come across historic legends from linux ancient history regarding epic battles between supporters of Vi/Vim and Emacs, with Emacs evolving almost into an operating system on its own. Is history repeating now with init systems? Can visualize university profs teaching political "game" theory using the linux "flame wars" for their simulations and teaching examples......
Again, everyone, thanks for your patience and help answering my questions.
76 • systemd journal (by Dan on 2019-01-19 20:23:15 GMT from Israel)
@75 "So now I am left wondering, if we are talking journaling and file corruption, is this not the job of the filing system? Surely, if that is a concern, choosing ZFS or BTRFS would seem to make more sense, than having an init system perform this function?"
Database software do it too, and AFAIK it doesn't impose an overhead if you're also using a copy-on-write filesystem.
77 • Processes and System Down (by Claude on 2019-01-19 20:30:58 GMT from Canada)
If you are coming from a Windows world you should know swap on linux is much much slower than Windows. Even dipping into swap by a 100 MB or so will make you think your desktop is frozen. Be patient and slowly shut down uneeded applications. On my systems I tried adjusting swapiness but it does not seem to do much.
78 • journals and corruption (by Jesse on 2019-01-19 20:32:54 GMT from Canada)
@75: >> "So now I am left wondering, if we are talking journaling and file corruption, is this not the job of the filing system? Surely, if that is a concern, choosing ZFS or BTRFS would seem to make more sense, than having an init system perform this function?"
I think you may be confusing a couple of terms here. For example, I think you are equating journalling file systems with systemd journal logs. And bitrot file corruption (which can sometimes be solved with advanced file systems) versus file corruption that comes mishandling data.
Post 73 seems to be talking about how systemd binary logs used to get corrupted due to software bugs and, since the data was binary instead of plain text, it was hard to recover or read for humans. Instead of trying to "rescue" to data in the journal, systemd was designed to rotate the logs. This is unrelated to the file system.
ZFS and Btrfs have built-in tools to avoid on-disk degradation of data. This protects against a different type of corruption (issues with the physical media instead of misbehaving software). It's good to have, but mostly deals with a different issue.
79 • Systemd (by zephyr on 2019-01-19 21:26:14 GMT from United States)
Pros and Cons of systemd but from the horse's mouth comes the truth!
80 • init systems (by Newby on 2019-01-19 21:49:49 GMT from Canada)
@76 Dan and @78 Jesse
Yup - I WAS confusing those terms.
Re: "ZFS and Btrfs have built-in tools to avoid on-disk degradation of data" - I thought THAT was supposed to be handled by the hard drive firmware doing crc checks, and locking out bad blocks? How many types of "corruption" are there?
Have been trying to learn more about linux by studying "Running Linux" by Matt Welsh on O'Reilly Books, and "Linux System Administration" by Gagne on Addison Wesley. Think I've learned a lot from them, but things like: systemd, bitrot, journaled file systems, etc.; not even a mention.
Can anyone recommend a modern, up-to-date, paper text/book that covers recent innovations in Linux. Lot easier to study with a paper book while on the bus, or whatever, than having to track down arcane information scattered all over the internet. Same problem with videos- fine for a specific topic, but it would be nice to have a paper reference that is current. Amazon books lists plenty, but not sure what to actually buy.
Again, thanks for your help. Excuse me while I take a pain reliever for my headache. Sinking ever deeper into information overload......
81 • @74 • Old Computers and Elderly (by Rev_Don on 2019-01-19 22:19:12 GMT from United States)
"Unfortunately, like I said before, Chromium is a must. I am simply limited in this regard.
Everyone is either tied to Google or their adult children are. The most useful thing Google gives is a functional connection between the elderly and their adult children."
None of that has anything to do with Chromium. It's all dependent on signing into your Google account and you can do that from ANY modern browser. Your Google account doesn't give a rat's patooty what browser you use. I do everything you mentioned in your post in FireFox on a daily basis. I haven't needed to use Chrome or Chromium for anything in years.
Number of Comments: 81
|• 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|
|• Issue 790 (2018-11-19): NetBSD 8.0, Bash tips and short-cuts, Fedora's networking benchmarked with FreeBSD, Ubuntu 18.04 to get ten years of support|
|• Issue 789 (2018-11-12): Fedora 29 Workstation and Silverblue, Haiku recovering from server outage, Fedora turns 15, Debian publishes updated media|
|• Issue 788 (2018-11-05): Clu Linux Live 6.0, examining RAM consumpion, finding support for older CPUs, more Steam support for running Windows games on Linux, update from Solus team|
|• Issue 787 (2018-10-29): Lubuntu 18.10, limiting application access to specific users, Haiku hardware compatibility list, IBM purchasing Red Hat|
|• Issue 786 (2018-10-22): elementary OS 5.0, why init keeps running, DragonFly BSD enables virtual machine memory resizing, KDE neon plans to drop older base|
|• Issue 785 (2018-10-15): Reborn OS 2018.09, Nitrux 1.0.15, swapping hard drives between computers, feren OS tries KDE spin, power savings coming to Linux|
|• Issue 784 (2018-10-08): Hamara 2.1, improving manual pages, UBports gets VoIP app, Fedora testing power saving feature|
|• Issue 783 (2018-10-01): Quirky 8.6, setting up dual booting with Ubuntu and FreeBSD, Lubuntu switching to LXQt, Mint works on performance improvements|
|• Issue 782 (2018-09-24): Bodhi Linux 5.0.0, Elive 3.0.0, Solus publishes ISO refresh, UBports invites feedback, Linux Torvalds plans temporary vacation|
|• Issue 781 (2018-09-17): Linux Mint 3 "Debian Edition", file systems for SSDs, MX makes installing Flatpaks easier, Arch team answers questions, Mageia reaches EOL|
|• Issue 780 (2018-09-10): Netrunner 2018.08 Rolling, Fedora improves language support, how to customize Kali Linux, finding the right video drivers|
|• Issue 779 (2018-09-03): Redcore 1806, keeping ISO downloads safe from tampering, Lubuntu makes Calamares more flexible, Ubuntu improves GNOME performance|
|• Issue 778 (2018-08-27): GuixSD 0.15.0, ReactOS 0.4.9, Steam supports Windows games on Linux, Haiku plans for beta, merging disk partitions|
|• Issue 777 (2018-08-20): YunoHost 126.96.36.199, limiting process resource usage, converting file systems on Fedora, Debian turns 25, Lubuntu migrating to Wayland|
|• Issue 776 (2018-08-13): NomadBSD 1.1, Maximum storage limits on Linux, openSUSE extends life for 42.3, updates to the Librem 5 phone interface|
|• Issue 775 (2018-08-06): Secure-K OS 18.5, Linux is about choice, Korora tests community spin, elementary OS hires developer, ReactOS boots on Btrfs|
|• Issue 774 (2018-07-30): Ubuntu MATE & Ubuntu Budgie 18.04, upgrading software from source, Lubuntu shifts focus, NetBSD changes support policy|
|• Issue 773 (2018-07-23): Peppermint OS 9, types of security used by different projects, Mint reacts to bugs in core packages, Slackware turns 25|
|• Issue 772 (2018-07-16): Hyperbola GNU/Linux-libre 0.2.4, UBports running desktop applications, OpenBSD auto-joins wi-fi networks, boot environments and zedenv|
|• Issue 771 (2018-07-09): Linux Lite 4.0, checking CPUs for bugs, configuring GRUB, Mint upgrade instructions, SUSE acquired by EQT|
|• Issue 770 (2018-07-02): Linux Mint 19, Solus polishes desktop experience, MintBox Mini 2, changes to Fedora's installer|
|• Issue 769 (2018-06-25): BunsenLabs Helium, counting Ubuntu users, UBports upgrading to 16.04, Fedora CoreOS, FreeBSD turns 25|
|• Issue 768 (2018-06-18): Devuan 2.0.0, using pkgsrc to manage software, the NOVA filesystem, OpenBSD handles successful cron output|
|• Issue 767 (2018-06-11): Android-x86 7.1-r1, transferring files over OpenSSH with pipes, LFS with Debian package management, Haiku ports LibreOffice|
|• Issue 766 (2018-06-04): openSUSE 15, overview of file system links, Manjaro updates Pamac, ReactOS builds itself, Bodhi closes forums|
|• Issue 765 (2018-05-28): Pop!_OS 18.04, gathering system information, Haiku unifying ARM builds, Solus resumes control of Budgie|
|• Issue 764 (2018-05-21): DragonFly BSD 5.2.0, Tails works on persistent packages, Ubuntu plans new features, finding services affected by an update|
|• Issue 763 (2018-05-14): Fedora 28, Debian compatibility coming to Chrome OS, malware found in some Snaps, Debian's many flavours|
|• Issue 762 (2018-05-07): TrueOS 18.03, live upgrading Raspbian, Mint plans future releases, HardenedBSD to switch back to OpenSSL|
|• Issue 761 (2018-04-30): Ubuntu 18.04, accessing ZFS snapshots, UBports to run on Librem 5 phones, Slackware makes PulseAudio optional|
|• Issue 760 (2018-04-23): Chakra 2017.10, using systemd to hide files, Netrunner's ARM edition, Debian 10 roadmap, Microsoft develops Linux-based OS|
|• Issue 759 (2018-04-16): Neptune 5.0, building containers with Red Hat, antiX introduces Sid edition, fixing filenames on the command line|
|• Issue 758 (2018-04-09): Sortix 1.0, openSUSE's Transactional Updates, Fedora phasing out Python 2, locating portable packages|
|• Issue 757 (2018-04-02): Gatter Linux 0.8, the UNIX and Linux System Administration Handbook, Red Hat turns 25, super long term support kernels|
|• Issue 756 (2018-03-26): NuTyX 10.0, Neptune supplies Debian users with Plasma 5.12, SolydXK on a Raspberry Pi, SysV init development|
|• Issue 755 (2018-03-19): Learning with ArchMerge and Linux Academy, Librem 5 runs Plasma Mobile, Cinnamon gets performance boost|
|• Issue 754 (2018-03-12): Reviewing Sabayon and Antergos, the growing Linux kernel, BSDs getting CPU bug fixes, Manjaro builds for ARM devices|
|• Issue 753 (2018-03-05): Enso OS 0.2, KDE Plasma 5.12 features, MX Linux prepares new features, interview with MidnightBSD's founder|
|• Issue 752 (2018-02-26): OviOS 2.31, performing off-line upgrades, elementary OS's new installer, UBports gets test devices, Redcore team improves security|
|• Issue 751 (2018-02-19): DietPi 6.1, testing KDE's Plasma Mobile, Nitrux packages AppImage in default install, Solus experiments with Wayland|
|• Issue 750 (2018-02-12): Solus 3, getting Deb packages upstream to Debian, NetBSD security update, elementary OS explores AppCentre changes|
|• Issue 749 (2018-02-05): Freespire 3 and Linspire 7.0, misunderstandings about Wayland, Xorg and Mir, Korora slows release schedule, Red Hat purchases CoreOS|
|• Issue 748 (2018-01-29): siduction 2018.1.0, SolydXK 32-bit editions, building an Ubuntu robot, desktop-friendly Debian options|
|• Issue 747 (2018-01-22): Ubuntu MATE 17.10, recovering open files, creating a new distribution, KDE focusing on Wayland features|
|• Issue 746 (2018-01-15): deepin 15.5, openSUSE's YaST improvements, new Ubuntu 17.10 media, details on Spectre and Meltdown bugs|
|• Full list of all issues|
|Random Distribution |
Enso OS is a Linux distribution based on Xubuntu. Enso features the Xfce desktop with Gala, imported from elementary OS, as the default window manager. The distribution also features the Panther application launcher and the Plank dock.