Viewing profile — shuss

There are many impediments to scaling vibe coding. We built a tool to internally scale vibe coding to vibe engineering: https://mfbt.ai/blog/vibe-coding-vs-vibe-engineering/

[dead]

Fast changing libraries are a huge pain. That's why a no-code approach like Unstract ( https://github.com/zipstack/unstract ) makes sense.

There's also Gocker: https://github.com/shuveb/containers-the-hard-way

Hello HN! One of the most common uses of LLMs is to go beyond what traditional RPA or IDP can do when it comes to structuring unstructured documents. However, there are a lot of ch…

Hello HN! One of the most common uses of LLMs is to go beyond what traditional RPA or IDP can do when it comes to structuring unstructured documents. However, there are a lot of ch…

Yep. Docker is famously written Go. The only reason I wrote this is as an educational tool to discuss how containers under Linux really work. It’s self-contained (pun unintended) e…

This is such a great point. Never thought how async I/O could be a problem this way. In the SQ polling example, I used BPF to "prove" that the process does not make system calls: h…

io_uring_get_probe() needs v5.6 at least.

True. Have to agree, here. Although one advantage over aio for block I/O that io_uring will still have is to use polling mode to almost completely avoid system calls.

The raw io_uring interface, once you ignore the boilerplate initialization code, is actually a super-simple interface to use. liburing is itself only a very thin wrapper on top of …