4 ms·
> Things will never be the same again after the dust settles. And yes, I’m talking about Linux. One has to be in quite a techie bubble to equate Linux kernel f
by mwcampbell 6y ago
> Things will never be the same again after the dust settles. And yes, I’m talking about Linux.
One has to be in quite a techie bubble to equate Linux kernel features with actual world-changing events, as the author goes on to do.
More on-topic though, having read the rest of the article, my guess is that while these features will let companies squeeze some more efficiency out of high-end servers, they won't change how most of us develop applications.
- the8472 6y agoAny async or event-loop runtime can be almost entirely powered by io_uring. Timers, waiting for work when you're out of CPU-bound tasks, most IO syscalls, it all can go through io_uring. You'll still need a few worker threads for blocking syscalls that haven't been ported to io_uring yet but that need is greatly reduced compared to the previous state of things. So even if you're not using io_uring yourself the language standard libraries or server frameworks will. There are WIPs for netty, libuv, nginx. Other projects are exploring it or have announced intent to use it.
- jorangreef 6y agoAnother example, Zig landed io_uring in the std lib a month ago: https://github.com/ziglang/zig/pull/6356 https://github.com/ziglang/zig/pull/6356 I'm also really excited by how you can use io_uring to power everything (fs, networking etc.) with one easy api and a single-threaded event loop: https://github.com/coilhq/tigerbeetle/tree/master/demos/io_uring#what-this-means-for-the-future-of-event-loops https://github.com/coilhq/tigerbeetle/tree/master/demos/io_u... io_uring makes thread-per-core designs so much easier.
- ben509 6y agoHe also brings up 2020 because OMG, it's worst year EVAR. It's not a tech bubble as much as it's a journo bubble. People are reading before they're writing, so he's seeing trendy topics like 2020 and the virus. He feels he needs a hook to get his readers engaged, so he's reaching for things readers can related to. It's a bad hook. I think an editor would have cut that whole intro.
- Matumio 6y agoOh please. It's bad hook, yes. But once we get over that, we should acknowledge that this is an extremely well-written article. It has been a long time since I've stumbled over an article on HN that was such a joy to read.
- blub 6y agoIf the premise is nonsense how can the article be well-written? Most applications will not change the way they work with the kernel, because they don't work with it, they hide it as well as possible under libraries and frameworks. Even so, most applications need neither io_uring, nor eBPF. Hardly a revolution.
- ben509 6y agoI agree it is well-written overall and should have been clearer about that; in my defense, my conclusion was simply that an editor would cut the intro. The intro is both highly visible, and, because of how writing and thinking work, it's also the spot where you're either collecting your thoughts or trying to hook the reader. If you don't have an editor and you're done with your first draft, try deleting your first few paragraphs. It's often a simple way to vastly improve a piece.
- fnord123 6y agoIt was written (or, published) in May. The zeitgeist was very much Corona without the fatigue we have now.
- tehjoker 6y agoWell, getting GB/sec speeds instead of 100s of MB/sec is a pretty impressive improvement in disk utilization.
- hvidgaard 6y agoWithout any doubt, but the impact on the world as a whole is going to barely noticeable.
- perlgeek 6y agoMy real hope is that eventually, you can use some higher-level language to write device drivers for things like crappy IoT gadgets using eBPF, without any chance of crashing the machine due to a pointer fu or so. Knowing that with eBPF I simply cannot crash the laptop I'm working on is a huge deal, and reduces the great psychological hurdle that kernel development always had (for me, at least).