I surely become tired of becoming the product for someone else's overly inflated bottom line after having an option to feel it is "safe" to be a part of a community...
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.
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.
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
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'?
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.
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.
I think most projects where a person is trying to learn something such that it builds on something else are often not understood by a person who is not on the same path. In the end, the tapestry formed is only understood by the one doing the journey and then in hindsight it all makes perfect sense.
I'm actually cleaning up my GitHub repos at this very moment. So much basic stuff not really useful to anyone, things that other people clearly have done many times better. Old messy code, new messy code .... but to me they're experiences and represent invaluable learning that I've done.
I look at some repo that is a mess, but I remember making widget X work and how great that felt.
When someone says they created something I always think about what they must have learned to do that something, and not so much about the actual something.
I get a bit frustrated when folks critique something about "Yeah but this other thing" and so forth. For me that's almost never the point...
Kinda.. You can download the HTML file and host it on localhost, but it still relies on ipinfo.io. If you can figure out how to use e.g. the MaxMind GeoIP database in javascript, then it should be simple enough to hook up and run everything locally.
