7 ms·

> 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

> 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 11y ago
HTTP/2 really doesn't belong in that basket. One of these things is not like the others.
- hackuser 11y ago
  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.
  - lstamour 11y ago
    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 11y ago
      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 11y ago
      > 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.
  - jcranmer 11y ago
    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 11y ago
      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 https://en.wikipedia.org/wiki/Robustness_principle [2] https://media.ccc.de/v/28c3-4763-en-the_science_of_insecurity https://media.ccc.de/v/28c3-4763-en-the_science_of_insecurit...
      - oldmanjay 11y ago
        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.

ianlevesque 11y ago

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

hackuser 11y ago
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.
- lstamour 11y ago
  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 11y ago
    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 11y ago
    > 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.
- jcranmer 11y ago
  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 11y ago
    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 https://en.wikipedia.org/wiki/Robustness_principle [2] https://media.ccc.de/v/28c3-4763-en-the_science_of_insecurity https://media.ccc.de/v/28c3-4763-en-the_science_of_insecurit...
    - oldmanjay 11y ago
      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.