Update May 21: GitHub has now linked this breach to the TanStack npm sup­ply-chain at­tack and says the em­ployee in­stalled a ma­li­cious ver­sion of the Nx Console ex­ten­sion.

GitHub has con­firmed that roughly 3,800 in­ter­nal repos­i­to­ries were breached af­ter one of its em­ploy­ees in­stalled a ma­li­cious VS Code ex­ten­sion.

The com­pany has since re­moved the un­named tro­janized ex­ten­sion from the VS Code mar­ket­place and has se­cured the com­pro­mised de­vice.

“Yesterday we de­tected and con­tained a com­pro­mise of an em­ployee de­vice in­volv­ing a poi­soned VS Code ex­ten­sion. We re­moved the ma­li­cious ex­ten­sion ver­sion, iso­lated the end­point, and be­gan in­ci­dent re­sponse im­me­di­ately,” the com­pany said.

“Our cur­rent as­sess­ment is that the ac­tiv­ity in­volved ex­fil­tra­tion of GitHub-internal repos­i­to­ries only. The at­tack­er’s cur­rent claims of ~3,800 repos­i­to­ries are di­rec­tion­ally con­sis­tent with our in­ves­ti­ga­tion so far.”

This comes af­ter GitHub told BleepingComputer on Tuesday evening that it was in­ves­ti­gat­ing claims of unau­tho­rized ac­cess to its in­ter­nal repos­i­to­ries and added that it has no ev­i­dence that cus­tomer data stored out­side the af­fected re­pos has been af­fected.

While GitHub has yet to at­tribute the breach, the TeamPCP hacker group claimed ac­cess to GitHub source code and “~4,000 re­pos of pri­vate code” on the Breached cy­ber­crime fo­rum on Tuesday, ask­ing for at least $50,000 for the stolen data.

“As al­ways this is not a ran­som, We do not care about ex­tort­ing Github, 1 buyer and we shred the data on our end, it looks like our re­tire­ment is soon so if no buyer is found we will leak it free,” the cy­ber­crim­i­nals said. “If you are in­ter­ested. Send your of­fers to the com­mu­ni­ca­tions be­low, we are not in­ter­ested in un­der 50k, the best of­fer will get it.”

​TeamPCP was pre­vi­ously linked to mas­sive sup­ply chain at­tacks tar­get­ing de­vel­oper code plat­forms, in­clud­ing GitHub, PyPI, NPM, and Docker, and, more re­cently, to the “Mini Shai-Hulud” sup­ply chain cam­paign(which also im­pacted two OpenAI em­ploy­ees).

​VS Code ex­ten­sions are plu­g­ins that can be in­stalled from the VS Code Marketplace (the of­fi­cial store for add-ons for Microsoft’s code ed­i­tor) to add fea­tures or in­te­grate tools into the ed­i­tor.

This is­n’t the first time a tro­janized VS Code ex­ten­sion has been spot­ted on the mar­ket­place, as mul­ti­ple other ma­li­cious ex­ten­sions with mil­lions of in­stalls have been used to steal de­vel­oper cre­den­tials and other sen­si­tive data over the last sev­eral years.

For in­stance, last year, VSCode ex­ten­sions with 9 mil­lion in­stalls were pulled over se­cu­rity risks, and 10 more, pos­ing as le­git­i­mate de­vel­op­ment tools, in­fected users with the XMRig cryp­tominer.

Later in the year, a ma­li­cious ex­ten­sion with ba­sic ran­somware ca­pa­bil­i­ties snuck onto the VS Code mar­ket­place af­ter a threat ac­tor named WhiteCobra flooded it with 24 crypto-steal­ing ex­ten­sions.

More re­cently, in January, two ma­li­cious ex­ten­sions ad­ver­tised as AI-based cod­ing as­sis­tants with 1.5 mil­lion in­stalls ex­fil­trated data from com­pro­mised de­vel­oper sys­tems to servers in China.

GitHub’s cloud-based plat­form is now used by over 4 mil­lion or­ga­ni­za­tions (including 90% of the Fortune 100) and more than 180 mil­lion de­vel­op­ers who con­tribute to over 420 mil­lion code repos­i­to­ries.

The Validation Gap: Automated Pentesting Answers One Question. You Need Six.

Automated pen­test­ing tools de­liver real value, but they were built to an­swer one ques­tion: can an at­tacker move through the net­work? They were not built to test whether your con­trols block threats, your de­tec­tion rules fire, or your cloud con­figs hold.

This guide cov­ers the 6 sur­faces you ac­tu­ally need to val­i­date.

Download Now

FIRE plain­tiff Larry Bushart and his wife Leanne.

NASHVILLE, May 20, 2026 — After spend­ing 37 days in jail for noth­ing more than post­ing a meme, re­tired Tennessee law en­force­ment of­fi­cer Larry Bushart has won a sub­stan­tial set­tle­ment from the county and sher­iff be­hind his ar­rest.

Represented by the Foundation for Individual Rights and Expression and Phillips & Phillips, PLLC, Larry Bushart filed a fed­eral civil rights law­suit last December against Sheriff Nick Weems, Investigator Jason Morrow, and Perry County, Tennessee, for vi­o­lat­ing his con­sti­tu­tional rights in re­tal­i­a­tion for his pro­tected speech.

Today, the par­ties an­nounced in a joint state­ment that Larry will re­ceive $835,000 in ex­change for dis­miss­ing his com­plaint.

“I am pleased my First Amendment rights have been vin­di­cated,” said Larry. “The peo­ple’s free­dom to par­tic­i­pate in civil dis­course is cru­cial to a healthy democ­racy. I am look­ing for­ward to mov­ing on and spend­ing time with my fam­ily.”

After the September 2025 as­sas­si­na­tion of con­ser­v­a­tive ac­tivist Charlie Kirk, Larry com­mented on a Facebook post pro­mot­ing a vigil in nearby Perry County by shar­ing a meme that ac­cu­rately quoted Donald Trump’s state­ment af­ter a school shoot­ing:  “We have to get over it.”

That meme — which Larry did­n’t cre­ate or al­ter — in­cluded a ref­er­ence to the 2024 school shoot­ing at Perry High School in Perry, Iowa. But that did not stop Weems from seek­ing and ob­tain­ing a war­rant for Larry’s ar­rest, based on the ab­surd no­tion that the meme could be in­ter­preted as a threat against Perry County High School in Tennessee. Video of the ar­rest shows Larry in­formed the ar­rest­ing of­fi­cer (not a de­fen­dant in the case) that he had never made a threat.

“No one should be hauled off to jail in the dark of night over a harm­less meme just be­cause the au­thor­i­ties dis­agree with its mes­sage,” said FIRE se­nior at­tor­ney Adam Steinbaugh. “We’re pleased that Larry has been com­pen­sated for this in­jus­tice, but lo­cal law en­force­ment never should have forced him to en­dure this or­deal in the first place.”

COURTESY PHOTOS OF LARRY FOR MEDIA USE

Weems ad­mit­ted in a later in­ter­view that he knew at the time of the ar­rest that Larry’s Facebook post was a pre-ex­ist­ing meme that re­ferred to an ac­tual shoot­ing that took place in a dif­fer­ent state, over 500 miles away. But Weems and Morrow left out that ex­tremely im­por­tant con­text from their war­rant ap­pli­ca­tion. Not that it should have mat­tered; the Supreme Court has long held that heated po­lit­i­cal rhetoric is fully pro­tected by the First Amendment.

Larry spent over a month be­hind bars on a $2 mil­lion bond. Perry County re­leased him from jail only af­ter his plight went vi­ral na­tion­wide and prompted out­rage. During his stay in jail, Larry lost his post-re­tire­ment job and missed his an­niver­sary — as well as the birth of his grand­child. After his re­lease, he teamed up with FIRE to hold those who vi­o­lated his con­sti­tu­tional rights ac­count­able.

Larry was just one of hun­dreds of Americans cen­sored for on­line speech af­ter Kirk’s as­sas­si­na­tion. Elsewhere in Tennessee, FIRE also rep­re­sents Mon­ica Meeks, a life­long pub­lic ser­vant who the state fired solely for a Facebook post crit­i­ciz­ing Kirk. And ear­lier this year, Austin Peay State University settled a law­suit filed by a pro­fes­sor fired sim­ply for cit­ing Kirk’s own words on gun vi­o­lence.

“It’s in times of tur­moil and height­ened ten­sions that our na­tional com­mit­ment to free speech is tested the most,” said FIRE staff at­tor­ney Cary Davis. “When gov­ern­ment of­fi­cials fail that test, the Constitution ex­ists to hold them ac­count­able. Our hope is that Larry’s set­tle­ment sends a mes­sage to law en­force­ment across the coun­try: Respect the First Amendment to­day, or be pre­pared to pay the price to­mor­row.”

The Foundation for Individual Rights and Expression (FIRE) is a non­par­ti­san, non­profit or­ga­ni­za­tion ded­i­cated to de­fend­ing and sus­tain­ing the in­di­vid­ual rights of all Americans to free speech and free thought — the most es­sen­tial qual­i­ties of lib­erty. FIRE ed­u­cates Americans about the im­por­tance of these in­alien­able rights, pro­motes a cul­ture of re­spect for these rights, and pro­vides the means to pre­serve them.

CONTACT:Alex Griswold, Communications Campaign Manager, FIRE: 215 – 717-3473; me­dia@fire.org

In Yesterday’s IO Keynote Google de­clared war on the rem­nants of the Web. (See longer de­scrip­tion on their web­site.) TL;DR: They are push­ing Search more into the “here’s your processed an­swer” di­rec­tion that “AI Overviews” have es­tab­lished (you know, those AI snip­pets in cur­rent Search that are wrong about 10% of the time). So they are mostly giv­ing up on the par­a­digm of pro­vid­ing links to in­for­ma­tion.

While they pack­aged it as a lot of “AI” talk and “agentic” and what­not, what their whole ap­proach of de­con­tex­tu­al­iz­ing in­for­ma­tion, of tak­ing away links to sources and in­stead pro­duc­ing some LLM gen­er­ated re­sponse means is that they want to es­tab­lish a new ab­strac­tion layer on the web. Where Zuckerberg with his Metaverse failed Google is start­ing the next at­tack: Your web­site, your work no longer mat­ters. The web is be­ing fully hid­den be­hind a Google-controlled sur­face. And I am not even talk­ing about their browser mo­nop­oly.

Your work, your writ­ing or art do mat­ter a bit still: As (unpaid) raw ma­te­r­ial for their syn­thetic text ex­trud­ers. You get to work for free so Google can have tight con­trol on the flow of in­for­ma­tion and make sure that the re­sponses peo­ple get are in line with what they need them to be. But your work is no longer seen as an im­por­tant cul­tural ar­ti­fact you can share with oth­ers.

This is a lit­eral rev­o­lu­tion but one against the par­tic­i­pa­tory web, against us: The goal is to take away the web and guide peo­ple into Google’s ab­strac­tion on top of it. An ab­strac­tion they con­trol and mod­er­ate. It’s about mo­nop­o­liz­ing ac­cess to in­for­ma­tion. A true Metaverse un­bound by open stan­dards and your abil­ity to build your own cor­ner of the web ac­cord­ing to your needs and de­sires. Which — given how strong Google’s in­flu­ence is on web stan­dards — will change the shape of the stan­dards for the tech­no­log­i­cal land­scape we are build­ing the web on.

The next step will be Google or other com­pa­nies in that space de­vel­op­ing and de­ploy­ing a new deroga­tory term for the web mark­ing it as un­clean, un­ruly, dan­ger­ous, bad (similar to “the Dark Web”) and mak­ing their ab­strac­tion the “safe” web.

If you do care about the web, about peo­ple’s abil­ity to par­tic­i­pate in it as more than mere pas­sive con­sumers, this needs to be taken se­ri­ously. De-googlifying your men­tal ap­pa­ra­tus be­comes more ur­gent to­day. Find other search en­gines, don’t use the Chrome browser. Or wake up in a slop­i­fied AOL kind of en­vi­ron­ment where your ac­cess to in­for­ma­tion is lim­ited to what Google’s syn­thetic text ex­trud­ers deem rel­e­vant.

Liked it? Take a sec­ond to sup­port tante on Patreon!

This work is li­censed un­der a Creative Commons Attribution-ShareAlike 4.0 International License.

Railway Service Disruption

Major Outage

Dashboard (railway.com)Login - GitHubLogin - GoogleDNSTrafficBuild Machines (GCP)Image Registry (GCP)TCP Proxy (GCP)Southeast Asia (GCP / Singapore)US East (GCP / Virginia, USA)US West (GCP / Oregon, USA)EU West (GCP / Amsterdam, Netherlands)EU West (GCP / Amsterdam, Netherlands)US West (GCP / Oregon, USA)US East (GCP / Virginia, USA)Southeast Asia (GCP / Singapore)TCP Proxy (Metal)US East (Metal / Virginia, USA)Southeast Asia (Metal / Singapore)EU West (Metal / Amsterdam, Netherlands)US West (Metal / California, USA)MetricsLogsSoutheast Asia (Metal / Singapore)US East (Metal / Virginia, USA)US West (Metal / California, USA)EU West (Metal / Amsterdam, Netherlands)Build Machines (Metal)Image Registry (Metal)Central Station (station.railway.com)

May 20, 07:57 UTC

Earlier up­dates

Monitoring

Railway ser­vices have fully re­cov­ered. Some work­loads may still need a re­de­ploy, we’re au­to­mat­i­cally re­de­ploy­ing any we de­tect as un­healthy. If your ser­vice is­n’t re­spond­ing cor­rectly, please trig­ger a re­de­ploy from the dash­board or CLI.We’re sorry for the dis­rup­tion. A de­tailed post­mortem will fol­low once we’ve con­firmed sta­bil­ity.

May 20, 06:14 UTC

May 20, 04:58 UTC

Identified

More work­loads are com­ing back on­line. Some users may still ex­pe­ri­ence in­ter­mit­tent is­sues dur­ing the re­cov­ery. Non-enterprise de­ploys re­main paused; en­ter­prise de­ploys are un­af­fected.

May 20, 03:05 UTC

Identified

We are see­ing grad­ual re­cov­ery on Railway metal work­loads. To en­sure things re­main sta­ble as we ramp back up, we are tem­porar­ily throt­tling all non-en­ter­prise builds to avoid over­whelm­ing our build in­fra­struc­ture.

May 20, 01:41 UTC

Identified

We have re­cov­ered our com­pute on Google Cloud, but ser­vices are un­able to start be­cause of on­go­ing net­work­ing is­sues on Google Cloud’s side. We are en­gaged with Google Cloud sup­port to re­solve this and will post the next up­date as soon as we have more to share.

May 20, 01:34 UTC

Identified

We are con­tin­u­ing to work on restor­ing ac­cess to our work­loads on Google Cloud. In par­al­lel, our in­fra­struc­ture team is eval­u­at­ing al­ter­na­tive paths to bring af­fected ser­vices back on­line. We do not have an ETA at this time and will con­tinue post­ing up­dates as we have them.

May 20, 01:23 UTC

Identified

We are work­ing to re­store the Google Cloud in­fra­struc­ture that pow­ers our dash­board, API, and in­ter­nal net­work’s con­trol plane. We are in di­rect con­tact with Google Cloud’s sup­port team. We do not have an ETA at this time.

May 20, 00:37 UTC

Identified

Google Cloud has blocked our ac­count, mak­ing some Railway ser­vices un­avail­able. We have es­ca­lated this di­rectly with Google.The Railway Platform team has since con­firmed ac­cess to Google Cloud and is work­ing on restor­ing ac­cess to all work­loads. We have ac­cess to some of our Google Cloud–hosted in­fra­struc­ture and are work­ing to re­store the rest of the ser­vice. We apol­o­gize for the dis­rup­tion.

May 19, 23:37 UTC

Identified

We have iden­ti­fied the cause of the dis­rup­tion. Access to our up­stream cloud provider has been re­stored and we are work­ing on a fix.The Railway dash­board and ser­vices run­ning on our cloud in­fra­struc­ture may con­tinue to be af­fected un­til the fix is de­ployed.

May 19, 22:43 UTC

Investigating

We are in­ves­ti­gat­ing a wide­spread ser­vice dis­rup­tion af­fect­ing Railway. Users may be ex­pe­ri­enc­ing er­rors in­clud­ing “no healthy up­stream”, “unconditional drop over­load”, lo­gin fail­ures, and in­abil­ity to ac­cess the dash­board. We are ac­tively in­ves­ti­gat­ing and will pro­vide up­dates as soon as pos­si­ble.

May 19, 22:29 UTC

Every lo­cal-LLM bench­mark re­ports through­put: “47 tok/​s on an M3,” “180 tok/​s on a 4090,” “500 tok/​s on Groq.” Unless you’ve ac­tu­ally watched to­kens stream at those rates, the num­bers are hard to in­ter­nal­ize. This is the ren­der­ing.

Four modes

code — syn­tax-high­lighted pseudo-code, the most com­mon thing you watch stream out of an LLM.

text — lorem ip­sum prose, for the chat/​an­swer case.

think — dim-italic rea­son­ing sen­tences al­ter­nat­ing with code, mim­ic­k­ing a rea­son­ing model think­ing out loud.

agent — al­ter­nat­ing tool calls and code gen­er­a­tion with pro­cess­ing pauses, sim­u­lat­ing an AI cod­ing agent.

What to try

Start at the de­fault 30 and read along. Then hit 1 (5 tok/​s — Raspberry-Pi-class lo­cal model), 5 (60 tok/​s — typ­i­cal hosted Claude or GPT), 7 (200 tok/​s — Groq ter­ri­tory), 9 (800 tok/​s — Cerebras-class, where the bot­tle­neck is your eye­balls).

Now switch be­tween c and t at the same rate. The dif­fer­ence is strik­ing — and in­ten­tional.

What counts as a to­ken

This ap­prox­i­mates BPE-style to­k­eniza­tion, not any ven­dor-spe­cific en­coder (tiktoken, Claude’s to­k­enizer, etc. — those dis­agree in the de­tails any­way).

Short words are of­ten one to­ken; longer iden­ti­fiers split into chunks (processUserInput → process + User + Input); punc­tu­a­tion and op­er­a­tors usu­ally count too.

Code is more to­ken-dense than prose, so the same tok/​s can feel very dif­fer­ent de­pend­ing on what’s stream­ing. The bench­mark num­ber is hon­est; the per­cep­tual ef­fect varies a lot by con­tent type — which is the gap this tool ex­ists to ex­pose.

English prose av­er­ages ~1.3 to­kens per word, so 30 tok/​s ≈ 23 words/​s.

To al­low for eq­ui­table ac­cess to all users, SEC re­serves the right to limit re­quests orig­i­nat­ing from un­de­clared au­to­mated tools. Your re­quest has been iden­ti­fied as part of a net­work of au­to­mated tools out­side of the ac­cept­able pol­icy and will be man­aged un­til ac­tion is taken to de­clare your traf­fic.

Please de­clare your traf­fic by up­dat­ing your user agent to in­clude com­pany spe­cific in­for­ma­tion.

For best prac­tices on ef­fi­ciently down­load­ing in­for­ma­tion from SEC.gov, in­clud­ing the lat­est EDGAR fil­ings, visit sec.gov/​de­vel­oper. You can also sign up for email up­dates on the SEC open data pro­gram, in­clud­ing best prac­tices that make it more ef­fi­cient to down­load data, and SEC.gov en­hance­ments that may im­pact scripted down­load­ing processes. For more in­for­ma­tion, con­tact open­data@sec.gov.

For more in­for­ma­tion, please see the SEC’s Web Site Privacy and Security Policy. Thank you for your in­ter­est in the U.S. Securities and Exchange Commission.

Reference ID: 0.aa24c317.1779371612.53b2f99c

More Information

Internet Security Policy

By us­ing this site, you are agree­ing to se­cu­rity mon­i­tor­ing and au­dit­ing. For se­cu­rity pur­poses, and to en­sure that the pub­lic ser­vice re­mains avail­able to users, this gov­ern­ment com­puter sys­tem em­ploys pro­grams to mon­i­tor net­work traf­fic to iden­tify unau­tho­rized at­tempts to up­load or change in­for­ma­tion or to oth­er­wise cause dam­age, in­clud­ing at­tempts to deny ser­vice to users.

Unauthorized at­tempts to up­load in­for­ma­tion and/​or change in­for­ma­tion on any por­tion of this site are strictly pro­hib­ited and are sub­ject to pros­e­cu­tion un­der the Computer Fraud and Abuse Act of 1986 and the National Information Infrastructure Protection Act of 1996 (see Title 18 U.S.C. §§ 1001 and 1030).

To en­sure our web­site per­forms well for all users, the SEC mon­i­tors the fre­quency of re­quests for SEC.gov con­tent to en­sure au­to­mated searches do not im­pact the abil­ity of oth­ers to ac­cess SEC.gov con­tent. We re­serve the right to block IP ad­dresses that sub­mit ex­ces­sive re­quests. Current guide­lines limit users to a to­tal of no more than 10 re­quests per sec­ond, re­gard­less of the num­ber of ma­chines used to sub­mit re­quests.

If a user or ap­pli­ca­tion sub­mits more than 10 re­quests per sec­ond, fur­ther re­quests from the IP ad­dress(es) may be lim­ited for a brief pe­riod. Once the rate of re­quests has dropped be­low the thresh­old for 10 min­utes, the user may re­sume ac­cess­ing con­tent on SEC.gov. This SEC prac­tice is de­signed to limit ex­ces­sive au­to­mated searches on SEC.gov and is not in­tended or ex­pected to im­pact in­di­vid­u­als brows­ing the SEC.gov web­site.

Note that this pol­icy may change as the SEC man­ages SEC.gov to en­sure that the web­site per­forms ef­fi­ciently and re­mains avail­able to all users.

Note: We do not of­fer tech­ni­cal sup­port for de­vel­op­ing or de­bug­ging scripted down­load­ing processes.

We’re fi­nally ready to talk about Flipper One — a pro­ject we’ve been grind­ing on for years and have re­built from scratch sev­eral times. It’s an in­cred­i­bly hard pro­ject, both fi­nan­cially and tech­ni­cally. So to­day we’re go­ing pub­lic not with a big shiny an­nounce­ment, but to tell the whole story straight. Honestly? We’re gen­uinely ter­ri­fied, and we need your help.

TL;DR With Flipper One, we’re reimag­in­ing what a Linux cy­berdeck can be — it’s a huge pro­ject. We’re open­ing up the de­vel­op­ment process and ask­ing the com­mu­nity for help.

With Flipper One, we’ve set our­selves a list of am­bi­tious goals:

Build the most open and best-doc­u­mented ARM com­puter in the world, with full main­line Linux ker­nel sup­port.

Push ven­dors to open up their ex­ist­ing closed-source code and ditch bi­nary blobs en­tirely.

Build an un­con­ven­tional hard­ware plat­form based on a co-proces­sor ar­chi­tec­ture that pairs a mi­cro­con­troller with a CPU, and port tons of low-level MCU code.

Rethink how peo­ple use Linux and de­velop our own GUI frame­work with wrap­pers around ex­ist­ing CLI util­i­ties.

Many of these goals come with a lot of un­cer­tainty, which is scary. But we be­lieve this is the only way to make a truly mean­ing­ful con­tri­bu­tion to the open-source com­mu­nity and to ed­u­ca­tion.

What is Flipper One?

Flipper One is­n’t an up­grade to Flipper Zero — it’s a com­pletely dif­fer­ent pro­ject with its own goals. Flipper One is an open Linux plat­form you can build al­most any­thing on: from a 5G-enabled IP net­work an­a­lyzer to an SDR-powered ra­dio sig­nal an­a­lyzer with lo­cal AI. We fo­cused a lot on the hard­ware ex­pan­sion sys­tem. You can con­nect high-speed mod­ules to Flipper One over PCI Express, USB 3.0, and SATA in­ter­faces. Add an SDR, a fast SSD, or a cel­lu­lar mo­dem — just plug in the right mod­ule.

Flipper One comes with sev­eral net­work in­ter­faces: 2x Gigabit Ethernet, USB Ethernet (5 Gbps), and Wi-Fi 6E (2.4/5/6 GHz). You can add 5G con­nec­tiv­ity by plug­ging in an M.2 mo­dem. That means you can use Flipper One as a router, a VPN gate­way, or a bridge be­tween wired and wire­less net­works.

Zero vs One

Flipper Zero and Flipper One are com­pletely dif­fer­ent pro­jects built for dif­fer­ent tasks. The eas­i­est way to think about it is in terms of net­work­ing lay­ers:

Layer 0 — Offline point-to-point ac­cess-con­trol pro­to­cols: NFC, low-fre­quency RFID, Sub-1 GHz ra­dio, Infrared, wired pro­to­cols like iBut­ton, UART, SPI, I²C. Based on a low-power mi­cro­con­troller.

Layer 1 — Everything that’s IP-connected: Wi-Fi, Ethernet, 5G, and satel­lite. It’s all about net­work­ing, data trans­fer, and high-per­for­mance com­put­ing. Running on pow­er­ful hard­ware and an open Linux toolkit — enough com­put­ing power to han­dle SDR and lo­cal AI.

So they’re not “newer” and “older” gen­er­a­tions of the same prod­uct. Flipper One does­n’t re­place Flipper Zero — they’re dif­fer­ent cat­e­gories of de­vices.

Truly Open Linux plat­form

We want to build a truly open Linux hard­ware plat­form — the best-doc­u­mented ARM com­puter, one that works out of the box on any re­cent up­stream ker­nel. It will never go stale be­cause it’ll keep get­ting the lat­est up­dates. Our goals:

Full main­line Linux ker­nel sup­port

No bi­nary blobs, closed dri­vers, or pro­pri­etary firmware

No ven­dor-locked BSP (board sup­port pack­age)

We say “truly open” be­cause the cur­rent state of ARM Linux is de­press­ing. Every ven­dor bolts on their own cus­tom mess: closed boot blobs, ven­dor-spe­cific patches, “board sup­port pack­ages” that no­body out­side the chip maker can re­ally un­der­stand. You can no longer just read the specs and un­der­stand how com­put­ers work — you can only learn the workarounds for one spe­cific chip with one spe­cific BSP. We’re sick of this our­selves, and we don’t want to be part of the prob­lem by ship­ping yet an­other prod­uct that just adds to the mess.

To pull this off, we’ve part­nered with the Collabora team to push full sup­port for the Rockchip RK3576 SoC into the main­line Linux ker­nel. Practically, this means you can down­load the ker­nel di­rectly from ker­nel.org, with zero ven­dor patches, and run it on your Flipper One.

👩‍👩‍👧‍👦

Flipper + Collabora — Making things open to­gether We’ve part­nered with Collabora to bring the RK3576 SoC into the main­line ker­nel and give Flipper One full up­stream sup­port.Read more: Collabora blog post

Current RK3576 main­line sup­port is in pretty good shape, and all the ma­jor com­po­nents are work­ing. But there’s still one last bi­nary blob in the boot chain — the DDR trainer, which ini­tial­izes RAM dur­ing early boot.

We’re ask­ing the com­mu­nity to help us pol­ish RK3576 sup­port so we can build a truly open plat­form to­gether. We’d be glad for any kind of con­tri­bu­tion, not just code. For ex­am­ple, maybe you can find a way to con­vince Rockchip to open up that last blob.

Right now, we’re fo­cused on power man­age­ment and USB DP Alt-mode sup­port. There are also dri­vers and ac­cel­er­a­tors that aren’t fully up­stream yet — the NPU, hard­ware video de­cod­ing, and other ac­cel­er­a­tors. Collabora main­tains a pub­lic list of what’s al­ready work­ing in main­line and what is­n’t, and we’d love help clos­ing those gaps.

RK3576 open source roadmap — what we plan to do and how you can con­tribute

Open tasks — where you can help us

RK3576 main­line sta­tus from Collabora

Developer Portal — let’s build to­gether

Openness has al­ways been our thing. With Flipper One, we want to go fur­ther — not just open-source code, but an open de­vel­op­ment process. We’re pub­lish­ing our task track­ers, in­ter­nal dis­cus­sions, half-fin­ished docs, and ar­chi­tec­tural de­bates. All the messy stuff com­pa­nies usu­ally keep be­hind closed doors.

Introducing → Flipper One Developer Portal

This is un­com­fort­able. We’ve never been this open be­fore, and there’s a real in­stinct to hide the un­fin­ished work, the wrong turns, and the ar­gu­ments. But we be­lieve the ed­u­ca­tional value of build­ing openly is worth more than the pol­ish of pre­tend­ing it was easy.

What is the Developer Portal?

Flipper One Developer Portal is a pub­lic wiki with all the de­vel­op­ment doc­u­men­ta­tion for Flipper One, and any­one can edit it. The por­tal de­scribes the pro­jec­t’s struc­ture and ways you can par­tic­i­pate in de­vel­op­ment.

Flipper One is a mas­sive pro­ject, and sev­eral teams are work­ing on it, each re­spon­si­ble for its own part. We call these parts sub-pro­jects:

🔌 Hardware — elec­tri­cal hard­ware de­vel­op­ment. This is where the printed cir­cuit boards (PCBs), an­ten­nas, and every­thing re­lated to the elec­tri­cal con­nec­tions of chips, con­nec­tors, and proces­sors are de­signed.

⚙️ Mechanics — me­chan­i­cal en­gi­neer­ing and in­dus­trial de­sign. This is where the en­clo­sure, but­tons, plas­tic and metal parts, and mount­ing com­po­nents are de­signed. Everything the user phys­i­cally in­ter­acts with.

🐧 Linux (CPU Software) — soft­ware de­vel­op­ment for the RK3576 proces­sor. Linux ker­nel, mod­ules, dri­vers, user­space, boot­loader, Rockchip tools, etc. This is the largest and most com­plex sub-pro­ject, span­ning many repos­i­to­ries.

🕹️ MCU Firmware — firmware de­vel­op­ment for the RP2350 mi­cro­con­troller, which con­trols the dis­play, power sub­sys­tem, and CPU boot process, and han­dles but­ton and touch­pad events.

🎨 User Interface — UI/UX de­vel­op­ment. This is where the user in­ter­face, the de­vice’s vi­sual lan­guage, and all graph­ics are de­vel­oped.

📚 Docs — de­vel­oper por­tal wiki, tech­ni­cal docs, guides, and datasheets. All doc­u­men­ta­tion, in­clud­ing the Developer Portal it­self, is de­vel­oped here. It cov­ers the Flipper One prod­uct, de­vel­op­ment processes, and con­tri­bu­tion guides.

🧪 Testing — tools for test­ing de­vice sub­sys­tems and hard­ware val­i­da­tion. Includes scripts and pro­grams for test­ing power, net­work­ing, CPU, au­dio, graph­ics, etc., as well as in­ter­face pro­to­types, demos, and test apps.

Anyone can join

Whether you’re an en­gi­neer, soft­ware de­vel­oper, de­signer, or sim­ply an en­thu­si­as­tic user with ideas to share, you’re wel­come to par­tic­i­pate in de­vel­op­ment and help shape Flipper One.

We’re also hir­ing a Developer Portal Manager — some­one to act as a proxy be­tween our dev team and the com­mu­nity, help shape the Developer Portal, and en­gage with con­trib­u­tors. Apply for the Developer Portal & Community Manager role.

Co-processor ar­chi­tec­ture

Flipper One runs on two proces­sors: a high-per­for­mance CPU and a tiny low-power MCU. They run in par­al­lel, and each man­ages its own part:

High-performance CPU — the 8-core RK3576 SoC that runs Linux. It comes with a Mali-G52 GPU and an NPU for run­ning LLMs and other mod­els lo­cally. There’s also 8 GB of RAM on board. Read more in CPU Software.

Low-power MCU — the 2-core Raspberry Pi RP2350 mi­cro­con­troller that con­trols the dis­play, but­tons, touch­pad, LEDs, and the power sub­sys­tem. It runs its own MCU Firmware.

The de­vice can run on the MCU alone. Even when Linux is off, you can con­trol Flipper One with its but­tons and LCD screen, con­fig­ure the boot process — all with­out the main CPU run­ning. This is what’s miss­ing on most SBCs: when Linux is off, the de­vice is dead.

MCU ↔ CPU in­ter­con­nect

The two proces­sors com­mu­ni­cate over a set of in­ter­faces we call the Interconnect: SPI car­ries the frame­buffer to the MCU for dis­play out­put, I²C car­ries com­mands to the MCU and but­ton and touch­pad events back to the CPU, and UART plus a few GPIO lines han­dle CPU boot con­trol. This is a non-triv­ial ar­chi­tec­ture.

We plan to land the dis­play and in­put dri­vers in the Linux ker­nel. We want to do it cleanly, with­out out-of-tree ven­dor hacks. We’d love for the ker­nel com­mu­nity to re­view this de­sign, push back on it, and help us up­stream it the right way.

Flipper OS + FlipCTL

How we’re reimag­in­ing Linux cy­berdecks

I’m a fan of Raspberry Pi and use it in my own pro­jects, in­clud­ing car­ry­ing one around as a travel tac­ti­cal Linux box. A typ­i­cal Raspberry Pi OS (formerly Raspbian OS) work­flow looks like this: to­day it’s a router, to­mor­row it’s a TV box, the day af­ter that it’s a logic an­a­lyzer for a de­bug ses­sion. You in­stall dozens of pack­ages, com­pile some from source, edit sys­tem con­figs, tweak the de­vice tree, patch the ker­nel — and very quickly the sys­tem turns into a mess. There’s no clean way to undo it. Roll back to fac­tory? Doesn’t ex­ist. Every new pro­ject starts with re-flash­ing the SD card.

Even though we’ll be crit­i­ciz­ing Raspberry Pi a lot, we gen­uinely love and re­spect the com­pany. Their prod­ucts in­spired ours in many ways — they make in­cred­i­ble things and have con­tributed mas­sively to the em­bed­ded in­dus­try. And that love is ex­actly why we keep com­par­ing our­selves to them.

What is Flipper OS?

We want to fix this and reimag­ine how peo­ple use Linux on the go. We’re build­ing Flipper OS — a layer on top of a Debian-based sys­tem that in­tro­duces pro­files: full snap­shots of the OS with dif­fer­ent pre­con­fig­ured pack­ages and set­tings. You can boot a pro­file, clone it, break it, in­stall what­ever, and jump back to a clean copy. Or switch to an en­tirely dif­fer­ent pro­file for a dif­fer­ent use case. No more SD card shuf­fling.

Honestly, Flipper OS is an ex­tremely hard pro­ject, and we’re not 100% sure how to ar­chi­tect it yet. We’re pro­to­typ­ing con­cepts, and we want this to be use­ful far be­yond Flipper One — for cy­berdeck builds based on Raspberry Pi, or any portable tac­ti­cal Linux box. If you’ve thought about this prob­lem or built some­thing sim­i­lar, we’d love to hear from you. Read about the Flipper OS con­cept.

FlipCTL — a UI frame­work for tiny screens

As part of Flipper OS, we’re build­ing FlipCTL to solve a prob­lem com­mon to all Linux-based cy­berdecks: no­body de­signs UIs for small screens. So peo­ple end up run­ning full desk­top en­vi­ron­ments (KDE, GNOME, etc.) squeezed onto a tiny 7″ touch­screen. It’s mis­er­able. What made Flipper Zero great was its user in­ter­face, pur­pose-built for a small LCD. That’s largely what made the de­vice pop­u­lar. We want to bring that ap­proach to Linux multi-tools.

FlipCTL is a frame­work for build­ing menu-based in­ter­faces for small LCD screens, con­trolled by a D-pad and a few but­tons. The idea is to wrap ex­ist­ing Linux util­i­ties like ping, nmap, tracer­oute in a clean, nav­i­ga­ble UI that ac­tu­ally makes sense on a tiny screen. Our long-term goal: make adding an HMI (human-machine in­ter­face) to any em­bed­ded Linux de­vice as easy as run­ning one com­mand: apt in­stall flipctl

Routers, NAS boxes, servers, head­less boards — any­thing you can bolt a small screen onto should be able to use FlipCTL. The idea is sim­ple: get FlipCTL, write a con­fig, and ship a us­able in­ter­face with­out drag­ging in Qt, GNOME, or X11. We’re also plan­ning to re­lease the Flipper One dis­play and a but­ton board as a stand­alone “FlipCTL Control Board” — a pe­riph­eral you can plug into any Linux-based de­vice and in­stantly get a menu-dri­ven in­ter­face. Right now, FlipCTL is still at the con­cept and ar­chi­tec­ture stage, and we’d love any­one in­ter­ested to join in: Read about the FlipCTL con­cept.

M.2 ex­pan­sion mod­ules

The core idea be­hind Flipper One is an ex­pand­able hard­ware plat­form. Anyone can turn it into their own spe­cial­ized multi-tool. That’s why we added sup­port for high-speed M.2 ex­pan­sion mod­ules that in­stall in­side, un­der the back plate.

M.2 is a com­mon name for an ex­pan­sion mod­ule form fac­tor, but it does­n’t de­fine the ac­tual con­nec­tion in­ter­face. Under the hood, M.2 mod­ules can use dif­fer­ent in­ter­faces and come in dif­fer­ent sizes and con­nec­tor types.

We worked hard to make the M.2 port in Flipper One as uni­ver­sal as pos­si­ble, so you can plug in al­most any type of mod­ule — cel­lu­lar or satel­lite modems, SDR mod­ules, AI ac­cel­er­a­tors, SSDs (NVMe or SATA), and Wi-Fi cards via adapters.

M.2 tech specs

We packed the M.2 port with as many in­ter­faces as pos­si­ble and added sup­port for dif­fer­ent mod­ule sizes:

M.2 type: Key-B

Supported sizes: 2242, 3042, 3052 (up to D3 class thick­ness)

Interfaces: PCI Express 2.1 ×1 / USB 3.1 / USB 2.0 / SATA3 / Serial Audio / UART / I2C / SIM card

For the full M.2 port spec­i­fi­ca­tion and pinout, see the doc­u­men­ta­tion: M.2 Port spec­i­fi­ca­tion. We ex­pect the com­mu­nity and ven­dors to build their own M.2 mod­ules for Flipper One, so any feed­back and sug­ges­tions are wel­come.

GPIO mod­ules

For sim­pler DIY mod­ules, we added a GPIO con­nec­tor with stan­dard 2.54mm pin head­ers. Even here, we made sure the de­vice can be car­ried fully as­sem­bled with the mod­ule at­tached with­out it com­ing loose.

GPIO mod­ules also have their own mount­ing sys­tem:

Threaded in­serts — the back plate and an­tenna rail have threads spaced in a grid with 2.54mm pitch, match­ing stan­dard perf­board hole spac­ing. So you can just cut a piece of perf­board to size, sol­der your mod­ule onto it, and screw it to the Flipper One’s back.

Snap-fit notches — both sides of the body have notches for a snap-fit pro­tec­tive cover that adds rigid­ity to the whole as­sem­bly.

For the tech­ni­cal spec­i­fi­ca­tion, pinout, and schemat­ics, see the GPIO port page. You can also check out ex­am­ples of GPIO mod­ules, in­clud­ing a walkie-talkie and a cam­era mod­ule. Any feed­back and com­ments are wel­come.

Open hard­ware mod­ule sys­tem

0:00

/0:07

[video] You can view and down­load the 3D mod­els

We de­signed a cus­tom mount­ing sys­tem for Flipper One mod­ules. We are fully open­ing up the en­clo­sure parts in­volved in this sys­tem:

Body — the main en­clo­sure of the de­vice. M.2 mod­ules screw into a metal heatsink plate, with two threaded in­serts for 42mm and 52mm mod­ule lengths.

Back plate — the rear cover that pro­vides ac­cess to the M.2 ex­pan­sion port. It at­taches to the body with screws and can be swapped out for dif­fer­ent de­signs de­pend­ing on the in­stalled mod­ule.

Antenna rail — a sep­a­rate part used for mount­ing SMA an­ten­nas. The an­tenna rail is in­ten­tion­ally sep­a­rated from the back plate so that an­ten­nas can be in­stalled and ca­bles routed to the ra­dio mod­ule be­fore the back plate is closed. This elim­i­nates the risk of dam­ag­ing an­tenna ca­bles dur­ing as­sem­bly.

You can down­load the 3D mod­els to­day to de­sign en­clo­sures for your mod­ules or even cre­ate your cus­tom back plate and an­tenna rail. We look for­ward to com­mu­nity feed­back and sug­ges­tions on the me­chan­i­cal de­sign of mod­ules. Read about Mechanics.

Network multi-tool

Flipper One is all about con­nec­tiv­ity — a Swiss Army knife for IP net­works across all OSI lay­ers. We packed in all the es­sen­tial phys­i­cal in­ter­faces, giv­ing you five in­de­pen­dent net­work up­links, which you can bridge to­gether, con­fig­ure cus­tom rout­ing for, or pipe through VPN tun­nels:

2× Gigabit Ethernet — two in­de­pen­dent WAN/LAN ports, each run­ning at 1 Gbps. Can be used for trans­par­ent bridge, MitM sniff­ing, and more.

Wi-Fi 6E — 802.11ax based on the MT7921AUN chipset with mon­i­tor mode sup­port. Covers 2.4/5/6 GHz bands and can run as both a Wi-Fi client (STA) and a hotspot (AP).

Cellular mo­dem — 5G or LTE mo­dem via the M.2 ex­pan­sion mod­ule, with sup­port for ex­ter­nal an­ten­nas. Accepts a phys­i­cal Nano SIM (4FF) and eSIM.

USB Ethernet — up to 5 Gbps em­u­lated over USB-C. Connect your lap­top or smart­phone via a USB ca­ble to add an ex­tra net­work in­ter­face. Works via USB-CDC NCM, so no dri­vers are re­quired.

Out of the box, Flipper One can work as a gate­way to any net­work, a multi-hotspot bridge, an in­line Ethernet snif­fer, a USB Wi-Fi/Ethernet adapter for a PC or smart­phone — or any com­bi­na­tion, with dy­namic rout­ing, load bal­anc­ing, and failover. We de­scribe these as user-story-dri­ven fea­tures in the Features list.

Advanced built-in Wi-Fi

A video wall­pa­per en­gine for ma­cOS Tahoe.

Phosphene is a menu bar app + wall­pa­per ex­ten­sion that plays your own video files as the ma­cOS desk­top and lock-screen wall­pa­per. It plugs into the sys­tem’s na­tive wall­pa­per picker, so videos ap­pear along­side Apple’s built-in Aerials in System Settings → Wallpaper.

It is built on top of Apple’s pri­vate WallpaperExtensionKit frame­work — the same one Apple’s own Aerials use — which means play­back runs out-of-process, sur­vives app quits, and in­te­grates with the OS-level lock-screen / idle / sleep life­cy­cle.

⚠️ Private frame­work. Phosphene loads WallpaperExtensionKit via dlopen and uses Mirror-based run­time in­tro­spec­tion to talk to its XPC types. Apple could change this at any ma­jor OS re­lease. The pro­ject tracks ma­cOS 26 (Tahoe).

⚠️ Private frame­work. Phosphene loads WallpaperExtensionKit via dlopen and uses Mirror-based run­time in­tro­spec­tion to talk to its XPC types. Apple could change this at any ma­jor OS re­lease. The pro­ject tracks ma­cOS 26 (Tahoe).

Features

Bring your own videos. Import MP4 / MOV / any AVFoundation-readable file. They show up in the sys­tem wall­pa­per picker.

Gapless loop­ing. Frame-accurate loops by off­set­ting PTS/DTS across loop bound­aries — no flush, no stut­ter.

Multi-display + per-Space se­lec­tions. Different wall­pa­pers per dis­play, per­sisted by ma­cOS.

Power-aware play­back. A grad­u­ated PlaybackPolicy re­duces work or pauses en­tirely based on ther­mal state, bat­tery level, on-bat­tery vs AC, Game Mode, and pre­sen­ta­tion mode (active / locked / idle).

Smooth lock-screen ramp. When Only on Lock Screen is en­abled, the wall­pa­per eases in/​out with a cu­bic curve as you lock and un­lock, match­ing Apple’s own Aerials be­hav­ior.

Pause when oc­cluded. Detects when every dis­play is fully cov­ered by win­dows and pauses ren­der­ing un­til the desk­top is vis­i­ble again.

Adaptive vari­ants. Optionally pre-ren­der lower-res­o­lu­tion / lower-fps vari­ants of a video; the ren­derer swaps to the cheap­est vari­ant that sat­is­fies the cur­rent pol­icy at each loop bound­ary.

Menu bar con­trol. Preview the cur­rent wall­pa­per, tog­gle pause, switch dis­plays, con­fig­ure be­hav­ior, launch at lo­gin.

Requirements

ma­cOS Tahoe (26.0+). Phosphene de­pends on the Wallpaper ex­ten­sion point in­tro­duced in ma­cOS 14 but uses Tahoe-only SwiftUI and glass­Ef­fect() APIs.

Apple Silicon. Targets ar­m64-ap­ple-ma­cos26.0.

Xcode 17+ to build, with Swift 6 strict con­cur­rency en­abled.

Building

git clone https://​github.com/<you>/phosphene cd phosphene open Phosphene.xcodeproj

In Xcode, se­lect the Phosphene scheme and Run. The pro­ject uses syn­chro­nized filesys­tem groups, so adding/​re­mov­ing files in Phosphene/ or PhospheneExtension/ re­quires no pbx­proj ed­its.

You’ll need to set a de­vel­op­ment team for code sign­ing. The wall­pa­per ex­ten­sion is em­bed­ded into the app bun­dle and reg­is­tered with the sys­tem when the app launches.

Using a video wall­pa­per

Launch Phosphene. Use the menu bar icon to Manage Library and add one or more videos.

Open System Settings → Wallpaper. Phosphene’s videos ap­pear un­der their own col­lec­tion.

Pick a video. ma­cOS han­dles the ac­tual wall­pa­per as­sign­ment — Phosphene’s ex­ten­sion pro­vides the frames.

Architecture

┌─────────────────────────┐ ┌──────────────────────────────┐ │ Phosphene.app │ │ PhospheneExtension.appex │ │ (menu bar UI) │ │ (host: WallpaperAgent) │ │ │ │ │ │ • Library man­age­ment │ Darwin │ • XPC han­dler │ │ • Per-video meta­data │ ──────▶ │ • AVSampleBufferDisplayLayer │ │ • Optimization (HEVC) │ no­tif. │ • Power / ther­mal mon­i­tor │ │ • Preferences │ │ • Snapshot gen­er­a­tor │ └─────────────────────────┘ └──────────────────────────────┘ │ │ └──────────────┬───────────────┘ ▼ Shared App Group con­tainer (~/Library/Group Containers/glass.kagerou.phosphene) • Video li­brary + vari­ants • WallpaperPrefs.plist • BMP snap­shot cache

App side (Phosphene/) — SwiftUI menu-bar app. Manages the on-disk video li­brary, transcodes op­tional lower-res­o­lu­tion vari­ants via VideoOptimizationService, ex­poses pref­er­ences, and posts a Darwin no­ti­fi­ca­tion when the li­brary changes.

Extension side (PhospheneExtension/) — runs in­side the sys­tem WallpaperAgent process when a Phosphene wall­pa­per is ac­tive. Loads WallpaperExtensionKit.framework at run­time, reg­is­ters as a wall­pa­per provider, and ren­ders frames into a re­mote CAContext via AVSampleBufferDisplayLayer. It re­ceives XPC ac­quire / up­date / in­val­i­date / snap­shot calls from WallpaperAgent and routes pre­sen­ta­tion-mode changes through PlaybackPolicy.

PlaybackPolicy is the sin­gle source of truth for play­back be­hav­ior. Inputs (thermal state, bat­tery, pre­sen­ta­tion mode, user pause, oc­clu­sion, etc.) col­lapse to one of full / re­duced / min­i­mal / paused. The ren­derer ap­plies the pol­icy on every state change.

VideoRenderer owns the de­code pipeline. Instead of AVPlayerLayer — which silently fails in­side a re­mote CAContext — it dri­ves AVSampleBufferDisplayLayer man­u­ally: one AVAssetReader for the cur­rent loop, a pre­loaded one for the next, and a PTS off­set that grows across loops to keep the time­line mo­not­o­n­i­cally in­creas­ing. Result is glitch-free loop­ing with­out flush­ing the ren­derer.

Quirks worth know­ing

WallpaperSnapshotXPC swiz­zle. The sys­tem’s snap­shot en­coder checks type(of: coder) == NSXPCCoder.self, but the real coder is a sub­class. Without the run­time swiz­zle in PhospheneExtension.swift, snap­shots silently en­code to noth­ing and you get a grey lock screen dur­ing tran­si­tions.

Mirror-based XPC pars­ing. Apple’s re­quest types (WallpaperCreationRequestXPC etc.) aren’t part of any pub­lic SDK header. The ex­ten­sion reads them via Mirror re­flec­tion. If Apple re­names fields, ex­pect sur­gi­cal break­age.

Variants are ad­vi­sory. A “1080p@30” vari­ant won’t be se­lected if Power-Monitor thinks we’re on AC and idle — PlaybackPolicy al­ways picks the high­est tier that’s still al­lowed.

License

MIT. Do what­ever you want, no war­ranty.

Acknowledgements

Built by @kageroumado. Phosphene was orig­i­nally a com­mer­cial pro­ject; it’s open-source now be­cause the mar­ket for “video wall­pa­per apps on ma­cOS” turned out to be more crowded than it looked.