The actual paper is very clear about what it's for: https://fiteoweb.unige.ch/~eckmannj/ps_files/ETPRL.pdf

It says:

    Consider now a general time-dependent field B(t) of duration T. The pulse B(t) may be extremely convoluted ... Can one make the field B(t) return the system to its original state at the end of the pulse...?

They are trying to take any pulse B(t) and zero out any rotation it imparts on some particle or whatever by

    uniformly tuning the field’s magnitude, B(t) → λB(t) or by uniformly stretching or compressing time, B(t) → B(λt)

I think maybe a syntax like -F=-regex would work.

> The way Nixpacks uses Nix to pull in dependencies often results in massive image sizes with a single /nix/store layer ... all Nix and related packages and libraries needed for both the build and runtime are here.

This statement is kinda like “I’m giving up on automobiles because I can’t make them go forward”. This is one of the things Nix can do most reliably. It automates the detection of which runtime dependencies are actually referenced in the resulting binary, using string matching on /nix/store hashes. If they couldn’t make it do that, they’re doing something pretty weird or gravely wrong. I wouldn’t even know where to start to try to stop Nix from solving this automatically!

I wouldn’t read too much into their experience with it. The stuff about versioning is a very normal problem everyone has, would have been more interesting if they attempted to solve it.

It is: https://github.com/facebookincubator/buck2-change-detector

> Some tools such as bazel and buck2 discourage you from checking in generated code and instead run the code generator as part of the build. A downside of this approach is that IDE tools will be unable to resolve any code references to these generated files, since you have to perform a build for them to be generated at all in the first place

Not an issue I have experienced. It's pretty difficult to get into a situation where your IDE is looking in buck-out/v2/gen/781c3091ee3/... for something but not finding it, because the only way it knows about those paths is by the build system building them. Seeing this issue would have to involve stale caches in still-running IDE after cleaning the output folder, which is a problem any size repo can have. In general, if an IDE can index generated code with the language's own build system, then it's not a stretch to have it index generated code from another one.

The problem is more hooking up IDEs to use your build system in the first place. It's a real slog to support many IDEs.

Buck recently introduced an MSBuild project generator where all build commands shell out to buck2. I have seen references to an Xcode one as well, I think there's something there for Android as well. The rust-analyzer support works pretty well but I do run a fork of it. This is just a few. There is a need (somewhat like LSP, but not quite) for a degree of standardization. There is a cambrian explosion of different build systems and each company that maintains one of them only uses one or two IDEs and integrates with those. If you want to use a build system for an IDE they don't support, you are going to have a tough time. Last I checked the best effort by a Language Server implementation at being build-system agnostic is gopls with its "gopackagesdriver" protocol, but even then I don't think anyone but Bazel has integrated with it: https://github.com/bazel-contrib/rules_go/wiki/Editor-and-to...

Whatever it is you think you might like about GitLab in theory, it’s much worse when this is your reality. When it takes that long to render a single MR, you do not want to be creating more of them than you have to, and you certainly don’t want to make yourself and the rest of your team navigate between MRs to do code review.

Nix doesn't need any more home-manager tutorials, because it doesn't need any more small-time tinkerers. It would benefit more from becoming essential to a bunch of businesses who will become invested in making their own developer experience acceptable at scale, and who will have to improve Nix to that end.

Pretty soon a bunch of people are going to realise they actually do need the exact same version of every tool in every toolchain on every machine in a team, to make use of the transformative caching abilities of tools like Bazel and Buck2. And if that catches on, I would not be surprised to see an alternative Nix frontend configured in Starlark, like every other tool in that arena. There's already a buck2-nix that generates dhall under the hood.

There is a separate regime that covers useful articles: design patents, which have a much shorter term. The design patents can AFAIK cover things like toys, I don’t know about game assets. You might have to look at the actual grant of patent rights to see what is claimed. I don’t get the impression that the big aircraft manufacturers care about games for plane nerds.

I am not attempting to claim that games do not have security issues or cannot experience remote code execution, just that this is not a normal pattern of behaviour that they plan for, so it is normal that a game author would deploy wgpu long before Firefox does (while Firefox spends a lot of effort on fuzzing, etc). If anything a terrible CVE that Activision has expended apparently zero resources fixing is a very good example of what I'm talking about.

Firefox has not enabled WebGPU via wgpu for the same reasons Chrome Security has done an in-depth review of Dawn. It is a component that must be hardened. For anyone out there trying it out by enabling config flags, remember to disable it once you are done. It will be ready in time.

Also available on iTunes for a dollar, search for Samir Mezrahi (the blessed soul who made this).