derefr

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.

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