> This regressive change in behaviour (taking away pertinent information for no obvious benefit) There is a benefit. The benefit is that it's logged, always,

> This regressive change in behaviour (taking away pertinent information for no obvious benefit) There is a benefit. The benefit is that it's logged, always, and through a mechanism that is the same for every process. It's a trade off. We can argue whether it's a worthwhile trade off, or one that even really needs to exist (is there a reason they don't immediately show an error? I don't know), but to say there is no obvious benefit even after I pointed out this specific benefit in my prior comment is odd. > People get turned off before they even begin to understand what systemd is trying to do, not because of core reasons, but because of one of the first interactions the average person has with systemd is to make their life harder. Any change from what existed previously that requires a different way of doing something, whether ultimately better or worse, makes the user's life harder in the short run since they need to learn something new. That's not to say that's all that's happening here. There appears to be a regression in usability in at least one aspect. That said, I sort of understand why they didn't make it output that info. There have been plenty of times in the past for where sysV has reported a service started, but it actually failed very shortly after start. Generally, figuring out why can be painful, because STDOUT/STDERR have been redirected (or likely sent to /dev/null). Keeping a log of the stdout so you can see what happened on that last service action (and not hope it was logged to a log file, which it sometimes isn't...) is very useful. Outputting that the service started successfully is nice. Outputting that it started successfully when it didn't is misleading and more of a problem. Again, that's a trade-off, where it appears they've decided to favor accuracy over convenience in this case.