matthewbauer

Do you notice this on macOS or Linux?

I definitely notice an EDR tax on macOS generally, but I haven't noticed Emacs having issues specifically. It's usually certain I/O operations like Git or tarball extraction that become slow.

Is this new? The date says July 8, 2026.

Might want to check your git logs if you are using the Merge Queue feature. This afternoon, we found that Merge Queue was silently reverting changesets in the merge queue. Acknowledged by GitHub, but could be a very hard problem to debug if you aren't looking for it.

Yeah city is not fully a function of zip. ~I think state is though.~* I believe when multiple cities share a zip code USPS uses the larger one. Usually the wrong city will get delivered though, probably not guaranteed.

* correcting myself, some zip codes do cross state lines

It seems like they should be able to “overweight” newer training data. But the risk is the newer training data is going to skew more towards AI slop than older training data.

I don’t think you can do that. Or at least if you could, it would be an unintelligible version of English that would not seem much different from a programming language.

I went by it a few weeks ago. There's a gate on the driveway, and I assume some kind of security presence. Probably no different than anyone under constant public scrutiny.

Hard to know what OP meant, but I took it as an oblique reference to China.

I mean you can do it in Nix using overlays and overrides. But it won’t be cached for you and there’s a lot of extra fiddling required. I think it’s pretty much the same as how Bazel and Buck work. This is the future like it or now.

Not sure on the exact take of the OP, but:

Package maintainers often think in terms of constraints like I need a 1.0.0 <= pkg1 < 2.0.0 and a 2.5.0 <= pkg2 < 3.0.0. This tends to make total sense in the micro context of a single package but always falls apart IMO in the macro context. The problem is:

- constraints are not always right (say pkg1==1.9.0 actually breaks things)

- constraints of each dependency combined ends up giving very little degrees of freedom in constraint solving, so that you can’t in fact just take any pkg1 and use it

- even if you can use a given version, your package may have a hidden dependency on one if pkg1’s dependencies, that is only apparent once you start changing pkg1’s version

Constraint solving is really difficult and while it’s a cool idea, I think Nixpkgs takes the right approach in mostly avoiding it. If you want a given version of a package, you are forced to take the whole package set with you. So while you can’t say take a version of pkg1 from 2015 and use it with a version of pkg2 from 2025, you can just take the whole 2015 Nixpkgs and get pkg1 & pkg2 from 2015.