lima

There's a different, open source Jujutsu extension as well: https://github.com/keanemind/jjk

Modern EVs with thermal management simply haven't been around for long enough for a significant quantity to reach 1 million miles, especially those with LFP cells.

There are some taxis and limo service Teslas that famously did make it to 300-400k+ miles on their original pack.

The technology exists, CATL is offering a million-mile/15 year warranty for some of their packs: https://chargedevs.com/newswire/catl-warrants-its-new-ev-bat...

It's a solved problem. When you consider TCO, EVs win even if the battery needs replacement.

First of all, as your article shows, batteries rarely need replacement at all, even at very high mileage. And those are old vehicles, battery management and cell chemistry are much better now.

And when they do, it's usually just a few cells that need replacing. In Europe, there are specialized third party repair shops that can do it a fraction of the cost of a new battery: https://www.smart-emotion.de/article/431-cell-replacement-at...

Lots of real world data shows that the TCO of EVs is much lower - fewer moving parts, less complexity, less maintenance.

And even those those ancient luxury cars can often be repaired by a third-party shop like EVClinic.

There aren't many 10+ year old EVs yet, and demand is limited. This is changing, and EVClinic will be the first of many aftermarket EV repair shops.

Battery swapping is a dead technology, it is simply not economical. It is too expensive, much harder to scale and incompatible with cell-to-chassis designs. Industry barely managed to agree on a charging connector!

Meanwhile, battery longevity is essentially a solved problem. Manufacturers do have an incentive to improve it due to customer demand, and modern NMC chemistry, cooling and BMS have improved significantly to the point where they're expected to maintain 70-85% capacity after 10 years[1], far from worthless. At this point, components like the motor likely fail before the battery does.

Given the much lower failure rate of everything else in an EV, TCO is dramatically better than ICE cars even with degradation[3].

Manufacturers like Mercedes even guarantee 70% health after 8 years (a worst-case estimate).

There is a significant commercial incentive for aftermarket battery repair shops. EVClinic[2] is very successful and a glimpse into the future.

[1]: https://www.geotab.com/blog/ev-battery-health/

[2]: https://evclinic.eu/

[3]: https://evclinic.eu/2025/12/31/diesel-mythology-vs-ev-realit...

The minimum capital requirement is the whole point of a GmbH. If you don't want it, you can found a UG, which is the same thing with no capital requirement.

The German eID system had a bad start but it works fine now.

Not anymore, Germany has a streamlined online notarization process for creating a simple GmbH now.

I've recently managed to get everything done in <1 week, including bank account.

Progress!

No, radiation from radon at naturally occurring levels won't cause any damage to plastics.

Radon and its progenitors won't produce nearly enough radiation to damage plastics like that at naturally occurring levels.

If Kernel Lockdown is enabled, a zero-day exploit is required to bypass module restrictions without a reboot.

Unfortunately, threat actors tend to have a stash of them and the initial entry vector often involves one (container or browser sandbox escape), and once you have that, you are in ring 0 already and one flipped bit away from loading the module.

The Linux kernel is not really an effective privilege boundary.

Red teams (internal or consultants) use this sort of tooling in the real world. Their job is to emulate a real, competent threat actor. APTs routinely use high-quality rootkits for EDR evasion.

Persistence is actually quite rare nowadays - since it's the most easily detected, red teams usually prefer not to and stay memory-only.

Is there a paper or some other architecture document for dsync?

It's really hard to solve this problem without a consensus algorithm in a way that doesn't sacrifice something (usually correctness in edge cases/network partitions). Data availability is easy(ish), but keeping the metadata consistent requires some sort of consensus, either using Raft/Paxos/..., using strictly commutative operations, or similar. I'm curious how RustFS solves this, and I couldn't find any documentation.

EiB scale doesn't mean much - some workloads don't require strict metadata consistency guarantees, but others do.

Hard to say these days!

RustFS appears to be very early-stage with no real distributed systems architecture: https://github.com/rustfs/rustfs/pull/884

I'm not sure if it even has any sort of cluster consensus algorithm? I can't imagine it not eating committed writes in a multi-node deployment.

Garage and Ceph (well, radosgw) are the only open source S3-compatible object storage which have undergone serious durability/correctness testing. Anything else will most likely eat your data.

Great, so this means that the only way to get an Android release that's up-to-date on security patches is a binary-only distro - either Google Pixel, or the GrapheneOS preview channel.

Just wonderful. Google should know better than this, shame on the other OEMs that forced this mess.

It's just poor risk management at this point. Making sure that a configuration change doesn't crash the production service shouldn't take more than a few seconds in a well-engineered system even if you're not doing staged rollout.

If there is a proper rollout procedure that would've caught this, and they bypass it for routine WAF configuration changes, they might as well not have one.

They don't appear to have a rollout procedure for some of their globally replicated application state. They had a number of major outages over the past years which all had the same root cause of "a global config change exposed a bug in our code and everything blew up".

I guess it's an organizational consequence of mitigating attacks in real time, where rollout delays can be risky as well. But if you're going to do that, it would appear that the code has to be written much more defensively than what they're doing it right now.

There's an experimental-advance-branches feature which helps with that!

Ceph is quite expensive in terms of resource usage, but it is robust and battle-tested. RustFS is very new, very much a work in progress[1], and will probably eat your data.

If you're looking for something that won't eat your data in edge cases, Ceph (and perhaps Garage) are your only options.

[1]https://github.com/rustfs/rustfs/issues/829

When you want just the API for compatibility, I guess?

Self-hosted S3 clones with actual durability guarantees exist, but the only properly engineered open source choices are Ceph + radosgw (single-region, though) or Garage (global replication based on last-writer-wins CRDS conflict resolution).

Shipping updates almost weekly is the opposite of what I want for a complex, mission-critical distributed system. Building a production-ready S3 replacement requires careful, deliberate and rigorous engineering work (which is what Garage is doing[1]).

It's not clear if RustFS is even implementing a proper distributed consensus mechanism. Erasure Coding with quorum replication alone is not enough for partition tolerance. I can't find anything in their docs.

[1]: https://arxiv.org/pdf/2302.13798

Is it stable now? Last time I checked, the amount of correctness bugs being fixed in the Git history wasn't very confidence-inspiring.

They required a "Community Contribution License" in each PR description, which licensed each contribution under Apache 2 as an inbound license.

Meanwhile, MinIO's own contributions and the distribution itself (outbound license) were AGPL licensed.

It's effectively a CLA, just a bit weaker, since they're still bound by the terms of Apache 2 vs. a full license assignment like most CLAs.

Apparently, it's (1): https://proton.me/support/search

There are obvious UX/performance issues, but it's an honest approach.

Gerrit also maps really nicely to jj concepts, and there is an accepted RfC to add support for Jujutsu change IDs to Gerrit.

This article is talking about relocating residents, doesn't sound great: https://kbr.id/articles/indeks/membongkar-ancaman-paparan-ra...

"Released from the facility’s smokestack" sounds bad.

Is it even possible to clean this up, if true?

It's certainly not the case for Google Drive, which is geo-replicated, and I would be very surprised if it's true for any other major cloud.