[jbschirtzinger]

While this article makes a case for the new command, the reality is simple. I personally learned ifconfig continually in my life and so I learned how to read it and interpret what it was trying to say. It output its commands in a fairly easy to parse way. The new command, while I am sure is progressive and forward thinking, feels clunky. I often have to try to remember the name of the command itself as it is not obvious. It is a good example of a command not really doing the function of making the job easier on the network admin in favor of accommodating new conceptions of features. All the thousands of hours I spent on ifconfig are, basically, useless unless I want to be antiquated and have useless debates about standards. Basically, I just want the computer to do what I tell it with as little extra trouble as possible.

[djsumdog]

I feel like systemctl and journalctl are the same way. They are terrible commands with awful usability. Having a full process control system is nice and helpful when writing a package once for several platforms, but I wish something had caught on that had better usability and didn't try to do everything from login management to filesystem mounting, but rather just process management.

Where as someone could probably write a newer drop in ifconfig that uses modern kernel APIs, several people have tried to for systemd and it's just so massive no fork can keep up anymore and almost all have been abandoned.

[kashyapc]

Are they really "terrible" with "awful usability"? In my day-to-day debugging, I do find `journalctl` much better. Let's see a couple of quick examples:

- Show logs for the current boot: $ journalctl -b

- To get all errors that are of priority level ERROR and worse: $ journalctl -b -p err

- Show me logs for a given binary: $ journalctl /usr/sbin/libvirtd

- Or via its unit file: $ journalctl -u libvirtd -l

- Want to query all the errors for a given disk? Here we go: $ journalctl /dev/sda -p err

And so on...

[nailer]

I quite like journalctl, but the naming could be better. 'system' means OS, and kernel, and init system, and computer, and many other things. 'start-service' would have been better.

The worst is 'system-cat' to send a log message (SysVInit used 'logger'). Why not just 'log'?

[yarrel]

Yes that is an awful soup of switches that should either be separate commands or usages of existing Unix tools.

[craftyguy]

Ok, then you've traded one command with switches for multiple commands each with their own set of switches (and almost certainly following different switch 'standards'). I like systemctl/journalctl for cleaning up that mess, even if it requires me to learn how to use them.

[kashyapc]

Then you will have an awful salad of separate commands that you have to juggle around. I am all for "UNIX philosophy" within reason; it has its bounds, let us not over-romanticize it.

[kevin_b_er]

systemd has decided for you that these commands are better. It is now your responsibility to accept their decisions.

[hackmiester]

I have embraced systemctl, and it's intuitive to me, but I feel the way you do about journalctl.

If I want to tail the log of a service, though, there's a mnemonic for that: 'journalctl -fu httpd' - that one sure is easy to remember!