drivenextfunc

The behavior of CPython and a few other implementations of Python (such as PyPy) is well documented and well understood. The semantics of the tiny subset of Python that this Python-to-eBPF compiler understands is not. For example, inferring from the fact that it statically compiles Python-ish AST to LLVM IR, you can have a rough idea that dynamic elements of Python semantics are unlikely to be compiled, but you cannot know exactly which elements without carefully reading the documentation or source code of the compiler. You can guess globals() or locals() won't work, maybe .__dict__ won't as well, but how about type() or isinstance()? You don't know without digging into the documentation (which may be lacking), because the subset of Python this compiler understands is rather arbitrary.

And also, having an LLM translate Python-ish pseudo code into C does not imply that you cannot examine it before putting it into a program. You can manually review it and make modifications as you want. It just reduces time spent compared with writing C code by hand.

Writing C for eBPF is cumbersome and you'd like to avoid it. Okay, that's reasonable. But I don't think it would be a good idea to write a compiler that emits eBPF binary from (a tiny subset of) Python. Why not just write code in pseudo-Python (or whatever language you're comfortable with) and have it translated by an LLM, and paste it in the source code? That would be much better because there would be fewer layers and a significant reduction in runtime cost.

If you look at the code, you'll be (unpleasantly) surprised, I think. The author does not seem to have known what Y combinator is.

This reads like GPT-5 output. Anyone familiar with the model will recognize its distinctive style. While using LLM-generated content isn't inherently wrong, why not share the prompts? It's like presenting a book summary without naming the book.

Has anyone used OpenTelemetry for long-running batch jobs? OTel seems designed for web apps where spans last seconds/minutes, but batch jobs run for hours or days. Since spans are only submitted after completion, there's no way to track progress during execution, making OTel nearly unusable for batch workloads.

I have a similar issue with Prometheus -- not great for batch job metrics either. It's frustrating how many otherwise excellent OSS tools are optimized for web applications but fall short for batch processing use cases.

Many companies seem to be using Apache Iceberg, but the ecosystem feels immature outside of Java. For instance, iceberg-rust doesn't even support HDFS. (Though admittedly, Iceberg's tendency to create many small files makes it a poor fit for HDFS anyway.)

Regarding the stubborn and narcissistic personality of LLMs (especially reasoning models), I suspect that attempts to make them jailbreak-resistant might be a factor. To prevent users from gaslighting the LLM, trainers might have inadvertently made the LLMs prone to gaslighting users.

I share the author's sentiment completely. At my day job, I manage multiple Kubernetes clusters running dozens of microservices with relative ease. However, for my hobby projects—which generate no revenue and thus have minimal budgets—I find myself in a frustrating position: desperately wanting to use Kubernetes but unable to due to its resource requirements. Kubernetes is simply too resource-intensive to run on a $10/month VPS with just 1 shared vCPU and 2GB of RAM.

This limitation creates numerous headaches. Instead of Deployments, I'm stuck with manual docker compose up/down commands over SSH. Rather than using Ingress, I have to rely on Traefik's container discovery functionality. Recently, I even wrote a small script to manage crontab idempotently because I can't use CronJobs. I'm constantly reinventing solutions to problems that Kubernetes already solves—just less efficiently.

What I really wish for is a lightweight alternative offering a Kubernetes-compatible API that runs well on inexpensive VPS instances. The gap between enterprise-grade container orchestration and affordable hobby hosting remains frustratingly wide.

As a relatively well-educated Japanese native speaker, I too experience this problem when writing Japanese on paper - being unable to write many kanji characters by hand. I am no exception among Japanese native speakers. While the author seems to interpret this problem as something crucial, I question whether it truly is.

The orthography of Mandarin and Japanese includes an alphabet consisting of thousands of characters, the majority of which comprise dozens of strokes. Although East Asian people have higher IQ scores on average, we are not superhuman - our memory capacity is bound by human limits, and the decreased frequency of actually writing kanji on paper has naturally resulted in our forgetting how to write many of them. Is this surprising?

Furthermore, orthography is not part of language in a fundamental sense - it's merely a useful tool that accompanies a language. Therefore, I do not see the writing system becoming less stable as a significant issue. Consider Korea as an example: they used to use kanji in their orthography but have almost completely eliminated it with virtually no adverse effects. While laypeople often assume orthography is an integral part of a language, this is just not the case from the linguistic perspective.

While I acknowledge that JSON Patch can be useful in certain contexts, I find that there are far better alternatives, particularly for the scenarios I encounter. Specifically, when using kustomization.yaml to generate slightly different Kubernetes manifests for various environments (dev/staging/production), tools like jsonnet offer superior functionality and flexibility.