Systemd-networkd (not systemd the init system) defaulted to the google DNS servers when:
That is indeed a serious issue worth bringing up decades later.
You are not done one the config is written: A configuration requires maintenance effort: New plugins get released, others stop getting developed, APIs change. You constantly need to adapt your configuration.
That is why I recommend using a distribution like astonvim. A distribution takes care of keeping the basics going and gives a well msintained base and thus gives you more time to fiddle with the interesting bits of the configuration.
Astronvim in particular is "just" a lazy nvim config and very easy to customize, filtering the standard override process defined by the lazy plugin manager.
I actually got rid of most custom config I had on top of astronvim by using its community repository: It contains easy to add config snippets that fully integrate other plugins with all the plugins in the astronvim config (lsp setup, treesitter, snippets, completion, ...). This ranges from adding one plugin to entire language packs with all the recommended bells and whistles to work with some programming language.
Oh, the repository are easy to move.
The bug reports, PRs, wikis, CI/CD are stuck in github though. There is a huge lock in.
Are they embracing activity pub? I read it is just one guy in the community working in it.
And the vast majority of users are on GitHub, looking for code on there. Having activity pub on other forges will not change that big time:-(
Everybody needs just a small subset of that excel does, but everybody needs a different subset.
If you do not have all the features, most of your users will be missing something that is critical to their use case.
An update is only truly done once no remnants of the old code is in memory. Code can stick around in the form of binaries (restart the binaries), libraries (restart all binaries that use this library) and the kernel (reboot or use kexec).
One very simple way to make sure no old code sticks around is to reboot:-)
It is damn hard to write tooling for C++ projects: There are no standard ways to do anything, so you need to add lots of options just to cover a range of project configurations. Those add a lot of complexity very fast, which is unrelated to the actual task you want to solve.
Build everything you use and ackage it in flatpak?
It's not even that hard to build your own gentoo-based runtimes and install stuff on top of that. Fedora does offer that, too, offering fatpaks based on their own fedora based runtime + rpms.
Works for me on arch linux. No hickups or anything and I am using it since it was first announced.
A good choice... another ist astronvim.
Astronvim covers the basic setup and their community repo with its language packs the specifics :-)
The problem is that you lose out on dev attention when moving away from github.
I moved my projects into github when placeholder projects literally containing a README with a link to the real repo only got way more interaction on github than in the real repository: More stars, more views, more issue reports and even more PRs (where the devs have obviously Cloned the repo from the actual repository but could not be arsed to push there as well).
If you want your project to be visible, it needs to be on github at this point in time:-(
Yeah, sure... integrating a init system is a huge task (if you want to do it properly). Let's do that several times!