I’m sad it has consumed every distro I had used before it existed.
That’s all I’m going to say about it. It is a contentious bit of technology for many reasons. Lack of choice (and having it as a hard dependency) is a primary reason.
But it solved a lot of problems for people, and he deserves some respect for that.
I don’t think it’s productive to focus on the specific pid 1 process per se. If we did that, I’d note that SMF doesn’t even replace pid 1. We still have a relatively simple init process which hasn’t changed a great deal in decades, and is responsible for starting svc.startd and svc.configd that represent the bulk of SMF management mechanism.
It’s really a crude way of analysing complexity but it looks like it’s gone from 33,157 lines of text as the total project to 635,407 in src/ alone, which is a dramatic increase.
More than 50k lines of code each year, 1.5x the entire project as it existed added on top YoY.
That Poettering’s article was the primary reason I gave my best to have every company server using systemd. I can’t stress the number of times systemd saved my day in the last four years (mostly because that journal thing logged literally everything, including obscure errors from bizarre ruby scripts that everyone forgot about since ages). A very few systemd issues in 4 years were well worth than the usual monthly battles in the init-scripts jungle.
This said, I found every single anti-systemd rant based on either ignorance or “I already have a couple shellscripts doing everything well on my single-application server”. A server only exposing a PostgreSQL instance over a fixed-address ethernet may let you think systemd is useless.
Way before Lennart came up with systemd, I posted a number of criticisms about init scripts. Man, Lennart just did the right® thing™ I never had the time to develop.
I usually barely skim through articles related to systemd or Lennart because they’re mostly propaganda from either side of the systemd debate. I started reading this as “someone is taking a go at another init system”, and I was glad to not see systemd mentioned for once. I only realised what I was reading after telling myself a few times “That’s weird, he is taking the same assumptions as with systemd!!”.
My opinions about systemd remain unchanged, but I’m glad I read this article, which is a very good read !
at the bottom of every page, and if you click the large “Imprint” link on the left side of each page, it displays his name, postal address and email address.
I’m glad it exists.
I’m sad it has consumed every distro I had used before it existed.
That’s all I’m going to say about it. It is a contentious bit of technology for many reasons. Lack of choice (and having it as a hard dependency) is a primary reason.
But it solved a lot of problems for people, and he deserves some respect for that.
Interesting to see SMF called out as being too complex, given what systemd has turned into in the last ten years!
This is about PID 1. Has systemd’s PID 1 gotten that much more complex?
I don’t think it’s productive to focus on the specific pid 1 process per se. If we did that, I’d note that SMF doesn’t even replace pid 1. We still have a relatively simple init process which hasn’t changed a great deal in decades, and is responsible for starting
svc.startd
andsvc.configd
that represent the bulk of SMF management mechanism.Hard to tell because the systemd repo does not just contain pid1: https://github.com/systemd/systemd/tree/master/src
Here’s how the repo looked back when this blog post was written: https://github.com/systemd/systemd/tree/6c78be3c3c63b59f18311b2d2b0e8d745f6ba131
It’s really a crude way of analysing complexity but it looks like it’s gone from 33,157 lines of text as the total project to 635,407 in
src/
alone, which is a dramatic increase.More than 50k lines of code each year, 1.5x the entire project as it existed added on top YoY.
Here’s the shell output of my checking: https://git.drk.sc/-/snippets/79
That Poettering’s article was the primary reason I gave my best to have every company server using systemd. I can’t stress the number of times systemd saved my day in the last four years (mostly because that journal thing logged literally everything, including obscure errors from bizarre ruby scripts that everyone forgot about since ages). A very few systemd issues in 4 years were well worth than the usual monthly battles in the init-scripts jungle.
This said, I found every single anti-systemd rant based on either ignorance or “I already have a couple shellscripts doing everything well on my single-application server”. A server only exposing a PostgreSQL instance over a fixed-address ethernet may let you think systemd is useless.
Way before Lennart came up with systemd, I posted a number of criticisms about init scripts. Man, Lennart just did the right® thing™ I never had the time to develop.
[Comment removed by author]
That’s not a bad thing.
I usually barely skim through articles related to systemd or Lennart because they’re mostly propaganda from either side of the systemd debate. I started reading this as “someone is taking a go at another init system”, and I was glad to not see systemd mentioned for once. I only realised what I was reading after telling myself a few times “That’s weird, he is taking the same assumptions as with systemd!!”.
My opinions about systemd remain unchanged, but I’m glad I read this article, which is a very good read !
What was unclear about it? It says
at the bottom of every page, and if you click the large “Imprint” link on the left side of each page, it displays his name, postal address and email address.