[hackuser]

> large parts of the GNU/Linux community are just irrational idealists hard to work with. ... Linus always said: He cares about the code back and otherwise not what vendors do with it.

I imagine they were called "irrational" when they started the FOSS movement and created the licenses and other tools that are part of it. Yet look what they built and what has been built on top of it. Now it's cool for people who benefit enormously from it, including Linus Torvalds, to disparage it. It's all lefty, hippy 'idealism' after all - if you ignore the enormous practical results.

What foundation are we building for the next generation of engineers and tinkerers? Spying and tracking systems? Closed proprietary silos (like smartphones and web applications)? HTTP/2 and systemd - which may be technically great, but don't provide that same freedom-to-tinker for future hackers.

[ianlevesque]

HTTP/2 really doesn't belong in that basket. One of these things is not like the others.

[hackuser]

I really haven't dealt with HTTP/2 so perhaps I misunderstand: Doesn't it replace hacker-friendly (and flexible) plain text with a binary code?

I'm not saying the trade-off is bad or good, but there is a cost; it's not free.

[jcranmer]

Plain text protocols suck. They give you the illusion of readability, and they can make what looks like the obvious solution turn out to be bug-ridden and rife with security holes. The readability is overrated--even in protocols like XML or JSON, most of the time I need to filter down to a small subset anyways, which requires me to write some sort of tool. And if you're already using a tool for all of your poking, what's the benefit to the input format? A good tag/length/value format (particularly when the tag implies how to interpret the value without needing to know a grammar, sorry ASN.1) is even easier to decode than a CRLF-based protocol, since you don't worry about things like "how long could this line be" or "does a bare LF count as a CRLF? What do I need to do for compatibility?"

[pdkl95]

Plain text protocols help keep interoperability honest and open. They also have benefits that are often overlooked, such as more easily avoiding integer overflow and endian issues.

> If you're already using a tool

Often, I'm not.

> illusion of readability

That depends entirely on the protocol design; some are better than others. Binary protocol can also be a mess. More importantly, binary protocols will always require external definitions, while some text protocols do not.

> bug-ridden and rife with security holes

Changing from readable tokens and ASCIIified intege4rs to packed binary doesn't magically fix bus or security holes.

> what do I need to do for compatibility

That's easy: use the robustness principle[1].

(and most RFC-based protocols say you should send a CRLF).

A possible argument against this could...

> how long could this line be

...also be an argument against length fields. If you want reliable parsing - a very good idea - a good argument[2] can be made to only use context-free protocols (i.e. use parser-combinators).

[1] https://en.wikipedia.org/wiki/Robustness_principle

[2] https://media.ccc.de/v/28c3-4763-en-the_science_of_insecurit...

[oldmanjay]

To anyone who takes your advice on the robustness principle, don't. Liberal acceptance is a maintenance and security nightmare. Be strict on all boundaries and provide clear errors.

[pdkl95]

The robustness principle is fine, but it does need to be strictly interpreted, which I should have mentioned. Too often robustness is used as a license to be sloppy or to abuse lenient parsers with invalid input.

Meredith covers this specific issue at 33:25 in her 28c3 talk I referenced ([2]). "Be definite in what you accept" can emulate traditional "liberal" parsers if the compatibility is strictly defined in the grammar.

I really should have phrased that better; the robustness principle is great historically, and is therefor necessary in many current protocols, but newer protocols should be using well-defined either regular grammars or deterministic context-free grammars. As Meredith and Sergey explain in that talk, moving away form Turing complete protocols would prevent an important class of exploits.

[ltp]

> Plain text protocols suck. They give you the illusion of readability...

They don't, and the readability is a feature.

I'm not sure how you conflate XML and JSON as synonymous to "protocol" and also requiring tools to filter, but than imply that a "good tag/length/value" format would somehow be superior to the former.

[marcosdumay]

Exactly what feature binary protocols can have that make protocols less bug ridden and with less security holes?

Because, well except for readability and ease of debug, that you lose completely by going binary, and message size that improves by going binary, I can't find any other difference.

[hackuser]

> Plain text protocols suck

An honest question: Is it possible that they suck for you and people like you, skilled, experienced engineers with sophisticated tools, and with much less time than money - but they don't suck for less experienced, less equipped, hackers or tinkerers with time to try things but little money or expertise?

Remember that those people built quite a few things, from Facebook to Napster to Dell to the web browser to the web itself (just off the top of my head). Empowering them is arguably the key to innovation.

[lstamour]

Last I checked, ASCII is an encoding, and was transmitted in packets, so if you're relying on tools to decode and unpack your messages, why not simply upgrade them?

Also, people don't seem to complain about the cost of HTTP over SSL in these discussions on HTTP/2. I've never understood that. If you're allowing for TLS, why not HTTP/2?

[stonogo]

Because TLS works with many protocols. Encryption software is hard to write and should be reusable for multiple services; the world is not the web.

[hackuser]

> ASCII is an encoding, and was transmitted in packets, so if you're relying on tools to decode and unpack your messages, why not simply upgrade them?

ASCII has a much lower barrier to entry. By the same reasoning, everything is 1's and 0's so everything is the same - just use better tools.