julien tayon commented on a post on Blogger.
Basically one of systemd biggest problem is to solve like pip, puppet, and apt-get the same problem: the dependency resolution hell in an asynchronuous fashion. So it is a FSM consituted of small system interacting with one another all having their state machine interacting with one another ; we are basically hoping to achieve with no pain a stable system with a chaotic system.

Good news of what we know about complex system is that they can have property of robustess if all your subsystem state machine maximize their entropy of rules (worked on this problem with cellular automata). So a weirdly robuster stable system is achievable (that is the good paradoxal news).

Bad news, is out of this domain, the system is chaotic. And when it fails, it fails in an unpredictable way with a snowball effect.

I explicitly am for the use of complex system.

I just wouldn't want a choatic system to boot the operating system of a robot needed for medical or critical systems this way.  Or an airplane, or a backbone router ...

I would prefer a system to always be able by default in a way not that is robustly converging to the equlibrum most of the time, I would like a critical OS to boot deterministically every time the configuration is the same.

I want a causal system that is easy to debug.

I want linux to be used in these cases because I want linux to be used for critical systems either because it is a funkier job or because it is safer than closed source system.

The more people will rely on systemd the more entanglement in terms of coupling of the state machines, the less stable linux shall be. Systemd is the road to a future hell paved with so much lazyness (let's state it 90% of our softwares should be fixed, mine included) and un-preparation (let's work in a non deterministic fashion and wait for trouble to discover it is totally un-debugable).

I am glad to have learnt BSD basics.
Shared publiclyView activity