I semi-respectfully disagree that I've given you undue attitude.
One of the things I really enjoyed about the Flix programming language submission today was running across their principles section. Right off the top of the list:
> Simple is not easy
> We believe in Rich Hickey's creed: simple is not easy. We prefer a language that gets things right to one that makes things easy. Such a language might take longer to learn in the short run, but its simplicity pays off in the long run.
In my view, yes, there are warts to systemd, but it is an operable understandable system which has a hard fought simplicity to it. I can go to any systemd computer and get a good idea of what's running, understand how it's wired. I use common practices and configs to change or drop in config.
My feeling is that a lot of people want easy. That systemd doesn't pass the easy test.
The past? The past was enormously complicated. It was complicated because every shop has its own way of configuring things. Every shop has their own tools to assess system state, their own way to configure subsystems like logins, dns, networking, logging, time sync, booting. There were countless countless easy answers, a path littered with the bodies of dead easy answers to this or that concern. And you needed an easy answer for each concern; easy didn't go hard to integrate the different factors.
That past was a horrible mess of easy. Systemd feels complex, but compared to the past, there is a persistent understandable simplicity that is a raw joy to use. Things make sense. When you see one thing, you sort of learn how the next works. The back to the woods rejectionism that springs up today is a bizarre weird thing; folks have not seen how wildly different and bedazzling system management used to be, within and across orgs. You might not appreciate why but there's very very good reasons, and I'm fact, the world is inherently complex, there's aot to do, and systemd has created a wonderful pervasive cross-sectional (via it's many opt-in components) "easy" that harnesses and enables the complexity that is, in a sensible glorious way. ("This has made a lot of people very angry and been widely regarded as a bad move.")
Systemd is anything but simple. And the past definitely wasn't easy. You seem to have the terms backward. For the end user, yes, it's a polished experience that you mostly don't have to mess with, and the parts of it you're most likely to interact with are, well, fine. Not great, but fine.
> operable understandable system
Every system is understandable, it's just a question of how much work you have to put into understanding it. Good design reduces the amount of this effort needed. Many many systemd components simply aren't well-designed. But they all interop with each other so there's no way to slowly wean a system off of systemd. Trust me I tried.
I don't want to understand systemd. It feels like being at work. Good on you for putting in the effort. I should be able to use software I like and want to use. Maybe even hand-write some replacements, like I'm doing with my shell. Systemd doesn't get in my way there, thankfully, it's been awhile so I don't have specifics off the top of my head for the last time I tried removing a few systemd components only to find hard dependencies on each other.
This is not how Linux needs to be. I agree the old ways sucked. I don't want to go back to them either. But neither do I want to be locked into the big ugly mess that systemd turned into. I want clean, modern, well-designed components that are independent of each other.
One of the things I really enjoyed about the Flix programming language submission today was running across their principles section. Right off the top of the list:
> Simple is not easy
> We believe in Rich Hickey's creed: simple is not easy. We prefer a language that gets things right to one that makes things easy. Such a language might take longer to learn in the short run, but its simplicity pays off in the long run.
In my view, yes, there are warts to systemd, but it is an operable understandable system which has a hard fought simplicity to it. I can go to any systemd computer and get a good idea of what's running, understand how it's wired. I use common practices and configs to change or drop in config.
My feeling is that a lot of people want easy. That systemd doesn't pass the easy test.
The past? The past was enormously complicated. It was complicated because every shop has its own way of configuring things. Every shop has their own tools to assess system state, their own way to configure subsystems like logins, dns, networking, logging, time sync, booting. There were countless countless easy answers, a path littered with the bodies of dead easy answers to this or that concern. And you needed an easy answer for each concern; easy didn't go hard to integrate the different factors.
That past was a horrible mess of easy. Systemd feels complex, but compared to the past, there is a persistent understandable simplicity that is a raw joy to use. Things make sense. When you see one thing, you sort of learn how the next works. The back to the woods rejectionism that springs up today is a bizarre weird thing; folks have not seen how wildly different and bedazzling system management used to be, within and across orgs. You might not appreciate why but there's very very good reasons, and I'm fact, the world is inherently complex, there's aot to do, and systemd has created a wonderful pervasive cross-sectional (via it's many opt-in components) "easy" that harnesses and enables the complexity that is, in a sensible glorious way. ("This has made a lot of people very angry and been widely regarded as a bad move.")