That's a semantic distinction without a difference.

> The way that you discuss your plan makes it sound as if you consider it morally incumbent upon others to follow suit. I do object to that.

That's more or less true: I do believe that people should BDS corporations that knowingly and willingly harm humanity (eg: aid and abet genocide); that it's not within our interests to let such things slide. And while I am biased, this doesn't feel like a particularly controversial take: it feels like I'm just spelling out basic civics. But.. this is also just like my opinion, man. You do you.

Well, yes, presumably because the maintainers have an obligation to their users (or whoever else they answer to), so I doubt they're overly willing to relegate themselves to being a rubber stamp for whatever some LLM hallucinates as looking good to it.

For example:

- .sdkman has: bin, candidates, contrib, etc, ext, libexec, src, tmp, var

- .gitkraken has: logs, notif, profiles, repohooks, service, themes

- .mullvad-browser has: Downloads, .cache, .config, .local, .mullvad

- .dropbox has: events, instance1, instance_db, logs, machine_storage, metrics, ssa_events

- .steam has: bin, bin32, bin64, debian-installation, root, sdk32, sdk64, steam

- .xpipe has: cache, logs, settings, shell, storage, webview

...etc

I will say that even though I really don't like having a cluttered home folder, I do appreciate things being more or less in one place and so can be easily uninstalled and cleaned up. Flatsweep even being a thing is a testament to the tedium created by dispersing everything across the file system. It reminds me of macOS and not in a good way: I had an equivalent to Flatsweep on my old macbook but I couldn't remember its name so I searched "macos app cleanup tool", and the first page is just a bunch of comparison articles for the 10 (or whatever) best cleanup tools. This shouldn't be a thing. Alas, it is because applications can't or wont clean up after themselves.

I feel like "this is AI" needs to join the ranks "it's not that deep" and "this is a Wendy's" as an annoying thought-terminating cliche.

With that said, Zig falls well short when dependencies have more involved build systems that are too obnoxious to recreate, eg: libevent. I have a bit of a sentimental attachment to libevent and would love to use it within my Zig projects, but the only viable options are: 1) dynamically link; 2) have two [or more] separate build steps; or 3) wait until allyourcodebase does the obnoxious work for me. None of which are appealing so I end up using different libraries just for the build-system integration. And by their nature of being Zig libraries, they're usually less known, less battle-tested, and riskier to use because it's more likely to be some random guy's side project.

Putting aside the StackOverflow tier "why would you ever do/want that?" troll argument, the issue is that I'm being obstructed from using the libraries I want to use over build system incompatibilities. It feels somewhat similar to the complaint about having two [or more] languages within the same codebase.

Fun fact, I've spent the last few days fretting over whether to add H2 to my FabricMC mod. The problem being that I don't know what class-loading shenanigans could possibly occur if I jar-in-jar include it: what happens if another mod has H2 jar-in-jar included? Will my mod only reference its own version of H2? What implications [if any] would that have? Or will the Fabric Loader pick one? What if another mod has H2 shaded instead? Will the classes clash differently? What if, instead of jar-in-jar including it, I shade and relocate it? Does H2 or JDBC rely on reflection or services that would render it non-functional?

All recommendations point to using/creating a mod specifically for that library and depending on it. As luck would have it, one already exists on Modrinth. Except... I'm then requiring anyone who trusts my mod to also install this other mod that I have no control over. I just looked at the source code and it looks fine, but that's if you trust that the published jars are the exact result of that source code: maybe there's something malicious in the Gradle Wrapper binary. This mod could at any time become malicious and how would I detect that?

Guess what? I asked around and was summarily told to stop worrying, that it's fine. We on this website need to realise that we're a minority: NO ONE is routinely (or even occasionally) scrutinising the source code of the stuff they install from third-party websites. I have never, not once, seen anyone hash a downloaded file to check that it matches what's on the website. At the very most, I've seen people find the Github repo, see that it has a lot of stars, and then assume it's safe.