Let me give a concrete example. Hardware "passkeys" - FIDO2 authenticators - are designed such that their credentials are bound to a particular Relying Party (web site). Browsers enforce this by sending the current web domain the user is on to the authenticator when Javascript tries to list, create, or use a credential.

This would be completely broken if Javascript talked directory to a FIDO2 USB device, because the JS could send a Relying Party that is NOT the web site on which the user currently lands.

So Chrome blocks WebUSB from communicating with USB devices whose USB HID descriptor "looks like" a FIDO one, by some hardcoded "not this device" blacklist code in Chrome itself.

But what if what you have connected to your computer is a USB NFC card reader, and the user taps their FIDO authenticator on that? Letting the Javascript communicate directly with the card reader breaks the FIDO security model exactly the same way... but Chrome allows it!

The problem with WebUSB is that it exposes devices that were built under the threat model that only trusted code would be able to access them to untrusted code. The set of devices acceptable for WebUSB use should have been a whitelist instead of a blacklist to be secure. Letting the user choose the device to grant access doesn't solve the problem, because the user doesn't have a way to understand what will happen when the site is granted access, per the FIDO example I gave above.

To you it might be obvious our brains are different from a network of weights being reconfigured as new information comes in; to me it's not so clear how they differ. And I do not feel I know the meaning of the word "know" clearly enough to establish whether something that can emit fluent text about a topic is somehow excluded from "knowing" about it through its means of construction.

But we don't appear to have entirely done that yet. It's just curious to me that the linguistic structure is there while the "intelligence", as you call it, is not.

I don't really understand why this type of pattern occurs, where the later words in a sentence don't properly connect to the earlier ones in AI-generated text.

"The probability just moves" should, in fluent English, be something like "the model just selects a different word". And "no warning appears" shouldn't be in the sentence at all, as it adds nothing that couldn't be better said by "the model neither refuses nor equivocates".

I wish I better understood how ingesting and averaging large amounts of text produced such a success in building syntactically-valid clauses and such a failure in building semantically-sensible ones. These LLM sentences are junk food, high in caloric word count and devoid of the nutrition of meaning.

This is not, technically, true. We could have globally-routable, unique, random-esque IDs if every routing device in the network had the capacity to store and switch on a full table of those IDs.

I'm not saying this is feasible, mind you, just that it's not impossible.

If your computer is compromised after you've already entered the PIN, or there is an app running on the computer but it is not sufficiently privileged to sit in between you and the TPM, no.

That's quite good protection generally. The defense against this type of attack is to get a smartcard reader with an on-board PIN entry keypad - those do exist, but it's quite a step.

The PIN can be an arbitrary string (password).

If you ever want to answer this type of question yourself, you can look at the size of the model files. Loading a model usually uses an amount of RAM around the size it occupies on disk, plus a few gigabytes for the context window.

Qwen3.5-122B-A10B is 120GB. Quantized to 4 bits it is ~70GB. You can run a 70GB model in 80GB of VRAM or 128GB of unified normal RAM.

Systems with that capability cost a small number of thousand USD to purchase new.

If you are willing to sacrifice some performance, you can take advantage of the model being a mixture-of-experts and use disk space to get by with less RAM/VRAM, but inference speed will suffer.

In a Jetbrains IDE, for example, you check a devcontainer.json file into your repository. This file describes how to build a Docker image (or points to a Dockerfile you already have). When you open up a project, the IDE builds the Docker image, automatically installs a language-server backend into it, and launches a remote frontend connected to that container (which may run on the same or a different machine from where the frontend runs).

If you do anything with an AI agent, that thing happens inside the remote container where the project code files are. If you compile anything, or run anything, that happens in the container too. The project directory itself is synced back to your local system but your home directory (and all its credentials) are off-limits to things inside the container.

It's actually easier to do this than to not, since it provides reusable developer tooling that can be shared among all team members, and gives you consistent dependency versions used for local compilation/profiling/debugging/whatever.

DevContainers are supported by a number of IDEs including VSCode.

You should be using them for non-vibe projects. You should DEFINITELY be using them for vibe projects.

If we're talking about a predictive model like current LLMs, you can "make" them do something by injecting a half-complete assent into the context, and interrupting to do the same again each time a refusal starts to be emitted. This is true whether or not the model exhibits "intelligence", for any reasonable definition of that term.

To use an analogy, you control the intelligent being's "thoughts", so you can make it "assent".

This is in addition to the ability to edit the model itself and remove the paths that lead to a refusal, of course.

"I was at the library" is firsthand testimony.

"I saw her at the library" is firsthand testimony.

"I saw her library card in her pocket" is firsthand testimony.

"She was at the library - Bob told me so" is hearsay. Just look at the word - "hear say". Hearsay is testifying about events where your knowledge does not come from your own firsthand observations of the event itself.

Malicious code can't be injected at boot without breaking that TPM.

It talks about whatever you used to authenticate and the platform can manipulate (or omit) it.

It's Play Services that does not support this combination, likely to shepherd you towards Google acoount usage. Alternate Android apps work fine.

Next up, backups stored as layers in the same OCI registries.

I am not, however, sure ostree is going to be the final image format. Last time I looked work was in progress to replace that.