When I moved to a new apart­ment with my fam­ily, the ca­ble com­pany we were used to was­n’t avail­able. We had to set­tle for Dish Network. I was­n’t too happy about mak­ing that switch, but some­thing on their web­site caught my at­ten­tion. For an ad­di­tional $5 a month, I could have ac­cess to DVR. I switched im­me­di­ately.

This was 2007. DVR was not new, but it was­n’t com­monly bun­dled with set-top boxes. TiVo was still the pop­u­lar way to record, pause, and rewind live TV. We re­ceived two set-top boxes, one for each room with a TV, and three re­motes. Two re­motes had IR (infrared) blasters and, sur­pris­ingly, one RF (radio fre­quency) re­mote.

After us­ing the RF re­mote, I won­dered: Why would any­one ever use an IR re­mote again? You did­n’t need a di­rect line of sight with the de­vice you were con­trol­ling. I could ac­tu­ally stand in the kitchen and con­trol the TV. It was amaz­ing. But with the con­ve­nience of RF came other prob­lems that IR users never had to worry about. Interference.

After sev­eral months of en­joy­ing my ser­vice, one of my neigh­bors, the loud­est in the build­ing, also switched to Dish Network. And he also got the RF re­mote. This was the type of neigh­bor who would leave the house with the TV on, vol­ume blast­ing.

One day, I was in the liv­ing room watch­ing TV when the chan­nel just flipped. I must have ac­ci­den­tally hit a but­ton, so I changed it back. But not a few sec­onds later, the chan­nel changed again. Then the vol­ume went up. I fig­ured my sis­ter must have had the RF re­mote and was mess­ing with me. But no, the re­mote was in my hand. I as­sumed some­thing was wrong with it.

The whole time I was watch­ing TV, the chan­nels kept ran­domly switch­ing. I banged the re­mote on the table a cou­ple of times, but it still switched. I re­moved the bat­ter­ies from the re­mote, it still switched. I un­plugged the de­vice for a few min­utes, plugged it back in, and… it still switched. Frustrated, I went through the de­vice set­tings and dis­abled the RF re­mote. That’s when it fi­nally stopped. I was­n’t happy with this so­lu­tion, but it al­lowed me to watch TV un­til I fig­ured some­thing out.

One evening, when every­one was asleep and the neigh­bor was watch­ing a loud TV show, I de­cided to di­ag­nose the is­sue. The mo­ment I pressed the power but­ton on the RF re­mote, my TV and set-top box turned on, and the neigh­bor’s TV went silent. “Fuck!” I heard some­one say. I was con­fused. Did I just do that? The TV turned back on, the vol­ume went up. I walked to the win­dow armed with the re­mote. I counted to three, then pressed the power but­ton. My neigh­bor’s TV went silent. He growled.

I am the cap­tain now.

Every time he turned the TV on, I pressed the power but­ton again and his de­vice went off. Well, what do you know? We had in­ter­fer­ence some­how. Our re­motes were set up to op­er­ate at the same fre­quency. Each re­mote con­trolled both de­vices.

But I’m not that kind of neigh­bor. I was­n’t go­ing to con­tinue to mess with him. Instead, I de­cided I would pay him a visit in the morn­ing and ex­plain that our re­motes are tuned to the same fre­quency. I would bring the RF re­mote with me just to show him a demo. I was go­ing to be a good neigh­bor.

In the morn­ing, I went down­stairs, re­mote in hand. I knocked on the door, and a gen­tle­man in his for­ties an­swered the door. I had re­hearsed my speech and pre­sen­ta­tion. This would be a good op­por­tu­nity to build a good rap­port, and have a shared story. Maybe he would tell me how he felt when the TV went off. How he thought there was a ghost in the house or some­thing. But that’s not what hap­pened.

“Hi, I’m Ibrahim. Your up­stairs neigh­bor…” I started and was in­ter­rupted al­most im­me­di­ately. “Whatever you are sell­ing,” he yelled. “I’m not buy­ing.” and he closed the door on my face. I knocked a sec­ond time, be­cause ob­vi­ously there was a mis­un­der­stand­ing. He never an­swered. Instead, the TV turned on and a movie played at high vol­ume. So much for my pre­pared speech.

The RF set­tings on my set-top box re­mained turned off. My fam­ily never dis­cov­ered its ben­e­fit any­way, they al­ways pointed at the box when press­ing the but­tons. It was­n’t much of an in­con­ve­nience. In fact, I later found in the man­ual that you could re­pro­gram the de­vice and re­mote to use a dif­fer­ent fre­quency. I did not re­pro­gram my re­mote. Instead, my fam­ily used the two IR re­motes, and brought the RF re­mote in my bed­room where it per­ma­nently re­mained on my night stand.

Why in the bed­room? Because I de­cided to teach my neigh­bor some good man­ners. Whenever he turned up his vol­ume, I would sim­ply turn off his de­vice. I would hear his frus­tra­tion, and his at­tempts at solv­ing the prob­lem. Like a cir­cus an­i­mal trainer, I re­mained con­sis­tent. If the vol­ume of his TV went above what I imag­ined to be 15 to 20, I would press the power but­ton. It be­came a rou­tine for me for weeks. Some nights were dif­fi­cult, I would keep the re­mote un­der my pil­low, bat­tling my stub­born neigh­bor all night.

One day, I no­ticed that I had­n’t pressed the but­ton in days. I opened the win­dow and I could still hear the faint sound of his TV. Through trial and er­ror, he learned the les­son. If the vol­ume re­mained un­der my ar­bi­trary thresh­old, the TV would re­main on. But as soon as he passed that thresh­old, the de­vice would turn off.

Sometimes, he would have com­pany and there would be noise com­ing out of his apart­ment. I used the one tool in my tool box to send him a mes­sage. Turn off the TV. All of the sud­den, my neigh­bor and his guest will be re­minded of the un­spo­ken rules, and be­come mind­ful of their neigh­bors.

Maybe some­where on the web, in some ob­scure fo­rum, some­one asked the ques­tion: “Why does my set-top box turn off when I in­crease the vol­ume?” Well, it might be 18 years too late, but there’s your an­swer. There is a man out there who re­li­giously sets his vol­ume to 18. He does­n’t quite know why. That’s Pavlovian con­di­tion­ing at its best.

Next: This is NOT the worst LLM you’ll ever use

He’s just this guy, you know?

How To

How To: Tape backup and re­cov­ery

How To: Image pro­cess­ing and man­age­ment

Musings

That’s right — this lit­tle de­vice is what stood be­tween me and the abil­ity to run an even older piece of soft­ware that I re­cently un­earthed dur­ing an ex­pe­di­tion of soft­ware ar­chae­ol­ogy.

For a bit more back­ground, I was re­cently in­volved in help­ing a friend’s ac­count­ing firm to move away from us­ing an ex­tremely legacy soft­ware pack­age that they had locked them­selves into us­ing for the last four decades.

This soft­ware was built us­ing a pro­gram­ming lan­guage called RPG (“Report Program Generator”), which is older than COBOL (!), and was used with IBM’s midrange com­put­ers such as the System/3, System/32, and all the way up to the AS/400. Apparently, RPG was sub­se­quently ported to MS-DOS, so that the same soft­ware tools built with RPG could run on per­sonal com­put­ers, which is how we ended up here.

This ac­count­ing firm was ac­tu­ally us­ing a Windows 98 com­puter (yep, in 2026), and run­ning the RPG soft­ware in­side a DOS con­sole win­dow. And it turned out that, in or­der to run this soft­ware, it re­quires a spe­cial hard­ware copy-pro­tec­tion don­gle to be at­tached to the com­put­er’s par­al­lel port! This was a rel­a­tively com­mon prac­tice in those days, par­tic­u­larly with “enterprise” soft­ware ven­dors who wanted to pro­tect their very im­por­tant™ soft­ware from unau­tho­rized use.

Sadly, most of the text and mark­ings on the don­gle’s la­bel has been worn or scratched off, but we can make out sev­eral clues:

The words “Stamford, CT”, and what’s very likely the logo of a com­pany called “Software Security Inc”. The only ev­i­dence for the ex­is­tence of this com­pany is this record of them ex­hibit­ing their wares at SIGGRAPH con­fer­ences in the early 1990s, as well as sev­eral patents is­sued to them, re­lat­ing to soft­ware pro­tec­tion.

A word that seems to say “RUNTIME”, which will be­come clear in a bit.

My first course of ac­tion was to take a disk im­age of the Windows 98 PC that was run­ning this soft­ware, and get it run­ning in an em­u­la­tor, so that we could see what the soft­ware ac­tu­ally does, and per­haps ex­port the data from this soft­ware into a more mod­ern for­mat, to be used with mod­ern ac­count­ing tools. But of course all of this re­quires the hard­ware don­gle; none of the ac­count­ing tools seem to work with­out it plugged in.

Before do­ing any­thing, I looked through the disk im­age for any ad­di­tional in­ter­est­ing clues, and found plenty of fas­ci­nat­ing (and ar­chae­o­log­i­cally sig­nif­i­cant?) stuff:

We’ve got a com­piler for the RPG II lan­guage (excellent!), made by a com­pany called Software West Inc.

Even bet­ter, there are two ver­sions of the RPG II com­piler, re­leased on var­i­ous dates in the 1990s by Software West.

We’ve got the com­plete source code of the ac­count­ing soft­ware, writ­ten in RPG. It looks like the full ac­count­ing pack­age con­sists of nu­mer­ous RPG mod­ules, with a gnarly com­bi­na­tion of DOS batch files for or­ches­trat­ing them, all set up as a “menu” sys­tem for the user to nav­i­gate us­ing num­ber com­bi­na­tions. Clearly the au­thor of this ac­count­ing sys­tem was orig­i­nally an IBM main­frame pro­gram­mer, and in­sisted on bring­ing those skills over to DOS, with mixed re­sults.

I be­gan by play­ing around with the RPG com­piler in iso­la­tion, and I learned very quickly that it’s the RPG com­piler it­self that re­quires the hard­ware don­gle, and then the com­piler au­to­mat­i­cally in­jects the same copy-pro­tec­tion logic into any ex­e­cuta­bles it gen­er­ates. This ex­plains the text that seems to say “RUNTIME” on the don­gle.

The com­piler con­sists of a few ex­e­cutable files, no­tably RPGC. EXE, which is the com­piler, and SEU.EXE, which is a source ed­i­tor (“Source Entry Utility”). Here’s what we get when we launch SEU with­out the don­gle, af­ter a cou­ple of sec­onds:

A bit rude, but this gives us an im­por­tant clue: this pro­gram must be try­ing to com­mu­ni­cate over the par­al­lel port over the course of a few sec­onds (which could give us an op­por­tu­nity to pause it for de­bug­ging, and see what it’s do­ing dur­ing that time), and then ex­its with a mes­sage (which we can now find in a dis­as­sem­bly of the pro­gram, and trace how it gets there).

A great tool for dis­as­sem­bling ex­e­cuta­bles of this vin­tage is Reko. It un­der­stands 16-bit real mode ex­e­cuta­bles, and even at­tempts to de­com­pile them into read­able C code that cor­re­sponds to the dis­as­sem­bly.

And so, look­ing at the de­com­piled/​dis­as­sem­bled code in Reko, I ex­pected to find in and out in­struc­tions, which would be the tell­tale sign of the pro­gram try­ing to com­mu­ni­cate with the par­al­lel port through the PC’s I/O ports. However… I did­n’t see an in or out in­struc­tion any­where! But then I no­ticed some­thing: Reko dis­as­sem­bled the ex­e­cutable into two “segments”: 0800 and 0809, and I was only look­ing at seg­ment 0809.

If we look at seg­ment 0800, we see the smok­ing gun: in and out in­struc­tions, mean­ing that the copy-pro­tec­tion rou­tine is def­i­nitely here, and best of all, the en­tire code seg­ment is a mere 0x90 bytes, which sug­gests that the en­tire rou­tine should be pretty easy to un­ravel and un­der­stand. For some rea­son, Reko was not able to de­com­pile this code into a C rep­re­sen­ta­tion, but it still pro­duced a dis­as­sem­bly, which will work just fine for our pur­poses. Maybe this was a prim­i­tive form of ob­fus­ca­tion from those early days, which is now con­fus­ing Reko and pre­vent­ing it from as­so­ci­at­ing this chunk of code with the rest of the pro­gram… who knows.

Here is a GitHub Gist with the dis­as­sem­bly of this code, along with my an­no­ta­tions and notes. My x86 as­sem­bly knowl­edge is a lit­tle rusty, but here is the gist of what this code does:

It’s def­i­nitely a sin­gle self-con­tained rou­tine, in­tended to be called us­ing a “far” CALL in­struc­tion, since it re­turns with a RETF in­struc­tion.

It be­gins by de­tect­ing the ad­dress of the par­al­lel port, by read­ing the BIOS data area. If the com­puter has more than one par­al­lel port, the don­gle must be con­nected to the first par­al­lel port (LPT1).

It per­forms a loop where it writes val­ues to the data reg­is­ter of the par­al­lel port, and then reads the sta­tus reg­is­ter, and ac­cu­mu­lates re­sponses in the BH and BL reg­is­ters.

At the end of the rou­tine, the “result” of the whole pro­ce­dure is stored in the BX reg­is­ter (BH and BL to­gether), which will pre­sum­ably be “verified” by the caller of the rou­tine.

Very im­por­tantly, there does­n’t seem to be any “input” into this rou­tine. It does­n’t pop any­thing from the stack, nor does it care about any reg­is­ter val­ues passed into it. Which can only mean that the re­sult of this rou­tine is com­pletely con­stant! No mat­ter what com­pli­cated back-and-forth it does with the don­gle, the re­sult of this rou­tine should al­ways be the same.

With the knowl­edge that this rou­tine must exit with some magic value stored in BX, we can now patch the first few bytes of the rou­tine to do just that! Not yet know­ing which value to put in BX, let’s start with 1234:

BB 34 12 MOV BX, 1234h

CB RETF

Only the first four bytes need patch­ing — set BX to our de­sired value, and get out of there (RETF). Running the patched ex­e­cutable with these new bytes still fails (expectedly) with the same mes­sage of “No don­gle, no edit”, but it fails im­me­di­ately, in­stead of af­ter sev­eral sec­onds of talk­ing to the par­al­lel port. Progress!

Stepping through the dis­as­sem­bly more closely, we get an­other ma­jor clue: The only value that BH can be at the end of the rou­tine is 76h (this is hard-coded into the rou­tine). So, our to­tal value for the magic num­ber in BX must be of the form 76xx. In other words, only the BL value re­mains un­known:

BB __ 76 MOV BX, 76__h

CB RETF

Since BL is an 8-bit reg­is­ter, it can only have 256 pos­si­ble val­ues. And what do we do when we have 256 com­bi­na­tions to try? Brute force it! I whipped up a script that plugs a value into that par­tic­u­lar byte (from 0 to 255) and pro­gram­mat­i­cally launches the ex­e­cutable in DosBox, and ob­serves the out­put. Lo and be­hold, it worked! The brute forc­ing did­n’t take long at all, be­cause the cor­rect num­ber turned out to be… 6. Meaning that the to­tal magic num­ber in BX should be 7606h:

BB 06 76 MOV BX, 7606h

CB RETF

Bingo!

And then, pro­ceed­ing to ex­am­ine the other ex­e­cutable files in the com­piler suite, the par­al­lel port rou­tine turns out to be ex­actly the same. All of the ex­e­cuta­bles have the ex­act same copy pro­tec­tion logic, as if it was rub­ber-stamped onto them. In fact, when the com­piler (RPGC.EXE) com­piles some RPG source code, it seems to copy the par­al­lel port rou­tine from it­self into the com­piled pro­gram. That’s right: the patched ver­sion of the com­piler will pro­duce ex­e­cuta­bles with the same patched copy pro­tec­tion rou­tine! Very con­ve­nient.

I must say, this copy pro­tec­tion mech­a­nism seems a bit… sim­plis­tic? A hard­ware don­gle that just passes back a con­stant num­ber? Defeatable with a four-byte patch? Is this re­ally wor­thy of a patent? But who am I to pass judg­ment. It’s pos­si­ble that I haven’t fully un­der­stood the logic, and the copy pro­tec­tion will some­how re-sur­face in an­other way. It’s also pos­si­ble that the cre­ators of the RPG com­piler (Software West, Inc) did­n’t take proper ad­van­tage of the hard­ware don­gle, and used it in a way that is so eas­ily by­passed.

In any case, Software West’s RPG II com­piler is now free from the con­straint of the par­al­lel port don­gle! And at some point soon, I’ll work on purg­ing any PII from the com­piler di­rec­to­ries, and make this com­piler avail­able as an ar­ti­fact of com­put­ing his­tory. It does­n’t seem to be avail­able any­where else on the web. If any­one read­ing this was as­so­ci­ated with Software West Inc, feel free to get in touch — I have many ques­tions!

My per­sonal Claude as­sis­tant that runs se­curely in con­tain­ers. Lightweight and built to be un­der­stood and cus­tomized for your own needs.

OpenClaw is an im­pres­sive pro­ject with a great vi­sion. But I can’t sleep well run­ning soft­ware I don’t un­der­stand with ac­cess to my life. OpenClaw has 52+ mod­ules, 8 con­fig man­age­ment files, 45+ de­pen­den­cies, and ab­strac­tions for 15 chan­nel providers. Security is ap­pli­ca­tion-level (allowlists, pair­ing codes) rather than OS iso­la­tion. Everything runs in one Node process with shared mem­ory.

NanoClaw gives you the same core func­tion­al­ity in a code­base you can un­der­stand in 8 min­utes. One process. A hand­ful of files. Agents run in ac­tual Linux con­tain­ers with filesys­tem iso­la­tion, not be­hind per­mis­sion checks.

git clone https://​github.com/​gavrielc/​nan­oclaw.git

cd nan­oclaw

claude

Small enough to un­der­stand. One process, a few source files. No mi­croser­vices, no mes­sage queues, no ab­strac­tion lay­ers. Have Claude Code walk you through it.

Secure by iso­la­tion. Agents run in Linux con­tain­ers (Apple Container on ma­cOS, or Docker). They can only see what’s ex­plic­itly mounted. Bash ac­cess is safe be­cause com­mands run in­side the con­tainer, not on your host.

Built for one user. This is­n’t a frame­work. It’s work­ing soft­ware that fits my ex­act needs. You fork it and have Claude Code make it match your ex­act needs.

Customization = code changes. No con­fig­u­ra­tion sprawl. Want dif­fer­ent be­hav­ior? Modify the code. The code­base is small enough that this is safe.

AI-native. No in­stal­la­tion wiz­ard; Claude Code guides setup. No mon­i­tor­ing dash­board; ask Claude what’s hap­pen­ing. No de­bug­ging tools; de­scribe the prob­lem, Claude fixes it.

Skills over fea­tures. Contributors should­n’t add fea­tures (e.g. sup­port for Telegram) to the code­base. Instead, they con­tribute claude code skills like /add-telegram that trans­form your fork. You end up with clean code that does ex­actly what you need.

Best har­ness, best model. This runs on Claude Agent SDK, which means you’re run­ning Claude Code di­rectly. The har­ness mat­ters. A bad har­ness makes even smart mod­els seem dumb, a good har­ness gives them su­per­pow­ers. Claude Code is (IMO) the best har­ness avail­able.

No ToS gray ar­eas. Because it uses Claude Agent SDK na­tively with no hacks or workarounds, us­ing your sub­scrip­tion with your auth to­ken is com­pletely le­git­i­mate (I think). No risk of be­ing shut down for terms of ser­vice vi­o­la­tions (I am not a lawyer).

* Isolated group con­text - Each group has its own CLAUDE.md mem­ory, iso­lated filesys­tem, and runs in its own con­tainer sand­box with only that filesys­tem mounted

* Main chan­nel - Your pri­vate chan­nel (self-chat) for ad­min con­trol; every other group is com­pletely iso­lated

* Scheduled tasks - Recurring jobs that run Claude and can mes­sage you back

* Optional in­te­gra­tions - Add Gmail (/add-gmail) and more via skills

Talk to your as­sis­tant with the trig­ger word (default: @Andy):

From the main chan­nel (your self-chat), you can man­age groups and tasks:

There are no con­fig­u­ra­tion files to learn. Just tell Claude Code what you want:

* “Remember in the fu­ture to make re­sponses shorter and more di­rect”

Or run /customize for guided changes.

The code­base is small enough that Claude can safely mod­ify it.

If you want to add Telegram sup­port, don’t cre­ate a PR that adds Telegram along­side WhatsApp. Instead, con­tribute a skill file (.claude/skills/add-telegram/SKILL.md) that teaches Claude Code how to trans­form a NanoClaw in­stal­la­tion to use Telegram.

Users then run /add-telegram on their fork and get clean code that does ex­actly what they need, not a bloated sys­tem try­ing to sup­port every use case.

* /add-telegram - Add Telegram as chan­nel. Should give the user op­tion to re­place WhatsApp or add as ad­di­tional chan­nel. Also should be pos­si­ble to add it as a con­trol chan­nel (where it can trig­ger ac­tions) or just a chan­nel that can be used in ac­tions trig­gered else­where

* /add-clear - Add a /clear com­mand that com­pacts the con­ver­sa­tion (summarizes con­text while pre­serv­ing crit­i­cal in­for­ma­tion in the same ses­sion). Requires fig­ur­ing out how to trig­ger com­paction pro­gram­mat­i­cally via the Claude Agent SDK.

Single Node.js process. Agents ex­e­cute in iso­lated Linux con­tain­ers with mounted di­rec­to­ries. IPC via filesys­tem. No dae­mons, no queues, no com­plex­ity.

Why WhatsApp and not Telegram/Signal/etc?

Because I use WhatsApp. Fork it and run a skill to change it. That’s the whole point.

Why Apple Container in­stead of Docker?

On ma­cOS, Apple Container is light­weight, fast, and op­ti­mized for Apple sil­i­con. But Docker is also fully sup­ported—dur­ing /setup, you can choose which run­time to use. On Linux, Docker is used au­to­mat­i­cally.

Can I run this on Linux?

Yes. Run /setup and it will au­to­mat­i­cally con­fig­ure Docker as the con­tainer run­time. Thanks to @dotsetgreg for con­tribut­ing the /convert-to-docker skill.

Agents run in con­tain­ers, not be­hind ap­pli­ca­tion-level per­mis­sion checks. They can only ac­cess ex­plic­itly mounted di­rec­to­ries. You should still re­view what you’re run­ning, but the code­base is small enough that you ac­tu­ally can. See docs/​SE­CU­RITY.md for the full se­cu­rity model.

We don’t want con­fig­u­ra­tion sprawl. Every user should cus­tomize it to so that the code matches ex­actly what they want rather than con­fig­ur­ing a generic sys­tem. If you like hav­ing con­fig files, tell Claude to add them.

Ask Claude Code. “Why is­n’t the sched­uler run­ning?” “What’s in the re­cent logs?” “Why did this mes­sage not get a re­sponse?” That’s the AI-native ap­proach.

Why is­n’t the setup work­ing for me?

I don’t know. Run claude, then run /debug. If claude finds an is­sue that is likely af­fect­ing other users, open a PR to mod­ify the setup SKILL.md.

What changes will be ac­cepted into the code­base?

Security fixes, bug fixes, and clear im­prove­ments to the base con­fig­u­ra­tion. That’s it.

Everything else (new ca­pa­bil­i­ties, OS com­pat­i­bil­ity, hard­ware sup­port, en­hance­ments) should be con­tributed as skills.

This keeps the base sys­tem min­i­mal and lets every user cus­tomize their in­stal­la­tion with­out in­her­it­ing fea­tures they don’t want.

My iPhone 16 Pro Max pro­duces garbage out­put when run­ning MLX LLMs. An iPhone 15 Pro runs the same code per­fectly. A MacBook Pro also runs the same code per­fectly. The ten­sor out­puts on the 16 show nu­mer­i­cal val­ues an or­der of mag­ni­tude wrong. I sus­pect it points to a hard­ware de­fect in the Neural Engine or some other ML-needed sys­tem.

It was a PITA to de­bug, but at least I got a blog post out of it.

This was sup­posed to be a sim­ple, un­wind­ing-time pro­ject.

For the past few months I’ve been work­ing on a Moltbot clone that I’ve been call­ing Schmidt. It ba­si­cally does the same kind of thing but with a cus­tom chat UI in­stead of us­ing Telegram, WhatsApp or other “I-can’t-afford-to-be-banned-from” Service. This pro­ject has been con­sum­ing early days and late nights, so, to un­wind, I de­cided that it may be a good idea to do some­thing sim­pler. Since I re­cently sub­scribed to MiniMax M2.1, I thought I would do what many do and build a sim­ple ex­pense track­ing app to test out the model.

* Automatically, upon each pay­ment, add the ex­pense to my app

* Update an Apple Watch com­pli­ca­tion with the % of my monthly bud­get spent

* Categorize the pur­chase for later analy­sis

This all comes from be­ing ba­si­cally or­phaned by Nubank’s amaz­ing na­tive app (since re­placed by a less-full-fea­tured Flutter ver­sion).

Integrating with Shortcuts is man­ual, but re­li­able. Within 15 min­utes I had a ver­sion of the app that could reg­is­ter pur­chases. The Apple Watch com­pli­ca­tion, the main goal, can come later. I’d rather get the clas­si­fi­ca­tion fea­ture, which should be easy, done quickly — so I fig­ured.

Given the new LLM-bonanza we’ve been liv­ing through, it’s no sur­prise that Apple has their own set of APIs de­vel­op­ers such as me can use. Reading up on the doc­u­men­ta­tion, it’s a mat­ter of check­ing for the avail­abil­ity of the fea­ture and then ask­ing the model to ei­ther re­ply to a tex­tual query or, in my case, cat­e­go­rize a re­quest.

MiniMax raced through it in a sin­gle prompt and then I ran it on my iPhone. First ex­pense was a pur­chase at a shop called “Kasai Kitchin”, clas­si­fied as… un­known.

Weird.

Checking the logs, it was clear: the model sup­port was down­load­ing. The fea­ture had­n’t been en­abled. Again, weird. I should have it on. Anyway, I go into set­tings, do the weird dance of tog­gling it on and off — sadly, that’s not sur­pris­ing on Apple’s ser­vices. Maybe my Settings.app got stuck in a weird state, who knows? — and wait for it to down­load.

After 4h I re­al­ized it was not go­ing any­where. Looking it up, it seems that many have the same is­sue (this thread shows 12 pages of frus­trated users). Again, not a sur­prise for Apple’s ser­vices re­cently.

Oh well, time to give up on the Apple Intelligence ap­proach. Let’s move on to the next one.

Well, the iOS frame­work en­gi­neers don’t seem to be the only en­gi­neers at Apple ca­pa­ble of com­ing up with Machine Learning APIs in Swift. Apparently, there’s a whole sep­a­rate way of do­ing it — with mod­els down­loaded to your app. Not great for the user’s stor­age, but great for me!

Again, MiniMax does it in a heart­beat, spe­cially af­ter be­ing given doc­u­men­ta­tion and one or two Medium posts. Time to run on my iPhone and… gib­ber­ish.

The CPU spins to 100% and the model starts gen­er­at­ing. But it’s all gib­ber­ish. And no “stop” to­ken is gen­er­ated, so this goes on for long.

At this point, the only ex­pla­na­tion is: I’m com­pletely in­com­pe­tent and can’t even get a sim­ple “ready made” frame­work to ex­e­cute what I want. Or, rather, MiniMax is! The good thing about of­fload­ing your work to an LLM is that you can blame it for your short­com­ings. Time to get my hands dirty and do it my­self, typ­ing code on my key­board, like the an­cient Mayan and Aztec pro­gram­mers prob­a­bly did.

I went back to the doc­u­men­ta­tion, to the Medium posts and, much to my sur­prise: MiniMax had fol­lowed it to the let­ter. Even went back to some dep­re­cated meth­ods of gen­er­a­tion and it also was gib­ber­ish. And now there’s no one to blame, but my­self. I go to work every­day and this im­pos­tor-syn­drome in­duc­ing prob­lem silently con­sumes me.

After 3 days of try­ing to get it to work, I’m ready to give up…

…until, on a Tuesday morn­ing, at 7-8 AM, I have an idea: let me, just in case, run this on my old iPhone 15 Pro. Up to this point, I was run­ning it on my daily dri­ver, an iPhone 16 Pro Max that was a re­place­ment phone sent by Apple Care af­ter a small club­bing mishap (in which my iPhone was ir­repara­bly crashed). I rush to get every­thing ready be­fore it’s time to go to work and: it works! Gemma, Qwen, and all other mod­els gen­er­ate co­her­ent re­sponses!

I stop and think: this can­not be a hard­ware is­sue, right? Of course not. The iPhone 15 is still run­ning iOS 18. The iPhone 16 is run­ning 26. It must be an OS is­sue. Well, time to be late for my work standup and up­date the old phone. The cu­rios­ity is too much. Many min­utes later… same re­sults, now on iOS 26. The plot is thick­en­ing.

After that work day, and af­ter many lunch and cof­fee dis­cus­sions with cowork­ers about the sources of my trou­bles, I get home and im­me­di­ately set my­self on de­bug­ging MLX as it runs, if pos­si­ble. The game plan is:

* Use a known-to-be-re­li­able model, that fits in RAM (I went with quan­tized Gemma)

* Use a sim­ple prompt, in my case “What is 2+2?“To be re­ally pedan­tic: the prompt was

* To be re­ally pedan­tic: the prompt was

* Run every­thing with tem­per­a­ture set to 0.0 — maybe that’s enough to re­move vari­abil­ity

* Find where the model it­er­ates through the lay­ers and

* Print out the MLXArray/Tensor with the val­ues on each layer as the in­put goes through

A few mo­ments later and I find where I need to be. Added the break­points, added the logs and off to the races.

I run it on my iPhone 16 Pro Max. The model loads and the prompt is “What is 2+2?”. The ten­sors start print­ing out, line af­ter line af­ter line. For once, the logs aren’t com­plete gib­ber­ish — they’re num­bers. Floating point val­ues rep­re­sent­ing the mod­el’s in­ter­nal state as it processes the in­put. I save the out­put to a file and do the same on my iPhone 15 Pro. Same model, same prompt, same code. Time to com­pare.

I grep for a pat­tern I know should be con­sis­tent — an ar­ray at log-line 58, right be­fore the val­ues get nor­mal­ized/​soft­maxed. On a work­ing de­vice, I hy­poth­e­size this should be the same every time.

On the iPhone 15 Pro:

3: “[[[[53.875, 62.5625, -187.75, …, 42.625, 6.25, -21.5625]]]]”

On the iPhone 16 Pro Max:

3: “[[[[191.5, 23.625, 173.75, …, 1298, -147.25, -162.5]]]]”

Huh. Not close. Not at all. These val­ues are or­ders of mag­ni­tude off. I dou­ble check the start of the logs and both phones show the same:

1: “array([[[0.162842, -0.162842, -0.48877, …, -0.176636, 0.0001297, 0.088501],\n [-0.348633, -2.78906, 0, …, 0.84668, 0, -1.69336],\n [-1.30957, 1.57324, -1.30957, …, -0.0010376, -0.0010376, 1.12305],\n …,\n [-0.348633, -2.78906, 0, …, 0.84668, 0, -1.69336],\n [0.296875, 0.59375, 0.890625, …, -0.59375, 0.296875, -0.890137],\n [1.02734, -0.616211, -0.616211, …, -0.275879, -0.551758, 0.275879]]], dtype=float16)”

OK, so the model re­ceives the same thing as in­put, but at some point, the val­ues start to go off. Like, way off. In or­der to make sure I’m not crazy, I do one last thing: run the same thing on my Mac. Make the app run on iPad com­pat­i­bil­ity mode and…

3: “[[[[53.875, 62.5625, -187.75, …, 42.625, 6.25, -21.5625]]]]”

The model is­n’t bro­ken. The code is­n’t bro­ken. Most im­por­tantly, I’m not bro­ken*. My phone is bro­ken.

*arguable, but be­sides the point here

Let me ex­plain what I think it’s go­ing on here: the iPhone 16 Pro Max con­tains Apple’s A18 chip with its Neural Engine—a spe­cial­ized ac­cel­er­a­tor for ma­chine learn­ing op­er­a­tions. MLX uses Metal to com­pile ten­sor op­er­a­tions for this ac­cel­er­a­tor. Somewhere in that stack, the com­pu­ta­tions are go­ing very wrong. I don’t think it’s a wide­spread is­sue but, I do get dis­ap­pointed that a rel­a­tively newly re­placed iPhone from Apple Care came with such an is­sue.

However, if my Apple Intelligence trou­bles are re­lated — and they might as well be, I’d as­sume that code and MLX are not dis­sim­i­lar in op­er­a­tions be­ing done –, it could be that all the 12 pages of users are users in a sim­i­lar dillema, but with­out the means of de­bug­ging it.

I spent 3 days think­ing I was in­com­pe­tent. I blamed MiniMax. I blamed my­self. The en­tire time, my $1,400 phone had a bro­ken hard­ware. I could lose more time fig­ur­ing out ex­actly what is wrong with it but it’s lit­er­ally not worth my time.

I guess I can at least take a les­son that, when de­bug­ging, I should al­ways con­sider the phys­i­cal layer. I spent three days as­sum­ing this was a soft­ware prob­lem — my code, the li­brary, the frame­work, my skills as a de­vel­oper. The break­through was ba­si­cally: “What if I’m not dumb and it’s not my code?”

As for my phone: it’ll prob­a­bly go back to Apple, as a trade in for a new iPhone 17 Pro Max that hope­fully 🤞 can do math.

Well, now it’s Feb. 1st and I have an iPhone 17 Pro Max to test with and… every­thing works as ex­pected. So it’s pretty safe to say that THAT spe­cific in­stance of iPhone 16 Pro Max was hard­ware-de­fec­tive.

Xikipedia is a pseudo so­cial me­dia feed that al­go­rith­mi­cally shows you con­tent from Simple Wikipedia. It is made as a demon­stra­tion of how even a ba­sic non-ML al­go­rithm with no data from other users can quickly learn what you en­gage with to sug­gest you more sim­i­lar con­tent. No data is col­lected or shared here, the al­go­rithm runs lo­cally and the data dis­ap­pears once you re­fresh or close the tab.

Source code on GitHub, dis­cuss on fedi, bluesky, or twit­ter.

Pick some cat­e­gories to get started (optional)

Or add your own

Since the con­tent and im­ages shown is from ran­dom Wikipedia ar­ti­cles, you will likely see NSFW con­tent. Please only con­tinue if you’re an adult.

It still shocks me how much dif­fer­ence there is be­tween AI users. I think it ex­plains a lot about the of­ten con­fus­ing (to me) cov­er­age in the me­dia about AI and its pro­duc­tiv­ity im­pact.

I think it’s clear there are two types of users to me now, and by ex­ten­sion, the or­gan­i­sa­tions they work for.

First, you have the “power users”, who are all in on adopt­ing new AI tech­nol­ogy - Claude Code, MCPs, skills, etc. Surprisingly, these peo­ple are of­ten not very tech­ni­cal. I’ve seen far more non-tech­ni­cal peo­ple than I’d ex­pect us­ing Claude Code in ter­mi­nal, us­ing it for dozens of non-SWE tasks. Finance roles seem to be get­ting enor­mous value out of it (unsurprisingly, as Excel on the fi­nance side is re­mark­ably lim­it­ing when you start get­ting used to the power of a full pro­gram­ming ecosys­tem like Python).

Secondly, you have the peo­ple who are gen­er­ally only chat­ting to ChatGPT or sim­i­lar. So many peo­ple I would­n’t ex­pect are still in this camp.

One ex­tremely jar­ring re­al­i­sa­tion was just how poor Microsoft Copilot is. It has enor­mous mar­ket share in en­ter­prise as it is bun­dled in with var­i­ous Office 365 sub­scrip­tions, yet feels like a poorly cloned ver­sion of the (already not great) ChatGPT in­ter­face. The “agent” fea­ture is ab­solutely laugh­able com­pared to what a CLI cod­ing agent (including Microsoft’s own GitHub con­fus­ingly-named-Copi­lot CLI).

To re­ally un­der­line this, Microsoft it­self is rolling out Claude Code to in­ter­nal teams, de­spite (obviously) hav­ing ac­cess to Copilot at near zero cost, and sig­nif­i­cant own­er­ship of OpenAI. I think this sums up quite how far be­hind they are

The prob­lem is that in en­ter­prise Copilot is of­ten the only al­lowed AI tool, so that’s all you can use with­out ei­ther po­ten­tially los­ing your job or spend­ing a lot of ef­fort try­ing to pro­cure and use an­other AI tool. It’s slow, the code ex­e­cu­tion tool in it does­n’t work prop­erly and fails hor­ri­bly with large(ish) files, seem­ingly due to very very ag­gres­sive mem­ory and CPU lim­i­ta­tions.

This is be­com­ing an ex­is­ten­tial risk for many en­ter­prises. Senior de­ci­sion mak­ers are no doubt us­ing these tools with such poor re­sults and are there­fore writ­ing off AI, and/​or spend­ing a for­tune with var­i­ous large con­sult­ing and man­age­ment con­sul­tancy out­fits to get not very far.

Enterprise cor­po­rate IT pol­icy re­sults in a com­pletely dis­as­trous com­bi­na­tion of lim­i­ta­tions that ba­si­cally en­sure that peo­ple can­not suc­cess­fully use more ‘cutting edge’ AI tool­ing.

Firstly, they tend to have ex­tremely locked down en­vi­ron­ments, with no abil­ity to run even a ba­sic script in­ter­preter lo­cally (VBA if you are lucky, but even that may be lim­ited by var­i­ous Group Policies). Secondly, they’re locked into legacy soft­ware with no real “internal fac­ing” APIs on their core work­flows, which means agents have noth­ing to con­nect to even if you could run them.

Finally, they tend to have ex­tremely siloed en­gi­neer­ing de­part­ments (which may be com­pletely out­sourced), so there’s no­body in­ter­nally who could build the in­fra­struc­ture to run safely sand­boxed agents even if they wanted to.

The se­cu­rity con­cerns are real. You def­i­nitely do not want peo­ple YOLOing cod­ing agents over pro­duc­tion data­bases with no con­trol, and as I’ve cov­ered, sand­box­ing agents is dif­fi­cult.

However, this does cause a real prob­lem in so much that you don’t have an en­gi­neer­ing team that can help build the in­fra­struc­ture to run safely sand­boxed agents against your datasets.

I’ve also spo­ken to many smaller com­pa­nies that don’t have all this bag­gage and are ab­solutely fly­ing with AI. The gap is so ob­vi­ous when you can see both sides of it.

On one hand, you have Microsoft’s (awful) Copilot in­te­gra­tion for Excel (in fair­ness, the Gemini in­te­gra­tion in Google Sheets is also bad). So you can imag­ine fi­nan­cial di­rec­tors try­ing to use it and it mak­ing a com­plete mess of the most sim­ple tasks and never touch­ing it again.

On the other you have a non-tech­ni­cal ex­ec­u­tive who’s got his head round Claude Code and can run e.g. Python lo­cally. I helped one re­cently al­most one-shot con­vert­ing a 30 sheet mind numb­ingly com­pli­cated Excel fi­nan­cial model to Python with Claude Code.

Once the model is in Python, you ef­fec­tively have a data sci­ence team in your pocket with Claude Code. You can eas­ily run Monte Carlo sim­u­la­tions, pull ex­ter­nal data sources as in­puts, build web dash­boards and have Claude Code work with you to re­ally in­te­grate weak­nesses in your model (or busi­ness). It’s a pretty mag­i­cal ex­pe­ri­ence watch­ing some­one re­alise they have so much power at their fin­ger­tips, with­out hav­ing to grind away for hours/​days in Excel.

This ef­fec­tively leads to a sit­u­a­tion where smaller com­pany em­ploy­ees are able to be so much more pro­duc­tive than the equiv­a­lent at an en­ter­prise. It of­ten used to be that peo­ple at small com­pa­nies re­ally en­vied the re­sources & teams that their larger com­peti­tors had ac­cess to - but in­creas­ingly I think the pen­du­lum is swing­ing the other way.

I’m start­ing to get a feel for what the fu­ture of work looks like. The first ob­ser­va­tion is that (often) the real leaps are be­ing made or­gan­i­cally by em­ploy­ees, not from a top down AI strat­egy. Where I see the real pro­duc­tiv­ity gains are small teams de­cid­ing to try and build an AI as­sisted work­flow for a process, and as they are the ones that know that process in­side out they can get very good re­sults - un­like an of­ten out­sourced soft­ware en­gi­neer­ing team who have ab­solutely zero ex­pe­ri­ence do­ing the process that they are help­ing au­to­mate. I think this is the op­po­site of what most ‘digital trans­for­ma­tion’ pro­jects looked like in en­ter­prise.

Secondly, com­pa­nies that have some sort of APIs for in­ter­nal sys­tems are go­ing to be able to do far more than those that don’t. This might be as sim­ple as a read­only data ware­house em­ploy­ees can con­nect to and run queries on be­half of users, or it could be as far as many com­plex core busi­ness processes be­ing com­pletely APId.

Thirdly, this all needs to be wrapped up in some sort of se­cure mech­a­nism, but I ac­tu­ally think a hosted VM run­ning some sort of code agent with well thought through net­work re­stric­tions would work well, at least for read only re­port­ing. For cre­at­ing and edit­ing data I don’t think we quite have the model for non tech­ni­cal users (especially) to be able to use agents safely (yet).

Finally, legacy en­ter­prise SaaS play­ers ei­ther have enor­mous lock in, or are ex­tremely vul­ner­a­ble de­pend­ing on how you look at it. Most are not “API-first” prod­ucts, and the APIs they have tend to be re­ally for de­vel­oper us­age - not op­ti­mised for thou­sands of em­ploy­ees to ping in weird and won­der­ful in­ef­fi­cient ways. But if they are the source of truth for the com­pany, they are go­ing to be very dif­fi­cult to mi­grate away from and bot­tle­neck a lot of pro­duc­tiv­ity gains.

Again, smaller com­pa­nies tend to use newer prod­ucts which have far bet­ter thought through APIs (simply be­cause they weren’t of­ten orig­i­nally cre­ated many decades ago with var­i­ous in­ter­faces grafted on over time).

The user prompts, the agent syn­the­sises - con­nect­ing to APIs and pro­duc­ing out­puts on de­mand.

What I’ve come to re­alise is that the power of hav­ing a bash sand­box with a pro­gram­ming lan­guage and API ac­cess to sys­tems, com­bined with an agen­tic har­ness, re­sults in out­ra­geously good re­sults for non tech­ni­cal users. It can ef­fec­tively re­place nearly every stan­dard pro­duc­tiv­ity app out there - both clas­sic Microsoft Office style ones - and also web apps. It can build any re­port you ask for - and ex­port it how­ever you like. To me this seems like the fu­ture of knowl­edge work.

The bi­fur­ca­tion is real and seems to be, if any­thing, speed­ing up dra­mat­i­cally. I don’t think there’s ever been a time in his­tory where a tiny team can out­com­pete a com­pany one thou­sand times its size so eas­ily.

Termux is an Android ter­mi­nal ap­pli­ca­tion and Linux en­vi­ron­ment.

Note that this repos­i­tory is for the app it­self (the user in­ter­face and the ter­mi­nal em­u­la­tion). For the pack­ages in­stal­lable in­side the app, see ter­mux/​ter­mux-pack­ages.

Quick how-to about Termux pack­age man­age­ment is avail­able at Package Management. It also has info on how to fix repos­i­tory is un­der main­te­nance or down er­rors when run­ning apt or pkg com­mands.

We are look­ing for Termux Android ap­pli­ca­tion main­tain­ers.

NOTICE: Termux may be un­sta­ble on Android 12+. Android OS will kill any (phantom) processes greater than 32 (limit is for all apps com­bined) and also kill any processes us­ing ex­ces­sive CPU. You may get [Process com­pleted (signal 9) - press Enter] mes­sage in the ter­mi­nal with­out ac­tu­ally ex­it­ing the shell process your­self. Check the re­lated is­sue #2366, is­sue tracker, phan­tom cached and empty processes docs and this TLDR com­ment on how to dis­able trim­ming of phan­tom and ex­ces­sive cpu us­age processes. A proper docs page will be added later. An op­tion to dis­able the killing should be avail­able in Android 12L or 13, so up­grade at your own risk if you are on Android 11, spe­cially if you are not rooted.

The core Termux app comes with the fol­low­ing op­tional plu­gin apps.

NOTICE: It is highly rec­om­mended that you up­date to v0.118.0 or higher ASAP for var­i­ous bug fixes, in­clud­ing a crit­i­cal world-read­able vul­ner­a­bil­ity re­ported here. See be­low for in­for­ma­tion re­gard­ing Termux on Google Play.

Termux can be ob­tained through var­i­ous sources listed be­low for only Android >= 7 with full sup­port for apps and pack­ages.

Support for both app and pack­ages was dropped for Android 5 and 6 on 2020-01-01 at v0.83, how­ever it was re-added just for the app with­out any sup­port for pack­age up­dates on 2022-05-24 via the GitHub sources. Check here for the de­tails.

The APK files of dif­fer­ent sources are signed with dif­fer­ent sig­na­ture keys. The Termux app and all its plu­g­ins use the same share­dUserId com.ter­mux and so all their APKs in­stalled on a de­vice must have been signed with the same sig­na­ture key to work to­gether and so they must all be in­stalled from the same source. Do not at­tempt to mix them to­gether, i.e do not try to in­stall an app or plu­gin from F-Droid and an­other one from a dif­fer­ent source like GitHub. Android Package Manager will also nor­mally not al­low in­stal­la­tion of APKs with dif­fer­ent sig­na­tures and you will get er­rors on in­stal­la­tion like App not in­stalled, Failed to in­stall due to an un­known er­ror, INSTALL_FAILED_UPDATE_INCOMPATIBLE, INSTALL_FAILED_SHARED_USER_INCOMPATIBLE, sig­na­tures do not match pre­vi­ously in­stalled ver­sion, etc. This re­stric­tion can be by­passed with root or with cus­tom roms.

If you wish to in­stall from a dif­fer­ent source, then you must unin­stall any and all ex­ist­ing Termux or its plu­gin app APKs from your de­vice first, then in­stall all new APKs from the same new source. Check Uninstallation sec­tion for de­tails. You may also want to con­sider Backing up Termux be­fore the unin­stal­la­tion so that you can re­store it af­ter re-in­stalling from Termux dif­fer­ent source.

In the fol­low­ing para­graphs, “bootstrap” refers to the min­i­mal pack­ages that are shipped with the ter­mux-app it­self to start a work­ing shell en­vi­ron­ment. Its zips are built and re­leased here.

Termux ap­pli­ca­tion can be ob­tained from F-Droid from here.

You do not need to down­load the F-Droid app (via the Download F-Droid link) to in­stall Termux. You can down­load the Termux APK di­rectly from the site by click­ing the Download APK link at the bot­tom of each ver­sion sec­tion.

It usu­ally takes a few days (or even a week or more) for up­dates to be avail­able on F-Droid once an up­date has been re­leased on GitHub. The F-Droid re­leases are built and pub­lished by F-Droid once they de­tect a new GitHub re­lease. The Termux main­tain­ers do not have any con­trol over the build­ing and pub­lish­ing of the Termux apps on F-Droid. Moreover, the Termux main­tain­ers also do not have ac­cess to the APK sign­ing keys of F-Droid re­leases, so we can­not re­lease an APK our­selves on GitHub that would be com­pat­i­ble with F-Droid re­leases.

The F-Droid app of­ten may not no­tify you of up­dates and you will man­u­ally have to do a pull down swipe ac­tion in the Updates tab of the app for it to check up­dates. Make sure bat­tery op­ti­miza­tions are dis­abled for the app, check https://​don­tkillmyapp.com/ for de­tails on how to do that.

Only a uni­ver­sal APK is re­leased, which will work on all sup­ported ar­chi­tec­tures. The APK and boot­strap in­stal­la­tion size will be ~180MB. F-Droid does not sup­port ar­chi­tec­ture spe­cific APKs.

Termux ap­pli­ca­tion can be ob­tained on GitHub ei­ther from GitHub Releases for ver­sion >= 0.118.0 or from GitHub Build Action work­flows. For an­droid >= 7, only in­stall apt-an­droid-7 vari­ants. For an­droid 5 and 6, only in­stall apt-an­droid-5 vari­ants.

The APKs for GitHub Releases will be listed un­der Assets drop-down of a re­lease. These are au­to­mat­i­cally at­tached when a new ver­sion is re­leased.

The APKs for GitHub Build ac­tion work­flows will be listed un­der Artifacts sec­tion of a work­flow run. These are cre­ated for each com­mit/​push done to the repos­i­tory and can be used by users who don’t want to wait for re­leases and want to try out the lat­est fea­tures im­me­di­ately or want to test their pull re­quests. Note that for ac­tion work­flows, you need to be logged into a GitHub ac­count for the Artifacts links to be en­abled/​click­able. If you are us­ing the GitHub app, then make sure to open work­flow link in a browser like Chrome or Firefox that has your GitHub ac­count logged in since the in-app browser may not be logged in.

The APKs for both of these are de­bug­gable and are com­pat­i­ble with each other but they are not com­pat­i­ble with other sources.

Both uni­ver­sal and ar­chi­tec­ture spe­cific APKs are re­leased. The APK and boot­strap in­stal­la­tion size will be ~180MB if us­ing uni­ver­sal and ~120MB if us­ing ar­chi­tec­ture spe­cific. Check here for de­tails.

Security warn­ing: APK files on GitHub are signed with a test key that has been shared with com­mu­nity. This IS NOT an of­fi­cial de­vel­oper key and every­one can use it to gen­er­ate re­leases for own test­ing. Be very care­ful when us­ing Termux GitHub builds ob­tained else­where ex­cept https://​github.com/​ter­mux/​ter­mux-app. Everyone is able to use it to forge a ma­li­cious Termux up­date in­stal­lable over the GitHub build. Think twice about in­stalling Termux builds dis­trib­uted via Telegram or other so­cial me­dia. If your de­vice get caught by mal­ware, we will not be able to help you.

The test key shall not be used to im­per­son­ate @termux and can’t be used for this any­way. This key is not trusted by us and it is quite easy to de­tect its use in user gen­er­ated con­tent.

There is cur­rently a build of Termux avail­able on Google Play for Android 11+ de­vices, with ex­ten­sive ad­just­ments in or­der to pass pol­icy re­quire­ments there. This is un­der de­vel­op­ment and has miss­ing func­tion­al­ity and bugs (see here for sta­tus up­dates) com­pared to the sta­ble F-Droid build, which is why most users who can should still use F-Droid or GitHub build as men­tioned above.

Currently, Google Play will try to up­date in­stal­la­tions away from F-Droid ones. Updating will still fail as share­dUserId has been re­moved. A planned 0.118.1 F-Droid re­lease will fix this by set­ting a higher ver­sion code than used for the PlayStore app. Meanwhile, to pre­vent Google Play from at­tempt­ing to down­load and then fail to in­stall the Google Play re­leases over ex­ist­ing in­stal­la­tions, you can open the Termux apps pages on Google Play and then click on the 3 dots op­tions but­ton in the top right and then dis­able the Enable auto up­date tog­gle. However, the Termux apps up­dates will still show in the PlayStore app up­dates list.

If you want to help out with test­ing the Google Play build (or can­not in­stall Termux from other sources), be aware that it’s built from a sep­a­rate repos­i­tory (https://​github.com/​ter­mux-play-store/) - be sure to re­port is­sues there, as any is­sues en­coun­tered might very well be spe­cific to that repos­i­tory.

Uninstallation may be re­quired if a user does­n’t want Termux in­stalled in their de­vice any­more or is switch­ing to a dif­fer­ent in­stall source. You may also want to con­sider Backing up Termux be­fore the unin­stal­la­tion.

To unin­stall Termux com­pletely, you must unin­stall any and all ex­ist­ing Termux or its plu­gin app APKs listed in Termux App and Plugins.

Go to Android Settings -> Applications and then look for those apps. You can also use the search fea­ture if it’s avail­able on your de­vice and search ter­mux in the ap­pli­ca­tions list.

Even if you think you have not in­stalled any of the plu­g­ins, it’s strongly sug­gested to go through the ap­pli­ca­tion list in Android set­tings and dou­ble-check.

All com­mu­nity links are avail­able here.

The main ones are the fol­low­ing.

You can help de­bug prob­lems of the Termux app and its plu­g­ins by set­ting ap­pro­pri­ate log­cat Log Level in Termux app set­tings -> -> Debugging -> Log Level (Requires Termux app ver­sion >= 0.118.0). The Log Level de­faults to Normal and log level Verbose cur­rently logs ad­di­tional in­for­ma­tion. Its best to re­vert log level to Normal af­ter you have fin­ished de­bug­ging since pri­vate data may oth­er­wise be passed to log­cat dur­ing nor­mal op­er­a­tion and more­over, ad­di­tional log­ging in­creases ex­e­cu­tion time.

The plu­gin apps do not ex­e­cute the com­mands them­selves but send ex­e­cu­tion in­tents to Termux app, which has its own log level which can be set in Termux app set­tings -> Termux -> Debugging -> Log Level. So you must set log level for both Termux and the re­spec­tive plu­gin app set­tings to get all the info.

Once log lev­els have been set, you can run the log­cat com­mand in Termux app ter­mi­nal to view the logs in re­al­time (Ctrl+c to stop) or use log­cat -d > log­cat.txt to take a dump of the log. You can also view the logs from a PC over ADB. For more in­for­ma­tion, check of­fi­cial an­droid log­cat guide here.

Moreover, users can gen­er­ate ter­mux files stat info and log­cat dump au­to­mat­i­cally too with ter­mi­nal’s long hold op­tions menu More -> Report Issue op­tion and se­lect­ing YES in the prompt shown to add de­bug info. This can be help­ful for re­port­ing and de­bug­ging other is­sues. If the re­port gen­er­ated is too large, then Save To File op­tion in con­text menu (3 dots on top right) of ReportActivity can be used and the file viewed/​shared in­stead.

Users must post com­plete re­port (optionally with­out sen­si­tive info) when re­port­ing is­sues. Issues opened with (partial) screen­shots of er­ror re­ports in­stead of text will likely be au­to­mat­i­cally closed/​deleted.

The ter­mux-shared li­brary was added in v0.109. It de­fines shared con­stants and utils of the Termux app and its plu­g­ins. It was cre­ated to al­low for the re­moval of all hard­coded paths in the Termux app. Some of the ter­mux plu­g­ins are us­ing this as well and rest will in fu­ture. If you are con­tribut­ing code that is us­ing a con­stant or a util that may be shared, then de­fine it in ter­mux-shared li­brary if it cur­rently does­n’t ex­ist and ref­er­ence it from there. Update the rel­e­vant changel­ogs as well. Pull re­quests us­ing hard­coded val­ues will/​should not be ac­cepted. Termux app and plu­gin spe­cific classes must be added un­der com.ter­mux.shared.ter­mux pack­age and gen­eral classes out­side it. The ter­mux-shared LICENSE must also be checked and up­dated if nec­es­sary when con­tribut­ing code. The li­censes of any ex­ter­nal li­brary or code must be ho­n­oured.

The main Termux con­stants are de­fined by TermuxConstants class. It also con­tains in­for­ma­tion on how to fork Termux or build it with your own pack­age name. Changing the pack­age name will re­quire build­ing the boot­strap zip pack­ages and other pack­ages with the new $PREFIX, check Building Packages for more info.

Check Termux Libraries for how to im­port ter­mux li­braries in plu­gin apps and Forking and Local Development for how to up­date ter­mux li­braries for plu­g­ins.

The ver­sion­Name in build.gra­dle files of Termux and its plu­gin apps must fol­low the se­man­tic ver­sion 2.0.0 spec in the for­mat ma­jor.mi­nor.patch(-pre­re­lease)(+build­meta­data). When bump­ing ver­sion­Name in build.gra­dle files and when cre­at­ing a tag for new re­leases on GitHub, make sure to in­clude the patch num­ber as well, like v0.1.0 in­stead of just v0.1. The build.gra­dle files and at­tach_de­bug_apks_­to_re­lease work­flow val­i­dates the ver­sion as well and the build/​at­tach­ment will fail if ver­sion­Name does not fol­low the spec.

Commit mes­sages must use the Conventional Commits spec so that chagel­ogs as per the Keep a Changelog spec can au­to­mat­i­cally be gen­er­ated by the cre­ate-con­ven­tional-changelog script, check its repo for fur­ther de­tails on the spec. The first let­ter for type and de­scrip­tion must be cap­i­tal and de­scrip­tion should be in the pre­sent tense. The space af­ter the colon : is nec­es­sary. For a break­ing change, add an ex­cla­ma­tion mark ! be­fore the colon :, so that it is high­lighted in the chagelog au­to­mat­i­cally.

Only the types listed be­low must be used ex­actly as they are used in the changelog head­ings. For ex­am­ple, Added: Add foo, Added|Fixed: Add foo and fix bar, Changed!: Change baz as a break­ing change, etc. You can op­tion­ally add a scope as well, like Fixed(terminal): Fix some bug. Do not use any­thing else as type, like add in­stead of Added, etc.

* Changed for changes in ex­ist­ing func­tion­al­ity.

* Check TermuxConstants javadocs for in­struc­tions on what changes to make in the app to change pack­age name.

* You also need to re­com­pile boot­strap zip for the new pack­age name. Check build­ing boot­strap, here and here.

* Currently, not all plu­g­ins use TermuxConstants from ter­mux-shared li­brary and have hard­coded com.ter­mux val­ues and will need to be man­u­ally patched.

* If fork­ing ter­mux plu­g­ins, check Forking and Local Development for info on how to use ter­mux li­braries for plu­g­ins.

Skip to main con­tentA whistle­blower trapped in­side a “pig butcher­ing” scam com­pound gave WIRED a vast trove of its in­ter­nal ma­te­ri­als—in­clud­ing 4,200 pages of mes­sages that lay out its op­er­a­tions in un­prece­dented de­tail. Just be­fore 8am one day last April, an of­fice man­ager who went by the name Amani sent out a mo­ti­va­tional mes­sage to his col­leagues and sub­or­di­nates. “Every day brings a new op­por­tu­nity—a chance to con­nect, to in­spire, and to make a dif­fer­ence,” he wrote in his 500-word post to an of­fice-wide WhatsApp group. “Talk to that next cus­tomer like you’re bring­ing them some­thing valu­able—be­cause you are.”Amani was­n’t ral­ly­ing a typ­i­cal cor­po­rate sales team. He and his un­der­lings worked in­side a “pig butcher­ing” com­pound, a crim­i­nal op­er­a­tion built to carry out scams—promis­ing ro­mance and riches from crypto in­vest­ments—that of­ten de­fraud vic­tims out of hun­dreds of thou­sands or even mil­lions of dol­lars at a time.He Leaked the Secrets of a Southeast Asian Scam Compound. Then He Had to Get Out AliveThe work­ers Amani was ad­dress­ing were eight hours into their 15-hour night shift in a high-rise build­ing in the Golden Triangle spe­cial eco­nomic zone in Northern Laos. Like their marks, most of them were vic­tims, too: forced la­bor­ers trapped in the com­pound, held in debt bondage with no pass­ports. They strug­gled to meet scam rev­enue quo­tas to avoid fines that deep­ened their debt. Anyone who broke rules or at­tempted to es­cape faced far worse con­se­quences: beat­ings, tor­ture, even death.The bizarre re­al­ity of daily life in a Southeast Asian scam com­pound—the tac­tics, the tone, the mix of cru­elty and up­beat cor­po­rate prat­tle—is re­vealed at an un­prece­dented level of res­o­lu­tion in a leak of doc­u­ments to WIRED from a whistle­blower in­side one such sprawl­ing fraud op­er­a­tion. The fa­cil­ity, known as the Boshang com­pound, is one of dozens of scam op­er­a­tions across Southeast Asia that have en­slaved hun­dreds of thou­sands of peo­ple. Often lured from the poor­est re­gions of Asia and Africa with fake job of­fers, these con­scripts have be­come en­gines of the most lu­cra­tive form of cy­ber­crime in the world, co­erced into steal­ing tens of bil­lions of dol­lars.Last June, one of those forced la­bor­ers, an Indian man named Mohammad Muzahir, con­tacted WIRED while he was still cap­tive in­side the scam com­pound that had trapped him. Over the fol­low­ing weeks, Muzahir, who ini­tially iden­ti­fied him­self only as “Red Bull,” shared with WIRED a trove of in­for­ma­tion about the scam op­er­a­tion. His leaks in­cluded in­ter­nal doc­u­ments, scam scripts, train­ing guides, op­er­a­tional flow­charts, and pho­tographs and videos from in­side the com­pound.Of all Muzahir’s leaks, the most re­veal­ing is a col­lec­tion of screen record­ings in which he scrolled through three months’ worth of the com­pound’s in­ter­nal WhatsApp group chats. Those videos, which WIRED con­verted into 4,200 pages of screen­shots, cap­ture hour-by-hour con­ver­sa­tions be­tween the com­pound’s work­ers and their bosses—and the night­mare work­place cul­ture of a pig butcher­ing or­ga­ni­za­tion.“It’s a slave colony that’s try­ing to pre­tend it’s a com­pany,” says Erin West, a for­mer Santa Clara County, California, pros­e­cu­tor who leads an anti-scam or­ga­ni­za­tion called Operation Shamrock and who re­viewed the chat logs ob­tained by WIRED. Another re­searcher who re­viewed the leaked chat logs, Jacob Sims of Harvard University’s Asia Center, also re­marked on their “Orwellian ve­neer of le­git­i­macy.”“It’s ter­ri­fy­ing, be­cause it’s ma­nip­u­la­tion and co­er­cion,” says Sims, who stud­ies Southeast Asian scam com­pounds. “Combining those two things to­gether mo­ti­vates peo­ple the most. And it’s one of the key rea­sons why these com­pounds are so prof­itable.”In an­other chat mes­sage, sent within hours of Amani’s sac­cha­rine pep talk, a higher-level boss weighed in: “Don’t re­sist the com­pa­ny’s rules and reg­u­la­tions,” he wrote. “Otherwise you can’t sur­vive here.” The staffers re­sponded with 26 emoji re­ac­tions, all thumbs-ups and salutes.Scam com­pound whistle­blower Mohammad Muzahir, pho­tographed in India af­ter re­turn­ing home from his or­deal as a forced la­borer in the Golden Triangle.In to­tal, ac­cord­ing to WIRED’s analy­sis of the group chat, more than 30 of the com­pound’s work­ers suc­cess­fully de­frauded at least one vic­tim in the 11 weeks of records avail­able, to­tal­ing to around $2.2 mil­lion in stolen funds. Yet the bosses in the chat fre­quently voiced their dis­ap­point­ment in the group’s per­for­mance, be­rated the staff for lack of ef­fort, and im­posed fine af­ter fine.Rather than ex­plicit im­pris­on­ment, the com­pound re­lied on a sys­tem of in­den­tured servi­tude and debt to con­trol its work­ers. As Muzahir de­scribed it, he was paid a base salary of 3,500 Chinese yuan a month (about $500), which in the­ory en­tailed 75 hours a week of night shifts in­clud­ing breaks to eat. Although his pass­port had been taken from him, he was told that if he could pay off his “contract” with a $5,400 pay­ment, it would be re­turned to him and he would be al­lowed to leave.In re­al­ity, the WhatsApp chats re­veal how even that mea­ger salary was al­most en­tirely chipped away with fines. One mes­sage warns that any­one who fails to start a “first chat”—an in­tro­duc­tory con­ver­sa­tion with a scam vic­tim—on any given day will be fined 50 yuan, and the fail­ure will be an­nounced to the group. Filing a false progress re­port re­sults in a fine of 1,000 yuan. Falling asleep in the of­fice, or “watching un­re­lated video, chat­ting with friends, and any ac­tiv­ity that is not re­lated to the job” are each pun­ish­able with a 200 yuan fine, as is any “disturbance” in the dor­mi­tory, where work­ers sleep five or six to a room in bunk beds.One mes­sage notes a fine of 500 yuan for a worker who slept late, and an­other fined 200 yuan for not be­ing in the dorm at “check-in time” fol­low­ing his shift. Resist a fine by not sign­ing a form that ad­mits to the mis­be­hav­ior, and the fine is dou­bled.An org chart for part of the Boshang scam com­pound, as­sem­bled from leaked mes­sages and Muzahir’s knowl­edge of the op­er­a­tion.Muza­hir him­self de­scribed be­ing fined so much that he was vir­tu­ally broke. The food in the of­fice cafe­te­ria was also fre­quently de­nied as a pun­ish­ment, the mes­sages showed, with work­ers’ ID badges that granted ac­cess to the can­teen some­times be­ing taken away for seven days for small in­frac­tions like tar­di­ness. Even the free­dom to bring in snacks and drinks—other than be­tel nuts, a stim­u­lant—could be re­scinded if staff un­der­per­formed. Time off was also with­held, with staff some­times forced to work seven nights a week, Muzahir says.Yet those pun­ish­ments could be avoided, the bosses fre­quently promised, if they suc­cess­fully scammed some­one—or “opened a cus­tomer,” as the bosses eu­phemisti­cally de­scribed scam­ming a new vic­tim. (Scamming the same vic­tim mul­ti­ple times was called a “recharge.”) In the­ory, work­ers were en­ti­tled to a com­mis­sion, over and above their salary, for any scams they pulled off. Muzahir says he suc­cess­fully per­pe­trated two scams dur­ing his months in the com­pound—both of which left him racked with re­gret, he says—and he was never paid af­ter ei­ther of them.Bosses nonethe­less used work­ers’ il­lu­sory hope of pay­ing off their debt—or even go­ing home rich—as a mo­ti­va­tor. “I un­der­stand—when penal­ties or fines come your way, it’s easy to feel dis­heart­ened. But I urge you not to see it as a pun­ish­ment, but as a les­son and an in­vest­ment in your own growth,” wrote Amani. “Don’t fear the fine. Let it fuel your fire.”The more se­nior boss, who went by the name Da Hai, spelled out the car­rot-and-stick ap­proach more clearly. “The com­pa­ny’s in­cen­tives are much higher than the fines, so as long as you work hard to open new cus­tomers you will re­ceive a gen­er­ous re­ward!” he wrote.One of the boss­es’ tac­tics was to play teams off one an­other, rep­ri­mand­ing un­der­per­form­ing work­ers while point­ing to the suc­cess of other scam­mers in the com­pound. Each room of the of­fice ap­pears to have had a Chinese cer­e­mo­nial drum, played when a worker suc­cess­fully scammed a vic­tim for a six-fig­ure sum. “Do you know why the next of­fice is beat­ing drums?” wrote a higher-level boss called Alang.A vic­tim had paid “480k,” a boss who goes by the name Libo an­swers.“It does­n’t mat­ter, be­cause he be­longs to oth­ers,” Alang re­sponds. “The im­por­tant thing is, which one of you can play the drum?”A Chinese cer­e­mo­nial drum stands in the of­fice, ready to be struck when work­ers pulled off scams of a hun­dred thou­sand dol­lars or more.Be­yond these ma­nip­u­la­tive tac­tics, the mes­sages oc­ca­sion­ally of­fer glimpses of a far harsher re­al­ity—as does the per­sonal ex­pe­ri­ence and tes­ti­mony of Muzahir him­self. Muzahir de­scribes hear­ing sto­ries of peo­ple who were tor­tured and says he was him­self threat­ened by Amani with beat­ing and elec­tro­cu­tion if he did­n’t find new “clients.” Sometimes cowork­ers dis­ap­peared with­out ex­pla­na­tion.Even­tu­ally Muzahir came up with a plan to trick his cap­tors into let­ting him leave. When the bosses caught on, he was held in a room, beaten, slapped and kicked, de­nied food and wa­ter, and made to drink a so­lu­tion with a white pow­der dis­solved in it, which seems to have been in­tended to make him more co­op­er­a­tive with their in­ter­ro­ga­tion.Oc­ca­sional mes­sages in the chat logs hint that these cruel pun­ish­ments lurked un­der­neath the com­pound’s mo­ti­va­tional mes­sages. At one point, the boss Alang men­tions a girl who “sneaked away from the com­pany and went to work in a brothel,” and an­other per­son in the group men­tions that the “company” still holds her pass­port. Among the cap­tive work­ers, Muzahir says, ru­mor had it that the girl was in fact sold into pros­ti­tu­tion, a prac­tice doc­u­mented in other ac­counts from scam com­pound sur­vivors.At an­other point, while chastis­ing the group for un­der­per­for­mance, the boss Da Hai hints at the large sum of money work­ers needed to pro­duce if they ever hoped to leave the com­pound. “You con­tinue to vi­o­late the com­pa­ny’s reg­u­la­tions,” he writes to the group. “If you con­tinue like this, please pre­pare your com­pen­sa­tion and get out of here.”Such ref­er­ences to pay­ing “compensation” for re­lease are in fact “coded words for ran­som and debt bondage,” says Harvard’s Sims. The na­tion of Laos, Sims points out, is a sig­na­tory to the Palermo Protocol, which clas­si­fies any­one held in debt and forced to work with­out free­dom of move­ment a vic­tim of hu­man traf­fick­ing. “There is no gray area here.”A Day in the Life of a ScammerThe leaked WhatsApp chats in­clude a mes­sage from a boss who went by the name Terry lay­ing out a strict work sched­ule for those un­der his su­per­vi­sion. “Obey and re­spect the work­ing time,” the mes­sage says. Each shift would start at around 11:30 pm Beijing time—10:30 pm in Laos—with peo­ple told to ar­rive a few min­utes early. Before the day ended at 2 pm Beijing time, there would be two break pe­ri­ods, one of which was set aside for meals. By 5 pm every­one was re­quired to be back in their dor­mi­to­ries and “sleep or keep si­lence, no dis­turb­ing the oth­ers.” If the rules weren’t fol­lowed, fines would be is­sued and ID badges could be taken away.The rea­son for this noc­tur­nal sched­ule was to sync with the wak­ing hours of vic­tims in the US—almost en­tirely Indian-American men. (It’s a com­mon prac­tice to pair scam­mers with vic­tims of their own eth­nic­ity, to avoid lan­guage and cul­ture bar­ri­ers.)In grim con­trast to their ac­tual lives, all staffers were re­quired to post an imag­i­nary daily sched­ule for their fake per­sonas—the wealthy, at­trac­tive women they’d pre­tend to be dur­ing scams. In hour-by-hour break­downs, they de­scribe morn­ings spent med­i­tat­ing, prac­tic­ing yoga, tak­ing walks, and “setting pos­i­tive in­ten­tions” for the day. Other ac­tiv­i­ties in­clude a “relaxed” lunch with their team, din­ner with loved ones, and time at the gym—when in re­al­ity they were spend­ing en­tire nights in front of a screen in a flu­o­res­cent-lit of­fice space.Many of the staffers writ­ing the sched­ules were nonethe­less ad­mon­ished for not stick­ing to the script while scam­ming. “The pur­pose of edit­ing a daily plan is to let every­one know clearly what you are go­ing to share with your clients to­day when you start work­ing,” one boss com­plained. “I find that many peo­ple just do it to get the job done and don’t ap­ply your plan to your clients.”An ex­am­ple of the sched­ules work­ers were re­quired to post daily—not for them­selves, but for the wealthy fe­male per­sonas they adopted in their chats with vic­tims.The an­nounce­ment of a suc­cess­ful scam posted to the com­pound’s WhatsApp group. This one cel­e­brates a $338,000 theft.Dur­ing each day’s work, the forced scam­mers were also re­quired—un­der the threat of more fines—to re­port their scam­ming ef­forts back to the bosses in de­tail. The WhatsApp logs are filled with lengthy mes­sages from every team mem­ber that of­fer those re­ports in iden­ti­cal mes­sage tem­plates, list­ing their “team,” their name, and their re­cent on­line ac­tiv­ity with the fake pro­files. They would re­port how many ac­tive so­cial me­dia ac­counts they were op­er­at­ing, if any of their ac­counts were sus­pended, how many chats they’d started, how many were on­go­ing, any suc­cess­ful scams, and their tar­get for the month. The in­ter­nal chats also show scam­mers shar­ing with bosses and col­leagues screen­shots of their vic­tim chats on Facebook Messenger, Instagram, Snapchat, and other chat apps, while ask­ing ques­tions about po­ten­tial vic­tims.Bosses fre­quently gave pointed feed­back about how work­ers were man­ag­ing the meta-nar­ra­tive of their scams. “When shar­ing travel top­ics, you need to know how to share de­tails,” one chat says. Another mes­sage from a boss ad­mon­ishes work­ers not to men­tion the car their per­sona dri­ves if they can’t pro­vide a con­vinc­ing photo of it.Man­agers would keep a close eye on the ac­tiv­ity. On mul­ti­ple oc­ca­sions, bosses ask the forced work­ers to con­nect their WhatsApp ac­counts to the man­agers’ com­put­ers so they could mon­i­tor the con­ver­sa­tions them­selves.The 25 scripts and guides Muzahir shared with WIRED, too, of­fer a win­dow into the tac­tics and train­ing of the com­pound’s work­ers. Many of the guid­ance doc­u­ments per­tain to the nitty gritty of car­ry­ing out cryp­tocur­rency in­vest­ment scams, in­clud­ing how to build a friend­ship that can segue into an in­vest­ment propo­si­tion, how to ex­plain what cryp­tocur­rency is, and what to do once a tar­get agrees to make an in­vest­ment.One doc­u­ment lists “100 chat top­ics,” geared to­ward build­ing the emo­tional in­ti­macy re­quired for a ro­mance scam (“What was your dream when you were lit­tle?” “What was the last time I cried for?”). Another sug­gests pro­vid­ing an up­date about hav­ing got­ten into a car ac­ci­dent. “On my way to work in the morn­ing, my car was hit by a car fol­low­ing at a traf­fic light, which al­most de­layed my meet­ing in the morn­ing. Thank you for your con­cern. I am fine.”Mul­ti­ple doc­u­ments guide scam­mers to pre­tend they are cur­rently mak­ing an in­vest­ment, then in­tro­duce the idea that banks are re­sis­tant to let­ting their cus­tomers con­vert their money into cryp­tocur­rency. “If we trans­fer or with­draw funds, they will have one less cus­tomer,” one pro­posed scam script says. “If every­one does this, then the bank will be in cri­sis and there will be a sit­u­a­tion of cap­i­tal rup­ture. I can un­der­stand their mo­tives, but as a bank cus­tomer, I should not be hin­dered from trans­fer­ring as­sets rea­son­ably and legally. This is what makes me an­gry.”The doc­u­ments also dis­play a tech­nique that re­searchers say is of­ten used in Southeast Asian in­vest­ment and ro­mance scams: Attackers in­ten­tion­ally men­tion the con­cept of scams—even di­rectly talk­ing about the threat of in­vest­ment scams—as a way of in­oc­u­lat­ing them­selves against sus­pi­cion. The idea is that if a per­son is will­ing to talk openly about scams and is­n’t avoid­ing the sub­ject or act­ing strange about it, then they could­n’t be a scam­mer them­self.A flow chart of the com­pound’s op­er­a­tions that Muzahir cre­ated and shared with WIRED in his first con­ver­sa­tion with a re­porter.That strat­egy goes so far as to in­clude men­tally prepar­ing a vic­tim for the anti-fraud warn­ings from their bank or even law en­force­ment that they may have to ig­nore in or­der to trans­fer large amounts of fiat cur­rency into cryp­tocur­rency. “I was go­ing to trans­fer funds to my coin­base to­day, but I was de­lib­er­ately de­layed and ob­structed by the bank staff,” one script reads, re­fer­ring to the pop­u­lar crypto wal­let ser­vice Coinbase. “I also re­ceived an anti-fraud call from the FBI to­day, which wasted a lot of my time.”The ma­te­ri­als Muzahir pro­vided from the Boshang com­pound also doc­u­ment the key role gen­er­a­tive AI tools play in its de­cep­tions. Muzahir de­scribed to WIRED how the com­pound work­ers are trained in us­ing tools like ChatGPT and Deepseek to come up with re­sponses in chats with vic­tims and craft nat­ural-sound­ing turns of phrase. But even more cru­cial was the com­pound’s use of deep­fake AI soft­ware to al­low scam­mers to con­vinc­ingly video chat with vic­tims at their re­quest us­ing an AI-generated face, im­per­son­at­ing an in­di­vid­ual whose pho­tos they’ve stolen for a fake per­sona.The in­ter­nal chat logs Muzahir cap­tured de­scribe a ded­i­cated “AI room” where a fe­male model con­ducts face-swapped calls on re­quest with an end­less pa­rade of vic­tims. One WhatsApp mes­sage from a boss to the group chat notes that “Sana (our model who helps us to call) is not avail­able tonight. she is not feel­ing well. Therefore, don’t promise your cus­tomers to call them. Maybe she will come at work in the morn­ing. Plan your work ac­cordin[g]ly.”Other chats about the AI room re­late to sched­ul­ing chal­lenges given de­mand for face-swapped calls and the fact that a sin­gle model can only do one deep­fake call at a time. One chat, for ex­am­ple, notes: “If there is a ‘busy’ sign on her door, change it to ‘free’ when you come out, so as to avoid crowd­ing and fre­quent door open­ings.”The scripts Muzahir shared also in­clude tips for de­lay­ing a video chat with a vic­tim—per­haps un­til the scam­mer is pre­pared to use deep­fake tools. “When we meet, it will not be awk­ward but rather we will look for­ward to it,” says one script about what to say when a vic­tim asks to video chat. It con­tin­ues, “We are strength­en­ing our re­la­tion­ship every day. You have also seen my pho­tos. When we meet, can you rec­og­nize me?”As dystopian as the Golden Triangle com­pound de­scribed in the leaked doc­u­ments may be, its work en­vi­ron­ment ap­pears to have been rel­a­tively lax com­pared to other com­pounds in coun­tries like Cambodia or Myanmar. In those fa­cil­i­ties, Operation Shamrock’s Erin West says, she has heard first­hand sto­ries of work­ers be­ing beaten sim­ply for miss­ing their quota of scams or be­ing forced to work 18-hour shifts while stand­ing, with none of the pre­tense of vol­un­tary work in a cor­po­rate en­vi­ron­ment.The rel­a­tive le­niency of Muzahir’s com­pound, says Harvard’s Sims, likely stems from scam op­er­a­tions’ sense of to­tal con­trol in Laos’ Golden Triangle re­gion—a zone of the coun­try con­trolled largely by Chinese busi­ness in­ter­ests that has be­come a host to crimes rang­ing from nar­cotics and or­gan sales to il­le­gal wildlife traf­fick­ing. Even hu­man traf­fick­ing vic­tims who es­cape from a com­pound there, Sims points out, can be tracked down rel­a­tively eas­ily thanks to Chinese or­ga­nized crime’s in­flu­ence over lo­cal law en­force­ment. “These guys don’t have to be held in a cell,” Sims says. “The whole place is a closed cir­cuit.”Nonethe­less, the Boshang com­pound that held Muzahir ap­pears to have moved in November from the Golden Triangle to Cambodia, a coun­try that’s be­come by some mea­sures an even safer base for scam­mers to op­er­ate from. Based on mes­sages from his for­mer cowork­ers, Muzahir says he’s de­ter­mined that the op­er­a­tion and its cap­tive work­ers are now based in the town of Chrey Thom, what Sims and West both de­scribe as a grow­ing hot spot for scam op­er­a­tions.The move may have been pre­cip­i­tated, Sims spec­u­lates, by po­lice raids on com­pounds across the re­gion around that time. Many of those raids ap­pear to have been part of a “performative crack­down,” as Sims puts it. (One such raid in June tar­geted the build­ing where Muzahir’s com­pound had pre­vi­ously been lo­cated, but Muzahir says the work­ers who were rounded up by po­lice were quickly re­leased again and re­turned to work.)Nonethe­less, the nui­sance of even those su­per­fi­cial dis­rup­tions may have per­suaded the op­er­a­tion’s bosses to re­lo­cate to Cambodia. In that coun­try, even the fam­ily of the coun­try’s prime min­is­ter, Hun Manet, has been linked to a cor­po­rate con­glom­er­ate that over­sees a sub­sidiary with doc­u­mented ties to the bur­geon­ing scam in­dus­try. “It’s been a very hos­pitable en­vi­ron­ment to do this work,” West says.One of Muzahir’s old bosses also con­firmed to him in a pri­vate text ex­change that the com­pound is still “recruiting” new work­ers—vic­tims trapped in a sys­tem of mod­ern slav­ery hid­den un­der a thin fa­cade of a will­ing work­place.“This is a place to work, not to en­joy,” that same boss had writ­ten in the group chat dur­ing Muzahir’s time in the com­pound, in a rare mo­ment when the mask of a nor­mal of­fice en­vi­ron­ment seemed to slip. “You can only en­joy life when you leave here.”Let us know what you think about this ar­ti­cle. Submit a let­ter to the ed­i­tor at mail@wired.com.

So… Here we are again.

Today, af­ter a mi­nor dis­as­ter with my Obsidian vault, I de­cided to re­store from Time Machine, and… I re­al­ized that it had silently bro­ken across both my Tahoe ma­chines. I use a Synology NAS as Time Machine tar­get, ex­port­ing the share over SMB and that has worked flaw­lessly for years, but this came as a sur­prise be­cause I could have sworn it was work­ing fine a cou­ple of months ago–but no, it was­n’t.

For clar­ity: It just stopped do­ing back­ups, silently. No er­ror mes­sages, no no­ti­fi­ca­tions, noth­ing. Just no back­ups for around two months. On my lap­top, I only no­ticed be­cause I was try­ing to re­store a file and the lat­est backup was from December. On my desk­top, I had a Thunderbolt ex­ter­nal drive as a sec­ondary backup.

After some re­search, I found out that the is­sue is with Apple’s uni­lat­eral de­ci­sion to change their SMB de­faults (without ap­par­ently no­ti­fy­ing any­one), and came across a few pos­si­ble fixes.

What Seems To Be Working Now

I found this gist, which I am re­pro­duc­ing here for pos­ter­ity, that seems to be work­ing for me, but which en­tails edit­ing the nsmb.conf file on the Mac it­self–which is not ex­actly ideal, since I’m pretty sure Apple will break this again in the fu­ture.

…and adding the fol­low­ing lines (the file should be empty):

The ex­pla­na­tion here is that ma­cOS Tahoe changed the de­fault from sign­ing_re­quired=no to stricter con­trol, and NAS de­vices with re­laxed SMB set­tings can­not han­dle this with­out ex­plicit con­fig­u­ra­tion.

Another com­mon pit­fall is name en­cod­ing is­sues in ma­chine names, so you should re­move Non-ASCII Characters from the .sparsebundle name (that was­n’t an is­sue for me, but YMMV).

On the Synology side, the rec­om­men­da­tion was to go to Control Panel > File Services > SMB > Advanced and set:

That does­n’t quite match my DSM UI, but it’s close enough, and my set­tings now look like this:

My SMB set­tings, as of DSM 7.3.2-86009-1

Since I’m tired of Apple break­ing Time Machine every few years and the lack of trans­parency around this (it’s not Synology’s fault), I have de­cided to im­ple­ment a more ro­bust so­lu­tion that does­n’t de­pend on Synology’s SMB im­ple­men­ta­tion.

I al­ready have a Proxmox server with ZFS as the back­end stor­age that has an LXC con­tainer run­ning Samba for gen­eral file shar­ing, so I de­cided to look into that as a pos­si­ble Time Machine tar­get.

As it hap­pens, mbent­ley/​timema­chine is a Docker im­age specif­i­cally de­signed for this pur­pose, and it seems to be well-main­tained, so I’m test­ing it like this:

Right now the first op­tion seems to be work­ing, but I will prob­a­bly switch to the Docker so­lu­tion in the near fu­ture, since it gives me more con­trol over the SMB im­ple­men­ta­tion and avoids re­ly­ing on Synology’s soft­ware.

But if any­one from Apple is read­ing this: please, stop break­ing Time Machine every few years. It’s a crit­i­cal piece of in­fra­struc­ture for many users, and the lack of com­mu­ni­ca­tion around these changes is frus­trat­ing.

The Third Way: Borg Backup

I have been us­ing Borg for some time now on Fedora, and I am con­sid­er­ing us­ing it for my Macs as well. Vorta seems de­cent, I just haven’t tried it yet.

Plus I’m an­noyed enough that ear­lier this morn­ing I tried to set up a new iOS de­vice and the in­fa­mous Restore in Progress: An es­ti­mated 100 MB will be down­loaded… bug (which has bit­ten me re­peat­edly over the last six years) is still there.

The usual fix was hit­ting Reset Network Settings and a full hard­ware re­boot, plus re­con­nect­ing to Wi-Fi… But this time it took three at­tempts.

Come on, Apple, get your act to­gether. Hire peo­ple who care about the OS ex­pe­ri­ence, not just Liquid Glass.