And vice versa. As someone who likes both languages, I appreciate how they both have their pros and cons. I was a Schemer before I learnt Java (when Java barely existed) and I adore Clojure, but if I were to write 10 MLOC mobile network routing and billing system, an air-traffic control system, or a credit-card transaction processing system etc. etc. that needs to evolve by a large team for 20 years, I would choose Java over Clojure any day. So I came to Java from C, C++, Scheme, and ML, and it's completely unsurprising to me why there has never existed a language that better supports large, long-lasting, important software (I'm not saying such a language couldn't exist, but it currently doesn't). And it's not just about the features Java has and, just as importantly, doesn't have (and if you think keeping features out of a programming language is easy, think again), but also how its evolution is handled.
In this particular case, of course it is more straightforward to embed what is effectively an untyped language in another untyped language than in a typed language, at least while keeping the language simple and without adding features we don't wish to add (even in TypeScript, working with JSON directly requires bypassing type checks). Still, as the JEP says, there are good, popular Java libraries that offer more convenient and powerful ways of working with JSON, but that is not the purpose of this particular package.
Zitron is a hack who sells anger to people who don't know any better. Just because he's right about some things doesn't mean you should give him the time of day.
> Every device is supposed to have its own unique private key, stored in TPM, released only when passing the user challenge (biometrics or pin, or a yubikey).
This is a misconception. A particular service can choose to enforce those class of passkeys, but most don't need that and shouldn't.
Passkeys are primarily meant to replace passwords and be hard (but not necessarily impossible) to exfiltrate.
The key difference is during normal usage you don't have to type the secret in anywhere, it's strictly asymmetric, so a unwitting user is far less likely to get fooled into accidentally leaking the actual credential.
Passkeys is basically a brand name for "discoverable credentials" (a Webauthn term). They do a little more than that technically, but in practice their purpose is what you said. Replace passwords. Or more accurately usernames and password pairs. This is in contrast from 2FA, but even before Apple started marketing Passkeys the FIDO standard supported the concept of Passwordless authentication, alongside 2FA.
Passkeys came together with multi-device syncing when Apple introduced them and IIRC it was pushed as their killer feature by Apple back then, but passkeys can also be completely device-bound. The marketing around this was all quite confusing, but it's a bit too late to fix now.
What we got, as far as the average consumer should be concerned, is that "passkey" is any authentication mechanism (not the actual credential) that can replace a password. And it's still confusing.
I think in Apple stack they cannot be made hardware bound anymore. Platform claim is ignored on creation and the keypair is always in Keychain and syncable unless iCloud sync is disabled.
> Passkeys are primarily meant to replace passwords
Unfortunately, the designers of passkeys decided they should replace passwords and usernames and second factors.
Also they decided they should be cloud-synchronised, so the something-you-have second factor doesn't impose the burdensome requirement for you to have something, which was apparently a big usability problem.
> Unfortunately, the designers of passkeys decided they should replace passwords and usernames and second factors.
They obviate the need for a user identifier as the key is itself unique, but removing the 2nd factor is a choice of the service, not the designers of the Webauthn standard.
> Also they decided they should be cloud-synchronised
The earlier versions of the spec required that the keys be resident in hardware, but it was updated to allow "roaming" keys. The important part is it's up to the service to decide on whether they want to require hardware resident keys (which cannot be synced via the cloud). Most do not.
The usability problems are actually larger than that, see sibling comments for why. Passkeys, even when cloud synced, are still better than cloud synced passwords and still give the option of hardware backed keys for those whose threat model warrants it.
> The important part is it's up to the service to decide on whether they want to require hardware resident keys (which cannot be synced via the cloud).
From what I know, Apple ignores `platform` and `ResidentKeyRequirement` claims and always creates cloud-synced key pairs.
Moreover, the strongest claim value allowed for the `ResidentKeyRequirement` is “discouraged”, which per spec is treated as SHOULD in RFC 2119 since. In other words, browsers are free to ignore it when “they know better”, which Apple always does.
Sure, but you can still use a Titan T3 or recent Yubikey model on an iPhone. If I had the threat model to justify it, I would not set up the passkey in Apple's infrastructure.
It is too bad they ignore that though. That's really disappointing.
One recommendation: do not let the LLM write your README for you. It can write other docs (though IME they still suck at it), but your README needs to be focused and easily digestible by a human glancing at the project.
LLMs have no concept of focus when it comes to docs, so they spew out way more information than is necessary or helpful to a human reading the document.
Ha - ok understood, although in my specific case I think this is better than anything I would have written. I edited it pretty hard to get it to say what I wanted it to say, so not sure if that counts. Thanks anyway for the feedback.
This is one of the cases where I think people really want a personal touch. Your README is the "hook" of a project, it's the first thing we see, and so you want to advertise "this thing was made with thought and care". Also the README does not need to be exhaustive, it should be a form of advertising and you can nest the lower level documentation in a /docs and link the sections from the README.
No, I think the technology fundamentally is not there and a decade away even with stronger financial incentives (of which there are already plenty). Between range, charge times, and worst of all: weight. A huge percentage of loads are operating at the limit of what is legally allowed on highways and it's strictly enforced. If you increase the baseline weight of the vehicle substantially, as you must with current battery energy densities, you decrease what can be carried by a single truck proportionally.
What will actually happen is literally everything will get more expensive.
For a relatively low-traffic site like Lobster's, yeah I'm not surprised they don't need anything crazy. SQLite is really efficient and modern hardware is really fast.
I don't think SQLite is particularly optimized for modern hardware. It's just crazy efficient with a regression test suite many projects wish they could have.
I've found it lacking, especially with kinda buggy interaction with the vim keybindings.
Obsidian's data model, a huge selling point to some, really hinders it too. Logseq's new db format let's you treat any block as a page, metadata and all which can be super helpful.
I'll stick with my portable local-filesystem markdown over any db format (let alone with Obsidian's Coreview and Dataview plugins, and Bases, for db-like querying).
I really like the art direction of the new GitS adaptation (I hope this retro style gets used more), but yeah it's completely different in tone from the '95 adaptation and most of what followed.
They're not even technically one organism, but colonies of independent but mostly specialized organisms. I'd be willing to bet that has something to do with the articles title
True jellyfish (like moon jellies, box jellyfish)are a single organism, just like you or me. Theres a single genome and one body.
Portuguese man o’ war is not a single organism at all but a siphonophore, a colony of many genetically identical but specialized individual organisms called zooids, all fused together and functionally dependent on each other.
Whats the difference between a siphonophore and a single organism? Aren't all the organs of an organism genetically identical, specialized, fused together, and functionally dependent on each other?
It's a very fuzzy line. But according to The Octopus Lady's video in the other comment, it's because separating them from the other zooids doesn't result in immediate death. They may die later due to lack of ability to swim, or eat, but that is a secondary cause which is considered important.
It's just a fact about the evolutionary history. You are a "multicellular" organism; you are composed of a bunch of genetically identical cells that fuse with each other and differentiate their development to specialize in certain tasks. It's not just your organs; your entire being is like that.
Siphonophores are identical, except that they can be subdivided into units that are, much like organs, composed of multiple cells. Those units can be identified as evolutionary derivations of certain branches of the tree of life. This is more similar to your mitochondria, which are (like zooids) identifiable as having once been independent organisms, though unlike zooids your mitochondria are not genetically identical to you.
True. And also amazing how complex their interactions can be! Just because immune cells are often individually motile, does not mean they're not intimately interoperating within an incredibly complex social ecology of cells. https://en.wikipedia.org/wiki/T_cell is full of surprises.
Your comment has completely failed to distinguish "organisms" from "siphonophores". As you describe yourself, a siphonophore also has a single genome and one body.
reply