Not Quite So Broken | Hacker News Reader

Not Quite So Broken

nqsb.io

71 pointsaburan2814 comments

I like the idea, but why do software types seem to be so allergic to state machines?

State machines have well-defined semantics, can be visualized nicely, implemented in a straightforward manner, and tested against specification.

The only thing that I would point out to people is that "time" is an input to your state machine. That's single change makes most state machines deterministic in software.

I don't think they all are. Basically every project I write for work seems to wind up having at least one state-machine in it.

I wonder if it's a domain-related thing. I got into software from hardware.

I don't know. TCP has a nice well-defined state machine, but otherwise people don't seem to be in the habit of thinking that way. And the tools don't point people in that direction. Maybe it's associated with the UML fiasco?

I suspect a lot of things like SSL have really complicated state machines that are hard to visualise. Perhaps that should count more heavily against their design.

> TCP has a nice well-defined state machine

I can't remember where, but I recently read that the TCP state machine in e.g. the Linux kernel is significantly more complex than any you'll find in any TCP RFC

I just took the leap this weekend from designing state machines on paper, mentally reasoning through them, and hoping I got it right, to doing verification on them using TLA+. Lamport’s video series is really awesome, and the process really helped me nail down all the edge cases. I did it in a somewhat literate programming style too, and the output PDF is a beautiful spec that should be straightforward to implement in C (it’s for an embedded device that’s going to be installed in remote locations... knowing that the spec of the FSM can’t deadlock is delightful!)

I can't speak for the developers, but I don't think it's so much that they don't like state machines, more that complex state machines make it hard to reason about the protocol, and it seems really hard in practice to get many people to independently implement complex state machines uniformly.

RNG state is another usually non-deterministic input, but you are correct. This implementation takes time as input, and allows the manual passing of RNG state, but defaults to maintaining internal RNG state to make it halfway-nice to actually use. There's a trade-off between maintaining purity, and the complexity you impose on the users of the API. I think they made a good call in this case.

I don't see any GCM ciphers nor ECDHE/DHE key exchanges deployed on this site, so forward secrecy and authenticated encryption are not implemented and supported by the Not Quite So Broken toolchain? It would be a project of great value if those are implemented, plain RSA and CBC is pretty much dead in TLS nowadays...

- "(ECB/CBC/CCM/CTR/GCM)" -> GCM is implemented in the nocrypto library.

- TLSv1.2 and thus GCM and DHE are supported (and default).

- TLSv1.3 is in the works as we speak (which implies ECDHE), check back in a few months.

Shame this fully text site doesn’t support reader mode on mobile. Is there some bookmarklet or something that people like to allow it on sites that otherwise do not support it?

You could try outline.com: https://outline.com/SsnxnL

Reader mode works on my iPad.

Interesting! Seems like Firefox is the one at fault here. Opening in Safari showed a reader mode option.

The html is nice and light (I had a look bc I appreciate sites with zero bloat). The problem is with the reader that can't cope with:

body > div class="content"

Reply on news.ycombinator.com