10 interesting stories served every morning and every evening.




1 532 shares, 24 trendiness

Why xor eax, eax? — Matt Godbolt’s blog

Written by me, proof-read by an LLM.

Details at end.

In one of my talks on as­sem­bly, I show a list of the 20 most ex­e­cuted in­struc­tions on an av­er­age x86 Linux desk­top. All the usual cul­prits are there, mov, add, lea, sub, jmp, call and so on, but the sur­prise in­ter­loper is xor - eXclusive OR. In my 6502 hack­ing days, the pres­ence of an ex­clu­sive OR was a sure-fire in­di­ca­tor you’d ei­ther found the en­cryp­tion part of the code, or some kind of sprite rou­tine. It’s sur­pris­ing then, that a Linux ma­chine just mind­ing its own busi­ness, would be ex­e­cut­ing so many.

That is, un­til you re­mem­ber that com­pil­ers love to emit a xor when set­ting a reg­is­ter to zero:

We know that ex­clu­sive-OR-ing any­thing with it­self gen­er­ates zero, but why does the com­piler emit this se­quence? Is it just show­ing off?

In the ex­am­ple above, I’ve com­piled with -O2 and en­abled Compiler Explorer’s Compile to bi­nary ob­ject” so you can view the ma­chine code that the CPU sees, specif­i­cally:

If you change GCCs op­ti­mi­sa­tion level down to -O1 you’ll see:

The much clearer, more in­ten­tion-re­veal­ing mov eax, 0 to set the EAX reg­is­ter to zero takes up five bytes, com­pared to the two of the ex­clu­sive OR. By us­ing a slightly more ob­scure in­struc­tion, we save three bytes every time we need to set a reg­is­ter to zero, which is a pretty com­mon op­er­a­tion. Saving bytes makes the pro­gram smaller, and makes more ef­fi­cient use of the in­struc­tion cache.

It gets bet­ter though! Since this is a very com­mon op­er­a­tion, x86 CPUs spot this zeroing id­iom” early in the pipeline and can specif­i­cally op­ti­mise around it: the out-of-or­der track­ing sys­tems knows that the value of eax” (or whichever reg­is­ter is be­ing ze­roed) does not de­pend on the pre­vi­ous value of eax, so it can al­lo­cate a fresh, de­pen­dency-free zero reg­is­ter re­namer slot. And, hav­ing done that it re­moves the op­er­a­tion from the ex­e­cu­tion queue - that is the xor takes zero ex­e­cu­tion cy­cles! It’s es­sen­tially op­ti­mised out by the CPU!

You may won­der why you see xor eax, eax but never xor rax, rax (the 64-bit ver­sion), even when re­turn­ing a long:

In this case, even though rax is needed to hold the full 64-bit long re­sult, by writ­ing to eax, we get a nice ef­fect: Unlike other par­tial reg­is­ter writes, when writ­ing to an e reg­is­ter like eax, the ar­chi­tec­ture ze­ros the top 32 bits for free. So xor eax, eax sets all 64 bits to zero.

Interestingly, when ze­ro­ing the extended” num­bered reg­is­ters (like r8), GCC still uses the d (double width, ie 32-bit) vari­ant:

Note how it’s xor r8d, r8d (the 32-bit vari­ant) even though with the REX pre­fix (here 45) it would be the same num­ber of bytes to xor r8, r8 the full width. Probably makes some­thing eas­ier in the com­pil­ers, as clang does this too.

xor eax, eax saves you code space and ex­e­cu­tion time! Thanks com­pil­ers!

See the video that ac­com­pa­nies this post.

This post is day 1 of Advent of Compiler Optimisations 2025, a 25-day se­ries ex­plor­ing how com­pil­ers trans­form our code.

This post was writ­ten by a hu­man (Matt Godbolt) and re­viewed and proof-read by LLMs and hu­mans.

Support Compiler Explorer on Patreon

or GitHub, or by buy­ing CE prod­ucts in the Compiler Explorer Shop.

Matt Godbolt is a C++ de­vel­oper liv­ing in Chicago. He works for Hudson River Trading on su­per fun but se­cret things. He is one half of the Two’s Complement pod­cast. Follow him on Mastodon

or Bluesky.

...

Read the original on xania.org »

2 381 shares, 34 trendiness

Last Week on My Mac

Cast your mind back to when you learned to drive, ride a bike, speak a for­eign lan­guage, per­form a tra­cheostomy, or ac­quire any other skill. Wasn’t con­fi­dence the key to your suc­cess? Whatever we do in life, con­fi­dence is al­ways crit­i­cal. If you run a busi­ness, one of the met­rics that are likely to be col­lected is con­fi­dence in your busi­ness, as that’s such an im­por­tant eco­nomic in­di­ca­tor. Confidence is every bit as im­por­tant in com­put­ing.

Over the last few weeks I’ve been dis­cov­er­ing prob­lems that have been erod­ing con­fi­dence in ma­cOS. From text files that sim­ply won’t show up in Spotlight search, to Clock timers that are blank and don’t func­tion, there’s one com­mon fea­ture: ma­cOS en­coun­ters an er­ror or fault, but does­n’t re­port that to the user, in­stead just bury­ing it deep in the log.

When you can spare the time, the next step is to con­tact Apple Support, who seem equally puz­zled. You’re even­tu­ally ad­vised to re­in­stall ma­cOS or, in the worst case, to wipe a fairly new Apple sil­i­con Mac and re­store it in DFU mode, but have no rea­son to be­lieve that will stop the prob­lem from re­cur­ring. You know that Apple Support does­n’t un­der­stand what’s go­ing wrong, and de­spite the in­volve­ment of sup­port en­gi­neers, they seem as per­plexed as you.

One rea­son for this is that ma­cOS so sel­dom re­ports er­rors, and when it does, it’s un­in­for­ma­tive if not down­right mis­lead­ing. Here’s a small gallery of ex­am­ples I’ve en­coun­tered over the last few years, to bring back un­happy mem­o­ries.

Maybe you saved an im­por­tant web­page in Safari 26.1 us­ing its Web Archive for­mat, then a cou­ple of days later dis­cov­ered you could­n’t open it. There’s no er­ror mes­sage, just a blank win­dow, so you try again with the same re­sult. Another site shows the same prob­lem, forc­ing you to con­clude that it’s a bug in Safari. Are you now go­ing to de­vote your time to ob­tain­ing suf­fi­cient in­for­ma­tion to re­port that to Apple us­ing Feedback? Or to con­tact Apple Support and pur­sue its es­ca­la­tion to an en­gi­neer who might for­tu­itously dis­cover the cause?

Silent fail­ures like these are least likely to be re­ported to Apple. In most cases, we find our­selves a workaround, here to aban­don Web Archives and switch to sav­ing web­pages as PDF in­stead. When some­one else men­tions they too have the same prob­lem, we ad­vise them that Web Archives are bro­ken, and our loss of con­fi­dence spreads by con­ta­gion.

Honest and un­der­stand­able er­ror re­port­ing is es­sen­tial to con­fi­dence. It en­ables us to tackle prob­lems rather than just giv­ing up in frus­tra­tion, as­sum­ing that it’s yet an­other fea­ture we used to rely on that has suc­cumbed in the rush to get the next ver­sion of ma­cOS out of the door.

Eroding con­fi­dence is also a prob­lem that the ven­dors of AI ap­pear to have over­looked, or at least se­ri­ously un­der­es­ti­mated. It’s all very well us­ing the eu­phemism of hal­lu­ci­na­tion to play down the sever­ity of er­rors gen­er­ated by LLMs. But those can only cause users to lose con­fi­dence, no mat­ter how intelligent’ you might think your AI is be­com­ing. Go talk to the lawyers who have been caught out by courts sub­mit­ting AI fab­ri­ca­tions whether they still have full con­fi­dence in your prod­uct.

...

Read the original on eclecticlight.co »

3 328 shares, 21 trendiness

coder/ghostty-web: Ghostty for the web with xterm.js API compatibility

Ghostty for the web with xterm.js API com­pat­i­bil­ity — giv­ing you a proper VT100 im­ple­men­ta­tion in the browser.

* Migrate from xterm by chang­ing your im­port: @xterm/xterm → ghostty-web

* WASM-compiled parser from Ghostty—the same code that runs the na­tive app

Originally cre­ated for Mux (a desk­top app for iso­lated, par­al­lel agen­tic de­vel­op­ment), but de­signed to be used any­where.

Live Demo on an ephemeral VM (thank you to Greg from disco.cloud for host­ing).

npx @ghostty-web/demo@next

This starts a lo­cal HTTP server with a real shell on http://​lo­cal­host:8080. Works best on Linux and ma­cOS.

xterm.js is every­where—VS Code, Hyper, count­less web ter­mi­nals. But it has fun­da­men­tal is­sues:

xterm.js reim­ple­ments ter­mi­nal em­u­la­tion in JavaScript. Every es­cape se­quence, every edge case, every Unicode quirk—all hand-coded. Ghostty’s em­u­la­tor is the same bat­tle-tested code that runs the na­tive Ghostty app.

npm in­stall ghostty-web

ghostty-web aims to be API-compatible with the xterm.js API.

im­port { init, Terminal } from ghostty-web’;

await init();

const term = new Terminal({

font­Size: 14,

theme: {

back­ground: #1a1b26’,

fore­ground: #a9b1d6’,

term.open(doc­u­ment.getEle­ment­ById(‘ter­mi­nal’));

term.on­Data((data) => web­socket.send(data));

web­socket.on­mes­sage = (e) => term.write(e.data);

For a com­pre­hen­sive client server ex­am­ple, re­fer to the demo.

ghostty-web builds from Ghostty’s source with a patch to ex­pose ad­di­tional func­tion­al­ity.

bun run build

Mitchell Hashimoto (author of Ghostty) has been work­ing on libghostty which makes this all pos­si­ble. The patches are very min­i­mal thanks to the work the Ghostty team has done, and we ex­pect them to get smaller.

This li­brary will even­tu­ally con­sume a na­tive Ghostty WASM dis­tri­b­u­tion once avail­able, and will con­tinue to pro­vide an xterm.js com­pat­i­ble API.

At Coder we’re big fans of Ghostty, so ku­dos to that team for all the amaz­ing work.

...

Read the original on github.com »

4 326 shares, 23 trendiness

How to Attend Meetings

JavaScript is­n’t en­abled in your browser, so this file can’t be opened. Enable and re­load.

...

Read the original on docs.google.com »

5 313 shares, 14 trendiness

Google *unkills* JPEG XL?

I’ve writ­ten about JPEG XL in the past. First, I noted Google’s move to kill the for­mat in Chromium in fa­vor of the home­grown and in­fe­rior AVIF. Then, I had a deeper look at the for­mat, and vi­su­ally com­pared JPEG XL with AVIF on a hand­ful of im­ages.

The lat­ter post started with a quick sup­port test:

If you are brows­ing this page around 2023, chances are that your browser sup­ports AVIF but does not sup­port JPEG XL.”

Well, here we are at the end of 2025, and this very sen­tence still holds true. Unless you are one of the 17% of users us­ing Safari, or are ad­ven­tur­ous enough to use a niche browser like Thorium, LibreWolf or the newer Zen Browser, chances are you see the AVIF ban­ner in green and the JPEG XL im­age in black/​red.

The good news is, this will change soon. In a dra­matic turn of events, the Chromium team has re­versed its Obsolete tag, and has de­cided to sup­port the for­mat in Blink (the en­gine be­hind Chrome/Chromium/Edge). Given Chrome’s po­si­tion in the browser mar­ket share, I pre­dict the for­mat will be­come a de fac­tor stan­dard for im­ages in the near fu­ture.

I’ve been fol­low­ing JPEG XL since its ex­per­i­men­tal sup­port in Blink. What started as a promis­ing fea­ture was quickly axed by the team in a bizarre and ridicu­lous man­ner. First, they asked the com­mu­nity for feed­back on the for­mat. Then, the com­mu­nity re­sponded very pos­i­tively. And I don’t only mean a cou­ple of guys in their base­ment. Meta, Intel, Cloudinary, Adobe, ffm­peg, lib­vips, Krita, and many more. After that came the in­fa­mous com­ment:

Thank you every­one for your com­ments and feed­back re­gard­ing JPEG XL. We will be re­mov­ing the JPEG XL code and flag from Chromium for the fol­low­ing rea­sons:Ex­per­i­men­tal flags and code should not re­main in­def­i­nite­lyThere is not enough in­ter­est from the en­tire ecosys­tem to con­tinue ex­per­i­ment­ing with JPEG XLThe new im­age for­mat does not bring suf­fi­cient in­cre­men­tal ben­e­fits over ex­ist­ing for­mats to war­rant en­abling it by de­faultBy re­mov­ing the flag and the code in M110, it re­duces the main­te­nance bur­den and al­lows us to fo­cus on im­prov­ing ex­ist­ing for­mats in Chrome

Yes, right, not enough in­ter­est from the en­tire ecosys­tem”. Sure.

Anyway, fol­low­ing this com­ment, a steady stream of mes­sages pointed out how wrong that was, from all the or­ga­ni­za­tions men­tioned above and many more. People were notic­ing in blog posts, videos, and so­cial me­dia in­ter­ac­tions.

Strangely, the fol­low­ing few years have been pretty calm for JPEG XL. However, a few no­table events did take place. First, the Firefox team showed in­ter­est in a JPEG XL Rust de­coder, af­ter de­scrib­ing their stance on the mat­ter as neutral”. They were con­cerned about the in­creased at­tack sur­face re­sult­ing from in­clud­ing the cur­rent 100K+ lines C++ lib­jxl ref­er­ence de­coder, even though most of those lines are test­ing code. In any case, they kind of re­quested a memory-safe” de­coder. This seems to have kick-started the Rust im­ple­men­ta­tion, jxl-rs, from Google Research.

To top it off, a cou­ple of weeks ago, the PDF Association an­nounced their in­tent to adopt JPEG XL as a pre­ferred im­age for­mat in their PDF spec­i­fi­ca­tion. The CTO of the PDF Association, Peter Wyatt, ex­pressed their de­sire to in­clude JPEG XL as the pre­ferred for­mat for HDR con­tent in PDF files.

All of this pres­sure ex­erted steadily over time made the Chromium team re­con­sider the for­mat. They tried to kill it in fa­vor of AVIF, but that has­n’t worked out. Rick Byers, on be­half of Chromium, made a com­ment in the Blink de­vel­op­ers Google group about the team wel­com­ing a per­for­mant and mem­ory-safe JPEG XL de­coder in Chromium. He stated that the change of stance was in light of the pos­i­tive signs from the com­mu­nity we have ex­posed above (Safari sup­port, Firefox up­dat­ing their po­si­tion, PDF, etc.). Quickly af­ter that, the Chromium is­sue state was changed from Obsolete to Assigned.

This is great news for the for­mat, and I be­lieve it will give it the fi­nal push for mass adop­tion. The for­mat is ex­cel­lent for all kinds of pur­poses, and I’ll be adopt­ing it pretty much in­stantly for this and the Gaia Sky web­site when sup­port is shipped. Some of the fea­tures that make it su­pe­rior to the com­pe­ti­tion are:

* Lossless re-com­pres­sion of JPEG im­ages. This means you can re-com­press your cur­rent JPEG li­brary with­out los­ing in­for­ma­tion and ben­e­fit from a ~30% re­duc­tion in file size for free. This is a killer fea­ture that no other for­mat has.

* Support for im­age sizes of up to 1,073,741,823x1,073,741,824. You won’t run out of im­age space any­time soon. AVIF is ridicu­lous in this as­pect, cap­ping at 8,193x4,320. WebP goes up to 16K2, while the orig­i­nal 1992 JPEG sup­ports 64K2.

* Maximum of 32 bits per chan­nel. No other for­mat (except for the de­funct JPEG 2000) of­fers this.

* Maximum of 4,099 chan­nels. Most other for­mats sup­port 4 or 5, with the ex­cep­tion of JPEG 2000, which sup­ports 16,384.

* JXL sup­ports pro­gres­sive de­cod­ing, which is es­sen­tial for web de­liv­ery, IMO. WebP or HEIC have no such fea­ture. Progressive de­cod­ing in AVIF was added a few years back.

For a full codec fea­ture break­down, see Battle of the Codecs.

JPEG XL is the fu­ture of im­age for­mats. It checks all the right boxes, and it checks them well. Support in the over­whelm­ingly most pop­u­lar browser en­gine is prob­a­bly go­ing to be a cru­cial step­ping stone in the for­mat’s path to star­dom. I’m happy that the Chromium team re­con­sid­ered their in­clu­sion, but I am sad that it took so long and so much pres­sure from the com­mu­nity to achieve it.

...

Read the original on tonisagrista.com »

6 304 shares, 14 trendiness

For Decades, Cartographers Have Been Hiding Covert Illustrations Inside of Switzerland’s Official Maps

The first three di­men­sions—length, height, and depth—are in­cluded on all topo­graph­i­cal maps. The fourth di­men­sion,” or time, is also avail­able on the web­site of the Swiss Federal Office of Topography (Swisstopo). In the Journey Through Time,” a time­line dis­plays 175 years of the coun­try’s car­to­graphic his­tory, ad­vanc­ing in in­cre­ments of 5-10 years. Over the course of two min­utes, Switzerland is drawn and re­drawn with in­creas­ing pre­ci­sion: inky shapes take on hard edges, blues and browns ap­pear af­ter the turn of the cen­tury, and in 2016, the let­ters drop their ser­ifs.

Watching a sin­gle place evolve over time re­veals small his­to­ries and gran­u­lar in­con­sis­ten­cies. Train sta­tions and air­ports are built, a gun­pow­der fac­tory dis­ap­pears for the length of the Cold War. But on cer­tain maps, in Switzerland’s more re­mote re­gions, there is also, cu­ri­ously, a spi­der, a man’s face, a naked woman, a hiker, a fish, and a mar­mot. These barely-per­cep­ti­ble ap­pari­tions aren’t mis­takes, but rather il­lus­tra­tions hid­den by the of­fi­cial car­tog­ra­phers at Swisstopo in de­fi­ance of their man­date to re­con­sti­tute re­al­ity.” Maps pub­lished by Swisstopo un­dergo a rig­or­ous proof­read­ing process, so to find an il­licit draw­ing means that the car­tog­ra­pher has out­smarted his col­leagues.

It also im­plies that the map­maker has openly vi­o­lated his com­mit­ment to ac­cu­racy, risk­ing pro­fes­sional reper­cus­sions on ac­count of an alpine ro­dent. No car­tog­ra­pher has been fired over these draw­ings, but then again, most were only dis­cov­ered once their au­thor had al­ready left. (Many map­mak­ers timed the pub­li­ca­tion of their draw­ing to co­in­cide with their re­tire­ment.) Over half of the known il­lus­tra­tions have been re­moved. The lat­est, the mar­mot draw­ing, was dis­cov­ered by Swisstopo in 2016 and is likely to be elim­i­nated from the next of­fi­cial map of Switzerland by next year. As the spokesper­son for Swisstopo told me, Creativity has no place on these maps.”

Errors—both ac­ci­den­tal and de­lib­er­ate—are not un­com­mon in maps (17th-century California as an is­land, the omis­sion of Seattle in a 1960s AAA map). Military cen­sors have long trans­formed nu­clear bunkers into non­de­script ware­houses and rou­tinely pix­e­late satel­lite im­ages of sen­si­tive sites. Many maps also con­tain in­ten­tional er­rors to trap would-be copy­right vi­o­la­tors. The work of record­ing re­al­ity is par­tic­u­larly vul­ner­a­ble to pla­gia­rism: if a car­tog­ra­pher is sus­pected of copy­ing an­oth­er’s work, he can sim­ply claim to be du­pli­cat­ing the real world— ide­ally, the two should be the same. Mapmakers of­ten rely on fic­ti­tious streets, typ­i­cally no longer than a block, to dif­fer­en­ti­ate their ac­counts of the truth (Oxygen Street in Edinburgh, for ex­am­ple).

Their en­tire pro­fes­sional life is spent at the mag­ni­fi­ca­tion level of a postage stamp.

But there is an­other, less in­sti­tu­tional rea­son to hide some­thing in a map. According to Lorenz Hurni, pro­fes­sor of car­tog­ra­phy at ETH Zurich, these il­lus­tra­tions are part in­side joke, part cop­ing mech­a­nism. Cartographers are quite metic­u­lous, re­ally high-pre­ci­sion peo­ple,” he says. Their en­tire pro­fes­sional life is spent at the mag­ni­fi­ca­tion level of a postage stamp. To sus­tain this kind of con­cen­tra­tion, Hurni sus­pects that they even­tu­ally look for some­thing to break out of their daily rou­tine.” The sat­is­fac­tion of these il­lus­tra­tions comes from their trans­gres­sive na­ture— the la­bor and se­crecy re­quired to con­ceal one of these vi­sual puns.

And some of them en­joy re­mark­able longevity. The naked woman draw­ing, for ex­am­ple, re­mained hid­den for al­most sixty years in the mu­nic­i­pal­ity of Egg, in north­ern Switzerland. Her rel­a­tively un­der­stated shape was com­posed in 1958 from a swath of green coun­try­side and the blue line of a river, her knees bend­ing at the curve in the stream. She re­mained un­no­ticed, re­clin­ing peace­fully, un­til 2012.

Several of the other draw­ings came about con­sid­er­ably later. In 1980, a Swisstopo car­tog­ra­pher traced the spi­der over an arach­nid-shaped ice field on the Eiger moun­tain. It faded out over the course of the decade, re­tract­ing its spindly legs in the in­ter­me­di­ary edi­tions. Around the same time, an­other car­tog­ra­pher con­cealed a fresh­wa­ter fish in a French na­ture pre­serve along the Swiss bor­der. The fish lived in the blue cir­cum­fer­ence of a marshy lake un­til 1989 when, ac­cord­ing to Swisstopo, it dis­ap­peared from the sur­face of the lake, div­ing to the depths.”

It’s un­clear how these draw­ings made it past the in­sti­tute’s proof­read­ers in the first place. They may have been in­serted only af­ter the maps were ap­proved, when car­tog­ra­phers are asked to ap­ply the proof­read­ers’ fi­nal ed­its. When the maps were once printed as com­pos­ite lay­ers of dif­fer­ent col­ors, car­tog­ra­phers could have built the draw­ings from the in­ter­play of dif­fer­ent topo­graph­i­cal el­e­ments (the naked woman, for ex­am­ple, is com­posed of a blue line over a green-shaded area). Hurni also spec­u­lates that car­tog­ra­phers could have par­ti­tioned their il­lus­tra­tions over the cor­ners of four sep­a­rate map sheets, al­though no such ex­am­ple has (yet) been found.

Some of these clan­des­tine draw­ings al­lude to ac­tual topo­graph­i­cal fea­tures: near the town of Interlaken, where an out­crop­ping of stones ap­prox­i­mates two eyes and a nose, the 1980 edi­tion of the map fea­tures an an­gu­lar car­toon face be­tween the trees. (According to lo­cal leg­end, it’s a monk who was turned to stone as pun­ish­ment for chas­ing a young girl off the cliff.) In the late 1990s, the same car­tog­ra­pher drew a hiker in the map’s mar­gins. With boots each about the size of a house, the hiker serves a prag­matic pur­pose. Like a kind of topo­graphic patch, he cov­ers an area in the Italian Alps where the Swiss ap­par­ently lacked the nec­es­sary information and data from the Italian ge­o­graph­i­cal ser­vices.”

The mar­mot, the lat­est il­lus­tra­tion, hides in plain sight in the Swiss Alps. His plump out­line was con­cealed in the del­i­cate re­lief shad­ing above a glac­ier, which shielded him from de­tec­tion for nearly five years. The moun­tain’s hachures— short, par­al­lel lines that in­di­cate the an­gle and ori­en­ta­tion of a slope— dou­ble as his fur. He is mostly in­dis­tin­guish­able from the sur­round­ing rock, ex­cept for his face, tail, and paws. He even fits eco­log­i­cally: as an an­i­mal of the ice age, alpine mar­mots are com­fort­able at high al­ti­tudes, bur­row­ing into frozen rock for their nine months of hi­ber­na­tion. In 2016, Hurni re­vealed his lo­ca­tion to the pub­lic on be­half of an un­named source.

There is a de­gree of wink­ing tol­er­ance for these draw­ings, which con­sti­tute some­thing of an un­of­fi­cial na­tional tra­di­tion: the spokes­woman for Swisstopo re­ferred me to a 1901 fish hid­den in a well-known paint­ing of Lake Lucerne at the National Council palace (probably in honor of the palace’s April 1st in­au­gu­ra­tion, which some European coun­tries cel­e­brate by at­tach­ing April Fish” to the backs of shirts). Nevertheless, the mar­mot—along with the face and hiker—will likely be eliminated” from Switzerland’s next of­fi­cial map (per a de­ci­sion from the chief of car­tog­ra­phy).

Swiss car­tog­ra­phers have a long­stand­ing rep­u­ta­tion for topo­graph­i­cal rigor. A so-called Seven Years War of Cartography” was even waged in the 1920s over the scale of the na­tional maps, with the Swiss Alpine Club ad­vo­cat­ing greater topo­graph­i­cal de­tail for its moun­taineer­ing mem­bers. Swisstopo is now an in­dus­try bench­mark for the moun­tains, from its use of aer­ial pho­togram­me­try (images taken first by bal­loons and then small planes) to aer­ial per­spec­tive (that nat­ural hazi­ness that ren­ders dis­tant peaks with less con­trast). In 1988, they were com­mis­sioned to draw Mount Everest.

Still, the orig­i­nal draw­ings were never au­tho­rized in the first place. Perhaps a metic­u­lous read­ing of next year’s Swiss maps may re­veal some other na­tion­ally-cel­e­brated an­i­mals in un­fre­quented bod­ies of wa­ter or alpine mead­ows. As Juerg Gilgen, a cur­rent car­tog­ra­pher at Swisstopo, told me as a mat­ter of fact, the proof-reader is also just a hu­man be­ing prone to fail­ure. And car­tog­ra­phers are also just hu­man be­ings try­ing to fool around.”

...

Read the original on eyeondesign.aiga.org »

7 259 shares, 15 trendiness

High-income job losses are cooling housing demand

Skip to con­tent

Most met­ros are adding jobs more slowly than nor­mal. Char­lotte leads in job growth among ma­jor met­ros, while Austin and Denver fall far short of their his­tor­i­cally strong pace.

High-income sec­tors are con­tract­ing, while Education and Healthcare are ex­pand­ing faster than nor­mal across most met­ros.

Employment com­po­si­tion mat­ters as much as to­tal growth for lo­cal hous­ing mar­ket strength. Met­ros re­liant on lower-wage job growth are likely to face softer for-sale de­mand.

The na­tional la­bor mar­ket is soft­en­ing, with im­pli­ca­tions for lo­cal hous­ing mar­kets. Most ma­jor met­ros are adding jobs more slowly than nor­mal. We an­a­lyzed em­ploy­ment per­for­mance by metro and in­dus­try, com­par­ing to­day’s growth to long-term trends since 2010. Red rep­re­sents job losses, yel­low shows slower-than-nor­mal growth, and green rep­re­sents faster-than-nor­mal growth.

The job mar­ket dri­ves hous­ing de­mand, but the type of jobs cre­ated or lost im­pacts the type of hous­ing. High-income sec­tors—In­for­ma­tion, Professional Services, and Financial Activities—are shrink­ing across most ma­jor met­ros. Workers in these in­dus­tries drive for-sale hous­ing de­mand more than rental de­mand. Nationally, high-in­come sec­tor em­ploy­ment re­mained flat YOY in August, well be­low its long-term com­pound an­nual growth of +1.6%.The Education and Healthcare sec­tors ac­count for the bulk of new jobs added in most met­ros and are grow­ing faster than nor­mal in al­most every mar­ket. Many of these jobs pay lower wages on av­er­age and of­ten gen­er­ate rental de­mand more than home­buy­ing ac­tiv­ity. Nationally, ed­u­ca­tion and health­care em­ploy­ment rose +3.3% YOY in August, well above its long-term com­pound an­nual growth of +2.1%

Philadelphia (+1.8% YOY) and New York (+1.7% YOY) show stronger job growth than their his­tor­i­cal trends (+1.1% and +1.6%, re­spec­tively). However, this im­prove­ment re­flects re­cov­ery from weak post-Great Financial Crisis base­lines rather than gen­uine out­per­for­mance. Charlotte (+2.6% YOY) is a stand­out per­former, main­tain­ing ro­bust job growth sup­ported by Professional Services ex­pan­sion (+4.5% YOY)—a rare bright spot for for-sale de­mand.Austin (+0.8% YOY) and Den­ver (+0.0% YOY) are grow­ing much more slowly than their his­tor­i­cally strong em­ploy­ment trends (+3.8% and +2.3%, re­spec­tively). Tech and Professional Services jobs are de­clin­ing in both mar­kets, and even health­care—which is ex­pand­ing faster than nor­mal in most met­ros—shows weak growth here. This re­duc­tion in high-pay­ing jobs is weak­en­ing de­mand for both home pur­chases and rentals.The Bay Area continues to lose jobs across high-in­come sec­tors (-0.4% YOY), dri­ving mod­est over­all em­ploy­ment de­clines. These job losses have slowed com­pared to a year ago but re­main neg­a­tive YOY. Despite gen­er­at­ing sub­stan­tial spend­ing and wealth, the AI-driven tech boom has­n’t added mean­ing­ful em­ploy­ment to the re­gion.

What this means for your busi­ness

Whether you build, in­vest, or ad­vise in hous­ing mar­kets, these em­ploy­ment shifts will im­pact your growth op­por­tu­ni­ties in 2026 and be­yond:Rental op­er­a­tors: Pre­pare for sus­tained de­mand from renters em­ployed in health­care and ed­u­ca­tion.

Our Metro and Regional Housing re­search pack­age in­cludes analy­sis of the lat­est de­mand, sup­ply, and af­ford­abil­ity fun­da­men­tals for each metro and re­gion as well as re­sults from our pro­pri­etary sur­veys. Our consulting team con­tin­u­ally eval­u­ates mar­ket fea­si­bil­ity, ab­sorp­tion/​pric­ing/​prod­uct rec­om­men­da­tions, and over­all in­vest­ment/​ex­pan­sion strat­egy in mar­kets na­tion­wide. Combining these two ar­eas of ex­per­tise yields qual­i­ta­tive and quan­ti­ta­tive in­sight for more in­tel­li­gent de­ci­sion-mak­ing.

This pack­age pro­vides a com­plete pic­ture of hous­ing sup­ply, de­mand, and af­ford­abil­ity through lo­cal in­sight, pro­pri­etary sur­veys, and ex­ten­sive data analy­sis. We cur­rently pro­vide an overview of ma­jor hous­ing and eco­nomic trends across 100 MSAs na­tion­wide.

Our re­search ser­vices en­able our clients to gauge hous­ing mar­ket con­di­tions and bet­ter align their busi­ness and strate­gic in­vest­ments in the hous­ing in­dus­try. We pro­vide a thought­ful and unique holis­tic ap­proach of both quan­ti­ta­tive and qual­i­ta­tive analy­sis to help clients make in­formed hous­ing in­vest­ment de­ci­sions.

Our ex­pe­ri­enced team of con­sul­tants helps clients make sound hous­ing in­vest­ment de­ci­sions. We thrive on their suc­cess and work with many clients over mul­ti­ple years and nu­mer­ous pro­jects. ​

Connect with me on LinkedIn

John leads JBRECs Southern California mar­ket cov­er­age for the Metro Analysis and Forecast re­ports, pro­duces the Regional Analysis and Forecast and Homebuilder Analysis and Forecast re­ports, and as­sists with cov­er­age of the pub­lic home­builder space.

If you have any ques­tions about our ser­vices or if you would like to speak to one of our ex­perts about we can help your busi­ness, please con­tact Client Relations at clientser­vices@jbrec.com.

Want to in­ter­view one of our ex­perts?

Media pro­fes­sion­als seek­ing ex­pert analy­sis and au­thor­i­ta­tive com­men­tary on US hous­ing mar­ket trends, pol­icy im­pacts, and in­dus­try de­vel­op­ments can email our team for in­ter­views, quotes, and data-dri­ven in­sights.

Every week, we de­liver analy­sis to over 40,000 sub­scribers with our Building Market Intelligence™ newslet­ter. Subscribe to our weekly BMI newslet­ters to stay cur­rent on press­ing top­ics in the hous­ing in­dus­try.

What’s ahead for hous­ing—In­sights from our 2026 Housing Market Outlook con­fer­ence

...

Read the original on jbrec.com »

8 254 shares, 10 trendiness

Self-hosting a Matrix server for 5 years

Experiences with the Matrix pro­to­col, Matrix Synapse server, bridges, and Element mo­bile apps.

I have been host­ing a Matrix server for about five years now, mostly for text chats be­tween a few rel­a­tives and close friends, and a bridge to WhatsApp for a few more peo­ple. These are my ex­pe­ri­ences.

I don’t have many thoughts on the pro­to­col it­self.

The only thing that I don’t re­ally un­der­stand is the de­ci­sion on data repli­ca­tion. If a user on server A joins a room on server B, re­cent room data is copied from server B to server A and then kept in sync on both servers. I sup­pose this re­duces the load on the orig­i­nal server at the ex­pense of fed­er­a­tion over­head and space on other servers. However, this also cre­ates a sit­u­a­tion where any­thing said across fed­er­a­tion can­not be un­said, which is an ironic sit­u­a­tion for a pro­to­col/​sys­tem that of­ten comes up when talk­ing about pri­vacy.

Synapse is the only choice that sup­ports bridges, which was why I wanted to try Matrix in the first place. And back in 2019-2020 this was the only choice any­way.

As of right now, I run Synapse, PostgreSQL, and co­turn di­rectly, with­out con­tainer­iza­tion, on a small VPS.

Works fairly re­li­ably, sup­ports bridges, and is more ef­fi­cient that it was in 2020.

API is well doc­u­mented, and al­lows au­then­ti­cat­ing and send­ing (unencrypted) mes­sages via sim­ple HTTP calls. At some point in time, I wanted to write a sim­ple shell client to use with SXMO and such.

Does not have an ad­min panel

There is no ad­min page or panel. There was a third-party ad­min site, but it’s an en­tire site just for mak­ing HTTP calls. So I ended up writ­ing my own.

While tech­ni­cally, Synapse can work with a sqlite data­base (and which at first seems like an OK choice for hav­ing

Initial setup pre­sumes that the server is go­ing to be fed­er­ated, and there is no good way to turn it off. The best workaround in­volves a blank whitelist of fed­er­ated servers.

I don’t know the im­pli­ca­tions of dis­abling it.

Message re­ten­tion pol­icy can be set up server-wide, but also per-room. There are spe­cific lines in the con­fig­u­ra­tion that need to be set to ac­tu­ally en­able a ser­vice that runs the cleanup.

Synapse keeps the room even af­ter all of the mem­bers leave it, in­clud­ing fed­er­ated rooms. This re­sults in many (sometimes large) rooms with­out lo­cal mem­bers or­phaned on the server, tak­ing up data­base space.

Deleting mes­sages (events) with at­tach­ments does not delete the at­tach­ment (because an­other mes­sage might re­fer to it?), which means that the sent files con­tinue ex­ist­ing on the server in­def­i­nitely. Another pri­vacy im­pli­ca­tion. A sim­ple delete all files older than X” script works great un­til it deletes avatars. So yeah, seems like this is some­thing that should be han­dled by the Synapse server in­stead of cob­bled-to­gether scripts.

Even af­ter ex­ten­sive cleanup, PostgreSQL data­base might need to be vac­u­umed to re­duce the disk space it takes up.

Even for my small server with

Synapse keeps track of room states in an ap­pend-only (!) table named state_­group­s_s­tate. Deleting a room does not delete the state_­group­s_s­tate records. So it is never au­to­mat­i­cally cleaned up, and grows in size in­fi­nitely. It is pos­si­ble to delete many of those records from the data­base di­rectly, and Element (the com­pany) pro­vides some tool to compress” those records, but again, some­thing that should be han­dled by the server.

This is sim­ply not an op­tion in the API. Server ad­min can per­form a deactivate” (disable lo­gin) and erase” (remove re­lated data, which claims to be GDPR-compliant) on user ac­counts, but the ac­counts them­selves stay on the server for­ever.

How this not con­sid­ered a GDPR vi­o­la­tion is a mys­tery to me. Even on my tiny server, I have users who use their first name as their ID and bridged WhatsApp users that use phone num­bers as IDs.

While Matrix-Element ecosys­tem has been cater­ing to­wards gov­ern­ment and cor­po­rate en­ti­ties for some time, there have been mul­ti­ple re­cent an­nounce­ments about its fu­ture.

Specifically, Element (the com­pany) is now pro­vid­ing an all-in-one Element Server Suite (ESS) to re­place the cur­rent setup, in­clud­ing

It is in­tended for non-pro­fes­sional use, eval­u­a­tions, and small to mid-sized de­ploy­ments (1–100 users).

ESS Community in­cludes 7 com­po­nents/​ser­vices, now re­quires a min­i­mum of 2 CPUs, 2GB of RAM, and runs us­ing… Kubernetes? IMO, this is an overkill for dozen users.

For com­par­i­son, Snikket, an all-in-one so­lu­tion with sim­i­lar func­tion­al­ity us­ing XMPP, re­quires a sin­gle CPU and 128MB (!) RAM for 10 or so users.

Yes, I have seen the an­si­ble setup script setup rec­om­mended, but at this point, mak­ing setup eas­ier does not ad­dress the is­sue of ex­tra ser­vices be­ing re­quired in the first place.

Also, the ESS han­dles ac­count cre­ation and calls in an en­tirely dif­fer­ent way, more on that later.

Pretty great. Easy to in­stall and set up, works re­ally well, and needs only oc­ca­sional (semi-yearly or so) up­dates when WhatsApp changes their web API. Does not sup­port calls.

Same on all plat­forms

Element ex­ists and looks con­sis­tent on Android, iOS, and web, mak­ing it eas­ier for reg­u­lar users and for trou­bleshoot­ing.

This is silly, but while (official?) bridges sup­port im­age cap­tions, of­fi­cial Element app does not. The an­swer in the FAQ? Get a bet­ter app. Well, OK.

Image with a cap­tion in SchildiChat Classic (the bet­ter app).

Sometimes it can take up to a few min­utes to get a mes­sage, even be­tween two Android clients us­ing Google Cloud Messaging. Sometimes it is nearly in­stant. Still un­sure of the cause.

One un­re­li­able way to tell that the server is un­reach­able is the end­less load­ing bar. But even then, it even­tu­ally goes away with­out in­di­cat­ing any er­rors.

Then, when send­ing a mes­sage, the user re­ceives Unable to send mes­sage”. Frustration en­sues.

But I know the app is try­ing to call the /sync end­point. Why does­n’t it show any er­rors when that fails?

IIRC the first thing the app does is ask user to back up their sign­ing keys and en­ter the key pass­word, with­out a sim­ple ex­pla­na­tion. Not a great ex­pe­ri­ence for reg­u­lar users.

Some peo­ple re­ported is­sues with Element los­ing its keys or fre­quently re­quest­ing to be re-ver­i­fied. Thankfully I have not en­coun­tered these.

Even if you con­nect to a self-hosted server, Element Classic could at­tempt to con­nect to vec­tor.im in­te­gra­tion server and ma­trix.org key backup server.

Element X is now rec­om­mended as the new and bet­ter client. It is not.

Somehow, it is slower. Clicking on a con­ver­sa­tion takes 0.5-1.0 sec­onds to load it, com­pared to al­most in­stant load on Classic.

Perhaps it does work bet­ter for ac­counts with many large rooms, but that is not my case.

Conversations are sorted by… who knows. It is not re­cent nor al­pha­bet­i­cal.

Element X does not sup­port pe­ri­odic back­ground sync, so you need to set up ntfy or some­thing sim­i­lar to use Element X on a de-googled de­vice. Seems like a sim­ple enough fail-safe (even WhatsApp does this), but it was dropped for some rea­son.

This sliding sync” op­tion is avail­able only for newer Synapse ver­sions, and only if run­ning with PostgreSQL data­base (which should al­ready be the case - see above). Probably not an is­sue un­less the user tries to con­nect Element X to an out­dated Synapse.

Calling with Element X re­quires Element Call (part of ESS). This sup­ports group calls, but… only video calls at the mo­ment.

You also might be asked to tell your con­tact to in­stall the new app:

I don’t reg­u­larly use calls, but some peo­ple I would like to in­vite to my server would want to use them.

A few years ago, I ended up ei­ther tem­porar­ily en­abling un­re­stricted reg­is­tra­tion (a ter­ri­ble idea), or cre­at­ing my users’ ac­counts man­u­ally, be­cause the invite” ma­trix.to link was bro­ken, and reg­is­tra­tion to­kens did not work cor­rectly in mo­bile apps.

So let’s see how it works now. Keep in mind, I am still on stand­alone Synapse, not ESS.

I am a user, and I was to reg­is­ter an ac­count on my friend’s server. I see that Element X is now a rec­om­mended app, so let’s try that.

Click Create ac­count” (which is a dif­fer­ent style that does not look like a but­ton for some rea­son).

But I want an ac­count on a dif­fer­ent server. Click Change ac­count provider”.

Now I can search for the server my friend is host­ing, and it should ap­pear in the list be­low the search.

As server ad­min: I do not re­mem­ber if Synapse server has to en­able/​keep fed­er­a­tion for this to work.

Yes! That is what I want, why is this so ver­bose?

WTF. So Element X can­not cre­ate even the sim­plest user­name+pass­word ac­count. That is all I want, I don’t want to sign in with Google, Apple, or any other form of third-party au­then­ti­ca­tion.

I was un­able to reg­is­ter an ac­count us­ing Element X, so Element Classic should work bet­ter.

What dif­fer­ence does this make? Skip.

The cur­rent of­fi­cial app is telling me to use Element X. Just tried that. Click EDIT where it says matrix.org” (which does not say server”, ac­tu­ally) and en­ter the server name.

Why not? No ex­pla­na­tion. Sure, I’ll use a web client.

Well, fuck me, I guess. Why can’t I just cre­ate an ac­count?

As a server ad­min: Synapse is set to al­low reg­is­tra­tions via reg­is­tra­tion to­kens, be­cause un­re­stricted reg­is­tra­tion is a bad idea. I did not find where the /static/client/register path is set.

IIRC it is pos­si­ble to reg­is­ter an ac­count by go­ing to a web-hosted Element app, such as app.el­e­ment.io, which will al­low to reg­is­ter an ac­count us­ing a reg­is­tra­tion to­ken. But then the user has to deal with the headache of cross-ver­i­fy­ing their mo­bile de­vice to the web app (which they might never use).

So now what?

Matrix-Element is grow­ing, build­ing new fea­tures, and ac­quir­ing large cus­tomers (mostly gov­ern­ment en­ti­ties AFAIK). However, the new cor­po­ratesque ESS Community is not worth it in my opin­ion. I don’t need fancy auth, third-party IDs, group video con­fer­enc­ing, or even fed­er­a­tion for that mat­ter. But it is clear that Synapse and Element X are se­verely crip­pled and are not de­signed to work with­out these ser­vices.

I will prob­a­bly switch to Snikket, which is more ef­fi­cient, has timely no­ti­fi­ca­tions, and very smooth on­board­ing.

...

Read the original on yaky.dev »

9 250 shares, 14 trendiness

Why Am I Paying $40,000 for the Birth of My Child?

I had never heard of Michael Green be­fore his now-in­fa­mous es­say Part 1: My Life Is a Lie - How a Broken Benchmark Quietly Broke America” went ex­tremely vi­ral on X.

Go read it. The short ver­sion: real poverty is closer to $140,000 than $31,000.

The U. S. poverty line is cal­cu­lated as three times the cost of a min­i­mum food diet in 1963, ad­justed for in­fla­tion.”

The com­po­si­tion of house­hold spend­ing trans­formed com­pletely. In 2024, food-at-home is no longer 33% of house­hold spend­ing. For most fam­i­lies, it’s 5 to 7 per­cent.

Housing now con­sumes 35 to 45 per­cent. Healthcare takes 15 to 25 per­cent. Childcare, for fam­i­lies with young chil­dren, can eat 20 to 40 per­cent.

If you keep Orshansky’s logic—if you main­tain her prin­ci­ple that poverty could be de­fined by the in­verse of food’s bud­get share—but up­date the food share to re­flect to­day’s re­al­ity, the mul­ti­plier is no longer three.

Which means if you mea­sured in­come in­ad­e­quacy to­day the way Orshansky mea­sured it in 1963, the thresh­old for a fam­ily of four would­n’t be $31,200.

It would be some­where be­tween $130,000 and $150,000.

And re­mem­ber: Orshansky was only try­ing to de­fine too lit­tle.” She was iden­ti­fy­ing cri­sis, not suf­fi­ciency. If the cri­sis thresh­old—the floor be­low which fam­i­lies can­not func­tion—is hon­estly up­dated to cur­rent spend­ing pat­terns, it lands at $140,000.

This ar­ti­cle res­onated with me be­cause I have had three chil­dren born since 2021 - well, tech­ni­cally, my third ar­rives in a week.

I have spent $30,000, $35,000, and now $40,000 for each child de­liv­ered.

That is my full out-of-pocket cash-paid cost as a self-em­ployed en­tre­pre­neur who runs a small busi­ness. I do not have a cor­po­rate daddy to share costs with me. This is to­tally un­sus­tain­able and in­sane, yet every cen­tral bank-wor­ship­ping think tank econ­o­mist who at­tacked Green had noth­ing to say when I asked them to jus­tify my so­cial­ized cost for the pub­lic good of bring­ing a new tax-payer into this world.

America has a cost of liv­ing cri­sis; it’s not be­ing taken se­ri­ously by serious” econ­o­mists; and the on­go­ing fail­ure to ad­dress it will lead to po­lit­i­cal, so­cial, and eco­nomic calamity.

The es­sen­tial theme of Green’s piece is that participation costs” - the price of ad­mis­sion you pay to sim­ply be in the mar­ket, let alone win, have grown out of con­trol. Food and shel­ter are par­tic­i­pa­tion costs for liv­ing. Having a $200/mo smart­phone is now a par­tic­i­pa­tion cost for many things such as get­ting ac­cess to your bank­ing in­for­ma­tion re­motely, med­ical records, and work / school.

There’s no greater participation cost” to hu­man civ­i­liza­tion than re­pro­duc­tion.

I run Petabridge - we’re a small, spe­cial­ized soft­ware com­pany. I have fewer than 5 em­ploy­ees and I own 100% of the com­pany. Been in busi­ness for 11 years. I love what I do. We’re too small for most tra­di­tional in­sur­ance bro­kers / group mar­ket­places but use TriNet, one of the largest Professional Employment Organizations (PEO)s in the United States, to han­dle pay­roll / taxes / ben­e­fits. I also used them when I ran MarkedUp, my last com­pany be­fore Petabridge.

My wife and I got mar­ried in 2020 and she be­came a full-time home maker, so I’m the sole bread win­ner.

This is what my cur­rent health care costs look like per pay pe­riod, which is bi­monthly.

Remember, I own 100% of the com­pany - so it makes no real dif­fer­ence which side of the ledger the money comes from. I pay the full freight.

Before any of those magic ben­e­fits kick in though, there’s the sticky is­sue of my health in­sur­ance de­ductible:

I have to hit a $14,300 de­ductible first, which I will ab­solutely hit next week when my child is de­liv­ered (if I haven’t al­ready.)

Thus I’ll spend $39,980 bring­ing my new daugh­ter into this world in 2025, and there are as­suredly things I’ve paid for that are not cov­ered by in­sur­ance ei­ther (i.e. we paid for some tests and sono­grams that aren’t cov­ered at all by our plan) - so the real cost will be $40k+ when it’s all said and done.

Here’s what my in­sur­ance pre­mi­ums look like for 2026:

The de­ductible is stay­ing the same at $14,300, so now my max spend is $43,496 - an 8.8% in­crease in to­tal cost over the pre­vi­ous year, but a 13.6% in­crease in pre­mi­ums. I’ve had some ver­sion of this plan for about 5 years and this price in­crease has been fairly con­sis­tent over time - I think I was pay­ing $1850 a month in pre­mi­ums back in 2021, which was more than my mort­gage.

My ac­tual in­sur­ance cost is some­what higher than the $40,000 I’ve laid out here.

I also pay $1250 per month to TriNet for the priv­i­lege of be­ing able to buy their health in­sur­ance in the first place - sure, I get some other ben­e­fits too, but I’m the only US-based em­ployee cur­rently so this over­head is re­ally 100% me. The only rea­son I stick with TriNet and don’t re­place them with a sig­nif­i­cantly cheaper pay­roll proces­sor like QuickBooks Payroll is for ac­cess to their health in­sur­ance ben­e­fits.

So my real par­tic­i­pa­tion cost is closer to $55,000 a year - the health­care mar­ket is so­cial­iz­ing enor­mous costs to me for pub­lic ser­vice of sir­ing new tax­pay­ers.

Health young peo­ple who can par­tic­i­pate in Obamacare / eHealth Insurance (individual) mar­kets; and

Poor peo­ple who get ei­ther sub­si­dized ACA plans or Medicaid.

I have the mis­for­tune of cre­at­ing jobs for other peo­ple, so op­tion 1 is out.

My wife and I are healthy, but we’re build­ing our fam­ily and I have yet to see a mar­ket­place plan that sup­ports child-birth. Maybe the sub­si­dized ones do, but I earn too much money to see those. All of the ones I’ve found through eHealth Insurance or Healthcare.gov never cover it - and I check every year. So op­tions 2 and 3 are out. This leaves me with few op­tions to con­tinue run­ning my com­pany AND grow a fam­ily at the same time.

The Affordable Care Act (Obamacare) barred in­sur­ers from turn­ing down ap­pli­cants based on ex­ist­ing pre-con­di­tions; the way in­sur­ers get around this for preg­nancy and child-birth is not by re­ject­ing preg­nant ap­pli­cants (illegal), but by sim­ply re­fus­ing to cover the care those ap­pli­cants need to sur­vive preg­nancy (legal and com­mon.)

I’ve had the same ver­sion of this Aetna plan since late 2020 when my wife and I got mar­ried and she quit her job. It’s the cheap­est PPO I can buy through TriNet that gives us ac­cess to our pe­di­a­tri­cian and OBGYN. The other PPOs are sig­nif­i­cantly more ex­pen­sive and usu­ally have lower de­ductibles. The cheaper” al­ter­na­tives of­fered through TriNet are HMOs or EPOs that have some is­sues with them: co-in­sur­ance or none of our med­ical providers be­ing in their net­work.

If you’re fa­mil­iar with how health­care charge mas­ters work, then you’ll un­der­stand why co-in­sur­ance is a bad bet when you know for cer­tain you’re go­ing to need an ex­pen­sive med­ical in­ter­ven­tion (like child-birth.)

Earlier this month our 4 year old had a 15 minute pro­ce­dure to treat blad­der re­flux - the billed cost” to Aetna was roughly $32,000. That’s nowhere close to the real” cost of the pro­ce­dure, but the point stands: if you have a big med­ical event while you’re on co-in­sur­ance you might get ex­posed to the same heat lev­els that to­tally unin­sured peo­ple have to tol­er­ate.

I’ve also looked into buy­ing plans di­rectly from Aetna and other smaller bro­kers like SimplyInsured - sim­i­lar prob­lems there:

The costs are ac­tu­ally higher than what I’m al­ready pay­ing TriNet.

It’s also worth not­ing, by the way, that TriNet’s quotes to me aren’t unique to my com­pany, as far as I know. These are the stan­dard plans TriNet of­fers to all Texas-based em­ploy­ers.

My sit­u­a­tion leaves me with un­fa­vor­able op­tions:

Continue pay­ing through the nose for my Aetna PPO;

Drop health in­sur­ance al­to­gether; start ne­go­ti­at­ing cash set­tle­ments; and back­stop my risk with a plat­form like CrowdHealth - this is more time-ex­pen­sive and ex­poses us to risk, but it can be man­aged;

Use an EPO / HMO and search for new health care providers who will ac­cept these plans - we’ve looked and it’s bleak;

Have my wife go find a BigCo cor­po­rate job some­where and raise our chil­dren in day­care; or

Destroy my firm and all of the eco­nomic value it cre­ates to go get a BigCo job my­self.

I’ve cho­sen num­ber 1 be­cause I have to ne­go­ti­ate the fol­low­ing trade-offs:

Forcing my preg­nant wife to find new pe­di­a­tri­cians, OBGYN, GPs, et al for her and our chil­dren;

The amount of time I can per­son­ally spend each November search­ing for al­ter­na­tives - 10-30 hours each year usu­ally;

The amount of time I can per­son­ally spend ne­go­ti­at­ing health care costs - CrowdHealth might be able to help with that, but I’m ex­tremely time-poor at the mo­ment;

The amount of un­capped fi­nan­cial ex­po­sure I’m will­ing to tol­er­ate - this is why Aetna can get away with high­way rob­bery in the first place - in­sur­ers like them in­cen­tivize the cre­ation of this ex­po­sure risk through Chargemaster / dis­count games; and

The amount of cash I am will­ing to pay for any of the above.

I am for­tu­nate. I am a higher earner, so I can sign the enor­mous check each year. The real peo­ple who bear this cost though are the em­ploy­ees I’m not go­ing to hire; I’m not go­ing to spend $40-$100k an en­try level soft­ware en­gi­neer / ad­min / SDR / mar­keter or what­ever if I need to keep $55k in re­serve to ex­pand my fam­ily.

What if I was start­ing a solo plumb­ing busi­ness or a restau­rant? What would my al­ter­na­tives be then? What if I fell be­neath the $140k poverty line” but not low enough where I can qual­ify for Medicaid / CHIP / sub­si­dized mar­ket plans? I’d be ut­terly screwed.

The prob­lem I have with health in­sur­ance is­n’t just the high price tag. It’s:

The real lack of vi­able al­ter­na­tives, mak­ing me feel robbed at gun­point while watch­ing my liv­ing stan­dards or op­tion­al­ity on my own hard-fought busi­ness cap­i­tal shrink each year.

The so­ci­etal ab­sur­dity of this sit­u­a­tion - what civ­i­liza­tion can sur­vive such strong eco­nomic head­winds against the re­pro­duc­tion of its own pop­u­lace? The health in­sur­ance mar­ket takes wealth from the young, healthy, and re­pro­duc­tive and trans­fers it as ser­vices to the old and dy­ing. This is in­sane and un­sus­tain­able.

The worst of all: I am old enough to re­mem­ber health in­sur­ance mar­kets not be­ing this way, so I know things can be dif­fer­ent.

The first thing I’d ex­pect some­one like Tyler Cowen to ex­plain to me, upon read­ing this post, is to gaslight me about me­dian health­care costs and show me a chart of pre­mi­ums stay­ing sta­ble in in­fla­tion-ad­justed dol­lars - as though that does any­thing to solve my im­me­di­ate prob­lem of hav­ing to spend a sum of money that is higher than many American’s an­nual in­come in or­der to have my third child de­liv­ered.

You can make the ar­gu­ment that maybe I need to change my sit­u­a­tion, but that ar­gu­ment is a to­tal loser. Just go back to work for Microsoft” or don’t have three chil­dren” or send your wife back to work” or move away from your fam­ily.”

If your an­swer to I can’t af­ford to have chil­dren and run a busi­ness” is then don’t,” you are build­ing the po­lit­i­cal con­di­tions for ex­trem­ism. This is how every rev­o­lu­tion starts: a crit­i­cal mass of peo­ple who con­clude the sys­tem of­fers them noth­ing worth pre­serv­ing. They don’t just want change - they want re­venge.

Economists and Wall Street big shots have not been re­motely per­sua­sive in mak­ing their case that everyone is do­ing great in 2025, ac­tu­ally” be­cause it runs com­pletely afoul of most American’s re­cent ex­pe­ri­ences at the till, hence the high eco­nomic anx­i­ety re­flected in the polls.

Green writes a piece say­ing 140k is the new poverty line.

It’s thor­oughly de­bunked.

And a le­gion of the cred­u­lous syco­phants who dig the vibe ex post re­de­fine poverty to en­nui (the piece never would’ve got­ten trac­tion with­out the 140k poverty thing which we are now told is… https://​t.co/​LG2lQp2mgy— Clifford Asness (@CliffordAsness) December 1, 2025

The rea­son why Mike Green’s piece res­onated with so many is be­cause this sen­tence per­fectly cap­tures what I and many oth­ers have been try­ing to do for the past five years:

Become rich enough to ig­nore the cost” - that is ex­actly what I have been try­ing to do and it is daunt­ing.

Per Jeff Bezos: When the data and the anec­dotes dis­agree, the anec­dotes are usu­ally right.”

I am tired of hear­ing econ­o­mists tell me how great every­thing is by show­ing me a chart that does­n’t look any­thing like real life on the ground - that’s ex­actly how Biden got voted out on his ass and the same will hap­pen to Trump if con­di­tions don’t im­prove. My be­ing un­happy with the sta­tus quo is not populism” - it’s re­al­ity. And it sucks.

A so­ci­ety that makes it this hard to have chil­dren is a so­ci­ety that has de­cided it does­n’t want a fu­ture. I’m fight­ing for mine any­way.

In a week, I’ll hold my third child. I’ll sign the check. I’ll keep build­ing my busi­ness. But I won’t pre­tend this is fine - and nei­ther should you.

...

Read the original on aaronstannard.com »

10 246 shares, 38 trendiness

What Will Enter the Public Domain in 2026?

At the start of each year, on January 1st, a new crop of works en­ter the pub­lic do­main and be­come free to en­joy, share, and reuse for any pur­pose. Due to dif­fer­ing copy­right laws around the world, there is no one sin­gle pub­lic do­main — and here we fo­cus on three of the most promi­nent. Newly en­ter­ing the pub­lic do­main in 2026 will be:

* works by peo­ple who died in 1955, for coun­tries with a copy­right term of life plus 70 years” (e.g. UK, Russia, most of EU and South America);

* works by peo­ple who died in 1975, for coun­tries with a term of life plus 50 years” (e.g. New Zealand, and most of Africa and Asia);

* films and books (incl. art­works fea­tured) pub­lished in 1930 for the United States.

In our ad­vent-style cal­en­dar be­low, find our top pick of what lies in store for 2026. Each day, as we move through December, we’ll open a new win­dow to re­veal our high­lights! By pub­lic do­main day on January 1st they will all be un­veiled — look out for a spe­cial blog­post from us on that day. (And, of course, if you want to dive straight in and ex­plore the vast swathe of new en­trants for your­self, just visit the links above).

...

Read the original on publicdomainreview.org »

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.