Slackbuilds are really nice. Sbopkg lets you download queue files for each program, then automatically install necessary dependencies in the correct order, no matter if they’re available as packages or from source. Unfortunately, Slackware is so bare-bones out of the box that there are still pitfalls. For example, LibreOffice depends on avahi. And to successfully install that, you first need to create an avahi user and group, then install avahi, then write an init script that starts the avahi daemon and another one to stop it on shutdown.
-Current is much too active for my personal taste. I run Slackware because I’m a lazy Slacker.
The laziest approach to Slacking today is to install the default full install, then do:

wget https://github.com/sbopkg/sbopkg/releases/download/0.38.2/sbopkg-0.38.2-noarch-1_wsr.tgz    #Download the Slackbuilds helper Sbopkg  
slackpkg install sbopkg-0.38.2-noarch-1_wsr.tgz                                                  #Install it  
sbopkg -r                                                                                        #Sync its local repository to Slackbuilds   
sqg -a                                                                                           #Build queue files (dependency info) for the repository
sbopkg -i flatpak                                                                                #Install Flatpak and its dependencies  
flatpak remote-add --user flathub https://dl.flathub.org/repo/flathub.flatpakrepo                #Add the Flathub repo

The distros are very different. HM is just Ubuntu with a theme.
RB is, to my knowledge, the only distro built around Weston, Wayland’s reference compositor. It doesn’t include any Rebecca Black theming, it’s just called that cause the distro’s maintainer is a fan of hers.

Way back in the day we’d download Britney Spears and My Little Pony™ distros. Times change, I guess.

For Slackware itself, you install all available software up front. That way, all dependencies are resolved.
You then just hide the stuff you don’t need from your DE using its menu editor, or ignore it.
During an update, the package manager updates all installed packages, installs all packages that were added to the repo and removes all packages that are obsolete.

For additional software, there is a semi-official repo that’s very similar to Arch’s AUR.
And like the AUR, it offers several helper scripts and additional package managers that do dependency resolution.
Or you use Flatpaks.

Plan 9 is still actively developed in the form of 9front; updates and new features trickle down to 9legacy from there.

The “original” Plan 9—meaning stock 4th Edition—is more of a museum piece at this point, though, yes.

I use OpenBSD on my production machine and VPS, I use Alpine Linux on my phone. I’m also partial to Void Linux, though I don’t use it on any of my devices at the moment.

You can use nix alongside guix, it’ll just double-up the dependencies on disk:

services (append (list (service nix-service-type))
                    %base-services)))

Services are, in guix terms, any configuration change to a computer, so creating your own service 99% of the time is just extending etc-service-type and creating a variable interface to fill in the config file text yourself

Creating a service as in a daemon of some kind uses shepherd and involves extending shepherd-service-type or home-shepherd-service-type with your service description, depending on whether the service runs in root or user space.

Shepherd service configurations aren’t actually part of the guix spec(https://www.gnu.org/software/shepherd/manual/shepherd.html#Defining-Services), but still use Guile, so you can interoperate them super easily.

It’s important in guix to understand lisp pretty thoroughly, and knowing how to program lisp is still a very useful skill to have so I’d recommend learning it even if you never touch guix.

Please allow me to link to an earlier comment of mine that goes over this in more length. You may also find it copied-and-pasted down below:

First of all, apologies for delaying this answer.

Disclaimer:

• I’m not an expert. While I try to verify information and only accept it accordingly, I’m still human. Thus, some falsehoods may have slipped through, my memory may have failed me, and/or what’s found below could be based on outdated data.
• Additionally, I should note that I’m a huge nerd when it comes to ‘immutable’ distros. As a result, I’m very much biased towards secureblue, even if Kicksecure were to address all of their ‘issues’.
• Furthermore, for the sake of brevity, I’ve chosen to stick closely to the OOTB experience. At times, I may have diverged with Qubes OS, but Qubes OS is so far ahead of the others that it’s in a league of its own.
• Finally, it’s important to mention that -ultimately- these three systems are Linux’ finest when it comes to security. In a sense, they’re all winners, each with its use cases based on hardware specifications, threat models, and priorities. However, if forced to rank them, I would order them as:

Qubes OS >> secureblue >~ Kicksecure

Context: Answering this question puts me in a genuinely conflicted position 😅. I have immense respect for the Kicksecure project, its maintainers and/or developers. Their contributions have been invaluable, inspiring many others to pursue similar goals. Unsurprisingly, some of their work is also found in secureblue. So, to me, it feels unappreciative and/or ungrateful to criticize them beyond what I’ve already done. However, I will honor your request for the sake of providing a comprehensive and balanced perspective on the project’s current state and potential areas for improvement.

Considerations: It’s important to approach this critique with nuance. Kicksecure has been around for over a decade, and their initial decisions likely made the most sense when they started. However, the Linux ecosystem has changed dramatically over the last few years, causing some of their choices to age less gracefully. Unfortunately, like most similar projects, there’s insufficient manpower to retroactively redo some of their earlier work. Consequently, many current decisions might be made for pragmatic rather than idealistic reasons. Note that the criticisms raised below lean more towards the idealistic side. If resources allowed, I wouldn’t be surprised if the team would love to address these issues. Finally, it’s worth noting that the project has sound justifications for their decisions. It’s simply not all black and white.

With that out of the way, here’s my additional criticism along with comparisons to Qubes OS and secureblue:

• Late adoption of beneficial security technologies: Being tied to Debian, while sensible in 2012, now presents a major handicap. Kicksecure is often late to adopt new technologies beneficial for security, such as PipeWire and Wayland. While well-tested products are preferred for security-sensitive systems, PulseAudio and X11 have significant exploits that are absent from PipeWire and Wayland by design. In this case, preferring the known threat over the unproven one is questionable.
  • Qubes OS: Its superior security model makes direct comparisons difficult. However, FWIW, Qubes OS defaults for its VMs to Debian and Fedora. The latter of which is known to push new technologies and adopt them first.
  • secureblue: Based on Fedora Atomic, therefore it also receives these new technologies first.
• Lack of progress towards a stateless^[1] system: Stateless systems improve security by reducing the attack surface and making the system more predictable and easier to verify. They minimize persistent changes, impeding malware’s ability to maintain a foothold and simplifying system recovery after potential compromises. While this is still relatively unexplored territory, NixOS’s impermanence module is a prominent example.
  • Qubes OS: There’s a community-driven step-by-step guide for achieving this.
  • secureblue: Based on Fedora Atomic, which has prioritized combating state since its inception^[2]. Its immutable design inherently constrains state compared to traditional distros, with ongoing development promising further improvements.
• Deprecation of hardened_malloc: This security feature, found in GrapheneOS, was long championed by Kicksecure for Linux on desktop. However, they’ve recently chosen to deprecate it.
  • Qubes OS: Supports VMs with hardened_malloc enabled OOTB, for which Kicksecure used to be a great candidate.
  • secureblue: Continues to support hardened_malloc and has innovatively extended its use to flatpaks.

1. This paper provides a comprehensive (albeit slightly outdated) exposition on the matter. Note that it covers more than just this topic, so focus on the relevant parts.
2. Colin Walters, a key figure behind Fedora CoreOS and Fedora Atomic, has written an excellent blog post discussing ‘state’.

What are the main advantages of using this, that make it more secure?

More secure compared to your average distro? Or more secure compared to a specific set of distros? Unless, this is properly specified, this comment could become very unwieldy 😅.

Thanks in advance for specifying!

Whonix is an OS exclusively meant to be used within a VM; at least, until Whonix-Host is released. Therefore, I didn’t include it as it’s not actually competing within the same space; as it can be run on any of the aforementioned systems within a VM. Finally, it’s worth noting that by its own documentation, it’s desirable to do so with Qubes OS.

We sound like we have almost identical experiences. Except, while I do have some Debian kicking around, I just love Arch and the AUR. But I mostly use EndeavourOS ( Arch for people who don’t have time for this shit ).

It’s a Threadripper system which effectively behaves like two CPUs and loads of coree, two GPUs, one dedicated to my desk for the monitors, and the other one can be reassigned freely with VFIO to be a few different things. The TV is connected to that GPU. Storage is all ZFS.

• One VM is a kube node to run stuff on that GPU
• One VM is the media center / gaming stuff
• Technically I have a Windows and Mac VM too but I practically never use them.

When the second GPU isn’t attached to a VM, I can also use it on the host with DRI_PRIME. The host is also a kube node, so I can also run some (modest) AI stuff there too.

The rest is random glue scripts like detecting when the controller connects and shuffling VMs around on that signal. The kube stuff is brand new, half the things are just regular docker compose files still.

I’m looking into trying out kubevirt and see where that goes. The GUI is the only thing left that’s relatively normal on the host and I’d very much like to make that a container and split things up in sort of “activities” so the browser is its own thing, each project is its own thing so I don’t npm install a rat.