dirk94018

toast is sed with a brain. I got tired of cut and paste and made my own tool. Then I decided to let the AI drive and tried toast | bash, pretty good but AIs are terrible at escaping, got annoyed and wrote a shell for AI to use called jam. Wanted a bot to answer my texts, so I wrote iMessage, a cli tool. Now you can do iMessage -c iMessage | toast | iMessage and it answers texts. There is more and now its a startup, Unix re-imagined for AI: https:/linuxtoaster.com

Crawler. Heh.. never thought of it that way.

This is exactly right. We hit the same wall. Our solution was to re-imagine Unix at https://linuxtoaster.com, and either pipe through jq etc or just start rewriting tools that do that. A good tool shouldn't be verbose out of laziness, it should be conscious of the information that might be needed by the next step in the pipeline. If deeper information is needed, the user should ask for that, with a command line flag.

The Pentagon seems to see this as a procurement issue, we bought a tool, don't tell us how to use it, and Anthropic seems concerned that the tool's nature is shaped by the constraints put on it, and we don't really understand this AI thing, and an unconstrained version could be a worse and more dangerous tool.

Cool

This is exactly why local inference matters. Every query you send to a cloud API is another data point. Your prompts contain your code, your logs, your thought process — arguably more identifying than your HN comments.

The paper shows deanonymization from public posts. Imagine what's possible with private API traffic: the questions you ask, the code you paste, the errors you debug. Even if providers don't read it today, the data exists and the cost of analyzing it is going to zero.

Air-gapped local inference isn't paranoia. It's necessary.

TexMacs is great. However, I use LaTeX regularly. Used to keep a cheat sheet of commands I'd forget between documents. Today I can describe what I want in plain English, pipe it through toast, and get the LaTeX back.

LaTeX, vim, sed, awk, the whole Unix toolkit is getting a new lease on life, because their interfaces are text. Text in, text out. An LLM can write you a perfect \begin{tikzpicture} on the first try.

Clicking through a GUI is much harder and instead of the computer doing the work, I feel like I am working. WYSIWYG won because it made functionality discoverable, today we have AI mentors.

Hydrogen has been the future as long as I have been paying attention to electric cars. There are many problems with it, including Hydrogen is the smallest molecule. It leaks through seals, embrittles metals, and has terrible energy density by volume. You either compress it to 700 bar (heavy tanks), liquefy it at -253°C (energy-intensive), or store it in metal hydrides (heavy, slow release). Solid state batteries are much more interesting. They extend EV range to 600-1000 miles and enable 10-minute charging. If they work at scale, they kill hydrogen for cars, trucks, and probably short-haul aviation too.

Early BSD VM pre-allocated swap backing for every anonymous page — you couldn't allocate virtual memory without a swap slot reserved for it, even if the page was never paged out.

When a process forks, the child needed swap reservations for the parent's entire address space (before exec replaces it). A large process forking temporarily needs double its swap allocation. If your working set is roughly equal to physical RAM, fork alone gets you to 2x.

This was the practical bottleneck people actually hit. Your system had enough RAM, swap wasn't full, but fork() failed because there wasn't enough contiguous swap to reserve. 2x was the number that made fork() stop failing on a reasonably loaded system.

The later overcommit/copy-on-write changes made this less relevant, but the rule of thumb outlived the technical reason. Most people repeating "2x RAM" today are running systems where anonymous pages aren't swap-backed until actually paged out.

Today swap is no longer about extending your address space, it's about giving the kernel room to page out cold anonymous pages so that RAM can be used for disk cache.

A little swap makes the system faster even when you're nowhere near running out of memory, because the kernel can evict pages it hasn't touched in hours and use that RAM for hot file data instead.

The exception is hibernation — you need swap >= RAM for that, which is why Ubuntu's recommendations are higher than RedHat's 20% of RAM.

Hmm. Interesting thought but maybe not everyone without a car needs a bus? My favorite way to get around SF is an EUC. On the side walk, I'm a pedestrian, moving at 2 miles per hour. On the road I'm a car, moving at 30-40 miles per hour. In the coffee shop, I'm a guy with luggage. CALTRAIN is great for moving me and the EUC between San Francisco and Palo Alto. Truck takes me and the EUC to the coast for a swim.

I remember that. A few weeks later ran a script to count all the websites on the Internet.. 324 at that time.

Aren't LLMs supposed to write machine code directly, no more programming languages at all, any day now? Joking aside, programming languages are a good mental exercise. Forth was my first language after assembly. Didn't like the stack juggling and ended up using its macro assembler more and more, it became something else, conventions over code I suppose, like what to keep in registers. Forth (and Unix) got the composability requirement right, the testing of individual units.

Those European university tests copied by Google, then copied by SV startups, mostly deliver two things, making the interviewer feel superior and filtering for submissive coders.

All managers dream of robots that can read minds and work for titles but lazy managers prefer to hire those who do what they are told, even if its pointless, even when done poorly or without imagination.

A good manager is worth his weight in gold. "I will not do your tech interview" while offering a short contract is an excellent way to screen out the lazy managers.