If that's all the issues there are with the dataset, it is probably far and away the best dataset any researcher has ever used.

Does RAMP or CURE offer any possibility of conditional writes with CRDTs? I have had these papers on my list to read for months, specifically wondering if it could be applied to Garage

https://dd.thekkedam.org/assets/documents/publications/Repor... http://www.bailis.org/papers/ramp-sigmod2014.pdf

I had a very rapid look at these two papers, it looks like none of them allow the implementation of compare-and-swap, which is required for if-match / if-none-match support. They have a weaker definition of a "transaction". Which is to be expected as they only implement causal consistency at best and not consensus, whereas consensus is required for compare-and-swap.

ack - makes sense, thank you for looking!

When I was there, DigitalOcean was writing a complete replacement for the Ceph S3 gateway because its performance under high concurrency was awful.

They just completely swapped out the whole service from the stack and wrote one in Go because of how much better the concurrency management was, and Ceph's team and codebase C++ was too resistant to change.

Unrelated, but one of the more annoying aspects of whatever software they use now is lack of IPv6 for the CDN layer of DigitalOcean Spaces. It means I need to proxy requests myself. :(

Could you use something like Fly's Corrosion to shard and distribute the SQLite data? It uses a CRDT reconciliation, which is familiar for Garage.

Garage already shards data by itself if you add more nodes, and it is indeed a viable path to increasing throughput.

I would say if you're going to charge a pretty penny for the box, you have to make it ridiculously seamless to run every app the way a user wants, without issue.

TrueNAS sort of half-accomplishes this but as soon as you have to start configuring Redis and Postgres parameters to install Immich or understanding how to set permission on every layer of the filesystem so you can SMB share, the idea of a normal person being able to do this goes completely out the window.

My advice is to go ahead and just open-source everything. You won't on being closed-source anyway. You'll win on the experience for nontechnical users (or tehcnical users that don't want to spend time fiddling). You'll stomp out these complaints on Reddit and HackerNews so people don't get a bunch of negative comments when they google your company.

Kagi's Orion browser is 1.0 on Mac and working on the first full Linux release - it's built on WebKit. That WebKit is a "third party" dependency but it's still a break from the browser monoculture and it doesn't seem like Mozilla has as much interest in pushing the browser engine space forward after pulling back from Servo.

> The latter is what my Copilot suggested when I addressed complaints about higher gas prices

I would suspect this is because it is most mainstream recommendation from economists on how to disincentivize fossil usage without destroying your society & economic stability in the interim. Not because it's "lefty".

The yellow vest protests in France were basically what happens when you try to do A without also doing B.

Well it only needs to be Kafka-compatible, so personally I hope that things like RedPanda will turn out to be easier to run for this use case than actual Kafka.

Having an S3-compatible store was already a fairly heavy dependency in terms of something to run correctly in production, it's just that most people don't even consider running their own object store at any real scale, they just go to cloud. Whereas running your own Kafka is something more platform teams are already attempting.

Google was unable or unwilling to fight people gaming their SEO to float garbage and blogspam to the top results, waay before these more specific policy change events that have been reported w.r.t intentionally making search worse.

The world of Auth has been made miserable with everything having to support OAuth2/LDAP/SSO/SAML etc., plus a million versions of access control, session configs, yadda yadda. Each of these has their own (usually legitimate) purpose, but also each one has to integrate with other providers that each don't follow and/or extend the spec in their own special way. And the pain goes on and on.

Obviously you can make a product that only does really good username/password auth for example, but there's always more pressure to implement more things for another use case.

Another problem is also that "standards" like OAuth2/OIDC are used for a thousand use cases that weren't intended by the authors, so people get really creative with them. Plus the spec itself is vague on many essential things, for example how logout should work. Thankfully I never had to implement SAML but I would guess it's even worse there...