In this way I’m able to set up AWS EC2 instances or digital ocean droplets, a bunch of game servers spin up and report back their existence to a backend game services API. So far it’s working but this part of my project is still in development.

I used to target containerizing my apps, which adds complexity, but often in AWS I have to care about VMs as resources anyways (e.g. AWS gamelift requires me to spin up VMs, same with AWS EKS). I’m still going back and forth between containerizing and using systemd; having a local stack easily spun up via docker compose is nice, but with systemd what I write locally is basically what runs in prod environment, and there’s less waiting for container builds and such.

I share all of this in case there’s a gray beard wizard out there who can offer opinions. I have a tendency to explore and research (it’s fuuun!) so I’m not sure if I’m on a “this is cool and a great idea” path or on a “nobody does this because <reasons>” path.

  systemd-networkd now implements a resolve hook for its internal DHCP
      server, so that the hostnames tracked in DHCP leases can be resolved
      locally. This is now enabled by default for the DHCP server running
      on the host side of local systemd-nspawn or systemd-vmspawn networks.

All the services you forgot you were running for ten whole years, will fail to launch someday soon.

* https://en.wikipedia.org/wiki/Jamie_Zawinski#Zawinski's_Law

* https://www.jwz.org/hacks/

:)

Breaking systemd was a thorn on distributions trying to use musl.

Probably no biggie to google the necessary copypasta to launch stuff from .service files instead. Which, being custom, won't have their timeout set back to "infinity" with every update. Unlike the existing rc.local wrapper service. Which, having an infinity timeout, and sometimes deciding that whatever was launched by rc.local can't be stopped, can cause shutdown hangs.

v259? [cue https://youtu.be/lHomCiPFknY]

> Required minimum versions of following components are planned to be raised in v260:

* Linux kernel >= 5.10 (recommended >= 5.14),

Don't these two statements contradict each other?