The perils of federated protocols

Posted May 20, 2016 18:03 UTC (Fri) by Cyberax (✭ supporter ✭, #52523)
In reply to: The perils of federated protocols by aemerson
Parent article: The perils of federated protocols

> And federated protocols CAN do that. Developers can remove support for old, insecure fallbacks.
No, they can not. Clients _can_ remove support for _some_ bad fallbacks, after years of gradual deployment. Servers are usually stuck pretty much for a decade (e.g.: SSLv3 deprecation).

So if in your book a decade to make a change is quick, then I don't want to know what is "slow".

> If I want to make Signal the input or output to a complex pipeline, say filtering piles of messages into interesting places, using some to update displays on my desktop and queueing up some for later examination, extracting information from others, populating an Org mode document with times I plan to meet people, can I? No?
You can, nobody stop you personally. However, you should be prepared for your scripts to break at any moment if Signal makes an incompatible change.

That might be OK for a homegrown project that nobody cares about, but if you try that with actual real-life users who depend on your tools...

The perils of federated protocols

Posted May 26, 2016 5:58 UTC (Thu) by madhatter (subscriber, #4665) [Link] (4 responses)

> Clients _can_ remove support for _some_ bad fallbacks, after years of gradual deployment. Servers are usually stuck pretty
> much for a decade (e.g.: SSLv3 deprecation).

# rcsdiff -r1.45 /etc/httpd/conf/httpd.conf
1113a1114
> SSLProtocol All -SSLv2 -SSLv3

I'd have the check my daybook to be sure, but my memory is that it took me less than a decade to type and commit the above change.

The perils of federated protocols

Posted May 26, 2016 6:02 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

> I'd have the check my daybook to be sure, but my memory is that it took me less than a decade to type and commit the above change.
Duh. You probably don't have an expensive middlebox in front of your server doing load balancing.

The perils of federated protocols

Posted May 26, 2016 6:35 UTC (Thu) by madhatter (subscriber, #4665) [Link]

I agree that code that's baked into firmware (especially on platforms that are infrequently upgraded by the manufacturer) is much harder to upgrade than code that's deployed in software, but that's equally true on client (eg, think weird android-esque tablets) as on server platforms. That's a pretty good argument for using general-purpose computing platforms for as much as possible, but I'm not sure it argues specifically against servers.

The perils of federated protocols

Posted May 26, 2016 8:18 UTC (Thu) by chojrak11 (guest, #52056) [Link] (1 responses)

> my memory is that it took me less than a decade to type and commit the above change.
Said last person in the world still using RCS routinely...

The perils of federated protocols

Posted May 26, 2016 8:24 UTC (Thu) by madhatter (subscriber, #4665) [Link]

We could certainly have a discussion about the pros and cons of localised-lightweight vs centralised-heavyweight source control, and it might even be interesting, but here is probably not the right place to do it. If you think that my choice of source-control applications has any bearing on my underlying argument, please feel free to argue your case. Do, however, bear in mind Pirsig's dictum that "the world's biggest fool can say the sun is shining, but that doesn't make it dark out".