Indeed, the only advantage to Resident Keys (i.e., Passkeys) is the discoverabillity of them, so you can login without even using a username. It's a shame all of the terminology around WebAuthn/FIDO2 and Passkeys is so loose and badly defined.
Honestly, I think OAuth logins are still an ok option for the average user, unfortunately, as I would never recommend someone I love to use Passkeys and put them through the burden of having to understand and deal with all of this mess.
Yeah, they do. But what if you want to move from Android to iPhone or vice versa? That's the big problem regarding these keychains/password managers. Some of them didn't even allow you to export your Passkeys until a few months ago, meaning you were literally locked into their platform.
Remember that your average user has no idea what a passkey is, doesn't remember half of their passwords and has no idea what a password manager is.
Whenever a website offers to create a passkey, it could end up in any of these:
- Samsung's Password Manager (if using a Samsung phone)
- Apple's Keychain (if using an iPhone)
- Google Password Manager
- Your operating system's keychain
- A bespoke password manager (e.g., Bitwarden or LastPass)
- Your hardware key
Most users do not have a security key fob. Instead, the proposal being mostly pushed is the idea that users can store keys on their own smartphones, making use of the modern TPM and chip security. Most of the discussion here revolves around that idea: "What if I lose my phone? What if I switch phones?" and that's why the problems seem so obvious to you.
I absolutely agree the best solution is to use hardware keys, but I'll admit it's cumbersome if I need them for hundreds of accounts (which I do have), having to register both for every website and praying that I never lose both at the same time in the case there's no viable recovery flow for some of the accounts. Also, most of these hardware keys are limited to 25 or 100 resident keys, which again makes them unable to substitute passwords. Observe the usage of the term resident keys: passkeys do rely on the private key being stored on the hardware key, as that allows discovery.
> If you set light mode, you'll get some light gray text on lighter gray background somewhere, but if you use dark mode, then you'll get some black text rendered on a black background elsewhere.
I've been using Linux (Linux Mint Cinammon, then Fedora Linux GNOME) for over five years and I've never had that. What kind of desktop environment, themes and applications are you using?
It has apparently been developed using LLMs. However, it's not vibe-coded as in no-thought development. According to the commit History, the developer first defined a design system and a product requirement document, which is one of my favorite ways of developing software nowadays (even if it's not necessarily "agile" or modern), specially whenever LLMs will be around the codebase.
> And acknowledges how people that identify as monogamous are not monogamous - they aspire for monogamy and have a deep discomfort with people that identify as nonmonogamous despite the aspirationally monogamous doing the same things in a harmful way
Could you elaborate further on this idea? At first, I just disagree completely, but I'm missing your reasoning and the actual thesis behind this idea.
HTTP/3 uses QUIC as the transport layer, which in turn relies on UDP. QUIC replaces TCP while allowing a reduction of handshake exchanges in HTTP/3 first requests. Finally, even though UDP supports multicast, I believe QUIC doesn't. GP saying Google has developed it to use multicast thus is nonsense. Furthermore, QUIC takes much more CPU than TCP right now, due to running in userland.
In my opinion, QUIC and HTTP/3 are technical marvels, but are perhaps way too complicated and don't really serve the interest of most internet users.
There will be a point in the development of web browsers and associated technologies where we should just stop a bit to get things stable instead of churning protocol version after protocol version after new API. Will it ever stop?
Eventually, it all becomes so complicated no company can manage it all. Honestly, we might already be past this point, with Chromium at almost 40mi LOC, more than the Linux kernel itself, including all its drivers. When will the madness stop? Do we really need such complicated software to see Instagram posts, comment on a few Hacker News threads and mess around with Google Sheets?
The biggest reason I worry so much about this is that in the web, adding new features, APIs and protocols is easy. Removing and deprecating is basically impossible.
That makes a lot of sense! I have no idea how I'd use that much money, so maybe the 128gb MBP for messing around with local LLMs wouldn't sound so absurd :)
You're most welcome! I'll admit I did search before answering because you said Apple produced their memories so confidently LOL
I guess they would love to produce it themselves, but for the average scenario the production reserves they have with Samsung already work well enough and prevent them from having to get into such a complicated industry.
That's incorrect. Apple purchases RAM from all of these providers to produce their unified memory. They also rely on TSMC fabs for all of the chips their memory relies on. If they haven't doubled the prices of their machines, that just goes to show how fat of a profit margin they take on everyone that buys from them...
I feel like I'm going insane seeing people buy these 128gb MBP for thousands of dollars to run models that are objectively much worse than SOTA and spending so much more. The amount spent on a 128gb M5 MAX can buy you a damned new car here. What the hell am I missing? Are developers in other countries living in such different worlds?
(I'm aware the price is, in absolute terms, more expensive where I live compared to the USA. That reinforces what I think, because anyone sane that would've bought one of those in another country would sell them as soon as they landed here and save that money.)
How much does one of those cost in the US? Here in Brazil, your notebook is worth as much as a used Honda Fit, which seems absolutely insane. For comparison, the ThinkPad I'm currently running cost me 1/20 of how much this MBP costs here, leaving me with over $8.000 to spend with LLM inference (if I actually spent money with that).
Absolutely! That's why they are students: you learn to walk before you learn to run. Students should be forced to plan their texts and practice getting better at that. Whenever they leave school, they'll be able to write even better texts than the essays.
Honestly, school essays, as a text genre, suck to read. They are not meant to be enjoyable, beautiful texts! Instead, they are meant to help gauge the student's ability at text planning, the quality of their text project, their grammatical knowledge, and orthography.
I must say I'd be open to seeing schools attempting other models, though, and measuring the results thereafter to see in practice what happens when students type their essays instead. In terms of text projects and planning, that could be interesting and train different skills.
And that's exactly the point! By making sure the student can't edit the entire text once its written, you force him to think about the essay's structure and force him to plan much more before writing :)
Nowadays, these code forges have also become a centralized place for issue tracking, kanban boards, wiki editing and, specially, as CI/CD servers, in the case of GitHub Actions, which are, sometimes, the only for you to deploy software to package repositories. The same limitations apply to GitLab CI or Codeberg's Forgejo Runners/Woodpecker.
Whenever GitLab, Codeberg, BitBucket and, mostly, GitHub goes down, a lot of the software and websites you use can't be updated, including dependencies of your software that you're pulling from npm, for instance.
Finally, companies use code forges mostly for the ease of doing code reviews through Pull Requests/Merge Requests. Developers rarely, if ever, actually merge branches locally, before having it reviewed by peers in one of these code forges.
I'm impressed that, in the meanwhile, Google has already thrown into the grave not one, but two different implementations of Material Design in the web: Material Design Lite [0] and Material Components for the Web [1], bot of which never managed to actually be competitive UI libraries.
edit: Actually, they've thrown a total of _three_ implementations into the grave, as MWC is in maintenance mode already [2].
https://www.doodlesdev.com