derefr

“Origin” isn’t part of the Pareto frontier because it’s not a quantitative dimension.

(You could say that “ability to be trusted by US government/military users” is quantifiable, but I would argue that by that metric, this model falls behind non-US-originated open-weight models that have more eyes on them!)

Fun fact, the word “cooties” didn’t originally refer to a fictitious infective agent spoken of by children; it was originally a nickname for body lice.

> Coined during World War I by British and American soldiers in the trenches of Belgium and France to describe the pervasive body lice that infested their uniforms. The word likely traces back to the Malay word kutu (parasitic louse).

Funny enough, the same sorts of activities that can “give you cooties” can in fact spread cooties (the real ones.) Though mostly due to physical proximity and skin contact.

To be crystal clear, this internal framework and these databases exist as tweaks to make these words be autosuggested to / autocorrected to more often than they would be before the tweak.

Also, not only Windows and Android but even Linux (aspell / hunspell) also have+use “don’t suggest this word in autosuggest” metadata tags in their dictionary databases.

No? Presumably the one base-model clock would be the canonical clock writing its idea of the time to the bus. No need to read it, and no need for a hidden clock anywhere.

I think HDMI-CEC is just fundamentally broken (at least in all versions of the spec up to now.) I've played around with hypothetical workarounds, and I suspect so have many device manufacturers, and it seems like there's just no way to "stabilize" an HDMI-CEC network into behaving correctly while there's at least one bad actor on it, if you can't directly modify the firmware of that bad-actor device. You can't do it from a peer device; you can't do it from a "man in the middle" like a switch; and you can't even do it from the TV.

Why? Because the HDMI-CEC bus protocol, as it stands today, has no separation of responsibilities/phases between "request" and "response" messages, or between "command" and "event" messages.

Imagine how you or any other reasonable person would design HDMI-CEC. There'd be one "leader" device (probably the TV) whose opinion on the current active source / signal-path is canonical for the whole bus. Other devices would send command messages to this leader device to get it to change the active source. The leader could ACK or NACK these command messages. If the leader accepts the change, the leader would broadcast an event message declaring to the bus what the new canonical active source is. And if a device misses that message, it could also query the leader device to find out the active source.

But that's not how any of this works. Instead, at any time, any device on the bus can just outright say "I'm the active source now." And every other device on the bus that receives this packet, must then update their own internal HDMI-CEC state-machines to consider that device to be active. If something (the TV, say) disagrees with this assertion, it can't just ignore the packet, because everything else on the bus won't have ignored it. So even if the TV had logic telling it to stay on source 1.0.0.0 rather than switching to 3.1.0.0, the soundbar (3.0.0.0) connected to said TV might have switched from playing the eARC audio stream from the TV to playing audio directly from its downstream 3.1.0.0. And 1.0.0.0 might have gone to sleep in response to seeing the message that 3.1.0.0 is now active. Etc.

The only legal thing a device that wants to "prevent another device from making itself the active source" can do, under HDMI-CEC, is to steal focus right back to itself (or, if it's a TV, assign focus right back to the source it remembers.) Which means everything on a bus sees the active source flapping back and forth.

Which is where all the stupid "your TV takes 30 seconds to turn on because it's flapping between three inputs" stuff comes from.

For some reason AI coding agents seem to think a README should be a Product Requirements Document (PRD).

I think it's because most projects don't have any settled place (or at least, any place that lives inside the project's source-code repo) to record PRD-like information.

But because AI coding agents really do benefit from having PRD-like info (i.e. a hierarchical breakdown of the "intended what" and "intended how" of the system that "should" exist in the repo, kept updated to reflect changing ideas about those intentions), they really want to record that type of info somewhere, so they can then reference it.

AI coding agents don't seem to have any "taste" (or maybe "confidence"?) when it comes to asserting that even if you don't already have a separate PRD-like file in the repo, you should have one, if you want the agent to do its job well, and so it would request you to let it create one (or just automatically do it.) Instead, they just shrug and cram the PRD stuff into whatever structure you do already have. Which, if you're starting fresh with a greenfield project, is usually just a README.

(I hypothesize that if you tell an AI coding agent to use Behavior-Driven Development [BDD] on a greenfield project, it'll probably lean toward maintaining its PRD-like info in the form of BDD test cases. Haven't tried this experiment yet; would be interested to know the outcome!)

> have it boot to HDMI1, hook up an external HDMI-CEC switch

That's not actually how HDMI-CEC works. HDMI-CEC switches aren't KVM switches that only do HDMI.

An HDMI-CEC switcher box (or devices with that functionality built into them, like many soundbars) doesn't act as its own isolated sub-HDMI-CEC bus, where the switch presents to its downstreams as the root HDMI-CEC device, catching (without bubbling) <Active Source> messages from said downstreams, selecting one downstream to be active in an internal sense, and then presenting itself to its upstream connected TV or what-have-you as if it's one leaf-node source whose video+audio signals just-so-happen to be those of the currently-selected downstream.

Rather, at an HDMI-CEC level, an HDMI switch is a lot more like a USB switch: it passes through all the CEC message broadcasts from all of its downstream source devices through to its upstream receiver device (and vice-versa), sometimes also interpreting them in turn for effect; and the root host device can actually see the whole tree topology, including any switches.

(Fun fact: HDMI-CEC devices have four-step hierarchical addresses, that look like IP addresses, describing at each step the physical socket-number offset on the upstream device that connects said upstream to the given downstream. The TV is always 0.0.0.0. Whatever's plugged into the TV's first HDMI socket is 1.0.0.0. If that thing is an HDMI switcher box, then whatever's plugged into its first downstream HDMI socket is 1.1.0.0. And so on. All of these devices can see and talk to one another using these addresses, at all times. It's a network!)

Importantly, this means that if a TV is plugged into an HDMI switcher box, which in turn has several source devices plugged into it, then the TV will still be aware of, and can still hear and speak to, all the inactive sources downstream of the switcher box, not just the active one.

Which in turn means that if your TV is really stupid in the way it handles HDMI-CEC (e.g. trying to "argue" with sources about who's supposed to be active on wake, with the TV trying to force the last-active source and the source that woke the TV trying to force itself as the active source), then putting an HDMI-CEC switcher box in between will by no means improve things. They'll still be arguing, now "through" the switcher box; and the switcher box will itself be doing additional things in response to seeing these messages. Where previously you had O(N) HDMI-CEC problems, now you'll have O(N log N) HDMI-CEC problems.

But hey, at least your leaf-node sources in this tree all show up in the TV's input switcher menu! That was definitely worth making all this mess, HDMI Forum! :P

> especially named variables and struct fields

Don’t you get this from most macro assemblers? I know I’ve seen some very old and crusty ASM that nevertheless does structured programming and even limited OOP through macro-ASM facilities.

(That being said, symbolasm looks 1000x more ergonomic and “also communicates developer intent”-laden than any macro ASM ever did; and also is probably something you could learn once, while a project’s macros are specific to said project.)

Presumably the same effect that made every fashion designer at every sports shoe company decide simultaneously and “independently” to put the players they were sponsoring in pink shoes during the recent World Cup, despite each of these companies having incentive for their design to stand out.

Ask AI (roughly) the same question; get (roughly) the same answer. Regardless of what model you’re talking to.

(Why? Because every AI company consumes the same whole-Internet corpus and distillations of all their competitors’ models; of course all their models’ answers will converge, especially about anything subjective where they haven’t supplied a specific “right answers for domain X” training dataset to override the “base consensus.”)

I'm sometimes those things. I'm more often a writer and a futurist. I am enough of a writer specifically, to really not want to live in a world where AI-generated prose substitutes for human stories and essays; and I feel empathy toward other creative professions (most of my friends are visual artists) and don't wish to see that kind of thing happen there either. I do think we have to push back on things like that happening. And I do think that people trying to push toward that end for monetary gain are erasing much of the joy of being human.

But that being said. I don't think that our need to push back on that particular use of AI, has anything to do with the need to push back on AI itself. Because that's not the only, or to me even the main, point of (generative) AI.

(It's just that "generating wholesale slop that people end up seeing" is the usage-profile that the AI companies can most-easily intermediate and make money on; and it's also the usage-profile that makes it most obvious that "AI is happening", and so markets AI to people not already using AI. So this is the usage profile that all the AI companies benefit from everyone focusing the conversaton around AI on!)

I think a lot of people have a failure of imagination when they think about the upside of "good" generative AI. Which to me is, specifically, the places where generative AI can be better put to use as a tool in a workflow for human creative labor to pass through, rather than being something that substitutes for said human labor.

The programming example might be the most obvious to people here: generative AI lets you write e.g. a hairy SQL statement in the form of a very long natural-language description of the query, or an example of how you'd do it in an actual imperative/functional programming language, and have that transformed into SQL grammar. So you don't have to try (and fail) to remember the arcana of SQL (e.g. how to use things like correlated subqueries, or window functions with explicit windows, or CUBE), always eventually resorting to looking it up anyway. (This is really a condemnation of SQL for having specific one-off syntax sugar for every single thing it wants to encode, rather than a uniform syntax that can fit in your head / trigger IDE auto-suggest.)

But consider Photoshop's "generative fill" tool. Yes, if you're selecting entire huge regions of the image and running that tool on them, it's going to be "doing original work" and the results will be awful. But that's not the use-case the tool was designed for. It was designed to be a better version of content-aware fill, i.e. PatchMatch. If you select a dust speck or tear on a scan of an old photo and run the generative-fill tool over it, the result will usually just be a better version of what you'd have got by running the content-aware fill tool over it. (And if it's not, you don't need to try to fight the tool; you just drop back to using the other tools in the toolbox. Not every tool is applicable in every situation, and that's okay.)

Or consider that newer versions of Melodyne use generative-AI models to better separate audio stems into their own tracks. The input here is your own manually-performed track. The output here is also your own track. Despite being a generative model, the AI here is only generating an internal byproduct that gets discarded (hypotheses for timbre- and acoustic-matched reference instrument performances) to aid the classifier and reduce stemming error/residue.

(And apparently, the compressed-sensing models used by MRI scanners are getting approximately the same benefit by approximately the same means. Less familiar with this, but it's probably the most important benefit here since improving the fidelity of MRI reconstruction means doctors can be more sure that an opacity is really "something" rather than an artifact, and so will have more confidence to diagnose real problems earlier.)

Or consider generative AI used for automatic human-language translation (where it captures much more of the speaker's original meaning and nuance than previous translation models, at the expense of giving the result "LLM voice.") As AI improves at this task, presumably there will be less "LLM voice" and the result will just sound like what the person themselves would have said if they were bilingual, because... that's the task.

In none of these cases is generative AI "producing content." In these cases, generative AI is subsuming the role not of human labor, but of tools that were already used: of "by-the-book" approaches, of heuristic algorithms, of weaker ML models relied upon by heuristic algorithms, etc. But all of these cases benefit from generative AI being improved.

And, to restate my premise: there are many tasks just like these, where generative AI currently has no place (because replacing or "enhancing" any tool in the task's workflow with gAI would currently make the results worse), where you can expect to see gAI eventually replace or "enhance" some tool in the workflow, once gAI model companies turn their attention and benchmarks to trying to optimize for performance in those sorts of tasks.

Is it odd? I would guess that they're doing cost-plus pricing and the costs have been fluctuating with model revs.

Thus "increasingly" :)

• DS9 only had a little soap-opera drama, serving as almost a kind of fanservice sprinkled judiciously into otherwise-thematic B-plots.

• VOY had more, with entire B-plots of episodes now being character-focused, including a few arcs that would have worked just as well if transplanted into some modern-age military drama with no SF elements.

• Drama-as-the-A-plot episodes were appearing by ENT.

(After that I stopped watching, but I've heard the trend has just continued from there.)

You can be pro-"thinking AI is going to get really good and solve many problems" (i.e. be the sort of person who would "go long" on AI), while also being anti-"applying AI right now to domains outside of the few it's been specifically optimized for [e.g. coding]" (because in these other domains, AI is yet to approach, let alone surpass, "authentic quality" equivalent to that of a skilled junior professional.)

I have to hand it to Roddenberry, though; even though having no infighting produces a somewhat-unrealistic show, I think there's a solid justification to have the rule anyway. It prevented TOS and TNG scripts from being caught in tension between trying to "say something", vs. entertaining the audience with "low" soap-opera drama (of the kind you see increasingly in the later series.)

I have a feeling this might be no small part in why TOS and TNG are the two ST series that contain 90% of the "only comes up once" sci-fi plots / concepts / worldbuilding that people ever make reference to when talking about "things from Star Trek" rather than when talking about Star Trek. TOS and TNG, while definitely soft sci-fi, were to some degree trying to create 22-minute-long works of literary Speculative Fiction, modelled after the sort of things you'd read in serial SF magazines of the 1950s. Later ST series are emphatically not that, and nor do they try to be.

I think another, clearer way to state this hypothesis is that "the fewer business models a company has other than making money directly off your data, the more they're going to jealously hoard your data to themselves and leverage it in ways that don't involve letting any other middle-man capture it."

Meta and Google are both founded on the premise of capturing and using your data, with everything else being a loss-leader.

Samsung, meanwhile, makes the majority of its money making and selling physical "things", whether for B2B2C (SSDs, display panels), B2B (construction cranes, cargo ships, oil refineries, grid-storage EV batteries), or B2C (phones, TVs, smart fridges, etc.)

However, while this rule holds true in general, things aren't black and white here. While indeed, most companies that "just make things" that might capture your data -- the majority of phone OEMs and smart-TV manufacturers -- do just shack up with a middle-man to sell this type of Automated Content Recognition fingerprint data (maybe eventually acquiring said ACR partner to disintermediate their relationships with ACR data buyers), Samsung is in fact more software/data-oriented than the other phone OEMs / smart TV manufacturers, when it comes to how they handle the data coming from Automated Content Recognition.

While other providers rely on third-party ACR data brokers (the rent-capturing middlemen here), Samsung has a vertically-integrated ACR-to-ad pipeline, where (AFAICT) their ACR data feeds into their own ad-tech-bidding infrastructure for placement on Samsung-operated properties (the aforementioned phones, TVs, smart fridges, etc.)

…or that the person responsible doesn’t speak English (well enough to audit the quality of English prose), but had the AI write the code (and prose) in English anyway, for TAM reasons. In such cases, the person responsible probably read back the README and title the AI gave them, and “from what they can tell” it says what it they wanted it for say, so they approved it.

(I’m not 100% sure this happens with entire repos, but it certainly seems to be an increasingly-common explanation for entirely AI-prose-populated PRs and demo sites.)

> And as long as we keep letting them give us an option to buy out the ads, but then they get to stick ads on that option anyhow, we can never get our way out of ads on these things.

I wonder if we could regulate a requirement that service providers that serve ads must

1. offer "remove ads" as its own standalone/unbundled thing-you-can-pay-for in relation to any given product or service they offer

2. have at least one SKU of "remove ads" that isn't a subscription, but rather a one-time lifetime purchase, costed at at most the fair-market-value-set projected LTV of the profit they'd make from ads being served to an average user across said average user's lifetime use of the product/service

3. and where these "remove ads" payables must use wording that ties them to a very specific and regulatorily-defined contractual-relationship structure, where the contract cannot have a unilateral change-in-terms clause ("the terms of this contract may be changed at any time" etc); cannot have an arbitration clause (so while you might not be able to sue for product performance, you must be empowered to sue if the company ever again shows you an ad during use of said product); must have a successors-and-assigns clause (so buyouts don't void the contract, but rather obligate the buyer to now execute it on the company's behalf); etc.

4. and where the company is not allowed to factor in whether you have an active "no ads" benefit in calculating dynamic pricing for other offerings (i.e. they can't crank up the prices of their "with ads" product plans for "no ads" purchasers, because then they'd just hide the increasing cost of "no ads" inside the plan cost, effectively making "ad plan where you actually watch ads" and "ad plan where you don't watch ads because of your benefit" into two different SKUs, mooting the unbundling of "no ads".)

With such a regulation in place, companies could always increase the costs of their actual product plans and make them more expensive; and could still continue to bundle "remove ads" as a perk of some plans (slowly slipping upward through pricing tiers as it does today); but they'd be stuck serving anyone who buys a "remove ads" one-time purchase, the same way that those airlines that once offered "lifetime flights" as a limited giveaway were then stuck serving those customers.

Huh; I would have thought that importing MIT code into a GPL codebase (like the Linux kernel) essentially “beats out” the original MIT-licensing and instead creates an GPL-licensed fork of said code; thus making such forked code ineligible for re-import into an MIT/BSD-licensed project like the OpenBSD kernel (unless that project wants to be infected by the component’s licensing and become GPL-licensed in turn.)

Are you saying instead that the DRM drivers in the Linux kernel (the in-tree parts, I mean, not the firmware blobs) exist as an island of MIT-licensed code inside the otherwise GPL-licensed codebase?

Or are these parts of the Linux kernel not even technically in-tree, but rather developed in a separate canonical repo and frequently synchronized into the kernel as a vendored dependency? That’s the only way I can see this working; but it’s unclear to me why this state of things would have been maintained for any length of time when the Linux kernel was the only consumer…

It's one of those paradoxes inherent to software development: even if a tool is designed to work with Big Data, developers are too impatient / feel too unproductive to actually work with Big Data during development, so they only bother testing their tool using small data for 99.9% of development. Problems the tool has under actual Big Data tend to only start being found as of v1.0-rc1.

> Setting up local decision / classification models is as easy as telling the agent you already use "set up laya on llama cpp locally https://github.com/ggml-org/llama.cpp https://huggingface.co/ggml-org/Laya-GGUF" (or your inference engine and model of choice, walk away for a minutes, and come back to it running on your computer.

I mean, yes, that works at dev time; but going from zero to nonzero local inference components makes an agent implementation suddenly much more complex to ship to production / drastically narrows the set of hosts such an implementation can be deployed onto.

I believe you could buy a random Android streaming box with an unlocked bootloader, and then install LineageOS on it. Not sure about the “streams from all the major services” part re: LineageOS, but last I heard it’s improving.

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

I believe the idiomatic solution for “handing your child an iDevice but only letting them touch one app” is Guided Access mode.

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

Seems like a useful innovation on the desktop level, but on the server level, isn't it already pretty normal to see machines with 24x high-performance (i.e. individually high-bandwidth) NVMe drives in them, that can then be used in software RAID0 to achieve pretty massive read bandwidth?

I would guess the assumption is that "agentic work" should be happening asynchronously in the background on a machine that's also used for foreground interactive work, where the slower the inference is, the longer the machine's GPU and [V]RAM are "hogged" by it at a time, and so the more the machine's performance seems to degrade.

What I don't understand is: when you only plan for your product to have 10 customers, why even make a marketing page like this for it? At that point it's essentially the hardware equivalent of consultingware, something you sell to your existing contacts through outbound calls and by shoving ads through the B2B equivalent of a post-consumer sales channel (i.e. proactive outreach by your org's internal champion for that customer, to said customer.)

Tool blueprints, I might suggest. (I.e. genes are blueprints for tool proteins/enzymes/etc.)

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

The diagrams seem to have been written (or generated[1]) while looking at the project source code, and use the sort of bass-ackwards approach to code documentation of giving a “post-hoc summation” that only makes sense when you’ve already read the code, rather than serving as an introduction to the code for someone who hasn’t read it yet.

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.

Presuming you are new-enough here that you didn't realize that jacquesm has been posting on HN for a very, very long time: did you consider clicking on the GP's profile link to answer your own question?

> But it may also be used to track the user's writing cadence, error correction style

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.

I think you missed the point. Things should look like what they are.

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.