Stop breaking Linux's usefulness as a server OS in a misguided attempt to make it a desktop OS. (see: systemd, networkmanager, etc)
I've never heard of any problems it solves other than things described in abstract terms that might make sense to a developer but that makes no sense to Operations/DevOps teams.
Nobody likes learning something new for zero benefit. I keep trying, though. But the more I am forced to learn about it, the more arcane it gets. It's not a learning curve, as far as I can tell. It's a learning wall with no payoff. It makes everything we do more difficult, the commands make no sense, and it brings no tangible benefit. It's change for change's sake. It reminds me of DJB's insistence on making logs in hex "just because".
Just a simple example. Why is it "systemctl list-unit-files"? What the hell are unit files? How is this in any way logical? Why is this an argument and not a flag? Why is it that I can use a systemctl command, and it tells me to use the -l flag to view non-ellipsized output, but then when I use the flag, it gives me an arcane error that tells me nothing about what happened? It's the tip of the iceberg in an endless string of junk that simply doesn't make any sense or work properly.
So, I like to vote against it whenever I can, because supporters like to keep insisting that it's the way of the future, and implying anyone who hates it is a luddite.
I suggest you read systemd.unit(5), which begins as follows:
"A unit configuration file encodes information about a service, a socket, a device, a mount point, an automount point, a swap file or partition, a start-up target, a watched file system path, a timer controlled and supervised by systemd(1), a temporary system state snapshot, a resource management slice or a group of externally created processes."
> Why is this an argument and not a flag?
Multi-use programs with a good CLI accept the argument(s) determining what they do positionally rather than as flags. Flags should be used for options that somehow modify the behaviour of the command.
> Why is it that I can use a systemctl command, and it tells me to use the -l flag to view non-ellipsized output, but then when I use the flag, it gives me an arcane error that tells me nothing about what happened?
I don't know what you mean. For me, 'systemctl list-units -l' works fine.
You claim unit files are confusing. Let's say we took a Windows programmer who was a sophomore in CS but didn't have any Unix or Linux experience, show him both systems. Explain how runlevels are handled in systemd vs sysvinit. Show him a systemd unit file vs the equivalent bash script. Explain how systemd tracks the process tree vs sysvinit pid file hack. You spent five minutes trying to figure out systemctl and declared it terrible. It probably took you more than 5 minutes to find /etc/init.d your first time
To most of us, it's change for change's sake, which makes life worse due to the learning curve. If it made life easier for the average end user or the average sysadmin, it would have more defenders.
Personally I loathe network manager in RHEL7 but that's not a systemd problem.
sysvinit maintainers must love systemd. Before systemd came along there were lots of complaints about what a terrible hack sysvinit is. Now it's a paragon of simplicity and stability without having actually changed any..
If I had a dollar for every time a systemd supporter reminded us that we need systemd because runsv was a terrible hack, on the other hand...
The solution? Put a sleep 7 in there, thus making the entire process slower than the previous solution.
EDIT: RHEL/CentOS only supports NetworkManager for this. Which sucks if you don't want to run NetworkManager (for a litany of reasons).
$ yum whatprovides "*/systemd-networkd-wait-online.service" No matches found
It wasn't really any better than upstart either, which is why I was mad about seeing ubuntu rip it out in order to replace it with systemd.
The main thing that concerns me most is that systemd is now dominant on virtually every linux platform and without competition it is going to stagnate.
Upstart wasn't perfect but it was decent and it was competition, it worked well for ubuntu and it would have been a better choice for debian (unfortunately the vote was split 50/50 and the tiebreaker guy decided on systemd).
Except he didn't. Another good example of the straw man arguments I was talking about. Hating systemd doesn't automatically make you a sysvinit fan.
>Upstart had a lot of problems
The fact that you didn't mention one of them demonstrates just how much you know about this (nothing).
Ok, snarky, yes. Still want to know the answer :)
Also, why is it that the ONLY alternative ever mentioned is sysvinit? Systemd is not the 2nd init system ever invented, nor even the 4th or 5th. There are simpler alternatives.
Binary log files? Don't even get me started.
The basic concepts journald is built on is lifted straight out of a doctorate thesis written by Lennart Poettering's brother.
Thinking about i don't think systemd really have a goal. It seems to be a hodgepodge of Poettering itch scratching, Gnome/Fedora/Freedesktop NIH-ing, and a bunch of "because we can" sub-projects.
Their threat sounds almost Microsoft. I have run into various claims where companies were worried they had to bend to MS wishes, or MS would start shipping a clone product.
THIS. It was both amusing and sad to watch this happen time and time again. My favorite is what happened (or, rather, didn't happen) around CoW filesystems and how they decided to just use a FUSE-based one instead.