When looked at the right way, init systems like systemd, launchd, etc are build systems; instead of building a piece of software, they build a working environment. This is more than just a vague metaphor: most reasonable init systems will have a way of expressing dependencies, expected outputs, etc.

What *is* legitimately different is that init systems keep running after the artifact is built, and have rules that dynamically fire; EG: a rule that fires when network configurations change, a rule that fires every hour, etc. In a sense, this means that init systems are build systems that are always in watch mode, and support dynamic rules.

It would be interesting to transfer these rules across our analogy, and experiment with a build-style system that supports dynamic watch rules. Most fancy build systems already support an ad-hoc form of this via hot-reloading, but a principled version seems very useful!

@totbwf FRB (functional reactive building)
@totbwf or package manager. Thise are also build systems.

@totbwf

I vaguely recall reading about a Linux distro (or hack thereon) that used `make` to launch services and dependencies. The reasoning (IIRC) was to start up faster by only launching the services you need and doing so in parallel.

@suetanvil that might have been Debian's sysvinit mod, I'm not sure if they used startpar in "make-like" mode or if it was literally a makefile.

the reasoning sounds closer to systemd's though, as parallel sysvinit didn't change /what/ was being launched, whereas systemd integrated like five different kinds of on-demand activation into the init system, so that many services no longer had to be started upfront (e.g. it kind of re-popularized inetd style services)

@suetanvil that's basically the reasoning behind every modern init system as well, but i figure make brought this idea into unix nerds' minds first
@totbwf Sounds like something that would be right up the alley of an Erlang or Lisp.
@totbwf cmake as init system
@totbwf oh gods, nooooo.... that seems deeply cursed...
@freya the NX bit is for cowards
@totbwf
few projects in the Rust ecosystem have emerged, primarily as simpler init processes for container environments or as proofs of concept
catatonit and sinit
@totbwf ooh i really like this
@totbwf In the early 2000s we did a project a bit like that for live content conversion - everything was a dependency relationship defined by a rule, and we had “meta-rules” that could emit more rules as output. So the “root rule” of the system was fixed, but everything else could change dynamically and the minimal set of necessary changes would propagate. I’ve used that pattern a few times since for build systems and it works pretty well once you get the dependency engine implemented.