zzz61831

I'll give you a more regular story. Some time ago I thought I needed to take D3 supplements after being exposed to all this PR pushing it and given that I don't eat food rich in it, rarely get sunlight, don't go outside in daylight (densely populated area, supermarkets work 24/7, etc.). So I bought some and took 2000 IU/day for a few days. Suddenly I started feeling numbness on the tip of my toes. After a bit of research I attributed it to D3, immediately stopped taking it, but numbness went away only after a few weeks. It's hard to see how taking it longer could have been safe.

So please don't generalize that 2000 IU is safe just because something showed that it was for some people in certain circumstances given certain country-specific lifestyle, foods, etc. I don't think a decent study on D3 safety even exists.

Among various properly written and practical open source licenses Parity license is probably the most anti-capitalist one.

Here's how it could be done (very roughly):

When a client makes a modification, it creates an op representing that modification and includes a list of server identifiers to send the op to. Then queues the op. Once op is sent and ACKed by at least one of the servers the op is dropped from the queue.

Servers receiving the op synchronize the op with each other, ACKing each other and removing ACKed servers from the list. They also synchronize with the clients, sending the op to each client and asking clients to ACK to all servers. Obviously there are multiple ways to do it and it can be almost as efficient as theoretically possibly, but of course you can't avoid some metadata for each client associated with a particular document even though it doesn't have to be kept in server memory, it could be stored on disk.

> I'm talking about structures with semantic meaning.

Semantic meaning generally doesn't map to any data structure directly, CRDTs are not an exception here either.

I think you are not talking about CRDTs here. CRDTs are a pretty good fit for distributed systems that share state, which is what collaborative editing is underneath. It's just that semantically completely automatic conflict resolution is incompatible with human collaborative editing, which is pretty obvious, but for some reason plenty of research goes into trying to do just that.

That's not true, you don't need to keep them throughout the session. You can drop them as soon as you either synchronize with other clients or with the server, which can then synchronize with the clients, that's what conflict-free nature of CRDTs allows you to do. The only fundamental requirement is to keep track of changes when you are offline or out of sync until they are sent to others and even then you are supposed to merge those changes into fewer changes keeping disk and memory use down to a minimum.

> CRDTs were perfect for plain strings and arbitrary key/value pairs. But when it comes to schematic JSON that has semantic value CRDT was an added overhead.

Also not true. They were never perfect for plain strings, even incompatible semantically, but perfect for sets, counters, numbers, where basic commutative math is enough, a few other things and anything that combines those primitives into more complex ones, especially true for schematic structures, tables.

You should really try implementing CRDTs, especially OP-based, they change the way you think about keeping shared state in distributed systems.

> Since the software is primarily a cloud document editor, a central server is necessary even otherwise. So why not use the server for efficient version management and operation sequencing as well? Why chose CRDTs whose bulk of complexity comes from eliminating the need of a central system?

There is zero complexity in CRDTs that comes from eliminating the need of a central system, it's a completely different problem orthogonal to CRDTs. Central systems is where CRDTs are used the most actually.

I've used UPSes that discharge batteries no lower than 10.5 (no deep discharge) and only once in a couple of years and that charge them to and keep them at 13.6 volts under stable room temperature all year. All batteries lost most of the capacity after 3 years, two almost all of it, one had like 40% left. In five years only that one was still surviving short minutes outages, while initially was able to do a few hours. For comparison, I had one battery just laying around for 6 years in the same room without touching it and it lost only like 30%.

It's just that consumer home UPSes are almost scam level products designed to profit from naive people. They are both not improving things for an average user and killing batteries after like a year of operation (lead acid batteries can last for like a decade when not subjected to those UPS chargers).

Also if you have them on a tiny service it's likely an indication of poor user experience: poor user interfaces, poor performance, poor documentation, poor reliability, etc.