If you're willing to take the pain of setting up an actual authz model, I've found OpenFGA^ to be really nice. We used it to set up some pretty complex authz involving cross-agent/user/org creation and sharing of data. It's not _simple_, but it is effective.
I really want to love KeyCloak. I've had really bad experiences with weird uptime bugs and crash loops that kept me from giving it an honest retry over the last couple years.
It also really shows its age, imo. The interface is clunky, roles and groups having overlapping responsibilities is confusing, making custom UIs for it makes me feel ancient, etc.
I really can't complain though. There is simply no alternative that's as open atm. It's also not easy to make one ( I tried :( ).
Keycloak and Better Auth aren't as fundamentally different as you may think! Better auth supports authn/z, being an identity _source_, being an identity provider, being an OIDC/SSO provider (so others can login using better auth), rbac, SAML/SCIM, and a ton more. It's actually really powerful! Most folks found better auth as an alternative to next-auth/auth.js - but better auth does a lot more than those.
This seems to be focused on Python, but for all the TS devs out there, what you'll see will be implicit `any` errors. Quick word of warning on having LLMs fix those - they love to use explicit `any`s or perform `as any` casts. This makes the lint error disappear, but keeps the actual logic bug in the code.
Even if you ask it not to use any at all, it'll cast the type to `unknown` and "narrow" it by performing checks. The problem is that this may be syntactically correct but completely meaningless, since it'll narrow it down to a type that doesn't exist.
The biggest problem here is that all of these are valid code patterns, but LLMs tend to abuse them more than using it correctly.
There's an easy shortcut in the second level past the climb on the pink pipe and before you climb the ramp where you can jump to the semi-circle on the lower platform on the other side. Love it!
This section in particular piques my interest. I never found this confusing, since the change in HEAD is just representative of the order of operations (in rebase, you are setting the current commits "on top" of the commit you are rebasing onto, etc). This feels like what is confusing isn't really HEAD itself, it's a fundamental understanding of the git model?
I feel like folks using git without understanding the basics of what it does is what leads people astray? If so, why isn't this part of our basic training as engineers who use git?
Just searched for Docker Swarm, and got [0] one "People also ask" card, one section for images, some related searched, and a button that says "More Results" that doesn't work. Moreover, the formatting of the CSS in the footer also looks weird. Seems like there's definitely been some issue with the deployment.
Edit: using brave and chrome on an Intel Mac, same results for both.
Oh wow, we're building something very similar to this. We were literally just filling up the YC form for S23 too haha. I may be a bit biased, but I think this is an excellent idea, and it can change the way testing works for backend services. We were inspired by Meticulous, too! Hope we can learn from y'all as well :)
Ok so in general I'd chalk this up to being disinterested, but I think this is relevant for a product meant for people with ADHD:
After a couple pages of choices, I was met with a screen with options A through K, and I instantly closed the tab. I didn't even read what it was asking. I realised that this may literally be ADHD like behaviour, so I opened it back up again, but it was still quite overwhelming and it took conscious effort to read through the form. I think this is just because I'm used to just entering my email and password, or using social logins, so filling the form seemed to be a substantial point of friction (even though I realise how it could be useful)
I'm unsure if I have ADHD, and it's never been a problem for me, but I sure do have a short attention span haha
To be fair, it'll probably be a lot easier to replace the battery on that dell (and the system76, I imagine?) than on the Macbook. That evens things out even if the battery doesn't last.
Correct me if I'm wrong, but shouldn't the criterion be that the probability of death is the same between 80-90, 90-100, and so on (for example) to say that humans stop aging after 80?
Saying that your chance of dying is 50% after 80 != saying it's the same consistently after 80?