(There are also some boxes made specifically for this, usually sold as development platforms for STB products, marketed based on what SoC they contain. Though they’ll tend to be $200, while the random “finished product” streaming box will be more like $30. Both come with decent remotes.)

It’s only when you want to let them jump in and out of multiple apps (e.g. pick what game they want to play on their own) that you start having a problem.

(And the not-idiomatic-but-people-do-it-anyway solution for that, from what I’ve seen, is buying one extra iPad, and creating a special whole-family Apple account for it, to effectively serve as a game console for the kids.)

Though with the weird proviso that every so often, each cell opens up its cabinet of blueprints and just 3D-prints up one of every tool it has a blueprint for, unless sees a sticky note on the blueprint telling it to skip (silence/suppress) printing one of that tool for now.

(And, if anyone is wondering, this strategy of "just always print all tools unless otherwise specified" works because these tools are mostly very flimsy, breaking/being consumed quickly after just a few uses, sometimes as little as one. So there's a constant need for new prints of most of these tools. The ones that are more durable, the cell has to be more careful to not overproduce.)

I say that "tool blueprints" is a useful model, because it makes it more intuitive that e.g. for the important stuff, the genome keeps a pile of duplicate blueprints for the same tool; and then also keeps some machinery (autosense suppressors) to add and remove notes to those blueprints on observing that there's "enough" or "not enough" of the tool floating around inside/outside the cell. Which allows "having N redundant tool blueprints" to work just like "having only one tool blueprint" does, rather than drowning you in printed tools; yet also ensures that if something scribbles over one of the blueprints, everything "just keeps working", since the machinery will just end up unsilencing the other blueprints more often. (And also, as a bonus, allows the "corrupted" duplicate blueprints to act as forks of the parent blueprint, gradually being redrawn over N generations of mutations into a working blueprint for a new tool, much more quickly than a new tool blueprint could be mutated into existence from scratch, and without losing the ability to produce the original tool in the process.)

---

Oh, and to be even more pedantic, it's probably best to think of genes as tool part blueprints, since several proteins might need to come together and link up to make a functional tool; and since a single part might end up being consumed in the creation of several different tools. (But that doesn't really add much to predictive intuition, unless you're trying to predict the precise failure modes of any particular tool's production under a point mutation of a single part. You can mostly forget about it.)

That being said, AFAICT, the diagrams are also basically irrelevant to the article in its capacity as a high-level overview of the project. You can just ignore them for the purpose of reading the article.

It’s when digging into the project source code that you should look at those diagrams, and then feel frustrated by how much they suck. :)

===

[1] This seems to happen a lot with LLM-generated code docs / diagrams / etc, when the docs are written in the same session as the code itself, but later; the LLM seems to see the docs as “following” the prior work in its linear context, and so mistakenly writes as if the reader of the docs will have also read whatever’s in the context before getting to the docs. That assumption, of an incrementally-growing shared context that can be implicitly made reference to by “later” text to compress that “later” text, makes a lot of sense when generating one long linear stream of prose, or even when generating a series of chain-linked entries (like conversation responses, or chapters of a book); but doesn’t work out when generating a web/graph of separate bits of text. This is kind of a fundamental flaw in producing coding agents as fine-tunes over conversational base models, and it’s one that coding-agent harnesses have yet to really focus on addressing.

I'm pretty sure it is used for this; but rather than for anything nefarious, my guess is that this info is then fed to a classifier model to ensure that users of ChatGPT-the-service (as opposed to the OpenAI inference API) are actual humans, rather than agents trying to circumvent having to pay API pricing.

The Linux kernel is ultimately a friendly open-source project. There's no harm in it being marketed using a cartoon penguin.

These AI services, meanwhile, are the dangled lights on the heads of data-hungry environment-threatening job-killing leviathantine anglerfish.

Making the dangled light present as non-threatening is not a good thing for society, no matter how much you may personally like pretty lights.

My understanding of Jev is that it’s a replacement for the LLM you’d necessarily need to use to identify reasoning-sensitive workloads in a heterogeneous mix, where Jev will be cheaper than an actual LLM and so act as an actual optimization / de-bottlenecking change.

This works for immutably recording the current time into a log, yes.

For much else (e.g. a timer still-to-come that should go off in “1000 days”), leap seconds break this.

You could store such time using TAI as the timezone (TAI is UTC without the leap seconds), if RDBMSes actually persisted the timezone. But they don’t. They’ll just convert back to UTC at point of write.

I have a feeling that most people who really need to solve this problem end up using a (pos, len) column pair where `pos` is the current UTC time when the future-event was registered, and `len` is an interval representing how far away it is in monotonic time — either as a difference of POSIX timestamps at time of evaluation, or as a SQL INTERVAL, etc.

Er… just write '2026-02-28 16:00:00-08Z'::timestamptz.

Were you maybe thinking some kind of wire mesh, like the "washable pre-filters" in air purifiers tend to be? I did initially consider this; but, after running the air scrubber for a few months and seeing what actually builds up in the pre-filter, it seems like the pre-filters don't actually end up being coated in anything (dust/hair/etc) that can actually be rubbed/scratched away or even vacuumed out of them. Rather, just end up gradually blackening (due, I think, to fine [PM2.5] particulate making it partway through them before gradually embedding deep inside them); and gradually feeling more and more "skudgy" to the touch (due perhaps to some of those particulates being hygroscopic, and due to also trapping things like pollen/mold spores.) You can actually touch the surface of the fouled pre-filter and your fingertip will come away clean (but touching it won't be a nice sensory experience.)

I think, for helping with that kind of particulate, a wire mesh wouldn't do much if anything. The only "passive" thing that would help is a non-woven cross-linked fiber material, porous enough to not overwork the air scrubber's fan to the point of making it work harder / be louder / burn out sooner, yet layered and "internally labyrinthine" enough to capture particulate despite that porosity. I.e. the same material used in the pre-filter.

(If I could add an active component, I might introduce an intake-side ionizing air purifier, where particulate gets charged and then preferentially deposits onto the fins of a washable heatsink-like grille. AFAIK, those don't normally work at the sort of CFM being pushed by the air scrubber. But if anyone wants to design a better mousetrap here, that might be a direction to look into.)

What ended up making a difference for us, is buying a portable industrial air scrubber, of the kind construction/remediation sites use to clean the smoke and dust (and mold, and asbestos, etc) they’re generating out of the air before it gets vented outside (see e.g. https://a.co/d/01lTtyuZ); and plumbing this machine into our apartment in reverse: putting it out on our (covered) balcony, with it exhausting the “scrubbed” air into the apartment. (I made a little sliding-door shim of the type people use to pipe portable AC units outside, just with the hose on the other side.)

Generally works great. We run it on a very low speed, so it’s surprisingly quiet (no louder than other fans we have for air circulation, and a more pleasant frequency because of the large diameter of the fan it has inside.) The pre-filters get absolutely caked with exhaust and road dust after ~2wks, and start to let through an odd stench at that point, so we’re actually replacing those faster than even is recommended for the industrial use-case. But the actual main HEPA filter inside the unit seems to last longer than in industrial usage.

(If you look, most other toggles that appear under "Content & Privacy Restrictions" are for similar things: things Apple provides no more-visible setting to disable; because they think you have "no reason" to turn these features off; because these features are, at least in Apple's opinion, "unobtrusive" [i.e. only really doing something if explicitly activated] and "costless.")

In contrast, I presume the underlying setting identifier, as appears in `defaults` and/or MDM profiles, has a more sensible hierarchical prefix based on what potential risks an organization would see in a roll-out of LLM use.

ETA: yes: the macOS settings domain for "LLM stuff" is `com.apple.applicationaccess`, and the declarative-configuration namespace is `com.apple.configuration.intelligence.settings`. Neither of which has anything to do with parental controls per se (though `com.apple.applicationaccess` is generally where MDM settings related to preventing employees from using "potentially insecure" device capabilities live.)

There's also the declarative-configuration namespace of `com.apple.configuration.external-intelligence.settings` ...which is a bit of a bass-ackwards use of their own declarative configuration model, since if it had been `com.apple.configuration.intelligence.external.settings` instead, then the settings in the enclosing "intelligence" namespace would serve as fallback defaults for the external-intelligence specific settings. Ah well.

Such managed inference providers have (for now) plausible deniability of behaving ethically (at least enough that they don't get boycotted / scare away investors) due to them being "blind" to what gets run on their systems. They're acting as the inference equivalent of data transit carriers.

But I don't think it would be possible for managed inference providers to publicly expose "runtime activation steering" in the way antirez's DS4 does, without that reading much more explicitly as them inviting unethical workloads.

(Yes, there are other things you can do with runtime steering. But almost all of those things are workload-specific, relying on you privately tuning to the needs of your own dataset. And if you can do that, you can run inference without the help of a managed inference provider. The only time a customer will come along with a pre-made runtime-steering vector file in hand, is if that vector is an alignment-orthogonalization vector.)

Self-synchronization is the idea that if you take an arbitrary Unicode-encoding-encoded text stream, and then do any combination of 1. flipping bits in it at random, 2. injecting random extra whole bytes into the stream, and 3. dropping random whole bytes from the stream, then each such change will corrupt at most one Unicode code-unit in the stream, and from that, corrupt at most one semantic grapheme-cluster encoded by the stream. No such change will corrupt the stream itself so as to leave the stream in an invalid/indeterminate state that a Unicode parser can't know how to recover from. You'll have a one-character-wide "hole", and then the stream will resume. Unless that hole occurred at a character that's critical to the stream's meaning on an application-semantics level, the document will still be valid/useful (especially for archival/forensic-recovery purposes); just like a printed document is still valid/useful even if you drip a bit of ink on it.

Unicode encodings are self-synchronizing at the byte-pattern level. But, much less often discussed, Unicode itself is also designed to be self-synchronizing in how it encodes interactions between code-units. (In other words, Unicode is designed to never have modal or stateful semantics, beyond the boundary of a single grapheme cluster.) And this really constrains how certain Unicode features can be, and historically have been, designed.

If you want a run of Unicode code-units to all be "tagged" or "colored" with some property, then, due to the self-synchronization requirement (i.e. due to the assumption that any single one of those bytes could be corrupted or blown away, including whatever metadata-encoding bytes your scheme wants to use), you have to either:

- define a "pre-colored" alphabet, and express your tagged content in that alphabet. (Think of e.g. the Unicode flag codepoints [https://en.wikipedia.org/wiki/Regional_indicator_symbol], which are essentially a special namespaced copy of the roman upper-case alphabet intended to be used only to spell out two-letter contiguous pairs that are [or at some point were] valid ISO country codes; where, when used in this way, the resulting 'colored'-letter-pair sequence has 'flag semantics', i.e. is meant to be rendered as a flag and machine-legible as a flag)

- or individually tag each and every one of those codepoints with its own tag/color codepoint (as in Unicode variation selectors)

- or interject binary-infix "operator" codepoints as glue between each codepoint in a codepoint sequence, so that those "operator" codepoints each affix together their immediate sibling codepoints, essentially constructing an abstract-Unicode-semantics list ADT "cons by cons", so that said list then may then be assigned its own semantics, e.g. being treated as a single grapheme-cluster with its own rendering (as in e.g. ZERO WIDTH JOINER used in its role in constructing complex emoji)

These encodings are all very high-overhead; but these are the kinds of trade-offs you have to make for self-synchronization to work.

And these trade-offs are sensible to make... if you're Ken Thompson in 1992, having to consider e.g. plaintexts being transmitted over raw RS232, or filesystems that just blast bytes to a spinning-rust disk without so much as a checksum, and then read them back "blindly" years later with that disk potentially highly-degraded.

But what if you live in the modern world, and you only care about holding and manipulating known-length strings in memory and/or embedded into code-signed (and thereby hashed) binaries; checksummed-block filesystems over rarely-corrupting NVMe; and transmission of data mostly over encrypted-stream protocols, where even the rare packet-level corruption that still TCP-checksums correctly, doesn't decrypt successfully, and therefore causes TLS-level retransmission?

Well, then you could define a much-more-concise reformulation of Unicode, that uses all the "forbidden" semantics-encoding techniques that Unicode itself avoids due to the self-synchronization constraint.

Where by "reformulation", I mean: a standard that keeps parity with Unicode in terms of what it can encode; and which at all times maintains a clearly-defined lossless bijective transformation between it and Unicode, evolving in lockstep with Unicode; but where Unicode and this formulation have their own distinct universes of codepoints, that compose using different rules, into the same ultimate sets of reachable grapheme-clusters with the same text-segmentation/collation/etc semantics.

I'm honestly kind of surprised that there isn't already a project somewhere to define an alternative Unicode formulation that looks like this.

It'd not only be potentially a highly-efficient representation for many in-memory string operations (that text shaping libraries would also love); it'd also likely perform impressively (compared to regular UTF-8) as a canonical representation for documents used to train+prompt LLMs. It'd give "more meaning per token", via all the repeated-per-codel overhead becoming once-per-sequence overhead; and it'd also allow many layers of meaning that are currently encoded via in-band protocols (ANSI escape codes, Markdown, HTML/XML, etc) that the LLM needs to learn additional recognition logic for, to instead be parsed out "during" initial text-stream recognition.

(And it's taking me real willpower not to go into depth on all the features such a formulation could have, and all the benefits it could provide. I should probably stop here before I nerd-snipe myself!)

I think this is because the JRE/JDK upstream releases are a bit like Linux kernel releases: all the major first-party feature development goes on in subprojects that maintain their own "living forks" during feature development, with the teams on these features doing PRs against the fork's own "main"; that "fork's main" having its own subproject maintainers who ensure a mess isn't made of it; and then those maintainers eventually polishing up that fork-main into a single big one-shot PR to upstream once the feature-as-a-whole is ready.

(Compare/contrast: the Linux kernel's mm, rt, and kvm feature development efforts.)

Because of this, the top-level "project maintainers" (i.e. the people who decide what gets merged into upstream main) aren't really the same people as these subproject people who care deeply about these new features. They want to ship stuff people want, but they personally mostly deal all day with requests to merge 1. small bugfixes, and 2. features so small that no JEP is needed.

But then, every once in a while, they have to deal with a request to merge one of these huge subproject upstreaming PRs. And sure, it's already heavily reviewed by the subproject's maintainers, who they trust. But they do still have to audit it and learn it and create a stabilized release path for it. "Handover" stuff. And that's tiring!

So, given that the toplevel project maintainers write the release notes, I'm not surprised they come off as weary about releases.

(That being said, for purely PR reasons, the toplevel maintainers could ask the subproject staff to contribute their perspective to the release notes of a release that merges their work? But this could also just-as-well be a separate blog post—which would probably be better for sharing. I don't think I've ever seen a centralized Java blog [is there one?] but I think the subproject teams do tend to have them.)