 DistroWatch Weekly |
| DistroWatch Weekly, Issue 1072, 27 May 2024 |
|
Welcome to this year's 22nd issue of DistroWatch Weekly!
The open source ecosystem is a complex tangle of technologies, communities, ideals, licenses, and business. There are a lot of pieces and people which need to work together in order to make open source operating systems work properly. Sometimes all the elements blend together well and sometimes there can be friction. This week, in our News section, we share some examples of each. We talk about OpenBSD developers quickly porting the Plasma 6 desktop to their security-focused platform and we also discuss Dell working to bring improvements to the company's ThinOS platform from FreeBSD. We also share highlights of a debate happening in the Arch Linux community which revolves around package mirrors and the requirements the project has for mirrors provided by volunteers. First though we take a look at the latest release from the Manjaro Linux project. This rolling release distribution strives to simplify and automate running an Arch-based operating system and we share details below. Plus we share a side-by-side comparison of various init software along with the good and problematic aspects of each init implementation. In our Opinion Poll this week we ask what our readers think of KDE's Plasma 6 desktop now that it has been released and a few bug fix releases have been published. Then we are pleased to share the releases of the past week and list the torrents we are seeding. Finally, we're grateful to be able to list our kind donors who help keep the site running. We wish you all a wonderful week and happy reading!
This week's DistroWatch Weekly is presented by TUXEDO Computers.
Content:
|
| Feature Story (By Jesse Smith) |
Manjaro 24.0
Manjaro Linux is an Arch-based distribution which works to be a user-friendly, desktop-oriented operating system. Key features include a graphical installation process using Calamares, automatic hardware detection, a more stable rolling-release model, and the ability to install multiple kernels.
Manjaro's latest snapshot is version 24.0. The new release is available in several desktop flavours. The official editions are KDE Plasma, GNOME, and Xfce. There are also community editions featuring the Cinnamon, i3, and Sway graphical interfaces. Manjaro is available in x86_64 and ARM builds.
Some of the key features in 24.0 are:
- The GNOME 46 desktop which now offers remote logins without an existing session already active.
- KDE Plasma's new 6.0 desktop which sees the return of the desktop cube.
- Xfce 4.18 where we can use Thunar to set custom colours on specific files and folders.
Each edition ships with the 6.9 version of Linux, though other versions of the kernel are available: "Kernel 6.9 is used for this release, such as [sic] the latest drivers available to date. With 6.6 LTS and 6.1 LTS we offer additional support for older hardware as needed."
I downloaded Manjaro's KDE Plasma edition, in large part to compare Manjaro's Plasma 6 implementation against Fedora's, which I tried earlier this year. The ISO for the Plasma edition was 3.5GB in size.
Live media
Booting from the live media brings up a menu which offers to start Manjaro in a few different ways. The main options are booting with open source drivers enabled (which is the default) or booting with proprietary drivers. I like that Manjaro defaults to the open option, but has a practical backup approach for people who need it.
Manjaro Linux 24.0 -- The welcome window
(full image size: 581kB, resolution: 1920x1080 pixels)
The live environment boots to the Plasma desktop. A dark panel is placed across the bottom of the screen. While the panel on the desktop is dark, Manjaro applications use a light theme by default. An icon for launching the system installer sits on the desktop. Once the session finishes loading a welcome window appears. This welcome window (called Hello in the application menu) offers to connect us with documentation (such as a readme file, release information, and the project's wiki). The welcome window also presents buttons which will connect us with the community forums, a mailing list, and Manjaro's GitLab software repository. There is also a button for launching the Calamares system installer.
Installer
The Calamares system installer makes getting up and running pleasantly straight forward. The installer walks us through picking our language preference, timezone, and keyboard layout. Guided and manual partitioning options are both offered and easy to navigate. The guided approach offers a few root filesystem options, including Btrfs, ext4 (which is the default), and XFS. I decided to use Btrfs. We can also choose to use a swap file, a swap partition, or to use no swap space at all. We are then asked to make up a username and password for ourselves. The final screen of the installer asks us if we'd like to use the LibreOffice productivity suite or FreeOffice with a brief description shared about both. There is also an option to not install any suite. I decided to use LibreOffice. Calamares then copied the Manjaro packages to my hard drive and offered to restart the computer. So far, things were going well.
Early impressions
My brand new copy of Manjaro booted to a bright, graphical login screen. Two session options are presented, Plasma on X11 and Plasma on Wayland with X11 selected as the default option.
When I signed into my account for the first time the welcome window from the live environment appeared. The resources it offers are all the same, except the Installer button has been replaced with a button called Applications. The Applications button opens a window which presents us with a list of software categories. We can click any of the categories to expand them to show a list of popular applications in the category. Each application has a short description next to it and a checkbox we can click to indicate we want to install the software. We can then click a button at the top of the window to install all checked items.
Here I ran into the first issue of my trial: I was unable to download any applications from this Applications screen. When I clicked the button to fetch new applications the system listed dependencies it would also fetch. I was then asked for my password. The password authentication step always failed, returning me to the software selection screen. I put this aside for a bit and moved on to explore other aspects of the operating system.
Manjaro Linux 24.0 -- Browsing popular applications
(full image size: 612kB, resolution: 1920x1080 pixels)
Shortly after signing into my account a notification appeared in the lower-right corner letting me know software updates were available. There is also an icon in the system tray which lets us know when new updates are available. Clicking this icon opens the Pamac software manager, a three-tabbed software centre, and shows us the Updates tab. We can then browse the list of available updates and click a button to install them.
Here again we are prompted for a password and, once again, the password authentication always fails. I want to explore this issue for a minute because it's unusual and persistent and I did quite a bit of troubleshooting for it.
Any time I tried to use Pamac on my installed copy of the distribution adding, removing, and updating packages always aborted with a pop-up window indicating authentication had failed. This happened whether I was running the Wayland or X11 session. Thanks to the "show password" button I was able to verify the password entered was correct. I also confirmed that if I typed the wrong password, a different error would be displayed right in the password prompt window and would not result in a new pop-up with the authentication error. In other words, providing the wrong password displays one error and asks us to try again, providing the right password displays a new window with a new error and aborts the action.
I investigated some other steps. I confirmed my user was able to use sudo on the command line to perform administrative actions, including running pacman to manage software. I enabled the root account and gave it a password and tried typing that, which also failed.
Password authentication always fails when using Pamac or other graphical tools for package management like the Applications window. However, password authentication works in all other command line and desktop applications I used, such as the Timeshift snapshot manager.
Manjaro Linux 24.0 -- Trying to use the welcome window and pacman to install packages
(full image size: 597kB, resolution: 1920x1080 pixels)
Something I found interesting was Pamac did work in the live session, running from a USB thumb drive. It didn't prompt for a password when running from the install media and had significant permissions to continue without extra authentication, side-stepping the issue.
I didn't find a fix for this issue and I'm a bit surprised such a big and persistent problem made it through testing.
Hardware
I tested Manjaro on a physical laptop and in a VirtualBox environment. When running on the laptop, Manjaro ran smoothly and detected all of my hardware. The distribution worked with my wireless card, audio worked out of the box, and my media keys all worked. My touchpad interpreted taps as clicks (a feature which usually isn't enabled by default on other distributions and it was a welcome surprise). On the laptop the distribution worked fairly quickly and smoothly, in both X11 and Wayland sessions.
When running in VirtualBox Manjaro worked well again, as long as I was in the X11 session. When I switched to the Wayland session the desktop lagged and was notably less responsive. The mouse pointer also seemed to get out of sync easily, clicking on areas of the screen an inch or so away from where my mouse pointer appeared.
Manjaro was a little on the heavy side when running Plasma. Signing into Plasma took about 960MB of RAM, though the amount in use would drop gradually in the minute following signing in until the consumption reached 880MB. This level of memory usage means Manjaro is heavier than most Linux distributions I have used, but still only about half as RAM hungry as Fedora 40 on the same hardware. A fresh install took up about 8.8GB of disk space, not including the swap partition Calamares created.
Applications
Manjaro's KDE Plasma edition ships with the Firefox web browser, an optional office suite (LibreOffice, in my case), the VLC media player, and Elisa music player. Timeshift is included with the distribution and this helps us make backups and Btrfs snapshots.
Since I was using the KDE edition, much of the applications were from the KDE family. These included the Gwenview image viewer, Dolphin file manager, Okular document viewer, and the KDE Connect service for linking to other devices. The KDE Help documentation was installed for me.
Manjaro Linux 24.0 -- Exploring the application menu
(full image size: 750kB, resolution: 1920x1080 pixels)
In the background we find the GNU command line utilities, systemd init software, and version 6.9 of the Linux kernel. Other kernel versions, from long-term support (LTS) branches, are available.
Something I noticed early on was Manjaro uses zsh as the default shell, rather than the more commonly used bash. The zsh shell has some convenient functions, including displaying suggestions while we type.
Manjaro includes some command line aliases which got in my way at first, until I got used to them or disabled them. I'm not a fan of distributions including aliases which change the default behaviour of commands, though I imagine this is put in place for new users to make output and functionality more beginner-friendly.
One command line feature I didn't like was sometimes when I was typing a command the shell would display a prompt asking if I'd really meant something else. For instance, typing "gcc" followed by some parameters to start the compiler would cause the shell to ask if I'd really meant to type "rcc". It's a minor inconvenience, but one which breaks up this user's flow. Another minor inconvenience is the terminal uses a dark cyan font on a black background. I found this colour combination hard to read and switched it to a higher contrast.
Manjaro Linux 24.0 -- Running the Dolphin file manager and exploring the settings panel
(full image size: 601kB, resolution: 1920x1080 pixels)
Software management
As I mentioned earlier, Manjaro primarily uses the Pamac software centre for package management. Pamac is organized into three tabs: one for browsing available software, organized into categories; one for browsing and removing installed items; and one for updating installed packages. While I was unable to get Pamac to successfully perform any actions, the software centre is nicely laid out and easy to navigate. It also makes browsing categories relatively quick.
Manjaro Linux 24.0 -- Browsing available software with Pamac
(full image size: 620kB, resolution: 1920x1080 pixels)
When working from the command line we can use the pacman package manager. This is an unusually fast package manager with an unusual syntax. The pacman utility worked well for me and fetched new software and updates with no issues.
The Flatpak software is also installed for us and configured to pull packages from the Flathub repository. This gives us access to a wide range of desktop applications.
Snapshots, boot environments, and other observations
Manjaro ships with the Timeshift snapshot manager. When combined with Btrfs as the root filesystem the Timeshift utility helps us set up automated snapshots. This makes it easy to see comparisons between files and directories. We can also rollback changes to the system, which is especially handy when using a rolling release distribution.
When we are using Btrfs we have the option of booting into a filesystem snapshot from the system's boot menu. This means most issues with configuration mistakes or system updates can be fixed with a reboot and selecting the previous snapshot. Manjaro is one of the only Linux distributions to automatically work with boot environments (bootable snapshots), though openSUSE is another rare example of a distro which enabled boot environments. Boot environments are not commonly set up for users by default in the Linux community and it's nice to see Manjaro go the extra mile with this feature.
The release announcement mentioned Plasma has restored the desktop cube, which I assumed was a reference to the popular visual effect that makes virtual desktops look like faces of a 3-D cube. This feature is not enabled by default. At one point I used Plasma's System Settings panel to enable visual effects, set up four virtual desktops, and went looking for a way to enable the cube animation. I was unable to find a way to enable the desktop cube, even when using the System Settings search feature. There are other animations that will indicate when virtual desktops are being navigated, but these were 2-D and fairly typical of other desktop environments. I was unable to find a way to enable the spinning cube animation.
I did a web search which turned up this support thread which suggests we need to install the qt6-quick3d package and access the cube by pressing Meta+C. I confirmed the qt-6quick3d package was on my system, but pressing Meta+C did nothing. I checked System Settings and attempted to use the shortcut in both the Wayland and X11 sessions with no success.
Conclusions
My trial with Manjaro this week was a mixed experience, full of some glorious good moments and some disappointing errors. Clearly the inability of the software manager to perform any tasks was the worst issue I ran into. This problem was made all the more puzzling since other desktop applications authenticated properly, the pacman command like package manager worked, and I was able to confirm my password was typed correctly.
There were a few other annoyances, though no serious problems. The default command line aliases, terminal colours, and shell that kept asking if I was making typos were unwelcome, but harmless. I was able to change these in a few minutes and move on. Having the project advertise the desktop cube and include the necessary dependencies only to not have it work in either session (X11 or Wayland) was also disappointing.
Now for the good parts: I really like how easy it is to install Manjaro. The Calamares system installer, the friendly welcome screen, and the variety of editions means Manjaro is quickly and easily accessible. We can pick a full featured or light edition and get it up and running in a few minutes. I like that we can pretty much click "Next" a few times in the installer and have a working system, but we can also customize partitions and the office suite.
Plasma 6 is working fairly well on Manjaro. It's still a little rough (the desktop panel kept jumping up and down during my trial) and Wayland was unusually sluggish when running in a virtual machine. The X11 session was snappy though in VirtualBox and both sessions worked well on my laptop.
Where Manjaro shines, I think, is automating a lot of things for the user. Manjaro's parent, Arch Linux, is famous for requiring a lot of manual work. Manjaro keeps the rolling nature and flexibility of Arch while automating all of the low-level work. The initial set up is easy, Flatpak support is ready to go out of the box, hardware and shortcut keys are all handled for us.
Manjaro also does a nice job of supplying some applications for basic tasks without overfilling the application menu. The distribution should be easy enough for beginners to use (the problems I encountered aside) while providing enough flexibility and tools to appeal to more experienced Linux users.
My favourite feature of this distribution is probably Timeshift combined with boot environments. I like being able to revert changes, especially on a rolling release distribution. Manjaro is one of just a few Linux distributions to enable boot environments and automated Btrfs snapshots and it's great to see this available.
There are some problems in this release, but I suspect nothing which cannot be overcome with a few tweaks or a future update. This feels like a solid, and powerful distribution that is easy to get up and running.
* * * * *
Hardware used in this review
My physical test equipment for this review was an HP DY2048CA laptop with the following
specifications:
- Processor: 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz
- Display: Intel integrated video
- Storage: Western Digital 512GB solid state drive
- Memory: 8GB of RAM
- Wireless network device: Intel Wi-Fi 6 AX201 + BT Wireless network card
* * * * *
Visitor supplied rating
Manjaro Linux has a visitor supplied average rating of: 8.1/10 from 440 review(s).
Have you used Manjaro Linux? You can leave your own review of the project on our ratings page.
|
| Miscellaneous News (by Jesse Smith) |
OpenBSD ports Plasma 6, Arch community debates mirror requirements, ThinOS gets an upgrade to its FreeBSD core
It took a while for the OpenBSD team to port, test, and package KDE Plasma 5, with the work completing last year. However, following the release of KDE Plasma 6, a small group of developers quickly tackled porting the new Plasma 6 desktop to OpenBSD and packages are now available for testing. Rafael Sadowski reports: "Last year marked a significant milestone for both myself and the OpenBSD desktop community, as we successfully ported KDE Plasma 5 and all dependencies to OpenBSD. With the release of OpenBSD 7.5 on April 5, 2024, KDE Plasma in version 5.27.10 has become a part of our lovely operating system. This success is the result of years of development work and commitment to achieving this goal.
KDE launched version 6 of its Plasma desktop environment on February 28, 2024, bringing numerous updates and features as well as the major switch to Qt6. I am immensely proud that the OpenBSD team has managed to prepare for this major update so swiftly." The blog post includes instructions for installing Plasma on OpenBSD.
* * * * *
The Arch Linux team have posted new requirements for community-run package mirrors. Some of the outlined requirements concern uptime, monitoring of issue trackers, rules for methods for contacting the mirror maintainers, security, and available bandwidth. Several mirror maintainers have responded, pointing out problems with the requirements which would make maintaining an Arch mirror impractical: "We appreciate the effort to standardize mirror management in the Arch Linux community through an RFC. However, this RFC fails to address critical issues in the current situation. It introduces major inconveniences or even inabilities for existing mirrors to comply with. We, as mirror administrators and maintainers, unanimously present our views as follows...." Key concerns include nearly uninterrupted uptime, unlimited bandwidth, fast response times from volunteers, and unlimited parallel client connections.
* * * * *
The FreeBSD Foundation is shining a spotlight on Dell's ThinOS, a FreeBSD-based operating system which "is a ready-to-deploy solution that aims to improve virtual desktops while offering a secure platform for applications and services." Dell is planning a series of updates to ThinOS which will bring improved hardware support and better compatibility with Linux applications. "The roadmap for ThinOS includes: Upgrade base OS to FreeBSD 14: The next version of ThinOS, version 10, will use the current release version of FreeBSD, version 14. Enhanced Hardware Support: Upgrading the FreeBSD kernel to support an ever-widening array of hardware platforms, ensuring ThinOS remains compatible with the latest technological advancements. Linux Application Compatibility: Improving FreeBSD's Linux application binary interface (ABI) will allow a broader base of Linux applications to run seamlessly on ThinOS, enhancing its versatility and appeal. Driver Portability: Making it easier to port Linux device drivers to FreeBSD, which will streamline the integration process and the adoption of new hardware technologies. Advanced Security Features: This feature builds upon the MAC (Mandatory Access Control) framework to introduce more sophisticated security capabilities, fortifying ThinOS against emerging threats." Additional details about improvements coming to FreeBSD and ThinOS are discussed in the Foundation's case study.
* * * * *
These and other news stories can be found on our Headlines page.
|
| Questions and Answers (by Jesse Smith) |
Comparing init systems
This-or-that asks: One of the things I pay some attention to is the "init diversity" spins of Antix -- and I always think of you when I read about them. You would seem one of the few qualified to render comparison/contrasting opinions. What do you think of the available init systems?
Jesse Smith answers: Thank you. While I might be qualified to talk about init software, or at least some init software and related services, I will also state right up front that I also have a conflict of interest. I'm currently the maintainer for SysV init (and a few related tools) so I have more familiarity and, perhaps, more appreciation for how SysV does things. With that said, I do try to maintain an open mind and I do think there are good and bad aspects to all of the init implementations available to Linux users today. Let's talk about them!
SysV init
I'd like to start with SysV init, partly because I'm the most familiar with it, but also because it's probably the oldest Linux init I am qualified to discuss. What I like about SysV is it tries to keep things really simple and minimal. SysV really only does a few things at its core.
Like all init software, it monitors for orphaned processes (processes whose parents have terminated) and cleans up after them when they exit. Otherwise, all SysV really does is allow the administrator select what is called a "runlevel" and then runs the program or script associated with that runlevel. That's pretty much the whole of SysV's function.
A runlevel is basically a pre-defined set of services or configurations the administrator might want to use together. For example, runlevel 0 is "poweroff", runlevel 6 is typically "reboot". Runlevel 1 is usually rescue or "single user" mode. On most systems runlevel 3 would be a multi-user environment with a command line, basically a server environment. Meanwhile runlevel 5 is usually a graphical/desktop environment. The idea is the distribution's maintainers figure out which services we might want to run in each of these situations and then the administrator selects which runlevel provides the environment they want.
If you look in the SysV configuration file, /etc/inittab, you will typically see six or seven lines which look like this:
l0:0:wait:/etc/init.d/rc 0
l1:1:wait:/etc/init.d/rc 1
What these lines basically say is when the administrator selects runlevel 0, init will run the program or script located at /etc/init.d/rc and pass it the parameter "0". When level 1 is selected, init will run the program /etc/init.d/rc and pass it the parameter "1". Usually there are six of these, one for each of the standard runlevels. SysV is told which runlevel we are going into and then runs the script or executable file associated with that runlevel and that's about it, SysV's work is finished.
What that program or script specified in the inittab file does is entirely up to the distribution or the administrator. It might launch a service supervisor, it might run a series of shell scripts, it might be one big program that knows how to launch everything else. SysV doesn't care, it has already completed its job. It does relatively little and remains pretty small, fast, and efficient as a result.
There are two downsides to this super minimal approach. The first is, of course, that if init doesn't do much on its own, then something does need to do the work of getting the distribution up and running - and later shut it down. This means the distribution needs to package a service manager (like OpenRC), create a complex collection of shell scripts (like Debian/Devuan uses), or introduce some other way of figuring out what should happen when SysV kicks off a new runlevel. Basically it puts more work on the distribution developers because they need to define what happens in each runlevel.
The second issue is related. Each Linux distribution ended up taking their own approach to defining what SysV should do when it entered a runlevel. As I mentioned, Debian created a massive collection of shell scripts (called init scripts) which pull in all sorts of dependencies and checks. I think openSUSE was the distribution which came up with a tool to detect dependencies and then run services in parallel using Makefile-like configurations, Slackware set up an interesting set of configuration files similar in style to how the BSDs organized their start-up processes. Each of these, in turn, had its own benefits and drawbacks.
This ended up meaning that the distributions couldn't share a lot of the work and solutions. It also resulted in a lot of misinformation about how SysV worked and its limitations. This misinformation spread because people might run into a problem on one distribution and assume it was true everywhere SysV was used. If you've ever heard people claim "SysV is slow" or "SysV requires shell scripts" or "SysV can't start jobs in parallel" then you have encountered this sort of misinformation born out of the fragmented approach distributions took to implementing SysV's runlevels. Those complaints are almost always true for one distribution, but not for SysV in general.
In short, SysV focuses on being minimal, doing one thing well, and sticks to the classic System V Unix approach of using runlevels. It also carries a lot of decades of legacy support put in place by distributions which were forced to define and implement what happens in each runlevel.
systemd
I think it's fair to say most people regard systemd as the replacement to SysV (or the replacement to Upstart, which was replacing SysV). systemd seems to be a direct answer to "What is wrong with SysV?" because it tends to do a lot of things the opposite way.
While SysV init tried to be very small and minimal, leaving configuration and implementation of runlevels up to distributions, systemd takes a much broader approach. The systemd project not only handles basic init functions, but has expanded to take on service management, networking, signing into desktops, replacing the bootloader, logging, and user home directory functionality. systemd does away with runlevels (separate silos of configurations and functionality) and instead enables targets. The administrator can then switch to a target (like single user mode, or graphical mode). This streamlines the whole process as we can limit the number of targets we use and only set up targets we know we will need. It also grants us additional flexibility because we could create as many targets as we want without worrying about how many runlevel slots we have.
Many distributions used init scripts to handle services in runlevels (and their dependencies) and this tended to result in massive scripts, sometimes dozens of lines long, to handle starting and stopping services. systemd uses small unit files with configuration options that are easy to read and fairly easy to parse. The functionality is then handled in the background. As a bonus, unit files are cross-platform, meaning distributions can usually share unit files between them, reducing the workload.
Most SysV implementations didn't do anything to track services and their processes. This could allow services to "fork and hide" and make it harder to shut down services which didn't leave a process identification (PID) file. systemd uses control groups to essentially corral and remove misbehaving services. Likewise, on its own, SysV didn't care about monitoring services or restarting failed services, that was considered outside functionality that would be handled by a script or service manager. systemd can monitor and restart services automatically.
While some distributions enabled parallel service start-up with SysV, it wasn't an automatic feature and systemd will automatically start services in parallel.
In my opinion, systemd set out to correct a lot of problems decades of using a variety of SysV implementations had revealed. In the process, systemd has become something much larger, more complex, and (sometimes) less predictable in its operations. The systemd suite does a lot of things for distribution developers, which (I believe) is a big part of why it has been so widely adopted. Developers no longer need to juggle a dozen small packages when they can rely on the functionality and layer of systemd capabilities. Distributions no longer need to maintain service scripts when they can share unit files. However, in doing so much, systemd has also added complexity, areas where things could go wrong, and increased the attack surface of the distribution (as we saw with the recent OpenSSH, systemd, xz exploit).
OpenRC
According to the Gentoo wiki page, OpenRC started out as a service manager rather than an init implementation: "OpenRC is a dependency based init system that works with the system provided init program, normally located at /sbin/init. It is not a replacement for /sbin/init." Basically, the idea was an init program, typically SysV, would do the minimal work of bringing the system on-line and then OpenRC would manage services and tasks.
Over time though OpenRC did develop its own init software which could replace SysV so OpenRC became a complete init and service manager solution, though some distributions still use a combination of SysV as init and OpenRC as the service manager running on top of init.
OpenRC relies on a special type of script file to handle service management and dependencies. These scripts are expected to have certain functions in them. Like systemd, OpenRC can monitor background services.
In my opinion OpenRC has always fit into a nice middle ground between SysV and systemd. It has the light, minimal, "do one thing well" approach of SysV. On the other hand, OpenRC has more explicit service management, arguably cleaner (or better defined) scripts, and the service monitoring capabilities of systemd.
If I'm not mistaken, OpenRC is also special in the init field because it is not tied to GNU/Linux. systemd runs on Linux only, some of SysV's approach is fairly specific to Linux (or at least GNU-related systems like GNU/Linux and GNU Hurd). OpenRC has the distinction of working well on multiple Linux distributions and on some of the BSDs (it has been used in GhostBSD and can be run on FreeBSD and NetBSD with some careful configuration.
runit
Next on my list is runit and, despite the earlier bias I mentioned in favour of SysV, I think runit might be my favourite init implementation. The runit init system is incredibly small and fast and, in my tests, often boots distributions in under half the time required by other init implementations. It also uses less memory than other init implementations I've tested.
This small footprint and blazing speed is accomplished by removing just about anything that is not strictly needed, while using a clean, straight forward design to make service administration fairly easy. While quite simple, runit also fixes a number of the problems people have with SysV.
The runit software includes process monitoring, optional automatic service restarts, built-in support for running services in parallel, offers a logging service, and has a clean, filesystem-oriented approach to enabling services. All of this is accomplished with under 1,000 lines of C code. For comparison's sake; SysV init is about 3,100 lines of code. Once you factor in all of SysV's helper programs and optional add-ons the SysV suite is about 11,600 lines of C. systemd's suite is up to about 1,300,000 lines of C code. In short, runit and its helper programs are literally 1,000 times smaller than systemd and its suite of programs.
In short, runit is small, fast, does everything init and a service manager needs to, and nothing extra.
s6
Lastly, I'd like to acknowledge s6. The s6 software is not widely used, but has found a following in some distributions, including Artix and Obarun. I haven't used s6 much, partly because I usually don't use the few projects which have adopted it and partly because I haven't been able to find a lot of documentation about what makes it special.
What I do like about s6 is it is designed to be modular. As I understand it, init and service management are separated and each component tries to be minimal and swappable. Also something I like is s6 has replaced runlevels with something called bundles. A bundle seems to give the administrator the ability to group packages or services together to be run in a pre-defined configuration, like a runlevel. However, a bundle also seems to be easier to edit and extend, closer to a systemd target in its flexibility.
People who are curious about s6 and want to dive into it more can check out the Artix wiki page for s6, it's a good place to get started with both the theory and practice side of s6.
Special note about Slackware
Since I'm talking about init software, I'd like to mention something I get asked about a lot. Slackware Linux, the world's oldest surviving distribution, runs SysV init. For some reason, none of the Slackware documentation says this, as far as I can tell. The documentation mentions Slackware offers SysV init "compatibility" and uses a BSD-style of init:
System V init compatibility was introduced in Slackware 7.0. Many other Linux distributions make use of this style instead of the BSD style. Basically each runlevel is given a sub-directory for init scripts, whereas BSD style gives one init script to each runlevel.
I'm not sure why it is phrased this way, but it has led a lot of people, including Slackware users, to believe the distribution runs a version of init imported from the BSDs or a custom init implementation, and Slackware developers have modified it to run SysV init scripts.
The truth is, Slackware uses SysV init. The scripts and configuration the distribution uses with SysV are arranged in a way that is very much like classic Unix or BSD in structure.
Detecting which init is running
At this point you might be wondering how you can know which init implementation you are running. There are a few approaches you can use. On any distribution running systemd, we can quickly confirm systemd is the init software by running the following command:
$ cat /proc/1/comm
systemd
The above command checks the name of the program running as init, the first process (PID 1). On most distributions this will return the name "systemd". Alternatively, on distributions running the runit software, you should see the following:
$ cat /proc/1/comm
runit
However, the command might return "init" instead, like this:
$ cat /proc/1/comm
init
Then we still have work to do as multiple init implementations call themselves simply "init". On distributions running SysV we can confirm the implementation by asking init itself:
$ init --version
SysV init version: 3.06
As you can see, SysV identifies itself by name in the version information.
In situations where the above commands do not reveal an answer, then you can usually see which init implementation you have by running the following command:
$ ls -l $(which init)
What this does is look up the path of the init software, usually /sbin/init, and displays the filename or name of the symbolic link at that location. This will often end up revealing that "init" is actually a symbolic link to another program, such as BusyBox or openrc-init, which reveals the name of the implementation of init in use.
* * * * *
Additional answers can be found in our Questions and Answers archive.
|
| Released Last Week |
MX Linux 23.3
The developers of MX Linux, a Debian-based desktop distribution with graphical administration tools and a choice of three popular desktops, have announced the release of MX Linux 23.3: "MX Linux 23.3 'Libretto' released. MX Linux 23.3 is the third refresh of our MX 23 release, consisting of bug fixes, kernel, and application updates since our original release of MX 23. If you are already running MX 23, there is no need to reinstall. Packages are all available through the regular update channels or by installing the changed applications. Some highlights include: when using the installer's OEM mode, the user will be able to select a system language before user setup starts so that the setup will be in the chosen language, this is set up by default on the RPI respin release; updated manual and manual now divided into language-specific packages; MX Locale tool includes a function to remove all manual packages except current system default language; zstd compression option added to live-remaster (antiX live system); systemd is usable on live system in rudimentary fashion; many language updates." Here is the complete release announcement.
GhostBSD 24.04.1
GhostBSD is a desktop-oriented operating system based on FreeBSD. The project's latest release is GhostBSD 24.04.1 which is based on FreeBSD's 14-STABLE development branch. The new snapshot includes an update to the MATE desktop to version 1.28.1, a return of the desktop Signal client, and a collection of bug fixes. "I am pleased to announce the release of GhostBSD 24.04.1! First and foremost, I extend my heartfelt gratitude to all those who reported issues and contributed their time, effort, and expertise to enhance GhostBSD for this latest release. GhostBSD 24.04.1 is the second release under FreeBSD 14 stable. I have updated the system to 1400510, and the MATE desktop is updated to 1.28.1. This release also contains some bug fixes found in previous releases and with some improvements." The release announcement contains a complete list of new features and bug fixes. GhostBSD maintains one official edition with the MATE desktop and a community edition which uses the Xfce desktop.
Alpine Linux 3.20.0
Alpine Linux is a community developed operating system designed for routers, firewalls, VPNs, VoIP boxes, containers, and servers. The project's latest stable release is Alpine Linux 3.20.0 which features a number of package updates, including Linux 6.6, GNOME 46, and KDE Plasma 6. The new version also introduces 64-bit RISC-V support: "We are pleased to announce the release of Alpine Linux 3.20.0, the first in the v3.20 stable series. Highlights: LLVM 18; Node.js (LTS) 20.10; Python 3.12; Ruby 3.3; Rust 1.78; Crystal 1.12; GNOME 46; Go 1.22; KDE 6; Sway 1.9; .NET 8.0. Significant changes: Initial support for 64-bit RISC-V was added." Additional information can be found in the project's release announcement and in the release notes for 3.20.0.
Murena 2.0
The Murena project delivers a de-Googled version of Android for smartphones which include several privacy protecting features and independent cloud services. The Murena team have released Murena 2.0 which ships with an updated version of the Bliss launcher, more capable tracker blocking, built-in QR code recognition in the camera app, and IP address hiding. "Advanced Privacy is a unique tool we have developed to prevent trackers from accessing your data while you are using third-party apps or just browsing the web. Let's have a look now at the enhanced Advanced Privacy features in /e/OS V2. Advanced Privacy lets you manage in-app trackers, IP addresses, and location. It's available as a widget and within the operating system settings. And now in a recent update, you can enjoy a better experience with Advanced Privacy with a more intuitive user interface; you'll have greater control over your privacy settings. In Advanced Privacy settings, you can also manage tracker permissions by app and see the complete statistics of trackers blocked." Additional information is provided through the release announcement and in the release notes. Download options for supported devices can be found on the project's Devices page.
Murena 2.0 -- The Bliss launcher
(full image size: 2.2MB, resolution: 1440x2960 pixels)
Ultramarine 40
Ultramarine Linux is a Fedora-based, desktop distribution which attempts to provide a better, out-of-the-box desktop experience. The project's latest release, Ultramarine Linux 40, swaps out the Pantheon desktop for Xfce and offers support for ARM devices, such as Raspberry Pi computers. "Now the moment we're sure you've been waiting for: Xfce Edition is here! Our new fourth edition (more about that further down.) Let's take a peek. Xfce Edition stays close to the stock Xfce experience with a little bit of Ultramarine spice sprinkled in. We embrace a more traditional dock and panel setup, compared to Xfce's split layout, and use a more modern menu (with search.) In addition to these layout changes, we use the beautifully familiar Materia theme. Xfce Edition is perfect for lower-powered devices and people who want to squeeze the most out of their computers." Additional information and screenshots can be found in the project's release announcement.
* * * * *
Development, unannounced and minor bug-fix releases
|
| Torrent Corner |
Weekly Torrents
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: 3,004
- Total data uploaded: 44.5TB
|
| Upcoming Releases and Announcements |
|
Summary of expected upcoming releases
|
| Opinion Poll (by Jesse Smith) |
Opinions on Plasma 6
Last year we asked what people thought of the upcoming Plasma 6 release. At the time over 80% of our readers who responded said they either hadn't used Plasma 6 or it was too soon to tell how the new version of KDE's desktop was going to perform. Now a few distributions, such as Fedora and Manjaro have shipped with Plasma 6 and others have packaged the desktop. What do you think of Plasma 6 now that it is has been launched as a stable release?
You can see the results of our previous poll on preferred system installer style in our previous edition. All previous poll results can be found in our poll archives.
|
How do you feel about Plasma 6?
| I like Plasma 6 better than Plasma 5: | 281 (12%) |
| I like Plasma 6 less than Plasma 5: | 82 (4%) |
| I like Plasma 6 and Plasma 5: | 223 (10%) |
| I do not like Plasma (5 or 6): | 70 (3%) |
| I do not use Plasma: | 1472 (65%) |
| Undecided: | 132 (6%) |
|
|
| Website News |
Donations and Sponsors
Each month we receive support and kindness from our readers in the form of donations. These donations help us keep the web server running, pay contributors, and keep infrastructure like our torrent seed box running. We'd like to thank our generous readers and acknowledge how much their contributions mean to us.
This month we're grateful for the $117 in contributions from the following kind souls:
| Donor |
Amount |
|---|
| J S | $50 |
| Mitchell V | $10 |
| Jonathon B | $10 |
| Sam C | $10 |
| Brian59 | $5 |
| Chung T | $5 |
| surf3r57 | $5 |
| TaiKedz | $5 |
| Mark C | $5 |
| Flaviano S | $4 |
| J.D. L | $2 |
| PB C | $2 |
| c6WWldo9 | $1 |
| Stephen M | $1 |
| Shasheen E | $1 |
| William E | $1 |
* * * * *
New distributions added to waiting list
- Oshin OS. Oshin OS is a desktop Linux distribution featuring the KDE Plasma desktop. The distribution ships with filters and parental controls in an attempt to filter undesirable content and messages.
* * * * *
DistroWatch database summary
* * * * *
This concludes this week's issue of DistroWatch Weekly. The next instalment will be published on Monday, 3 June 2024. Past articles and reviews can be found through our Weekly Archive and Article Search pages. 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)
|
|
| Tip Jar |
If you've enjoyed this week's issue of DistroWatch Weekly, please consider sending us a tip.
(Tips this week: 1, value: US$2) |
|
|
|
 bc1qxes3k2wq3uqzr074tkwwjmwfe63z70gwzfu4lx  lnurl1dp68gurn8ghj7ampd3kx2ar0veekzar0wd5xjtnrdakj7tnhv4kxctttdehhwm30d3h82unvwqhhxarpw3jkc7tzw4ex6cfexyfua2nr  86fA3qPTeQtNb2k1vLwEQaAp3XxkvvvXt69gSG5LGunXXikK9koPWZaRQgfFPBPWhMgXjPjccy9LA9xRFchPWQAnPvxh5Le paypal.me/distrowatchweekly • patreon.com/distrowatch |
|
| Extended Lifecycle Support by TuxCare |
|
|
| Reader Comments • Jump to last comment |
1 • Manjaro issues upon first boot (by brad on 2024-05-27 00:53:52 GMT from United States)
I have noticed that the first boot after installing Manjaro presents problems similar to the problems that Jesse mentioned in his review.
I've been using Manjaro long enough now to find that whatever issues crop up after first boot are usually resolved without further intervention after a subsequent boot.
Of course, things like that just shouldn't happen, as Jesse has observed, but I like Manjaro enough to "overlook" this particular flaw, reboot, and continue to use it, because of its many good qualities (the one I like the best is the ease of installing "LTS" kernels in place of the "latest and greatest").
I'm also pleased with how well Wayland works with Plasma - I've been "testing" it for over a month, and have found no show-stoppers (full disclosure - I don't have an NVIDIA graphics card on my laptop).
2 • Init systems (by New User on 2024-05-27 01:18:17 GMT from Canada)
Thanks for that discussion on init systems. This was the clearest explanation I have ever come across. I use primarily Slackware (and derivatives), so familiar with Sysvy, and have had no problem editing it's scripts. Occassionally used Debian (before systemd came along) and found the script layout looked a bit "messier".
Thanks to your clear explanation, I understand why; and for the first time, have gained some insight into why systemd MIGHT be appreciated (by some). Personally, it still comes across as an abomination.
In last week's weekly edition, you'd asked about suggestions re coverage. Perhaps a step-by-step tutorial on taking a disto (say Debian and or Slackware), and replacing it's default init with OpenRC or rcunit.
Seem to recall coming across a distro that offers a choice of init (including OpenRC and runit) during install. Might have been MX? (Do recall that MX does at least offer a choice of whether you want to use systemd during install).
Much as I dislike systemd, have at least come across numerous tutorials on THAT one.
Part of the problem is sometimes, there is not enough information, and sometimes there is so much, it takes time to plow through it all; and just haven't got time anymore. So when you give your weekly answers to reader's questions, that one feature alone makes this site invaluable.
Sites like linuxquestions are great, but usually go there when looking for specific answers. Over HERE, we pick up new knowledge each week that we weren't expecting to find!
3 • Manjaro punching bag (by Rick on 2024-05-27 01:22:20 GMT from United States)
This review seems to be a clear case of punish Manjaro, which is number 5 on the distrowatch home page. What distro are you recommending? Can you join the Manjaro team to support the distro and make it "perfect"?
4 • slackware init (by john on 2024-05-27 02:00:13 GMT from Canada)
Yes, Slackware uses sysV, but what I did not see mentioned is all init scripts are in one specific Directory, /etc/rc.d
The sysv run level directories exist and are usually empty. But these will be examined if some package dumps something in one of those directories.
I actually like the Slackware method better than the BSDs, want or do not want a service, do a chmod(1) on the init script in "/etc/rc.d". Nice and simple :)
BSDs want you to edit /etc/rc.conf and systemd wants you to issue a 1 or maybe 2 commands (I forget).
Anyway very nice overview.
5 • Manjaro experience and troubleshooting (by Vinfall on 2024-05-27 02:06:19 GMT from Hong Kong)
The reason I prefer Manjaro over Arch/Artix is simple, it does not break after I blindly run "sudo pacman -Syu" (or in the Manjaro way, "pamac upgrade -a") upon initial setup. Of course I should read all the changes careful before bumping versions. But none of the other rolling releases (Void, Gentoo, openSUSE Tumbleweed or even Debian "unstable") I use have this problem, so I would blame Arch for this even if it's my fault.
Also, I happened to try Manjaro-sway last week and it just works like a charm, despite the fact that I was unable to run Calamares installer. Everything is well-suited, calcurse opens when you click on date, htop shows up if you click on system usage status bar... I'm still trying to set up a similar workbench in Void in favor of musl-libc.
Regarding the update issue, it *might* relate to a misconfigured file (I entercountered that on SwayWM, not Plasma, so YMMV). Manually removing /var/tmp/pamac/dbs/sync and create a directory of the same name solves the issue for me. Or maybe it's a keychain issue as always, at times I have to run "pacman-key --init" before using pacman.
6 • Manjaro Plasma - pamac authentication (by Roger Brown on 2024-05-27 03:19:53 GMT from Australia)
Issue is not evident in Manjaro Xfce 24.0-240513 running under VirtualBox but it was noted in a clean Manjaro Plasma 24.0-240513 installation also under VirtualBox.
In this case authentication failed on first attempt but then succeeded on retry (correct password used in both instances). Command line installation either using pacman or pamac was fine.
Hopefully the Manjaro devs will sort this out because otherwise this implementation of Plasma works very nicely.
7 • Pamac, review (by Mr. Moto on 2024-05-27 03:33:27 GMT from Philippines)
Had the same problem with Pamac authorization. It resolved for me with "sudo pacman -Syu" Did the update, restarted. No more problem. (Don't know why. I ain't no techie,)
8 • Undecided vote on Plasma 5 and 6 (by Bobbie Sellers on 2024-05-27 04:53:47 GMT from United States)
I use KDE's Plasma 5.27.11 and am very happy with it.
Using a Rolling Release I wait on the packager to compile the DE as with any other
part of PCLinuxOS 2027.05. I read with great interest every report on Plasma 6
and hope that it's arrival on my machines will not impede my rather slow
work flow. Sooner or later it will come to my Dell 7730 and my E7450.
bliss- Dell Precision 7730- PCLOS 2024.05- Linux 6.6.31-pclos1- KDE Plasma 5.27.11
9 • Arch and derivatives not for me (by Any on 2024-05-27 05:20:59 GMT from Spain)
I tried in the past to use Manjaro and then Artix as my daily driver but they were prone to mismatch KDE after one month of updates. So, no rolling release distribution for me. Finally I settled on Debian Stable. Still my preferred distro is Slackaware, but what keeps me on Debian is it is much easier finding and installing some programs. I got lazy :)
As of the poll - I haven't tried KDE6 yet.
Thank you for explaining the init systems in Linux.
10 • Manjaro 24 with KDE 6 (by Terry Parris on 2024-05-27 06:38:29 GMT from United States)
Jesse,
I recently downloaded and installed Manjaro 24 with KDE 6 (minimal image). I chose the minimal image as it allows me to do more custom selection of software to my taste. I'm happy to report that I had none of the issues you ran into with pamac graphical software center nor getting the "desktop cube" working. Though I too had to install qt6-quick3d package like you did. Using the "meta + C" works. My only complaint with the cube is not having the open windows float above the cube face like it did in KDE 5.
Though I've not had good luck trying to run the cube in PopOS (with installed extension) nor any other flavor of Gnome. Same applies with Linux Mint Cinnamon and it's cube extension. It's possible I did not look into getting this extension set up properly in either desktop.
As to your issues with desktop effects in virtualbox, most distributions (KDE Neon, EndeavourOS, and Manjaro etc. etc.) distinctly disable many desktop effects in virtualbox as well as KVM. I've verified this using both forms of virtualization. The jumping taskbar which you mentioned is also something that can take some getting use to. The plasma taskbar is actually a floating taskbar. When you maximize a window the taskbar will jump. This can be avoided completely by right clicking on the taskbar, select enter edit mode, then under Style sliding the slide bar to the right. That will disable the float taskbar and stop the jumping around.
As to the "full image" which you used to install Manjaro KDE 24 causing the pamac issues you stated, I'm not sure what caused that. I know you check the downloads via checksum. You might have to check back in a bit. It's possible they may have corrected the issues you ran into with that image file.
And for your knowledge, I installed Manjaro KDE 24 on a System 76 Pangolin 11 with 32 GB of RAM and 1 TB of SSD. The only extra work I had to do in order for Manjaro to work without issues on this laptop was to install the System 76 drivers via AUR and using pamac. Other than that, I'm happily running KDE 6 with only one bug which I've yet to report to KDE involving dual monitors.
11 • Plasma 5 vs 6 (by Chris on 2024-05-27 06:52:26 GMT from South Africa)
I am running Plasma 5 on Kubuntu 24.10 and very happy and often think about when the Plasma 6 testing will begin ;)
12 • Hon /e/ pot (by Mur(ky ar)ena on 2024-05-27 08:08:17 GMT from United Kingdom)
Why take a google system and ‘attempt’ to de-google it?
But it makes an excellent platform to target surveillance to those who seek to circumvent the dragnet.
Perhaps The best thing to do with a murena is burn it before using it.
13 • Manjaro (by tomas on 2024-05-27 08:43:25 GMT from Czechia)
I have two installations of Manjaro on my PCs.
After running an upgrade on the first one I have now the problem of authentication in Pamac.
It is rather a long time since then but still no solution.
On my other installation I have already 728 updates available but I will not go into that!
As a side-note I must say that some visitors here insist that the "ordinary" user must read every information before installing some software or update.
I strongly disagree with this opinion - if this is necessary, Linux will always stay behind the closed operating systems like Windows or MacOS (though Windows had also some downfalls).
14 • Manjaro (by Jürgen on 2024-05-27 10:35:20 GMT from Czechia)
Ever since using Manjaro for a few weeks (several years ago), and then suddenly getting a non-booting system (no error messages, nothing), I had to realise Arch and derivatives are what they say they are: useful toys for learning, but totally unreliable for any practical use. (There was no information on either the Arch or Manjaro pages about any update needing attention, the distro suddenly just wouldn't boot. There wasn't even a back-up older kernel, because it wasn't configured by default.) I know, I know: some people will tell how their Arch(-based) distro is running without errors for decades now (Yeah, for sure...), but that won't change the fact the a distro "deciding" not to boot (without any visible reasons) is unusable. It's almost "good" to see it doesn't work very well these days either.
15 • Init Systems (by Otis on 2024-05-27 11:21:11 GMT from United States)
Amazing explanation of the init systems! Thank you for that, Jesse.
I've been philosophically against systemD since I began reading about its implementation in the open source world several years ago. But to tell the truth I have never seen or detected any significant differences between init systems as I distro hopped over the years.
Perhaps I did see or feel a difference from one distro to the next, but did not know it may have been a nuance of systemD, SysV vs OpenRC etc.
Bottom line is Linux users settle into their respective distro(s) and maybe the init software is not noticed much.
16 • Manjaro (by Roger Brown on 2024-05-27 11:21:24 GMT from Australia)
@14 Your experience of Manjaro from several years ago is almost certainly irrelevant to this discussion as the maintainer arrangements have significantly changed for the better in recent years.
That said, Archlinux, and to a fair extent, Manjaro are designed for experienced users who know how to keep their installation up to date, to diagnose and correct problems, and to take precautions such as installing a back up kernel series (usually linux-lts).
For these users, and I am one such, Arch and its derivatives are indeed reliable.
17 • init modularity (by BluPhenix316 on 2024-05-27 11:46:50 GMT from United States)
You said you liked s6 because it is modular. You didn't mention in the description of systemd that, it too, is modular.
systemd does a lot of things but the last I checked it too was modular. You could just run with the init replacement systemd and not use all the other stuff you mentioned.
For example systemd-boot does exist but most distros I've used(and currently use) still use Grub2. They don't use systemd-boot.
18 • systemd (by Jesse on 2024-05-27 11:50:57 GMT from Canada)
@17: "You said you liked s6 because it is modular. You didn't mention in the description of systemd that, it too, is modular."
That's because systemd is not at all modular. Not even a little. You can't, for example, use runit for init and systemd for service management. You can't use just systemd-home, but not systemd-init. They are all tied together.
With the other systems, like s6 and OpenRC you can swap components from other stacks. You can run SysV init with OpenRC managing services, for example.
19 • init (by Jesse on 2024-05-27 11:57:27 GMT from Canada)
@2: "Seem to recall coming across a distro that offers a choice of init (including OpenRC and runit) during install. Might have been MX? (Do recall that MX does at least offer a choice of whether you want to use systemd during install)."
There are three possible times when a distribution can provide init choice: Downloading, Installing, and Booting. In other words, you can select an init system tied to an ISO, you could select which init to enable in the installer, or you can select your init software at boot time from the GRUB menu.
antiX, Devuan, and Artix all allow you to select your init software at download time (you pick the appropriate ISO).
As far as I know there are not any binary distributions where you pick your init software at install time. Though I believe both Gentoo and LFS allow the user to pick their init software during the build process.
MX Linux allows you to pick your init software (SysV or systemd) at boot time from the GRUB menu.
20 • runit (by R. Cain on 2024-05-27 12:10:09 GMT from United States)
Can 'runit' be installed on MX-Linux? For absolutely dead-certain?
21 • init aware (by crayolaeater on 2024-05-27 13:22:33 GMT from United States)
@15
"Bottom line is Linux users settle into their respective distro(s) and maybe the init software is not noticed much. "
I would think not noticing the init would be a good defining description of init working well.
Like you, I have really never had any real issue (at least not instgated by me) with any init. Cut my linux teeth on Slackware and SysV eons ago, and since have run distros with systemd and runit. On all, I just let init do it's business, and now I pretty much keep my fumbling fingers off them.
In the end, I remain partial to my first, SysV, yet stay intrigued with runit for it's being the most 'linux' to me - lean, simple, basically one job and do it well.
22 • init (by kc1di on 2024-05-27 13:49:14 GMT from United States)
Just want to thank Jesse for the nice write up on init. Easy to understand.
Thank you. I like many I suppose don't pay a lot of attention to Init system as long as the system boot. But like the Idea of runit.
23 • manjaro (by hmm on 2024-05-27 13:52:31 GMT from Moldova)
Jesse,
this article is unfair, cause it is from a distrohopper's point of view, who ocasionaly tries manjaro, but never used it for a period of time.
the problem with pamac on manjaro, is because manjaro is a rolling release, and pacman design limitations,
the solution is to do a 'pacman -Syuu', pacman will update its caches(or whatever), and then everything will work just fine (pacman, yay, pamac cli and pamac gui).
every user of manjaro knows that, also every user of arch who uses pacman on other arch based distros knows that too...
so thats why IMHO it is an unfair article.
p.s:
pamac has wonderful cli and integration with aur and both snap & flatpak)
for example `pamac install vlc` instead of `pacman -S vlc`
but some problems are from upstream, i hope they will be fixed some day...
24 • Manjaro (by Jesse on 2024-05-27 13:57:57 GMT from Canada)
@23: "this article is unfair, cause it is from a distrohopper's point of view, who ocasionaly tries manjaro, but never used it for a period of time."
Why would you think I haven't used Manjaro for any length of time? This is a false assumption.
"the problem with pamac on manjaro, is because manjaro is a rolling release, and pacman design limitations,
You probably mean "Pamac" rather than "pacman" here? As I mentioned in the review, pacman worked perfectly.
"the solution is to do a 'pacman -Syuu', pacman will update its caches(or whatever), and then everything will work just fine
I did that. It doesn't work. As I mentioned in the review, even after running the updates from pacman, Pamac still failed to function.
"every user of manjaro knows that, also every user of arch who uses pacman on other arch based distros knows that too..."
Yes, that is why it was the first thing I tried.
"so thats why IMHO it is an unfair article."
How is it unfair to point out something is broken? Also, how is it unfair of me to point out something is both broken and that your suggested fix doesn't work?
25 • manjaro (by hmm on 2024-05-27 14:02:03 GMT from Moldova)
also, maybe there is a bug in how installer configures users in manjaro
in the installer there is a checkbox to use same password for root as the password of the main user, maybe the GUI package updates didn't work in this edition because this option wasn't checked...
cause it is a rolling release, sometimes unfortunatelly such bugs happen, and fixed in next .iso build.
26 • init choice (by Jimmy T. Geek on 2024-05-27 14:18:56 GMT from United States)
I like having a boot choice for init and use MX.
Jellyfin seems to require SystemD. Most of the time I boot with SysV because I don't want SystemD to override my choices.
Years ago, before I had more Linux experience, Mint 13 and an update to systemd changed my DNS from local dnsmasq with two host files and upstream resolver using DNSCrypt to systemd-resolve and Google DNS. At the time, the documentation for stopping systemd-resolve did not work. My solution was to find a better distro.
I have tried Manjaro and liked it but not as well as MX because of init choice and because MX has great tools such as snapshot and Live USB maker.
27 • SysV (by Otis on 2024-05-27 15:17:02 GMT from United States)
@21 (crayola eater, lmao brings back grade school memories).. anyway, noticing for the first time a short while back that our venerable Jesse is the maintainer/dev(?) of SysV, I think we should seek out and deploy whatever distros have that particular init, just as a reward to him for his dedication and work in that and this site. We can provide a plethora of feedback right here. ;o)
Now, we also await a Jesse developed Linux Distro Extraordinaire, no fooling. That would be something indeed (if he's already done that, don't tell me; I feel dumb enough about all this as it is).
28 • init and distro (by Jesse on 2024-05-27 15:25:07 GMT from Canada)
@27: " anyway, noticing for the first time a short while back that our venerable Jesse is the maintainer/dev(?) of SysV, I think we should seek out and deploy whatever distros have that particular init, just as a reward to him for his dedication and work in that and this site."
This is a nice idea, thank you. But please, use what works for you. I use SysV init, I like it. But I don't claim that it is the best init software. I encourage everyone to use what best suits their needs.
"Now, we also await a Jesse developed Linux Distro Extraordinaire, no fooling."
I've never created my own distro from scratch. I have contributed to a handful, but I've always been more inclined to help someone else improve their vision of a distro/game/init/service than build my own. The only distribution I've had a big role in was Phat Linux, but that was ages ago.
29 • runit (by former on 2024-05-27 15:46:28 GMT from United States)
@20 Don't know about MX. I know antiX now also uses 'runit' (and of course sysvinit). antiX and MX devs are working together, so maybe MX can in the future go 'runit' way also?
30 • @ 23; @ 24 • Manjaro (by Jesse... (by R. Cain on 2024-05-27 15:48:35 GMT from United States)
Everyone here needs to read the following article.
Every *fan(boy/girl)* needs to read the following article.
Every thin-skinned individual who thinks that a negative review, or a negative comment about their all-time personal-favorite Linux distribution is a personal attack needs to read this ("all-time personal favorite" for today, anyway; most of these types are distro-hoppers--hobbyists only--who have no concept nor intention of sticking with one distro long enough to learn anything about it...but they WILL attack anyone who has the temerity to comment negatively on their "distro du jour").
"Reading Comprehension is a Big Problem in Open-Source"
Updated: February 24, 2016
https://www.dedoimedo.com/computers/linux-reading-comprehension.html
A few snippets from the article for your serious (one can only hope) consideration...
----------------------------------------------------------------
"Commenter: "Wow. Sad to think that the reviewer only needed to add Packman to "fix" most of the issues he faced." "
"Reviewer: "No. It is sad that whoever wrote this comment didn't bother reading the review and paying attention to my message. Adding Packman was probably the FIRST thing I did." "
"...and the focus switches from technical pain points, of which there are many...to personal traits of the reviewer and how he/she may be suited to using Linux."
"...It makes me wonder if these kind of people ever bother reading anything at all, or if they are firing semi-coherent responses just because a title of a post or something along those lines caught their attention. And rage..."
"...The fact people comment on things without reading. After all, all those words. So difficult..."
"...When people [ a REVIEWER ] complain about technology, they are not attacking you [dear READING-COMPREHENSION-DEPRIVED READER ]. They are attacking lousy products. They want shit done. As long as the commentary diverges into discussions about noobs, someone's ability to gstreamer their sister and such, Linux will NEVER rise mighty as a consumer product. If your first instinct is to discuss the reviewer, you should shift-delete your Internet. It's all about being able to receive constructive feedback. Once that happens, we might actually end up with some decent software..."
-------------------------------------------------------------
Warmest regards...
31 • init (by ric on 2024-05-27 16:55:57 GMT from United States)
@19: "As far as I know there are not any binary distributions where you pick your init software at install time. Though I believe both Gentoo and LFS allow the user to pick their init software during the build process."
PeppermintOS's latest offers a debian base (systemd) version or a devuan base (sysV) version at download time; and, either 64bit or 32bit.
If one chooses PeppermintOS devuan version, one has a choice of 3 inits during installation: sysV, runit, openRC.
32 • KDE 6 (by J on 2024-05-27 17:36:47 GMT from Panama)
I voted for "Like KDE 6 less than 5" simply because some of the applets I like and latte-dock were discontinued and are incompatible witrh KDE 6.
33 • Plasma 6? Better to wait. (by Alvaro on 2024-05-27 20:30:11 GMT from Italy)
I tried Plasma 6 on Fedora KDE spin and had annoying problems with the bottom bar. Better to wait for the project to mature.
34 • init diversity (by anticapitalista on 2024-05-27 21:06:21 GMT from Greece)
antiX has a supported alpha development release by a user that is called init-diversity.
It includes sysVinit, runit, s6 and s6-66 on the live booting iso.
User can choose which init to try when running 'live'.
If user installs to a hard drive, all 4 init systems are still available and can be booted into.
More information here:
https://antixlinux.com/unofficial-antix-23-init-divesity-spin/
35 • @16 Manjaro (by Jürgen on 2024-05-27 22:00:46 GMT from Czechia)
@16 I was expecting an Arch-/Manjaro-fanboi post, and you didn't disappoint. :) Let me disprove your faulty "arguments".
> Your experience of Manjaro from several years ago is almost certainly irrelevant to this discussion
No, it isn't. Fanbois praised the hell out of both of them and swore to their mother's life that both were rock solid, dependable OS's -- they kept saying that even then. They weren't and they clearly still aren't.
> Archlinux, and to a fair extent, Manjaro are designed for experienced users who know how to
As a reply to me, this an ad hominem (which invalidates it instantly), moreover it is factually wrong. (Why the hell do you assume things?) I am certified in Linux system administration, already have been when I tried Manjaro as a daily driver. And while I never had as much experience with Arch/Manjaro as with Debian et al., I practiced a lot with them, did the manual Arch installation several times, so thank you, I knew what I was doing. To top it off, I did everything by the book, as they suggested if for beginners. Yes, I had the lts kernel (it was either the default, or I switched to it; I definitely checked I had those). I had no backup kernel because at the time there was nothing about it in the "newb" docs. I always disable splash-screens and such, and enable kernel messages, because I like to see what's going on -- or not going on. Manjaro suddenly stopping to boot with absolutely no visible error and without absolutely any obvious reason is a typical Arch-family problem. (And there was nothing in either the Arch or Manjaro news to suggest something needed attention.) I kept my system up-to-date, I didn't even wait long with updates, I did them every day or two (mostly daily). (By the way, not-regular-enough updates being able to break the system is cold hard proof how unreliable it is. You can update a Debian-machine after it has been turned off for months, and it won't bat an eyelash. You can do major-version upgrades just like a simple update, the only extra is changing the codename in the repo source files, and that's it, upgrade, reboot, done. And some derivatives not being able to do this doesn't disprove the point.)
So, if you please, stop it with the assumptions (you got them wrong), stop it with the condescension, and stop it with the faulty arguments and denial. There is a reason you hardly (if ever) see Arch/Manjaro as a server. Red Hat (et al.), Debian (et al.), Ubuntu (et al.), Alpine, some other Linuxes and BSDs of course make great and reliable servers (thought it can be done wrong as well, of course), but Arch/Manjaro are nowhere near the ballpark. When they work, they work great -- then one day they decide they stop working, and then they don't work at all. That's not even desktop-stable, let alone server-stable.
36 • @28 - Jesse and Phat Linux (by Andy Prough on 2024-05-27 22:03:12 GMT from Switzerland)
@Jesse - >"The only distribution I've had a big role in was Phat Linux, but that was ages ago."
There's still a 2002 article on Linux.com by Jesse about bricking his Phat Linux installation by deleting his C library, and then figuring out how to get it all working again. Good times! Was it "Phat" as in the hiphop definition, or as in "Portable RedHat" or something Jesse? There was a "Pubuntu" a few years later which did a similar thing - allowed users to install a Portable Ubuntu on a file in a running Windows instance.
37 • Phat Linux (by Jesse on 2024-05-27 22:17:58 GMT from Canada)
@36: " Good times! Was it "Phat" as in the hiphop definition, or as in "Portable RedHat" or something Jesse?"
To be honest, I don't know where the name came from. That question never came up in my discussions with the project's creator. The Phat Linux distribution was based on Mandriva Linux though, not Red Hat, so probably not any variation of "Portable Hat".
Personally, I always thought the distribution's name (Phat) was an alternative spelling of "Fat" because Linus Torvalds said he wanted the Tux logo to look like this:
"You should be imagining a slightly overweight penguin, sitting down after having gorged itself, and having just burped. It's sitting there with a beatific smile -- the world is a good place to be when you have just eaten a few gallons of raw fish and you can feel another burp coming."
Maybe I'm wrong, but that was the way I always thought of the distribution's name - a nod to Torvalds and how he wanted Tux to look - fat/phat and happy.
38 • manjaro left me disappointed (by someMuppetOnTheInternet on 2024-05-27 22:55:21 GMT from Australia)
I used manjaro for a few months a few years ago, but it bricked itself (DE crashed, was unable to bring it up again) after a normal pamac update. It was a vanilla xfce installation, with nothing from the AUR. I replaced it with fedora. This, and some other tidbits I've picked up along the way have left me with the impression that manjaro sometimes doesn't quite live up to its aspiration of providing a stable/approachable version of arch. Jesse's weird password experience and a few comments from other folks here seem to gel with my impression. It's clearly got traction, and all distros have bugs and various other kinds of tradeoffs and shortcomings, but I moved on myself.
39 • init (by lincoln on 2024-05-27 23:08:30 GMT from Brazil)
Jesse, correct me if I'm wrong, but when you say sysvinit has around 3000 lines, are you referring only to the file init.c (https://github.com/slicer69/sysvinit/blob/main/src/init.c) (excluding dependencies)? If so, wouldn't it be more accurate to compare it to runit-init.c (76 lines) (https://github.com/void-linux/runit/blob/master/src/runit-init.c), which generates the runit-init.o executable (https://github.com/void-linux/runit/blob/master/src/Makefile), or at most adding the 346 lines of runit.c? Wouldn't all the other lines of runit be "helper programs and optional add-ons" or service manager implementation?
Another question, Jesse, what do you think of the design and implementation rules of Daniel J. Bernstein (creator of daemontools and inspiration for runit and s6) (https://cr.yp.to/qmail/guarantee.html) in relation to the Unix philosophy?
40 • @39 init (by picamanic on 2024-05-28 09:30:17 GMT from United Kingdom)
@39:lincoln. A more realistic comparison between the sizes of the sysvinit and runit init systems can be assessed from the respective source directories: sysvinit=11646, runit=6030 lines of C. From memory, the sysvinit scripts are the same again, whereas runit scripts are tiny. Most of the size for these init systems comes from the daemon/service management. Without that, basic "sinit" init is just 120 lines of C, and the same again scripts. More modern init systemd like "dinit" are a similar size. All these are small because they concentrate on just doing the things necessary to init Linux and basic daemons.
41 • @40: init [correction] (by picamanic on 2024-05-28 10:19:40 GMT from United Kingdom)
@40: 'modern init systemd like "dinit"', "systemd" is a typo, sorry.
42 • init (by dr.J on 2024-05-28 10:30:41 GMT from The Netherlands)
The legend is knitted and it is that systemd makes work so easy for developers. What should we users do? Fall to our knees in gratitude? I think it's a myth. The basic idea of systemd is similar to that of Microsoft or google: a few people out there create the perfect system (for their purposes of course) and then take care of it. And everyone is happy that they do the work for us.
What a load of crap.
runit or OpenRC show that at most a few scripts are needed to control the basic processes of a system. The many processes that systemd has now taken over, including timers for logrotate etc., the completely unnecessary replacement for cron etc. only show me that a new monster is being created here that no longer has anything to do with the basic idea of Linux/Unix/BSD.
43 • @40 init (by lincoln on 2024-05-28 12:42:53 GMT from Brazil)
@40:picamanic. Take into account that within these 6030 lines of runit, there are experiment files (trycpp.c, trydrent.c, tryflock.c, trymkffo.c, trypoll.c, tryreboot.c, trysgact.c, trysgprm.c, tryshsgr.c, trysocketlib.c, trysysel.c, tryulong64.c, tryuwtmp.c, tryuwtmpx.c, trywaitp.c).
And a partial reimplementation of stdlib.h, stdio.h, string.h, unistd.h, signal.h as can be observed in the files alloc.c, alloc_re.c, buffer.c, buffer_0.c, buffer_1.c, buffer_2.c, buffer_get.c, buffer_put.c, buffer_read.c, buffer_write.c, byte_chr.c, byte_copy.c, byte_cr.c, byte_diff.c, byte_rchr.c, env.c, error.c, fmt_ptime.c, fmt_uint.c, fmt_uint0.c, fmt_ulong.c, open_read.c, open_trunc.c, open_write.c, openreadclose.c, scan_ulong.c, seek.h, seek_set.c, sig_block.c, sig_catch.c, sig_pause.c, str_chr.c, str_diff.c, str_len.c, str_start.c, stralloc.h, stralloc_cat.c, stralloc_catb.c, stralloc_cats.c, stralloc_eady.c, stralloc_opyb.c, stralloc_opys.c, stralloc_pend.c, , strerr_die.c, strerr_sys.c, subgetopt.c, ... If necessary, the extra lines from the dinit event library (dasynq) need to be counted.
But the main point would be Daniel J. Bernstein's design and implementation rules in contrast to Unix philosophy. In your opinion, does the software not become smaller, faster, more reliable and secure because of them?
44 • init comparison (by Jesse on 2024-05-28 13:02:06 GMT from Canada)
@39: > "Jesse, correct me if I'm wrong, but when you say sysvinit has around 3000 lines, are you referring only to the file init.c"
Yes, you are correct. For context for folks reading the comments, this is what I wrote: "The runit software includes process monitoring, optional automatic service restarts, built-in support for running services in parallel, offers a logging service, and has a clean, filesystem-oriented approach to enabling services. All of this is accomplished with under 1,000 lines of C code. For comparison's sake; SysV init is about 3,100 lines of code. Once you factor in all of SysV's helper programs and optional add-ons the SysV suite is about 11,600 lines of C. systemd's suite is up to about 1,300,000 lines of C code."
So the direct 1:1 comparison for the whole suite is 1,000 of C for runit, 11,600 for SysV, and 1,300,000 for systemd.
> "Another question, Jesse, what do you think of the design and implementation rules of Daniel J. Bernstein (creator of daemontools and inspiration for runit and s6)"
I think Bernstein makes some good points, particularly about parsing and passing information between programs. Parsing is where things tend to get weird in terms of exceptions, unexpected input, and weird corner cases.
I am a big fan of Daniel's idea of reducing attack surface and minimal privileges.
The last point in the design guidelines though strikes me as not being practical. Daniel mentions a lot of the work on the example mailing service uses a custom library rather than a standard C library. This is probably not good universal advice for two reasons:
1. Custom libraries are not viewed/audited/used by many people so bugs are likely to be missed. Most developers will almost always be better off using dedicated libraries rather their own custom solutions as the former have been through trials by fire. We all make mistakes and those mistakes are more likely to be fixed in tools like musl c, glibc, OpenSSL, etc than in our one-off creations.
2. Writing everything from scratch, including the low-level libraries, will take a long, long time. It might improve security or simplify a design, but if the developer wants to ship their service or application in a reasonable timeline, then they will probably need to borrow some libraries for any non-trivia task.
45 • init comparison (by lincoln on 2024-05-28 13:44:40 GMT from Brazil)
@44: >Thank you very much for the answer Jesse, your work is formidable, with clear and objective ideas that are very well grounded and conveyed.
46 • init (by This-or-that on 2024-05-28 16:05:18 GMT from United States)
Thanks Jesse -- that was a nice piece of work that even I can understand. The only thing better would've been an example of how to start/stop/restart a service in each. Very much appreciated.
47 • init and reading comprehension (by Stasek on 2024-05-28 17:53:13 GMT from Czechia)
Thanks for the "reading comprehension" article, it is quite on point. It is funny you should link it now: this week's DW (and commenters) mentions init systems, and I also looked at a few MX Linux user reviews here this week. The common point? One reviewer complained about having to try to make MX work with systemd for compatibility with some software; and they weren't the first such user. Apparently they didn't read the most basic FAQ or description about MX linux; had they done that, they would know it ships with SysV init *änd* systemd, and booting it with systemd is as simple as choosing the right GRUB menu entry. What I'm about to say may contradict the "reading comprehension " article, but I stand by it: if someone knows about init systems and they know they need a particular one for whatever reason, they have no excuse not to realise it is already installed for them and ready to boot. Some users are indeed not knowledgeable (or rather: attentive) enough for the use of some distributions.
48 • SysV init (by beardless coder on 2024-05-29 00:53:52 GMT from New Zealand)
Thank you Jesse for an enlightening writeup on the init systems. It seems to have become a very political arena, mainly due to systemd increasing the exposure of a system as it tries to be one tool to rule them all. For most folks, you start a system, and work. Init, what?
SysV init has a special memory for me as it was the "new" thing when I was moving into smaller Unix systems in the 1990s. The whining voices back then were that SysV wanted a slightly different folder structure than previous releases... the one you see in still today in most Linux distros. People it seems complain about change, for any reason.
49 • Bug fixed in next ISO! (by Gary W on 2024-05-30 08:29:56 GMT from Australia)
@25 "fixed in next .iso build."
So you have to reinstall your rolling-release distro from a fresh ISO, to deal with an egregious bug? Sounds like a case for installing debian-stable, or one of its flash derivatives like MX.
50 • @20 runit and MX (by Hoos on 2024-05-30 13:55:24 GMT from Singapore)
"Can 'runit' be installed on MX-Linux? For absolutely dead-certain? ..."
I'm not sure how perfectly their systems run, but a search of MX forum would indicate that a few members have managed it.
I am guessing that since it's not default, you will need to be able to sort out any issues on your own.
Slight tangent - MX has a basic graphical service manager that works with systemd and sysV. There was a forum member using runit on MX asking if runit management might be added to the tool. The MX developer replied that while he was not interested in doing this, he would be happy to consider pull requests.
https://forum.mxlinux.org/viewtopic.php?p=755620#p755620
@Jesse, thank you for the init comparison article. It helps me understand things better.
Number of Comments: 50
Display mode: DWW Only • Comments Only • Both DWW and Comments
| | |
| TUXEDO |
TUXEDO Computers - Linux Hardware in a tailor made suite
Choose from a wide range of laptops and PCs in various sizes and shapes at TUXEDOComputers.com. Every machine comes pre-installed and ready-to-run with Linux. Full 24 months of warranty and lifetime support included!
Learn more about our full service package and all benefits from buying at TUXEDO.
|
| Archives |
| • Issue 1119 (2025-04-28): Ubuntu MATE 25.04, what is missing from Linux, CachyOS ships OCCT, Debian enters soft freeze, Fedora discusses removing X11 session from GNOME, Murena plans business services, NetBSD on a Wii |
| • Issue 1118 (2025-04-21): Fedora 42, strange characters in Vim, Nitrux introduces new package tools, Fedora extends reproducibility efforts, PINE64 updates multiple devices running Debian |
| • Issue 1117 (2025-04-14): Shebang 25.0, EndeavourOS 2025.03.19, running applications from other distros on the desktop, Debian gets APT upgrade, Mint introduces OEM options for LMDE, postmarketOS packages GNOME 48 and COSMIC, Redox testing USB support |
| • Issue 1116 (2025-04-07): The Sense HAT, Android and mobile operating systems, FreeBSD improves on laptops, openSUSE publishes many new updates, Fedora appoints new Project Leader, UBports testing VoLTE |
| • Issue 1115 (2025-03-31): GrapheneOS 2025, the rise of portable package formats, MidnightBSD and openSUSE experiment with new package management features, Plank dock reborn, key infrastructure projects lose funding, postmarketOS to focus on reliability |
| • Issue 1114 (2025-03-24): Bazzite 41, checking which processes are writing to disk, Rocky unveils new Hardened branch, GNOME 48 released, generating images for the Raspberry Pi |
| • Issue 1113 (2025-03-17): MocaccinoOS 1.8.1, how to contribute to open source, Murena extends on-line installer, Garuda tests COSMIC edition, Ubuntu to replace coreutils with Rust alternatives, Chimera Linux drops RISC-V builds |
| • Issue 1112 (2025-03-10): Solus 4.7, distros which work with Secure Boot, UBports publishes bug fix, postmarketOS considers a new name, Debian running on Android |
| • Issue 1111 (2025-03-03): Orbitiny 0.01, the effect of Ubuntu Core Desktop, Gentoo offers disk images, elementary OS invites feature ideas, FreeBSD starts PinePhone Pro port, Mint warns of upcoming Firefox issue |
| • Issue 1110 (2025-02-24): iodeOS 6.0, learning to program, Arch retiring old repositories, openSUSE makes progress on reproducible builds, Fedora is getting more serious about open hardware, Tails changes its install instructions to offer better privacy, Murena's de-Googled tablet goes on sale |
| • Issue 1109 (2025-02-17): Rhino Linux 2025.1, MX Linux 23.5 with Xfce 4.20, replacing X.Org tools with Wayland tools, GhostBSD moving its base to FreeBSD -RELEASE, Redox stabilizes its ABI, UBports testing 24.04, Asahi changing its leadership, OBS in dispute with Fedora |
| • Issue 1108 (2025-02-10): Serpent OS 0.24.6, Aurora, sharing swap between distros, Peppermint tries Void base, GTK removinglegacy technologies, Red Hat plans more AI tools for Fedora, TrueNAS merges its editions |
| • Issue 1107 (2025-02-03): siduction 2024.1.0, timing tasks, Lomiri ported to postmarketOS, Alpine joins Open Collective, a new desktop for Linux called Orbitiny |
| • Issue 1106 (2025-01-27): Adelie Linux 1.0 Beta 6, Pop!_OS 24.04 Alpha 5, detecting whether a process is inside a virtual machine, drawing graphics to NetBSD terminal, Nix ported to FreeBSD, GhostBSD hosting desktop conference |
| • Issue 1105 (2025-01-20): CentOS 10 Stream, old Flatpak bundles in software centres, Haiku ports Iceweasel, Oracle shows off debugging tools, rsync vulnerability patched |
| • Issue 1104 (2025-01-13): DAT Linux 2.0, Silly things to do with a minimal computer, Budgie prepares Wayland only releases, SteamOS coming to third-party devices, Murena upgrades its base |
| • Issue 1103 (2025-01-06): elementary OS 8.0, filtering ads with Pi-hole, Debian testing its installer, Pop!_OS faces delays, Ubuntu Studio upgrades not working, Absolute discontinued |
| • Issue 1102 (2024-12-23): Best distros of 2024, changing a process name, Fedora to expand Btrfs support and releases Asahi Remix 41, openSUSE patches out security sandbox and donations from Bottles while ending support for Leap 15.5 |
| • Issue 1101 (2024-12-16): GhostBSD 24.10.1, sending attachments from the command line, openSUSE shows off GPU assignment tool, UBports publishes security update, Murena launches its first tablet, Xfce 4.20 released |
| • Issue 1100 (2024-12-09): Oreon 9.3, differences in speed, IPFire's new appliance, Fedora Asahi Remix gets new video drivers, openSUSE Leap Micro updated, Redox OS running Redox OS |
| • Issue 1099 (2024-12-02): AnduinOS 1.0.1, measuring RAM usage, SUSE continues rebranding efforts, UBports prepares for next major version, Murena offering non-NFC phone |
| • Issue 1098 (2024-11-25): Linux Lite 7.2, backing up specific folders, Murena and Fairphone partner in fair trade deal, Arch installer gets new text interface, Ubuntu security tool patched |
| • Issue 1097 (2024-11-18): Chimera Linux vs Chimera OS, choosing between AlmaLinux and Debian, Fedora elevates KDE spin to an edition, Fedora previews new installer, KDE testing its own distro, Qubes-style isolation coming to FreeBSD |
| • Issue 1096 (2024-11-11): Bazzite 40, Playtron OS Alpha 1, Tucana Linux 3.1, detecting Screen sessions, Redox imports COSMIC software centre, FreeBSD booting on the PinePhone Pro, LXQt supports Wayland window managers |
| • Issue 1095 (2024-11-04): Fedora 41 Kinoite, transferring applications between computers, openSUSE Tumbleweed receives multiple upgrades, Ubuntu testing compiler optimizations, Mint partners with Framework |
| • Issue 1094 (2024-10-28): DebLight OS 1, backing up crontab, AlmaLinux introduces Litten branch, openSUSE unveils refreshed look, Ubuntu turns 20
| | • Issue 1093 (2024-10-21): Kubuntu 24.10, atomic vs immutable distributions, Debian upgrading Perl packages, UBports adding VoLTE support, Android to gain native GNU/Linux application support |
| • Issue 1092 (2024-10-14): FunOS 24.04.1, a home directory inside a file, work starts of openSUSE Leap 16.0, improvements in Haiku, KDE neon upgrades its base |
| • Issue 1091 (2024-10-07): Redox OS 0.9.0, Unified package management vs universal package formats, Redox begins RISC-V port, Mint polishes interface, Qubes certifies new laptop |
| • Issue 1090 (2024-09-30): Rhino Linux 2024.2, commercial distros with alternative desktops, Valve seeks to improve Wayland performance, HardenedBSD parterns with Protectli, Tails merges with Tor Project, Quantum Leap partners with the FreeBSD Foundation |
| • Issue 1089 (2024-09-23): Expirion 6.0, openKylin 2.0, managing configuration files, the future of Linux development, fixing bugs in Haiku, Slackware packages dracut |
| • Issue 1088 (2024-09-16): PorteuX 1.6, migrating from Windows 10 to which Linux distro, making NetBSD immutable, AlmaLinux offers hardware certification, Mint updates old APT tools |
| • Issue 1087 (2024-09-09): COSMIC desktop, running cron jobs at variable times, UBports highlights new apps, HardenedBSD offers work around for FreeBSD change, Debian considers how to cull old packages, systemd ported to musl |
| • Issue 1086 (2024-09-02): Vanilla OS 2, command line tips for simple tasks, FreeBSD receives investment from STF, openSUSE Tumbleweed update can break network connections, Debian refreshes media |
| • Issue 1085 (2024-08-26): Nobara 40, OpenMandriva 24.07 "ROME", distros which include source code, FreeBSD publishes quarterly report, Microsoft updates breaks Linux in dual-boot environments |
| • Issue 1084 (2024-08-19): Liya 2.0, dual boot with encryption, Haiku introduces performance improvements, Gentoo dropping IA-64, Redcore merges major upgrade |
| • Issue 1083 (2024-08-12): TrueNAS 24.04.2 "SCALE", Linux distros for smartphones, Redox OS introduces web server, PipeWire exposes battery drain on Linux, Canonical updates kernel version policy |
| • Issue 1082 (2024-08-05): Linux Mint 22, taking snapshots of UFS on FreeBSD, openSUSE updates Tumbleweed and Aeon, Debian creates Tiny QA Tasks, Manjaro testing immutable images |
| • Issue 1081 (2024-07-29): SysLinuxOS 12.4, OpenBSD gain hardware acceleration, Slackware changes kernel naming, Mint publishes upgrade instructions |
| • Issue 1080 (2024-07-22): Running GNU/Linux on Android with Andronix, protecting network services, Solus dropping AppArmor and Snap, openSUSE Aeon Desktop gaining full disk encryption, SUSE asks openSUSE to change its branding |
| • Issue 1079 (2024-07-15): Ubuntu Core 24, hiding files on Linux, Fedora dropping X11 packages on Workstation, Red Hat phasing out GRUB, new OpenSSH vulnerability, FreeBSD speeds up release cycle, UBports testing new first-run wizard |
| • Issue 1078 (2024-07-08): Changing init software, server machines running desktop environments, OpenSSH vulnerability patched, Peppermint launches new edition, HardenedBSD updates ports |
| • Issue 1077 (2024-07-01): The Unity and Lomiri interfaces, different distros for different tasks, Ubuntu plans to run Wayland on NVIDIA cards, openSUSE updates Leap Micro, Debian releases refreshed media, UBports gaining contact synchronisation, FreeDOS celebrates its 30th anniversary |
| • Issue 1076 (2024-06-24): openSUSE 15.6, what makes Linux unique, SUSE Liberty Linux to support CentOS Linux 7, SLE receives 19 years of support, openSUSE testing Leap Micro edition |
| • Issue 1075 (2024-06-17): Redox OS, X11 and Wayland on the BSDs, AlmaLinux releases Pi build, Canonical announces RISC-V laptop with Ubuntu, key changes in systemd |
| • Issue 1074 (2024-06-10): Endless OS 6.0.0, distros with init diversity, Mint to filter unverified Flatpaks, Debian adds systemd-boot options, Redox adopts COSMIC desktop, OpenSSH gains new security features |
| • Issue 1073 (2024-06-03): LXQt 2.0.0, an overview of Linux desktop environments, Canonical partners with Milk-V, openSUSE introduces new features in Aeon Desktop, Fedora mirrors see rise in traffic, Wayland adds OpenBSD support |
| • Issue 1072 (2024-05-27): Manjaro 24.0, comparing init software, OpenBSD ports Plasma 6, Arch community debates mirror requirements, ThinOS to upgrade its FreeBSD core |
| • Issue 1071 (2024-05-20): Archcraft 2024.04.06, common command line mistakes, ReactOS imports WINE improvements, Haiku makes adjusting themes easier, NetBSD takes a stand against code generated by chatbots |
| • Issue 1070 (2024-05-13): Damn Small Linux 2024, hiding kernel messages during boot, Red Hat offers AI edition, new web browser for UBports, Fedora Asahi Remix 40 released, Qubes extends support for version 4.1 |
| • Issue 1069 (2024-05-06): Ubuntu 24.04, installing packages in alternative locations, systemd creates sudo alternative, Mint encourages XApps collaboration, FreeBSD publishes quarterly update |
| • Issue 1068 (2024-04-29): Fedora 40, transforming one distro into another, Debian elects new Project Leader, Red Hat extends support cycle, Emmabuntus adds accessibility features, Canonical's new security features |
| • Full list of all issues |
| Star Labs |
Star Labs - Laptops built for Linux.
View our range including the highly anticipated StarFighter. Available with coreboot open-source firmware and a choice of Ubuntu, elementary, Manjaro and more. Visit Star Labs for information, to buy and get support.
|
| Random Distribution | 
OB2D Linux
OB2D Linux (formerly B2D Linux) is a Debian-based Linux distribution developed in Taiwan, with user environment and read/write support for traditional Chinese.
Status: Dormant
|
| TUXEDO |
TUXEDO Computers - Linux Hardware in a tailor made suite
Choose from a wide range of laptops and PCs in various sizes and shapes at TUXEDOComputers.com. Every machine comes pre-installed and ready-to-run with Linux. Full 24 months of warranty and lifetime support included!
Learn more about our full service package and all benefits from buying at TUXEDO.
|
| Star Labs |
Star Labs - Laptops built for Linux.
View our range including the highly anticipated StarFighter. Available with coreboot open-source firmware and a choice of Ubuntu, elementary, Manjaro and more. Visit Star Labs for information, to buy and get support.
|
|
• 
• 
• 
• 
• 
• 
• 
