Can I block providers (for a model, not in general) that set up cache write cost when the mode is free cache writes?

Did you remember to:

- check for the other spawned process exit code?

- waitpid for all process in the other process chain?

- propagate/handle signals, like for example SIGINT/SIGTSTP/SIGPIPE/SIGHUP forward and back signals?

- change stdio buffering mode?

- remember to count how many bytes actually were written by write, and blocking if not, before clobbing the 64kb of the pipe buffer size with another write?

- flush, then close all file descriptors left behind by the pipes when it ends?

It's for reasons like that, that I don't trust anything non-trivial, not-shell to use pipelines correctly.

Under most r/w workloads, using parquet/lance/vortex/native-duckdb, with their built-in columnar compression will result in more performance AND space savings. Non-solid compression. Then, the query engine can push down your query predicate to a column row group level, instead of forcing it to decompress the entire dataset to operate.

Practical example: duckdb has syntax - https://duckdb.org/docs/lts/data/multiple_files/overview - to glob multiple files at once, but that really only works if you're applying push down query predicates instead of re-decompressing your entire data set per SELECT. I would say for most dataset, even 20%+ size is worth not having to decompress (or even download!) the entire dataset, to figure out if something fits the predicate.

After all, if you have to download and decompress the dataset back again to operate, then the "space savings" are gone.

For example, a Macbook Neo (so in theory, something with around 4GiB of free RAM lying around) might eat around 900GB of writes a day while not doing much at all, because it's basically on low on RAM and swapping all the time.

A NAT implementation could broadcast any "WAN" side incoming packets to all link local clients (aka: put everyone in the DMZ). The only thing preventing that is a stateful firewall.

Don't we already have those in mainstream computing in the form of dedicated silicon in DMA controllers? Programmed input–output performance is often low throughput, high jitter and uses a lot of CPU.

> Use electric fans only when temperatures are below 40˚C / 104˚F. In temperatures above 40˚C / 104˚F, fans will heat the body.

- https://www.who.int/news-room/fact-sheets/detail/climate-cha...

> commited on May 21, 2025, over 1 year ago

Fairly old update to the README.md of (instead of Qwen3.8), should have raised some flags?

Edit: arXiv:2505.09388 Qwen3 Technical Report

But again, VisiCalc is intentionally limited, it's not a all-powerful environment, on purpose. It's all about intentional limitations, making computation easier to reason about.

Isn't the the powerful, unlimited, unopinionated blank LLM text input waiting for your instructions eerily similar to a scary terminal?

WIMP and GUI paradigms are the exact the opposite: intentional dis-empowering, by design restrictions, enumeration of your few possible options. Those feel more constrained therefore safer.

What about the system prompt you're using? General purpose harness like Claude Code will insert their happy 22k tokens, even before your first useful token is processed. That might make it a no-go even _before_ you can even start, as the maximum context for this seems pretty limited (to make it fast)

And those LLMs are all "thinking", that is, rather that "one-shoting" the answer, they generate a lot of internal use reasoning tokens before starting to generate useful, visible response tokens. You can easily get to 30k tokens when your initial prompt is vague ambiguous garbage (as are naive transcriptions) as your LLM will "But wait, the user might have meant X, let me think more about this" lots of times.

No thinking (therefore much worse answers) will be a requirement.

ftfy.