int08h

This is more a hybrid "physicist writes a cryptography/graph-theory paper".

This paper takes secret sharing as a black box and asks the question: once you have your N shares, where on a network should you put them?

The author's claim is that placement is a first-class security parameter, not an implementation detail, because both recoverability and exposure depend on the topology of who holds what.

It's not a cryptography paper, the threat model is very weak by cryptographic standards — e.g. random compromise rather than adaptive or targeted adversaries, no correlation between hacking a vertex and its neighbors (the author flags this extension as realistic but out of scope), and only N-of-N (not M-of-N as one might expect) reconstruction.

I read it as a foundational framing paper that connects share placement to network reliability theory and statistical physics.

Right, I understand your meaning better.

I agree with you: no matter how good of a job the code (by construction or types or otherwise) does of “making unsafe states unrepresentable”, that in no way makes a real world complex system “safe” by itself.

Code can be structured so that valves may only be open OR closed, but nothing stops the real world from returning a sensor reading that says “the valve is <undefined>”. To remain a “safe” system, the system must deal with inconsistent states like “heisen-valves”.

Hmm, it seems you actually agree with the OP:

OP says (your quote):

> [Most production incidents] are due to the code entering a state that should never have been possible.

You say:

> [...] it is more true that most production incidents are due to the system entering into one of thousands of unsafe states which were possible and latent in production potentially for years

I see you both agree that a broken system enters an "unsafe state" (your words) or a "state that should never have been possible" (OP's words).

"Unsafe state" and "state that should not have been possible" are, in practice in a real system, the same practical thing. I suspect you both would agree "system confuses a string for an integer and acts based on erroneous value" or "system acts on internal state that indicates the valve is both open and closed" would be states that a system should not be in. Outside pedantry, your descriptions are practically synonymous with each other.

I've released version 2.0 of roughenough, a Rust implementation of the draft IETF Roughtime protocol (https://datatracker.ietf.org/doc/draft-ietf-ntp-roughtime/). The Roughtime protocol provides cryptographic secure time synchronization with detection of server malfeasance.

Release 2.0.x of roughenough is a rewrite of the implementation to be simpler, more comprehensive, and more performant. The repo has multiple crates that implement:

  * Performance-oriented async UDP server
  * Command-line client with multiple output formats
  * Multiple backends for secure key management for the server
  * Clients can (optionally) report malfeasance to a remote server for analysis

> In that sense, Rust enables escapism: When writing Rust, you get to solve lots of 'problems' - not real problems, mind you, but fun problems.

If this is true for Rust, it's 10x more true for C++!

Lifetime issues are puzzles, yes, but boring and irritating ones.

But in C++? Select an appetizer, entree, and desert (w/ bottomless breadsticks) from the Menu of Meta Programming. An endless festival of computer science sideshows living _in the language itself_ that juices the dopamine reward of figuring out a clever way of doing something.

Yes, the (IMHO) the easiest one to use is the Relacy Race Detector (https://github.com/dvyukov/relacy and https://www.1024cores.net/home/relacy-race-detector)

It's been around a while and is easy to work with. Written by Dmitry Vyukov, an expert in the concurrency world.

Related: the notion of "safety" (refusing to discuss "harmful" content) is rather shallow and (relatively) easily undone: _Refusal in Language Models Is Mediated by a Single Direction_ [https://arxiv.org/abs//2406.11717]

Sit in a Compare-and-Swap loop on `ping` and `pong` as uint32s. Go even faster in the shared memory case. Zoom zoom.

The average duration between any two moon phases is 29.530589 days.

Many watches use 29.5 days between phases for simplicity. This results in the watch's moon phase display being off by one day for every two years the watch operates.

There are a few watch manufacturers that use epicyclic gear trains to make the moon phase calculation more precise. An example: the Ochs und Junior moon phase watch will operate for 3,478.27 years before its moon phase display is off by one day (https://www.ochsundjunior.swiss/watches/moon-phase/).

Dmitry Vyukov has forgotten more about non-blocking synchronization (lock- and wait-free algorithms) that most developers presently remember.

Re: getting tooling "right" and that driving adoption/popularity.

I'll argue that Java and the JVM are very similar in this respect. Few will argue Java is a "good" language and the JVM has many shortcomings.

However the ecosystem of IDEs, JVM tools, and decades of big company investment (Sun, IBM, Oracle) have created an amazingly productive environment.

Only looked at link [2], but wow. That state machine is brilliant.

Don't know OCaml but am learning Rust and I see what you mean about the universality of how types make this possible.

Thanks for pointing this out.

Thank you.

I was typing up a response, but yours is great. You nailed it.

The only thing to add is that a tlsdate-like approach will not work consistently with TLS 1.3 as the standard makes time in the handshake OPTIONAL.