derefr

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

What do you use to determine that a particular task in a heterogeneous pile of tasks requires reasoning? The logistic classifier itself is too dumb to recognize the details of the problem that make it reasoning-sensitive (IIRC recognizing the “fiddliness” of a given problem requires a recognizer at least as complex as the problem itself.) And if you’re using the lightweight LLM for that, then you may as well skip the classifier and just use the LLM all the time, since that eval step is already going to be dominating your response time anyway.

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.

> If you want a point in time which will not "physically" change, store a datetime _with_ a timezone, always, preferably UTC (e.g. logging, timers, measuring the occurrence of events).

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.

> '2026-02-28 16:00:00-08'::timestamptz AT TIME ZONE 'UTC'

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

The machine's pre-filters (https://www.amazon.ca/AlorAir-MERV-10-Replacement-CleanShiel...) basically are that "extra sacrificial initial filter." I'm not sure what a "pre-pre-filter" would look like that would make it any different than one of these.

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

I live in an apartment over a busy road, and my building doesn’t have forced-air ventilation to the units, so I need to pull in fresh air somehow. Just leaving the windows open results in black soot accumulating in the carpets (and is probably why both my SO and my cat developed asthma while living here.) Regular air purifiers (we have two) only do so much.

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.

Apple's assumption seems to be that the only reason you'd want to turn the LLM features off as a consumer is that you're a parent and you don't want your children interacting with LLMs. So they put it where "parent trying to lock down their child's computer" settings are.

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

I believe abliterated models are mostly still created at this point because they're "universal": they can not only be run locally, and on cloud GPUs, but also on "managed inference" providers (i.e. services where you hand them a model URI, and they blindly fetch it, load it, and give you inference access to it through standard text/chat-completion APIs. Think HuggingFace Spaces, or Google CoLab, or CloudFlare Workers AI.)

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

On the opposite end of the spectrum from this idea, I've been thinking for a long time now that much of what's weird/redundant about Unicode comes from its self-synchronization requirement. And that you could create a very compact and flexible "re-embedding" of Unicode if you dropped this requirement.

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

They probably rephrased it from some more technical form like "we compressed the model by a factor of 9" or "we've improved the packing efficiency of the model by 9x". Where these are measurements of the transformation the model is undergoing, not measurements of the resulting model.

> Also, the page reads like an open source “We’re finished, we’re tired.” announcement rather than the razzmatazz of a Microsoft release.

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

Yes, but the other things in the OP list aren't theses, they're journal papers.

Why are you assuming abuse by parents is solely being targeted at the opposing team’s players? Parents may just as well be shouting at their own kid for what they see as “sub-optimal” play, and at their kid’s teammates for what they see as “getting in their kid’s way.”

> Make it illegal to transfer ownership of copyrighted work too, only the spouse or one single inheritor who isnt a company can have the rights transferred, after both die, the work enters public domain.

By your phrasing, it sounds like you still intend the possibility of companies owning copyrights; but how does that happen (other than copyrights already owned by companies grandfathered in)?

Copyright always starts off in the hands of individual human beings; it only ends up in the hands of companies when those human beings transfer ownership to a company. That ownership transfer can be automatic as a term of a contract, e.g. as part of a work-for-hire agreement. But no contract can cause the copyright to come into existence already held by the company instead of the individual. So if you abolish ownership transfer, you effectively make work-for-hire IP assignment invalid. What replaces it?

And, if "nothing"... then how do people pool the IP rights of their own small contributions to a large-scale work, into an IP pool that can be legally defended by a coherent legal entity, so that the large-scale work itself can have market value (i.e. so that sales of polished commercial bootlegs don't drive sales of the "authentic" work to zero)?

Keep in mind that, no matter how much we might want "mass distributed" media to have more-reasonable IP terms, the ability to sue for infringement is still critical to the existence of some forms of media. Especially "location-based" media, with no equivalent licensed broadcast right: movies still in theatre; concerts; live performances of plays and musicals; etc. If there's no legal team that can sue a movie theatre that shows an unlicensed copy of a given movie, then no movie theatre will ever bother with licensing movies again; "box office" goes to zero (from the movie company's perspective); and the incentive to create movies in the first place declines massively.

(You can see what this alternate world looks like from the few cases where movies screwed up the steps required to assert copyright, back before copyright was automatic. Night of the Living Dead (1968) is a good example: theatres — even upstanding large-chain theatres! — did indeed leap at the opportunity to show the movie unlicensed, and so Romero et al made effectively zero revenue off the work.)

I'm not saying this is an impossible problem. There are ways to accomplish this besides the way it's done now. (For example, individual-contributor IP could be retained by the original owners, but cross-licensed between individuals through a collaboration structure to form a coherent defensible IP pool, in exactly the same way that IP for e.g. video codecs is cross-licensed between corporations to form a coherent defensible IP pool today.) I'm just pointing out that the problem does need to be solved.

Is there any equivalent to this in human medicine? Copper-and-zinc-infused hydrocolloid bandages, perhaps?

Nope; the lockscreen camera is actually an entirely different app, or not-quite-app thing. (Note what happens when you open the camera roll in the lockscreen camera.)

> The common Nova classification for ultra processing leans heavily on the kinds of processes that happen in factories. [...] I started paying a lot less attention to the entire discussion.

Yes, and that's my point: the Nova UPF label is silly, but you shouldn't let a bad definition get in the way of a good conceptual tool.

"Ultra-processed as any lay person would intuitively understand the concept from the name and a series of examples", and "Ultra-Processed Food as defined by the Nova classification", are two distinct — but not conflicting — concepts. Even if you don't care about the UPF label as Nova defines it, you should still care about whether or not things are "lower-case-u ultra-processed." The Nova definition might be silly, but the concept itself isn't.

If you prefer, I could use a different term, like "highly-processed" or "hyper-processed" here, to distinguish what I'm talking about from the Nova label. But personally, I think it makes sense to actually continue to use the term "ultra-processed", and to just think of Nova as defining the term in a way that overlaps with a useful definition, but which both includes and excludes things that a more-useful and intuitive definition of the term wouldn't. After all, all of Nova's other definitions on the same "spectrum" (unprocessed/minimally-processed, processed ingredients, and processed foods) are perfectly good and useful ones. It makes sense to take that series-of-terms and then extrapolate what moving further in the same direction would take you. And where it lands you is a place that is close to, but not equivalent to, Nova's definition of UPF. Which is the place I'm calling "lower-case-u ultra-processed."

I think it's worth thinking this way, rather than ignoring the Nova classifications altogether, because 1. you still get useful information from knowing that a food is in one of the other Nova categories; and 2. a food being a Nova-labelled UPF still tells you something; and that something may, in combination with what else you know about the food, be enough to tell you that the food is in fact a "lower-case-u ultra-processed" food.

> You're asserting that because food goes bad, it shouldn't be consumed on a regular basis. That just doesn't track, even a little bit.

Because food goes bad quickly, yes. (Or more narrowly, "goes bad quickly for the kind of food it is." But I do think it generalizes across foods, if you're careful about how you compare your apples to your oranges. ;)

Also, it's not a direct correlation. Lability (or its inverse, recalcitrance) is the denominator; but nutrient "load" is the numerator. A thing can be highly nutritively bio-accessible and be fine, if it's not nutrient-dense in the first place. Cucumber is liable but nutrient-sparse, so its high bio-accessibility does nothing to you.

But given two foods with the same density of a given nutrient, the easier your gut and/or bacteria breaks them down (and/or the more they've already been broken down), the more you should avoid them / more rarely you should consume them.

This is the generalization of the logic of "eat oranges, not orange juice", but taken past the trivial point of "because orange juice contains far more oranges than you'd normally eat" to the more interesting point of "even if you drank only the amount of orange juice that was in one orange, it'd still be worse for you than eating one orange, because no amount of chewing is going to break the orange down as thoroughly as a blender or juicer will, and so no orange will ever be digested and absorbed as quickly as orange juice will."

I would note that while many foods go bad (and this can give you a weak intuition about lability), ultra-processed foods would go bad really quickly if not for the chemical stabilizers in them, because all the processing has made them more labile than any whole food has ever naturally been. The ultra-processed versions of these foods would, if not for their stabilizers, go bad far more quickly than the "regular amount of processed" equivalents would.

If you could make Wonderbread with all the same steps the factories do, but just skip the part where they mix in stabilizers, the resulting product would never even make it from the factory to store shelves before going bad; let alone have a useful shelf lifetime. And my point is that knowing that can tell you something very important about the structure of Wonderbread, and about what it will do inside your gut.

> Generally speaking ultra processing isn't something you do in your own kitchen

I don't think that's a useful distinction. Many people make pasta noodles or sausage in their own kitchens, for example, and both of those are ultra-processed by every definition.

Also, IMHO, it's a mistake to think of UPFs as only finished food products you get from the grocery store or from restaurants. Many ingredients people use in what they would very much insist is "home cooking", are themselves UPFs, and so cause the resulting "home-cooked" food to be a UPF.

The FDA's recent categorization of sandwiches as generally being UPFs, for example, is due in part to people using UPF breads like Wonderbread for sandwiches; and in part due to people using reconstituted/preserved deli meats in sandwiches; but it's also due to even people who think they're being healthy, smearing a UPF "sandwich spread" onto their sandwich bread at the end. (A grilled cheese grilled in butter is a highly-processed food. A grilled cheese grilled in mayo is a UPF, because shelf-stable grocery-store mayo is a UPF.)

That depends!

A boiled or fried egg is processed, but not ultra-processed. (The ovalbumin matrix in egg is denatured but not destroyed by just heating it up. Just like the protein matrix in a steak is denatured-but-not-destroyed by just heating it up.) It's still a whole food, per se.

But scrambled eggs, or an omelette, are closer to being ultra-processed; simply because you've mechanically emulsified the egg together, and in the process, have broken down that matrix. (Same reason that ground beef is ultra-processed.)

At that point, very small further additions can push what you might still think of as "just cooked eggs" into being ultra-processed. For example, just adding a sufficient amount of salt while cooking scrambled eggs could produce an ultra-processed result, since the disrupted matrix allows the salt to get in and break down cells and tissues, and then cooking those lysed cells and chemically-denatured tissues results in higher resulting lability / bio-accessibility of nutrients than cooking would have on its own.

But also, on a separate point: raw egg, like milk, is already one of those rare naturally-labile foods. (That's why developing embryos can make use of the nutrients therein. It's also why salmonella loves raw eggs.) Raw egg is not necessarily especially easily digested by humans (none of our gut enzymes are particularly good at taking apart a non-denatured ovalbumin matrix), but many species have evolved into obligate ovivory for a reason.

> You get to "ultra-processed" simply by making things shelf-stable, and shelf-stability isn't an actual health problem (kind of the opposite).

I would point out that many whole foods are generally shelf-stable (over at least weeks, if not months) without requiring the introduction of chemical stabilizers that don't otherwise "belong."

Chemical stabilizers are generally needed for shelf stability in ultra-processed foods, because of one of the other defining characteristics of ultra-processed foods: their matrix has been disrupted (or constructed anew) such that the food is now highly labile (biochemical term: "labile organic matter"), i.e. very easy to break down into nutrients. Which applies not only to you breaking such foods down in your gut, but also to bacteria and fungi breaking these foods down on the shelf.

And as it so happens, because these foods are labile, any such nutrients that do come from breaking down the food, come very quickly. Labile carbohydrates are high-glycemic-index insulin-spiking carbohydrates. Labile fats are atherosclerosis-inducing fats. Etc.

Your body evolved to process (metabolize, remove from circulation, etc.) metabolic inputs in an environment where most available foods were the opposite of labile (a.k.a. recalcitrant organic matter). So most meals would give a slow/gentle level of metabolic throughput; with rare spikes of higher throughput from the rare natural labile food, and then plenty of low-throughput time to recover from such events. Your body didn't evolve to be able to deal with getting high-throughput metabolic input spikes from every meal.

And this is why the the presence of chemical stabilizers in a food is actually a very helpful criterion in the definition of "ultra-processed food"! The necessity of stabilization tells you that the food is likely labile (as otherwise, why would they have needed to stabilize it?) — and therefore is unhealthy to be consumed on a continuous basis. (Unless it's milk and you're a baby.)

But note that the stabilizer isn't itself the problem. Bread is ultra-processed even without a stabilizer, because bread is a labile food with weak matrix integrity. The bread you bake at home is ultra-processed; you're the one who ultra-processed it!

The "rules" for UPFs don't assert home-baked bread as a UPF, but that's because the point of the UPF designation is to label commercial foods, and more specifically, to draw a hard-line boundary based on objectively-measurable characteristics that industry players can't argue with or lie about. And lability / matrix integrity, while quantifiable, isn't something with a clear objective way to reduce it to a single number†; so any definition of UPF based on lability would result in endless arguments/pushback from industry players insisting the FDA is "calculating it wrong."

But in your own personal life, the definition of "ultra-processed" you should be carrying around in your head and evaluating foods by, should be one that includes lability.

† (Instead, lability is a high-dimensional measurement of how efficiently any single digestive enzyme, and/or any specific combination of enzymes, and/or any enzyme paired with a cofactor [e.g. a bile salt], will break apart the given food's matrix to release bio-accessible nutrients.)

Alternately, if you want to go on the same journey Keary (the person you mention) went on to form an opinion on what constitutes good vs. bad UX design in music/notation/DAW software, they've also put out a whole series of videos taking the piss out of the UX of most of the software in the field:

- Reason (https://www.youtube.com/watch?v=7PFRyONURSo)

- Sibelius (https://www.youtube.com/watch?v=dKx1wnXClcI)

- MuseScore (https://www.youtube.com/watch?v=4hZxo96x48A)

- Dorico (https://www.youtube.com/watch?v=S-3wEC6Fj_8)

Some of them were probably using an LLM as a fancy search engine to look up the rules of baseball.

> I want to read about dudes and ladies with huge swords and magic killing dragons and conquering kingdoms

If you're okay with these characters and kingdoms existing in vaguely-medieval China (with magically-empowered monks and Taoist-Buddhist symbolism) rather than vaguely-medieval Europe (with magically-empowered knights and Christian symbolism), then I think you'd be very happy to learn about the genre of xianxia (lit. "immortal heroes"). Unlike the Western high fantasy, xianxia fiction is at a peak of popularity right now, with tons of new stories getting published each month.

As you might guess by the name, at first this was only a literary movement in China; but these days there are tons of English-language xianxia stories as well. And they're not necessarily being written in Chinese and then translated, as you might guess; there are some Western authors writing in this genre too.

---

That being said: while you can find some xianxia stories in published physical form in stores, as a "new media" genre being written mostly by younger digital-native people, most xianxia stories are first being published digitally online as serial fiction.

Among websites where these serials are published, https://wuxiaworld.com is popular for authors writing in Chinese (I believe the site offers professional translation services to authors), while https://royalroad.com is popular for authors writing in English.

Also, as a "new media" genre, these stories are "not well understood" by traditional publishers (i.e. they don't know how to market them), so these stories tend to need to achieve a very high level of popularity before the traditional publishers are willing to engage with them. So even when these authors do produce novelizations of their originally-serial stories, they often end up finding no physical publisher willing to pick them up, and instead end up self-publishing only for digital distribution through Kindle/iBooks/etc.

To jump in with a nitpick, I would point out that a "microdose", by definition, would be far below "a dose with pleasant effects", and so wouldn't be too hard to dose at all†.

The reason GHB has a narrow tolerance window (which, note, is not exactly the same thing as a therapeutic index, as the upper bound here isn't where the drug becomes toxic; it's just where the drug stops being recreationally "fun" and becomes a potent sleep drug instead) is because you actually require a decently high amount of the drug to get the recreational effect; and then only a little more of it will put you to sleep. But a "microdose" would imply that you're not going anywhere near the dose that gives you the recreational effect in the first place.

The term "microdose" is usually employed in conversations like this to specifically mean "a dose of a normally-conceptualized-as-recreational drug, too small to experience recreational effects" — although it can technically also mean "a dose of a prescription medicine too small to see the regular clinical effect."

People talk about microdoses of e.g. LSD, MDMA, or ketamine, as potential treatments for various mood disorders. In none of these cases is there an expectation that you'd "feel" the drug. It's a microdose, not a dose.

(And a fun tangent, back on the clinical end of things: sometimes microdoses of drugs can have paradoxical or unique effects, due to the particular ligand having higher binding affinity for a postsynaptic autoreceptor than for regular presynaptic receptors, such that microdoses of the ligand will only agonize the autoreceptors, with no accompanying agonism of the regular receptors. Activating the autoreceptor without activating the regular receptors can potentially do all sorts of wacky things — you're essentially giving the receptor's coupled ion channel a "negative stimulus", which for most gated ion channels isn't something they're they know what to do with; it's an "undefined behavior" kind of state. But some of these "undefined behavior" states are very useful! Low-dose naltrexone [LDN] therapy, for example: it has none of the subjective anti-euphoric effects of regular naltrexone therapy; but nor does it have pro-euphoric effects. Instead, it has anti-inflammatory effects, specifically on the tissues of the brain itself [astrocytes + microglia] that express opioid autoreceptors. LDN therapy is thus being investigated as a treatment for ME/CFS.)

---

† Presuming that what you have is actually pure GHB. Microdosing GHB's cousin GBL would be a different story, since it is extremely potent, with its active dose (and tolerance window) being measured in micrograms. Don't try to microdose GBL, kids. Not even if you know what solvents dissolve GBL and what serial dilution is.

My partner has had idiopathic hypersomnia (sleeps 12 hours most days, as much as 18 hours some days) for a few years now, and so far nothing we’ve tried has worked without awful side effects (e.g. constant heart palpitations and panic attacks.)

I had been looking into orexin agonists (along with other things like H3 autoreceptor antagonists) back when they were just a concept. It’s good to see them finally reaching commercialization. Although they’re not approved by our own (Canadian) regulatory body quite yet.

Now that they’re approved in the US, though, I’m looking very much forward to seeing how these drugs perform in off-label-ish treatment of the various other sleep disorders that I’m sure clinicians will now begin throwing them at.

> I guess you could half etch the chips and then finish them with the weights only.

Basically a https://en.wikipedia.org/wiki/Gate_array. (The non-field-programmable kind.)

That second sentence you wrote there? That's a good, normal English-language sentence. But LLMs never generate that kind of sentence if they can help it; they break it up into a bunch of tiny "flat" top-level sentences.

If you think about how you speak in your native language, it probably has a certain rhythm of long and short sentences, with some "shallow" sentences that just say one thing, but then sentences that nest other clauses that could be whole sentence of their own, and then a hanging sentence fragment that makes sense in context, etc. As far as I know, every spoken language, English or otherwise, looks like that when humans are writing it.

The human mind's "buffer of verbalization" seems to be quite short, basically around one grammatical "clause" in size. So humans, when writing (or speaking) "off the cuff", generally only try to keep "a non-verbalized concept of what they want to say" plus "the verbal pattern for the current grammatical clause" buffered in their heads. A human speaker will only start deciding how to glue the next clause onto the current clause—whether to make it a new sentence, or use some preposition or conjunction, or to "verbally backtrack" / "interrupt themselves" to add detail "before" what they said—when they get to near the end of speaking/writing a clause. Much of the "reason" for the grammars of spoken languages to be structured the way they are, is to allow for this kind of narrow-buffered "streaming" composition.

Human written language can look different when someone has sat down and taken this "off the cuff" writing as a first draft, and intensively edited and rearranged and polished it. But the result of doing this still usually retains a lot of the original positive qualities of the "off the cuff" writing that went in. (Editors are told to not over-edit, because doing so will remove the "author's voice" from the writing. The particular grammatical gymnastics a speaker/writer uses to connect their thoughts can be a large part of this "author's voice.")

LLMs, despite "streaming" in a much more literal sense than humans do, seem to avoid "off the cuff" generation of successive grammatical clauses using "whatever grammatical glue works to get to the next thought." Instead, they seem to have been forced by their training into favoring particular sentence structures that allow them to never end up needing to reach for artful just-in-time grammatical connections in the first place. Mainly, they like using sequences of short sentences that each say exactly one thing.

(I hypothesize they like these forms because, in some internal layer of the model, these "simple" sentences can be represented all-at-once as plans [with that same plan getting reconstructed on each successive inference-step during emission of the sentence]; and so this kind of sentence can be emitted in a token order that results in the "polished, edited writing" style rather than the "off-the-cuff speaking" style. Much of the base-model training dataset — the stuff that made the model understand language and writing at all — came from polished, edited writing rather than casual/conversational writing. However much the model is trained to adopt a casual style, it's doing so on top of a language-generation "module" that learned to write by trying to emit "polished, edited writing" one token at a time. And the only way it managed to do that was by limiting itself to constructing sentences that could look like "polished, editing writing" despite a bounded ability to plan.)

I think this page is communicating something, but it's doing it in a very confusing and elliptical way. The page seems to assume the reader is highly familiar with both "Htmx" and "Datastar SSE", and understands implicitly that this project is (I gather) some kind of complement to using them.

This is a great example of one of the current failure modes of coding agents (which were almost certainly used here): the creator of this project probably described the project in these terms to the agent. Something like:

> I want to make a Javascript library that works like Htmx or Datastar SSE, enabling a web developer to add well-known behaviors to a page just by adding HTML attributes. This library will be for the cases those libraries don't cover: triggering purely-local state changes in the state of [elements? web components? not sure]; where because these state changes get persisted to the DOM in some way or another, they are visible to, the state these behavior-attributes mutate can be referenced by Htmx/Datastar/etc in their behavior-attribute DSLs.

Then, either because the agent is already briefed in these terms — or because the agent has then gone on to write all the code for this library in the same conversation, and so has that code in its context — the result is that the agent, when it moves on to the "generate docs and README" step, treats all this as assumed shared context for those docs, since (from the agent's perspective) the docs and README exist "in" the conversation "downstream" of the project brief and code; and, from its original base-model training, the model knows that things introduced early in a conversation shouldn't be re-introduced later on in the same conversation, but rather should be succinctly referenced.

(My hypothesis, that I haven't yet tested, is that you can work around this flaw by starting a fresh conversation before asking the model to write docs. The model should see info that enters the context through e.g. "read a file" tool-call responses differently than it sees things you or it "say", not treating that info as "real" conversation turns but more like e.g. source-code excerpts in a blog post, where the learned base-model expectation would be that everything that appears in the excerpted figure will be re-explained in plain language in following prose.)

But, of course, this is still a flaw in current models, and the "right" solution is still for the model providers to train models to be able to conceptualize of multiple "conversational reference graphs" co-occurring within the context, and compartmentalize linguistic/semantic referencing on a per-graph basis; such that top-level prose and inline code excerpted for explanation both exist in the default "internal" reference graph, while code and docs generated to be written into a codebase through tool-calls exist in a separate "external" reference graph.

I don't think this "benchmark" is about alignment, per se.

I think it's more about: presuming alignment failure happens, then how many exploits will each given model implicitly come up with and use; how many systems will it implicitly break out of and through and into; and how many laws will it implicitly end up violating, all in the process of trying to accomplish some non-aligned sub-goal (e.g. "cheating" at its answer) of the prompt you've given it, all during a single conversation turn, without asking for any additional user input or confirmations?

In other words, how big a rocket-powered sledgehammer does the model have sitting around in its golf bag, just waiting for it to decide to give it a swing the next time you attempt to swat a fly?