Post #664025

2026-03-15 16:02 UTC

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!

Replies (7)

@suetanvil@freeradical.zone 2026-03-15 17:00

@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.

Open ##2162164
@lykso@tiny.tilde.website 2026-03-15 17:55

@totbwf Sounds like something that would be right up the alley of an Erlang or Lisp.

Open ##2162167
@freja@freja.zone 2026-03-15 18:08

@totbwf cmake as init system

Open ##2162168
@freya@social.highenergymagic.net 2026-03-15 20:12

@totbwf oh gods, nooooo.... that seems deeply cursed...

Open ##2162169
@xameer@mathstodon.xyz 2026-03-15 21:00

@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

Open ##2162171
@milo@types.pl 2026-03-15 21:43

@totbwf ooh i really like this

Open ##2162172
@shironekoben@mastodon.gamedev.place 2026-03-16 00:56

@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.

Open ##2162173