How does Slackware compare to ArchLinux? They both seem to be very barebones and force you to learn more about Linux, but ArchLinux seems much more popular from what I gather.
I find sbopkg and SlackBuilds.org to be better than yaourt and AUR. sbopkg's UI is just top notch (ncurses-based).
Slackware uses sysvinit with flat rc scripts as opposed to the traditional System V setup of numbered symlink farms. Much cleaner. Arch uses systemd.
Slackware's pkgtools are much more minimalistic than pacman. They're shell functions that manage local tarballs. In addition, you have slackpkg for fetching remote updates.
Slackware actually double-functions as both a rolling and stable release distribution. You can either set slackpkg to track -current, which is often bleeding edge yet surprisingly robust, or stick to official versions like 14.1.
Slackware's installer and setup utilities are all ncurses-driven rather than pure CLI as in Arch. I actually find them much more capable. The only pure CLI part of installing Slackware is disk partitioning, the rest is a highly detailed TUI menu installer (similar to FreeBSD if you've tried that).
Slackware has a very strict devotion to not patching upstream packages at all, with exceptions only in the most critical circumstances. This means that you're pretty much always using vanilla Linux userland as it is, and so if there's bugs, you report to upstream rather than to the distribution tracker. If you're a developer, this is great.
Slackware's package management can alternate between binary and source-based.
As such, I'd recommend Slack. It's venerable and rock solid.
systemd has extensive documentation, both in manpages and in higher-level documents explaining how all the pieces fit together. I've generally found it far more straightforward to learn about than the components it replaces.
> One of the most egregious problems was forcing the change from text logs to journalctl binary logs.
You can keep a syslog implementation like rsyslog installed, and you'll continue to have text logs too. And journalctl outputs plain text.
people seem to have this analogue of "you can configure away the bad bits" but in the end the bad bits are orthogonal to it's design and 'bypassing' them or hacking around them should not be encouraged- it should be able to be done by default.
Where in my comment did I imply that the journal was "bad"? The journal is awesome. But if you have some workflow designed around syslog, such as a log analyzer or statistics package that you don't want to tweak, text logging still works just fine.
...and the manpages for every tool, every config file, built-in units, and every type of unit, plus the extensive documents linked from https://wiki.freedesktop.org/www/Software/systemd/ , including a 21-part series of articles targeted at system administrators, a dozen more pages targeted at users and administrators about specific topics, several dozen documents for developers, a dozen videos...
There are many criticisms you could reasonably throw at systemd, but "not well documented" certainly doesn't seem like one of them.
On boot, systems waits for two minutes or so for dhcp on an Ethernet interface with no cable, and it's not cancelable if I happen to be at the console
On shutdown, it turns off swap before shutting down daemons; not an issue for my system because I don't expect swapping, but in what world does this make sense?
Closing the lid sleeps the computer without configuration; some people might find this to be a good thing, but in my experience in the last 15 years, Linux only slept on lid closure if i was running software to handle that (acpid and/or something from a desktop environment), if i have apache running on an old laptop with no GUI, i expect it to stay on. (yes, there's a config, but its still annoying)
With sysvinit you'd usually just put it on S99 and be done with it in most cases.
Debian has documentation of similar quality, with the Debian Reference[2] and the Debian Administrator's Handbook[3], which is more up-to-date. Also in DocBook, and all I said about the Fedora documentation applies as well.
This will not be a popular opinion, but I don't think Arch Linux's documentation compares to Debian's and Fedora's.
[1]: https://docs.fedoraproject.org/en-US/Fedora/23/html/System_A... [2]: https://www.debian.org/doc/manuals/debian-reference/ [3]: https://www.debian.org/doc/manuals/debian-handbook/
BUT Arch brokes often. Even when I look the news on the official website or search the forums for issues with recent updates, even when I check that everything is ok accordin to the (awesome, really awesome) docs, Arch brokes something.
I grew reluctant to run "pacman -Syu". Now with Slackware I am 100% sure that my system will always work after every update, and if it doesn't work is because a simple new dependency that I can install in a couple of minutes if I want, or I simply keep the already installed package without any issues whatsoever.