derefr
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!)
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
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.)
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.”)
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.
• 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.)
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.
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.)
(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.)
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.
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…
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.
(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.