I tried fedora silverblue for a while, but the way it works is that it builds a new root fs image whenever you change the installed packages, this makes system package changes take comparatively long vs a traditional os. They suggest installing most apps via flatpak, which is okay as long as you can deal with flatpak idiosyncrasies.

I also tried fedora coreos for a vm + container host, but found the recommended method to configure the system with ignition files and one shot systemd units to be too involved for making a one off system, and it’s probably better for a cloud deployment with many identical nodes.

In all fairness, Nix is similarly slow.

I think it’s not so much that the asyncio primitives got wrong about shared state, as much as is what the authors got wrong about the usage of those primitives. They are classic concurrency primitives that’s been around for almost half a century. They work as designed, but require some care to use correctly.

Agreed. This isn't an asyncio problem, it's just not how those primatices work.

I noticed requests that were exploiting the vulnerability were turning into timeouts pretty much immediately after rolling out the patch. I’m surprised it took so long for it to be announced.

Is there a mypy plugin or other tool to check this via static analysis before runtime? To my knowledge jaxtyping can only be checked at runtime.

I doubt it, since jaxtyping supports some quite advanced stuff:

    def full(size: int, fill: float) -> Float[Array, "{size}"]:
        return jax.numpy.full((size,), fill)

    class SomeClass:
        some_value = 5

        def full(self, fill: float) -> Float[Array, "{self.some_value}+3"]:
            return jax.numpy.full((self.some_value + 3,), fill)

I’ve also done a noctua fan replacement on my ups. My worry is that they are rated for lower airflow than the original fans they replaced. Have you checked whether it stays cool when running on battery?

It's a permanent double conversion UPS; it's always inverting. You could activate the "high efficiency" bypass mode to directly connect the input to the output in the presence of mains AC input, but this would also pass through disturbances like fluctuations, harmonics, and surges, so I don't have it enabled. This wastes about 80W in my setup but whatever. I'm not worried about the inverter temperature is the point I'm trying to make; but I was considering this when I did it, which is why they're wired to run at full speed all the time.

I had the same thought, and looked specifically for this in the paper. They do have a section where they talk about fine tuning with “cold” versions of the responses and comparing it with the fine tuned “warm” versions. They found that the “cold” fine tune performed as good or better than the base model, while the warm version performed worse.

One more: https://conifer.rhizome.org/

This one seems to be directly related to the webrecorder project which seems like a pretty full featured warc recorder.

But the author doesn’t give a single example, and so there’s nothing someone else can do to explain why or continue the conversation. The best we got use that he has a vague sense of unease, which I don’t think is very useful.

I think the facilities for building larger applications are lacking in APL. It would be great as something embedded into other languages. Consider something like numpy’s einsum, but using apl expressions instead. Use APL to express what it’s good at, and use the facilities of the host language to put together bigger systems.

Large parts of Sweden's health system run on APL; Deutsche Bank also uses lots of APL; Denkmark has an appreciable number of companies using APL. IMHO, the problem isn't the scalability of APL (Dyalog, specifically) but more that good, maintainable, solid APL violates what the industry holds up as Best Practices etc. Trying to apply typical software architecture methodologies to APL definitely evokes the feeling you describe.

However, APL in my experience enables radical simplicity for building large applications. Learning to leverage that means that you need to first unlearn lots of ingrained problem-solving habits and ways of thinking as a software engineer. It's admittedly a steep hill to climb.

Has there been one in the 22 years preceding 9/11?