xlii

effect of accidental development of a framework for GUI apps and personal sympathy toward diagrams

I've seen the other lately submited text-effect-claim-to-be font and I must say I find this much more amusing.

Humans can squint, AIs can't squint!

It's possible to single task using Round Robin strategy.

Have a list of things you do, go one by one over them. If new task appears add at the loop "gap".

I found that the worst thing is chasing the bunny: Oh wow. This finished. I should chboing oh another agent that's probablboing... - completely unsustainable.

The loop is very similar to old way of things. You just don't pay attention to notifications. Also it's worth grouping loop to minimal że context switching or ease context switching (e.g. task on project a, task on project a+b, task on project b, task on project a+b, etc.)

In order to get to looping part I use self-approval modes for agents. It's slightly uncomfortable but I built own agents with own permission reviewers and they are quite good. These can be used to run agents in the background. And if you do a loop and find agent still spinning - it's a good moment to take a five for yourself.

The deep focus is still there but somewhere else. Usually in coordination and integration.

I ran 10k test locally on 2e5 and I'm seeing 4 orders of magnitude instability, but very high local stability (i.e. runs within specific second are very stable, showing almost no deviation, runs couple second later are the same, but results are within 1 OoM of the prior results (smaller batches, 500 tests).

I'm not saying that optimization isn't valid, what I'm saying is that Quicksort shouldn't be optimized over randomized per run data set.

Is it only me..?

Quicksort is supposed to be an algorithm that has O(n) to O(n²) performance and O(n log n) being only an average performance case. Test was made on random data coming from different archs (so I doubt it's characteristic would be remotely identical).

Given input size of 50M it means that performance could be between 50M (5e7) up to 2.5e15. That's like performance instability of 8 orders of magnitude.

I'm not sure here if we can't write instead that "Your code is fast if you picked fast case for it" especially since fix of 6 OOM is smaller than algorithm's performance range.

Obviously Kakoune is much simpler than Emacs, so face variability, very interactive UI is not there (though there'd be nothing preventing writing it, but I doubt anyone wants it enough).

As for transition - I always was somewhat of an UNIX guy, so I replaced Swiper/Occur/Consult with delegating to shell. Kakoune has just enough utilities to create a on-keystroke-updated-buffer so I'm happy with that. In some languages I go as much to create "find functions" special mode - composition with shell is easier than Lisp - I rarely have to read documentation.

For Git I use Jujutsu (so I stopped using Magit long time ago) but Kakoune has a very nice "!commmand<ret>" utilities. It's nothing more than a "C-u M-!", but positioning of feature differs.

So the transition is mainly about delegation, not sticking to one application, but instead finding utility that does it and use that instead.

Oh, cool I was wondering how can I get to see that decoy!

Technically it's not a font, because font needs to be still. Analogy: if I took photo after book was closed would we say that font cannot be read by a camera?

Took a picture (only a single frame) and a 1s movie and threw it toward GPT 5.6 Sol (High):

Frame took 9m30s to decyper and GPT 5.6, it returned: WRITTEN IN GHOST FONT. Weird because I can only see "GHOST FONT" on the demo... but extracted data from image (I saw the highlited one) definitely looks like the "Ghost Font".

--

Video is more amusing, because after 3m GPT 5.6 figured it's motion-defined and asked to run QuickTime. At one moment I got:

The animation is a motion-defined illusion. I’ve confirmed there’s no readable static OCR layer; I’m decoding its optical-flow field so the letter shapes become explicit.

At 4m it got extracted motion image that was in shape of letters but analyzed for 9 more letters and returned (at 13m36s) "GHOST FONT"

--

So:

    a font...             - FALSE - not a font, but video effect
    ...humans can read... - FALSE - I can't read it from image (but AI can!)
    ...but AI cannot      - FALSE - it can

Edit: https://imgur.com/a/SHlGu4O - work-in-progress images

In this space I think I'm becoming LLM advocate.

Finding, reading outdated, writing, updating, grooming documentation is so much more expensive than just throwing LLM on repository (or multiple ones) with a "Go Fetch" quest.

Sure, it's ephemeral, but with assumptions of $50/h earn and assumption that non-naive piece of internal documentation takes 8h of work time and will be read ~100 times that comes in at $4 at read which I think is much more expensive than straight token-API costs (and probably much much more expensive than subsidized subscription costs).

And this is generous. Looking at Jira's stats from my past work, many long documents in small (but specialized) team were read 10-20 times boosting the (assumption-average-costs) to $20-$50 per read.

But wait, there's more (;-))! That's all assuming that knowledge absorption is 100%, what if only 50% of document is relevant. What if it's 25% etc.

In the end today there might as well be no documentation for code and LLMs could extract it raw from code. Raw - because I don't think indexers/RAGs/compressers are useful. I found that spending time on building such is fruitless: Indices can (and will) go stale just as materialized documents and lower context saturation results in more hallucinations in the end.

(There are out-of-code documents which obviously have no other source than then themselves so there's no other around it, though)

I agree with the premise of the article.

For example I've been using Jujutsu exclusively (as a Git frontend) for years and I don't think about it, I just use it. I reflected on this couple of years. It's existence is completely transparent to me.

I, however, don't agree with sibling commenter that it's a function of time spent with X though. As a counter example: Emacs was my go to editor for 15+ years, last 2 years - because reasons - I was switching between Neovim, Helix, Emacs, Kakoune. 6 months ago I settled with Kakoune.

Even with many years in Emacs, I still tweaked and tuned it. There was always something to do, change, understand. I actively thought about Emacs.

With Kakoune after initial "set me up" phase, it's just as transparent as Jujutsu. Sure, I made complex plugins (for searching, highlighting unbalanced parenthesis and even a GUI wrapper called Kakvide). But the difference is that in Emacs the driver was the tool itself and in Kakoune it's always "I wonder if I can do X".

And so I believe that Kakoune is better tool than Emacs as it's more transparent to me even with a big time difference in usage.

Not very thrilled mainly because I used chats for ad-hoc search queries. Now it's hard to reach. Not to mention private chats being removed.

Regarding "ChatGPT Work" vs "ChatGPT Codex" - In Work diffs are gone and in new chats there's a popup proposing creating docs or sheets. That's it I believe.

It has spoilers in it :)

For me, using Fuzzilli for testing a Zig code is not fuzzing, it's integration testing. If you're running code externally (e.g. wrapping binary) you cannot guarantee that side effect isn't caused by IO. I consider fuzzing a low level activity with many external variables removed.

Depending on where you are and how you communicate semantics matter more or less. It's very similar to compiler/transpiler. E.g. TypeScript "Compiler" is called compiler but in fact it's transpiler (it emits other high-level language as a result).

Yes, because neovim != vim :)

Dear Aunt Bee, Thank you for the sweater.

https://tinyurl.com/z9m89k2z

Word-engineer hat on:

The grapevine was (...), and all those grapes contained the juice of the same message: Jarred was a stinky manager.

Per exact words these two are different:

    - I think someone is stinky
    - I spoke with people who said someone is stinky 

AFAIU fuzzing code != fuzzing results. Through skimming it seems that integration tests were using fuzzing, but I would call it fuzzing the code itself.

From "product" perspective there's no difference, but in program-compiler perspective (and e.g. raising bugs about compiler), Fuzilli isn't fuzzing.

Per Wikipedia > (then...) The program is then monitored for exceptions such as crashes, failing built-in code assertions, or potential memory leaks.

As for myself, I wouldn't use term fuzzing for integration testing such the one used by Fuzilla. I always caught it dynamic testing, scenario testing and in bigger cases property based tests. Fuzzing in my mind is reserved to a low-abstraction calls.

Might just be me, though.

As sibling mentioned - bugs and regressions are the thing that are (in a perfect world) usually covered.

The problem however is non-covered success cases. A visualisation of the problem: let's say universe of interaction for DB consists of 10.000 SQL queries. Over 10 years various regressions were found and 2.000 SQL queries are guarded by tests. In reference implementation remaining 8.000 never surfaced over this time and it's unclear if they will work.

And, thinking of how many various SQL queries PostgreSQL users around the world are using vs the test cases covered it's obvious that feature space isn't covered in 1% of the success ratio cases.

Now the new, test-based implementation, has to prove it can handle remaining 99%.

I have found (partial) remedy: let it go.

There's some YOLO approach to it, but now Codex has self-approving as well as Claude Code (auto mode). I implemented the same feature by my own on Pi with models through OpenRouter and found results very stable thus I have (as always) limited confidence it can fly.

So (disclaimer: I'm Jujutsu advocate :)) I do "jj new", tell it what to do and then let it run, and check in back later.

If there are things I'm not comfortable (like creating PRs or pushing to repo) I ask it to create Ruby scripts instead named like "__pr.rb" (double underscore files are in my global gitignore). So I can leave it working and then inspect back and edit manually before I run "ruby __pr.rb".

The only thing that's not yet there is tying multiple tmux Claude/Codex session together, but I'm thinking about creating a small Rust app that communicates with Tmux for a preview (or a Ruby script that communicates with my LogSeq directly and manages nodes there :))

I'll emphasize that using something without a legal base isn't a crime.

It isn't even about legality (because laws usually don't regulate how one can interact with entity they have no legal ties to) but only about litigation risk.

There are no legal or moral obligations requiring valid license. Only interested organizations are brainwashing people into thinking otherwise.

But I don't think licenses are the problem. It's quite obvious. You have 100 works of art (music, graphics, code and text). You want to make money. If you sell it - you lose all the rights. You can give it out but then there's no profit.

The only way to not transfer ownership and give away for free is exact middle ground called the license.

Geez, people have no idea how licenses work...

License is not an ownership - It's limited right to use something. Any action anyone does that isn't covered by license (in software) is called "piracy".

Games were never sold. Mediums were sold with attached licenses. And most of the licenses as early as 2000 contained something like:

    "This license is personal to you and may not be assigned, sublicensed, or transferred."

The only difference today is that licenses are enforced better. They can be held on license-server and new user can be denied usage after transfering was detected.

But it doesn't matter if it's downloaded, on disc, or embedded on a spoon.

Don't make people believe they ever owned a game. They didn't. You don't own games as well. Never owned them. You rented them.

The only way to get out of it with winning hand is to side with reputable vendor that didn't cheat people out of licenses. Reason why I side with Steam is because I have my licenses intact even though they have 25 years, I know big corps that just make licenses go poof and pretended in never happened.

There are dozens of us. Dozens!

Years ago I was quite able when it came to git. I could plumb, mess with reflog: never had to do "copy dir" - safety.

For last 4 years I'm using Jujutsu exclusively, and it is just here. I forgot what staging is and only recalled it when it was mentioning in the post.

So I agree with siblings: because better frontend exists than git cli.

In places where it matters the fines are so high, that everyone are stickler to the rules. It's like a hot oven - not merely a warning of risk. It's actual risk which was touched and which burned.

If an adapter would put your yearly salary at risk (not an exaggeration) would you quicken it?

checking contribution policies "before the fact"

GNU has no such contribution policy. As I wrote it's currently a discussions behind the closed doors. Those who inform about usage of LLMs are notified that their contributions won't be accepted, and I think I'm second or third in the whole emacs-devel mailing list history.

Thread about LLM contributions sparked after my piece, not before it.

From my research, the only prior discussion was in March 2026 with conclusion that "lawyers are looking into it" and no followup whatsoever.

Though, if I made a mistake during my research don't hesitate to correct me, because it will prevent me from making similar mistake in future.

I formed (and am advocating) a theory that code reviews are three dimensional space exercising trust, need for control and awareness propagation.

E.g. LGTM could be categorized as high trust, low control, high awareness.

I'm still in process of forming it on writing mostly because I get hooked up with pathological scenarios and these are infinite source of jokes to me. Some I written down already:

https://xlii.space/fiction/approved_unread_shipped/

I've seen Sam working on this real time as I follow him on BlueSky. So maybe it's technically a slop but I've seen a proof of work.

Won't comment on the product because not my cup of tea.

I'm team cli ftw :)

I switch from Codex to GLM 5.2 when I'm out of tokens. The main difference for me is time to completion.

GPT gets there <5 minutes, GLM 5.2 without context takes ~1H.

Though the harness makes a significant difference. On Pi GLM5.2 dreams for minutes, with OpenCode it's more on the point and gets to editing quicker.

I never had to deal with that. At one place it was so complicated that specialized system took reconciliation over (it got baggage full of context data including exchange agreement details, with boundaries and time-regions plan).

In not-a-fintech we just went with doubles and rounded up (worst case - we get a cent more of a customer).

Though if I had to design today for that, I'd look for non-string serializable decimal, so not "10.123 == (10, 123)" but more like (10123, 3) and serialize in JSON as a value and precision separately.

Yet that's only cause I saw Decimal(10,123) sent in JSON as "10.123" which JSON reader red as 10.122 float and inserted to "1012" to database.

Quick browse over Stripe API (i.e. not a simplistic payment provider) will show exactly otherwise.

Metrics/durations/convexity/vega aren't monetary value, these are calculation values and I'm fine with them being whatever. If you're calculating averages to make decisions based on this I don't care if you're counting dolars or tomatoes.

Monetary value is $4.50 and it's representation of actual money passed through system. In practice this value is almost never undergoing any operations except for addition and subtraction. Any multiplication/divison etc. is left to specialized systems that return results wrapped in 800 pages of standarization documents, regulations and so on; systems where term "bit flip" is not a joke, but a risk.

As I wrote fintech != fintech, and I know many organizations aren't at that level of scrutiny, but a huge domain of people dealing with others' people money know that charging someone 1 cent too much is a tens of thousands of problems coming their way.