3 ms·

Hm I don't follow ... The narrow waist claims I'm making is only indirectly related to performance. I think you would have to define "intermediate" and "end" i

by chubot 5y ago

Hm I don't follow ... The narrow waist claims I'm making is only indirectly related to performance. I think you would have to define "intermediate" and "end" in Unix, ISAs, etc. It's not clear what analogy you're making. The claim you're making appears to be very strong: the narrow waist idea is a special case of the end-to-end principle? Is this something you are asserting now, or has something been written about it by you or others? As mentioned I see them as distinct in networking ... and when extended to software, I barely see the relation. I am purposely extending the "meta-idea" to software; this comment shows where it's going: https://old.reddit.com/r/programming/comments/t2bapy/the_internet_was_designed_with_a_narrow_waist/hynz9cu/ https://old.reddit.com/r/programming/comments/t2bapy/the_int... A critique I'd see as more valid is that a "narrow waist" is simply a "standard". That is by far the closer idea, not the end-to-end principle. But I will justify the term and make the definition crisper. All the comments here and elsewhere have convinced me of that, e.g. https://lobste.rs/s/o3rjb0/internet_was_designed_with_narrow_waist https://lobste.rs/s/o3rjb0/internet_was_designed_with_narrow... People understand what I'm saying, they are able to apply it, and they see the consequences... I will mention related concepts like Metcalfe's law, and maybe the end-to-end principle, but that one seems the least relevant. I'd definitely be interested in reading an article that claims otherwise though! --- To answer the first question, the moving waists are motivated by real world usage, i.e. engineering requirements. The waist is a big engineering compromise. IP doesn't have auth or content caching; HTTP has that. People who want that functionality start building on that layer, etc. Scaling and increase in nodes is another example of pressure on the waist, e.g. the need for NAT traversal

chubot 5y ago
Adding one more thing: I'd also say there's a big asymmetry in DLLs vs. static libraries. DLLs that can be independently upgraded pretty much have to use the C ABI, which is more like RPC/IPC. It doesn't really make sense to have a pure Rust or C++ DLL -- you lose all your types and type safety; you have to write glue. So actually I'd say IPC and DLLs are closer together, and static libraries are on the other end of the spectrum. IPC and DLLs are both dynamic, and that's the important distinction. That's what a lot of the decisions in the acko.net article hinge on

by chubot 5y ago

chubot 5y ago

Adding one more thing: I'd also say there's a big asymmetry in DLLs vs. static libraries. DLLs that can be independently upgraded pretty much have to use the C ABI, which is more like RPC/IPC. It doesn't really make sense to have a pure Rust or C++ DLL -- you lose all your types and type safety; you have to write glue. So actually I'd say IPC and DLLs are closer together, and static libraries are on the other end of the spectrum. IPC and DLLs are both dynamic, and that's the important distinction. That's what a lot of the decisions in the acko.net article hinge on