The web browser isn't Netflix trying to serve hundreds of gigabits per second of encrypted video streams from a single server. Do you really need the ability to reliably saturate a 40 Gb/s Ethernet link to browse Hacker News comfortably? You'll hit various other bottlenecks long before performance for practical usages of web browsers will be significantly impacted by a user-land network stack.

As I've said, there are use-cases where extreme throughput and latency requirements warrant a design focusing on performance. Smartphones aren't one of them.

> I don't know how you can possibly assert that, it's contradicting computer sciences' current understanding of operating system design as it relates to kernelmode/usermode switching, unless you're doing weird shared-memory things in userspace... which is terrifying.

Again, not everyone is Netflix. I'd rather have a computer capped at 1 Gb/s speed with a user-land network stack than a computer capable of saturating a 40 Gb/s Ethernet link with a kernel network stack when I'm managing my bank accounts. Most end-users don't need ludicrously fast network speeds to browse funny cat GIFs on their web browsers.

Also, I've contributed code to multiple operating systems (MINIX3, SerenityOS). Running an user-land network stack isn't going to turn your 1 Gb/s Ethernet card into a 10 Mb/s Ethernet card.

> Not really, C and Rust can interop just fine, you can have network drivers that are rust but the actual networking stack itself can remain C, if you want.

As far as I can tell, the bug is in the network stack itself. A network driver written in Rust wouldn't immunize your Linux kernel here from this bug.

> The post is literally memory safety bugs.

The consequence is about computer security, of which memory safety bugs are but one cause among many.

Shared-memory things in userspace, i.e. buffers shared between 2 distinct user processes are no weirder than buffers that are shared between a user process and a kernel-mode driver. In both cases the buffers cannot be accessed by third parties.

Moreover, the transfer of data between 2 processes through a shared buffer can be done without any context switch (which could be slow), if the 2 processes are executed on distinct cores. Therefore having the network device driver as a distinct process does not have to cause any reduction in performance, if the means for inter-process communication are chosen wisely.

For any device driver that is implemented as a user process, the kernel can enable direct access to any I/O ports and memory-mapped I/O areas that are needed by the device, so the device driver can work in user mode without requiring any context switches.

Such direct I/O access cannot be enabled for ordinary processes, because those are not trusted enough and also because the direct I/O access could be enabled only for a single process at a time.

A dedicated device driver process solves both the trust problem and the multiple access problem equally well as a kernel-mode driver.

They clearly didn't claim that. Your webbrowser being slow nowadays is not because it needs to do some networking.