The perils of federated protocols
The perils of federated protocols
Posted May 19, 2016 11:58 UTC (Thu) by khim (subscriber, #9252)In reply to: The perils of federated protocols by wahern
Parent article: The perils of federated protocols
However stunted and slow the evolution of HTTP has been, the browser environments have evolved quickly.
If you compare it to non-existent development of SMTP or decades-long process of switching to IPv6 then yes, sure. If you compare it to other competing, non-federated technologies… then it's slow as snail. What have we gotten on the web lately? WebGL, WebRTC, SPDY/HTTP/2… and now there are “exciting” new features: low-level bytecode, GPU computation with WebCL (or maybe with compute shaders?)… they were discussed years ago and are still not usable on the web.
Compare that development to the development of non-federated platforms: when old API is no longer suitable it's replaced quickly (both Metal and Vulkan were introduced and implemented in a span of about one year), and political discussions don't bogge down development (think NaCl/asm.js/WebAssembly fiasco: Android and even laggard Windows Phone 8 have gotten a way to run fast, native code in a couple of years—while “quickly evolving” world of web browsers ws left behind…
Sorry, but development of web browsers shows just how right Marlinspike is: federated worlds could exist—but only if non-federated alternative is unusable. Internet and web have won not because they were federated, but because they were large: they just had more users than AOL or CompuServe.
When you need federated protocols and clients/servers to reach out to billions of users then such protocols win by default. When you have an ability to develop non-federated solution… well, it's not even a contest.
In hardware world federated solutions often win because they spread development cost (if one company develops non-federated solution and dozen or hundreds of companies develop a federated one then sheer money power often prevail) but in a world of software this factor does not work: companies could just pool their resources and develop one single solution instead.
Posted May 19, 2016 12:09 UTC (Thu)
by pizza (subscriber, #46)
[Link] (1 responses)
They didn't start out large. The question you should be asking is how/why they became large, given their early disadvantages.
And that answer is ... federation.
Posted May 19, 2016 18:11 UTC (Thu)
by khim (subscriber, #9252)
[Link]
That's right answer to the wrong question. Of course federation makes it possible to build large system and, indeed, when large system couldn't be monolithic they become federated. Even today there are many systems which are federated: not just ISPs, but cellular networks, railroads, airlines and many other systems are federated today! Heck, you could even find popular federated systems developed in XXI century (here is one, e.g.). But they all share one important quality: they have some kind of “ceiling”. Some reason which limits growth of unfederated alternative. It may be technical reason (AOL/Compuserve growth hit the limit when it reached US borders: it was impossible to provide cheap enough access to people in Asia or Europe because intercontinental phone calls were incredibly expensive), it may be non-technical reason (RIAA and MPAA made sure that there would be no huge torrent sites with millions of user thus we've naturally gotten DHT), but if there are no “ceiling” then there are no reason for the federation. It's more cumbersome and thus less attractive solution, it's only chosen by users out of necessity, not out of desire.
Posted May 20, 2016 8:28 UTC (Fri)
by niner (subscriber, #26151)
[Link] (7 responses)
Posted May 22, 2016 16:54 UTC (Sun)
by jospoortvliet (guest, #33164)
[Link] (6 responses)
Posted May 22, 2016 17:35 UTC (Sun)
by flussence (guest, #85566)
[Link] (5 responses)
Posted May 22, 2016 19:34 UTC (Sun)
by mathstuf (subscriber, #69389)
[Link]
Posted May 23, 2016 14:16 UTC (Mon)
by khim (subscriber, #9252)
[Link] (3 responses)
Define “usable”, please. All the HPC is built today around GPGPU and similar architectures (things like Xeon Phi, it's used on your mobile phone (to process photos in real-time and do other compute-intensive things) and so on. The fact that Linux distros (and desktop in general) are no longer in the center of this development is unfortunate (especially since lots of development is based on Linux), but it does not mean that all that development have just stopped and disappeared. Vulkan works today (although not that many apps use it), Metal is used by real apps, too (look here - there are links to appstore where they could be found). Sure, you couldn't use it on your device if your insist on 100% OS but most users out there don't care and use it just fine. And while WebGL is usable today don't forget that we are talking about technology which is almost two decades old (DirectX was released in 1996 and OpenGL is even older then that). Sure, you could counter that other unfederated APIs (things like Glade, e.g.) have died—but there are emulators and people still play these games. My point was that most platforms had 3D by the end of XX century while Web needed another decade before it got it and, ironically enough, exactly when web finally, finally, arrived on that decade-old platform the rest of the world already moved and shifted to significantly different 3D API! When would web have things like Metal, Renderscript or Metal? My guess is: most likely answer is “never”—and if Android will, indeed, arrive on desktop even WebGL and WebRTC could become unavailable eventually (since people would use native apps instead of webapps for things like videocalls or maps)—although that is not guaranteed, freeze a-la SMTP is more likely.
Posted May 23, 2016 15:52 UTC (Mon)
by pizza (subscriber, #46)
[Link]
I think it's fair to say that GPGPU is only now becoming "usable" without relying on (highly) proprietary software stacks.
Posted May 24, 2016 22:43 UTC (Tue)
by flussence (guest, #85566)
[Link] (1 responses)
> things like Xeon Phi, it's used on your mobile phone
Posted May 25, 2016 1:24 UTC (Wed)
by nybble41 (subscriber, #55106)
[Link]
Indeed, a mobile phone with a 300W Xeon Phi processor would last about five seconds before either draining the battery or setting itself on fire, whichever comes first. Possibly both.
There should have been a closing parenthesis after "Phi". That was meant to be read as "GPGPU is used on your mobile phone".
Posted May 20, 2016 8:36 UTC (Fri)
by paulj (subscriber, #341)
[Link] (3 responses)
SMTP hasn't developed much because it's very mature, and basically does what's needed. The maturity of SMTP hasn't stopped development at higher layers above SMTP. Also, if you want to blame SMTP for identity and abuse issues, no one has solved those any better in any other protocol that couldn't also be applied to SMTP. SMTP is actually wildly successful, because it is "federated", distributed and decentralised.
Posted May 29, 2016 23:47 UTC (Sun)
by HelloWorld (guest, #56129)
[Link] (2 responses)
Posted May 30, 2016 1:17 UTC (Mon)
by Fowl (subscriber, #65667)
[Link]
Posted Feb 6, 2019 9:18 UTC (Wed)
by jond (subscriber, #37669)
[Link]
Posted May 24, 2016 7:35 UTC (Tue)
by micka (subscriber, #38720)
[Link]
The perils of federated protocols
The perils of federated protocols
They didn't start out large. The question you should be asking is how/why they became large, given their early disadvantages.
And that answer is ... federation.
The perils of federated protocols
The perils of federated protocols
The perils of federated protocols
The perils of federated protocols
The perils of federated protocols
Ten years later, still no sign of it ever becoming usable.
One day Vulkan might work, but I'm not holding my breath for it.
The perils of federated protocols
The perils of federated protocols
In the way VDPAU is today. Able to do more than run the demo/test code shipped with Mesa. Reducing power consumption by offloading work to an appropriate device instead of increasing it by being dead weight to compile.
I don't think my phone has a 300W processor (it seems to cope with image/photo editing fine regardless). Did you mean to say Someone Else's Computers? Those kind of services are best enjoyed as schadenfreude.
The perils of federated protocols
> I don't think my phone has a 300W processor
The perils of federated protocols
The perils of federated protocols
The perils of federated protocols
The perils of federated protocols
The perils of federated protocols