Thanks again for listening to the feedback and making these improvements! Especially the 302 redirect bit.
Would love to know if you’ve tested the hybrid migration mode against artifactory yet. Would be very very cool to have a way to run both of these side by side while evaluating the cutover. Maybe with a way to re-sync the artifactory db changes over periodically.
Can this do 302 redirect to s3? One neat feature of artifactory edge is that the asset download can skip hitting the edge peer and go straight to s3.
Would be cool if this also could support the existing artifactory s3 backend format so you could just point this at your existing artifactory s3 bucket and migrate your db over to this.
Seems to be nfs v3 [0] - curious to test it out - the only userspace nfsv4 implementation I’m aware of is in buildbarn (golang) [1]. The example of their nfs v3 implementation disables locking. Still pretty cool to see all the ways the rust ecosystem is empowering stuff like this.
I’m kinda surprised someone hasn’t integrated the buildbarn nfs v4 stuff into docker/podman - the virtiofs stuff is pretty bad on osx and the buildbarn nfs 4.0 stuff is a big improvement over nfs v3.
Anyhow I digress. Can’t wait to take it for a spin.
It’s not just the UK implementing age verification actively. 5 EU member states [0] are actively participating: Denmark, Greece, Spain, France [1], and Italy.
In addition to some other things, I was responsible for all vehicle simulation in Army of Two. This article is a good starting point. I was glad they mentioned implementing Pacejka’s tire model and the transmission differential in the article - those help a lot. Aside from that, I was surprised (not surprised) how important an anti-roll bar physics sim and suspension sim helped make driving feel “fun”.
That’s the most important follow up. Without it, you’ll notice that the driving feels icy - I see it in the demo video. Most folks who fail to do the anti-roll bar and suspension wind up with cars that easily flip on turns - so they make the tires slip or they play with the surface friction, which makes the driving experience worse.
Git-crypt is a dead product with numerous unresolved issues and drawbacks.
Newer versions of git cause git to crash when invoking git-crypt[0].
It doesn’t scale with users: Off-boarding a key is a commit in git. Since it is trivially easy to rewind a git repo before the revocation commit and then decrypt with the revoked key, this means you need to rotate every key under management when any revoke is performed.
It provides the illusion of asymmetric key encryption, but your asymmetric key wraps a shared symmetric key used to encrypt the entire repository. This also means a user could roll the repository back before a key was revoked and steal the symmetric key used to protect the repository and then use that key to decrypt the repository any time in the future.
It doesn’t scale with the number of files under management. As a result of how it’s implemented, every invocation is a separate process launch. This means every file triggers an asymmetric unwrap of the symmetric key. If you’re protecting your GPG key with hardware keyfob, decrypting the repository will take a long time.
This product seemed like a cool idea for a while but it’s implementation leave much to be desired and has not stood the test of time…
Password-store[1] does a better job than git-crypt for single user git based gpg encrypted password management.
For multi-user git repo encryption I prefer Mozilla SOPS[2], especially when coupled with something like AWS KMS…
But then you might consider stepping up to something like Hashicorp Vault[3] or Infisical[4].