Yet https://linear.app/Homepage doesn't scroll without jank on mobile.

    Copyable vs Non-Copyable passkeys
    Transferable vs Non-Transferable passkeys
    Hardware-Backed vs Software-Backed passkeys
    User-Present vs Non-User-Present passkeys
    User-Verified vs Non-User-Verified passkeys
    Attested vs Non-Attested passkeys

    Roaming vs Platform passkeys

This is what e.g. PayPal uses to prevent you from using your Yubikey as a passkey, while it works perfectly as a passkey on other providers (e.g. Wise bank)

It's checkable in the browser with e.g.: `await PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable()`

What makes you bet that?

As far as I know, the kernel doesn't have any official CI. People test as they feel like it. Some people/companies build some CI initiatives, others don't use them.

https://lwn.net/Articles/972713/

Also the kernel has > 10000 Kconfig options. Somebody told me that 2^64 is a lot, and that 2^10000 is a lot more.

There are lots of cases of "we wrote our own X, here's how it works", but rarely the concrete internal knowledge shared about what existing Xs can't do and why.

When the motivation stops at "look, the naive thing wouldn't work" even before the "normal" thing everybody does (fetch), it leaves many open questions to which you probably have an answer already.

> password doesn't show up you know there's a problem

Here is your contradiction.

The normal person will just assume that some tech isn't working today again.

A key point of passkeys seems to be that it guarantees to the site owner that the user cannot be phished, without having to make assumptions on whether the user is tech-stupid.

As the article explains, "over 600 PB" = 25M code checkouts * 25 GB "compressed working copy".

So "fetched naively" here means doing a full `git clone` on every need for `git checkout`, which of course nobody should do, nor does that refer to "code that needs changing daily".

So probably its RSS usage is just mostly its own executable code?

If anybody can create any software anytime, everybody gets a lot of the Four Freedoms of Free Software (change it to make it do what you wish, distribute your modified version, etc), without even "having the source".

And all the programmers constantly feeding their new code into training is the contorted version of GPL'ing it.

Anyway, the website seems to be fixed now, nice!

This stuff is still so user unfriendly.

Why cannot the software just save the desired setting to set it when the device comes online next? I feel like many things in zigbee2mqtt are like that: I click something, it fires off some message and it often isn't clear if that worked, if it'll work later, and so on.

If you can boostrap one version of stagex (so that its mold is trustworthy), I don't see why you can't use that to build another version of stagex.

As you say, you can rely on the cached binary because nothing in the old version's supply chain would change; it is pinned, and as long as you can build that, everything is fine.

https://delaybahn.com/en/?fromId=A%3D1%40O%3DK%C3%B6ln+Hbf%4...

Click the "+30 min (28/30 days)" tags to see the delays of the last month.

I also find Haskell's concurrency in practice much easier to reason about than Go's, let me do a pitch:

In Haskell you can just fork a thread and block till it's done. Threaded, "async" logic just looks like blocking serial code (but isn't blocking). I feel like in typical channel-based Go code I have to jump and scroll a lot in the code because of all the message-passing instead of block-scoped "blocking-style" variable use, and that this makes it hard to conclude whether the whole thing terminates or deadlocks.

In Haskell, channels are considered low-level concurrency primitives you should only use when you have no clean high-level primitives for it. This is because they are not "structured" concurrency: When you send something into a channel, it is gone out of your scope, and you now need to track in your brain where it is, and who should consume that thing in the right way ("message-passing").

For example, in Stolon, a high-availability Postgres orchestrator written in Go (https://github.com/sorintlab/stolon), I found the logic for failover with multiple channels and various timeouts very difficult to reason about when investigating failover bugs. I'm pretty sure that would read much easier in Haskell (see below how).

In Haskell, you can start 2, or N, things in parallel, and easily wait till they are done. You can invoke parallel `map` easily.

    results <- mapConcurrently f mylist

You can get bounded, steaming parallelism, easily.

You can set time limits to function calls writing

    timeout 1000 (myIoFunction ...)

You wrap the 2 words "timeout 1000" around your function and done.

Concurrency _composes_ in Haskell. You can write

    res :: Maybe (Maybe a) < timeout a (timeout b (myIoFunction ...))

You can build trees of parallel operations that live and die together.

And there are no data races (because mutability is a very explicit thing), and I'm not even mentioning STM here (which allows you to do database-style transactions across variables) because that's already pointed out in another post.

As a composed example, in Haskell you can write:

    timeout 1000 (race (downloadUrl ...) (forever (putStrLn "Still loading ...")))

If you enjoy concurrency, give Haskell a shot!

I believe Go didn't originally have it, and added it in 2020, 14 years after Haskell.

> integer literals become i32, float literals become f32

Don't use the shitty small sizes that have introduced countless bugs over the last decades, as a language default.

Especially if you care about correctness.

i32 is all over the examples.

Use 64 bits, like Python and Haskell; even JavaScript and thus TypeScript got floats right defaulting to f64.

Killer feature!