xlii

They most likely don't charge fees on consumer.

Usually the fee is on merchant (and it's few % depending on region regulations etc.) Payment providers such as Wero are doing direct bank transfer, which is usually fee-less, but then they can afford to put a on-merchant fee that's much lower than what credit card companies are charging.

Thus the model is win-win-win: Consumer doesn't pay more, Merchant pays less, and Wero gets their share.

> ...this is not unique to the US by any means

I've searched and found that Australia has similar concept. According to EU laws person on-territory is under jurisdictiction of said territory (even though it might bar from entering, but still EU/local laws apply there) - this is probably why I'm so surprised.

Also regarding this exact nuke-phone-through-distress-password: in many European countries it's perfectly legal to protect oneself from law. While the law is nuanced (i.e. one might not be obligated to provide password, and responsibility for destruction can be put on forces as they could be found at failure when securing device), usually it's fair game.

In the end I just find this terrifying. The idea that I'm getting back from vacations and then I get myself as probed like that. Here, the only things I'm afraid of are... queues.

There are so many peculiar things here, I - as not an US citizen - don't understand:

If the border isn't "US soil" then what jurisdiction is it?

How come American forces can seize goods if that's not US? What prevents them from trying the same, e.g. in Europe or Australia?

Also I find the law penalizing people who might deprive state of evidence especially odd. In (AFAIK) most of the Europe there's no self indictment, so destroying any kind of evidence that might get you indicted is fair game and you can't get penalized by such fact alone.

And of all of it the fact that US government is pulling this stuff on US citizens is unbelievable.

No idea, might be only me, but I start to perceive US more and more as a totalitarian state.

Not all HN visitors are native English speakers and in some languages "it" doesn't construct well with verbs, thus thought frameworks forms through usage of him/her. Nothing more to see I suppose.

Good idea, haven't thought about this before.

It's infinite canvas, so I'm actually drawing diagrams for code, for LLMs (those are much more receptive to text diagram than screenshots).

Scratchpad is default mode but it can edit text files, or have own files for editing. One more magical use case is filter mode when using CLI agents. Switch prompt to editor, select some text I want to be laid out, I filter through `ascdraw -` which opens editor, let's me move things around, align, add arrows & stuff and then after closing I get selected text in a new form.

Well it isn't that simple :)

It mentions 144FPS, because of scrolling/zooming events.

If there's a key-by-key panning then probably you need 1 frame and you're good. Macbook's Pro touchpads generate events with 150hz - and in order to maintain "butter smooth" FPS has to follow.

Number of cells on screen matters: rendering 80x80 is not a problem. After zooming out and 1000x1000 on screen panning with 150FPS is straightfoward.

In the end there is a deterioration of user experience when jank in scrolling, zooming and even typing happens.

Thus ceiling right now is around 144FPS, mostly because ~6ms budget (on M2 Macbook and 4K 144hz display). 60hz refresh rate 60FPS is an easy mode ;-)

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

:D

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 

i.e. I might myself not share the sentinment, or not know anything about it, or simply not engage - relay is not an opinion in itself.

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

Selling game with such license was just as big of a "violation" as straight copying and giving it out (not having right to do something doesn't equal to crime though, even if some companies, coughMicrosoftcough, want you to think otherwise).

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.