@sun@shitposter.world tbh in my very simple use of AI when coding, I find that it's just very shit at abstraction. It can extend stuff, sure, but offers near-zero capabilities for simplification (without spending a fuckton of money like OpenAI did with ARC). And there's only so much you can extend stuff without simplification before you get into a massive pile of spaghetti code.
@whitequark@mastodon.social checked out the AD9361S and surprisingly it seems it has the potential of being more expensive than the FPGA, somehow, if it's the -CSH variant, purely from more certifications (20x price different on that is wild)
@whitequark@mastodon.social honestly feels like they just went "hey, what are our direct contacts making with the previous version? We'll just put it all into the datasheet"
It's gettext is very well designed, and there is a good reason why it is the standard. I can bet whatever you're using cannot handle proper pluralization, whereas gettext can without a problem. Legitimately haven't seen a single good reason to use anything but gettext for internationalization.
@piggo@piggo.space there's libraries for gettext in every language imaginable, you don't need to touch it
and .po is essentially standard for all translation things, if you want to get professional translations (or even community ones), they want stuff as .po.
@wolf480pl@mstdn.io@quad@akko.quad.moe idk, it's more that, you don't particularly really need to have the ability to get the plaintext of the private key for what this thing is built for. And the ability presents potentials for attacks, and some companies would rather not deal with the "higher risk" credentials if the payout from popping the credential is quite high.
Genuinely don't really see a need to have a simple to pop credential for daily use. For experimenting - sure, but you don't really need such credentials to work on every website anyways.
Unless the RP is braindead stupid, you should be able to add multiple credentials to each one. That's the standard way to do things. Heck, I've seen a guy on HN say that he added "passkeys" from each of his devices to the services he logs into, even though they don't share it.
I have like 4 separate physical keys, with some in cold storage and stuff, and they all get registered on most of my logins. There's no other way to do stuff if you're using physical keys, even. So IMO having a key trapped in a TPM is almost zero disadvantages from usability side, and plenty of advantages from security side.
and them asking for strong devices is kinda equivalent to them asking for strong passwords. they are taking on a risk as well, so they have a valid reason to mitigate it.
There are legitimate reasons for both sides of the coin
You're acting as if the decision of some businesses to act more carefully is a part of a plan to lock everybody in to only a cabal of cryptographic implementations and then never let anyone touch their own private keys ever again
This view is just plain paranoia and conspiracy theory. I legitimately cannot understand how are you equating these things together. Genuinely, WTF
@wolf480pl@mstdn.io@quad@akko.quad.moe If it is, it is in no way done through attestation - maybe through abusing their existing monopoly, marketing, and lack of key extraction from their devices - but that's far, far from the "everyone will require attestation and the only attestation that will work will be google's and apple's" that you seem to be proposing
They themselves do not enforce attestation at all, and eveything about suggesting checking attestation on the web is marked as "if you're a high-risk business, you might want to do this, otherwise, don't bother"
@wolf480pl@mstdn.io@quad@akko.quad.moe What if it turns out webauthn attestation is useful as a captcha / anti-sybil mechanism?FWIW Cloudflare did try that, I don't think anyone was a fan of that and I think they stopped? IDK didn't follow it closely, but it had problems
But I don't think that things are going to change from how they are right now. There is little incentive for 99% of websites to care about attestation, and because implementing it is extra work than not, I don't see that changing, ever.
I like some parts of what they do, but not all of them. There is a value for co-building the stuff, but there's also a cost (in re-usability)
I put this quite well in an HN comment when they talked about their no-BIOS "holistic booting":For what it's worth, a holistic system only allows the user to bring their own code only above some layer. For Unix systems of ye olden days, that would be your C source code that you compile. For Chrome OS, that's gonna be websites and extensions. For Oxide, it seems like that is going to be VM images.
But it's important to note that these days, there will always be somebody who wants to bring their code in at a lower level. And the immediate reaction of all vendors is "But why would you want to do that?". Why would you want to bring your own Unix flavor to our hardware? Why would you want to run Linux executables on Chrome OS? Why would you want to run a different hypervisor on Oxide racks?
Those people will exist. And layers like BIOS and UEFI allow system vendors to say "Eh, sure, we don't think that what you're doing is wise, but whatever, here's a standard way we'll allow you to use". Holistic systems don't have these standards. They are only usable as their creators intended. And not everyone will agree with their creators intentions. But the work required to refit them to fit another purpose, which the hardware is very fit to do, but the software fights against, is usually too high, and you'll be better off using something that is worse, but left you an avenue to customize it for your purpose easily.
My main takeaway from this talk, is that we need some standards for phase-based booting, as there is some very cool improvements that could be done with it. But I see no need for holistic systems as described in that talk, I just see a need for better, more transparent systems. And a system doesn't have to be holistic to be transparent, or good.
you can really tell how most arm stuff comes from embedded markets, because all of the hardware is built as if it will ever run only a single set of software that will know everything about the hardware it's running on beforehand - that's what happens in embedded, and exactly what doesn't happen everywhere else.
I do in fact existI'm an information sponge, so if you have some question that you think I might have an answer to, feel free to ask! Even if I won't have it off my head, I know how to look up things fast.