I just stopped using Slackware because of this thread ("because of" in the sense of "inspired by", I'm not blaming anybody ).

For over a decade I've used the exact same Slackware setup on my laptops. Dwm, Firefox and urxvt were my workhorse apps. It was simple and just worked. I had zero complaints.

Then, on reading this thread, I got to wondering exactly what could be improved. And you know, I realised that I'm a bit tired of upgrading my SBO packages. I use sbopkg and queues within config management (Ansible) to make things a bit easier. Still, say something big and low-level like QT5 receives an update and it's a real pain to go and rebuild all the other libraries and apps which depend on it.

The other annoyance is that I was rolling my own kernels. My preference was for slackware-stable, and when I got my current laptop the kernel in 14.2 at the time wasn't so great on it (Skylake and all that). So I've just been building the latest stable kernel from kernel.org and updating every month or so. It's not a big deal, but life is pretty busy at the moment and I just can't be bothered.

So I thought about what I was missing from my Slackware, and it was:

1. Good integration with config management.
2. Easy upgrades.

I already had most of my Slackware config outside of my home directory managed by Ansible (for stuff inside my home directory I just relied on backups, with critical config files also tracked in a git repo). But still, this was an imperfect solution. It was really hard to maintain actual system state. Note this problem is not confined to Slackware, but exists in most distros where you plug in external config management.

Config management in NixOS is a solved problem. It's not so much that config management is built into the OS; rather there's an OS built into the config management . There's one config file (/etc/nixos/configuration.nix) which tracks everything outside your home directory (this is slightly optional, but that's how I'm doing it). Combine the NixOS "channel" (AKA release, so there's the "unstable" rolling channel or periodic stable channels which only receive security/bugfix updates) with your configuration.nix and your system will be configured the same way every single time. Not only that, but on-the-fly changes and rollbacks are included as well. When you change your config for anything (including upgrades) in the system a new GRUB entry is added for the new configuration, but the old ones are preserved. This allows you to reboot back into previous configurations at any time. It's a turtles-all-the-way-down config system which gives you a totally deterministic system.

There's also the Nix package manager itself, which is pretty trippy, but that's a subject for another time. Suffice to say that to enforce determinism in the system every package you install has its own environment with strictly versioned dependencies. It's completely possible, and indeed normal, to have two different versions of a dependency installed simultaneously for two different apps.

Easy upgrades also play into this. To update to the latest shiny stuff in your chosen channel, just update the channel and run the rebuild command. Voila, new config, new GRUB entry, new packages. Also works for switching channels.

Anyway, that's my story and I'm sticking to it. I have to say, though, my next laptop is probably going to be a MacBook .


EDIT: I'm now using systemd and GNOME! The last time I used Gnome was ~15 years ago!

2 members found this post helpful.

I switched from Unix (server/workstations) and PC's with MS-Dos to Linux in 1994 and Slackware was about the only significant choice then. Have worked with other distro's since (at work), but at home it stayed Slackware all of the time.

3 members found this post helpful.

Not that I'm trying to persuade you to come back to Slackware (since it seems like you've found something that fits your requirements really well with NixOS... and Linux is all about choices ), but these two problems both have decent solutions by forum member 55020 (aka David Spencer).

For the first, with SBo updates, he developed slackrepo. This tracks all dependencies and will automatically rebuild all downline software when a dependency has been updated. It does still take the processing time to do so, so it could still be a long build, but there's no requirement to manually track which programs would need to be recompiled if qt5 is updated, since slackrepo does it on its own. If you need to make modifications to how a package is built, you do it using hintfiles, which are saved and used every time the package is rebuilt (lifesaver for things like ffmpeg that have a ton of options). You can set up a cron job where it will sync with SBo over the weekend and recompile everything (for me, I have mine set to about 2AM Saturday morning, as the weekly public update of SBo is typically done by then).

For the second, there's DUSK (aka Dave's Unofficial Slackbuilt Kernels). He automated building kernels, so that as soon as kernel.org has a new kernel pushed, his computer will start compiling that kernel and will spit out Slackware packages. You're free to use his kernel packages, or you can use his script and automate things on your own (allowing you custom configs with your kernels).

Right now, he's providing 4.4 kernels (for those using 14.2 and not wanting to upgrade to a newer kernel series) and 4.18 kernels (since Pat has been staying on top of 4.14 kernels for -current). Once 4.19 is out, I'm sure he'll add that, probably dropping 4.18 within a few releases.

9 members found this post helpful.

I remember trying out slackrepo a few years back but I didn't jive with it. I can't remember the exact details, but maybe the UI was just a bit unclear and awkward to use. Maybe it's changed since then.

I didn't know about DUSK, but that looks like a good solution for building kernels.

Thanks for the tips, they're worth keeping in mind for the future .

The only drawback to slackrepo is that you really should use a stock system to do the builds. I happen to have a spare machine that I can dedicate to do those builds, but you could use a VM to do the work.

3 members found this post helpful.

Even better, use a LXC container. However, I do not recommend running slackrepo in an unprivileged container, there are a few problems doing so. Stick with a privileged container and all works as expected. Just be sure to set ARCH in the slackrepo configuration if you have a x86_64 host and plan to build i586 packages.

2 members found this post helpful.

In my previous job I used Ubuntu because almost everybody did it too and I didn't know Slackware so well yet but 4 years of using Ubuntu at work and Slackware at home made me like Slackware even more than before. Ubuntu is too complicated, changes too often for no good reasons and what's perhaps the most important it does a lot of things behind my back. For example, I remember that apt-get install mutt also installed postfix although I have never asked for it, I only wanted mutt. By default .bashrc came with some aliases I didn't know and want. And one day system didn't boot due to some bug in init system. Horrible. Now I use Slackware both at work and at home and that's ok.

3 members found this post helpful.

When coming from something like sbopkg, it can seem like quite the complicated way to get packages onto your system (it took a lot of questions until I figured out how to get it to do everything I wanted). But once you get it figured out, it makes keeping things up-to-date extremely easy.

As Richard Cranium said, it is best used on a standalone machine or VM (or container as mralk3 stated) where the base is just a stock install of Slackware. By default, slackrepo will build everything in a chroot to prevent polluting the stock install and you can have it set up a slackpkg+/slapt-get supported repo to make keeping your main machine (or multiple machines) easily up-to-date.

What's the benefit behind using a container instead of a VM? I must admit that my knowledge of containers is pretty limited as I've never felt a need to explore them and find out what benefits they can offer me.

You have direct access to the hardware on your system. When compiling code this makes a big difference if you do not have a beastly build box to do so. Virtual machines require that you assign resources from the host machine to each installation- not required with containers. It is possible to limit container resources but I don't usually.

The main reason I like lxc is because with just a few commands I can rebuild a full installation of 14.2 without needing to go through the Slackware installer. I just point the "lxc-create" command to the mirror on my LAN, designate which lxc template I want to use, the architecture, etc. dnsmasq listens on the bridged NIC on my host machine and assigns IP addresses to containers as they boot up.

I do keep a Slackware virtual machine for testing purposes, but I use vms less and less. The only downside is lxc on Slackware has a bit of a steep learning curve if you have not used it before.

3 members found this post helpful.

I guess this is my problem. Any good guides that could help get me started?

Not needing to run a VM to do the stuff I do in a VM seems like quite the benefit and would probably be worth going through that steep learning curve. If I understand it right, not only would you be saving CPU and RAM from not needing to run a separate OS, but you wouldn't need to pre-allocate the disk space for the VM filesystem. This was the biggest issue I ran into when I first started using slackrepo (I didn't provide it enough space for everything and had to consistently delete the source downloads to make room for the packages).

Ponce has a great guide, although it was written for Slackware 14.0. The work he did for 14.0 has been incorporated into Slackware 14.2 already. So you do not need to download anything, just use the lxc-slackware template.
http://slackware.ponce.cc/blog/2012/...lackware-14-0/

Chris Willing has a great guide that talks about how to set up unprivileged containers. Due to how slackrepo builds packages it's best to use a privileged container to build packages (an example of what happens with slackrepo in unprivileged containers: https://lists.slackbuilds.org/piperm...er/022263.html). You can skip setting up the permissions for cgroups and just use the networking bit of his guide.
http://www.chriswilling.com/lxc/setu...slackware.html

The default in the lxc-slackware template is to create a Slackware-current installation following the architecture of the host. So if you have a x86_64 host it install Slackware64-current in the container. Here are some useful commands that should get you started. Be sure to use sudo or log in as root to run these commands, unless of course you have an unprived container.

Just replace $MIRROR with the local or remote slackware mirror of your choice. The default template for slackware builds a very minimal slackware installation. It will have networking and a shell. From there you can connect to the lxc console and use the installed system as normal.

I find lxc-console to work better.

This gist explains how to expose a directory on the host to the container, think file sharing. Great to share your own slackbuilds repository with slackrepo by copying your changes into /var/lib/slackrepo/SBo/slackbuilds.

https://gist.github.com/julianlam/07abef272136ea14a627

EDIT: I forgot to add... Make sure you have enough room on your host root partition. You can also configure lxc to use a directory on your home partition. I use root because it's easier to keep everything in /var/lib/lxc and I have sized my partitions to support this.

4 members found this post helpful.

That gives me a ton to go on... I might try and tackle this this weekend. Thanks!

For a slackrepo container, I assume I'd want to install all the packages I'd expect to have on the computer the resulting packages from slackrepo will be installed on, correct?

Yeah just do a "slackpkg install slackware64" or "slackpkg install slackware". lxc-create will take the contents of $MIRROR if you pass it as a variable to it and automatically add the contents to /etc/slackpkg/mirrors within the container.

1 members found this post helpful.

Me thinks this would be a great thread, could be updated for each Slack version, people can post their trials/tweaks etc....

I wrote this page on SlackDocs about LXC:

https://docs.slackware.com/howtos:misc:lxc

I'm sure there's lots that's not covered, but it includes everything I use. Feel free to add to it. I agree containers are much more convenient than VMs in general. I'm doing all my test builds for my SBo packages on them now, including testing on -current.

By the way, sboui is another option if you want something that will automatically tell you which packages [potentially] need rebuilding following an upgrade.

4 members found this post helpful.