Problem is, nobody’s alternative solves all of the problems people wanted their init system to solve. sysvinit didn’t solve booting/service supervision well, so it’s hard to say it was really a UNIX philosophy solution, and it wasn’t even part of the OG Unix system but came over a decade later in 1981 with AT&T’s system iii (later included in system v, hence the name sysvinit). There’s nothing sysvinit does well. The most popular services and distributions had simply thrown away so many hours of time and effort bashing their heads against sysvinit’s limitations that they had managed to make them work, but that’s different from the system overall working well.
Anyways, people don’t like Poettering, but he made inroads with systemd in large part because he actively took notes on what people wanted, and then delivered. He’s an unlikable prick, but he delivered a product it was hard for many projects to say no to. That’s why project after project adopted it. It solved problems that needed solving. This counts for more than adherence to an archaic design philosophy from the 70’s most people don’t follow anyways and which the predecessor wasn’t even a good exemplar of anyways.
Problem is, nobody’s alternative solves all of the problems people wanted their init system to solve. sysvinit didn’t solve booting/service supervision well, so it’s hard to say it was really a UNIX philosophy solution, and it wasn’t even part of the OG Unix system but came over a decade later in 1981 with AT&T’s system iii (later included in system v, hence the name sysvinit). There’s nothing sysvinit does well. The most popular services and distributions had simply thrown away so many hours of time and effort bashing their heads against sysvinit’s limitations that they had managed to make them work, but that’s different from the system overall working well.
Anyways, people don’t like Poettering, but he made inroads with systemd in large part because he actively took notes on what people wanted, and then delivered. He’s an unlikable prick, but he delivered a product it was hard for many projects to say no to. That’s why project after project adopted it. It solved problems that needed solving. This counts for more than adherence to an archaic design philosophy from the 70’s most people don’t follow anyways and which the predecessor wasn’t even a good exemplar of anyways.
Following an ideal while being based on free labor is difficult
Yeah, and as “ideals” go, an OS design philosophy is a bad hill to die on. Just take the process supervision and go.