As Flatfire mentions, another issue can arise if plugins can modify the config. I assumed config to be read-only for the software, only editable by the admins, and never by the tools themselves.

I’d try to share the config space as much as possible. Options 1 and 3 make sense then.

What feels “right” to me, when using NixOS and its module system, is that all config has the same shape, and is therefor easily moved to a different section, or to a section that is shared by a subset of plugins.

Con: It could lead to bad practices like strengthening dependencies between plugins (if they hard code to use a specific config option of another plugin).

Pro: But if you can discourage that, or use “deprecated pointers” to the new location of an option, the ease of moving shared config options to a more generic level can make it easier to maintain the total configuration. Developers of the separate plugins can build on what others have already done, and even synergize functionality (add a convenient integration if they see another option configured).

If some options are “secret”, though, and you don’t want those shared, they should either be in their own config (easier), or you’d need some access control on the configuration storage/file for each plugin (more work). Allowing a plugin to have a separate file for credentials, for instance, could be a good choice.

I like that I can hear that omitted space there.

git was designed to be decentralized. Everyone can (technically, but it is not too hard to set up if you have some affinity with servers) fork/clone another git repository and serve it up. It has built-in ways to synchronize with any other server. In fact, that synchronizing is what most developers do when they use git.

Of course, that would make it harder to know which repository has the “official” version, but in a way, that is maybe also a benefit of decentralisation. Knowing what code is authentic can be done by signing the commits.

The hubs that we see, are usually a combination of git and a way to serve the code, along with documentation, roadmap, bug tracking, automatic testing and building and the resulting binaries in a visually pleasing way. That does not need to be a part of decentralizing the code, and it is not the only way to do it.

Some of that can also be done with git built-in tracking of files, and the building and testing can probably also done in other locations, as long as there are files describing how to do that bundled with the code (which practically all projects already do).

Sourcehut (https://sr.ht) is one hub that helps developers use simpler tools for those workflows, and I think that’s a good place to find some inspiration.

I would suggest pronouncing “pain killers” in a nice French accent (pan keelUHRZ) when telling the joke. Writing it down might not be necessary then.

ETA: not a native English speaker (nor French). Nor a dad. Also, I tried saying it out loud a few times, and it still misses something. I do see potential, but it might need someone better qualified to fix this completely.

I would say not much different from looking up whether they are in the +0530 or +0630 part of India. I guess the perception of convenience also depends on what you are used to seeing.

That information won’t be lost, though. It just would be expressed differently. They are no longer in a +8 hour time zone, which given your own location in a +1 hour zone would lead to a most likely open time of 8 - 8 + 1 = 1 til 17 - 8 + 1 = 10 your time, but in an area where opening hours are most likely between 0100 and 1000.

There is still a lookup, but no longer a lookup of time difference of the area, but a lookup of usual business hours in the area.

I like the use of the phrase All rights reversed when talking about copyleft.