Correct, see the github mirror[1]. I don't know how well supported that feature is compared to main branch. If it was completely stable, then it would have already landed in the main stable branch. Clarity about the roadmap of that branch would be nice.
It may not be just about stability (in the sense of being free of defects) but also about whether they've decided to commit to maintaining it forever and supporting it in combination with whatever other features they intend to add to the main branch.
It does, but the map has a reference to it, so it will "leak" (in gc languages an unwanted reference is considered a leak). If this map got rather large, you could end up with a rather large heap and it would be un-obvious why at first.
gVisor is used in a lot of places[1] that require more performance than a clock. I'm not saying you can't achieve more performance with C++/rust, what I'm saying is that this probably isn't the primary concern.
Network performance in gvisor is awful and, by gvisor's own documentation, this is a matter of "implementation costs" ie: it is how gvisor is written, not gvisor's fundamental constructs, that makes it slow.
The rest of the benchmarks are notable as well, there are a few other places where the implementation is called out as being a problem.
So maybe they should team up and work on replacing gVisor with something that shares as much code as possible with this new thing, which one would hope would be architected in a way to be able to help replace gVisor?
Not everything needs to be molded into a common base that serves the needs of all. Fuchsia has different constraints than the ones gvisor is written for and choosing to not try to morph gvisor into something it doesn't want to be is okay. Optimizing to solve problems should be the goal. Sharing code is nice to have where it makes sense.
The context here was that gVisor was a suboptimal way to solve the problem and they know that... so I am not sure in what point you are trying to make by saying people can optimize to solve problems unless you actually mean people can optimize to not solve problems.
Yeah, of course: if you are the kind of company that like a having tens of thousands of engineers working on five different versions of the same thing, with one team explicitly working on solving a problem another team has but without helping them as that's some combination of not-fun and not-promotion-worthy, you can of course do whatever you want.
I don't want a yubikey either. Hardware products are notorious for being subverted by agencies, honest companies can be bought by agency shell companies, etc.
I find the recent push by big tech and others to discredit open software solutions like PGP suspicious. Banks push out new apps on a yearly basis, we are supposed to insert USB sticks to contribute to open source. Big tech rarely acts in your best interests.
Ignoring Postgres and comparing apples to apples, rqlite has limitations on "safe" SQL statements[1]. This might be a big deal breaker for you than it might for others. As dqlite replicates the pages and not the SQL statements over raft, which means dqlite doesn't have _that_ problem. Using random() and now() are classified as non-deterministic[2].
Using the application to send the time, although not idea could be used as a workaround, but attempting to use non-deterministic functions in triggers becomes a lot harder.
Yes, that's correct. rqlite does statement-based replication, which means it has the limitation you outlined. This could be solved by parsing the entire SQLite statement passed into rqlite before it's written to the Raft log, but I haven't got around to that yet.
It depends what you call a deal. Are they new trade deals from scratch, absolutely not. Are they trade deals that have been copied from the EU trade deals to satisfy ongoing deals ("rollover" deals), yes they are. Are we getting the trade deals that Boris promised, absolutely not.
1. https://github.com/adobe/avmplus