Hacker News Reader

Comment by komaromy | Hacker News Reader

The Arch docs are superior (best that I've encountered in the Linux world) but Slackware is worth it to me to stay away from systemd.

View on HN

I disagree. For every Fedora release, the Documentation Project prepares a new version of the System Administrator's Guide[1] and of five other high-quality manuals. These manuals are usually up-to-date, accurate and comprehensive, and since they are maintained in the DocBook format (which is very superior to wikimarkup for technical documents), they can be converted into HTML (for the version on docs.fedoraproject.org), PDF (for printing or viewing in a PDF reader) and EPUB (so I can put the guides on a e-reader and read them comfortably). The documentation is even translated in multiple languages.

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/

Out of curiosity, why don't you like systemd?

It felt too restrictive to me. Things were changing without me asking for them and that was preventing me from learning. One of the most egregious problems was forcing the change from text logs to journalctl binary logs.

> Things were changing without me asking for them and that was preventing me from learning.

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.

You can also make rsyslog work on windows, doesn't mean it's supported or encouraged..

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.

> people seem to have this analogue of "you can configure away the bad bits"

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.

"bad" is just a metaphor in this context

systemd only has extensive documentation if you count the source code itself. otherwise, most people are left guessing for things above a "systemctl restart"

> systemd only has extensive documentation if you count the source code itself

...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.

I recently put together a systemd system, here's a list of grievances compared to the previous setup:

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)

it's like the face-hugger, from Alien(s). Once it gets into your distro, it impregnates it with a horror monster. An init should not be micromanaging every aspect of my system. I'm on arch now, but my next Linux will not have systemd or journald.

Let's say we have a service, that needs network to be up and running. network.target won't work on boot, you start googling and find network-online.target that should do the trick, but it doesn't. Then you spend half an hour trying to figure out how to make it wait for dhcp config to finish for /etc/network/interfaces. In the end, either find that you need to enable some obscure service that waits for it and makes network-online.target actually work and enable it or you copy-paste it from somewhere on the internet and it is a shell script anyway. I'm not sure how you can you depend on network-online.target and be sure this network waiting services are properly enabled.

With sysvinit you'd usually just put it on S99 and be done with it in most cases.

Reply on news.ycombinator.com