We’ve been search­ing for a mem­ory-safe pro­gram­ming lan­guage to re­place C++ in Ladybird for a while now. We pre­vi­ously ex­plored Swift, but the C++ in­terop never quite got there, and plat­form sup­port out­side the Apple ecosys­tem was lim­ited. Rust is a dif­fer­ent story. The ecosys­tem is far more ma­ture for sys­tems pro­gram­ming, and many of our con­trib­u­tors al­ready know the lan­guage. Going for­ward, we are rewrit­ing parts of Ladybird in Rust.

When we orig­i­nally eval­u­ated Rust back in 2024, we re­jected it be­cause it’s not great at C++ style OOP. The web plat­form ob­ject model in­her­its a lot of 1990s OOP fla­vor, with garbage col­lec­tion, deep in­her­i­tance hi­er­ar­chies, and so on. Rust’s own­er­ship model is not a nat­ural fit for that.

But af­ter an­other year of tread­ing wa­ter, it’s time to make the prag­matic choice. Rust has the ecosys­tem and the safety guar­an­tees we need. Both Firefox and Chromium have al­ready be­gun in­tro­duc­ing Rust into their code­bases, and we think it’s the right choice for Ladybird too.

Our first tar­get was LibJS , Ladybird’s JavaScript en­gine. The lexer, parser, AST, and byte­code gen­er­a­tor are rel­a­tively self-con­tained and have ex­ten­sive test cov­er­age through test262, which made them a nat­ural start­ing point.

I used Claude Code and Codex for the trans­la­tion. This was hu­man-di­rected, not au­tonomous code gen­er­a­tion. I de­cided what to port, in what or­der, and what the Rust code should look like. It was hun­dreds of small prompts, steer­ing the agents where things needed to go. After the ini­tial trans­la­tion, I ran mul­ti­ple passes of ad­ver­sar­ial re­view, ask­ing dif­fer­ent mod­els to an­a­lyze the code for mis­takes and bad pat­terns.

The re­quire­ment from the start was byte-for-byte iden­ti­cal out­put from both pipelines. The re­sult was about 25,000 lines of Rust, and the en­tire port took about two weeks. The same work would have taken me mul­ti­ple months to do by hand. We’ve ver­i­fied that every AST pro­duced by the Rust parser is iden­ti­cal to the C++ one, and all byte­code gen­er­ated by the Rust com­piler is iden­ti­cal to the C++ com­pil­er’s out­put. Zero re­gres­sions across the board:

No per­for­mance re­gres­sions on any of the JS bench­marks we track ei­ther.

Beyond the test suites, I’ve done ex­ten­sive test­ing by brows­ing the web in a lock­step mode where both the C++ and Rust pipelines run si­mul­ta­ne­ously, ver­i­fy­ing that out­put is iden­ti­cal for every piece of JavaScript that flows through them.

If you look at the code, you’ll no­tice it has a strong “translated from C++” vibe. That’s be­cause it is trans­lated from C++. The top pri­or­ity for this first pass is com­pat­i­bil­ity with our C++ pipeline. The Rust code in­ten­tion­ally mim­ics things like the C++ reg­is­ter al­lo­ca­tion pat­terns so that the two com­pil­ers pro­duce iden­ti­cal byte­code. Correctness is a close sec­ond. We know the re­sult is­n’t id­iomatic Rust, and there’s a lot that can be sim­pli­fied once we’re com­fort­able re­tir­ing the C++ pipeline. That cleanup will come in time.

This is not be­com­ing the main fo­cus of the pro­ject. We will con­tinue de­vel­op­ing the en­gine in C++, and port­ing sub­sys­tems to Rust will be a side­track that runs for a long time. New Rust code will co­ex­ist with ex­ist­ing C++ through well-de­fined in­terop bound­aries.

We want to be de­lib­er­ate about which parts get ported and in what or­der, so the port­ing ef­fort is man­aged by the core team. Please co­or­di­nate with us be­fore start­ing any port­ing work so no­body wastes their time on some­thing we can’t merge.

I know this will be a con­tro­ver­sial move, but I be­lieve it’s the right de­ci­sion for Ladybird’s fu­ture. :^)

Brian Merchant, writ­ing for Blood in the Machine, re­ports that peo­ple across the United States are dis­man­tling and de­stroy­ing Flock sur­veil­lance cam­eras, amid ris­ing pub­lic anger that the li­cense plate read­ers aid U. S. im­mi­gra­tion au­thor­i­ties and de­por­ta­tions.

Flock is the Atlanta-based sur­veil­lance startup val­ued at $7.5 bil­lion a year ago and a maker of li­cense plate read­ers. It has faced crit­i­cism for al­low­ing fed­eral au­thor­i­ties ac­cess to its mas­sive net­work of na­tion­wide li­cense plate read­ers and data­bases at a time when U. S. Immigration and Customs Enforcement is in­creas­ingly re­ly­ing on data to raid com­mu­ni­ties as part of the Trump ad­min­is­tra­tion’s im­mi­gra­tion crack­down.

Flock cam­eras al­low au­thor­i­ties to track where peo­ple go and when by tak­ing pho­tos of their li­cense plates from thou­sands of cam­eras lo­cated across the United States. Flock claims it does­n’t share data with ICE di­rectly, but re­ports show that lo­cal po­lice have shared their own ac­cess to Flock cam­eras and its data­bases with fed­eral au­thor­i­ties.

While some com­mu­ni­ties are call­ing on their cities to end their con­tracts with Flock, oth­ers are tak­ing mat­ters into their own hands.

Merchant re­ports in­stances of bro­ken and smashed Flock cam­eras in La Mesa, California, just weeks af­ter the city coun­cil ap­proved the con­tin­u­a­tion of Flock cam­eras de­ployed in the city, de­spite a clear ma­jor­ity of at­ten­dees fa­vor­ing their shut­down. A lo­cal re­port cited strong op­po­si­tion to the sur­veil­lance tech­nol­ogy, with res­i­dents rais­ing pri­vacy con­cerns.

Other cases of van­dal­ism have stretched from California and Connecticut to Illinois and Virginia. In Oregon, six li­cense plate-scan­ning cam­eras on poles were cut down and at least one spray-painted. A note left at the base of the sev­ered poles said, “Hahaha get wrecked ya sur­veilling fucks,” re­ports Merchant.

According to DeFlock, a pro­ject aimed at map­ping li­cense plate read­ers, there are close to 80,000 cam­eras across the United States. Dozens of cities have so far re­jected the use of Flock’s cam­eras, and some po­lice de­part­ments have since blocked fed­eral au­thor­i­ties from us­ing their re­sources.

A Flock spokesper­son did not say, when reached by TechCrunch, if the com­pany keeps track of how many cam­eras have been de­stroyed since be­ing de­ployed.

On Christmas Eve, 9 “peer-reviewed” eco­nom­ics pa­pers were qui­etly re­tracted by Elsevier, the world’s largest aca­d­e­mic pub­lisher.

This in­cludes 7 pa­pers in the International Review of Financial Analysis (a good jour­nal—it has an 18% ac­cep­tance rate):

Plus two more re­trac­tions in Finance Research Letters (29% ac­cep­tance rate):

Two days later, three more pa­pers were re­tracted at the International Review of Economics & Finance (30% ac­cep­tance rate):

All 12 pa­pers had one thing in com­mon: Brian M Lucey, Professor of International Finance and Commodities, Trinity College Dublin — the #1 ranked eco­nom­ics and busi­ness school in Ireland — as a co-au­thor.

Lucey pub­lished 56 pa­pers in 2025, one pa­per every 6.5 days. Lmao.

Lucey has pub­lished 44 pa­pers in Finance Research Letters alone, an Elsevier jour­nal he edited.

I emailed Lucey for com­ment, but he did not re­spond.

Brian Lucey… where have I heard that name be­fore?

Oh yeah, he bul­lied me on Twitter in 2023.

The stated rea­son for the re­trac­tions was that: “review of this sub­mis­sion was over­seen, and the fi­nal de­ci­sion was made, by the Editor Brian Lucey, de­spite his role as a co-au­thor of the man­u­script. This com­pro­mised the ed­i­to­r­ial process and breached the jour­nal’s poli­cies.”

In plain terms, Lucey was serv­ing as ed­i­tor while ap­prov­ing his own pa­pers. The re­sult was a com­plete by­pass of peer re­view—an abuse of ed­i­to­r­ial au­thor­ity that func­tioned as a ci­ta­tion-car­tel scheme.

Apparently this was an open se­cret in the pro­fes­sion for many years, with EJMR com­ments go­ing back 5+ years ex­plic­itly call­ing him out as a cheater:

Along with the 12 re­trac­tions, Lucey was re­moved as an ed­i­tor at 5 jour­nals: International Review of Financial Analysis, the International Review of Economics & Finance, Finance Research Letters, Financial Management, & Energy Finance.

Lucey re­mains as ed­i­tor-in-chief at Wiley’s Journal of Economic Surveys.

I emailed Wiley, and they pro­vided me with this state­ment:

We are aware of these con­cerns and have in­ves­ti­gated Prof. Lucey’s ac­tiv­ity on Journal of Economic Surveys. Our re­search in­tegrity team did not find any con­cerns re­gard­ing con­flict of in­ter­est or mis­han­dling of pa­pers, nor has Prof. Lucey pub­lished any pa­pers in the jour­nal since he joined the ed­i­to­r­ial team as a co-ed­i­tor in 2024. We ex­pect full com­mit­ment and ad­her­ence to our ed­i­to­r­ial prac­tices and stan­dards, and we will be mon­i­tor­ing the sit­u­a­tion to en­sure that there is no im­proper han­dling of pa­pers at the jour­nal.

In re­sponse to Wiley’s state­ment, one EMJR user wrote: “I am baf­fled how they could pos­si­bly still have con­fi­dence in him, given his se­ri­ous and sys­tem­atic eth­i­cal lapses in ed­i­to­r­ial po­si­tions. Sounds some­what naive to ex­pect ‘full ad­her­ence to our ed­i­to­r­ial prac­tices and stan­dards’!”

Until be­ing purged from the lead­er­ship of these 5 jour­nals, Lucey played a cen­tral role in co­or­di­nat­ing Elsevier’s Finance Journals Ecosystem, which al­lows “participating jour­nals to sug­gest trans­fer­ring a re­jected man­u­script to an­other jour­nal in the sys­tem with­out the need for re­sub­mis­sion and the as­so­ci­ated cost.”

That sys­tem, and the ed­i­tors in­volved, “came un­der fire last year when a preprint sug­gested it might fa­cil­i­tate ci­ta­tion stack­ing as a way to boost jour­nal im­pact fac­tors. The analy­sis in the preprint also sug­gested a ci­ta­tion ring in­volv­ing Elsevier ed­i­tors could be at work.”

I emailed the anony­mous “Theophilos Nomos” who wrote this pa­per, but they did not re­spond to my email.

That pre-print names Samuel Vigne, a fi­nance pro­fes­sor at Luiss Business School, for­mer PhD stu­dent of Lucey, and pro­lific Lucey co-au­thor (they have pub­lished at least 33 pa­pers to­gether) as a core node of Lucey’s ci­ta­tion car­tel.

Multiple pub­li­ca­tions by Vigne and Lucey are flagged on PubPeer.

This ex­am­ple neatly il­lus­trates how their co-au­thor­ship trad­ing scheme op­er­ated:

It de­scribes a draft up­loaded to SSRN with three au­thors:

After sub­mit­ting that draft to the Elsevier fi­nance ecosys­tem, that draft was scrubbed from SSRN, and in the fi­nal pub­lished ver­sion, an ad­di­tional au­thor (Samuel Vigne) was added as a new au­thor, with an “equal con­tri­bu­tion” state­ment. The two ver­sions are oth­er­wise iden­ti­cal, con­tain­ing the same fig­ures, sec­tions, and text.

Co-authorship trad­ing is only one part of the op­er­a­tion. The other is ci­ta­tion stack­ing. In this model, a small, tightly linked group fun­nels an enor­mous vol­ume of pa­pers into the same hand­ful of jour­nals, then sys­tem­at­i­cally stuffs those pa­pers with ci­ta­tions to one an­other. The re­sult is a rapid, ar­ti­fi­cial ex­plo­sion in ci­ta­tion counts that makes them look like in­flu­en­tial ge­niuses.

Take John Gooddell, a pro­fes­sor at the University of Akron and a Lucey co-au­thor. Gooddell has pub­lished 68 pa­pers in Finance Research Letters alone, a jour­nal edited by Lucey. If each pa­per con­tains even a mod­est 50 ref­er­ences, that amounts to roughly 3,400 ci­ta­tions re­cy­cled through a sin­gle out­let. In 2024 alone, Gooddell pub­lished 61 pa­pers. He’s not do­ing re­search. He’s farm­ing ci­ta­tions.

Following Lucey’s re­trac­tions, Samuel Vigne was re­moved as the ed­i­tor-in-chief of International Review of Financial Analysis and Finance Research Letters.

In ad­di­tion to that anony­mous pre-print, there is also a 2025 pa­per writ­ten by ac­tual pro­fes­sors with so­phis­ti­cated econo­met­ric analy­sis & graph the­ory which de­scribes the ci­ta­tion car­tel in much more de­tail. The con­clu­sion of that pa­per is: ”Elsevier ecosys­tem jour­nals ben­e­fited from the cre­ation of the ecosys­tem … Elsevier jour­nals in the ecosys­tem have over­lap­ping ed­i­tors and Elsevier ap­points these ed­i­tors in co­or­di­na­tion with a sin­gle aca­d­e­mic [Brian Lucey] that man­ages the fleet of ecosys­tem jour­nals.”

Brian Lucey posted a re­ply to this pa­per, which was ex­tremely weak and does not con­tain any ta­bles or fig­ures. It mostly ig­nores the data and struc­tural model of the ci­ta­tion ring and in­stead leans on Lucey’s “lived ex­pe­ri­ence” as an ed­i­tor (“we have ex­pe­ri­ence shep­herd­ing…”), while also nit­pick­ing se­man­tics and phras­ing, such as Lucey com­plain­ing that they called him a “professor of fi­nance” in­stead of his full hon­orific, “professor of in­ter­na­tional fi­nance and com­modi­ties.”

The Elsevier ecosys­tem web page went live on 4 November 2020 , ac­cord­ing to Lucey’s re­but­tal. Below is a vi­su­al­iza­tion of the net­work be­fore and af­ter this tran­si­tion date, which shows a clear dis­tor­tion of the ci­ta­tion net­work. During 2021-2025, the Ecosystem ci­ta­tions per ar­ti­cle is 103 % higher.

2020 is also the year where Brian Lucey’s ci­ta­tion pro­file ex­hibits an ex­po­nen­tial “J-curve”, a Hallmark of ci­ta­tion rings. Did he sud­denly be­come a well-re­spected ge­nius in 2020? Or did he fig­ure out how to cheat the sys­tem?

In a com­ment to Retraction Watch, Lucey fur­ther ar­gued that ci­ta­tion car­tels are not a crime, be­cause every­one does it.

”Because here’s the thing: Elsevier are aware of [editors pub­lish­ing in their own jour­nals] as a pretty com­mon prac­tice in fi­nance and eco­nom­ics. We’ve given them ev­i­dence of hun­dreds of in­stances of this. And noth­ing has hap­pened, which does raise the ques­tion, you know, maybe they’re go­ing to go back and go look at all these. Presumably, they will treat every­thing the same.” Lucey shared his list of such in­stances. It in­cludes 240 ar­ti­cles, 133 of which are in Science of the Total Environment, which was delisted from Clarivate’s Web of Science in November.

Dr. Thorsten Beck, in a blog post, con­firmed that no, not every­one does it, and yes, it is a crime.

This in­ci­dent raises an im­por­tant ques­tion: is this com­mon prac­tice across aca­d­e­mic jour­nals? And are there rules for ed­i­tors pub­lish­ing in ‘their’ jour­nals? As I was ed­i­tor across three jour­nals for a to­tal of 11 years, I can cer­tainly speak to this (and clearly say NO).I don’t have for­mal con­fir­ma­tion but I have been told by sev­eral in­de­pen­dent sources that ul­ti­mately even Elsevier re­alised that this ed­i­tor was se­ri­ously dam­ag­ing the rep­u­ta­tion of the jour­nal, ap­point­ing a sec­ond ed­i­tor and then eas­ing out the ‘doubtful’ ed­i­tor from his re­spon­si­bil­i­ties.

The fall­out from the Lucey–Vigne era ex­tends far be­yond a hand­ful of re­tracted PDFs. What it ex­poses is a struc­tural weak­ness in how aca­d­e­mic “excellence” is man­u­fac­tured, mea­sured, and mon­e­tized. By pre­sid­ing over a co­or­di­nated clus­ter of jour­nals, a small group of ed­i­tors ef­fec­tively gained the abil­ity to print their own aca­d­e­mic cur­rency.

However, blam­ing Lucey and Vigne alone ig­nores the hand that fed them. Elsevier did not just “allow” this to hap­pen; they en­gi­neered the en­vi­ron­ment for it to flour­ish, be­cause of in­cen­tives: Elsevier’s in­ter­nal met­rics (Impact Factors) di­rectly ben­e­fit­ted from this be­hav­ior. It was a sym­bi­otic cor­rup­tion: the ed­i­tors re­ceived a fast-track to aca­d­e­mic star­dom, and Elsevier re­ceived a high-mar­gin, high-vol­ume pro­duc­tion line of citable con­tent.

This is the “paper mill” reimag­ined for the elite: not a base­ment op­er­a­tion in a third-world na­tion, but a pol­ished, cor­po­rate-man­dated fac­tory within the halls o the world’s most pow­er­ful pub­lisher. This is the nat­ural re­sult of a cor­po­rate man­date to max­i­mize prof­its by bundling jour­nals into mo­nop­oly-priced pack­ages, forc­ing uni­ver­si­ties to pay for the very “prestige” that Elsevier’s own staff helped to di­lute. As one EJMR com­menter noted, “The tragedy is­n’t that they cheated; it’s that the sys­tem was de­signed to let them thrive for a decade be­fore any­one both­ered to look at the data.”

The ques­tion now is whether Trinity College Dublin will fire Lucey.

They did not re­spond to my in­quiry.

An ed­i­tor of a psy­chol­ogy jour­nal was of­fered $1,500 per ac­cepted pa­per.

Richard Tol, a pro­fes­sor of eco­nom­ics at the University of Sussex, wrote that he was of­fered $5,000 per pa­per.

Muhammad Ali Nasir, a pro­fes­sor of Macroeconomics at Leeds University, wrote about how com­mon sell­ing pa­pers is in European fi­nance jour­nals: “I had been made such of­fers from anony­mous emails but I choose not to en­gage and in one case for­warded the email to EiC. I will be sur­prised if any ed­i­tor is not ap­proached by these peo­ple.”

This raises a multi-mil­lion-euro ques­tion: given their doc­u­mented cor­rup­tion, are the var­i­ous “educational con­sul­tan­cies” and spe­cial-pur­pose ve­hi­cles op­er­ated by Brian Lucey and Samuel Vigne used to cir­cu­late ecosys­tem funds, con­fer­ence fees, or “consultancy” pay­outs from au­thors seek­ing a short­cut to pub­li­ca­tion?

Here is a hy­po­thet­i­cal out­line of how such a cash-flow scheme could func­tion.“Hello [unknown, dis­tant in­sti­tu­tions], we of­fer con­sult­ing ser­vices: €€€ for ex­cel­lent ad­vice on how to pub­lish in top-tier fi­nance jour­nals. Our ad­vice yields re­sults.”

I’m not go­ing to pro­vide de­tails on how to cor­ruptly have a pa­per pub­lished. I’m just go­ing to spec­u­late on what could be go­ing on in a sit­u­a­tion like this. It could be based on “consultancy fees” for ad­vice on pub­lish­ing that you or your in­sti­tu­tion pay to one of those com­pa­nies. They give some ad­vice, in­clud­ing what pa­pers to cite, etc, and if you fol­low their ad­vice you are likely to be pub­lished in one of their jour­nals. This could be at­trac­tive for re­searchers and in­sti­tu­tions in, e.g., China and the Middle East.

Another anony­mous eco­nom­ics pro­fes­sor I spoke to told me:

Universities in East and West Asia pay cash bonuses for pub­li­ca­tions. Some au­thors hire a bro­ker (many ad­ver­tise openly on Facebook), other au­thors con­tact the ed­i­tor di­rectly. The cash bonus is shared be­tween the au­thor, bro­ker, and ed­i­tor. Besides sell­ing pa­pers, they also sell spe­cial is­sues, which al­low the guest ed­i­tors to do what they want.And they sell po­si­tions on the ed­i­to­r­ial board, which are im­por­tant for pro­mo­tion to the next aca­d­e­mic rank.Some pay­ments are in cash, oth­ers in kind. Finally, they or­ga­nize con­fer­ences. Registration fees more than cover the costs of putting on a con­fer­ence. The con­fer­ence name sug­gests it is or­ga­nized by a so­ci­ety, but it re­ally is Lucey who pock­ets the prof­its.

Brian Lucey and Samuel Vigne op­er­ate four pri­vate com­pa­nies in Ireland and the UK clas­si­fied un­der “other ed­u­ca­tion,” likely func­tion­ing as con­sul­tan­cies or spe­cial-pur­pose ve­hi­cles for aca­d­e­mic or pol­icy work.

The ex­is­tence of these con­sul­tan­cies war­rants in­ves­ti­ga­tion into po­ten­tial con­flicts of in­ter­est and fi­nan­cial mis­con­duct.

Why are 21st cen­tury prod­ucts still pro­tected with 1950s ma­te­ri­als like ex­panded poly­styrene EPS that per­sist in land­fill for cen­turies? EPS now car­ries com­mer­cial risk through plas­tic taxes and rep­u­ta­tional risk through en­vi­ron­men­tal im­pact. There is a bet­ter way.

Mushroom® Packaging is grown from mycelium and agri­cul­tural by prod­ucts to form a high per­for­mance pro­tec­tive ma­te­r­ial. It matches EPS for strength and cost while elim­i­nat­ing per­sis­tent plas­tic waste. The fin­ished ma­te­r­ial is fully dried and bi­o­log­i­cally in­ac­tive be­fore it leaves our fa­cil­ity, so it will not grow or sprout.

As Europe’s first in­dus­trial scale mycelium pack­ag­ing man­u­fac­turer, MMC proves that sus­tain­abil­ity can op­er­ate at scale and at cost par­ity.

Since 2020 we have pro­duced mil­lions of units, re­mov­ing thou­sands of tonnes of EPS from sup­ply chains. In 2026 alone we will man­u­fac­ture around ten mil­lion more pieces, dis­plac­ing thou­sands of ad­di­tional tonnes.

Leading brands in­clud­ing BA Kitchens, Renais Gin, ICAX Heat Pumps, Tom Dixon, Raymarine and Flextronics trust MMC to pro­tect their prod­ucts and rep­u­ta­tions.

Regulation is tight­en­ing. Customers are de­mand­ing change. Businesses still de­pen­dent on EPS risk be­ing left be­hind.

Wildfire Games, an in­ter­na­tional group of vol­un­teer game de­vel­op­ers, proudly an­nounces the re­lease of 0 A. D. Release 28: “Boiorix”, the twenty-eighth ver­sion of 0 A.D., a free, open-source real-time strat­egy game of an­cient war­fare. The re­lease is named af­ter the king of the Cimbri Germanic tribe Boiorix.

Download and in­stal­la­tion in­struc­tions are avail­able for Windows, Linux, and ma­cOS. 0 A.D. is free soft­ware. This means you can down­load, re­dis­trib­ute, mod­ify and con­tribute to the ap­pli­ca­tion un­der the same li­censes: GNU Public Licence ver­sion 2 (GPL v2) for code and Creative Commons Attribution Share-Alike 3.0 (CC-BY-SA 3.0) for art­work. Although you might find some peo­ple sell­ing copies of 0 A.D., ei­ther over the in­ter­net or on phys­i­cal me­dia, you will al­ways have the op­tion to down­load 0 A.D. com­pletely gratis, di­rectly from the de­vel­op­ers. No “freemium” model, no in-game ad­ver­tis­ing, no catch.

Don’t for­get to de­ac­ti­vate every mod be­fore up­dat­ing the game to avoid any risk of con­flict. If you’re a mod cre­ator, please look at this page on how to port your mod to the new ver­sion. As al­ways, feel free to reach out to us for as­sis­tance.

Now is the time to con­tribute!

The Release 28 is our first re­lease with­out the Alpha la­bel: our de­vel­op­ment process has ma­tured, our re­leases are more fre­quent, and our com­mit­ment to qual­ity has never been higher. Now is the time to join us and place 0 A.D. in the spot­light. We need your help to make the game flour­ish and to bring new fea­tures to life.

As you can see, this re­lease un­for­tu­nately comes with­out a video trailer. It is dif­fi­cult for the cur­rent team to spread the word about our beloved game. We are in sore need of con­trib­u­tors in the fol­low­ing ar­eas:

Of course, we are also al­ways look­ing for, and pro­vid­ing a wel­com­ing con­tri­bu­tion en­vi­ron­ment, for:

Translators (get started right away on Transifex)

and of course, Developers and Artists — the team will gladly wel­come con­tri­bu­tions in all ar­eas.

You can also sup­port us by sim­ply do­nat­ing. This al­lows us to pay the server host­ing fees for our mul­ti­player, web­sites, and de­vel­op­ment en­vi­ron­ments.

Terror Germanicus, the fear of the Germanic tribes mi­grat­ing south, from the Jutland re­gion, to­wards the Roman Republic, is com­ing to 0 A.D. in Release 28.

The Cimbri were a large group of Germanic peo­ples orig­i­nally from the north of mod­ern-day Denmark. In the late 2nd cen­tury BC, their mi­gra­tion south into Italy and France would spark the decade-long Cimbrian War against the Roman Republic. Accompanied by pow­er­ful armies and seer­esses, Germanic con­voys, in long trains of wag­ons, brought live­stock, shel­ter and goods. The Cimbri placed great im­por­tance on an­i­mals for re­li­gious sac­ri­fices.

In 0 A.D., we rep­re­sent the no­madic coali­tion formed be­tween the Cimbri, the Teutones, the Ambrones, and other Celto-German tribes sim­ply as the “Germans”. The Germans are a semi-no­madic civ­i­liza­tion with a flex­i­ble econ­omy ow­ing to Supply Wagons and Wagon Encampments, which can be for­ti­fied. The unique tech­nolo­gies “Wagon Trains” and “Migratory Resettlement” lean into this flex­i­bil­ity, re­duc­ing de­pen­dence on ter­ri­to­r­ial bound­aries. The Germans also fea­ture an ag­gres­sive lineup of siege units, with a crush-deal­ing unit avail­able in each phase. Between their eco­nomic flex­i­bil­ity and unique mil­i­tary units, Cimbrian raiders, Log Rams, and Seeresses, the Germans are a mys­te­ri­ous force to be reck­oned with.

Play with this new fac­tion, against their his­tor­i­cal Roman foes, or turn his­tory around by mak­ing them bat­tle the 14 other fac­tions of the game. Many other nov­el­ties await you in the new re­lease of 0 A.D.!

In an ef­fort to im­prove his­tor­i­cal con­sis­tency, we have re­placed the vi­sual ap­pear­ance of civil­ian units. Previously de­scribed as a “female cit­i­zen”, the ba­sic eco­nomic unit is now called the “civilian” and has male and fe­male mod­els.

This en­hance­ment was made pos­si­ble by in­cre­men­tal im­prove­ments of the en­gine, which now al­lows a unit to have vari­ants not only in its ap­pear­ance, but also in its voice and in other gen­dered char­ac­ter­is­tics.

In the civ­i­liza­tions dis­played in the game, women did not usu­ally hold cit­i­zen­ship, which was a prized so­cial sta­tus. The “female cit­i­zen” was a mis­nomer. It was also in­cor­rect to dis­play all men as sol­diers, and most women as ser­vants. Instead, we want to de­scribe the armies of 0 A.D. as fol­lowed by a group of min­ions of lower so­cial sta­tus, able to sup­port the sol­diers in the army camp, but not on the bat­tle­field. Those are the new Civilians. Citizens, on the other hand, were sol­diers, able to wage war as well as work­ing, which we have al­ways been ac­cu­rately de­scrib­ing in the game with the cit­i­zen-sol­dier con­cept. The am­bi­gu­ity of the term “citizen” is re­moved: this word now only de­scribes cit­i­zen sol­diers.

This change does not touch the bal­ance of the game at all. The so-called “female cit­i­zens” keep all their sta­tis­tics, only their ap­pear­ance and name have changed. The cit­i­zen sol­diers are not touched at all.

In or­der to dis­play text, we used to pre-ren­der fonts and load them into mem­ory when start­ing the game. In or­der to dis­play scripts such as Chinese, we needed to load a large at­las of thou­sands of char­ac­ters into mem­ory, which could over­whelm the play­ers’ RAM. As a con­se­quence, we were forced to pro­vide East Asian lan­guages as mods, which was an ac­ces­si­bil­ity is­sue for non-Eng­lish speak­ing users of these lan­guages.

On top of mem­ory man­age­ment im­prove­ments, we now use the Freetype li­brary in the en­gine to ren­der fonts on the fly when the game runs. Modding the fonts also be­comes far eas­ier with this new fea­ture.

This new ren­der­ing sys­tem also im­proves the text dis­play with GUI scal­ing, for users with Hi-DPI screens or who sim­ply wish to use a larger in­ter­face.

In the fu­ture, we hope to also use this fea­ture to ren­der an­cient scripts, such as hi­ero­glyphs and cuneiform.

New per­son­al­iza­tion op­tions are avail­able in the game setup screen.

You can re­move some play­ers en­tirely (removing all of the ini­tial build­ings and units in their start­ing zone) in Skirmish and Scenario games.

It is also pos­si­ble to set the pop­u­la­tion limit per team:

Lastly, some code refac­tor­ing al­lowed us to fix out­stand­ing bugs in the game setup. For in­stance, in Alpha 27, a re­cur­ring is­sue would cre­ate an un­wanted flood event in games where the user had pre­vi­ously played a flood game. This is­sue has been fixed.

The mul­ti­player lobby re­ceived some qual­ity of life im­prove­ments. Verifying TLS cer­tifi­cates is now en­abled by de­fault when con­nect­ing to the mul­ti­player lobby, re­duc­ing the risk of man-in-the-mid­dle at­tacks. A se­cure con­nec­tion to the lobby will be­come manda­tory in fu­ture re­leases, so please check that TLS en­cryp­tion and cer­tifi­cate ver­i­fi­ca­tion are not dis­abled in your set­tings, and re­port any is­sue you may en­counter.

It is also more straight­for­ward now to host matches, as there is no need to de­cide whether to use STUN or not; and a bug caus­ing freezes when join­ing a match got fixed.

We have de­cided to re­name the main menu en­try for play­ing with friends over LAN or by di­rect IP: now called Multiplayer > Connect by IP, it is still the same sys­tem for di­rect match­mak­ing with­out us­ing the lobby.

In Release 28, we have up­graded the SpiderMonkey JavaScript en­gine to ver­sion 128. This up­grade drops sup­port for Windows 7 and 8.1, and for ma­cOS be­low 10.15. Windows 10 and 11 are now the only sup­ported Windows ver­sions, and we will try our best to keep sup­port­ing Windows 10 as long as pos­si­ble.

Still on Windows, we now pro­vide a long-awaited 64-bit build, which should ad­dress in­fre­quent out-of-mem­ory er­rors. The 64-bit ver­sion will be­come the de­fault one for the next re­lease, and the 32-bit build will even­tu­ally be dep­re­cated in the fu­ture.

On Linux dis­tri­b­u­tions, spe­cial care is al­ways given to re­lease bun­dles for pack­age main­tain­ers, but we also walked the ex­tra mile to pro­vide an AppImage in of­fi­cial re­leases, start­ing with Release 28. We are also work­ing close to­gether with main­tain­ers of the Snap and Flatpak ver­sions, so that you can en­joy the lat­est re­lease as soon as we get it out.

Our con­trib­u­tor manowar has brought gifts for the his­tory nerds among you with a dozen new quotes in the game load screen, and, to­gether with Vantha, they have added new tips for both be­gin­ners and sea­soned play­ers.

Structure, Civil Center, and Fortress de­fault (ungarrisoned) cap­ture re­sis­tance in­creased from 0.5, 5, 10, to 5, 30, and 45, re­spec­tively.

Civilians (formerly Women) given a cap­ture at­tack of 1.0.

Units’ des­ti­na­tions are dis­trib­uted around the end­point, al­low­ing groups to move co­he­sively with­out col­lid­ing and form­ing long lines.

Cataphract Champion Cavalry +2 Hack and Pierce ar­mor, but speed de­creased from 17.1 to 14.4.

3 traders are no longer re­quired for re­search­ing Diaspora.

New civ­i­liza­tion bonus: Stone gath­er­ing store­house tech­nolo­gies are free and in­stant with each phase.

Mercenary refac­tor­ing and dif­fer­en­ti­a­tion. The Celtic em­bassy trains sword cav­alry and in­fantry.The Iberian em­bassy trains unique ranged in­fantry mer­ce­nar­ies. The Italic em­bassy trains spear cav­alry and in­fantry.

Minister econ­omy and build­ing auras in­creased from 2% to 10%, but ranged re­duced from 40 me­ters to 20 me­ters. This is no longer stack­able.

Ministers and Ministry avail­able in vil­lage phase in­stead of town phase.

The full list of changes can be found at the changelog page of the wiki.

After nu­mer­ous con­tri­bu­tions in many ar­eas of the game, es­pe­cially the user in­ter­face and the game sim­u­la­tion, Vantha has joined the team at the be­gin­ning of the prepa­ra­tion of Release 28. We are ex­tremely happy to wel­come him!

If you ex­pe­ri­ence a tech­ni­cal prob­lem with the game, please re­port it at gitea.wild­firegames.com. This is also the first ad­dress to visit when you wish to ded­i­cate some of your time to help patch the code. Got any fur­ther ques­tions or sug­ges­tions? Discuss them with other play­ers and de­vel­op­ers at the fo­rum or talk with us di­rectly in the IRC chat rooms: #0ad and #0ad-dev on QuakeNet.

See our LinkTree. For press/​me­dia in­quiries, please DM play0ad@mastodon.so­cial on Mastodon, or email web­mas­ter at wild­firegames dot com.

Fix wrong value for the Aura of Kush Hero Arakamaniby obelix on February 21, 2026 at 12:16 PM by Atrik on February 21, 2026 at 7:48 AM by Vladislav Belov on February 20, 2026 at 9:46 PM by Vladislav Belov on February 20, 2026 at 9:46 PM by Vladislav Belov on February 20, 2026 at 9:46 PM

Mastodon

My old 2016 MacBook Pro has been col­lect­ing dust in a cab­i­net for some time now. The lap­top suf­fers from a “flexgate” prob­lem, and I don’t have any prac­ti­cal use for it. For quite some time, I’ve been think­ing about re­pur­pos­ing it as a guinea pig, to play with FreeBSD — an OS that I’d as­pired to play with for a long while, but had never had a real rea­son to.

During the re­cent hol­i­day sea­son, right af­ter FreeBSD 15 re­lease, I’ve fi­nally found time to set the lap­top up. Doing that I did­n’t plan, or even think, this may turn into a story about AI cod­ing.

2016 MacBook Pro mod­els use Broadcom BCM4350 Wi-Fi chip. FreeBSD does­n’t have na­tive sup­port for this chip. To have a work­ing Wi-Fi, a typ­i­cal sug­ges­tion on FreeBSD fo­rums, is to run wifi­box — a tiny Linux VM, with the PCI Wi-Fi de­vice in pass through, that al­lows Linux to man­age the de­vice through its br­cmf­mac dri­ver.

Brcmfmac is a Linux dri­ver (ISC li­cence) for set of FullMAC chips from Broadcom. The dri­ver of­floads the pro­cess­ing jobs, like 802.11 frame move­ment, WPA en­cryp­tion and de­cryp­tion, etc, to the firmware, which is run­ning in­side the chip. Meanwhile, the dri­ver and the OS do high-level man­age­ment work (ref Broadcom br­cmf­mac(PCIe) in Linux Wireless doc­u­men­ta­tion).

Say we want to build a na­tive FreeBSD ker­nel mod­ule for the BCM4350 chip. In the­ory, this sep­a­ra­tion of jobs be­tween the firmware and the dri­ver sounds per­fect. The “management” part of work is what FreeBSD al­ready does for other sup­ported Wi-Fi de­vices. We need to port some amount of ex­ist­ing “glue code” from specifics of Linux to FreeBSD. If we ig­nore a lot of de­tails, the prob­lem does­n’t sound too com­pli­cated, right?

A level-zero idea, when one hears about “porting a bunch of ex­ist­ing code from A to B”, in 2026 is, of course, to use AI. So that was what I tried.

I cloned the br­cmf­mac sub­tree, and asked Claude Code to make it work for FreeBSD. FreeBSD al­ready has dri­vers that work through LinuxKPI — com­pat­i­bil­ity layer for run­ning Linux ker­nel dri­vers. So I specif­i­cally pointed Claude at the iwl­wifi dri­ver (a soft­mac dri­ver for Intel wire­less net­work card), ask­ing “do as they did it”. And, at first, this even looked like this can work — Claude told me so.

The mod­ule, in­deed, com­piled, but it did­n’t do any­thing. Because, of course: the VM, where we tested the mod­ule, did­n’t even have the hard­ware. After I set the PCI de­vice into the VM, and at­tempted to load the dri­ver against the chip, the chal­lenges started to pop up im­me­di­ately. The ker­nel pan­iced, and af­ter Claude fixed the pan­ics, it dis­cov­ered that “module did­n’t do any­thing”. Claude hon­estly tried to sift through the code, adding more and more #ifdef __FreeBSD__ wrap­pers here and there. It com­plained about miss­ing fea­tures in LinuxKPI. The mod­ule kept caus­ing pan­ics, and the agent kept build­ing FreeBSD-specific shims and call­backs, while warn­ing me that this pro­ject will be very com­pli­cated and messy.

After a num­ber of ses­sions, the diff, pro­duced by the agent, stared to look sig­nif­i­cantly larger than what I’d hoped it will be. Even worse, the dri­ver did­n’t look even close to be work­ing. This was right around time when Armin Ronacher posted about his ex­pe­ri­ence build­ing a game from scratch with Claude Opus and PI agent.

Besides the part that work­ing in Pi cod­ing agent feels more pro­duc­tive, than in Claude Code, the video got me think­ing that my ap­proach to the task was too straight­for­ward. The code of br­cmf­mac dri­ver is mod­er­ately large. The dri­ver sup­ports sev­eral gen­er­a­tions of Wi-Fi adap­tors, dif­fer­ent ca­pa­bil­i­ties, etc. But my im­me­di­ate task was very nar­row: one chip, only PCI, only Wi-Fi client.

Instead of con­tin­u­ing with the code, I spawned a fresh Pi ses­sion, and asked the agent to write a de­tailed spec­i­fi­ca­tion of how the br­cmf­mac dri­ver works, with the fo­cus on BCM4350 Wi-Fi chip. I ex­plic­itly set the au­di­ence for the spec­i­fi­ca­tion to be read­ers, who are tasked with im­ple­ment­ing the spec­i­fi­ca­tion in a clean-room en­vi­ron­ment. I asked the agent to ex­plain how things work “to the bits”. I added some high-level de­tails for how I wanted the spec­i­fi­ca­tion to be laid out, and let the agent go br­rrr.

After a cou­ple of rounds, the agent pro­duced me a “book of 11 chap­ters”, that hon­estly looked like a fine spec­i­fi­ca­tion

% ls –tree spec/

spec

├── 00-overview.md

├── 01-data-structures.md

├── 02-bus-layer.md

├── 03-protocol-layer.md

├── 04-firmware-interface.md

├── 05-event-handling.md

├── 06-cfg80211-operations.md

├── 07-initialization.md

├── 08-data-path.md

├── 09-firmware-commands.md

└── 10-structures-reference.md

Of course, one can’t just trust what AI has writ­ten.

To proof­read the spec I spawned a clean Pi ses­sions, and — for fun — asked Codex model, to read the spec­i­fi­ca­tion, and flag any places, where the text is­n’t aligned with the dri­ver’s code (“Source code is the ground truth. The spec needs to be ver­i­fied, and up­dated with any miss­ing or wrong de­tails”). The agent fol­lowed through and found sev­eral places to fix, and also pro­posed mul­ti­ple im­prove­ments.

Of course, one can’t just trust what AI has writ­ten, even if this was in a proof­read­ing ses­sion.

To dou­ble-proof­read the fixes I spawned an­other clean Pi ses­sions, ask­ing Opus model to ver­ify if what was pro­posed was aligned with how it works in the code of the dri­ver.

As a pro­cras­ti­na­tion ex­er­cise, I tried this loop with a cou­ple of cod­ing mod­els: Opus 4.5, Opus 4.6, Codex 5.2, Gemini 3 Pro pre­view. So far my ex­pe­ri­ence was that Gemini hal­lu­ci­nated the most. This was quite sad, given that the model it­self is­n’t too bad for sim­ple cod­ing tasks, and it is free for a lim­ited use.

Having a writ­ten spec­i­fi­ca­tion should have (in the­ory) ex­plained how a dri­ver’s code in­ter­acts with the firmware.

I started a fresh pro­ject, with noth­ing but the men­tioned “spec”, and prompted the Pi agent, that we were build­ing a brand new FreeBSD dri­ver for BCM4350 chip. I pointed the agent to the spec­i­fi­ca­tion, and asked it to ask me back about any im­por­tant de­ci­sions we must make, and de­tails we must out­line, be­fore jump­ing into “slopping the code”. The agent came back with ques­tions and de­ci­sion points, like “Will the dri­ver live in the ker­nels source-tree?”, “Will we write the code in C?”, “Will we rely on LinuxKPI?”, “What are our high-level mile­stones?”, etc. One in­flu­en­tial bit, that turned fairly pro­duc­tive mov­ing for­ward, was that I asked the agent to doc­u­ment all these de­ci­sion points in the pro­jec­t’s docs, and to ex­plic­itly ref­er­enced to these de­ci­sion docs in the pro­jec­t’s AGENTS.md.

It’s worth say­ing that, just like in any real pro­ject, not all de­ci­sions stayed to the end. For ex­am­ple,

Initially I asked the agent to build the dri­ver us­ing lin­uxkpi and lin­uxkpi_wlan. My naive think­ing was that, given the spec was writ­ten af­ter look­ing at Linux dri­ver’s code, it might be sim­pler for the agent, than build­ing the on top of the na­tive prim­i­tives. After a cou­ple of ses­sions, it did­n’t look like this was the case. I asked the agent to drop LinuxKPI from the code, and to refac­tor every­thing. The agent did it in one go, and up­dated the de­ci­sion doc­u­ment.

With spec­i­fi­ca­tion, docs and a plan, the work­flow process turned into a “boring rou­tine”. The agent had SSH ac­cess to both the build host, and a test­ing VM, that had been run­ning with the Wi-Fi PCI de­vice passed from the host. It me­thod­i­cally crunched through the back­log of its own mile­stones, it­er­at­ing over the code, build­ing and test­ing the mod­ule. Every time a mile­stone or a por­tion was fin­ished, I asked the agent to record the progress to the docs. Occasionally, an it­er­a­tion of the code crashed or hanged the VM. When this hap­pened, be­fore fix­ing the prob­lem, I asked — in a forked Pi’s ses­sion — to sum­ma­rize, in­ves­ti­gate and record the prob­lem for agen­t’s fu­ture-self.

After many low-in­volved ses­sions, I got a work­ing FreeBSD ker­nel mod­ule for the BCM4350 Wi-Fi chip. The mod­ule sup­ports Wi-Fi net­work scan­ning, 2.4GHz/5GHz con­nec­tiv­ity, WPA/WPA2 au­then­ti­ca­tion.

The source code is in repos­i­tory github.com/​narqo/​freebsd-br­cmf­mac. I did­n’t write any piece of code there. There are sev­eral known is­sues, which I will task the agent to re­solve, even­tu­ally. Meanwhile, I strongly ad­vise against us­ing it for any­thing be­yond a study­ing ex­er­cise.

The link you clicked leads to a Base64 en­coded string.

To de­code it, you can use:

Skip to con­tent­Feb­ru­ary Updates 🌸The largest col­lec­tion of free stuff on the in­ter­net!Learn how to block ads, track­ers and other nasty things. Explore the world of AI and ma­chine learn­ing.Stream, down­load, tor­rent and binge all your favourite movies and shows!Stream, down­load and tor­rent songs, pod­casts and more!Down­load and play all your favourite games or em­u­late some old but gold ones!Whether you’re a book­worm, otaku or comic book fan, you’ll be able to find your favourite pieces of lit­er­a­ture here!Down­load all your favourite soft­ware, movies, shows, mu­sic, games and more!Down­load your favourite me­dia us­ing the BitTorrent pro­to­col.All forms of con­tent for Android and iOS.Con­tent in lan­guages other than English.Various top­ics like food, travel, news, shop­ping, fun sites and more!

Catch bugs be­fore they make it to pro­duc­tion

Usage Guide

The Las Vegas Metropolitan Police Department (LVMPD) qui­etly en­tered an agree­ment in 2023 with Flock Security, an au­to­mated li­cense plate reader com­pany that uses cam­eras to col­lect ve­hi­cle in­for­ma­tion and cross-ref­er­ence it with po­lice data­bases.

But un­like many of the other po­lice de­part­ments around the coun­try that use the cam­eras in their po­lice work, Metro funds the pro­ject with donor money fun­neled into a pri­vate foun­da­tion. It’s an arrange­ment that al­lows Metro to avoid so­lic­it­ing pub­lic com­ment on the sur­veil­lance tech­nol­ogy, which crit­ics worry could be co-opted to track un­doc­u­mented im­mi­grants, po­lit­i­cal dis­si­dents and abor­tion seek­ers, among oth­ers.

“It’s a short cir­cuit of the de­mo­c­ra­tic process,” Jay Stanley, a Washington D. C.-based lawyer for the American Civil Liberties Union (ACLU) who works on how tech­nol­ogy can in­fringe on in­di­vid­ual pri­vacy and civil lib­er­ties, said in an in­ter­view with The Nevada Independent.

The cam­eras scan li­cense plates as well as ve­hi­cles’ iden­ti­fy­ing de­tails — such as make, model and color — plug­ging that in­for­ma­tion into a na­tional data­base that po­lice can use to search the lo­ca­tion of spe­cific ve­hi­cles be­yond their own ju­ris­dic­tions. Flock op­er­ates more than 80,000 of these AI-powered cam­eras na­tion­wide, and the com­pa­ny’s pop­u­lar­ity has ex­ploded in re­cent years, with po­lice tout­ing it as a tool to solve crime faster and boost pub­lic safety.

Although tax­payer dol­lars fund Flock cam­eras in other ju­ris­dic­tions, most of the cam­eras in the Las Vegas area have been bought with money from the Horowitz Family Foundation, a phil­an­thropy group con­nected to the Las Vegas-based ven­ture cap­i­tal­ist Ben Horowitz, co-founder of the firm Andreessen Horowitz.

The Horowitz Family Foundation did not re­spond to a re­quest for com­ment at the time of pub­li­ca­tion.

Metro told The Nevada Independent that it op­er­ates ap­prox­i­mately 200 Flock li­cense plate reader cam­eras on city or county in­fra­struc­ture and it shares its Flock data with hun­dreds of state and lo­cal law en­force­ment agen­cies through­out the coun­try.

Since late 2023, Las Vegas po­lice have made more than 23,000 searches of ve­hi­cles, ac­cord­ing to the web­site Have I Been Flocked, which com­piles pub­lic au­dit logs of Flock data.

As the cam­eras were not bought with pub­lic funds, Metro does not have to hold meet­ings with the pub­lic to com­ment on the tech­nol­ogy, some­thing ex­perts say leaves cit­i­zens with­out any in­put on the polic­ing method.

In other cities, Stanley said Flock is of­ten brought up and dis­cussed dur­ing city coun­cil meet­ings or other pub­lic fo­rums. It’s not re­quired to be on pub­lic meet­ing agen­das in the Las Vegas area.

“Police de­part­ments serve the com­mu­nity and are sup­posed to make life in the com­mu­nity bet­ter. Does the com­mu­nity want this tech­nol­ogy im­posed on it?” Stanley said.

Though Horowitz’s foun­da­tion do­nated ad­di­tional funds for Flock cam­eras in October, it was not brought up at the Clark County Commission meet­ing that month, nor was their use dis­cussed any­time in 2025, ac­cord­ing to com­mis­sion meet­ing min­utes.

Some mu­nic­i­pal­i­ties in Clark County, such as the City of Las Vegas, have li­cense plate reader poli­cies that in­cludes a pub­lic Flock pol­icy with a dash­board on how many li­cense plates Flock picked up (about 185,000 in the past month in the city), how many cam­eras were in use (22 in Las Vegas), and how many searches had been done on a monthly ba­sis (five in the past 30 days). In com­par­i­son, Metro’s pol­icy is not pub­licly avail­able on­line, though The Indy ob­tained a copy through a pub­lic records re­quest.

Flock’s most re­cent con­tract with Metro, signed in 2023, stip­u­lates that the com­pany re­tains all rights in any record­ings or data pro­vided by the ser­vice and that Flock can use any of the data for “any pur­pose” at the com­pa­ny’s dis­cre­tion. The agree­ment also says that Flock record­ings are not stored for longer than 30 days.

Meanwhile, Metro pol­icy says that de­part­ment mem­bers will not seek or re­tain li­cense plate reader in­for­ma­tion about in­di­vid­u­als or an or­ga­ni­za­tion based solely on their cit­i­zen­ship, so­cial views, race or other clas­si­fi­ca­tions pro­tected by law. The pol­icy states that re­tained li­cense plate reader data does not in­clude spe­cific iden­ti­fi­ca­tion of in­di­vid­u­als. Misuse of the data will re­sult in dis­ci­pli­nary ac­tion up to ter­mi­na­tion, ac­cord­ing to the pol­icy.

But for many, in­clud­ing a for­mer of­fi­cer who spoke to The Indy on the con­di­tion of anonymity for fear of pro­fes­sional reper­cus­sions, such poli­cies are not enough.

“It’s ripe for mis­use,” the of­fi­cer said, point­ing to ex­am­ples around the coun­try of peo­ple us­ing Flock to look for cur­rent and for­mer ro­man­tic part­ners and track their move­ments. A po­lice chief in Kansas used Flock to track his ex-girl­friend 228 times in four months. An of­fi­cer in South Carolina used pub­lic cam­eras to mon­i­tor his wife, who he sus­pected was hav­ing an af­fair.

The for­mer Metro of­fi­cer said his ma­jor con­cern was not the tech­nol­ogy it­self, but the fact that there was lit­tle trans­parency on how the tech­nol­ogy was be­ing used or what the de­part­men­t’s pol­icy was on Flock us­age.

“If you look around the coun­try where li­cense plate read­ers are be­ing used, there’s some kind of pub­lic meet­ing, there’s some kind of pub­lic process,” the of­fi­cer said. “What’s hap­pen­ing here is on a very large scale — they’re putting out sur­veil­lance tech­nol­ogy — and there’s no pub­lic dis­clo­sure.”

The Horowitz Foundation do­na­tion in October in­cluded a soft­ware sub­scrip­tion to Flock’s Nova fea­ture, which al­lows of­fi­cers to eas­ily ac­cess pri­vate li­cense plate in­for­ma­tion along­side other per­sonal data, such as Social Security num­bers, credit scores, prop­erty and oc­cu­pancy in­for­ma­tion, as well as emails or so­cial me­dia han­dles.

Experts say this data could be used to iden­tify un­doc­u­mented im­mi­grants, po­lit­i­cal pro­test­ers and peo­ple trav­el­ing across state lines to ob­tain abor­tions.

Athar Haseebullah, the ex­ec­u­tive di­rec­tor of the ACLU of Nevada, said that Flock not only poses a height­ened risk for im­mi­grants, but any­one en­gaged in ac­tions that are found to be po­lit­i­cally de­fi­ant. He pointed to a case in Texas where po­lice con­ducted a na­tion­wide search us­ing Flock tech­nol­ogy for a woman who self-in­duced an abor­tion.

“This could be ripe for abuse by ICE (Immigrations and Customs Enforcement), but it could also be ripe for abuse by other gov­ern­ment en­ti­ties,” Haseebullah said. In 2025, the ACLU pushed back against a mea­sure that would al­low lo­cal ju­ris­dic­tions to use au­to­mated traf­fic cam­eras to crack down on speed­ing and red-light cross­ings, al­though the bill was never voted on.

Flock has re­ceived back­lash na­tion­wide for al­low­ing fed­eral agen­cies such as Customs and Border Patrol to tap into their data. The com­pany has said it does not work with ICE af­ter ev­i­dence was found that the agency used Flock data for im­mi­gra­tion in­ves­ti­ga­tions. Several cities have ter­mi­nated or mod­i­fied their Flock agree­ments af­ter re­al­iz­ing they were in­ad­ver­tently shar­ing their data with other agen­cies.

However, though Flock might not want to part­ner with ICE, it has lit­tle choice — Flock is ob­lig­ated to ful­fill sub­poe­nas from ICE and can’t refuse a le­gal war­rant, Andrew Ferguson, an at­tor­ney and a pro­fes­sor re­search­ing tech and po­lice sur­veil­lance at George Washington University, said.

Flock’s sur­veil­lance cam­eras are meant to catch crime, though ex­perts say it could de­ter cer­tain be­hav­iors if cit­i­zens are aware they are be­ing watched.

“There’s a chill­ing ef­fect know­ing that your gov­ern­ment is es­sen­tially track­ing you wher­ever you go,” Ferguson said. “It might be even more chill­ing if you put cam­eras in sen­si­tive places, like a med­ical clinic, or a Gambler’s Anonymous meet­ing, or a church.”

In a city such as Las Vegas, known for drink­ing, gam­bling and a hearty party cul­ture, sur­veil­lance is the last thing peo­ple are in­ter­ested in, ac­cord­ing to Ferguson.

“Things are hap­pen­ing in Vegas that are not go­ing to stay in Vegas,” Ferguson said. “They’re go­ing to be broad­cast through Flock.”

As re­cently as October of last year, the Horowitz Family Foundation do­nated al­most $1.9 mil­lion for Flock li­cense plate read­ers and an­other $2.47 mil­lion for sup­port­ing soft­ware for Flock ma­chines, ac­cord­ing to the min­utes of an LVMPD fis­cal af­fairs com­mit­tee meet­ing.

Because the do­na­tions aren’t com­ing di­rectly to Metro, but to the non­profit LVMPD foun­da­tion, also known as “Friends of Metro,” any dis­cus­sions on the cam­eras’ use aren’t sub­ject to Nevada’s open meet­ing laws.

The li­cense plate read­ers and their sup­port­ing soft­ware are not the only gift that the Horowitz Family Foundation, led by Ben Horowitz’s wife, Felicia Horowitz, has do­nated to Las Vegas po­lice. The foun­da­tion has also gifted drones, as well as Tesla Cybertrucks, to the agency.

Proponents have billed the gifts as morale boost­ers for po­lice that help the agency stay on the cut­ting edge with­out tap­ping into lim­ited tax­payer dol­lars. Critics, such as the Progressive Leadership Alliance of Southern Nevada, have sug­gested that the Cybertrucks show that Metro is “prioritizing cor­po­rate give­aways.”

Felicia Horowitz said she is fo­cused on “creating the best com­mu­nity in America” in Las Vegas, ac­cord­ing to her bio from a lo­cal non­profit or­ga­ni­za­tion that she sits on the board of. Part of that is com­bat­ing crime and keep­ing cit­i­zens safe. In a Wall Street Journal ar­ti­cle, Felicia Horowitz em­pha­sized how crime and weak polic­ing had hurt Black com­mu­ni­ties across the coun­try.

“The new poli­cies — de­fund the po­lice, don’t pros­e­cute crime — are de­stroy­ing the com­mu­ni­ties where I grew up,” Felicia Horowitz, who is Black, told the WSJ in 2024. Felicia Horowitz was raised in Los Angeles and the Horowitzes re­lo­cated to Las Vegas around 2021 and 2022 af­ter decades in California.

So far, the foun­da­tion has not pub­licly com­mented on whether it will con­tinue do­nat­ing money for Flock ser­vices. Some ex­perts think the do­na­tions might be a strat­egy called “penetration pric­ing,” where a com­pany gives free or re­duced prod­ucts or ser­vices in or­der to hook con­sumers be­fore charg­ing them.

“There’s no ques­tion that there’s a fi­nan­cial in­ter­est in them prov­ing that the Flock tech­nol­ogy works in Las Vegas so that they can sell it to other places,” said Ferguson.

The for­mer po­lice of­fi­cer said he was con­cerned about tax­pay­ers hav­ing to cough up funds to con­tinue Flock ser­vices if the Horowitz money ran dry.

“Once you start re­ly­ing on a cer­tain type of polic­ing, it’s go­ing to be hard to switch over, and then who will foot the bill?” the of­fi­cer said.

Meta, Amazon, Google, OpenAI, and other tech com­pa­nies spent bil­lions last year in­vest­ing in AI. They’re ex­pected to spend even more, roughly $700 bil­lion, this year on dozens of new data cen­ters to train and run their ad­vanced mod­els.

This spend­ing frenzy has kept Wall Street buzzing and fu­eled a nar­ra­tive that all this in­vest­ment is help­ing prop up and even grow the U. S. econ­omy.

President Donald Trump has cited that ar­gu­ment as a rea­son the in­dus­try should not face state-level reg­u­la­tions.

“Investment in AI is help­ing to make the U. S. Economy the ‘HOTTEST’ in the World — But over­reg­u­la­tion by the States is threat­en­ing to un­der­mine this Growth Engine,” Trump wrote in a post on Truth Social in November. “We MUST have one Federal Standard in­stead of a patch­work of 50 State Regulatory Regimes.”

Some promi­nent econ­o­mists have also given cred­i­bil­ity to this story with their analy­sis. Jason Furman, a Harvard eco­nom­ics pro­fes­sor, said in a post on X that in­vest­ments in in­for­ma­tion pro­cess­ing equip­ment and soft­ware ac­counted for 92% of GDP growth in the first half of the year. Meanwhile, econ­o­mists at the Federal Reserve Bank of St. Louis sim­i­larly es­ti­mated that AI-related in­vest­ments made up 39% of GDP growth in the third quar­ter of 2025.

But now some Wall Street an­a­lysts are start­ing to re­think this nar­ra­tive.

“It was a very in­tu­itive story,” Joseph Briggs, a Goldman Sachs an­a­lyst, told The Washington Post on Monday. “That maybe pre­vented or lim­ited the need to ac­tu­ally dig deeper into what was hap­pen­ing.”

Briggs’ col­league, Goldman Sachs Chief Economist Jan Hatzius, said in an in­ter­view with the Atlantic Council that AI in­vest­ment spend­ing has had “basically zero” con­tri­bu­tion to the U. S. GDP growth in 2025.

“We don’t ac­tu­ally view AI in­vest­ment as strongly growth pos­i­tive,” said Hatzius. “I think there’s a lot of mis­re­port­ing, ac­tu­ally, of the im­pact AI in­vest­ment had on U. S. GDP growth in 2025, and it’s much smaller than is of­ten per­ceived.”

Hatzius said one ma­jor rea­son is that much of the equip­ment pow­er­ing AI is im­ported. While U. S. com­pa­nies are spend­ing bil­lions, im­port­ing chips and hard­ware off­sets those in­vest­ments in GDP cal­cu­la­tions.

“A lot of the AI in­vest­ment that we’re see­ing in the U. S. adds to Taiwanese GDP, and it adds to Korean GDP but not re­ally that much to U.S. GDP,” he said.

On top of that, there is cur­rently no re­li­able way to ac­cu­rately mea­sure how AI use among busi­nesses and con­sumers con­tributes to eco­nomic growth.

So far, many busi­ness lead­ers say AI has­n’t sig­nif­i­cantly im­proved pro­duc­tiv­ity.

A re­cent sur­vey of nearly 6,000 ex­ec­u­tives in the U. S., Europe, and Australia found that de­spite 70% of firms ac­tively us­ing AI, about 80% re­ported no im­pact on em­ploy­ment or pro­duc­tiv­ity.