sirclueless

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.

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.

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.

That may be true but people here aren't talking about firing the bottom 10% of ICs, they're talking about firing "50% of Google".

While that's true, I'd be very surprised if git delta-compressed the commit objects themselves. Changing a commit to point at a different tree wouldn't impact the delta-compressed packings of any file blobs, it would just change the actual file the commit points to.

For example, suppose you started with a commit graph that looked like this:

    C1 --- C2 --- C3
     \      \      \
      T1     T2     T3
       \      \      \
        F1 - - F2 - - F3

Where C1, C2 and C3 are commits; T1, T2 and T3 are the trees they reference; and F1, F2 and F3 are three versions of a file blob stored delta-compressed in your packfile. Then if you had a malicious version of C2 with the same hash you could replace C2 with a new commit C2' pointing at a new tree T2' with a new file object F2', and nothing would break. The resulting commit graph would look like this, and F1, F2 and F3 would all still be in your packfile delta-compressed and accessible, just with nothing referencing T2/F2:

    C1 --- C2'--- C3
     \      \      \
      T1     T2'    T3
       \      \      \
        F1 - - \  - - F3
                \
                 F2'

Regardless, this is all moot to some extent. The attack most everyone talks about is that if you were in control of a central git repository (for example if you were hosting a mirror of an open source repository), you could give two different versions of that repository to different people without them being able to tell, even if they were checking PGP signatures or referencing specific git hashes. For example you could serve the non-malicious files to human developers, and when a user-agent that looks like a CI/CD pipeline such as Jenkins or the Ubuntu/Debian/RedHat packager's build machine or someething clones the repository to build a specific hash requested by the user, give it a malicious version of the source tree that builds a backdoor into the binaries it creates. In this sort of attack you never have to "change" a git object on someone's machine which is something the git protocol naturally isn't designed to do because it never happens naturally.

These things really aren't so far apart.

                    --> solve the problem
                  /
    see a problem
                  \
                    --> exploit the problem

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.

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).

Commits aren't patches. They contain the whole tree. Retroactively changing a commit can't possibly introduce conflicts with other commits on top of it, the worst it can do is introduce big funny-looking diffs.

The point isn't to authenticate control of an account, it's to tie the account to some kind of expensive-to-replicate real-world cost, ideally one that most potential customers are already paying for.

Phone numbers are nice because the marginal cost to a customer is low (they probably already have one) while the marginal cost to a bad actor is high (it's expensive to acquire many of them or to change one once it's been identified as malicious).

The DMCA has a couple major parts. The part most people are familiar with deals with safe harbor provisions and "DMCA takedowns". The relevant part for this discussion makes it illegal to circumvent digital access-control technology. So you could argue that if you have reasonable measures in place to stop automated access of your content such as robots.txt then Facebook continuing to send automated requests would be a circumvention of your access controls.