3 ms·
I have to agree with this, I never got the major systemd hate. And I started using linux in 1994-95ish and still use it and different bsds. The only thing it
by tyfon 9y ago
I have to agree with this, I never got the major systemd hate.
And I started using linux in 1994-95ish and still use it and different bsds.
The only thing it doesn't do properly out of the box is logging. I'm not the biggest fan of non text log files.
- api 9y agoI haven't had a lot of stability problems with systemd, but I hate it. For me the hate comes from its extremely arcane interface and configuration layout. It's as bad as git in that you have to Google to learn how to do anything at all and the way to do simple things is obtuse and non-memorable, but unlike git I don't use it constantly so I never remember. Doing anything with systemd involves searching for how to do it since the command structure, layout, etc. is bizarre and counter-intuitive. There seem to be some Unix/Linux developers who have a mysterious affinity for obtuse arcane time-wasting cognitive-load-increasing design. It's like they see the ability to master crufty badly designed systems as a badge of honor or something, or maybe it comes from a drive for job security or consulting hours. Example: "systemctl list-units" What's wrong with "systemctl ls"? What would have been wrong with a shorter command that's easier to type like "sys ls"? It's a core aspect of the system so a name like "sys" would have been appropriate, easy to type, and easy to remember. Even worse the output of list-units has overly long lines and manages to be simultaneously hard for humans to read and hard for machines to parse. It uses white space as both a delimiter and within identifiers, making shell script parsing with "cut" etc. impossible. The entire design is like this: obtuse, verbose, clunky, hard to type, hard to remember. I absolutely loathe this stuff. Using it inspires fantasies of causing physical pain to its designers. A little bit of thought could have resulted in a clean, sparse, intuitive, and discoverable design with memorable commands and a straightforward configuration structure. Don't get me started on abominations like Debian packaging or Windows drivers, though those are somewhat forgivable as their ugliness can be explained by their age and the need for backward compatibility. Systemd was a green field design from the 21st century so it has no excuse.
- jjoonathan 9y ago"Clean, sparse, intuitive, and discoverable"? I have yet to meet a single non-broken production init script that merits a single one of those adjectives.
- api 9y agoThat's exactly my point. Systemd had a chance to replace the arcane cruft of sysvinit with something clean and well designed, but instead they developed something almost as arcane and unusable. It's pointless arcana to boot. There is no reason whatsoever that a green field implementation of something so straightforward needs to be so obtuse. If the complexity of interface exceeds the complexity of the information it needs to take and provide, it's bad design. If the command or UI structure uses arcane terms when straightforward terms exist, it's bad design.
- e12e 9y agoI've used plenty of init-scripts that are named after the daemon in question, support start/stop/reload/status and work fine. What more do you generally need?
- vidarh 9y agoThe "work fine" part tends to break down horribly the moment something unexpected happens. E.g. pid files being left lying around and breaking restarts.
- dmix 9y agoI have to agree on systemctl's naming scheme is terrible inefficient. This is something I use all the time when I'm on Archlinux and while I've come to memorize systemctl's interface for the most part it's still very poorly thought out, favouring verbosity over simplicity at every level. I've made enough aliases to make it useful and without having to type such a long name. It should definitely be a shorter name for such a critical piece of software. One example is using user services vs system services and the various non-intuitive locations and name schemes of the various .service files.
- pmoriarty 9y ago"What's wrong with "systemctl ls"? What would have been wrong with a shorter command that's easier to type like "sys ls"? It's a core aspect of the system so a name like "sys" would have been appropriate, easy to type, and easy to remember." "Even worse the output of list-units has overly long lines and manages to be simultaneously hard for humans to read and hard for machines to parse. It uses white space as both a delimiter and within identifiers, making shell script parsing with "cut" etc. impossible." It's the Microsoftization of Linux. This gives me bad flashbacks of Powershell where exactly what you describe is the case, where the simple is made difficult and the difficult made impossible. The overengineered, bloated monstrosity that was CORBA also springs to mind. Systemd has been one of the worst things that have happened to Linux in recent years.
- michaelmrose 9y agoI'm not a systemd fan, quite the opposite however I have often found package manager, service management clis less than friendly so I regularly write a little wrapper script just to provide a short cuts to my most used functions. The package management system regardless of distro is pkg the the service management is serv. This would also be helpful if you are using more than one system and needn't be complicated.
- vidarh 9y agoWhile I can agree about some of the commands, they're still far better than what they replaced for the most part, and easy enough to wrap with aliases or little helpers if you prefer. That said, the problem with "systemctl ls" would be that systemctl has commands to list multiple things things: units, socket, timers, dependencies, unit files, virtual machines, jobs. I agree it's annoying that the output isn't formatted in more parsing friendly ways, though. Especially because there e.g. is an option to format the journal output in systemctl status as json -- why couldn't they do that for the main output too (indeed, I wish all tools had an option for that)