monus

> You may wonder whether I tried asking an LLM for help or not. Well, I did. In fact it was very helpful in some tasks like summarizing kernel logs [^13] and extracting the gist of them. But when it came to debugging based on all the clues that were available, it concluded that my code didn't have any bugs, and that the CPU hardware was faulty.

This matches my experience whenever I do an unconventional or deep work like the article mentions. The engineers comfortable with this type of work will multiply their worth.

Agreed. I don’t know if it will create or eliminate jobs but this is certainly another level from what we’ve seen before.

Since last 2 months, calling LLMs even internet-level invention is underserving.

You can see the sentiment shift happening last months from all prominent experienced devs to.

Well, we are serving latency sensitive remote control to <one of the biggest banks in US> via WebRTC which uses TLS over TURN so you get 443 HTTPS for the whole traffic.

No NAT, no UDP, just pure TURN traffic over Cloudflare TURN with TLS.

We’ve recently had a disk failure in the primary and CloudNativePG promoted another to be primary but it wasn’t zero downtime. During transition, several queries failed. So something like pgBouncer together with transactional queries (no prepared statements) is still needed which has performance penalty.

The problem with old computers isn’t that they’re slow but fail randomly so they don’t need “smaller” Linux, they need more resiliency that can work with random RAM erros, corrupt disks, absurd CPU instruction failures.

The size was a 90s problem.

Agreed. Use LLM all you want to do the discovery and proof but do not use it to replace your voice. I literally can’t read, my brain just shuts off when I see LLM text.

The hard part is the content of isMalicious() function. The bots can crash but they’d be quick to restart anyway.

> bringing HTTP/2 all the way to the Ruby app server is significantly complexifying your infrastructure for little benefit.

I think the author wrote it with encryption-is-a-must in the mind and after he corrected those parts, the article just ended up with these weird statements. What complexity is introduced apart from changing the serving library in your main file?

Well, yeah, “magic link” is a thing and one of the easiest form of authentication supported by many providers, like Supabase, Vercel and libraries like Next Auth.

Another great side effect is that your backend doesn’t have to store user passwords which means removal of a lot of compliance headaches.

> If I would knew some killer feature, I'd go ahead and write it here. But that's the thing, I can't think of any.

Speed to open and general snappiness. Nothing comes close to Zed especially in larger codebases as most agree in the thread.

TCP connections are identified with source IP:port and target IP:port tuples. When a new pod is created, it gets a new IP so there is not much way to restore the TCP connections. So crik drops all TCP connections and lets the application handle the reconnection logic. There are some CNIs that can give a static IP to pod, but that’s rather unorthodox in k8s.