Your 1. seems good enough as a starter, yeah. I’ll probably tell my users to ditch the app altogether otoh, so I’m looking forward to the Pi as a long-term solution

Though, what kind of non-tech nightmares are you referring to? I’d think that if being done properly and with autodiscovery enabled, it would be as seamless as “connect to printer/scanner X on the network” which is the Pi itself. But I probably haven’t understood enough

Damn, I didn’t know devices do these dynamic MACs, but yeah it’s not a trusted field to begin with.

By IPP autodiscovery, do you mean mDNS? If so, does the router needs to install avahi as well for single-network discovery to work? Or just the client?

Avahi on the router for multi VLAN discovery seem to be a nice idea, I’ll look into it and maybe try to hook it up to solution 2. I’ve thought users could just manually input the IP addresses (and the non-tech users will just simply be onboarded by me anyways), but having it advertised by default may just be less of a hassle for them.

Seems okay-ish if it removes all the AI slop and spam quickly. The mods already have the technical power to dictate things, so this rule change just make their actions tie more closely to their management reputation

The blog also stated that FUTO repeatedly gave money to other FOSS projects without following proper process for institutional sponsors, and stick their names onto their front page.

Aside from that, their own projects are source-available at best.

Building a new way does not adequately means giving up on developer verification. In the last paragraph, Google is also promoting the verification for non-GPlay developers.

Out of all possibilities in this universe, there may be a chance that these new flows include user verification instead of developer.

There should also be a rule to rephrase “sideloading” as “installing from non-Google-approved sources” at this point.

So what are the alternatives that work with both Alpine and Debian?

My opinion is that you’d be better off sticking to the OOTB init system that these distros provide, and hop to an entirely different distro that supports the init system you want/need. And for distros that do support multiple, stick to their guides carefully. Would save from a lot of incompat quirks and unsupported bugs, since these things can be as integrated into the main system as the package manager, if not more.

Conceptually though systemd can be a bunch. The s6 dev put out these definitions for the way he conceptually breaks down the entire init/service ecology into small pieces so have a look (ou may be interested in his full post explaining the motivation behind s6/s6-manager too). And since you’re on Alpine, see their plans for a future init system.

With that said you may wanna try out dinit on Chimera Linux. They’re one of the unique distros that offers this and some other cool things

If you have the WireGuard config from Mullvad already, just edit your wg.conf files on client devices to route all traffic via the Mullvad servers. Basically replace all the values of the [Peer] block with Mullvad values.

If you can share your Mullvad wg config file and your wireguard-server config file here, we can sort this out together

Edit: actually since your only goal is to increase the Mullvad device limits, why not just use Mullvad-provided confs directly in your client WireGuard apps? Should be straightforward to do