4 ms·
The problem isn't your kernel that needs updating. That's the least of your problems. The problem are the network appliances that are sitting between you and t
by 1_player 8y ago
The problem isn't your kernel that needs updating. That's the least of your problems.
The problem are the network appliances that are sitting between you and the server. i.e. the whole internet. To support feature X, everything between you and the server will need to support that (unless it's backwards compatible, but that's not always the case, as described in the article).
Decade-long adoption will solve this problem, until one day your packet gets routed through some router running Linux v2.5 and your connection silently fails.
This isn't good enough to build a faster (and more reliable) internet on, whereas UDP is a 40-year old standard, and we can assume everybody supports it, even Linux v2.5
- simias 8y agoI agree about the use of UDP to be able to reuse network gear, my comment was prompted by this part of the parent's comment: >from now on we won't have to wait for your kernel to support feature X This is orthogonal to the issue you're discussing (for instance as a thought experiment you could design a new protocol on top of ethernet in userland using raw sockets and it won't be supported by anybody, or you could implement something on top of TCP in the kernel and it'll work everywhere). I just wanted to point out that outdated kernels aren't a fatality, it's a consequence of bad industry practices (in particular, although not uniquely, by Microsoft with its Windows OS). On Linux everything is updated together and the kernel is mostly just another package, so it's a non-issue. It's also means that applications don't have to package a custom updater (and all related infrastructure) by themselves.
- spc476 8y agoSupporting a new protocol on top of IP using raw sockets can be supported by endpoints that are running your software. Except, of course, if you go through NAT or any of these "middleware boxes" that litter the Internet.
- amaccuish 8y ago> On Linux everything is updated together and the kernel is mostly just another package, so it's a non-issue Except say on my linux (ubuntu), yes the kernel is patched, but the version doesn't increase very often at all sadly. Yes I decide to run the mainline kernels since I'm on a laptop and I find that beneficial, but it's not the default of most linux installations I believe.
- asveikau 8y ago> UDP ... we can assume everybody supports it, even Linux v2.5 If you can actually remember the days of Linux 2.5 (development branch which became 2.6) this is a hilarious analogy. I guess that's what the kids are calling ancient these days, eh? Linux 2.5, when dinosaurs roamed the earth! It even did UDP, can you believe it?!
- spc476 8y agoI just now realized that the telephony mindset has won---the "dumb network" (slung packets to an intelligent edge) that was the Internet back in 1992 is now dead a buried. All hail the "smart network!"
- tedd4u 8y agoWhy is that? What’s dumber than UDP (from the network perspective)? From the network perspective it’s a lot dumber than TCP.
- cben 8y agoIndeed. But (not sure if that's what GP meant just guessing) it's sad that tons of middleboxes that peeked too much inside packets effectively broke "end-to-end" goals, so now it's impractical to deploy any new protocols (such as SCTP) alongside existing UDP and TCP. Most practical progress is made by layering more and more on top of existing protocols :-( Actually I'm kinda relieved QUIC succeeded at all with much less layering on top existing stuff than usual. (Compared to say Websockets-over-HTTPS-over-TLS-over-TCP-over-someIPv6-over-IPV4-tunnel...). If it's feasible to deploy a major new protocol over just UDP, that's practically as good as directly over IP! P.S. I think encryption is the main force that held back the (economically almost inevitable) desire of middleboxes to "add value" by manipulating inner layers.