> So please don't interpret this story as a reason to avoid any vitamin D supplementation. 1-2000 IU/day has been shown to be safe with long term use
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.
No offense, but this sounds like a bad diagnosis on your part. It takes more than a few days for Vitamin D problems to arise. The fact that the numbness took a few weeks to go away after taking Vitamin D for only a couple of days means it was most probably some other thing causing the problem.
It took a few weeks to go away completely, but got noticeably better just after a couple of days. I'm pretty confident in that diagnosis, as nothing else have changed.
Sort of, there is pseudoanonimity layer in Telegram that doesn't show your phone number to others, so if you can be reasonably sure that Telegram isn't going to give you up to the police of your country - your privacy can be preserved. While Signal literally identifies contacts via phone numbers and there is no mass communication features anyway, so it's both less private and less useful for such purposes.
Their crypto is state of the art, but their ops sec threat model does not include “we’ll torture you or go to your mobile operator and their would cooperate fully”. So signal is good for USA, not so good for 3rd world countries. This people making decisions in Signal live in a different world then most of the people who need secure comms. Well telegram have us covered. Sadly, if you stop trusting Durov - you are screwed. Signal is much better in that regard.
Because Telegram uses phone's contact list for contact discovery. There's nothing unusual about this. This how Signal, Riot, Threema, Wire and dozens and dozens of messengers work.
Maybe GPL started as an anti-capitalist license, but in practice it became very much pro-capitalist. It got to the point that GPLv3 and AGPLv3 were split into two licenses to satisfy capitalists.
Among various properly written and practical open source licenses Parity license is probably the most anti-capitalist one.
> it's because CRDT merges aren't a good fit for the problems a code editor is trying to solve
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.
I was trying to use a CRDT to share state between the GUI editor and the language server process. My attempt didn't work well, for reasons I've written about. I have no doubt it can be made to work, and the research towards that might be interesting.
> Memory issues with tombstones. Marking as deletion has a cost of maintaining them throughout the session.
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.
> You can drop them as soon as you either synchronize with other clients or with the server
Say 100 nodes edit a doc. To drop a tombstone, without a central server we need 99 acks. Even with a server, the server keeps an ever-growing list of ops unless it uses some garbage collection techniques. And as stated by OP those techniques have their own problems. Remember, OP relies on V8's hidden classes for deriving an optimal representation without eliminating tombstones. Servers though need not necessarily hold CRDTs in JS. It might be a different VM altogether.
> anything that combines those primitives into more complex ones, especially true for schematic structures, tables.
I'm not implying CRDTs are only for simple structures. Automerge has support for tables too. I'm talking about structures with semantic meaning. In database tables the ops are always inserting/delete columns/rows and updating cells. In HTML tables, it extends into cell-merging, cell-splitting, inner tables and all sorts of valid operations. Merging these operations without inspecting the op and writing a custom modifier - will certainly end up in an invalid table structure.
> Central systems is where CRDTs are used the most actually.
I'm assuming the central system referred here is the database resilience systems using CRDTs to merge. Database syncing without master/slave is exactly the kind of problem best solved with CRDTs. The very point is to eliminate the need for a central point of failure.
OT comes with very different problems when it comes to representing tables. Structured content (tables, tables containing tables, tables containing quotes containing tables, ..) is much better represented using CRDTs.
And another note, Yjs completely supports the OT rich-text type (i.e. delta format [1]). This is how the Quill editor was made collaborative.
So Yjs is at least as powerful as OT. If you want, you can still base your application around OT deltas, but Yjs is IMO much easier to use.
> Say 100 nodes edit a doc. To drop a tombstone, without a central server we need 99 acks. Even with a server, the server keeps an ever-growing list of ops unless it uses some garbage collection techniques. And as stated by OP those techniques have their own problems.
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.
> Then queues the op. Once op is sent and ACKed by at least one of the servers the op is dropped from the queue.
Unfortunately, it's a lot more complicated than this.
First, you can't wait until just one peer has ACKed -- you need to wait until all of them have. Any peer that hasn't ACKed could still send an op based on the one you want to delete, and then you wouldn't have enough information to merge the new op.
Second, you can't just wait until all peers have ACKed an op, you need to wait until no new ops depend on that op. An op could depend on an op even though it has been ACKed by everyone.
Third, a peer could go offline for a while, and then come back online. But if you are waiting for all peers to ACK an op, you might never get a situation where all peers are online at the same time.
20 years ago we already knew that internet was too architecturally broken to be free as that was around the time early attempts of censorship resistance were born, like Freenet [1].
It was hard to jam radio transmissions in the past, but these days it's common. Russia did that to Ukrainian channels in Crimea and Donbass and Belarus has access to the same Russian technology.
They were not, but since the polls were banned during elections the government at least had some deniability and fewer people were convinced it was all fake. But this time massive protests and polls and information online convinced everyone there is no real support left. Hence the shutdown of the internet.
Deep discharge is a factor, but not a big one, heat has very little effect, it only affects voltages at which battery will be considered overcharged or deeply discharged as specs are usually all for room temperature.
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 turns out that APC intentionally overcharges the batteries to maximize runtime during the 2-year target battery lifetime, at the cost of killing the batteries relatively young. And the overcharged voltage drifts upwards over time.
You can put your equipment on a voltage relay to make failure modes as simple as flipping a circuit breaker. It will turn off once voltage drops too much and will wait for it to stabilize for specified amount of time to turn it on.
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.