packetlost

Oracle banned AI code for copyright reasons, you cannot interpret that as a assessment of the practical output of the models.

As someone who has mostly written Rust and Python over the last 10 years... yeah. Go is actually a really solid choice for Agents IME

CL and Janet both come to mind as supporting image-based deployment.

I've had a good time using my Google Home devices exclusively as kitchen timers and music playing devices, though they semi frequently get song requests wrong.

There are Lisps with similar semantics. It faded (further) out of popularity for a number of reasons, but it still has its niche.

> The one thing that falls over is that the webhooks are actually self modifying code since you have an 'on commit' webhook that bootstraps the actions logic from the workflow.yaml file(s) (which are not really config files, they have logic that needs to be evaluated).

Sure, but the part that actually schedules where a 'job' gets run is based on a relatively simplistic tag system. Reading the yaml and plopping some job metadata into a queue-like system isn't where I would expect their issues to be, but at their scale I'm sure everything becomes fragile and inscrutable.

> imagine you schedule a job, and there's no runner available. How do you disambiguate between no runners available because you've reached capacity, runners not being available because they're on a real network with faulty connections, and runners not being available because of a faulty rollout of internal updates?

You don't need to. GitHub Actions runners, and most CI runners that I've interacted with appear to have a pull-based model where they ask for work that matches their declared tags/shape (usually platform/runtime/OS/etc.). This probably amounts to a database query, but who knows.

> A simple message queue for job scheduling is fine if you own everything and can deal with the operational overhead of identifying those cases by hand, but Github can't do that.

I highly doubt it's a simple message queue. My issue is git repos and their CI infrastructure have very low coupling to other repos or entities in most circumstances, at least conceptually, so parts of the system (ie. regions, shards, etc.) should be able to function even when others are down (ie. it shouldn't break for everyone). There's clearly centralization and coupling that isn't obvious from an outside perspective, which sorta tells me it's incidental, but that's a guess.

The only statement I'm making about their system is that it appears to be poorly designed, as evident by their poor uptime. The rest is just visible details about what data is involved in performing the task at hand, agnostic to the implementation underlying it.

That "scheduling" is just a git hook and a message queue, maybe with some database updates in between with very clear boundaries that make sharding easy to reason about, assuming they have a sane architecture (they evidently don't)

That kind of thing is extremely rare in the US sadly.

Unfortunately coding is a perishable skill, unlike walking which is at least partially ingrained into our DNA.

You really can't appreciate how awesome Clojure is until you're coming from Java, can you...

Zitron is a hack who sells anger to people who don't know any better. Just because he's right about some things doesn't mean you should give him the time of day.

Sure, but you can still use a Titan T3 or recent Yubikey model on an iPhone. If I had the threat model to justify it, I would not set up the passkey in Apple's infrastructure.

It is too bad they ignore that though. That's really disappointing.

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