Comment

Comment by scottlamb

> But doesn't their value lie in getting you access to the core of the OS that you wouldn't be able to touch otherwise? What if your network stack was a library you could instrument just like you do with the rest of your app code?

Yes and no. The traditional separate kernel exposes one set of interfaces that these tools use. A library version might expose a different set of interfaces that accomplish the same thing. Your application could then use those to provide similar observability. But maybe not—that consideration was mostly absent from this article. And with new tools, you need to retrain your developers, SREs, LLM agents, etc. If your new tools are that much better, it might be worth it. But these articles have fallen far short of making that claim.

> Also, I don't need a tool to tell me I'm being punished by the IO or CPU scheduler if I am the only one using the CPU and IO :)

Disagree. Embedded programs still have IO and CPU scheduling problems, including priority inversions. You don't need different programs to have CPU scheduling problems, just different threads, or different tasks with an async scheduler. Any time you have concurrency you need to consider scheduler observability.

parent scottlamb 18 days ago

No comments yet

Be the first to share your thoughts.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton