[irl_]

I think you're missing a few things here:

* Services started with sysvinit would put logs where they want, which is fine if you know where they are but per-service you might be guessing. Having everything always in the same place is handy.

* sysvinit wasn't giving you any of these security benefits.

* If your system really was working fine before, why did you need to upgrade it to a newer distribution with systemd?

[turminal]

> * If your system really was working fine before, why did you need to upgrade it to a newer distribution with systemd?

Because the only two alternatives are 1) running mainstream distros from before 2014 or 2) running obscure distros that still don't use systemd.

[kzrdude]

yes, people forget that we are a village.

Contrary to “popular misconception”, Linux is not a settler's freehold where every holdout makes their own rules.

Admins have to work with a diversity of systems. They can choose how to setup new ones, but they have to work with a range of them. What everyone does has an effect on everyone else. If some distro introduces a new way of doing things, it has some chance of ending up affecting a lot of people - they might have to adapt to also support that way, or handle it in some way.

In that way we are a village, things are connected, and that’s why there is some degree of "social control" - looking across the neighbor’s fence and meddling with their way of solving the problem - it can in some sense become ours, if we are unlucky.

Fortunately, we can relentlessly copy good solutions from others in the village too.

[theranger]

So the admins should really not rant about systemd but complain about the distributions who switched to systemd or about their employers who force them to use such distributions.

[lanstin]

Or just buckle down and view a new chance to learn something as an enjoyable opportunity. Dammit people we aren’t paid for being experts but the ability to become expert-like in new areas.

[regularfry]

More than one thing can be bad.

[geofft]

That's the marketplace of ideas in action. Volunteer-run distributions like Debian and Arch have switched over. If the whole world where RHEL, you might have a point, but it's not.

You can contribute to your own distro, and the "veteran UNIX admins" made Devuan. If it still counts as obscure and you don't want it to be, you - yes, you - can do something about it.

The free/open-source community is a do-ocracy. The things that are worked on are the things the people doing the work want to work on. If you have a well-paid sysadmin job where you are providing your employer value by using the work they provide you for free - and, in particular, using their ongoing work which they continuously provide you for free, because you feel like a mainstream distro from 2014 doesn't suit your needs - then you can either be grateful for what you get for free or you can contribute back.

(Which doesn't necessarily have to be contributing your own work. I'm sure if you get your employer to donate one FTE's salary to Devuan, you can change its obscurity pretty quickly!)

[jbverschoor]

Or you could've actually improved init.d and add all the features to is, and make easy to use/create.

[iso1210]

I suspect many sysadmins, certainly the ones who complain about syslog, were quite happy with init.d

Traditionally developers would write code and packagers would package them into a distro specific rpm/deb -- including the init scripts (which may be pushed back upstream). Developers wanted to bypass this slow process, and there were far more developers than people willing to package the software.

Personally I've never had a problem writing an init.d script.

[lanstin]

All I ever could do was add a line to rc.local that started a supervisor process to run my stuff. But I have many service unit’s as part of user-data.sh or cloud init and they work and restart on failure and are visible to other admins I haven’t talked to etc. it was surprisingly easy.