I'll be honest, that does not sound "easy".

It is straightforward, but so is the NixOS module system, and I could describe writing a custom module the same way you described custom Docker images.

It isn't the absolutely easiest process.

But it works on Ubuntu, it works on Debian, it works on Mac, it works on Windows, it works on a lot of things other than a Nix install.

And I have to know Docker for work anyhow. I don't have to know Nix for anything else.

You can't win on "it's net easier in Nix" than anywhere else, and a lot of us are pretty used to "it's just one line" and know exactly what that means when that one line isn't quite what we need or want. Maybe it easier after a rather large up-front investment into Nix, but I've got dozens of technologies asking me for large up-front investments.

It only works on Mac and windows as a VM.

Nix is for reproducibility. Nix and docker are orthogonal. You can create reproducible docker image via nix. You can run nix inside docker on systems that doesn’t allow you to create the nix store.

This is a familiarity problem. I've never used NixOS and all your posts telling me how simple it is sounds like super daunting challenges to me versus just updating a Dockerfile or a one liner in compose that I am already familiar with, I suspect its the inverse for you.

If that’s not easy I don’t know what is.

If it wasn't easy, I wouldn't be using it. I'm the laziest of programmers or users.

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.