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.

Log in to Our Site

Please log in (using your fo­rums ac­count) to make the most

of our site, or reg­is­ter here.

Learn More

Adventure Game Studio (AGS) is open-source soft­ware for cre­at­ing graph­i­cal point-and-click ad­ven­ture games. It is free, stand­alone, and re­quires no sub­scrip­tion.

The Windows-based IDE, stream­lines game cre­ation by in­te­grat­ing tools for im­port­ing graph­ics, writ­ing scripts, and test­ing. Games cre­ated with AGS can be played on mul­ti­ple plat­forms, in­clud­ing Linux, iOS, and Android.

Suitable for all skill lev­els, AGS fea­tures an ac­tive com­mu­nity for sup­port and so­cial­is­ing.

Showcase your games by up­load­ing them to this web­site.

Rot your brain by con­sum­ing AI slop and ser­vices in this clas­sic ar­cade style game cre­ated for the MAGS January 2026 game jam in the AGS fo­rums. Move […]

You awaken alone on a cold, rocky shore be­neath a moon­less sky, dragged from the sea through a sewer pipe with no mem­ory of who you are, how you […]

Get in, get the loot, get out… that’s how it usu­ally goes for mas­ter cat bur­glar Trilby. But af­ter he breaks into the sup­pos­edly va­cated coun­try […]

A mad­ness for spir­i­tu­al­ism has gripped London in 1907. Séances and the­atri­cal shows where spir­its make con­tact with their liv­ing fam­i­lies are all […]

Rot your brain by con­sum­ing AI slop and ser­vices in this clas­sic ar­cade style game cre­ated for the MAGS January 2026 game jam in the AGS fo­rums.Move […]

You awaken alone on a cold, rocky shore be­neath a moon­less sky, dragged from the sea through a sewer pipe with no mem­ory of who you are, how you […]

Get in, get the loot, get out… that’s how it usu­ally goes for mas­ter cat bur­glar Trilby. But af­ter he breaks into the sup­pos­edly va­cated coun­try […]

A mad­ness for spir­i­tu­al­ism has gripped London in 1907. Séances and the­atri­cal shows where spir­its make con­tact with their liv­ing fam­i­lies are all […]

The lat­est from our fo­rums

In: The Rumpus Room

By: Khris (2 hours ago)

In: Critics’ Lounge

By: Nine Toes (3 hours ago)

AGS has an ac­tive and friendly com­mu­nity, with many ways of keep­ing in touch and get­ting help with your pro­ject or games made with AGS.

These in­clude our lo­cal fo­rums, Facebook page, Discord server, in-per­son meet-ups, and many more.

The AGS com­mu­nity is run by a team of ded­i­cated vol­un­teers, who put their time and ef­forts into keep­ing it run­ning as a wel­com­ing, friendly and in­for­ma­tive place to be. The AGS server and fo­rums are paid for out of our own pock­ets, so in ef­fect it costs us money to pro­vide a free ser­vice to AGS users.

If you ap­pre­ci­ate the work we do, and would like to give a lit­tle some­thing back, please use the be­low link to do­nate via PayPal. Any profit made af­ter cov­er­ing server costs will be put back into host­ing com­mu­nity events such as Mittens.

By con­tin­u­ing to use this site you agree to the use of

cook­ies .

Please visit this page to see ex­actly how we use these.

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.

The

Apple Computer. A truly com­plete mi­cro­com­puter sys­tem on a sin­gle

PC board. Based on the MOS Technology 6502 mi­cro- proces­sor,

the Apple also has a built-in video ter­mi­nal and sock­ets for

8K bytes of on­board RAM mem­ory. With the ad­di­tion of a key­board

and video mon­i­tor, you’ll have an ex­tremely pow­er­ful com­puter

sys­tem that can be used for any­thing from de­vel­op­ing pro­grams

to play­ing games or run­ning BASIC.

Combining the com­puter, video ter­mi­nal and

dy­namic mem­ory on a sin­gle board has re­sulted in a large re­duc­tion

in chip count, which means more re­li­a­bil­ity and low­ered cost.

Since the Apple comes fully as­sem­bled, tested & burned-in

and has a com­plete power sup­ply on-board, ini­tial set-up is

es­sen­tially “hassle-free” and you can be run­ning within

min­utes. At $666.66 (including 4K bytes RAM!) it opens many

new pos­si­bil­i­ties for users and sys­tems man­u­fac­tur­ers.

You Don’t Need an Expensive Teletype.

Using the built-in video ter­mi­nal

and key­board in­ter­face, you avoid all the ex­pense, noise and

man­te­nance as­so­ci­ated with a tele­type. And the Apple video ter­mi­nal

is six times faster than a tele­type, which means more through­put

and less wait­ing. The Apple con­nects di­rectly to a video mon­i­tor

(or home TV with an in- ex­pen­sive RF mod­u­la­tor) and dis- plays

960 easy to read char­ac­ters in 24 rows of 40 char­ac­ters per

line with au­to­matic scrolling. The video dis­play sec­tion con­tains

its own 1K bytes of mem­ory, so all the RAM mem­ory is avail­able

for user pro­grams. And the

Keyboard Interface lets you use al­most

any ASCII-encoded key­board.

The Apple Computer makes it pos­si­ble for many

peo­ple with lim­ited bud­gets to step up to a video ter­mi­nal as

an I/O de­vice for their com­puter.

No More Switches,

No MoreLights

Compared

to switches and LED’s, a video ter­mi­nal can dis- play vast amounts

of in­for­ma­tion si­mul­ta­ne­ously. The Apple video ter­mi­nal can

dis­play the con­tents of 192 mem­ory lo­ca­tions at once on the

screen. And the fim­r­ware in PROMS en­ables you to en­ter,dis­play

and de­bug pro­grams (all in hex) from the key­board, ren- de­r­ing

a front panel un­nec­es­sary. The firmware also al­lows your pro­grams

to print char­ac­ters on the dis­play, and since you’ll be look­ing

at let­ters and num­bers in­stead of just LED’s, the door is open

to all kinds of al­phanu­meric soft­ware (i.e., Games and BASIC).

8K Bytes RAM in 16 Chips!

The Apple Computer uses the new 16-pin 4K dy­namic mem­ory chips.

They are faster and take 1/4 the space and power of even the

low power 2102′s (the mem­ory chip that every­one else uses).

That means 8K bytes in six­teen chips. It also means no more

28 amp power sup­plies.    The sys­tem is fully

ex­pand­able to 65K via an edge con­nec­tor which car­ries both the

ad­dress and data busses, power sup­plies and all tim­ing sig­nals.

All dy- namic mem­ory re­fresh­ing for both on and off-board mem­ory

is done au­to­mat­i­cally. Also, the Apple Computer can be up­graded

to use the 16K chips when they be­come availa-

ble. That’s 32K bytes on-board RAM in

16 IC’s –the equiv­a­lent of 256 2102′s!

A lit­tle Cassette Board that

Works!

Unlike many other cas­sette

boards on the mar­ket­place,ours works every timeIt plugs di­rectly

into the up­right con­nec­tor on the main­board and stands only

2″ tall. And since it is very fast (1500 bits per sec­ond),

you can read or write 4 K bytes in about 20 sec­onds.All tim­ing

is done in soft­ware, witch re­sults in crys­tal-con­trolled ac­cu­racy

and uni­for­mity from unit to unit.

un­like some other cas­sette in­ter­faces witch re­quires an ex­pen­sive

tape recorder, the Apple Cassette Interface works re­li­ably with

al­most any au­dio-grade cas­sette recorder.

Softwares

A tape of APPLE BASIC

is in­clued free with the Cassette Interface.Apple Basic fea­tures

im­me­di­ate er­ror mes­sage and fast ex­e­cu­tion, and let’s you pro­gram

in a high­ter level lan­guage im­me­di­ately and with­out added cost.Also

avial­able now are a dis-as­sem­bler and many games, with many

soft­ware pack­ages,(in­clud­ing a macro as­sem­bler) in the works.And

since our phi­los­o­phy is to pro­vide soft­ware for our ma­chines

free or at min­i­mal cost, you won’t be con­tin­u­ally pay­ing for

ac­cess to this grow­ing soft­ware li­brary.

The Apple Computer is in stock al al­most all ma­jor com­puter

stores.(if your lo­cal com­puter store does­n’t carry our prod­ucts,

en­cour­age them or write us di­rect).Dealer in­quiries in­vited.

FOSDEM, the Free and Open Source Developers’ European Meeting, is an an­nual pil­grim­age for open source en­thu­si­asts from all over the world. What started as a small gath­er­ing in 2000, orig­i­nally named the Open Source Developers of Europe Meeting (OSDEM), has grown into one of the most sig­nif­i­cant con­fer­ences ded­i­cated to free and open source soft­ware.

In 2026, FOSDEM felt more pur­pose­ful than ever. The con­fer­ence clearly re­flected a grow­ing aware­ness around dig­i­tal sov­er­eignty and Europe’s tech­no­log­i­cal fu­ture.

Self hosted so­lu­tions, open in­fra­struc­ture, and com­mu­nity dri­ven soft­ware were no longer niche top­ics. They were cen­tral to many dis­cus­sions and pre­sen­ta­tions. The fo­cus has vis­i­bly shifted away from con­ve­nience first and cen­tral­ized plat­forms and to­ward sys­tems that put con­trol, trans­parency, and re­silience back into the hands of users and com­mu­ni­ties. This shift was ily sup­ported by es­tab­lished com­mu­ni­ties such as the FreeBSD pro­ject, which con­tin­ues to demon­strate how long term, openly gov­erned sys­tems can serve as re­li­able foun­da­tions for sov­er­eign in­fra­struc­ture. At the same time, smaller but equally im­por­tant pro­jects showed how grass­roots in­no­va­tion dri­ves real change. Talks like Hyacinthe’s FlipFlap pre­sen­ta­tion on the DN42 net­work high­lighted de­cen­tral­ized and com­mu­nity op­er­ated net­work­ing in prac­tice, while Emile’s talk on SmolBSD demon­strated how min­i­mal, pur­pose built BSD sys­tems can bring clar­ity, au­ditabil­ity, and long term main­tain­abil­ity back to op­er­at­ing sys­tem de­sign. Projects such as BoxyBSD, crafted by gyptazy, show­cased how low­er­ing the bar­rier to learn­ing BSD based sys­tems em­pow­ers the next gen­er­a­tion of open source con­trib­u­tors. By pro­vid­ing free in­vite codes dur­ing FOSDEM, BoxyBSD made hands on ex­per­i­men­ta­tion im­me­di­ately ac­ces­si­ble and re­in­forced the con­fer­ence’s spirit of open­ness and com­mu­nity sup­port.

FOSDEM 2026 made one thing un­mis­tak­ably clear. Open source is no longer just about soft­ware free­dom. It is in­creas­ingly about in­de­pen­dence, sus­tain­abil­ity, and Europe’s abil­ity to shape its own dig­i­tal fu­ture.

Like every year, I de­cided to travel to FOSDEM by car. It’s ac­tu­ally the most re­laxed way for me to get there as I can sim­ply drive at any time in the morn­ing, but it comes with one clear dis­ad­van­tage: you have to ar­rive very early to se­cure a park­ing spot di­rectly on cam­pus. That means start­ing the jour­ney long be­fore the city fully wakes up. Overall, the travel time is more or less the same as tak­ing the train, so that part does­n’t re­ally mat­ter. What does mat­ter is the flex­i­bil­ity and be­ing able to move around freely and head back home when­ever I want. Since I usu­ally only at­tend the first day of FOSDEM, that flex­i­bil­ity makes the early start worth it.

This year, the ef­fort paid off once again. I ended up be­ing the first car in line at the gate lead­ing to the park­ing area. Better safe than sorry. Anyone who has at­tended FOSDEM knows that park­ing nearby is a small vic­tory that can shape the rest of the day.

After park­ing, there was time to slow down a bit. Before the talks be­gan, the cam­pus grad­u­ally filled with fa­mil­iar faces. FOSDEM has a unique rhythm in the early morn­ing hours, when every­thing is still calm and con­ver­sa­tions hap­pen with­out rush­ing from room to room.

I met up with a few friends, and we took the op­por­tu­nity to catch up and ex­change a few thoughts be­fore the day prop­erly started. With cof­fees and crois­sants in hand, we waited for the open­ing talk. It was a sim­ple mo­ment, but one that per­fectly cap­tured the at­mos­phere of FOSDEM: a mix of an­tic­i­pa­tion, com­mu­nity, and shared cu­rios­ity about what the week­end would bring.

My per­sonal sched­ule at FOSDEM fol­lowed a clear thread: un­der­stand­ing in­fra­struc­ture from the low­est lay­ers up to real-world, com­mu­nity op­er­ated sys­tems. Rather than chas­ing trends, I fo­cused on talks that ex­plored con­trol, re­li­a­bil­ity, and long term sus­tain­abil­ity.

The Rust-VMM talk set the tone by div­ing into mod­ern vir­tu­al­iza­tion foun­da­tions built with mem­ory safety in mind. It high­lighted how Rust en­ables a new gen­er­a­tion of vir­tual ma­chine mon­i­tors that re­duce en­tire classes of bugs while still meet­ing strict per­for­mance re­quire­ments. For any­one work­ing close to hard­ware or hy­per­vi­sors, it was a i ar­gu­ment for re­think­ing tra­di­tional sys­tems pro­gram­ming choices.

With Garage S3 Best Practices, the fo­cus shifted from de­sign to day-to-day op­er­a­tions. Object stor­age is of­ten treated as a com­mod­ity, yet the talk made it clear how many sub­tle chal­lenges ex­ist around con­sis­tency, fail­ure han­dling, and scal­ing. Real op­er­a­tional lessons and prac­ti­cal ad­vice em­pha­sized that run­ning stor­age re­li­ably is just as im­por­tant as build­ing it.

The talk on Mobility of Virtual Machines in Kubernetes Clusters ex­plored the in­creas­ingly blurred line be­tween clas­si­cal vir­tu­al­iza­tion and con­tainer or­ches­tra­tion. It showed how vir­tual ma­chines can move and adapt within Kubernetes en­vi­ron­ments, com­bin­ing the i iso­la­tion of VMs with the flex­i­bil­ity of cloud na­tive tool­ing. This hy­brid ap­proach chal­lenges the idea that plat­forms must choose one model ex­clu­sively.

SmolBSD brought a re­fresh­ing fo­cus on min­i­mal­ism. Instead of adding more lay­ers, the pro­ject em­braces small, un­der­stand­able sys­tems that are eas­ier to au­dit and main­tain over time. The talk re­in­forced the idea that sim­plic­ity is not a lim­i­ta­tion but a strate­gic choice, es­pe­cially for long lived in­fra­struc­ture.

Finally, FlipFlap Network in DN42 con­nected many of the ear­lier themes through a com­mu­nity per­spec­tive. DN42 demon­strates how de­cen­tral­ized, self op­er­ated net­work­ing can work in prac­tice. The talk show­cased au­toma­tion, ex­per­i­men­ta­tion, and co­op­er­a­tion in a real net­work built by its users, high­light­ing the ed­u­ca­tional and in­no­v­a­tive power of grass­roots in­fra­struc­ture.

Together, these talks formed a co­her­ent jour­ney through mod­ern open in­fra­struc­ture: from safe low level build­ing blocks to re­silient stor­age, hy­brid or­ches­tra­tion mod­els, min­i­mal op­er­at­ing sys­tems, and com­mu­nity dri­ven net­works.

One of my per­sonal high­lights of FOSDEM 2026 was a won­der­fully sim­ple yet bril­liant idea by the Mozilla Foundation: giv­ing away free cook­ies. It turned out to be more than just snacks. It was a fun lit­tle game, a great con­ver­sa­tion starter, and the se­lec­tion of cook­ies was gen­uinely ex­cel­lent. You might have come for open source, but you prob­a­bly left lik­ing cook­ies even more than be­fore.

Another stand­out mo­ment was the talk The Challenges of FLOSS Office Suites by Michael Meeks, where he dove into the tech­ni­cal de­tails be­hind Collabora Online. It was an ab­solute plea­sure to lis­ten to. What made the talk spe­cial was not only the depth of tech­ni­cal in­sight, but also the way it was pre­sented. Complex top­ics were ex­plained clearly, with con­text and hu­mor, mak­ing it ac­ces­si­ble with­out over­sim­pli­fy­ing.

I was gen­uinely amazed by how the chal­lenges of build­ing and main­tain­ing a full-fea­tured, open source of­fice suite were laid out so hon­estly. The talk went far be­yond ar­chi­tec­ture di­a­grams and per­for­mance con­sid­er­a­tions and gave real in­sight into the long-term ef­fort re­quired to keep such crit­i­cal soft­ware alive and com­pet­i­tive.

Beyond the talks, I also took the op­por­tu­nity to have some great con­ver­sa­tions at the booths. I chat­ted with fixoulab at the Proxmox booth and with the XCP-ng team at Vates, where I got an early look at the newly re­leased Orchestra fea­tures. It was es­pe­cially in­ter­est­ing since I had not yet found the time to dive into them in de­tail.

On a more per­sonal note, I was truly grate­ful to meet many of my friends from dif­fer­ent coun­tries again. Being able to jump into great talks to­gether, ex­change im­pres­sions on the spot, and con­tinue dis­cus­sions af­ter­wards is some­thing that makes FOSDEM spe­cial in a way no record­ing or live stream ever could.

FOSDEM has al­ways been crowded. Anyone who has at­tended more than once knows the fa­mil­iar ex­pe­ri­ence of packed hall­ways, full lec­ture rooms, and sprint­ing be­tween build­ings in the hope of catch­ing the last five min­utes of a talk. As the biggest open source con­fer­ence in the world, this has long been part of its iden­tity. But in 2026, it felt like some­thing had shifted.

There is no doubt that the grow­ing in­ter­est in free and open source soft­ware is a good thing. More peo­ple take open source se­ri­ously, more or­ga­ni­za­tions de­pend on it, and more con­trib­u­tors want to get in­volved. That en­ergy was clearly vis­i­ble every­where. At the same time, it felt like FOSDEM was reach­ing — or per­haps ex­ceed­ing — its nat­ural lim­its. Rooms filled faster than ever, in­for­mal dis­cus­sions be­came harder to have, and the sheer den­sity of peo­ple some­times worked against the very open­ness the con­fer­ence is known for.

A ma­jor dri­ver be­hind this growth is the cur­rent po­lit­i­cal and eco­nomic cli­mate. Topics like dig­i­tal sov­er­eignty, tech­no­log­i­cal in­de­pen­dence, and re­duc­ing re­liance on a small num­ber of dom­i­nant mar­ket play­ers were more pre­sent than ever. This was not sub­tle. It was vis­i­ble across the sched­ule, in hall­way con­ver­sa­tions, and es­pe­cially dur­ing the Friday pre-con­fer­ences, where these themes were ac­tively pur­sued and de­bated.

On one hand, this fo­cus is both nec­es­sary and over­due. Open source has al­ways been po­lit­i­cal in the sense that it is about con­trol, trans­parency, and au­ton­omy, even when it pre­tended not to be. Seeing these dis­cus­sions move to the cen­ter stage at FOSDEM is en­cour­ag­ing. It shows that the com­mu­nity un­der­stands the stakes and is will­ing to en­gage with the broader im­pli­ca­tions of the tech­nol­ogy it builds.

On the other hand, the in­ten­sity of this shift raises un­com­fort­able ques­tions. When every­thing be­comes ur­gent and strate­gic, the space for ex­per­i­men­ta­tion, learn­ing, and smaller niche pro­jects risks be­ing squeezed out. Not every open source pro­ject ex­ists to solve geopo­lit­i­cal prob­lems, and not every con­trib­u­tor ar­rives with a pol­icy agenda. FOSDEM has al­ways thrived on its di­ver­sity of mo­ti­va­tions, and main­tain­ing that bal­ance will be in­creas­ingly chal­leng­ing.

FOSDEM 2026 felt like a con­fer­ence at a cross­roads. Its suc­cess is un­de­ni­able, but so are the grow­ing pains that come with it. The chal­lenge for the com­ing years will be find­ing ways to scale with­out los­ing what made the event spe­cial in the first place: ac­ces­si­bil­ity, spon­tane­ity, and the feel­ing that there is room for every­one and not just for the loud­est or most timely top­ics. And while I al­ready crit­i­cized this last year, this be­comes even more im­por­tant this year.

The con­ver­sa­tions hap­pen­ing now are im­por­tant, and it is good that they are hap­pen­ing at FOSDEM. But if the con­fer­ence is to re­main sus­tain­able, both lo­gis­ti­cally and cul­tur­ally, it will need to evolve just as thought­fully as the open source ecosys­tem it rep­re­sents.

It is gen­uinely great to see that FOSDEM re­mains free and open to every­one, even as the top­ics it cov­ers be­come more com­plex and more rel­e­vant. The grow­ing fo­cus on mov­ing away from big tech and re­claim­ing own­er­ship of our data shows that the com­mu­nity is pay­ing at­ten­tion to what truly mat­ters. These dis­cus­sions are nec­es­sary, and it is en­cour­ag­ing to see them re­flected so clearly in the talks and hall­way con­ver­sa­tions.

The qual­ity of the talks was high, and the peo­ple were, as al­ways, amaz­ing. FOSDEM con­tin­ues to be a place where cu­rios­ity, ex­per­tise, and open­ness meet. At the same time, the ques­tion of scale can no longer be ig­nored. Camping in front of a sin­gle room just to make sure you can at­tend a talk is not a sus­tain­able so­lu­tion. In many cases, it may even dis­cour­age the peo­ple who are gen­uinely in­ter­ested but can­not af­ford to wait for hours or nav­i­gate over­crowded spaces.

For ex­actly this rea­son, I se­ri­ously con­sid­ered stay­ing home this year and watch­ing the talks via live streams or record­ings. From a purely tech­ni­cal per­spec­tive, that would have worked just fine. The con­tent would still be there, ac­ces­si­ble and well pro­duced.

But in the end, FOSDEM is not just about talks. It is about meet­ing peo­ple, re­con­nect­ing with friends, and hav­ing spon­ta­neous con­ver­sa­tions that no video stream can fully re­place. Seeing all of you again, shar­ing thoughts over cof­fee, and ex­chang­ing ideas in per­son ul­ti­mately mat­tered more than com­fort or con­ve­nience.

FOSDEM 2026 once again proved why this con­fer­ence is spe­cial. The chal­lenge now is to en­sure that it can con­tinue to grow with­out los­ing the open­ness and ac­ces­si­bil­ity that de­fine it. That bal­ance will shape what FOSDEM be­comes in the years to come.

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.

Yesterday, I wrote about Ariel OS RTOS for mi­cro­con­trollers writ­ten in Rust, but there’s an­other in­ter­est­ing open-source op­er­at­ing sys­tem for mi­cro­con­trollers that will be cov­ered at FOSDEM 2026: MicroPythonOS.

While Ariel OS is de­signed for se­cure, mem­ory-safe, net­worked IoT ap­pli­ca­tions on mi­cro­con­trollers, MicroPythonOS tar­gets ap­pli­ca­tions with graph­i­cal user in­ter­faces and is heav­ily in­spired by Android and iOS, with an app­store, an LVGL-based touch­screen and but­ton UI with plenty of wid­gets, ges­tures and theme sup­port, and a wifi man­ager, as well as over-the-air (OTA) firmware up­dates.

You’ll prob­a­bly be as­ton­ished to learn that MicroPythonOS is writ­ten in… MicroPython. It’s com­prised of a Thin OS which han­dles hard­ware ini­tial­iza­tion, mul­ti­task­ing, and UI, and every­thing else is an app, in­clud­ing sys­tem fea­tures like WiFi con­fig­u­ra­tion and OS up­dates.

* Runs on ESP32 mi­cro­con­trollers, but the FOSDEM 2026 talk men­tions that it can run on any­thing that sup­ports MicroPython, in­clud­ing the Raspberry Pi RP2350.

* Since it’s cross-plat­form, it can also run on Windows, Linux, and ma­cOS (mostly use­ful for app de­vel­op­ment and eval­u­a­tion)

Right now, five apps are pre-in­stalled: Launcher, WiFi for wire­less con­fig­u­ra­tion, AppStore to in­stall more apps, OSUpdate for OTA sys­tem up­dates, and Settings. The AppStore fea­tures var­i­ous apps, in­clud­ing Hello World, Camera, Image Viewer, and IMU to vi­su­al­ize the mo­tion sen­sor data, among oth­ers, all with source code avail­able.

It can be used to cre­ate smart home con­trollers, ed­u­ca­tional tools with in­ter­ac­tive dis­plays, de­cen­tral­ized pay­ment sys­tems, portable touch screen de­vices, ro­bot­ics with IMUs and cam­eras, smart wear­ables with ges­ture con­trols, and other pro­to­type DIY pro­jects. Hardware sup­port (on ESP32) cur­rently in­cludes WiFi, Bluetooth, sev­eral mo­tion sen­sors, cam­eras, touch screens, IO ex­panders, dis­plays, ADC, GPIO, I2C, etc…

You’ll find the source code on GitHub and in­struc­tions to get started with app and OS de­vel­op­ment on the doc­u­men­ta­tion web­site. For a quick try, in­stalling it on Windows, Linux, or ma­cOS is prob­a­bly the eas­i­est, but if you pre­fer to check the per­for­mance on ac­tual hard­ware, ESP32 tar­gets are the way to go, and you can in­stall MicroPythonOS through the web in­staller. It was specif­i­cally tested on the ESP32-S3-Touch-LCD-2  and Fri3d Camp 2024 Badge.

More de­tails can be found on the pro­jec­t’s web­site, or if you plan to go to FOSDEM 2026 this week­end, you can also at­tend the 25-minute talk on Sunday, February 1, by Thomas Farstrike.

Support CNX Software! Donate via cryp­tocur­ren­cies, be­come a Patron on Patreon, or pur­chase goods on Amazon or Aliexpress. We also use af­fil­i­ate links in ar­ti­cles to earn com­mis­sions if you make a pur­chase af­ter click­ing on those links.