This was quite interesting though. Surprised to see it work so well on a real example.

It's hard to justify the price unless you put value to Framework's gimmicks and mission.

There's no illusion that I'm not paying extra to vote with my wallet for sustainability. And I'm on with that.

Which worked well unless compiled with `strict-aliasing` gcc optimizations enabled...

Just writing UDP RFC compliant code doesn't protect you from running into annoying behavior with your programming language of choice...

Colocation has its uses bit is a bit finicky. The push/pull compatibility works perfectly fine (with some caveats of github being broken that can be worked around).

But not the 3rd mono repo on the same technology to avoid some scaling limit.

Actual fips compliant (certified) gives you confidence in some basic competence of the solution.

Just fips compatible (i.e. picking algos that could be fips compliant) is generally neutral to negative.

I'm not 100% up to date, so that might have changed, but AEAD used to be easier if you don't follow fips than fips compatible. Still possible, but more foot guns due to regulatory lag in techniques.

Overall, IMO the other top-level comment of "only fips if you have pencil pusher benefit" applies.

Granted, we already have US/EU/Asia as distinct regions. AUS would just make fail over even worse.

The high ping kills the throughput on davfs and makes their website hosting a pain to update :(

But the git directory entry contains: * a type (this one is quite limited, so I'm not sure how well that could be (ab)used * a name * a pointer to the content

Which is exaclty what an AST entry has.

The cli really isn't the greatest either way. But there's lots of infrastructure to make the sharing work reasonably well.

It shouldn't be hard to build a bijective mapping between a file system and AST.

I don't think there's a limit in git. The structure might be a bit deep for git and thus some things might be unoptimized, but the shape is the same.

Tree.

Not a result of git.

Business continuity (no uncontrolled external dependencies) and corporate security teams wanting to be able to scan everything. Also wanting to update everyone's dependencies when they backport something.

Once you got those requirements, most of the benefits of multi-repo / roundtripping over releases just don't hold anymore.

The entanglement can be stronger, but if teams build clean APIs it's no harder than removing it from a cluster of individual repositories. That might be a pretty load bearing if though.

Or would open the system up to the originally posted attack of providing ~an open relay.

If that ever repeats, the same I'd was used twice. At the same time, the site ID would act as salt to prevent simple matching between services.

And when then, only when I'm in foreign countries.