Run, don’t just add it on the TDO list, and download images from those two (Salix is dormant and part of Slackel) and if you do an installation, DO NOT do a network install, do copy from live image, or from CD. We will explain later, while you are downloading those historic pieces of Slackware forks.
Cut them some slack? New Years day and all happy hunky dory crap…. Not here folks, go to Phoronix or Fedora-Magazine for such festive atmosphere.
In our latest article about a stricter list of Linux distributions without systemd we located only 4 distributions up to now and we were asking for help from the community to locate the 5th, or more. A year ago we didn’t think it was that important, there were many. Many of what, you ask! Many that did not use systemd as init but also did not use elogind to support some demanding desktop setups. The common alternative for those who wanted to both support a variety of desktops and their software, is (IS) ConsoleKit2. Many of us who prefer a simpler system, a window-manager (either with floating or tiling windows) like to use the terminal to start and run anything, there may have not been any need for either one. Not even dbus. Not with all distributions, and it all depends on choices they make. Slackware has made it impossible to use with elogind. You can hardly use the console in Slackware without elogind/libelogind.
- I have not seen a worse case scenario, but I haven’t seen everything. There are more than 500 distros and forks out there, nearly half choose not to even list themselves in Distrowatch because of how they are portrayed, intentionally outdated unless they pay. Who can distro-hop throughout this entire ocean of distros?
How did we get a recent interest in Slackel/Zenwalk? Slackel we had seen and run a while back because Slackware + Openbox = Slackel. We remembered something positive out of the experience. Zenwalk has recently suggested by Oneirosopher as a possible candidate for out new list of elogind-less distros, and also because of the announcement of pipewire.
In the hunt to find more distros that both rejected the use of systemd and elogind, the thing to do is search for linux and consolekit in recent threads of forums, blogs, articles, announcements. So we run into most of the threads in LinuxQuestions relating to Slackware, there is hardly mention for anything else in LQ. Could it be true, Slackware has been such a healthy distribution for years and we neglected to pay extra attention to it? We JINXED it!
Back to our victims, Zenwalk, Slackel, Salix. Salix is dormant as the people contributing in Salix and some of those in Slackel seem to be about the same. One is the head of Salix another is the head of Slackel, but they seem to be friendly and cooperating. Zenwalk and Slackel are active and current distributions. Zenwalk comes with an image that is about 1GB and from experience you would expect a traditional live system with a desktop or window manager and some initial proposed set of software, together with an installer. Not true in Zenwalk. Zenwalk has the most minimalist system we have ever seen, it barely boots and runs the installer, that is it. Not even much of a console functionality. So why is it 1GB? Because all the necessary packages are included in cache in the live system. Basically you configure and mount a partition through the installer and the pkgs are handled by the package manager and installed. Very nice, you don’t have to have a network and you don’t get a modified copy of a live system as your system, it is freshly really installed pkg by pkg. And we suspect the package manager checks for integrity and authenticity of those packages against their origin, which by copying a live system you can never really know. Especially with forks of systems, the originals may have been altered and what you get may not be what came from the base distribution.
The installer works. It has an amazing amount of options and questions but are very clear as to what the answer should be. When it is done, it notifies of a successful installation, it reboots, ejects the CD (unmounts the USB or VM iso image) and boots. In terms of aesthetics, together with Artix, this is the best looking nicest working xfce setup I have seen. I do like dark themes, and this I like. For some reason, it probably relates with how the package manager works, the space needed to make an installation is nearly double or more than it really takes up when it is done. Most likely too many packages at once, are uncompressed, exploded, then copied. Unlike pacman and xbps that do pkg by pkg and direct uncompression and installation to chroot.
The sad part is that if you learn how to use the package manager, update with current slackware and upgrade all packages, you tend to download another 1GB worth of software, consolekit2 is removed, and elogind is installed. Nearly all software replacement is done due to this change. So your fine system turns into an IBM dummy terminal connected through dbus-elogind-…..-IBM-(and beyond!).
The real positive development that can probably be borrowed from Zenwalk’s setup is that instead of pulseaudio, if alsa is not enough for you, you can now use pipewire. See an article (the latest of news in Zenwalk’s pretty site).
Scratch, dump, forget.
Go to Slackel, I once remembered trying it (maybe 2 years ago) and I remember liking it back then but not enough to look away from Obarun. The summer 2020 image (072020 I believe and I don’t remember because I don’t want to go back and look – that bad!) which appeared to be last, is even more impressive than Zenwalk, basically because I’d rather have a WM than a desktop, and among all WMs I choose Openbox. Although their setup is more like a full desktop than a WM. Panels, menus, conky (windowed that somehow I couldn’t recreate as a non-windowed embeded module, as usual – something peculiar about the way conky is built and throws errors out or reappears as a window even when you turn the windowed option off).
You get a traditional live window manager with Slackel and software to make an equivalent to live installation, no network necessary. The installer gui though is a bit buggy, at least in a virtual environment. It doesn’t provide much documentation, help, or even hints, it has a left drop-down menu for copy live, and a right no-drop-no-down for net installation. The one on the left allows you to select partition to use, the right only allows sda1 (so nothing to drop nothing to come down, other than sda1). No matter what we tried /dev/sda1 was fixed. So we did this in a vm to be safe, and did provide an sda1 although we meant to use the copy live option. The relation of copy-live –> partition and net-install –> partition is speculative, not very clear, hence the insecurity that the wrong partition will be wiped out if we hit “install” and go. From videos on the net there seems to be little difference for years. The forum doesn’t automatically register users and we never got an email from admins, so after a week no way to ask a question. Oneirosopher on the other hand, who really liked both, and I don’t blame him, got in touch via-email, but not about this issue.
Slapt-get –update and slapt-get –dist-upgrade (debian influence in apt appearance and functionality but all similarities stop at the names of commands) is very nice. It is flexible and provides tons of options, unlike apk in alpine/adelie (possibly others). It is almost as good as pacman but it is nowhere as fast. It might be an illusion, I didn’t time it, but when a package is upgraded with slapt-get, every single file that is deleted and every file that is written to upgrade, is printed on the screen. Tons of unnecessary output could be the reason the package manager feels so slow. Consoles (and terminal emulators of consoles) have rates of how fast they can draw text on the screen and the defaults are at mid-80s mainframe terminal speeds. They can actually do several times faster than that but all you may get to see is gray cloudiness. If they could suppress all this output maybe they can stand together in the podium with pacman and xbps as a third.
Then there is another tool, slapt-src which updates, searches, downloads, builds, and installs software from source, placed in slackware compatible slackbuild format, in separate repositories. The repositories available through slackel don’t seem to provide any support for elogind, and even have a consolekit2 wrapper called nologind still available.
After the upgrade, not only xinit/startx needed elogind to start an X session, even some software that have never needed consolekit2 or elogind or systemd to run, would fail if you removed or shut-down elogind. Like pcmanfm.
Pcmanfm, in Obarun, (and I think Artix, Void, and others), comes straight from Arch (a systemd distribution). If it is current in arch and void, you know there hasn’t been an upstream release for a while. About 8 months as it seems. It runs in my obarun without elogind, without running consolekit2, or dbus. No errors or warnings produced. It is CLEAN! So why has Slackware made it DIRTY? So you can’t escape not using elogind no matter what you tried.
They didn’t just add elogind for functionality of gnome, and/or wayland for gnome and plasma, maybe sway as well is added in slackware, who knows, AND WHO CARES, they have added IT everywhere they possibly could.
Is it Slackel’s fault, is it Zenwalk’s fault? No, probably not, and the change seems to have come so abrupt there is little they can do right now. To revert to pre-December 7th repositories, mirror them and start rebuilding everything in slackware for their own repository, would take time if there was a will to do so. Meanwhile their users will continue to upgrade from Slackware, because that is what users do. So, if they have the setup they like, the previous functional pieces of software by slackel/zenwalk, why move to a different base. They may as well stay with Slackware and abandon the two forks.
For romantic sentimental historic preservation purposes, download the pre-Dec-7th-2020 images for both Slackel and Zenwalk, just to have as reference, what was there and what was lost.
References: (rest in peace-s)
A very sad development and realization. Unfortunately Slackware and forks have been listed in the really long list of unix-like systems without systemd. They are not going to be removed, just ignored and forgotten.
The real list of struggling and courageous distributions only has 4, possibly 5 with the possible addition of Oasis.
We may lose some fans and friends in this lonely less walked path we are following, but we believe the path less traveled is the path most worthy. The easy paved paths all lead to a trap. Same trap you tried to escape and begun walking in the first place. So go ahead, keep running circles around your masters.
PS To give slackware some credit in other respects, they have openrc, s6, and runit on their repositories. We installed runit in our slackel installation and removed sysvinit (although it is not necessary as long as you point a link of /sbin/init –> runit and move the halt/shutdown/reboot functionality from sysvinit’s to void’s. It booted fine, and the runit-services package it provided runscripts/service-files for anything you can possibly imagine. We suspect that s6 and OpenRC are equally well setup. But this has no effect in reverting the elogind dilemma. Out of disappointment and spite, we will erase the installations we did for both or three, salix as well, although it doesn’t differ significantly from a slackel installation, do it again from scratch but do not upgrade anything. Maybe add some packages from salix that are all pre-elogind. Then try all available init/service supervision systems, possibly add 66 on top of s6 too.