packetlost

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.

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.

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.

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.

I don't think electric trucks are actually ready for the realities of long haul trucking, especially in a country as expansive as the US.

Modern hardware mostly benefits from the optimizations made for older hardware too, so I'm not really sure what your point is.

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.

And more power to you. I find the SQLite database of plain-text to be a worthwhile tradeoff to grow past the limitations of plain markdown files.

Honestly, using AI helps me get more done in a day because I can delegate some decision making to it, usually inconsequential stuff.

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 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.

I've enjoyed it so far.

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

This [0] refers to their warehouse workers, but I've heard of similar problems during the earlier 2020s engineer hiring boom (on reddit iirc)

0: https://www.theguardian.com/technology/2022/jun/22/amazon-wo...

That's true to a point, but Amazon is finding out the hard way that eventually the well of people willing to put up with bullshit runs dry and it becomes much harder to get actually good talent or workers.

Meta needs to be careful IMO. The subset of capable people willing to work for a company as demonstrably evil as them is not infinite.

I believe at least one of the two official Minecraft implementations use it for their map/save format.

The only issue is pandoc is a pretty heavy dep. A fantastic tool, but a very heavy one.

Not that I don't agree, but PKI relies on a trusted authority which can be compromised. If you're running a trustless system, basically any party can be compromised but the blast radius is limited to just the compromised infrastructure and money, not the entire system.

"If I split a file in two I still want to be able to see blame correctly for the author of the function, not one file as freshly created and the other with a bunch of deletes." > Now this is a good idea that I've never seen in a VCS.

There's a reason no one has done that, the VCS would have to have a semantic understanding of what it's tracking. I'm sure that's possible, but I think would see extremely limited success. Honestly, it may have even been done for proprietary languages and VCS systems that have since faded into obscurity.

I'd settle for searching the git history for a particular regex/string and then running a blame on that.

I don't want the same account I use for social for my code

Then create separate accounts?

Based on my understanding, PLC is centralized primarily because there needs to be a global, authoritative source of truth for the current state of a given plc. You could in theory namespace a plc to a particular directory instance with a backwards reference or something, but I don't think it buys you anything when in theory you can just choose to trust a different PLC directory at the read/application layer if you really need.

At the end of the day, truly fully decentralized systems are literally impossible, there's always a centralized aspect (at least for bootstrapping) and it's usually DNS-shaped.

That being said, PLC directories are a problem that blockchains (yuck) actually solve very well: trustless, public ledgers. I would not be surprised if we see a separate implementation based on an architecture derived from such systems.

I get most of my electricity from solar farms through my local utility provider!

Companies are also much more inclined to spend money to solve a problem while hobbyists are much more likely to get enjoyment out of the process of building. I'm firmly in the latter category, having built a rather robust ZFS array on NixOS with a pretty gnarly NVMe cache hierarchy built on LVM. It was fun to do.

I feel like submodules could be a lot easier to work with if the git command made it easy to update all submodules in one go based on branch head for the submodule.

it's kinda abandonware at this point

That's sad. I'm a fan of rxi's work, including this one.

Why do you like gpt-oss-120b less now? What replaced it?

It really isn't comparable. Sure, nixpkgs is huge, but the surface area for what you need to understand and work with is considerably smaller. They aren't even really in the same domain anyways. I was able to get very comfortable with Nix(OS) in a single weekend, but it took me months to get to a similar level with the K8s ecosystem.

I use NixOS with nginx + acme / caddy, coredns and no docker anywhere. It's extremely homogeneous, easy to scale out (add another flake output, deploy to a new server, update DNS records). You could easily automate some of that with more nix, but I don't bother because that's already only like 50 lines of config.

I have a strong preference for renting bare metal and it has served me extremely well.

The driftless area certainly has some truly beautiful parts, but my statement is less about the homogeneity across the entire region and more about the distance between any notable landmarks. Hills alone aren't really that interesting either and I stand by my statement that most of the Midwest is boring and flat.

The Midwest in particular is extremely homogeneous and flat, mostly plains and farmland for hundreds of miles. The West cost has more in 15 miles than the Midwest has in 100, on average. There are pockets here and there, but not enough to warrant the several hour drive it will take to get there.

Honestly, most of the US is like this. It's huge and very, very sparse.

And trash your short-term memory? Nah, smoking weed is straight up bad for most people.