>Not everyone likes writing shell scripts to start services

Sure, but that isn't a good reason to remove the option to do so for everyone else.

I've been using Linux for 20+ years but the apparent shift from "stable and reliable" to "new and shiny" concerns me. The feeling of being an involuntary beta tester is not a good one.

> that isn't a good reason to remove the option to do so for everyone else

It really is. Accepting the status quo and abandoning progress is how software systems become stagnant and die. X is a bloated protocol, designed for a different age of computers. Sys V is an archaic system that makes the task of having a standard daemon run in a standard way surprisingly difficult (and also prevents parallelising startup). I'm not saying the replacements are perfect, but at least we're trying.

Maintaining perfect backwards compatibility would have an effect on progress somewhere between 'making it harder' and 'making it impossible'. Not that backwards compatibility should be completely abandoned. See XWayland, and also the fact that SystemD does still execute init.d shell scripts.

> and abandoning progress

Change is not, itself alone, progress.

Progress can be a lack of change, if that change was regression in functionality, q.v. the large and growing number of shitty interfaces.

And by interface I mean everything from boeing's mistake right down to the controls on a fan heater of mine.

I guess I need to explain the latter. I've had a period of joint pain in my hands due to a developing food intolerance (now under control). The fan heater control was a dial, partly flanged for grip. But just a fucking little flange, so as not to stick out too much. Trying to operate that with your digits hurting was a bitch. It would have been literally unusable for someone with strength loss from advanced age and some decent arthritis on top.

Interfaces are a very broad category in my view, and we have far too many bad ones. Anyway, sorry for the rant, but don't confuse change with better.

> designed for a different age of computers

i want to say this as kindly as possible, but every time i have heard statements to this effect (think "paradigm shift", "new age", etc.), the presumably "better" technology (which more often than not just means newer) is always oversold.

i would reconsider your line of argument, because as someone who has heard this several times throughout my career, this is almost certainly a bellwether of disappointment.

But computers were different in the 80s when X was designed (to talk about one example). We don't use networked terminals to a mainframe, the graphics stack (hardware and software) works completely differently now, user expectation on compositon and visual fidelity has increased, and the security threat model has changed (in that it exists now and never used to).

There has been no one paradigm shift, merely 40 years of incremental advance leading to a different landscape with different requirements.

> We don't use networked terminals to a mainframe

The mainframe is now a rack of servers, still separated from the framebuffer by a long network connection. The decline of X has us so desperate that we're abusing web browsers as remote displays.

> The decline of X has us so desperate that we're abusing web browsers as remote displays.

There's a fundamental difference between a X11 remote display, and an application running within a web browser. This difference becomes obvious when the network connection drops: the X11 application will immediately freeze, since all of its code was running in the remote computer, while the application within the web browser can retain some of its functionality.

Is it the decline of X11, or the fact that HTML+JS+CSS has proven to be a better model for building UI applications than X11 has?

Abusing? Web browsers are much better remote displays than X-Windows servers, by a long shot.

Do you want that rack of servers to keylog you? That's what it would be able to do with an X11 connection.

Every new piece of software is not progress, very little of it is actually innovative, none is better in every way and not that much of it is even usable. Having options at least accepts that, respects people's time and allows people to avoid suffering through it until it eventually dies anyway.

Speaking of stagnation, reinventing anything "not invented here" is also stagnation, not progress.

Yes, but please let’s not sneak into the conversation the idea that SystemD is anything but a trainwreck

Most distro maintainers disagree apparently, I wonder why.

Distro maintainers fall into the following categories (with the accompanying fictitious percentages):

* 50% - maintainers who don't care about systemd

* 35% - maintainers who do care, but who feel powerless to stop the Domino Effect (and don't want to echo the familiar criticisms of it, or be associated with the "haters")

* 10% - maintainers who actually like systemd, because it is optimised for their use cases (at the expense of others)

* 5% - maintainers who can't stand systemd, and leave their distro/OS over it

The option is still there, you can write an unit file which runs your_awesome_script.sh.

> Sure, but that isn't a good reason to remove the option to do so for everyone else.

It didn't. You can still write your init scripts.

I'm not a fan of the monolith here, I dislike the whole concept of binary logs, of tight coupling with udev and journald, but seriously - once you get into how the various systemd service and target files hang together it's a (comparative) delight. And they can still trigger your scripts.

I haven’t written an init script in ten years.

It is like coming home one day, and the house has been demolished. There’s a joker in a bulldozer proudly proclaiming there was some dog crap on the sidewalk, and that he took care of it for me.

Solid analogy. In the case of Systemd, it was fixing problems for me that I never had, and creating problems that I'd also never had: It broke laptop sleep. It broke /etc/rc.local. It broke domainless local DNS lookups. It broke boot on one of my servers (fstab's new nofail argument? really?) And it (soft) broke a keyboard of mine. A keyboard! Astonishing.

I really wish Debian had not drunk that particular kool-aid. :'(

I'd go somewhere else but Debian (and by extension Ubuntu) have been doing binary package management the longest, and for me it really shows. I want these boxes to just sit there for years, be extremely low maintenance and only pick up security updates, and I've never gotten a better experience anywhere else.

I've had a similarly good low-maintenance and dependable upgrade experience with CentOS

CentOS ain't gonna get me away from systemd, though.

> I haven’t written an init script in ten years.

Me neither, but that's because of systemd. How do you make your own SysV service without making an init script?

Not everyone wants to talk dbus to configure the firewall :P

I just put iptables shit into /etc/rc.local and it works, no dbus needed :)

this was just a stupid comment on firewalld