I don't think it's absurd at all. I think it is a practical principle that shows up all the time in collective action problems. For example, suppose hypothetically there were a bunch of business owners who operated under an authoritarian government which they believed was bad for business, but felt obliged to publicly support it anyways because opposing it could lead to retaliation, thus increasing its ability to stay in power.
That’s a completely different situation though. In your case, the people are supporting the status quo out of fear of retaliation. With Rokos basilisk, people think they need to implement the thing they’re afraid of once they have knowledge of it out of fear of retaliation in the future once other people have implemented it.
Like every other decision SBF would prefer you not examine: It fits because the ends justify the means.
It's important for the business that the insurance fund is safe. If you look closely you will find that it is unsafe. But if people believe it is safe you won't need the insurance fund, so do whatever you need to to inspire confidence in the insurance fund.
The safety (or not) of the insurance fund is not related to the need for it. The need would come from a counterparty defaulting - which is generally unrelated.
I don't really understand the analogy. Mechanical watches have created an industry of skilled practitioners trained to fix them because they often need diagnosis and repair. NASA has a room full of oncall personnel available for many hours any time they launch anything, and they launch things much less frequently than your average tech company.
Oncall rotations are part of defense-in-depth against bugs and unforeseen circumstances: Most of the companies that survive without a formal one only do so by outsourcing this for the most common cases; to Cloudflare, to Amazon, etc. -- if there's an opportunity cost to being down someone needs to be able to pick up the phone when there's an outage or critical issue.
It's especially hard because the stdlib changes quite a lot still. Examples go out of date so adding documentation like this is not just one-time work. I am working my way through learning the language and it's not uncommon to find blog posts or news snippets from 4 months ago introducing features, and they already don't compile.
> E.g. if A patents X and some large company B wants to use X and A refuses, then B cannot use X even if they offer millions.
How does this situation improve in any way if X is a trade secret? Under what circumstance would company A be willing to accept payment to make X open, but not willing to license X as a protected patent?
It sounds like you'd be in exactly the same situation except that there would be a massive collective action problem trying to figure out how much the world should pay A to make the invention open and who should pay it, and also A and B would have multi-million-dollar incentives to engage in corporate espionage and counter-espionage that achieves no progress.
As someone who occasionally watches competitive programming for fun (and competitive programming is basically competitive whiteboard interviewing) it gives me quite a bit of perverse pleasure that even in languages with great first-class class and object support the norm is to write functions that operate on global variables.
> Granted, the file that the commit touches would need to be not touched in other commits.
That's not how git works. The commit contains the entire tree. You could prepare two separate repositories such that `git checkout deadbeef0001deadbeef` in one checks out the linux kernel and in the other checks out ILOVEYOU.exe.
You're right. Commit id points to a commit object, that points to a tree object and subsequently to individual blob objects. Then it is sufficiently harder, you need to find a collision between 2 blob objects, both of which are executable and don't look suspicious.
Every commit references every file. If you change the content of an old commit you would only affect people who check out the old commit. So this is utterly pointless and not what someone would do.
Instead what you would do is attempt to make a file-object that has a certain SHA1 hash identifying it, and a colliding file-object that has the same SHA1 hash. Then you are free to give people who clone the repository different file contents depending on when/who/how someone requests it (if the file content is hosted on github, how to change the file object identified by a given SHA1 hash is an additional hurdle since it's assumed to be immutable and indefinitely cacheable; if you control the host yourself you can just change it whenever you like).
