Great talk indeed. And I will quickly acknowledge that something had to be done, and that systemd had the courage to innovate and address the issues. I just wish it did so in a more transparent way to the end user.
For instance: there’s a whole established system of dealing with logs in place. Why build a separate one just for your init system? Why binary? Why even integrate it with your init? I’m not saying storing everything on /var/log and using logrotate is ideal or even covers all use cases. But a log management system is its own thing.
That’s just an example of how systemd didn’t jive with every other subsystem in a Unix like OS. It could have been done in a Unix way - small cohesive tools that are good at one job and can be combined to do more together.
That’s where I think he missed the mark when dismissing the monolithic criticism by saying “it’s not a single binary so it’s not monolithic”. Its philosophy is monolithic.
That said, I use systemd on my machines because that’s what my do uses and I don’t think it’s a reason to swap distros. For the same reason I use Linux and not a micro kernel. I.e. philosophy is important, but implementation is importanter.
While monolithic may not be the keep is simple rule aimed for in originally in Unix/Linux, I wonder if it even matters…is there something really gained by init systems that make a difference for the average Linux user?
Wasn’t the systemd dude a Microsoft employee or something?
He wrote Pulseaudio, Avahi, and systemd before joining Microsoft, where he currently works.
So that’s the story. SystemD feels very Microsofty, though. A big, opinionated, monolith.
One task lifecycle management tool to bring them all, one tool to find them. One tool to rule them all and in the darkness bind them.
An excellent vid on Why systemD. https://www.youtube.com/watch?v=o_AIw9bGogo
Great talk indeed. And I will quickly acknowledge that something had to be done, and that systemd had the courage to innovate and address the issues. I just wish it did so in a more transparent way to the end user.
For instance: there’s a whole established system of dealing with logs in place. Why build a separate one just for your init system? Why binary? Why even integrate it with your init? I’m not saying storing everything on /var/log and using logrotate is ideal or even covers all use cases. But a log management system is its own thing.
That’s just an example of how systemd didn’t jive with every other subsystem in a Unix like OS. It could have been done in a Unix way - small cohesive tools that are good at one job and can be combined to do more together.
That’s where I think he missed the mark when dismissing the monolithic criticism by saying “it’s not a single binary so it’s not monolithic”. Its philosophy is monolithic.
That said, I use systemd on my machines because that’s what my do uses and I don’t think it’s a reason to swap distros. For the same reason I use Linux and not a micro kernel. I.e. philosophy is important, but implementation is importanter.
While monolithic may not be the keep is simple rule aimed for in originally in Unix/Linux, I wonder if it even matters…is there something really gained by init systems that make a difference for the average Linux user?