10 interesting stories served every morning and every evening.




1 856 shares, 46 trendiness

Microsoft gave FBI a set of BitLocker encryption keys to unlock suspects' laptops: Reports

Microsoft pro­vided the FBI with the re­cov­ery keys to un­lock en­crypted data on the hard dri­ves of three lap­tops as part of a fed­eral in­ves­ti­ga­tion, Forbes re­ported on Friday.

Many mod­ern Windows com­put­ers rely on full-disk en­cryp­tion, called BitLocker, which is en­abled by de­fault. This type of tech­nol­ogy should pre­vent any­one ex­cept the de­vice owner from ac­cess­ing the data if the com­puter is locked and pow­ered off.

But, by de­fault, BitLocker re­cov­ery keys are up­loaded to Microsoft’s cloud, al­low­ing the tech gi­ant — and by ex­ten­sion law en­force­ment — to ac­cess them and use them to de­crypt dri­ves en­crypted with BitLocker, as with the case re­ported by Forbes.

The case in­volved sev­eral peo­ple sus­pected of fraud re­lated to the Pandemic Unemployment Assistance pro­gram in Guam, a U. S. is­land in the Pacific. Local news out­let Pacific Daily News cov­ered the case last year, re­port­ing that a war­rant had been served to Microsoft in re­la­tion to the sus­pects’ hard dri­ves. Kandit News, an­other lo­cal Guam news out­let, also re­ported in October that the FBI re­quested the war­rant six months af­ter seiz­ing the three lap­tops en­crypted with BitLocker.

A spokesper­son for Microsoft did not im­me­di­ately re­spond to a re­quest for com­ment by TechCrunch. Microsoft told Forbes that the com­pany some­times pro­vides BitLocker re­cov­ery keys to au­thor­i­ties, hav­ing re­ceived an av­er­age of 20 such re­quests per year.

Apart from the pri­vacy risks of hand­ing re­cov­ery keys to a com­pany, Johns Hopkins pro­fes­sor and cryp­tog­ra­phy ex­pert Matthew Green raised the po­ten­tial sce­nario where ma­li­cious hack­ers com­pro­mise Microsoft’s cloud in­fra­struc­ture — some­thing that has hap­pened sev­eral times in re­cent years — and get ac­cess to these re­cov­ery keys. The hack­ers would still need phys­i­cal ac­cess to the hard dri­ves to use the stolen re­cov­ery keys.

It’s 2026 and these con­cerns have been known for years,” Green wrote in a post on Bluesky. Microsoft’s in­abil­ity to se­cure crit­i­cal cus­tomer keys is start­ing to make it an out­lier from the rest of the in­dus­try.”

...

Read the original on techcrunch.com »

2 700 shares, 0 trendiness

In Europe, Wind and Solar Power Overtakes Fossil Fuels

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

...

Read the original on e360.yale.edu »

3 394 shares, 16 trendiness

Can AI grow corn?

On January 21, 2026, @fredwilson chal­lenged @seth: AI can write code, but it can’t af­fect the phys­i­cal world. This is our re­sponse. Real corn, grown from seed to har­vest, with every de­ci­sion made by Claude Code.

AI does­n’t need to drive a trac­tor. It needs to or­ches­trate the sys­tems and peo­ple who do. A farm man­ager does­n’t per­son­ally plant every seed. They ag­gre­gate data, make de­ci­sions, co­or­di­nate con­trac­tors. Claude Code be­comes that farm man­ager— 24/7, data-dri­ven, fully doc­u­mented.

The Process — How this was built

Fred processes emails as part of his daily check rou­tine. Priority given to farm­ers and op­er­a­tors.

A pro­ject by @seth, in­spired by @fredwilson, or­ches­trated by Claude Code (Opus 4.5)Want to help? Iowa land leads, ag ex­per­tise, vibe coders wel­come: [email protected]

...

Read the original on proofofcorn.com »

4 338 shares, 15 trendiness

Gas Town’s Agent Patterns, Design Bottlenecks, and Vibecoding at Scale

1. Design and plan­ning be­comes the bot­tle­neck when agents write all the code 2. Buried in the chaos are sketches of fu­ture agent or­ches­tra­tion pat­terns 3. The price is ex­tremely high, but so is the (potential) value 4. Yegge never looks at code. When should we stop look­ing too? Access to feed­back loops and de­f­i­n­i­tions of suc­ces

1. Design and plan­ning be­comes the bot­tle­neck when agents write all the code 2. Buried in the chaos are sketches of fu­ture agent or­ches­tra­tion pat­terns 3. The price is ex­tremely high, but so is the (potential) value 4. Yegge never looks at code. When should we stop look­ing too? Access to feed­back loops and de­f­i­n­i­tions of suc­ces

A few weeks ago Steve Yegge pub­lished an elab­o­rate man­i­festo and guide to Gas Town, his Mad-Max-Slow-Horses-Waterworld-etc-themed agent or­ches­tra­tor that runs dozens of cod­ing agents si­mul­ta­ne­ously in a metaphor­i­cal town of au­to­mated ac­tiv­ity. Gas Town is en­tirely vibecoded, hastily de­signed with off-the-cuff so­lu­tions, and in­ef­fi­ciently burn­ing through thou­sands of dol­lars a month in API costs.

This does­n’t sound promis­ing, but it’s lit di­vi­sive de­bates and sparks of change across the soft­ware en­gi­neer­ing com­mu­nity. A small hype ma­chine has formed around it. It’s made the rounds through every en­gi­neer­ing team’s Slack, prob­a­bly twice. There’s some­how al­ready a $GAS meme coin do­ing over $400k in earn­ings. And the hype is jus­ti­fied. First, be­cause it’s ut­terly un­hinged, and sec­ond be­cause it’s a se­ri­ous in­di­ca­tion of how agents will change the na­ture of soft­ware de­vel­op­ment from this point on.

You should at least skim through Yegge’s orig­i­nal ar­ti­cle be­fore con­tin­u­ing to read my re­flec­tions. First, be­cause I’m not go­ing to com­pre­hen­sively sum­marise it. And sec­ond, be­cause a even a one minute glance over Yegge’s style of writ­ing will make the vibes clear.

We should take Yegge’s cre­ation se­ri­ously not be­cause it’s a se­ri­ous, work­ing tool for to­day’s de­vel­op­ers (it is­n’t). But be­cause it’s a good piece of spec­u­la­tive de­sign fic­tion that asks provoca­tive ques­tions and re­veals the shape of con­straints we’ll face as agen­tic cod­ing sys­tems ma­ture and grow.

Design fic­tion” or speculative de­sign” is a branch of de­sign where you cre­at­ing things (objects, pro­to­types, sketches) from a plau­si­ble near fu­ture. Not to pre­dict what’s go­ing to hap­pen, but to pro­voke ques­tions and start con­ver­sa­tions about what could hap­pen. Not in a bright-and-glo­ri­ous-fly­ing-cars way that fu­tur­ism can some­times fall into. But, most help­fully, in a way that thinks about ba­nal de­tails, over­looked every­day in­ter­ac­tions, low sta­tus ob­jects, im­per­fect im­ple­men­ta­tions, knock-on ef­fects, and in­con­ve­niences. See the Near Future Lab’s short ex­plainer video and their Manual of Design Fiction if you want to learn more.

I also think Yegge de­serves praise for ex­er­cis­ing agency and tak­ing a swing at a sys­tem like this, de­spite the in­ef­fi­cien­cies and chaos of this it­er­a­tion. And then run­ning a pub­lic tour of his shitty, quar­ter-built plane while it’s mid-flight.

When I was taken to the Tate Modern as a child I’d point at Mark Rothko pieces and say to my mother I could do that”, and she would say yes, but you did­n’t.” Many peo­ple have talked about what large-scale, au­to­mated agent or­ches­tra­tion sys­tems could look like in a few years, and no one else at­tempted to sin­cerely build it.

I should be trans­par­ent and say that I have not used Gas Town in earnest on any se­ri­ous work. I have only lightly poked at it, be­cause I do not qual­ify as a se­ri­ous user when I’m still hov­er­ing around stages 4-6 in Yegge’s 8 lev­els of au­toma­tion:

I cur­rently jug­gle a hand­ful of con­sec­u­tive Claude Code and OpenCode agents, but pay close at­ten­tion to the diffs and reg­u­larly check code in an IDE. Which I guess puts me in the agen­ti­cally con­ser­v­a­tive camp in this dis­tress­ingly break­neck mo­ment in his­tory.

Gas Town is a full-on stage 8 piece of tool­ing: us­ing an or­ches­tra­tor that man­ages dozens+ of other cod­ing agents for you. Yegge also warned me not to se­ri­ously use Gas Town mul­ti­ple times, in in­creas­ingly threat­en­ing ty­pog­ra­phy. I trust his guid­ance on his own slush pile.

But I have grokked the ba­sic con­cepts and spent more time with this man­i­festo than is war­ranted. And here is what stood out to me from the parts I could com­pre­hend:

When you have a fat stack of agents churn­ing through code tasks, de­vel­op­ment time is no longer the bot­tle­neck. Yegge says Gas Town churns through im­ple­men­ta­tion plans so quickly that you have to do a LOT of de­sign and plan­ning to keep the en­gine fed.” Design be­comes the lim­it­ing fac­tor: imag­in­ing what you want to cre­ate and then fig­ur­ing out all the gnarly lit­tle de­tails re­quired to make your imag­i­na­tion into re­al­ity.

I cer­tainly feel this fric­tion in both my own pro­fes­sional work and per­sonal pro­jects. My de­vel­op­ment ve­loc­ity is far slower than Yegge since I only wran­gle a few agents at a time and keep my eyes and hands on the code. But the build time is rarely what holds me up. It is al­ways the de­sign; how should we ar­chi­tect this? What should this feel like? How should this look? Is that tran­si­tion sub­tle enough? How com­pos­able should this be? Is this the right metaphor?

When it’s not the de­sign, it’s the prod­uct strat­egy and plan­ning; What are the high­est pri­or­ity fea­tures to tackle? Which piece of this should we build first? When do we need to make that de­ci­sion? What’s the next log­i­cal, in­cre­men­tal step we need to make progress here?

These are the kind of de­ci­sions that agents can­not make for you. They re­quire your hu­man con­text, taste, pref­er­ences, and vi­sion.

With agents to hand, it’s easy to get ahead of your­self, stum­bling for­ward into stacks of gen­er­ated func­tions that should never have been prompted into ex­is­tence, be­cause they do not cor­rectly ren­der your in­ten­tions or achieve your goals.

Gas Town seems to be halfway into this pit­fall. The biggest flaw in Yegge’s cre­ation is that it is poorly de­signed. I mean this in the sense that he ab­solutely did not de­sign the shape of this sys­tem ahead of time, thought­fully con­sid­er­ing which metaphors and prim­i­tives would make this ef­fec­tive, ef­fi­cient, easy to use, and com­pre­hen­si­ble.

He just made stuff up as he went. He says as much him­self: Gas Town is com­pli­cated. Not be­cause I wanted it to be, but be­cause I had to keep adding com­po­nents un­til it was a self-sus­tain­ing ma­chine.” Gas Town is com­posed of especially dif­fi­cult [theories] be­cause it’s a bunch of bull­shit I pulled out of my arse over the past 3 weeks, and I named it af­ter bad­gers and stuff.” It was slap­dashed to­gether over 17 days, 75k lines of code, 2000 com­mits. It fi­nally got off the ground (GUPP started work­ing) just 2 days ago.”

This Hacker News com­ment from qc­n­guy de­scribes the prob­lem well, and points out that Yegge’s pre­vi­ous Beads pro­ject, of which Gas Town is an ex­ten­sion, suf­fers the same is­sue:

Beads is a good idea with a bad im­ple­men­ta­tion. It’s not a de­signed prod­uct in the sense we are used to, it’s more like a stream of con­scious­ness con­verted di­rectly into code. It’s a pro­gram that is­n’t only vibe coded, it was vibe de­signed too.”

Gas Town is clearly the same thing mul­ti­plied by ten thou­sand. The num­ber of over­lap­ping and ad hoc con­cepts in this de­sign is over­whelm­ing. Steve is ahead of his time but we aren’t go­ing to end up us­ing this stuff. Instead a few of the core in­sights will get in­cor­po­rated into other agents in a sim­pler but no less ef­fec­tive way.”

Or this re­view from as­trra.space on Bluesky:

gas town [is] such a night­mare to use i love it… the mayor is dumb as rocks the wit­ness reg­u­larly for­gets to look at stuff the dea­con makes his own rules the crew have the ob­ject per­ma­nence of a tank full of gold­fish and the pole­cats seem in­tent on wreak­ing as much chaos on the pro­ject as they can. this is peak en­ter­tain­ment i swear”

Friends and col­leagues of mine who have been brave enough to try out Gas Town in more depth re­port the same thing; this thing fits the shape of Yegge’s brain and no one else’s. I’d cat­e­gorise that as a mod­er­ate de­sign fail, given this is a pub­lic prod­uct that I as­sume Yegge wants at least some peo­ple to try out. The on­board­ing is bap­tism by fire.

This feels like one of the most crit­i­cal, emerg­ing foot­guns of lib­er­ally hands-off agen­tic de­vel­op­ment. You can move so fast you never stop to think. It is so easy to prompt, you don’t fully con­sider what you’re build­ing at each step of the process. It is only once you are hip-deep in poor ar­chi­tec­tural de­ci­sions, in­scrutable bugs, and a fuzzy mem­ory of what you set out to do, do you re­alise you have burned a bil­lion to­kens in ex­change for a pile of hot trash.

Now that I’ve just cri­tiqued the de­sign of Gas Town, I will turn around and say that while the cur­rent amal­ga­ma­tion of pole­cats, con­voys, dea­cons, mol­e­cules, pro­to­mol­e­cules, may­ors, seances, hooks, beads, wit­nesses, wisps, rigs, re­finer­ies, and dogs is a bunch of un­der cooked spaghetti, Yegge’s pat­terns roughly sketch out some use­ful con­cep­tual shapes for fu­ture agen­tic sys­tems.

If you step back and squint, this mish­mash of con­cepts re­veals a few un­der­ly­ing pat­terns that fu­ture agen­tic sys­tems will likely fol­low:

Every agent in Gas Town has a per­ma­nent, spe­cialised role. When an agent spins up a new ses­sion, it knows who it is and what job it needs to do. Some ex­am­ples:

* The Mayor is the hu­man concierge: it’s the main agent you talk to. It talks to all the other agents for you, kick­ing off work, re­ceiv­ing no­ti­fi­ca­tions when things fin­ish, and man­ag­ing the flow of pro­duc­tion.

* Polecats are tem­po­rary grunt work­ers. They com­plete sin­gle, iso­lated tasks, then dis­ap­pear af­ter sub­mit­ting their work to be merged.

* The Witness su­per­vises the Polecats and helps them get un­stuck. Its job is to solve prob­lems and nudge the pro­le­tariat work­ers along.

* The Refinery man­ages the merge queue into the main branch. It eval­u­ates each piece of work wait­ing to be merged, re­solv­ing con­flicts in the process. It can cre­atively re-imagine” im­ple­men­ta­tions if merge con­flicts get too hairy, while try­ing to keep the in­tent of the orig­i­nal work.

There are many more char­ac­ters in this town, but these give you a flavour of the sys­tem. Giving each agent a sin­gle job means you can prompt them more pre­cisely, limit what they’re al­lowed to touch, and run lots of them at once with­out them step­ping on each oth­er’s toes.

There’s also a clear chain of com­mand be­tween these agents. You talk to the Mayor, who co­or­di­nates work across the sys­tem. The Mayor in Gas Town never writes code. It talks to you, then cre­ates work tasks and as­signs them to work­ers. A set of sys­tem su­per­vi­sors called the Witness, the Deacon, and Boot the Dog” in­ter­mit­tently nudge the grunt work­ers and each other to check every­one is do­ing their work. Oh and there’s also a crew of dogs” who do main­te­nance and clean­ing.

It’s eas­ier if I try and show you. Here’s the ba­sic re­la­tion­ship struc­ture of Gas Town, as best I can make out:

Since I’m mak­ing my own vi­su­als here, I should jus­tify it by point­ing out that while Yegge made lots of his own or­nate, zoop­mor­phic di­a­grams of Gas Town’s ar­chi­tec­ture and work­flows, they are un­help­ful. Primarily be­cause they were made en­tirely by Gemini’s Nano Banana  . And while Nano Banana is state-of-the-art at mak­ing di­a­grams, gen­er­a­tive AI sys­tems are still re­ally shit at mak­ing il­lus­tra­tive di­a­grams. They are very hard to de­ci­pher, filled with clut­tered de­tails, have ar­rows point­ing the wrong di­rec­tion, and are of­ten miss­ing key in­for­ma­tion. Case in point:

Does this help you un­der­stand how the sys­tem works? No? No.

Gas Town’s hi­er­ar­chi­cal ap­proach solves both a co­or­di­na­tion and at­ten­tion prob­lem. Without it, you are the one as­sign­ing tasks to dozens in­di­vid­ual agents, check­ing who’s stuck, who’s idle, and who’s wait­ing on work from some­one else. With the Mayor as your sin­gle in­ter­face, that over­head dis­ap­pears. You can con­tin­u­ously talk to the Mayor with­out in­ter­rupt­ing any agents or get­ting in the way, or hav­ing to think much about which one is do­ing what. This is less cog­ni­tive over­head than con­stantly switch­ing tabs be­tween Claudes.

I think there’s a lot of op­por­tu­nity to di­ver­sify the cast of char­ac­ters here and make more use of spe­cial­ist sub­agents  . The agents in Gas Town are all gen­er­al­ist work­ers in the soft­ware de­vel­op­ment pipeline. But we could add in any kind of spe­cial­ist we want: a dev ops ex­pert, a prod­uct man­ager, a front-end de­bug­ger, an ac­ces­si­bil­ity checker, a doc­u­men­ta­tion writer. These would be called in on-de­mand to ap­ply their spe­cial skills and tools.

One of the ma­jor lim­i­ta­tions of cur­rent cod­ing agents is run­ning out of con­text. Before you even hit the lim­its of a con­text win­dow, con­text rot de­grades the out­put enough that it’s not worth keep­ing. We con­stantly have to com­pact or start fresh ses­sions.

Gas Town’s so­lu­tion to this is make each agent ses­sion dis­pos­able by de­sign. It stores the im­por­tant in­for­ma­tion — agent iden­ti­ties and tasks — in Git, then lib­er­ally kills off ses­sions and spins up fresh ones when needed. New ses­sions are told their iden­tity and cur­rently as­signed work, and con­tinue on where the last one left off. Gas Town also lets new ses­sions ask their pre­de­ces­sors what hap­pened through seancing”: re­sum­ing the last ses­sion as a sep­a­rate in­stance in or­der to let the new agent ask ques­tions about un­fin­ished work.

This sav­ing and re­call­ing is all done through Gas Town’s Beads” sys­tem. Beads are tiny, track­able units of work — like is­sues in an is­sue tracker — stored as JSON in Git along­side your code. Each bead has an ID, de­scrip­tion, sta­tus, and as­signee. Agent iden­ti­ties are also stored as beads, giv­ing each worker a per­sis­tent ad­dress that sur­vives ses­sion crashes.

Yegge did­n’t in­vent this pat­tern of track­ing atomic tasks out­side agent mem­ory in some­thing struc­tured like JSON. Anthropic de­scribed the same ap­proach in their re­search on ef­fec­tive har­nesses for long-run­ning agents  , just pub­lished in November 2025. I give it a hot minute be­fore this type of task track­ing lands in Claude Code.

The whole promise of an or­ches­tra­tion sys­tem like Gas Town is it’s a per­pet­ual mo­tion ma­chine. You give high-level or­ders to the mayor, and then a zoo of agents kicks off to break it down into tasks, as­sign them, ex­e­cute them, check for bugs, fix the bugs, re­view the code, and merge it in.

Each worker agent in Gas Town has its own queue of as­signed work and a hook” point­ing to the cur­rent thing they should be do­ing. The minute they fin­ish a task, the next one jumps to the front of the queue. The mayor is the one fill­ing up these queues — it’s in charge of break­ing down large fea­tures into atomic tasks and as­sign­ing them to avail­able work­ers. In the­ory, the work­ers are never idle or lack­ing tasks, so long as you keep feed­ing the mayor your grand plans.

This prin­ci­ple of workers al­ways do their work” is bet­ter in the­ory than prac­tice. It turns out to be slightly dif­fi­cult to make hap­pen be­cause of the way cur­rent mod­els are trained. They’re de­signed as help­ful as­sis­tants who wait po­litely for hu­man in­struc­tions. They’re not used to check­ing a task queue and in­de­pen­dently get­ting on with things.

Gas Town’s patch­work so­lu­tion to this is ag­gres­sive prompt­ing and con­stant nudg­ing. Supervisor agents spend their time pok­ing work­ers to see if any­one’s stalled out or run dry on work. When one goes quiet, they send it a ping which jolts the agent into check­ing its queue and get­ting back to work. These pe­ri­odic nudges move through the agent hi­er­ar­chy like a heart­beat keep­ing every­thing mov­ing. This is a de­cent band-aid for the first ver­sion, but more se­ri­ous ef­forts at agent or­ches­tra­tion sys­tems will need re­li­able ways to keep agents on task.

When you have a bunch of agents all work­ing in par­al­lel, you’re of course go­ing to run into merge con­flicts. Each agent is off on its own branch, and by the time it fin­ishes its task, the main branch might look com­pletely dif­fer­ent — other changes have landed, the code has moved on. The later an agent fin­ishes, the worse this gets. Normally you, the hu­man, takes on the bur­den of sort­ing out the mess and de­cid­ing which changes to keep. But if agents are run­ning on their own, some­thing has to do that job for them.

So Gas Town has a ded­i­cated merge agent — the Refinery — that works through the merge queue one change at a time. It looks at each merge re­quest, re­solves any con­flicts, and gets it into main. When things get re­ally tan­gled — when so much has changed that the orig­i­nal work does­n’t even make sense any­more — it can cre­atively re-imagine” the changes: re-do­ing the work to fit the new code­base. Or es­ca­late to a hu­man if needed.

But there’s an­other way to side­step merge con­flict night­mares that Gas Town does­n’t have built in: ditch PRs for stacked diffs  . The tra­di­tional git work­flow puts each fea­ture on its own branch for days or weeks, ac­cu­mu­lat­ing com­mits, then get­ting merged back as one chunky PR.

Stacked diffs avoid this con­flict-prone ap­proach by break­ing work into small, atomic changes that each get re­viewed and merged on their own, build­ing on top of each other. Every change gets its own branch, forked off the pre­vi­ous change, form­ing a stack” of changes de­pen­dent on one an­other. When a change ear­lier in the stack gets up­dated, all the changes be­low it au­to­mat­i­cally re­base on top of the new ver­sion.

This fits how agents nat­u­rally work. They’re al­ready pro­duc­ing tiny, fo­cused changes rather than sprawl­ing multi-day branches. When con­flicts do pop up, they’re eas­ier to un­tan­gle be­cause each diff touches less code. Cursor s re­cent ac­qui­si­tion of Graphite  , a tool built specif­i­cally for stacked diff work­flows, sug­gests I am not the only one who sees this op­por­tu­nity. When you’ve got dozens of agents land­ing changes con­tin­u­ously, you need tools and in­ter­faces specif­i­cally de­signed for these fre­quent, in­cre­men­tal merges.

Yegge de­scribes Gas Town as expensive as hell… you won’t like Gas Town if you ever have to think, even for a mo­ment, about where money comes from.” He’s on his sec­ond Claude ac­count to get around Anthropic’s spend­ing lim­its.

I can’t find any men­tion on­line of the per-ac­count lim­its, but let’s con­ser­v­a­tively as­sume he’s spend­ing at least $2,000 USD per month, and lib­er­ally $5,000.

The cur­rent cost is al­most cer­tainly ar­ti­fi­cially in­flated by sys­tem in­ef­fi­ciency. Work gets lost, bugs get fixed nu­mer­ous times, de­signs go miss­ing and need re­do­ing. As mod­els im­prove and or­ches­tra­tion pat­terns ma­ture, the cost of or­ches­tra­tors like this should drop while out­put qual­ity rises.

I ex­pect com­pa­nies would hap­pily pay around the $1-3k/month mark for a sane, un­der­stand­able, higher qual­ity, and lower waste ver­sion of Gas Town. Maybe that sounds ab­surd to you, given we’ve all be­come an­chored to the ar­ti­fi­cially low rate of $100-200/month for un­lim­ited us­age by the ma­jor providers. But once the AI bub­ble pops, the VC funds dry up, and providers have to charge the true cost of in­fer­ence at scale, we should ex­pect that unlimited” tier to look a lot pricier.

Even when that comes to pass, a few thou­sand is pretty rea­son­able when you com­pare it to an av­er­age US se­nior de­vel­oper salary: $120,000 USD. If Gas Town could gen­uinely speed up the work of a se­nior de­vel­oper by 2-3x or more, it would eas­ily be worth 10-30% of their salary. The cost per unit of valu­able work starts to look com­pet­i­tive with hu­man la­bor.

The maths on pay­ing for some­thing like this is al­ready de­fen­si­ble in wealth­ier places like the US and parts of Western Europe. In spots where de­vel­oper salaries are lower, we would ex­pect the bud­get for AI as­sisted tools ad­justs ac­cord­ingly. They’ll get less crazy scaled au­toma­tion and more con­ver­sa­tive use­age with hu­mans fill­ing in the cog­ni­tive gaps.

Yegge is lean­ing into the true de­f­i­n­i­tion of vibecod­ing with this pro­ject: It is 100% vibecoded. I’ve never seen the code, and I never care to.” Not look­ing at code at all is a very bold propo­si­tion, to­day, in January 2026.

Given the cur­rent state of mod­els and the mea­gre safe­guards we have in place around them, the vast ma­jor­ity of us would con­sider this blind cod­ing ap­proach ir­re­spon­si­ble and daft to do on any­thing that is­n’t a throw­away side pro­ject. Which, given the amount of ef­fort and Claude to­kens Yegge has sunk into build­ing it, writ­ing doc­u­men­ta­tion, and pub­licly pro­mot­ing it, Gas Town is not.

Should de­vel­op­ers still look at code?” will be­come one of the most di­vi­sive and heated de­bates over the com­ing years. You might be of­fended by the ques­tion, and find it ab­surd any­one is ask­ing. But it’s a sin­cere ques­tion and the an­swer will change faster than you think.

I’m al­ready see­ing peo­ple di­vide along moral­is­tic, per­sonal iden­tity lines as they try to an­swer it. Some de­clare them­selves purist, AI skep­tic, Real Developers who check every diff and hand-ad­just spe­cific lines, sneer­ing at any­one reck­less enough to let agents run free. While oth­ers lean into agen­tic max­i­mal­ism, di­rect­ing fleets from on high and pity­ing the mass of lud­dites still faffing about with man­ual ed­its like it’s 2019. Both camps mis­take a con­tex­tual judge­ment for a per­son­al­ity trait and firm moral po­si­tion.

A more con­ser­v­a­tive, eas­ier to con­sider, de­bate is: how close should the code be in agen­tic soft­ware de­vel­op­ment tools? How easy should it be to ac­cess? How of­ten do we ex­pect de­vel­op­ers to edit it by hand?

Interfaces like Claude Code  , Cursor  , and Conductor do not put code front and cen­tre in the ex­pe­ri­ence. The agent is your first and pri­mary in­ter­face. You might be able to see diffs rolls by or dis­play code files in­line, but you can’t touch them. Trying to edit code your­self is a round­about jour­ney of open­ing your IDE and nav­i­gat­ing to the cor­rect files and lines.

This de­sign choice as­sumes it is eas­ier to ask an agent to make the change for you, than it is to type it out the syn­tax your­self. They clearly say we don’t be­lieve users need to touch code.”

Framing this de­bate as an ei­ther/​or — ei­ther you look at code or don’t, ei­ther you edit code by hand or you ex­clu­sively di­rect agents, ei­ther you’re the anti-AI-purist or the agen­tic-maxxer — is un­help­ful. Because noth­ing is a strict bi­nary.

The right dis­tance is­n’t about what kind of per­son you are or what you be­lieve about AI ca­pa­bil­i­ties in the cur­rent mo­ment. How far away you step from the syn­tax shifts based on what you’re build­ing, who you’re build­ing with, and what hap­pens when things go wrong. The de­gree of free­dom you hand over to agents de­pends on:

Front-end ver­sus back­end makes a huge dif­fer­ence. Language is a poor medium for de­sign­ing eas­ing curves and de­scrib­ing aes­thetic feel­ings — I al­ways need to touch the CSS, and it’s of­ten faster to just tweak di­rectly than try to ex­plain what I want. Yegge’s CLI tool­ing is much eas­ier to val­i­date with pass/​fail tests than eval­u­at­ing whether a no­ti­fi­ca­tion sys­tem feels calm enough”. Model com­pe­tence also varies wildly by lan­guage; prompt­ing React and Tailwind gives you much bet­ter re­sults than Rust or Haskell, where the mod­els still reg­u­larly choke on bor­row check­ers and type sys­tems.

The more agents can val­i­date their own work, the bet­ter the re­sults. If you let agents run tests and see the out­put, they quickly learn what’s bro­ken and how to fix it. If you let them open browsers, take screen­shots, and click around, they can spot their mis­takes. Tools like the Ralph Wiggum plu­gin lean into this — it loops un­til tests pass or some spe­cific con­di­tion is val­i­dated. This does­n’t work for less de­fined, clear cut work though. If you try to make an agent de­sign a vi­sual di­a­gram for you, it’s go­ing to strug­gle. It does­n’t know your aes­thetic pref­er­ences and can’t re­ally see” what it’s mak­ing.

Stakes mat­ter. If an agent breaks some im­ages on your per­sonal blog, you’ll re­cover. But if you’re run­ning a health­care sys­tem where a bug could mis­cal­cu­late drug dosages, or a bank­ing app mov­ing ac­tual money around, you can’t just wave an agent at it and hope. Consequences scale up fast. Corporate soft­ware has peo­ple whose en­tire job is com­pli­ance and reg­u­la­tory sign-off — they need to see the code, un­der­stand it, ver­ify it meets re­quire­ments. Those peo­ple aren’t go­ing to let you widly run Gas Town over pro­jects with­out se­ri­ous guardrails in place.

Gas Town sounds fun if you are ac­count­able to no­body: not for code qual­ity, de­sign co­her­ence or in­fer­enc­ing costs. The rest of us are ac­count­able for at least the first two and even in cor­po­rate sce­nar­ios where there is a blank check for to­kens, that can’t last. So the bot­tle­neck is go­ing to be how fast hu­mans can re­view code and agree to take re­spon­si­bil­ity for it.”

Starting fresh (greenfield), means you can let agents make ar­chi­tec­tural de­ci­sions and es­tab­lish pat­terns — if you don’t like them, you can eas­ily throw it out and restart. The cost of mis­takes is low. But in an ex­ist­ing code­base (brownfield) with years of ac­cu­mu­lated con­ven­tions, im­plicit pat­terns, and code that ex­ists for rea­sons no­body re­mem­bers any­more, agents need much tighter su­per­vi­sion. They’ll hap­pily in­tro­duce a new pat­tern that con­tra­dicts the three other ways this code­base al­ready solves the same prob­lem.

If you’re solo of course you can YOLO. If you’re work­ing with more than a hand­ful of peo­ple, you’ll have to agree on cod­ing stan­dards and agent rules. This cre­ates its own over­head: up­dat­ing the AGENTS.md file, pick­ing MCPs, writ­ing com­mands and skills and rules and what­ever else we in­vent to con­strain these things. The pace of change when you’re all us­ing agents can be over­whelm­ing and you need to fig­ure out a sen­si­ble re­view­ing pipeline to man­age it. Team co­or­di­na­tion can fall apart when every­one’s agents start mov­ing too fast. You might show up in the morn­ing and dis­cover some­one’s agent re­named the data­base schema while an­other agent refac­tored the whole API layer, and nei­ther of which jive with your gi­ant, un­merged fea­ture.

More se­nior de­vel­op­ers can prompt bet­ter, de­bug bet­ter, and setup more strin­gent pref­er­ences earned through decades of see­ing what can go wrong in scaled, pro­duc­tion en­vi­ron­ments. They can rec­og­nize pat­terns: oh, that’s a mem­ory leak” or that’s go­ing to dead­lock un­der load.” Newer de­vel­op­ers don’t have that cat­a­log of fail­ures yet and are much more likely to prompt their own per­sonal house of cards. The tests might pass and every­thing looks fine un­til you hit pro­duc­tion traf­fic or some­one en­ters a weird char­ac­ter. It is hard to de­fend against un­known un­knowns.

Given all these it de­pends” con­sid­er­a­tions, I’m cur­rently in the code-must-be-close camp for most se­ri­ous work done by pro­fes­sional de­vel­op­ers. But I ex­pect I’ll shift to the code-at-a-dis­tance camp over the next year or two as the har­nesses and tools we wrap around these agents ma­ture. If we can ship them with es­sen­tial safe guards and qual­ity gates, the risks drop. Sure, the mod­els will also im­prove, but the in­fra­struc­ture mat­ters far more: val­i­da­tion loops, tests, and spe­cialised sub­agents who fo­cus on se­cu­rity, de­bug­ging, and code qual­ity are what will make code-at-a-dis­tance fea­si­ble.

We have many, con­tin­u­ous ver­sions of the code dis­tance de­bate in­ter­ally at Github Next  . One of the pro­jects within the team dri­ving this is Agentic Workflows  — au­tonomous agents run through GitHub Actions in re­sponse to events: new PRs, new is­sues, or spe­cific times of day. Every com­mit can trig­ger a se­cu­rity re­view agent, an ac­ces­si­bil­ity au­dit, and a doc­u­men­ta­tion up­dater, all run­ning in par­al­lel along­side tra­di­tional CI/CD tests be­fore any­thing lands in main. The team build­ing it rarely touches code and do most of their work by di­rect­ing agents from their phones. It’s these kinds of guardrails that makes a hands-off Sim-City-esque or­ches­tra­tor sys­tem feel less ter­ri­fy­ing to me.

I don’t be­lieve Gas Town it­self is it”. It’s not go­ing to evolve into the thing we all use, day in and day out, in 2027. As I said, it’s a provoca­tive piece of spec­u­la­tive de­sign, not a sys­tem many peo­ple will use in earnest. In the same way any poorly de­signed ob­ject or sys­tem gets aban­doned, this manic cre­ation is too poorly thought through to per­sist. But the prob­lems it’s wrestling with and the pat­terns it has sketched out will un­ques­tion­ably show up in the next gen­er­a­tion of de­vel­op­ment tools.

As the pace of soft­ware de­vel­op­ment speeds up, we’ll feel the pres­sure in­ten­sify in other parts of the pipeline: thought­ful de­sign, crit­i­cal think­ing, user re­search, plan­ning and co­or­di­na­tion within teams, de­cid­ing what to build, and whether it’s been built well. The most valu­able tools in this new world won’t be the ones that gen­er­ate the most code fastest. They’ll be the ones that help us think more clearly, plan more care­fully, and keep the qual­ity bar high while every­thing ac­cel­er­ates around us.

...

Read the original on maggieappleton.com »

5 318 shares, 13 trendiness

Booting from a vinyl record

Most PCs tend to boot from a pri­mary me­dia stor­age, be it a hard disk drive, or a solid-state drive, per­haps from a net­work, or — if all else fails — the USB stick or the boot DVD comes to the res­cue… Fun, eh? Boring! Why don’t we try to boot from a record player for a change?

Update February 2022: Click here to ob­serve the very same vinyl ramdisk booted on an IBM PCjr!

So this nutty lit­tle ex­per­i­ment con­nects a PC, or an IBM PC to be ex­act, di­rectly onto a record player through an am­pli­fier. I made a small ROM on-chip boot loader that op­er­ates the built-in cassette in­ter­face” of the PC (that was hardly ever used), which will now be in­voked by the BIOS if all the other boot op­tions fail, i.e. floppy disk and the hard drive. The turntable spins an ana­log record­ing of a small bootable read-only RAM drive, which is 64K in size. This con­tains a FreeDOS ker­nel, mod­i­fied by me to cram it into the mem­ory con­straint, a mi­cro vari­ant of COMMAND. COM and a patched ver­sion of INTERLNK, that al­lows file trans­fer through a printer ca­ble, mod­i­fied to be runnable on FreeDOS. The boot­loader reads the disk im­age from the au­dio record­ing through the cas­sette mo­dem, loads it to mem­ory and boots the sys­tem on it. Simple huh?

The vinyl loader code, in a ROM

(It can also re­side on a hard drive or a floppy, but that’d be cheat­ing)

And now to get more tech­ni­cal: this is ba­si­cally a merge be­tween BootLPT/86 and 5150CAXX, mi­nus the printer port sup­port. It also re­sides in a ROM, in the BIOS ex­pan­sion socket, but it does not have to. The con­nect­ing ca­ble be­tween the PC and the record player am­pli­fier is the same as with 5150CAXX, just with­out the line-in (PC data out) jack.

The cassette in­ter­face” it­self is just PC speaker timer chan­nel 2 for the out­put, and 8255A-5 PPI port C chan­nel 4 (PC4, I/O port 62h bit 4) for the in­put. BIOS INT 15h rou­tines are used for soft­ware (de)modulation.

The boot im­age is the same 64K BOOTDISK. IMG example” RAM drive that can be down­loaded at the bot­tom of the BootLPT ar­ti­cle. This has been turned into an IBM cas­sette tape”-pro­to­col com­pli­ant au­dio sig­nal us­ing 5150CAXX, and sent straight to a record cut­ting lathe.

Vinyls are cut with an RIAA equal­iza­tion curve that a pre­amp usu­ally re­verses dur­ing play­back, but not per­fectly. So some sig­nal cor­rec­tion had to be ap­plied from the am­pli­fier, as I could­n’t make it work right with the line out­put straight from the phono pre­amp. In my case, in­volv­ing a vin­tage Harman&Kardon 6300 am­pli­fier with an in­te­grated MM phono pre­amp, I had to fade the tre­ble all the way down to -10dB/10kHz, in­crease bass equal­iza­tion to ap­prox. +6dB/50Hz and re­duce the vol­ume level to ap­prox­i­mately 0.7 volts peak, so it does­n’t dis­tort. All this, nat­u­rally, with any phase and loud­ness cor­rec­tion turned off.

Of course, the cas­sette mo­dem does not give a hoot in hell about where the sig­nal is com­ing from. Notwithstanding, the record­ing needs to be pris­tine and con­tain no pops or loud crack­les (vinyl) or mod­u­la­tion/​fre­quency drop-outs (tape) that will break the data stream from con­tin­u­ing. However, some wow is tol­er­ated, and the speed can be 2 or 3 per­cent higher or lower too.

Bootloader in a ROM; be­ing an EPROM for a good mea­sure

And that’s it! For those in­ter­ested, the boot­loader bi­nary de­signed for a 2364 chip (2764s can be used, through an adap­tor), can be ob­tained here. It as­sumes an IBM 5150 with a mono­chrome screen and at least 512K of RAM, which kind of re­minds me of my setup (what a co­in­ci­dence). The boot disk im­age can be ob­tained at the bot­tom of the BootLPT/86 ar­ti­cle, and here’s its ana­log vari­ant, straight from the grooves 🙂

...

Read the original on boginjr.com »

6 309 shares, 9 trendiness

Tesla kills Autopilot, locks lane-keeping behind $99/month fee

Tesla was told that if it could­n’t re­solve the de­cep­tive mar­ket­ing within those 60 days, the sales sus­pen­sion would take ef­fect. That would be bad for the au­tomaker, as California is far and away its largest mar­ket in the US, al­beit one that is shrink­ing each quar­ter. Having to sus­pend sales en­tirely in the state would be dis­as­trous. Some had spec­u­lated that Tesla could change Autopilot’s name to some­thing less mis­lead­ing, but the com­pany chose a more dras­tic ap­proach.

Now, if you buy a new Tesla and  want it to steer it­self—while you pay at­ten­tion to the road—you will have to pay for FSD. Until the mid­dle of February, that can be done for a one-time fee of $8,000. But start­ing on February 14, that op­tion goes away, too, and the sole choice will be a $99/month FSD sub­scrip­tion.

But prob­a­bly not for very long. Last night, Musk re­vealed on his so­cial me­dia plat­form that the $99/month for su­per­vised FSD will rise as FSDs ca­pa­bil­i­ties im­prove. The mas­sive value jump is when you can be on your phone or sleep­ing for the en­tire ride (unsupervised FSD).”

The quest for re­cur­ring rev­enue streams is be­com­ing some­thing of a holy grail in the au­to­mo­tive in­dus­try as OEMs that pre­vi­ously treated their cus­tomers as a sin­gle sale now hope to make them­selves more at­trac­tive to in­vestors by en­cour­ag­ing cus­tomers to give them reg­u­lar pay­outs.

This may have con­tributed to General Motors’ de­ci­sion to drop Apple CarPlay and Android Automotive. BMW has also ex­per­i­mented with sub­scrip­tion ser­vices. Tesla’s stock price re­mains so high that such games are prob­a­bly un­nec­es­sary here, but with falling profit mar­gins, de­clin­ing sales, and the loss of emis­sions cred­its to bol­ster the bot­tom line, one can see why reg­u­lar cash in­fu­sions from Tesla dri­vers would be de­sir­able.

...

Read the original on arstechnica.com »

7 276 shares, 22 trendiness

comma.ai — make driving chill

...

Read the original on comma.ai »

8 257 shares, 17 trendiness

Y Combinator

...

Read the original on www.ycombinator.com »

9 250 shares, 10 trendiness

What has Docker become?

It’s weird to see Docker Inc (the com­pany) strug­gle to find its place in 2026. What started as the com­pany that rev­o­lu­tion­ized how we de­ploy ap­pli­ca­tions has been through mul­ti­ple iden­tity crises, piv­ot­ing from one strat­egy to an­other in search of sus­tain­able rev­enue and mar­ket rel­e­vance.

Docker’s jour­ney reads like a startup try­ing to find prod­uct-mar­ket fit, ex­cept Docker al­ready had prod­uct-mar­ket fit - they cre­ated the con­tainer­iza­tion stan­dard that every­one uses. The prob­lem is that Docker the tech­nol­ogy be­came so suc­cess­ful that Docker the com­pany strug­gled to mon­e­tize it. When your core prod­uct be­comes com­modi­tized and open source, you need to find new ways to add value.

Docker Swarm was Docker’s at­tempt to com­pete with Kubernetes in the or­ches­tra­tion space. But Kubernetes won that bat­tle de­ci­sively, and Docker even­tu­ally sold Swarm. This was a clear sig­nal that Docker was step­ping back from try­ing to be the full-stack con­tainer plat­form and in­stead fo­cus­ing on what they could uniquely pro­vide.

For a while, Docker seemed to fo­cus on de­vel­oper ex­pe­ri­ence. This made sense - de­vel­op­ers are Docker’s core users, and im­prov­ing their work­flow could be a dif­fer­en­tia­tor. Docker Scout emerged from the ac­qui­si­tion of Atomist in June 2022, bring­ing software sup­ply chain” ca­pa­bil­i­ties. Scout al­lows Docker to see not just what’s in a con­tainer, but how it was built and where vul­ner­a­bil­i­ties are. This was a smart move to­ward se­cu­rity and ob­serv­abil­ity, ar­eas where Docker could add real value.

Docker also ac­quired AtomicJar, the com­pany be­hind Testcontainers, adding shift-left test­ing ca­pa­bil­i­ties. Testcontainers lets de­vel­op­ers run real de­pen­den­cies (databases, mes­sage queues, etc.) in con­tain­ers dur­ing test­ing, mak­ing in­te­gra­tion tests more re­li­able and closer to pro­duc­tion en­vi­ron­ments.

Then came the AI pivot. Docker Model Runner en­tered the scene, po­si­tion­ing Docker as a plat­form for run­ning AI mod­els. Docker Compose ex­panded to sup­port AI agents and mod­els. Docker Offload was in­tro­duced for cloud-scale GPU ex­e­cu­tion of AI tasks. Partnerships with Google Cloud, Microsoft Azure, and AI SDKs (CrewAI, LangGraph, Vercel AI SDK) fol­lowed.

The ac­qui­si­tion of MCP Defender in September 2025 fur­ther ce­mented Docker’s move into AI se­cu­rity, fo­cus­ing on se­cur­ing agen­tic AI in­fra­struc­ture and run­time threat de­tec­tion. This was a sig­nif­i­cant shift - from de­vel­oper tools to AI in­fra­struc­ture.

Suddenly, Docker moved into the hard­ened im­ages space. In December 2025, Docker made over 1,000 Docker Hardened Images free and open source un­der Apache 2.0, re­duc­ing vul­ner­a­bil­i­ties by up to 95% com­pared to tra­di­tional im­ages. This move was likely trig­gered by Chainguard’s suc­cess in the se­cure con­tainer im­age space. Chainguard had been build­ing a busi­ness around min­i­mal, se­cure con­tainer im­ages, and Docker needed to re­spond.

Making hard­ened im­ages free was a bold move - it’s hard to com­pete with free, es­pe­cially when it’s open source. But it also raises ques­tions about Docker’s busi­ness model. If you’re giv­ing away your se­cu­rity fea­tures for free, what are you sell­ing?

In February 2025, Docker re­placed CEO Scott Johnston (who led the com­pany since 2019) with Don Johnson, a for­mer Oracle Cloud Infrastructure founder and ex­ec­u­tive vice pres­i­dent. This lead­er­ship tran­si­tion has prompted tech an­a­lysts to an­tic­i­pate a po­ten­tial ac­qui­si­tion by a ma­jor cloud provider. The CEO swap, com­bined with the strate­gic piv­ots, sug­gests Docker may be po­si­tion­ing it­self for sale rather than build­ing a stand­alone busi­ness.

Docker’s strate­gic shifts tell a story of a com­pany search­ing for its place in a mar­ket it helped cre­ate. The con­tainer­iza­tion tech­nol­ogy Docker pi­o­neered be­came so suc­cess­ful that it be­came in­fra­struc­ture - some­thing every­one uses but no one wants to pay for di­rectly.

The piv­ots from or­ches­tra­tion (Swarm) to de­vel­oper tools (Scout, Testcontainers) to AI (Model Runner, MCP Defender) to se­cu­rity (Hardened Images) show a com­pany try­ing dif­fer­ent ap­proaches to find sus­tain­able rev­enue. Each pivot makes sense in iso­la­tion, but to­gether they paint a pic­ture of a com­pany with­out a clear long-term vi­sion.

The hard­ened im­ages move is par­tic­u­larly in­ter­est­ing be­cause it’s de­fen­sive - re­spond­ing to Chainguard’s suc­cess rather than lead­ing with in­no­va­tion. Making it free and open source is a strong com­pet­i­tive move, but it does­n’t solve the fun­da­men­tal busi­ness model ques­tion.

Docker the tech­nol­ogy is­n’t go­ing any­where. It’s too em­bed­ded in the in­fra­struc­ture of mod­ern soft­ware de­vel­op­ment. But Docker the com­pany? That’s less clear. The lead­er­ship change, ac­qui­si­tion spec­u­la­tion, and rapid strate­gic piv­ots sug­gest Docker Inc may be po­si­tion­ing it­self for an exit rather than build­ing a long-term in­de­pen­dent busi­ness.

For de­vel­op­ers, this does­n’t change much. Docker con­tain­ers will con­tinue to work, and the open source na­ture of Docker means the tech­nol­ogy will per­sist re­gard­less of what hap­pens to the com­pany. But it’s worth watch­ing how Docker Inc’s search for iden­tity plays out - it could af­fect the ecosys­tem of tools and ser­vices built around con­tain­ers.

The irony is that Docker cre­ated a stan­dard so suc­cess­ful that it be­came in­fra­struc­ture, and in­fra­struc­ture is hard to mon­e­tize. Docker Inc’s strug­gle to find its place is a cau­tion­ary tale about the chal­lenges of build­ing a busi­ness around open source tech­nol­ogy that be­comes too suc­cess­ful.

...

Read the original on tuananh.net »

10 246 shares, 11 trendiness

ramonvermeulen/whosthere: Local Area Network discovery tool with a modern Terminal User Interface (TUI) written in Go. Discover, explore, and understand your LAN in an intuitive way. Knock Knock.. who's there? 🚪

Local Area Network dis­cov­ery tool with a mod­ern Terminal User Interface (TUI) writ­ten in Go. Discover, ex­plore, and un­der­stand your LAN in an in­tu­itive way.

Whosthere per­forms un­priv­i­leged, con­cur­rent scans us­ing mDNS

and SSDP scan­ners. Additionally, it sweeps the lo­cal sub­net by at­tempt­ing TCP/UDP con­nec­tions to trig­ger ARP res­o­lu­tion, then reads the

ARP cache to iden­tify de­vices on your Local Area Network. This tech­nique pop­u­lates the ARP cache with­out re­quir­ing el­e­vated priv­i­leges. All dis­cov­ered de­vices are en­hanced with

OUI lookups to dis­play man­u­fac­tur­ers when avail­able.

Whosthere pro­vides a friendly, in­tu­itive way to an­swer the ques­tion every net­work ad­min­is­tra­tor asks: Who’s there on my net­work?”

* No Elevated Privileges Required: Runs en­tirely in user-space.

* Integrated Port Scanner: Optional ser­vice dis­cov­ery on found hosts (only scan de­vices with per­mis­sion!).

* Daemon Mode with HTTP API: Run in the back­ground and in­te­grate with other tools.

* Theming & Configuration: Personalize the look and be­hav­ior via YAML con­fig­u­ra­tion.

brew tap ra­mon­ver­meulen/​whos­there

brew in­stall whos­there

Or with Go:

go in­stall github.com/​ra­mon­ver­meulen/​whos­there@lat­est

git clone https://​github.com/​ra­mon­ver­meulen/​whos­there.git

cd whos­there

make build

whos­there

whos­there dae­mon –port 8080

Additional com­mand line op­tions can be found by run­ning:

whos­there –help

Whosthere is sup­ported on the fol­low­ing plat­forms:

* Windows (maybe in the fu­ture, con­tri­bu­tions wel­come!)

Whosthere can be con­fig­ured via a YAML con­fig­u­ra­tion file. By de­fault, it looks for the con­fig­u­ra­tion file in the fol­low­ing or­der:

* Path spec­i­fied in the WHOSTHERE_CONFIG en­vi­ron­ment vari­able (if set)

When not run­ning in TUI mode, logs are also writ­ten to the con­sole out­put.

Example of the de­fault con­fig­u­ra­tion file:

# How of­ten to run dis­cov­ery scans

scan_in­ter­val: 20s

# Maximum du­ra­tion for each scan

# If you set this too low some scan­ners or the sweeper might not com­plete in time

scan_­du­ra­tion: 10s

# Splash screen con­fig­u­ra­tion

splash:

en­abled: true

de­lay: 1s

# Theme con­fig­u­ra­tion

theme:

# Configure the theme to use for the TUI, com­plete list of avail­able themes at:

# https://​github.com/​ra­mon­ver­meulen/​whos­there/​tree/​main/​in­ter­nal/​ui/​theme/​theme.go

# Set name to custom” to use the cus­tom col­ors be­low

# For any color that is not con­fig­ured it will take the de­fault theme value as fall­back

name: de­fault

# Custom theme col­ors (uncomment and set name: cus­tom to use)

# prim­i­tive_back­ground_­color: #000a1a”

# con­trast_back­ground_­color: #001a33”

# more_­con­trast_back­ground_­color: #003366”

# bor­der_­color: #0088ff”

# ti­tle_­color: #00ffff”

# graph­ic­s_­color: #00ffaa”

# pri­ma­ry_­tex­t_­color: #cceeff”

# sec­ondary_­tex­t_­color: #6699ff”

# ter­tiary_­tex­t_­color: #ffaa00”

# in­verse_­tex­t_­color: #000a1a”

# con­trast_sec­ondary_­tex­t_­color: #88ddff”

# Scanner con­fig­u­ra­tion

scan­ners:

mdns:

en­abled: true

ssdp:

en­abled: true

arp:

en­abled: true

# Port scan­ner con­fig­u­ra­tion

port_s­can­ner:

time­out: 5s

# List of TCP ports to scan on dis­cov­ered de­vices

tcp: [21, 22, 23, 25, 80, 110, 135, 139, 143, 389, 443, 445, 993, 995, 1433, 1521, 3306, 3389, 5432, 5900, 8080, 8443, 9000, 9090, 9200, 9300, 10000, 27017]

# Uncomment the next line to con­fig­ure a spe­cific net­work in­ter­face - uses OS de­fault if not set

# net­work_in­ter­face: lo0

When run­ning Whosthere in dae­mon mode, it ex­poses an very sim­plis­tic HTTP API with the fol­low­ing end­points:

Theme can be con­fig­ured via the con­fig­u­ra­tion file, or at run­time via the CTRL+t key bind­ing. A com­plete list of avail­able themes can be found here, feel free to open a PR to add your own theme!

theme:

name: cy­ber­punk

When the name is set to cus­tom, the other color op­tions can be used to cre­ate your own cus­tom theme.

Logs are writ­ten to the ap­pli­ca­tion’s state di­rec­tory:

When not run­ning in TUI mode, logs are also out­put to the con­sole.

For clip­board func­tion­al­ity to work, a fork of go-clip­board is used. Ensure you have the ap­pro­pri­ate copy tool in­stalled for your OS:

Whosthere is in­tended for use on net­works where you have per­mis­sion to per­form net­work dis­cov­ery and scan­ning, such as your own home net­work. Unauthorized scan­ning of net­works may be il­le­gal and un­eth­i­cal. Always ob­tain proper au­tho­riza­tion be­fore us­ing this tool on any net­work.

Contributions and sug­ges­tions such as fea­ture re­quests, bug re­ports, or im­prove­ments are wel­come! Feel free to open is­sues or sub­mit pull re­quests on the GitHub repos­i­tory. Please make sure to dis­cuss any ma­jor changes on a Github is­sue be­fore im­ple­ment­ing them.

...

Read the original on github.com »

To add this web app to your iOS home screen tap the share button and select "Add to the Home Screen".

10HN is also available as an iOS App

If you visit 10HN only rarely, check out the the best articles from the past week.

If you like 10HN please leave feedback and share

Visit pancik.com for more.