allset_

FWIW, both AWS S3 and GCP GCS also allow you to store data in multi-region.

https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiR...

https://cloud.google.com/storage/docs/locations#consideratio...

> 5 to 6 hours of standing meetings each week

Wow that is a lot. That is (almost) a WHOLE DAY of meetings each week just for syncs.

I can only provide my own anecdotes, but I'm at 0.5-1hr for standup status-report type meetings.

You don't need PoE to do WoL.

What are you suggesting? They shouldn't secure their services before public disclosure?

WebAuthn is more secure, easier to use, and is not proprietary.

I would expect the TPM to wipe key material after X failed attempts, is that not the case?

In the US? Nope.

That sounds like a limitation on the remote end that doesn't support high bandwidth. If you have 10Gbps connections on both ends, your link should be saturated (minus some overhead).

You are correct it seems to be incorrect, apologies. That's what I get for not looking closely (and trusting Google search to promote factual info in the info cards).

If it goes to rent, it's not profit by definition. That's just a cost, same as any other. Starbucks made 32B in 2022 with a profit of almost 22B.

Not OP, but it's easy to find these numbers as it's a publicly traded company.

https://www.macrotrends.net/stocks/charts/SBUX/starbucks/gro...

https://investor.starbucks.com/press-releases/financial-rele...

> Is it because all profits accrue to shareholders?

Yeah.

> We've lived with 2K monitors for decades

This is a bit disingenuous. The 2013 MacBook Pro (a single decade ago) was the first mainstream device with a resolution above 1080p and with scaling people effectively still had a 1440x900 screen anyway. 1280x800 was common at the time for 13" devices. High DPI has really only taken off in the last 5 years.

edit: fixed info regarding scaling

The more pressing reason they expire for web sites is that site ownership can change and you don't want someone else having an infinite lifetime cert for a domain you just bought.

It's also useful to issue short lived certs and use the expiry date to handle revocation rather than maintaining a CRL.

> I just don't trust it that it's not phoning home or leaking data.

This is just irrational. The client is open source. You can build it and run it from source.

It could just as easily be configured to send a real payload if you're connecting from certain IP blocks, or if your user agent matches a certain version, etc. Advanced actors don't serve up a payload to any device that connects.

> it remains an open question of whether gay people will ultimately select themselves out of the gene pool or not.

Being gay is not a genetic trait though.

It is, though it has locations elsewhere. https://ubiquity.com/company/locations/

Attestation for hardware-backed FIDO authenticators is worthwhile. You can attest to various properties, such as whether or not the credential is protected by a PIN.

This is for U2F, which is not FIDO2, though FIDO2 is backward compatible with U2F with a limited set of features. U2F-only hardware is not compatible with the passkeys model.

See https://fidoalliance.org/specs/fido-v2.0-ps-20150904/fido-ke... for the FIDO2 attestation specs.

> you start creating a complicated network of soft dependencies between those modules. And when you have everything in a single repository, it's hard NOT to do that.

That is what the visibility [1] in Bazel solves. You can't import other people's code unless they say you can by making their code visible to yours.

[1] https://bazel.build/concepts/visibility

Why are you speaking as if this is some weird future state that doesn't exist and has lots of unknown downsides? This is the current state in some companies. I work in this flow daily and really appreciate the value it delivers.

> Why?

Three reasons from my perspective:

1) There's no setup steps. You just open your editor of choice and everything is set up for you. All the build tools, linters, specific versions of software $XYZ, etc.

2) Large VM (16 core, 96GB of RAM in my case) speeds builds and tests up dramatically.

3) Zero productivity lost if your laptop breaks. Just grab a new one from IT and you're up and running exactly where you left off with zero effort.

> Not being able to run the project natively

What do you mean by this? It's just running on a remote server rather than your laptop.

Because you say it's offline, but require an access token and to quote from your FAQ:

> Picovoice engines call home servers to stay active and report the consumption for billing purposes only.

That's not offline.

Then please explain the

> Picovoice engines call home servers to stay active and report the consumption for billing purposes only.

So... not offline.

Perhaps I'm missing something, but why does it need an access key if its offline?

Builds in production shouldn't be built using developer laptops. I think you're approaching this wrong. You can build and test on x86_64 laptops all day if you want and still easily deploy to arm64 servers.

> Explicit allows being all you can do in an IAM policy were easy(ish) when there was a handful of AWS services and API actions. As there were more and more services and policy actions etc. they became unwieldy.

How does adding more AWS services to the platform make following least-privilege unwieldy? Surely your workload does not need permissions to each new service, so new services and new IAM permissions being available is a no-op.

My Pixel 4a definitely did not the last time I ran into one of these.