If you are run­ning Android 8 or higher, a virus has been in­stalled on your de­vice and is silently await­ing re­mote ac­ti­va­tion. Over the past few months, de­vices around the world have been in­fected with this novel strain, with as many as 4 bil­lion Android hand­sets and tablets es­ti­mated to have al­ready been con­t­a­m­i­nated, mean­ing that around half of all hu­man­ity may be at risk from this threat.

Disguising it­self as the in­nocu­ously-ti­tled “Android Developer Verifier” (ADV) process, this tro­jan horse runs sur­rep­ti­tiously in the back­ground as a sys­tem ser­vice with full root priv­i­leges, qui­etly await­ing an ac­ti­va­tion sig­nal. The ser­vice can­not be blocked, dis­abled, or re­moved. Unlike a com­mon­place bit of mal­ware, this ex­tra­or­di­nary strain won’t be de­tected and neu­tral­ized by Play Protect (the mal­ware scan­ning and re­me­di­a­tion ser­vice that is in­stalled on all Android Certified de­vices). In fact, Play Protect is it­self the vec­tor through which this virus is trans­mit­ted and in­stalled.

That is be­cause it is Google them­selves who is prop­a­gat­ing ADV. And once ac­ti­vated, this malev­o­lent process has ex­actly one goal: to block you from run­ning soft­ware by de­vel­op­ers who haven’t been ap­proved cen­trally by Google.

Threat mas­querad­ing as Protection

We first raised the alarm about the Android Developer Verification pro­gram last September (“F-Droid and Google’s Developer Registration Decree”) shortly af­ter it was first an­nounced. Google’s loom­ing re­quire­ment that all Android de­vel­op­ers reg­is­ter them­selves cen­trally is ra­tio­nal­ized as a so­lu­tion to help stem the spread of mal­ware. However it does­n’t ac­tu­ally fea­ture any ca­pa­bil­i­ties to pre­vent a malev­o­lent ac­tor from dis­trib­ut­ing mal­ware in the first place; the only al­leged ben­e­fit of ADV is that it may help slow the ac­tions of an al­ready-iden­ti­fied re­cidi­vist by re­quir­ing that they cre­ate (or buy) an­other ac­count in or­der to con­tinue dis­trib­ut­ing their mal­ware with a new sign­ing key.

For this fairly nar­row threat vec­tor of mal­ware re­cidi­vism, a va­ri­ety of con­sid­er­ably less dra­con­ian so­lu­tions have been pro­posed. Play Protect it­self could be en­hanced to scru­ti­nize more closely those newly-in­stalled apps that have el­e­vated per­mis­sions or that were ob­tained through sus­pect chan­nels, con­tin­u­ing with their re­cently touted ad­vances in on-de­vice se­cu­rity ca­pa­bil­i­ties. Or a sys­tem of fed­er­ated ver­i­fiers might be im­ple­mented (as pro­posed in “DCM: A Developers Certification Model for Mobile Ecosystems”, 2023) that would em­power end-users to se­lect their own trusted cu­ra­tors and au­thor­i­ties for ex-ante ap­proval. Instead, Google has used this mi­nor vec­tor as a pre­text to rad­i­cally re-en­gi­neer the en­tire Android ecosys­tem by fiat, up­end­ing a 18 year tra­di­tion of open soft­ware de­vel­op­ment and po­si­tion­ing them­selves as the world’s sole gate­keeper for which apps are per­mit­ted to ex­ist.

What They Talk About When They Talk About Malware

Should a de­vel­oper — con­trary to our rec­om­men­da­tion — elect to reg­is­ter them­self with Google as a “verified” de­vel­oper, they should ex­pect to sign up for an ac­count and pay a fee, sur­ren­der de­tailed per­sonal in­for­ma­tion and up­load gov­ern­ment-is­sued iden­ti­fi­ca­tion, and then pro­ceed to reg­is­ter the iden­ti­fiers and sign­ing keys for all the apps they in­tend to dis­trib­ute (now or ever).

But the most di­a­bol­i­cal stage is the com­pul­sory agree­ment to the Android Developer Console Terms of Service. There are nu­mer­ous causes for dis­quiet in this doc­u­ment, but the most con­cern­ing of all ought to be:

6.5 If You vi­o­late any of the Terms or if You dis­trib­ute mal­ware or other harm­ful ap­pli­ca­tions, Google may ter­mi­nate Your ac­cess to the ADC…

6.5 If You vi­o­late any of the Terms or if You dis­trib­ute mal­ware or other harm­ful ap­pli­ca­tions, Google may ter­mi­nate Your ac­cess to the ADC…

This rea­son­able-sound­ing clause begs the ques­tion: what ex­actly is meant by “malware”? No de­f­i­n­i­tion of the term is to be found any­where in the doc­u­ment. With the ab­sence of any for­mal de­f­i­n­i­tion, stan­dard, or guide­line, it im­plic­itly states:

…and “malware” means what­ever we say it means.

…and “malware” means what­ever we say it means.

As we dis­cussed in “What We Talk About When We Talk About Sideloading”, be­ware the dan­gers of al­low­ing the ter­mi­nol­ogy of de­bate to be de­fined by those who don’t have your best in­ter­ests at heart. Malware be­ing syn­ony­mous with “software we don’t like” means that they can uni­lat­er­ally dic­tate — dri­ven ei­ther by busi­ness in­cen­tives or by be­ing com­pelled by a suf­fi­ciently pow­er­ful gov­ern­ment — what the mal­ware-du-jour de­f­i­n­i­tion is to be.

For prece­dent, per­sonal con­tent fil­ter­ing in the form of “ad block­ers” has long since been banned from the Play Store, and they have even clas­si­fied some in­stances as mal­ware. How long be­fore they des­ig­nate all ad-block­ing soft­ware as mal­ware, block in­stal­la­tion on all Android cer­ti­fied de­vices world­wide, and per­ma­nently des­ig­nate all de­vel­op­ers of this class of soft­ware as mal­ware cre­ators? Such a move would cer­tainly be aligned with their com­mer­cial in­cen­tives as the global ad-tech mo­nop­o­list, and would be com­pletely in ac­cor­dance with the lan­guage of their ADC Terms and Conditions.

Like a Lead Balloon

In terms of vol­un­tary de­vel­oper up­take, they re­cently claimed that “over 99% of [Play de­vel­op­ers’] apps have been reg­is­tered” sug­gests that ADV is some­how a pop­u­lar and widely-ac­cepted dic­tate. That could­n’t be fur­ther from the truth: those 99% of de­vel­op­ers were auto-opted-in with­out their in­formed con­sent due to be­ing al­ready bound by their Play Store agree­ments.

In fact, hun­dreds of thou­sands of peo­ple have signed a pe­ti­tion op­pos­ing ADV. The Open Letter at keepan­droidopen.org de­nounc­ing the pro­gram has been signed by over 70 or­ga­ni­za­tions around the world, in­clud­ing the EFF, FSF, FSFE, ACLU, and the in­es­timable Forbrukerrådet. Any in­ter­net search, chat­bot query, or so­cial me­dia poll will con­firm that the op­po­si­tion to this pro­gram is over­whelm­ing and the con­dem­na­tion is uni­ver­sal. 90% of view­ers of the de­vel­oper round­table video where they at­tempt to de­fend the pro­gram reg­is­tered a dis­like of the spec­ta­cle, and even Google Gemini re­sponds to in­quiries about the pop­u­lar­ity of the pro­gram with:

Aside from Google it­self, find­ing full-throated, en­thu­si­as­tic sup­port for the manda­tory Android Developer Verification pro­gram in the tech com­mu­nity is vir­tu­ally im­pos­si­ble.

The back­lash is over­whelm­ingly dom­i­nant—head­lined by the “Keep Android Open” coali­tion of civil rights and open-source groups fiercely op­pos­ing the cen­tral reg­is­tra­tion re­quire­ment.

Aside from Google it­self, find­ing full-throated, en­thu­si­as­tic sup­port for the manda­tory Android Developer Verification pro­gram in the tech com­mu­nity is vir­tu­ally im­pos­si­ble.

The back­lash is over­whelm­ingly dom­i­nant—head­lined by the “Keep Android Open” coali­tion of civil rights and open-source groups fiercely op­pos­ing the cen­tral reg­is­tra­tion re­quire­ment.

And yet their lock­down blitzkrieg pro­ceeds apace. Legislators and reg­u­la­tors have thus far been un­re­cep­tive to the out­cry. Our own po­si­tion as a bas­tion of soft­ware free­dom and re­spect for user rights and pri­vacy is in ex­treme jeop­ardy. The F-Droid model of se­cu­rity and trust through open-source trans­parency is fun­da­men­tally at odds with the “trust me bro” se­cu­rity model of the closed-source com­mer­cial app stores. And while these two mod­els have been able to co-ex­ist for the past 16 years of F-Droid’s ex­is­tence, it ap­pears that Google in­tends to es­tab­lish a regime where they alone have a mo­nop­oly on the de­f­i­n­i­tions of “security” and “trust”.

What to Expect in the Days to Come

We do not yet know the ex­act fail­ure mode to ex­pect when the ADV ac­ti­va­tion is trig­gered on September 30. If you are one of the 580 mil­lion peo­ple liv­ing in Brazil, Indonesia, Singapore, or Thailand, know that these are the first four tar­gets of the ADV lock­down ac­cord­ing to their pub­lished time­line (global roll­out is omi­nously pre­dicted to then oc­cur through­out “2027 and be­yond”).

There are many things we don’t know about what to ex­pect on September 30. Some com­mon ques­tions that we do not yet have the an­swer to, for those in the af­flicted re­gions, are:

What will hap­pen if I try to in­stall or launch the F-Droid app?

What will hap­pen to all the apps I’ve in­stalled through F-Droid? Will they be dis­abled? Deleted?

If apps that I rely on are sud­denly dis­ap­peared, what hap­pens to the data they con­tain? Can I still re­trieve it?

With all soft­ware in­stal­la­tions and launches now be­ing re­ported back to Google for ver­i­fi­ca­tion, what spe­cific in­for­ma­tion does that teleme­try in­clude?

We have reached out to the mal­ware ven­dor with our in­quiries. In the com­ing weeks and months lead­ing up to the lock­down, we will be pub­lish­ing more guid­ance and sup­port for those due to be im­pacted by ADV.

GLM Coding Plan

Code with GLM Coding Plan

GLM is tuned for ZCode, mak­ing agen­tic cod­ing faster and stead­ier.

GLM Coding

Lite

For light­weight work­loads

$16.2/ month$18

Base us­age al­lowance in­cluded

Built for light­weight it­er­a­tion on small repo

Rolling ac­cess to the lat­est flag­ship mod­els and fea­tures

Supports 20+ cod­ing tools, in­clud­ing deep ZCode in­te­gra­tion

GLM Coding

Pro

Popular

For pro­fes­sional work­loads

$64.8/ month$72

Everything in Lite, plus 5x Lite us­age

Built for day-to-day de­vel­op­ment on mid-sized re­pos

Priority ac­cess to the lat­est flag­ship mod­els and fea­tures

Includes a cu­rated se­lec­tion of MCP tools

Faster gen­er­a­tion speeds

GLM Coding

Max

Max Usage

For high-vol­ume work­loads

$144/ month$160

Everything in Pro, plus 20x Lite us­age

Built for ad­vanced users work­ing on mid-to-large re­pos

First ac­cess to the lat­est flag­ship mod­els and fea­tures

Dedicated re­sources dur­ing peak times

Prices and plan ben­e­fits may change. Final de­tails are shown on z.ai.

Capabilities

Stay on the Frontier

From un­der­stand­ing legacy mono­liths to ship­ping real-time fea­tures, ZCode keeps every en­gi­neer on the fron­tier of soft­ware de­vel­op­ment.

Long-running tasks

Use Goals to man­age com­plex work with con­tin­u­ous plan­ning, ex­e­cu­tion, and ver­i­fi­ca­tion.

Bot con­trol

Start and steer ZCode from WeChat, Feishu, or Telegram so work can keep mov­ing any­where.

Deep GLM-5.2 in­te­gra­tion

Optimized for GLM-5.2 across rea­son­ing, cod­ing, and multi-agent col­lab­o­ra­tion.

All Downloads

All ZCode in­stallers for every plat­form

MacOS

Windows

Linux

Beta

Today in Tedium: Recently, I passed 20,000 fol­low­ers on Bluesky, which I did­n’t re­ally say any­thing about. Sure, I thought about it, but then I had de­cided to my­self, what’s the point? Soon, there will be an­other mark I can point to and feel weird about. The thing about so­cial me­dia these days is that the good stuff all too of­ten pulls you in, but at the end of the day, you end up feel­ing hol­low. Perhaps it’s for this rea­son that, when I spot­ted a thread ask­ing about what my fa­vorite so­cial net­work of all time was, my an­swer was­n’t Twitter or Bluesky or even Tumblr. It was, of all things, a fo­rum for news de­sign­ers that ex­isted in the mid-2000s called Visual Editors. It barely worked, hon­estly: It had a chat op­tion that was pop­u­lar with de­sign­ers wait­ing for their pages to get proofed late in the evening, but it would of­ten go down with no warn­ing. But from a com­mu­nity stand­point, it was spec­tac­u­lar. Why don’t many mod­ern so­cial net­works feel like that? Today’s Tedium pon­ders the fate of the web fo­rum. — Ernie @ Tedium

110k

The num­ber of news­groups that many mod­ern Usenet providers, in­clud­ing GigaNews and SuperNews, pro­mote as be­ing avail­able on their ser­vices. The Usenet sys­tem, with roots in the late 1970s, was the first fo­rum-like sys­tem many early in­ter­net users re­lied on, with the other pri­mary op­tion be­ing email list­servs. But by the late 1990s, the not-par­tic­u­larly-graph­i­cal Usenet was al­ready falling out of fa­vor.

Why the Web even­tu­ally moved in the di­rec­tion of fo­rums

If you think about it, the web fo­rum was a ter­ri­ble fit for the way the Web worked. We al­ready tech­ni­cally had a tool that al­lowed peo­ple to com­mu­ni­cate with one an­other in a fo­rum set­ting in the early ’90s—Usenet.

Or, at least, that’s what it seemed like. So I won­dered, well, what did peo­ple think about the growth of web fo­rums on Usenet? And that led me in the di­rec­tion of a fas­ci­nat­ing post from mod­ern-day fu­tur­ist Eric Hunting.

Posting on alt.hy­per­text in the thread “Forums in the Web,” in April 1994, Hunting more or less pre­dicted what web fo­rums would be­come in just a cou­ple of years:

One of the things lack­ing in the en­vi­ron­ment of the Web is a means of us­ing Web pages as a medium for con­duct­ing open dis­cus­sions or fo­rums as you have in USENET. The rea­son for this is prob­a­bly that there is no means of pack­ag­ing pages, along with all their as­so­ci­ated graph­ics and mul­ti­me­dia data, like fo­rum posts nor would it be prac­ti­cal to dis­trib­ute such po­ten­tially huge amounts of data among fo­rum servers as with USENET.

One of the things lack­ing in the en­vi­ron­ment of the Web is a means of us­ing Web pages as a medium for con­duct­ing open dis­cus­sions or fo­rums as you have in USENET. The rea­son for this is prob­a­bly that there is no means of pack­ag­ing pages, along with all their as­so­ci­ated graph­ics and mul­ti­me­dia data, like fo­rum posts nor would it be prac­ti­cal to dis­trib­ute such po­ten­tially huge amounts of data among fo­rum servers as with USENET.

His post, which is a bit wordy, de­scribes the con­cept of threads, URLs as or­ga­niz­ing struc­tures, and what might or might not work. Essentially, the ad­di­tion of im­ages and mul­ti­me­dia, a sec­ond-class cit­i­zen on a text-based fo­rum like Usenet, would sig­nif­i­cantly re­shape how peo­ple in­ter­acted on fo­rums. One area where he was wrong, un­for­tu­nately, is a com­mon one. He as­sumed that the lack of anonymity would lead peo­ple to be­have a bit bet­ter on­line:

It’s one thing to toss out a hun­dred lines of spon­ta­neous vin­dic­tive­ness to the face­less USENET server, an­other thing to have to main­tain that mass of nas­ti­ness for a spe­cific pe­riod of time on one’s own com­puter. A Web Forum post would­n’t be a mes­sage on a pa­per air­plane tossed to the aether. It would be a bill­board in your own home.

It’s one thing to toss out a hun­dred lines of spon­ta­neous vin­dic­tive­ness to the face­less USENET server, an­other thing to have to main­tain that mass of nas­ti­ness for a spe­cific pe­riod of time on one’s own com­puter. A Web Forum post would­n’t be a mes­sage on a pa­per air­plane tossed to the aether. It would be a bill­board in your own home.

Welp, not so much. But Hunting would­n’t have to wait long to see an im­ple­men­ta­tion of a web fo­rum in the wild. In June 1994, CERN’s Ari Luotonen de­vel­oped what is be­lieved to be the first Web-based fo­rum soft­ware, WWW Interactive Talk (WIT).

“[Bear] in mind that this was put to­gether in a big hurry in a few days so for­give me if it does­n’t do yet all the things that it could do,” Luotonen wrote.

The soft­ware did not live for long, and no longer ap­pears on the W3C web­site—a sur­prise be­cause much of its early work has more or less stayed on­line. Not this, though—though a lit­tle Internet Archive Wayback-foo even­tu­ally helped me find where the archive file was hid­ing.

In hopes of kick­ing back off a trend in W3C-generated fo­rums, I up­loaded the soft­ware to GitHub. And for kicks, I got it to run in a Docker con­tainer.

(Want to try it your­self? I put it on the Web here. Watch out for falling spam.)

While the W3C was first, there are lots of ex­am­ples of sim­i­lar tools out there. For ex­am­ple, the Collaborative Cork Board (CoCoBoard) was de­vel­oped at the University of Illinois’ National Center for Supercomputing Applications (NCSA), the same place that launched Mosaic into the world. That tool es­sen­tially turned email replies into fo­rum threads.

It was­n’t long be­fore this pie in the sky con­cept, once the ex­per­i­men­tal ter­ri­tory of early Web de­vel­op­ers work­ing in CGI and Perl, found in­ter­est with big busi­nesses. These were pro­moted as one of many ex­am­ples of group­ware. Odds are, you prob­a­bly did not get your first ex­pe­ri­ence post­ing on a Web fo­rum us­ing an open-source tool, but a com­mer­cial one.

One of the first com­pa­nies to suc­cess­fully launch a web fo­rum startup was Lundeen & Associates, which cre­ated the WebCrossing fo­rum tool, which was an­nounced in the fall of 1995. Within a year, a num­ber of ma­jor pub­li­ca­tions, in­clud­ing the Minneapolis Star-Tribune, The New York Times, and Salon, had put the soft­ware to work—in the Times’ case, it was part of its 1996 elec­tion cov­er­age. While later tools be­came bet­ter known, WebCrossing may be one of the few in­ter­net-na­tive soft­ware tools to re­main in ac­tive de­vel­op­ment for more than 30 years.

(A tes­ta­ment to its legacy: Salon used the soft­ware as the an­chor of its dig­i­tal com­mu­nity for more than 15 years, only shut­ting it down in 2011 out of con­cerns it was­n’t where the Web was go­ing. With an­other 15 years of ret­ro­spect, can we ar­gue that this was prob­a­bly a bad move? Perhaps.)

But WebCrossing was far from alone. The web­site Perlwatch has a list of lit­er­ally hun­dreds of dif­fer­ent fo­rum sys­tems, some of which vary in lev­els of ob­scu­rity. The list, as far as I can tell, has not been up­dated in years, de­spite the site claim­ing oth­er­wise. But it is an ex­cel­lent his­toric doc­u­ment of what it was like look­ing for a bul­letin board sys­tem in the late ’90s and early 2000s.

But even with all this com­pe­ti­tion, the most dom­i­nant player in ’90s fo­rum soft­ware ben­e­fited from be­ing the free op­tion. Matt’s Script Archive, a col­lec­tion of Perl-based web­site tools (including guest­books and page coun­ters), hit on some­thing im­por­tant with WWWboard.

That tool, a prim­i­tive fo­rum tech­nol­ogy that barely worked, nonethe­less made threaded dis­cus­sions ac­ces­si­ble by nor­mal peo­ple, even if it meant fo­rums that ex­tended well past the point of load­abil­ity and se­cu­rity is­sues that never get patched. (We wrote a whole thing about it last week in case you want to dive in more.)

We quickly sur­passed the lim­ited ca­pa­bil­i­ties of WWWBoard. But the fo­rum it­self would even­tu­ally get left in the dust, too.

Five key ex­am­ples of web fo­rum soft­ware that are es­sen­tial to in­ter­net his­tory

Ultimate Bulletin Board. This soft­ware, later known as UBB and UBB.classic, found broad pop­u­lar­ity on the in­ter­net thanks in large part to its low cost. It was a sig­nif­i­cant step up from WWWboard, in a good way. The soft­ware was orig­i­nally de­vel­oped around 1996 by Social Strata, which ex­ists to­day un­der the name CrowdStack. (That said, its his­tory is a bit wind­ing, so not every ver­sion may work the same.)

Slash. Developed by Rob Malda in 1998 as a way to help man­age the fo­rums on his pop­u­lar tech-news site Slashdot, Slash proved supremely in­flu­en­tial as a com­mu­nity man­age­ment tool. (A big part of the rea­son? It came with re­ally strong self-mod­er­a­tion fea­tures that were later copied by plat­forms like Hacker News, Digg, and Reddit.) While it’s not to­tally clear if Slashdot it­self still uses Slash to­day (Malda, for one, left years ago), the site SoylentNews is known to use a di­rect fork of it.

vBul­letin. This is one of the more rec­og­niz­able fo­rum plat­forms on the in­ter­net, in part be­cause of its use on some very promi­nent fo­rums. Notably, Something Awful’s in­fa­mous fo­rums use vBul­letin, but that’s only half the story there: The soft­ware was forked years ago, and has been heav­ily mod­i­fied and cus­tomized by SA’s mod­er­a­tors and own­ers over the past two decades. At this point, it’s more theirs than vBul­let­in’s.

ph­pBB. While vBul­letin, which came out around the same time as ph­pBB, is a com­mer­cial tool, ph­pBB has al­ways been free and open source, and as a re­sult, has found a mas­sive com­mu­nity of peo­ple will­ing to write ex­ten­sions for it. The sim­i­lar nodeBB is a mod­ern­iza­tion of the ph­pBB ap­proach and mostly works the same.

Discourse. While it’s not the only tool of its kind, the de­ci­sion by Jeff Atwood, Robin Ward, and Sam Saffron to build a new type of fo­rum soft­ware was a big deal in 2014. After all, it was a medium in se­vere need of rein­ven­tion. (The move to a Ruby code­base, for ex­am­ple, was an im­por­tant shift at a time when many fo­rums still ran on PHP or Perl.) It can be seen as a con­tin­u­a­tion of Stack Exchange, a pop­u­lar plat­form for pro­gram­mer dis­cus­sions that Atwood co-founded in 2008.

1985

The year that The Whole Earth ’Lectronic Link, also known as The Well, first got its start. It is one of the longest con­tin­u­ously run­ning on­line com­mu­ni­ties in dig­i­tal cul­ture, and un­like most bul­letin boards or on­line ser­vices of its kind, it suc­cess­fully made the jump to the Web. It re­mains ac­tive to­day as a paid pri­vate com­mu­nity. (The Well ac­tu­ally spon­sored Tedium a mil­lion moons ago, which I re­al­ize is a cool thing to be able to say.)

Before there was Markdown, there was BBCode

One chal­lenge that a lot of early fo­rums had to nav­i­gate was the ne­ces­sity of san­i­tiz­ing the text that peo­ple posted in fo­rums. People could post lit­er­ally any­thing in a form, and it could break the site, en­cour­age ex­ploits, the whole bit.

(When you don’t san­i­tize, you run into is­sues like mak­ing it pos­si­ble to put CSS on MySpace pages.)

But on the other hand, you still wanted your web­sites to have at least some style to them, in a con­trolled way, with­out a lot of ex­tra junk. These days, a lot of plat­forms use Markdown to solve this prob­lem, in part be­cause of its ubiq­uity. But be­fore that, peo­ple post­ing on fo­rums needed al­ter­na­tive op­tions that made room for fun if not for putting mal­ware on your fo­rum.

That led to the cre­ation of BBCode in 1998, first start­ing with UBB, then spread­ing to other fo­rum plat­forms like ph­pBB and vBul­letin. (There is a BBCode dot org ded­i­cated to this script­ing lan­guage, but I refuse to link to it be­cause it’s now a Web3 SEO play.) While it does­n’t get the mod­ern level of at­ten­tion Markdown does, it is both older and more ca­pa­ble than Markdown is, for bet­ter or worse.

A sub­set of HTML, it ef­fec­tively re­placed the < or > with [ and ], and re­moved the abil­ity to add a bunch of ex­tra stuff that the HTML spec was ca­pa­ble of do­ing. Forum own­ers nat­u­rally ap­pre­ci­ated this be­cause it gave them a bit of con­trol over what users could do on their plat­form. JavaScript might be off the table, but 300 point text? Suddenly pos­si­ble. A li­brary of com­mon im­ages? Absolutely, they were called im­age macros. And fea­tures that make the fo­rum more us­able? You bet.

This lingo would some­times shape the com­mu­nity as a whole. Fans of Something Awful, for ex­am­ple, likely re­mem­ber the fo­rums had a num­ber of im­age macros, most no­tably :10bux:, which dis­played an im­age of a $10 bill, re­flect­ing the fo­rum’s in­fa­mous one-time en­try fee. And on some fo­rums, BBCode would end up get­ting used in ex­per­i­men­tal ways, help­ing to gen­er­ate some early meme cul­ture. In its own way, BBCode was what made fo­rums more than just Usenet in HTML for­mat.

The down­side is that the se­cu­rity rea­sons were more pro­nounced in the­ory than in prac­tice. A 2005 blog post by de­vel­oper Chris Shiflett ar­gued that the se­cu­rity rea­son for BBCode was a lot weaker than it seemed:

As reg­u­lar read­ers of Security Corner know, in­put must al­ways be fil­tered. When you’re al­low­ing users to en­ter very com­plex data, cre­at­ing a whitelist of ac­cept­able char­ac­ters can be very dif­fi­cult. Because of this, many de­vel­op­ers em­ploy very weak fil­ter­ing rules for such in­put and rely on the es­cap­ing per­formed by htm­len­ti­ties() for pro­tec­tion.While htm­len­ti­ties() can save you from poorly fil­tered data, re­ly­ing on es­cap­ing alone is not ideal. Because an at­tacker can send any type of data, it’s equally un­wise to rely on BBCode for pro­tec­tion—you can’t as­sume that the at­tack­ers will abide by your rules un­less you en­force those rules in your pro­gram­ming logic.

As reg­u­lar read­ers of Security Corner know, in­put must al­ways be fil­tered. When you’re al­low­ing users to en­ter very com­plex data, cre­at­ing a whitelist of ac­cept­able char­ac­ters can be very dif­fi­cult. Because of this, many de­vel­op­ers em­ploy very weak fil­ter­ing rules for such in­put and rely on the es­cap­ing per­formed by htm­len­ti­ties() for pro­tec­tion.

While htm­len­ti­ties() can save you from poorly fil­tered data, re­ly­ing on es­cap­ing alone is not ideal. Because an at­tacker can send any type of data, it’s equally un­wise to rely on BBCode for pro­tec­tion—you can’t as­sume that the at­tack­ers will abide by your rules un­less you en­force those rules in your pro­gram­ming logic.

But even if the se­cu­rity rea­sons did­n’t mat­ter so much, Shiflett con­ceded that it was good for users and may in some cases even be eas­ier to re­mem­ber than ac­tual HTML. (Though on the other hand, one pre­sumes BBCode did dis­cour­age some peo­ple from try­ing out fo­rums en­tirely. Those were the peo­ple who even­tu­ally went to Facebook.)

A sim­i­lar con­cept in con­tent man­age­ment sys­tems as­so­ci­ated with WordPress, the short­code, be­came a pop­u­lar tech­nique for help­ing vi­su­ally mod­ify or or­ga­nize con­tent on a page. (Tedium uses short­codes with Markdown.)

More video games should be pro­grammed with a lit­tle BBCode.

But what may be the most in­ter­est­ing legacy for BBCode in the mod­ern day might not even be fo­rums. The game de­vel­op­ment tool Godot has adopted the script­ing lan­guage for writ­ing for­mat­ted text within its node-dri­ven in­ter­face. Which, given Godot’s surge in pop­u­lar­ity over the past few years, likely means that a lot of mod­ern games you en­joy might be se­cretly tak­ing ad­van­tage of a tool de­vel­oped for fo­rum soft­ware built in Perl roughly 30 years ago.

Guess we can in­di­rectly blame Unity for help­ing give BBCode a sec­ond wind. What a story arc.

“We’re shrink­ing the world. It used to be that just a few peo­ple saw your photo. Now many do. We helped peo­ple in Tunisia broad­cast what was hap­pen­ing, and they could hear peo­ple around the world sup­port­ing them.”

“We’re shrink­ing the world. It used to be that just a few peo­ple saw your photo. Now many do. We helped peo­ple in Tunisia broad­cast what was hap­pen­ing, and they could hear peo­ple around the world sup­port­ing them.”

— Dick Costolo, the for­mer CEO of Twitter (in the pre-Elon days), dis­cussing what made Twitter such a pow­er­ful tool. While this shrink­ing of our world might seem like a good thing (with the Arab Spring a go-to ex­am­ple at the time Costolo was lead­ing the com­pany), re­cent think­ing has moved in a dif­fer­ent di­rec­tion. “There is some­thing ter­ri­bly wrong with so­cial me­dia,” psy­chol­o­gist Nigel Barber ar­gued in 2024. “The prob­lem is that they are run by an en­gage­ment al­go­rithm that ig­nores the prin­ci­ples of suc­cess­ful com­mu­ni­ties.” The con­cept of con­tent col­lapse likely also plays a role here. “The prob­lem is not lack of con­text,” cul­tural an­thro­pol­o­gist Michael Wesch wrote in 2009 about the then-new con­cept of YouTube. “It is con­text col­lapse: an in­fi­nite num­ber of con­texts col­laps­ing upon one an­other into that sin­gle mo­ment of record­ing.”

Why did fo­rums lose out to so­cial me­dia? I think the short an­swer comes down to nov­elty. Much like Usenet a decade ear­lier, we were ready for some­thing dif­fer­ent, hav­ing seen the weak­nesses of fo­rums in the late 1990s and early 2000s. We were ready to let some­one else han­dle the tech­nol­ogy part.

Plus, there’s the is­sue of scale. In so many ways, hav­ing a fo­rum run by some­one in a com­mu­nity on shared host­ing meant that you could­n’t have a com­mu­nity un­less there was some­one will­ing to take on that com­mit­ment. They were on the hook not just to pay for the host­ing, but to spend a ter­ri­ble night man­ag­ing things when the server got full, hacked, or sim­ply over­heated be­cause Slashdot linked one of your threads.

In many ways, the tech­ni­cal ar­gu­ment made it an easy tar­get for Web 2.0. There’s a rea­son why Digg, Reddit, and StackOverflow are per­haps the best man­i­fes­ta­tions of that era of tech­nol­ogy. They were pur­pose-built com­mu­nity plat­forms that mod­ern­ized things just enough for peo­ple who were look­ing for some­thing a lit­tle bet­ter than we were get­ting from the thing that your friend built.

We tried the fo­rum thing. We wanted some­thing else. Not nec­es­sar­ily be­cause it was bet­ter, though sure, maybe it was. But be­cause it was dif­fer­ent.

I want to pose a ques­tion: Is it pos­si­ble that on­line users just have non­stop shiny ob­ject syn­drome, and even if fo­rums worked cor­rectly and did the job, users would still move onto some­thing else be­cause we’re never happy? I think the ar­gu­ment is pretty strongly yes.

That said, I do think that as the in­ter­net ma­tures into some­thing that is more fur­ni­ture in our lives, per­haps some of us will slow down. Maybe we’ll log into a fo­rum and re­al­ize what we ac­tu­ally wanted out of our on­line ex­pe­ri­ence was never the abil­ity to reach every­one, but to reach the small num­ber of peo­ple that think kind of like us. Maybe the “collisions” that mod­ern so­cial net­works cre­ate just make things worse, even if it means we don’t get the oc­ca­sional ego boost of Patton Oswalt re­ply­ing to our tweet or what­ever.

There was charm to all that barely-work­ing PHP and Perl code that I think we’re still try­ing to re­cap­ture a quar­ter-cen­tury later.

–

Find this one an in­ter­est­ing read? Share it with a pal!

And we just added a bunch of new items to the Tedium Shopping Network. Maybe you might see some­thing there you don’t need. Check it out.

0 Members and 26 Guests are view­ing this topic.

2026 – 06-30 10:31:23

I re­cently did a full rewrite of FFmpeg’s AAC en­coder.  Everything from rate con­trol, RDO, and all cod­ing tools (PNS, TNS, I/S and M/S) was reengi­neered. Metrics-wise (Google’s new Zimtohrli, ViSQOL, and my own hear­ing) it’s ap­par­ently the best AAC en­coder, com­pared to qaac and fdk-aac:

The rewrite will be merged to­day. You can ei­ther com­pile it from source or grab one of BtbN’s lat­est nightly builds (once merged and they up­date) to test it.

Some specifics:

the new en­coder is strictly CBR, with very lit­tle vari­a­tion in rate. Having a bit bud­get tar­get helps cod­ing a lot. I don’t rec­om­mend us­ing -q:a (real VBR mode).

Other en­coders don’t use any cod­ing tools ex­cept TNS. So first, I beat them fair, us­ing only TNS, then reim­ple­mented PNS, I/S and M/S on top to crush them con­clu­sively.

I RE’d qaac and found out it does no per­cep­tual op­ti­miza­tions. It sim­ply uses band en­ergy with a bit al­lo­ca­tion curve that favours high fre­quen­cies. I im­proved on that by hav­ing a sim­i­lar curve, and us­ing masked band en­ergy for the RDO.

FFmpeg’s AAC DEcoder is busted with re­gards to stereo PNS, and the bug may be in other AAC de­coders too, so we work around it in the en­coder. Since no other en­coder used PNS, the bug was not found un­til now.

Special at­ten­tion was paid to high bi­trates. Coding tools like I/S and PNS get turned off by them­selves if the en­coder does good on its own to main­tain rate.

All cod­ing tools, PNS, TNS, I/S and M/S are part of the RDO loop. We use no par­roted heuris­tics or ar­bi­trary bi­trate cut­offs. If a tool can be used, it will be used.

If you in­tend to down­mix or ex­pect the out­put to get down­mixed, use -aac_is 0 -aac_pns 0 to main­tain the orig­i­nal sig­nal phase.

The en­coder was mainly op­ti­mized for 48Khz au­dio. Get over it. It’s 2026, re­sam­pling is free, 48Khz is the stan­dard. 44.1Khz will work, and so will 96Khz but use 48Khz if you want the best qual­ity.

If you look at spec­tro­grams, we leave a lot of holes. This is by de­sign. Masked bands get ze­ro’d or PNS’d, since a neigh­bour­ing band is loud enough to avoid notic­ing the miss­ing bands. It’s bet­ter to only code au­di­ble bands well, than code every­thing badly.

The en­coder prints ex­tra stats on uninit:Qavg: 207.975  Tr: 5.3%  TNS(L): 4.8%  TNS(S): 36.9%  M/S: 3.9%  I/S: 10.0%  PNS: 5.1%Here’s how to read them.

the av­er­age lambda value (higher val­ues == en­coder strug­gles more to keep rate)

Short blocks

TNS us­age on long frames

TNS us­age on short frames

Mid/Side cod­ing us­age

Intensity stereo cod­ing us­age

Perceptual Noise Substitution us­age

Re: FFmpeg 9.1′s new AAC en­coder

Reply #1 – 2026 – 06-30 10:37:12

Yet most of the worlds au­dio is 44KHz…

Re: FFmpeg 9.1′s new AAC en­coder

Reply #2 – 2026 – 06-30 10:53:44

“The en­coder was mainly op­ti­mized for 48Khz au­dio. Get over it. It’s 2026, re­sam­pling is free, 48Khz is the stan­dard. 44.1Khz will work, and so will 96Khz but use 48Khz if you want the best qual­ity.“Yet most of the worlds au­dio is 44KHz…

Yet most of the worlds au­dio is 44KHz…

Re: FFmpeg 9.1′s new AAC en­coder

Reply #3 – 2026 – 06-30 11:28:45

Re: FFmpeg 9.1′s new AAC en­coder

Reply #4 – 2026 – 06-30 12:14:21

Re: FFmpeg 9.1′s new AAC en­coder

Reply #5 – 2026 – 06-30 16:00:40

For those un­aware: Lynne also wrote the na­tive USAC de­coder for FFmpeg, all of it AFAIR. Bit off-topic, but: Lynne, are you aware of the USAC play­back glitches dur­ing seek­ing? Discussed a lot here, e.g. https://​hy­dro­ge­nau­dio.org/​in­dex.php/​topic,129641.ms­g1083064.html#ms­g1083064 and https://​hy­dro­ge­nau­dio.org/​in­dex.php/​topic,129641.ms­g1083087.html#ms­g1083087

I agree with Mycroft that FFmpeg’s old AAC en­coder per­forms quite “suboptimally”, and I think this is also con­firmed in the re­sults of one of Kamedo2′s lis­ten­ing tests, https://​hy­dro­ge­nau­dio.org/​in­dex.php/​topic,119861.0.html

Chris

Last Edit: 2026 – 06-30 16:03:22 by C.R.Helmrich

Re: FFmpeg 9.1′s new AAC en­coder

Reply #6 – 2026 – 06-30 16:55:06

$ ffm­peg124995 -i in.44100Hz.stereo.wav -c:a li­bo­pus -b:a 89k out.opus$ ffm­peg124995 -i in.44100Hz.stereo.wav -c:a opus -strict ex­per­i­men­tal -b:a 96k out.opus$ ffm­peg124995 -i in.44100Hz.stereo.wav -c:a libfd­k_aac -b:a 96k out.mp4$ ffm­peg124995 -i in.44100Hz.stereo.wav -c:a aac -b:a 96k out.mp4$ ffm­peg124995 -i in.44100Hz.stereo.wav -c:a aac_mf -b:a 96k out.mp4$ ffm­peg124995 -i in.44100Hz.stereo.wav -c:a libm­p3lame -b:a 96k out.mp3$ ffm­peg124995 -i in.44100Hz.stereo.wav -c:a ac3 -b:a 96k out.ac3

Re: FFmpeg 9.1′s new AAC en­coder

Reply #7 – 2026 – 07-01 13:33:48

The rewrite will be merged to­day.

Re: FFmpeg 9.1′s new AAC en­coder

Reply #8 – 2026 – 07-01 14:52:30

Oh, Lynne is on HA! Welcome!For those un­aware: Lynne also wrote the na­tive USAC de­coder for FFmpeg, all of it AFAIR. Bit off-topic, but: Lynne, are you aware of the USAC play­back glitches dur­ing seek­ing? Discussed a lot here, e.g. https://​hy­dro­ge­nau­dio.org/​in­dex.php/​topic,129641.ms­g1083064.html#ms­g1083064 and https://​hy­dro­ge­nau­dio.org/​in­dex.php/​topic,129641.ms­g1083087.html#ms­g1083087I agree with Mycroft that FFmpeg’s old AAC en­coder per­forms quite “suboptimally”, and I think this is also con­firmed in the re­sults of one of Kamedo2′s lis­ten­ing tests, https://​hy­dro­ge­nau­dio.org/​in­dex.php/​topic,119861.0.htmlChris

For those un­aware: Lynne also wrote the na­tive USAC de­coder for FFmpeg, all of it AFAIR. Bit off-topic, but: Lynne, are you aware of the USAC play­back glitches dur­ing seek­ing? Discussed a lot here, e.g. https://​hy­dro­ge­nau­dio.org/​in­dex.php/​topic,129641.ms­g1083064.html#ms­g1083064 and https://​hy­dro­ge­nau­dio.org/​in­dex.php/​topic,129641.ms­g1083087.html#ms­g1083087

I agree with Mycroft that FFmpeg’s old AAC en­coder per­forms quite “suboptimally”, and I think this is also con­firmed in the re­sults of one of Kamedo2′s lis­ten­ing tests, https://​hy­dro­ge­nau­dio.org/​in­dex.php/​topic,119861.0.html

Chris

Too bad, I am cur­rently test­ing the FFmpeg AAC en­coder ver­sion N-124995-gbb6de744cc, Sat, 13 Jun 2026 19:08:10 ver­sion. Your wholly-rewrit­ten ver­sion won’t be in­cluded in the up­com­ing ABC/HR lis­ten­ing test re­sults(now 19% done).

By the way, about the met­rics, Zim is the bet­ter met­ric, but sat­u­rates at high bi­trates, so ViS is used as a tiebreaker. Using this rule, we win across all com­par­isons (except Opus, be­cause it’s the best).

Re: FFmpeg 9.1′s new AAC en­coder

Reply #9 – 2026 – 07-01 15:35:00

i tested this with only one song (Burn the Boats from Marathon [Vol. II]: They are Waiting (Original Game Soundtrack)), but did so with -b:a mode as lynne re­quested.

fol­low­ing bi­trates tested are 64kbps, 134kbps, 200kbps.64k is good, al­beit with a bit of ar­ti­fact­ing. not sure if ffm­peg AAC PNS de­coder bug (playing the re­sult­ing file with ff­play btw) or not.134k and 200k makes for a sub­lime lis­ten.

Re: FFmpeg 9.1′s new AAC en­coder

Reply #10 – 2026 – 07-01 16:08:24

Re: FFmpeg 9.1′s new AAC en­coder

Reply #11 – 2026 – 07-01 16:24:42

ffm­peg -i in­put.flac -map 0:0 -c:a aac -b:a 128000 out­put.m4a

ffm­peg -i in­put.flac -map 0:0 -c:a aac -aac_is 0 -b:a 128000 out­put.m4a

ffm­peg -i in­put.flac -map 0:0 -c:a aac -aac_pns 0 -b:a 128000 out­put.m4a

Re: FFmpeg 9.1′s new AAC en­coder

Reply #12 – 2026 – 07-01 17:22:48

Re: FFmpeg 9.1′s new AAC en­coder

Reply #13 – 2026 – 07-01 18:42:41

edit: Seems that in my ju­ris­dic­tion, even short sam­ples (~8 sec­onds) can­not be pro­vided. Keeping this in­for­ma­tion avail­able in text form, in case Lynne has this par­tic­u­lar song avail­able.

thanks for your work on the ffm­peg AAC en­coder, this is cer­tainly very ex­cit­ing work!

I think I’m hav­ing a sam­ple the new en­coder (current git main) does­n’t like too much.

Sample: First 8 sec­onds of “The Tower” by Bruce Dickinson.

I think this uses the old AAC en­coder, which ap­pears to use a ca. 12 kHz cut­off:

ffm­peg -i the-tower-8s.flac -b:a 64k -aac_coder twoloop the-tower-8s-64k-twoloop.aac

ffm­peg -i the-tower-8s.flac -b:a 64k -aac_coder nmr the-tower-8s-64k-nmr.aac

ffm­peg -i the-tower-8s.flac -b:a 64k -aac_coder nmr -cutoff 12000 the-tower-8s-64k-nmr-12khz.aac

Last Edit: 2026 – 07-01 18:52:09 by maik­merten

Re: FFmpeg 9.1′s new AAC en­coder

Reply #14 – 2026 – 07-01 18:55:02

ffm­peg -i fat­boy_30sec.flac -c:a aac -b:a 192000 out­put.m4affm­peg -i fat­boy_30sec.flac -c:a aac -ar 48000 -b:a 192000 out­put48k.m4affm­peg -i fat­boy_30sec.flac -c:a aac -aac_tns 0 -b:a 192000 out­put_notns.m4a

Re: FFmpeg 9.1′s new AAC en­coder

Reply #15 – 2026 – 07-01 19:37:04

I quickly tested the fat­boy_30sec sam­ple at 192 kbps and heard a tick­ing sound at 6.836s and 10.480s. Resampling to 48kHz does­n’t fix the prob­lem, and ac­tu­ally in­tro­duces an ad­di­tional tick at 14.125s. The tick­ing only dis­ap­pears when TNS is turned off. I did­n’t do an ABX test be­cause the is­sue is clearly au­di­ble. Still, it’s great to hear a no­tice­able im­prove­ment in over­all qual­ity, so thanks to @lynne for that.Sam­ple: https://​hy­dro­ge­nau­dio.org/​in­dex.php/​topic,19682.ms­g193708.html­Com­mands:ffm­peg -i fat­boy_30sec.flac -c:a aac -b:a 192000 out­put.m4affm­peg -i fat­boy_30sec.flac -c:a aac -ar 48000 -b:a 192000 out­put48k.m4affm­peg -i fat­boy_30sec.flac -c:a aac -aac_tns 0 -b:a 192000 out­put_notns.m4a

ffm­peg -i fat­boy_30sec.flac -c:a aac -b:a 192000 out­put.m4affm­peg -i fat­boy_30sec.flac -c:a aac -ar 48000 -b:a 192000 out­put48k.m4affm­peg -i fat­boy_30sec.flac -c:a aac -aac_tns 0 -b:a 192000 out­put_notns.m4a

Re: FFmpeg 9.1′s new AAC en­coder

Reply #16 – 2026 – 07-01 19:39:20

Hi Lynne, edit: Seems that in my ju­ris­dic­tion, even short sam­ples (~8 sec­onds) can­not be pro­vided. Keeping this in­for­ma­tion avail­able in text form, in case Lynne has this par­tic­u­lar song avail­able.

Re: FFmpeg 9.1′s new AAC en­coder

Reply #17 – 2026 – 07-01 20:08:15

There re­ally is­n’t a lot we can do at 64kbps stereo. We can’t boost PNS with­out ru­in­ing the stereo im­age.

Re: FFmpeg 9.1′s new AAC en­coder

Reply #18 – 2026 – 07-01 21:47:00

2. I wel­come at­tempts to fix some out­right er­rors in ffm­peg’s au­dio codec han­dlings, It’s not the only one.

3. Wouldn’t mind if mods fixed the thread ti­tle ei­ther.

Re: FFmpeg 9.1′s new AAC en­coder

Reply #19 — Today at 03:55

With a sim­ple test, the rewrite re­ally does well on high bi­trates which is re­ally im­por­tant (>128kbps). Best part is that the en­coder by de­fault is mono com­pat­i­ble at any bi­trate I’ve tested it with (cough cough Opus hav­ing phase in­ver­sion en­abled by de­fault cough cough). Testing it with worst con­di­tions how­ever at 64kbps with forced 16khz cut­off, the Fraunhofer AAC en­coder seems to still sound bet­ter than the rewrite when it comes to low bi­trates. It tended to sound more metal­lic at 64kbps, and the snares for one song I tested re­ally sounded metal­lic for the new AAC en­coder while it sounded cleaner with fd­k_aac:

ffm­peg_new.exe -i “02. Porter Robinson - Cheerleader.flac” -vn -ab 64k -cutoff 16000 “cheerleader-64k-16khz-newaac.m4a”ffmpeg.exe -i “02. Porter Robinson - Cheerleader.flac” -vn -ab 64k -cutoff 16000 -c:a libfd­k_aac “cheerleader-64k-16khz-fdkaac.m4a

(also I was gonna say that the 18khz cut­off for 128kbps is too high but it seems that you’ve al­ready fig­ured that out)

Last Edit: Today at 04:25 by notcharldeon

Today I’m kick­ing off my most am­bi­tious Maker’s Pet pro­ject yet: oom­woo, an open-source home ro­bot vac­uum that you can build your­self. Open hard­ware, open firmware, open soft­ware — and built in pub­lic, from the first com­mit.

No cloud re­quired. No ven­dor lock-in. It maps your home with an af­ford­able 2D LiDAR and nav­i­gates on its own, runs lo­cally, and in­te­grates na­tively with Home Assistant. If you’re into Raspberry Pi, ROS 2, 3D print­ing, or just the idea of own­ing a vac­uum you fully un­der­stand and con­trol — this one’s for you.

About the name: “oomwoo” is a ro­ta­tional am­bi­gram — it reads the same flipped 180°, just like the ro­bot it­self roam­ing your floor in every di­rec­tion.

What oom­woo is

oom­woo is a build-it-your­self ro­bot vac­uum de­signed for the maker com­mu­nity:

Affordable and fully open — hard­ware, soft­ware, and firmware

2D LiDAR map­ping and au­tonomous nav­i­ga­tion with ROS 2 / Nav2

Native Home Assistant in­te­gra­tion for lo­cal con­trol

3D-printable, doc­u­mented, hack­able chas­sis

Local-first — no cloud needed for every­day clean­ing, ever

Home-appliance qual­ity — not a throw­away build

Step-by-step, zero-to-hero build in­struc­tions, with a com­plete bill of ma­te­ri­als so you can source every part your­self

Optional ex­tras — cloud fea­tures, and even­tu­ally an app store of ROS 2 apps to cus­tomize how your vac­uum be­haves — will layer on top. But the core promise never changes: the vac­uum al­ways works cloud-free and lo­cal, out of the box.

Where the pro­ject is to­day

This is gen­uinely early — and that’s the point of build­ing in pub­lic. The first mile­stone (v0) is a bare-bones, work­ing build:

3D-printed chas­sis

ROS 2 Gazebo sim­u­la­tion

LiDAR with man­ual SLAM

ROS 2 on a Raspberry Pi 5 and/​or ESP32 run­ning mi­cro-ROS (final ar­chi­tec­ture still be­ing de­cided)

The open-source de­liv­er­ables I’m work­ing to­ward: bill of ma­te­ri­als, 3D-printable files, ROS 2 pack­ages, firmware, a mo­tor-dri­ver and sen­sor PCB, full build / bringup / trou­bleshoot­ing docs, and demo videos.

Build it with me — mas­sively in par­al­lel

oom­woo is or­ga­nized so the com­mu­nity can build it in par­al­lel. The ro­bot and its soft­ware are split into self-con­tained mod­ules. You pick what­ever mod­ule in­ter­ests you, work on it when­ever you want, and sub­mit your work as a pull re­quest. Multiple peo­ple can tackle the same mod­ule — the best so­lu­tion sur­faces over time.

Modules ready to start right now in­clude:

ROS 2 URDF + Gazebo sim­u­la­tion — ro­bot model, TF, bumper, sim

First clean — cov­er­age clean­ing while SLAM-mapping and ex­plor­ing

Dust bin — de­sign, 3D print, and test

Vacuum fan / blower as­sem­bly — blower mo­tor, im­peller, vo­lute hous­ing

If you’d like to jump in, the GitHub repo has the mod­ule list, the ar­chi­tec­ture doc, and con­tri­bu­tion guide­lines.

Follow along

I’ll be shar­ing progress, dead ends, and wins as they hap­pen:

GitHub: github.com/​mak­er­spet/​oom­woo — code, docs, and dis­cus­sions

Discord: join the build chat

YouTube: build-in-pub­lic chan­nel

Reddit: r/​Ar­duinoAn­dRo­bot­ics

X: @0OMWO0

Follow OOMWOO build

Open-source ro­bot vac­uum com­mu­nity build up­dates

Parts Kit

Everything about oom­woo stays open — you can source every part your­self. If you’d rather skip the parts hunt, a con­ve­nience kit (motors, PCB, brushes, gas­kets, LiDAR) will be avail­able here at Maker’s Pet, from the same maker be­hind this pro­ject. The kit is a con­ve­nience, never a re­quire­ment.

More oom­woo: re­pos & tu­to­ri­als

Main pro­ject (RFCs, BOM, de­sign docs): github.com/​mak­er­spet/​oom­woo

oom­woo-one — first model, ROS 2 + Gazebo sim­u­la­tion: github.com/​mak­er­spet/​oom­woo-one

oom­woo-in­stall — ROS 2 / Docker dev en­vi­ron­ment: github.com/​mak­er­spet/​oom­woo-in­stall

Tutorial: How to source the BOM for oom­woo

I get asked fairly of­ten what peo­ple need to know to be hire­able as a graph­ics pro­gram­mer. I fig­ured it was time to make a page to link in­stead of re-typ­ing it each time.

We are in a strange time with LLMs. I think ML as it is right now won’t live up to the hype, and the pen­du­lum will swing away from ML a bit over the next cou­ple years. I think the grifters will move onto quan­tum com­put­ing next or find some other thing to pump and dump. However, ML it­self does have a place in the com­puter sci­ence tool box, so learn­ing about the fit­ting and op­ti­miza­tion tech­niques it of­fers is valu­able IMO. I made a video you can watch to learn about the bare metal bits, but it’s up to you if you think it’s worth while to learn or not.

Machine Learning For Game Developershttps://www.youtube.com/​watch?v=sTAqWR­sEiy0

Besides that:

Modern ren­der­ing is sort of like two jobs in one.

Learning the CPU side — Learning DirectX12, Vulkan, Metal, or sim­i­lar mod­ern “explicit” APIs and the en­gine pro­gram­ming to sup­port load­ing as­sets and other sup­port­ing tasks.

Learning the GPU side — the math­e­mat­ics of mod­ern light­ing and shad­ing, ren­der­ing tech­niques like shad­ows, am­bi­ent oc­clu­sion, and post pro­cess­ing ef­fects. Also un­der­stand­ing what is fast and what is slow on the GPU, to know how to make things that run bet­ter in real time.

It’s very dif­fi­cult to learn both things at once. If you want to fo­cus on #2, then you could use a sim­pler thing for #1, such as opengl, we­bgl, DirectX11, an en­gine, or sim­i­lar. If you want to fo­cus on #1, you should work un­til you get a first tri­an­gle up on the screen, then get a mesh on screen, and so on, but don’t worry about it be­ing very pretty.

Part of #2 is writ­ing a path tracer.  Path trac­ing is how movies do ren­der­ing, and it is what we try to ap­prox­i­mate with mod­ern real time ren­der­ing tech­niques. A great place to start with a path tracer is this free book on­line “Ray Tracing in One Weekend”. A lot of peo­ple have used it. It’s re­ally ap­proach­able and shows you how to make photo re­al­is­tic ren­der­ings.https://​ray­trac­ing.github.io/​books/​Ray­TracingI­nOne­Week­end.html

Another part of #2 is learn­ing “Physically based ren­der­ing” or PBR, which is a way of ap­ply­ing light­ing (mainly spec­u­lar, when it comes down to it). PBR is “principled,” mean­ing if you stick to the rules, you get good re­sults.  Before PBR, peo­ple wrote ran­dom equa­tions for light­ing with all sorts of ran­dom tweaks and hacks. It made it so you could make an as­set that looked good in one sit­u­a­tion, but chang­ing the light­ing would make it look too dark or would look like it was glow­ing.  People had to make dif­fer­ent ver­sions of the as­sets for dif­fer­ent light­ing con­di­tions, which was a lot of time and ef­fort.

PBR lets your as­sets look bet­ter in all light­ing con­di­tions by de­fault, and saves the time and ef­fort of hav­ing to make dif­fer­ent ver­sions. It was a big win for our in­dus­try. Even so, as­set cre­ation time, money and ef­fort is still a big bot­tle­neck in game de­vel­op­ment.

The PBR sec­tion (and sub­sec­tions) on this page are a great in­tro to PBR:https://​learnopengl.com/​PBR/​The­ory

If at some point you out­grow that and want to go deeper, read­ing the Filament doc­u­men­ta­tion is a good next step. lots of cal­cu­lus and sta­tis­tics as you go deeper into PBR:https://​google.github.io/​fil­a­ment/​Fil­a­ment.md.html

Beyond that is the fa­mous PBRT book “Physically Based Rendering: From Theory To Implementation” which is also free on­line:https://​pbrt.org/

Ideally you’ll end up with some source code you can share with prospec­tive em­ploy­ers (like on github, linked to on your re­sume) to show as proof that you know these things. Something like:

Something that looks vaguely like an en­gine in that it loads as­sets (models, tex­tures) and ren­ders them on the screen in real time, with light­ing and a cou­ple ef­fects (shadows, depth of field, area lights, tone map­ping, ray traced shad­ows, what­ever). Preferably lit us­ing PBR, with a user con­trol­lable cam­era, and is writ­ten us­ing DX12, vulkan or sim­i­lar, and in C++.

A path tracer that gen­er­ates a photo re­al­is­tic im­age. Preferably in C++, but it could be a pro­gram with­out a win­dow that just writes a png as out­put, it does­n’t have to be real time.

Bonus points if the path tracer is just a sep­a­rate mode of your “engine-like ren­derer” and you use it to help ver­ify that your real time PBR ren­der­ing is cor­rect, by show­ing that it matches path traced re­sults. Extra bonus points if you point out where the two ren­der­ings don’t match, you can ex­plain why they don’t match, and have thoughts on what you could im­ple­ment in your real time ren­derer to make them match more closely while still stay­ing real time.

You might won­der what math you need to know. If you do the above items, you will en­counter the math you need to know but ba­si­cally lin­ear al­ge­bra (matrix mul­ti­pli­ca­tion, cross prod­uct, dot prod­uct), ba­sic trigonom­e­try, and a lit­tle bit of cal­cu­lus is re­ally all you NEED. The fun thing about graph­ics (and game de­vel­op­ment in gen­eral), is that while the amount of math you need is fairly min­i­mal, the amount of math you can use is es­sen­tially un­bounded.

The same is true al­go­rith­mi­cally. You should know the ba­sic ab­stract data types and al­go­rithms such as linked lists, hash ta­bles, sort­ing and search­ing. Often times, the fastest al­go­rithms are the sim­plest. An ar­ray is far faster than a linked list. However, know­ing more ad­vanced al­go­rith­mic con­cepts can help you when you re­ally do need some­thing novel and cus­tom.

In game de­vel­op­ment, C++ is the lan­guage to learn. Some peo­ple use rust, and it’s hard to tell if rust use is grow­ing or not, but it does have a slice of the pie, while not be­ing the stan­dard lan­guage that peo­ple ex­pect you to know. WebGPU has a lot of ca­pa­bil­i­ties that WebGL did not have, and it’s be­com­ing more of a se­ri­ous plat­form, which lets you work in javascript to do the CPU side of the work. I haven’t seen a lot of WebGPU jobs posted though, and I don’t see a lot of WebGPU con­tent on the web. Knowing C++ seems to be the thing to learn, by far, for CPU side pro­gram­ming.

For shader lan­guages, hlsl seems most com­mon, but some peo­ple work in glsl. The shaders are of­ten tran­spiled to other shader lan­guages in multi plat­form games.

I’ll keep this page up­dated as things change or as peo­ple ask ques­tions not cov­ered here.

Extended ML Commentary Regarding Agents:I don’t be­lieve cur­rent ML tech­nol­ogy is “up to task” for most of the things they are sell­ing it’s use on. I do get use out of it by talk­ing to Claude about math, pa­pers, or un­fa­mil­iar al­go­rithms. It’s easy to see if it’s mak­ing things up or not in those sit­u­a­tions, and it’s easy to check other sources for san­ity checks. I do not find it very use­ful for pro­gram­ming how­ever be­cause even when it does what it’s sup­posed to do, I don’t un­der­stand the code with­out tak­ing the time to un­der­stand it. At that point, I should have just writ­ten it. There are some smaller things I find use­ful, such as “do you see any bugs in this file?” which ei­ther re­turns yes and i can in­ves­ti­gate, or re­turns no, and it cost me noth­ing to ask. These tech­ni­cal things aside, I do be­lieve that at some point hu­man­ity will fig­ure out how to make ac­tual hu­man level ar­ti­fi­cial in­tel­li­gence and then go be­yond that. I don’t know if that will hap­pen in my life­time, but I do be­lieve it will hap­pen some day, un­less we de­stroy our­selves first. In that way, this age of LLMs is sort of like a dress re­hearsal for when “the real stuff” comes later on. I hope we learn the right lessons and are more pre­pared when it comes.

A sweep­ing global re­view led by re­searchers at the University of British Columbia has found that mRNA vac­cines—now ad­min­is­tered bil­lions of times world­wide—are safe and highly ef­fec­tive at pre­vent­ing in­fec­tious dis­eases like COVID-19, and have po­ten­tial ap­pli­ca­tions for a range of other dis­eases, in­clud­ing in­fluenza, RSV, can­cer and au­toim­mune dis­or­ders.

Published to­day in The Lancet, the re­view draws on lab­o­ra­tory sci­ence, clin­i­cal tri­als and real-world ef­fec­tive­ness data to pro­vide one of the most com­pre­hen­sive as­sess­ments of mRNA vac­cines to date. It spans the full vac­cine life­cy­cle, from de­sign and man­u­fac­tur­ing to real-world per­for­mance and mon­i­tor­ing.

By bring­ing this ev­i­dence to­gether in a sin­gle re­source, the re­searchers aim to sup­port health­care providers, pol­i­cy­mak­ers and the pub­lic with clear, ev­i­dence-based in­for­ma­tion as new mRNA vac­cines and ther­a­pies are de­vel­oped.

“After bil­lions of doses, we now have an ex­tra­or­di­nary amount of sci­en­tific ev­i­dence,” said lead au­thor Dr. Anna Blakney, as­sis­tant pro­fes­sor at UBC’s Michael Smith Laboratories and School of Biomedical Engineering. “This re­view af­firms that mRNA vac­cines are a safe and highly ef­fec­tive plat­form, sup­ported by rig­or­ous test­ing and real-world mon­i­tor­ing. It pro­vides an ev­i­dence-based foun­da­tion as this tech­nol­ogy con­tin­ues to ex­pand into new ar­eas of med­i­cine.”

Building trust through ev­i­dence

The re­searchers em­pha­size that, like all vac­cines, mRNA vac­cines can have side ef­fects. They found that se­ri­ous ad­verse events—such as my­ocardi­tis, which oc­curs more fre­quently in younger males—are rare and con­sis­tently out­weighed by the vac­ci­nes’ pro­tec­tion against se­vere ill­ness, hos­pi­tal­iza­tion and death.

The find­ings con­firm that mRNA vac­cines pro­vide strong pro­tec­tion against in­fec­tious dis­eases, in­clud­ing se­vere COVID-19, across a wide range of groups, in­clud­ing chil­dren, preg­nant peo­ple and those who are im­muno­com­pro­mised. Booster doses were found to ex­tend and strengthen that pro­tec­tion over time, and reg­u­lar up­dates to the vac­cine for­mu­la­tion main­tained ef­fi­cacy as new vari­ants emerged.

“With any new vac­cine or med­i­cine, it is im­por­tant that we clearly and trans­par­ently com­mu­ni­cate the safety data and rig­or­ous test­ing that sup­ports their use,” said co-au­thor Dr. Manish Sadarangani, pro­fes­sor of pe­di­atrics at UBC and di­rec­tor of the Vaccine Evaluation Center at BC Children’s Hospital Research Institute. “This is es­sen­tial to build­ing pub­lic trust, coun­ter­ing mis­in­for­ma­tion and sup­port­ing in­formed de­ci­sions about vac­ci­na­tion.”

The re­view ad­dresses per­sis­tent mis­con­cep­tions about how mRNA vac­cines work, clar­i­fy­ing that they do not al­ter a per­son’s DNA. Instead, the mRNA—en­cap­su­lated in a lipid nanopar­ti­cle de­liv­ery sys­tem pi­o­neered by UBC re­searchers—pro­vides tem­po­rary in­struc­tions that al­low hu­man cells to pro­duce a harm­less piece of a virus, train­ing the im­mune sys­tem to re­spond. Both the mRNA and lipid nanopar­ti­cles are quickly bro­ken down and cleared from the body af­ter use.

A plat­form for the fu­ture of med­i­cine

Beyond COVID-19, the find­ings point to a rapidly ex­pand­ing fu­ture for mRNA tech­nol­ogy. Researchers are al­ready de­vel­op­ing vac­cines for dis­eases such as in­fluenza and RSV, as well as per­son­al­ized can­cer vac­cines and other RNA-based ther­a­pies.

“This is re­ally about what comes next,” said Dr. Blakney. “We’re see­ing the same plat­form be­ing ap­plied to can­cer treat­ment and other dis­eases. Understanding how these vac­cines work—and why they’re safe—helps build con­fi­dence in the next gen­er­a­tion of med­i­cines.”

The au­thors high­light the im­por­tance of trust, ac­cess and eq­uity. While mRNA vac­cines have proven highly ef­fec­tive, global up­take has been un­even, shaped in part by mis­in­for­ma­tion and his­tor­i­cal pub­lic mis­trust in health sys­tems.

Rather than dis­miss­ing vac­cine hes­i­tancy, the re­searchers ar­gue it should be met with bet­ter com­mu­ni­ca­tion and ac­ces­si­ble, ev­i­dence-based in­for­ma­tion.

“People should feel em­pow­ered to ask ques­tions about their health and what they put in their bod­ies,” said Dr. Blakney. “Our goal is to pro­vide clear, cred­i­ble ev­i­dence to in­form these con­ver­sa­tions and de­ci­sions.”

Expanding ac­cess will also be crit­i­cal to re­al­iz­ing the full po­ten­tial of mRNA tech­nol­ogy. The re­view calls for in­creased in­vest­ment in man­u­fac­tur­ing ca­pac­ity, par­tic­u­larly in low- and mid­dle-in­come coun­tries, as well as con­tin­ued in­no­va­tion to im­prove stor­age, dis­tri­b­u­tion and cost.

“mRNA vac­cines have al­ready changed how we re­spond to global health threats,” said Dr. Sadarangani. “With sus­tained in­no­va­tion, strong safety mon­i­tor­ing and a com­mit­ment to eq­ui­table ac­cess, they can play a ma­jor role in pre­vent­ing dis­ease and im­prov­ing health.”

This study was sup­ported by salary awards from the Canada Research Chairs pro­gram, Michael Smith Health Research BC, and the BC Children’s Hospital Foundation.

Interview lan­guage(s): English.

Featured Researcher

Prof. Anna Blakney, PhD

Assistant Professor, Michael Smith Laboratories and School of Biomedical Engineering

This browser ver­sion is no longer sup­ported. Please up­grade to a sup­ported browser.

rmayrhofer: Leaving Google

Tab

Sign in

Someone left a com­ment on my blog re­cently ask­ing if I’d mind mak­ing my lan­guage more in­clu­sive. They did­n’t get some of the cul­tural ref­er­ences I’d used and sug­gested it would be eas­ier if I used tropes which were more glob­ally known.

Here’s the thing. No.

All my blog posts start with a sim­ple de­c­la­ra­tion:

HTML<!doctype html> <html lang=en-GB>

There’s a rea­son for that. It is more than the lan­guage I speak; it is the cul­ture I live in, the way that I think, and the ac­cent I use.

When your AI bot reads this text aloud, it should do so with a British ac­cent0. That’s how I speak. It is OK to hear a slightly un­fa­mil­iar ac­cent. You’ll be able to fig­ure out what I’m say­ing. Your world won’t col­lapse if I don’t start each sen­tence with “Howdy, y’all!”

But what should you do if you come across a con­cept you don’t un­der­stand?

When The Wicked Witch of the TERFs re­leased the first Harry Potter book “Philosopher’s Stone”, it was pub­lished in the USA with a dif­fer­ent ti­tle; “Sorcerer’s Stone”. There were also a dozen other lan­guage changes - which caused great con­ster­na­tion in the fan­dom.

What do you think hap­pens if Skip or Madison come across a kid eat­ing “a sher­bet lemon” or a de­scrip­tion of Hermione’s “fringe” or dis­cover Harry wear­ing a jumper? Will their lit­tle minds col­lapse un­der the knowl­edge that peo­ple far away use dif­fer­ent words?

No. And nei­ther will you.

It is OK if things are un­fa­mil­iar to you.

Up un­til my mid-twen­ties, I had never seen or eaten a Twinkie. They were a cul­tural lode­stone in a hun­dred books and films, but not the sort of thing I could buy lo­cally. So I used my con­text clues. They seemed like an un­ap­peal­ing food­stuff which, nev­er­the­less, were in­ex­plic­a­bly pop­u­lar.

As a kid, I could re­cite all the lyrics to Vanilla Ice’s Ice Ice Baby with­out get­ting half the ref­er­ences. The brain is mal­leable and can fit in new con­cepts with rel­a­tive ease.

So if you see a ref­er­ence to Count Duckula, or hear me ex­claim “Accrington Stanley!”, or even blush as I de­scribe an ut­ter wanker - please take it as a sign that the hege­mony is not uni­ver­sal and some peo­ple ex­ist in a cul­tural mi­lieu dif­fer­ent to your own.

And breathe. It’ll be OK.

OK, ac­cents are a whole can of worms. Regional English is var­ied. I’m not sure if there are any BCP-style tags for in­tra-coun­try ac­cents. ↩︎

OK, ac­cents are a whole can of worms. Regional English is var­ied. I’m not sure if there are any BCP-style tags for in­tra-coun­try ac­cents. ↩︎