Ephera

Well, any software needs to include a license of some form, if you want it to be usable by others. But if it's not an open-source or libre license, then it's a proprietary license. That's not necessarily a bad thing. At that point, it depends on what's actually written into the license. But it's also not a good thing, as you miss out on various open-source benefits due to there being no proven legal compatibility with open-source licenses. Well, and if I remember correctly, FUTO's license actively prohibits reuse of the code anyways.

Over-full stack developer.

Well, I'm hoping, they also talked about whether she wants a public proposal. If she told him to ask her with a megaphone, whether she wants tea, then she's hopefully sure enough. Well, and it's not either like she'll have to empty that cup of tea right then and there. There's still plenty ways to back out, if she starts doubting herself.

I also like to use log statements or error messages as a way to describe what's happening.

Comments are only visible in the exact spot where they're written, whereas decent names or log statements become visible in a second place, which makes them more valuable, but also increases the chance of them being kept up-to-date.

Chances are, they've talked about it beforehand and it's only a matter of making the decision public...

Personally, I'm at the point where I try to only use community-developed software. I've seen it too often that even projects which are nominally open-source start becoming cunts...

Android, Chromium.

The problem is that:

1. Google puts in more development power than anyone else. Any forks we've seen so far are only really soft forks, as in they only apply a few patches on top of what Google puts out, rather than taking the project in a new direction, because you'd be behind pretty quickly.
2. These projects establish platforms that have shitty decisions baked in. For example, the Android dev tooling has Google ads/tracking as one of the built-in UI components, which is why even if you patch the OS, the apps will still be shitty. To actually change this stuff, you'd need a majority of users to switch to your fork and stay there for a few years.
3. Partially, it's only financially viable for Google to develop these projects, because they have those Android ads or benefit from a web with less tracking protection. This makes it extremely unlikely for any other organization to be able to splurge a similar amount of money, which brings us back to a fork just being unlikely.

And so long as a fork is unlikely, Google can do shitfuckery quite similar to proprietary projects.

Yeah, I guess this isn't the first of these costumes that needs to solve that problem, but rather all of them need to. I just had never thought about it...

Do I want to know the logistics of how the wiener bun is escape-proof, while not also being potty-proof?

Yeah, everyone else had already answered that, which felt like we're picking apart that specific thought experiment, even though there is actually a much more fundamental reason why it won't work.

Perhaps also worth pointing out that the speed of light is that exact speed, because light itself hits a speed limit.

As far as we know, light has no mass, so if it is accelerated in any way, it should immediately have infinite acceleration and therefore infinite speed (this is simplifying too much by using a classical physics formula, but basically it's like this: a = f/m = f/0 = ∞). And well, light doesn't go at infinite speed, presumably because it hits that speed limit, which is somehow inherent to the universe.

That speed limit is referred to as the "speed of causality" and we assume it to apply to everything. That's also why other massless things happen to travel at the speed of causality/light, too, like for example gravitational waves. Well, and it would definitely also apply to that pole.

Here's a video of someone going into much more depth on this: https://www.pbs.org/video/pbs-space-time-speed-light-not-about-light/

Oh, that is actually the part I do agree with. I don't think everyone will, but I do actually think JSON is easier to read and write (correctly) than YAML. I specifically wrote that JSON cares the least about that, because it was designed to just serialize JavaScript objects into strings and back. As far as its original purpose is concerned, no one would ever need to hand-edit JSON. Which is also why it doesn't support comments (which is still somewhat of a dealbreaker for a configuration language, although I guess for your proposed workaround, one could potentially use a JSON flavor which supports comments; potentially, you can even write your JSON in the YAML file with comments directly and then not convert it, since YAML is a superset of JSON).

As for documentation, yeah, it is possible to convert, but it makes it more annoying, particularly also if you then can't easily re-use configs in another project. And if you're working in a team, having to explain to all your team members, how they can convert the official documentation, is also not really acceptable...