The Shepard tone of "progress"

You can use "the" in the original sentence just fine if the pool had been established earlier, like with planning a pool party. Then the pool is the pool that you'd be using, and not simply a pool that will be found at some point in the future.

GET requests can have bodies too, and many low-level APIs will allow it - given how few things seem to be aware of this, you could probably sneak stuff through that way too.

A query parameter on a GET request is actually data written to memory. So this idea that any HTTP verb somehow provides context or enforcement of read versus write totally misses the point.

>This leads to passkeys being the perfect fit for a corporate environment, but a poor fit for personal security.

I 100% agree - almost everything about them screams "this is The Ideal Corporate Solution".

This isn't a bad thing, it's nice to have a standard for corporate uses. And the attestation-DRM stuff makes perfect sense there, you already have MDM and it fits with that perfectly....... though not all that differently than using MDM to set up client-side certificates. But app/OS support is better, for some reason. Why didn't they just improve that flow?

For personal use though, they seem outright hostile to people living in the real world with common failure modes. It's outrageously clear that normal people were a distant afterthought - just look at how hostile it was to syncing at the beginning, and how long it took to get key exporting (and how directly hostile they were to anyone building a stopgap in the meantime).

Passwords can move between walled gardens generally very easily (export) or manually in all cases (enter by hand).

Passkeys only very recently got relatively broad support for migrating data (after years of promise and no support at all), and they report (optionally with hardware attestation) what password manager you're using so sites can force specific ones.

I've been using keyboard-based launchers for a couple years now, I really like it. None quite yet feel perfect to me, but Olauncher has lasted the longest: https://play.google.com/store/apps/details?id=app.olauncher

If you set up a swipe to launch another launcher, you can have all your widgets there, as sometimes that's nice for a multi-app overview of Stuff™ at a glance.

1b: the docs are a pointless ritual that sometimes ends up taking multiple times longer than implementing, and if too many people see it they start asking things like "what are your KPIs" and "when are your deliverables synergized" and "have you written the oncall runbooks yet? what's the protocol spec for that?" and "what's your projected uplift". if it's less than 5 pages of text, you're dinged on perf because your documents aren't detailed enough. for projects like "we should add a small in-memory cache to this slow area".

so you're best off writing a small one that you do your best to hide, and make a few fancy ones per season with graphs and absurd will-never-be-implemented details for the higher-ups to be distracted by.

(edit: removed because I was confusing Bottles and Boxes, no need to leak wrong ideas)

Bottles is a wine/proton runner, not a VM manager. I think you might be mixing it up with Boxes?

Yes! I am indeed, thank you! Bottles has been useful, though I haven't used it in years.

particularly if you want to support all of the message-body features, of which there are MANY. it's very business-comms oriented.

I broadly expect third-party RCS apps to drop that though, like how essentially none support all of MMS. did you know MMS supports slideshows (I built support for this once)? 3d objects (mimetype model/gltf+json)? "timed text" (mimetype text/mp4)?

For anyone unfamiliar with this strategy: it's literally just "clone from a /path".