I don't know the specifics of this case, but maybe the investigators just asked in case there was an accidental trigger, or a real trigger etc. Seems reasonable for the detective to attempt to turn over any stone they can to aid the investigation.
Also, for a lot of people working on hardware, the alternatives aren't great. Big Tech players like Apple, Meta, Amazon, etc. all have downsides. Startsups are extremely risky, and don't pay employees as well (ex: Humane, Rabbit, Peleton, etc.)
A slightly better story for those working on software (e.g. Google Photos App or Backend). They have more options, but relatively good jobs (high pay, flexibility, great coworkers non-crazy hours, etc.) as still hard to come by. They exist, but not sure about the quantity.
For the lmarena leaderboard to be really useful you need click the "Style Control" button so that it normalizes for LLMs that generate longer answers, etc. that, while humans may find them more stylistically pleasing, and upvote them, the answers often end up being worse. When you do that, o1 comes out on top followed by o1-preview, then Sonnet 3.5, and in fourth place Gemini Preview 1206.
I'm assuming hedge funds are using LLMs to dissect information from company news, SEC reports as soon as possible then make a decision on trading. Having faster inference would be a huge advantage.
I think there should be a distinction here. E.g. if you work on a browser, possibly implementing parts of image loading, or javascript parser, etc.
Are you consider a dogfooder if you use the browser? or do you need to lots of write Javascript yourself, etc. to be considered "a user of your product"?
Typically, these are two different sets of people.
I suppose this problem is timeless, back when I was active in the PHP community it was a long-running joke that people who "graduated" to committing to the actual php source (in C) were not doing web development work anymore. And I suppose it was actually true for the majority. On the other hand, designing language features wasn't really related to using it for web work.
I should probably just write it up into a post, but the git mailing list at the time is the source (I remember reading it from the side a few months after convincing our VP R&D to switch from svn to git). We were chuckling around the same time that FB had to reallocate the stack on Galaxy S2 phones because they were somehow unaware of proguard or unable to have it work properly with their codegen.
I recall there being a message from someone either at AirBnB or Uber who mentioned that they have a similar monorepo but without the slow git status, but can't seem to find it now - it's likely on one of the other mailing list archives but didn't make it to this one.
Point being that painting this as "the community was hostile" or "git is too slow for FB" is just disingenuous. The FB engineer barely communicated with the git team (at least publicly) and when there was communication, it was pushing a single benchmark that was deeply flawed, and then ignoring feedback on how to both improve the performance of slow blame, commit by repacking checkpoint packfiles (a one-off effort) and also ignoring feedback that the benchmark numbers didn't make sense in absolute terms.
