What is that first paragraph? "This implementation proves the CAP theorem as wrong"? Doesn't tell me what your drawbacks are. This is mongodb all over again. Will only ever consider if the customer really wants it. (My guess performance)
(Also, bold move to write a db without fully being able to manage memory).
I do want to clarify a few points, on the project page it does provide the following information:
> Distributed Transactions: TiDB uses a two-phase commit protocol to ensure ACID compliance, providing strong consistency. Transactions span multiple nodes, and TiDB's distributed nature ensures data correctness even in the presence of network partitions or node failures.
> High Availability: Built-in Raft consensus protocol ensures reliability and automated failover. Data is stored in multiple replicas, and transactions are committed only after writing to the majority of replicas, guaranteeing strong consistency and availability, even if some replicas fail. Geographic placement of replicas can be configured for different disaster tolerance levels.
I can't find that first paragraph, and it seems that readme file was last modified 3 months ago, though you're using quotes, so perhaps you are paraphrasing?
The first paragraph I find under Key Features is:
Distributed Transactions: TiDB uses a two-phase commit protocol to ensure ACID compliance, providing strong consistency. Transactions span multiple nodes, and TiDB's distributed nature ensures data correctness even in the presence of network partitions or node failures.
It claims to ensure correctness in the presence of partitions, not availability, so I don't think that's a claim that CAP is wrong? I would expect it to be unavailable if it can't provide a consistent response.
I don't know about memory management. It seems go may not be used for the storage layer, but in any case, it wouldn't be the first attempt at a DB on a garbage collected runtime. I can think of at least Cassandra on the jvm and CockroachDB also on Go. I do prefer that DBs do their own memory management (as well as storage) but this is not as unique as it used to be though.
I don't get those dotfile managers. I just have a git repo with a branch for every machine. And my dotfiles are in many formats, not just yaml toml and JSON...
Are your per-machine branches mostly distinct, or do they share a lot?
I use https://github.com/thoughtbot/rcm and I find my dotfiles share _quite a bit_ in some respects (e.g. neovim config) but are drastically different in others (SSH config as one example) -- keeping things synced _across_ branches sounds very difficult. rcm handles this well, without branches, IMO.
I also don't get these, but for another reason: why write a dotfiles-specific configuration management tool with templating, conditions and all of that when we already have proper SCMs like salt or ansible that perfectly scale down to a single user and a small number of configs, but are still orders of magnitude more powerful when you need it.
I will do a lot of work to avoid having to touch ansible and friends. Fortunately, I don't have to do a lot of work because I spent 10 minutes writing a 50 line Go program a decade ago that has done everything I've needed it to do in the interim (IIRC the only change I made to it was supporting Go modules back in ~2015).
(Also, bold move to write a db without fully being able to manage memory).
reply