Readit News(This isn't the theoretical ivory tower kind of UB. Operating systems regularly remap a page that hasn't yet been written to.)
Looking at freebsd.org right now I see that my options for production, release systems are 12.3 and 13.0 ...
... which means that if 12.1-RELEASE came out at the end of 2019 and 13.0-RELEASE came out in April of 2021, you had all of 16 months to make investments in the 12 branch before it was hopelessly passe and all queries regarding it would be answered with:
"That's fixed in current ..."
The 4.x nostalgia is justified: it was polished and polished and polished over many years and many organizations were incentivized to invest in that branch
I'm curious: Why _shouldn't_ it be an OS primarily for its developers? Why should they focus on others when they're the one building it?
Ie, if I wanted an enum of either a string or an integer, it becomes "Either<&str, i64>".
But what I wanted is that it's either a string identifier or the database Id of something to be later referenced, which might be better described as "enum IdentOrDbId { Ident(String), DbId(i64) }".
This is of course a much simplified example of things I've faced.
fn some_func() -> impl SomeTrait {
if some_condition {
Either::Left(a)
} else {
Either::Right(b)
}
}
I think many of us are feeling these days that the rust standard library might already be too large and it's better to be very conservative adding stuff there or only after an extended period of time of independent vetting. I have yet to not experience that standard libraries turn into very stale and outdated things relatively quickly that carries an enormous maintenance burden.
In most GCed languages it wouldn't matter so much because you'd return a boxed `Iterator` or `Future` or what have you. But in Rust you generally want to avoid the allocation.
> If you look at _Lamport's paxos proofs_ he treats an accept as a promise... But this is not pointed out in _Paxos Made Simple_. In fact, it appears Lamport took great pains to specify that an accept was not a promise.
> The problem is when you combine the weaker portions of both variants; as the OP did and several implementations do. Then you run into this catastrophic bug.
That is, Lamport's proofs and Paxos Made Simple contradict each other ever so slightly to trip everyone all at the same time:
> What's more I looked through several proprietary and open-source paxos implementations and they all had the bug submitted by the OP!
https://stackoverflow.com/questions/29880949/contradiction-i...
Lamport himself acknowledges as much: https://www.youtube.com/watch?t=4398&v=8-Bc5Lqgx_c
The state after step 9 should be the same as after step 7, i.e. `A(-:-,100) B(100:b,100) C(100:b,-)` because C needs to retain the "highest-numbered proposal" it accepted, not the one it accepted last. That means the nine steps outlined in the post/on StackOverflow do not, by themselves, demonstrate any problem.
So what additional steps are missing/what alternative steps actually produce an inconsistency/divergence?
> (b) If an acceptor receives a prepare request with number n greater than that of any prepare request to which it has already responded, then it responds to the request with a promise not to accept any more proposals numbered less than n and with the highest-numbered proposal (if any) that it has accepted.
It says an acceptor must respond with the highest-numbered proposal (if any) that it has accepted.
How is acceptor C going to do that after step 9? That's where the bug is introduced, I think, not anywhere in the paper.
[1]: https://twitter.com/ryan_levick/status/1443202538099073027
I'm using DST in a personal project. My biggest issue is that significant parts of the ecosystem either require or prefer your runtime to be tokio. To deal with that, I re-implemented most of tokio's API on top of my DST runtime. Running my DST tests involves patching dependencies which can get messy.