|
|
Subscribe / Log in / New account

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.


to post comments

The perils of federated protocols

Posted May 19, 2016 12:09 UTC (Thu) by pizza (subscriber, #46) [Link] (1 responses)

> Internet and web have won not because they were federated, but because they were large: they just had more users than AOL or CompuServe.

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

Posted May 19, 2016 18:11 UTC (Thu) by khim (subscriber, #9252) [Link]

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.

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.

The perils of federated protocols

Posted May 20, 2016 8:28 UTC (Fri) by niner (subscriber, #26151) [Link] (7 responses)

Odd, I cann use WebGL, WebRTC and HTTP/2 just fine while I can use neither Metal nor Vulkan right now. Your examples seem to express the opposite of what you intended.

The perils of federated protocols

Posted May 22, 2016 16:54 UTC (Sun) by jospoortvliet (guest, #33164) [Link] (6 responses)

I guess the point parent wanted to make is that while webGL, WEBRTC etc are already very old they still don't work everywhere while Vulkan, not more than a year old, is announced to be supported almost everywhere. I agree with you that doesn't mean it IS. Time will tell if it will go as expected...

The perils of federated protocols

Posted May 22, 2016 17:35 UTC (Sun) by flussence (guest, #85566) [Link] (5 responses)

I remember all the hand-wavy hype about GPGPU and OpenCL when AMD opened up all the R600 hardware docs. 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

Posted May 22, 2016 19:34 UTC (Sun) by mathstuf (subscriber, #69389) [Link]

I've done some OpenCL on R600 hardware. It works, but is not complete by any means. This was probably 2.5-3 years ago now.

The perils of federated protocols

Posted May 23, 2016 14:16 UTC (Mon) by khim (subscriber, #9252) [Link] (3 responses)

Ten years later, still no sign of it ever becoming usable.

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.

One day Vulkan might work, but I'm not holding my breath for it.

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.

The perils of federated protocols

Posted May 23, 2016 15:52 UTC (Mon) by pizza (subscriber, #46) [Link]

> 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.

I think it's fair to say that GPGPU is only now becoming "usable" without relying on (highly) proprietary software stacks.

The perils of federated protocols

Posted May 24, 2016 22:43 UTC (Tue) by flussence (guest, #85566) [Link] (1 responses)

> Define “usable”, please.
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.

> things like Xeon Phi, it's used on your mobile phone
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

Posted May 25, 2016 1:24 UTC (Wed) by nybble41 (subscriber, #55106) [Link]

>> things like Xeon Phi, it's used on your mobile phone
> I don't think my phone has a 300W processor

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".

The perils of federated protocols

Posted May 20, 2016 8:36 UTC (Fri) by paulj (subscriber, #341) [Link] (3 responses)

IPv6 was slow to be rolled out not because of federation, but because of second-system-syndrome effects that led IPv6 designers to ignore backward compatibility.

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.

The perils of federated protocols

Posted May 29, 2016 23:47 UTC (Sun) by HelloWorld (guest, #56129) [Link] (2 responses)

So how come I *never* get any spam on WhatsApp and dozens to hundreds of spam emails every day?

The perils of federated protocols

Posted May 30, 2016 1:17 UTC (Mon) by Fowl (subscriber, #65667) [Link]

WhatsApp spam exists. (I've received it)

The perils of federated protocols

Posted Feb 6, 2019 9:18 UTC (Wed) by jond (subscriber, #37669) [Link]

Is that figure the spam you receive after filtering, or before?

The perils of federated protocols

Posted May 24, 2016 7:35 UTC (Tue) by micka (subscriber, #38720) [Link]

I wonder how you define the federatesd/centralized aspect when writing about graphical API that are purely local. Unless you're thinking about something like rendering distributed on multiple computers? I don't think metal/vulkan does that.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds