I haven't double checked, but my recollection of that story was that they were using Git as part of the operations at runtime, not (just) as a development dependency.

Do you have a link to a more in-depth analysis of the queuing theory for these numbers?

I can picture charts from various treatments in my head but none of the names stick.

I really should have a favorite couple of links or books but unfortunately I do not. I will put that on my todo list.

The magic search terms are “queue size/length”, “utilization”.

I don't think you can equate CI/CD unit tests and killing humans with 2 tons of metal.

And yet, that's what you get when your software org comes from that kind of devops culture. And here we are

I have to say, I don't see what makes it handle the criticism from the OP. It looks exactly the same as every other Dyson product I've ever seen.

Same as other Dyson product? Have you watched the video or used their vacuum cleaners?

I'm still in love with Caml from my time in prépa, one of the reasons I'm sometimes eyeing JS for a move.

I think OOP meant to say that the `.envrc` file _is_ committed, but they want to do local changes _without_ the possibility of them getting accidentally committed by mistake.

the simple workaround would be to have .envrc optionally load another gitignored file if it exists, which sounds much safer than accidentally committing local changes, even with plain git.

If that's not possible, maybe OP can rename it to .envrc.example, and commit that. Then put in the instructions to rename .envrc.example to .envrc on checkout

Unfortunately neither of that worked, as those are multiple monorepos with different code owners. JJ is nice, but not worth that much of a work around it..

When looking at their bridge documentation for my own homeserver, I noticed that they do provide a way to self-host the bridges to be used with Beeper's homeserver as well.

See https://github.com/beeper/bridge-manager

My thinking is that the dev _did_ work on it for X amount of time, but as part of their contract is not allowed to share the _actual_ history of the repo, thus the massive code dumped in their "Nobody expects the Red Team" commit?

Opening it in a new tab on FF on Android works fine on the first try.

This looks like a worse version of the one I used, the TI nspire CX CAS, for about the same price.

Both the CG50 and nspire has working Numworks ports (although very slow), if you wanted something more fancy on the same hardware.

https://github.com/UpsilonNumworks/Upsilon https://github.com/UpsilonNumworks/Upsilon/issues/327

Crap, this thread revealed to me that the developer of Giac/Xcas basically gave up on using git altogether due to its complexity/poor workflow. I'm profoundly annoyed that the worse DVCS won, became a monopoly, and that a whole generation which hasn't seen better just accepts its quirks without a second thought.