3 ms·
> See all citations about the moving narrow waist. It's far from clear what the design should be. The narrow waist isn't pure or mathematical -- it's a deep en
by gwern 5y ago
> See all citations about the moving narrow waist. It's far from clear what the design should be. The narrow waist isn't pure or mathematical -- it's a deep engineering compromise and can be done well or poorly.
And what motivates the moving or when the waist isn't so narrow?
> - In software, there is an incentive to build your own walled gardens, and not interoperate (Microsoft and Win32, Apple and iTunes, Google and the Cloud, etc.).
> Even if it does fall out in networking, it definitely doesn't in software. Like the Unix syscall interface is small but far from trivial. It's been haphazardly extended. People argue about its design all the time. Ditto for ISAs -- the designs are heavily debated compromises.
End-to-end doesn't argue that you can't have rent-seeking or local optima; just that if you build complexity and intelligence into the intermediate, you will probably limit performance of the total system.
And this is super true in all of the examples you give, they all sacrifice performance that more end-to-end systems would be able to achieve: nobody thinks that ISAs are close to optimal, and RISC won over CISC because they delivered more performance (or consider Itanium); Unix syscalls give up huge amounts of performance all the time (just look at memory management alone, where a decent chunk of syscall complexity is there to let databases and other applications opt out of syscall complexity) and also as demonstrated by exokernels; nobody involved with iTunes etc is laboring under the delusion that its centralized paywalling and Apple-centric design in any way maximizes worldwide music consumption or production efficiency (because it doesn't even try to support countless ways of interacting with music aside from a few blessed ones like albums and podcasting), just laboring under the true belief that it's very good for Apple's pocketbook.
- chubot 5y agoHm 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 agoAdding 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