To use the Mastodon web ap­pli­ca­tion, please en­able JavaScript. Alternatively, try one of the na­tive apps for Mastodon for your plat­form.

The Core Project is a highly mod­u­lar based sys­tem with com­mu­nity build ex­ten­sions.

It starts with a re­cent Linux ker­nel, vm­linuz, and our root filesys­tem and start-up scripts pack­aged with a ba­sic set of ker­nel mod­ules in core.gz. Core (11MB) is sim­ply the ker­nel + core.gz - this is the foun­da­tion for user cre­ated desk­tops, servers, or ap­pli­ances. TinyCore is Core + Xvesa.tcz + Xprogs.tcz + aterm.tcz + fltk-1.3.tcz + flwm.tcz + wbar.tcz

TinyCore be­comes sim­ply an ex­am­ple of what the Core Project can pro­duce, an 16MB FLTK/FLWM desk­top.

CorePlus ofers a sim­ple way to get started us­ing the Core phi­los­o­phy with its in­cluded com­mu­nity pack­aged ex­ten­sions en­abling easy em­bed­ded fru­gal or pen­drive in­stal­la­tion of the user’s choice of sup­ported desk­top, while main­tain­ing the Core prin­ci­pal of mounted ex­ten­sions with full pack­age man­age­ment.

It is not a com­plete desk­top nor is all hard­ware com­pletely sup­ported. It rep­re­sents only the core needed to boot into a very min­i­mal X desk­top typ­i­cally with wired in­ter­net ac­cess.

The user has com­plete con­trol over which ap­pli­ca­tions and/​or ad­di­tional hard­ware to have sup­ported, be it for a desk­top, a net­book, an ap­pli­ance, or server, se­lec­table by the user by in­stalling ad­di­tional ap­pli­ca­tions from on­line repos­i­to­ries, or eas­ily com­pil­ing most any­thing you de­sire us­ing tools pro­vided.

Our goal is the cre­ation of a no­madic ul­tra small graph­i­cal desk­top op­er­at­ing sys­tem ca­pa­ble of boot­ing from cdrom, pen­drive, or fru­gally from a hard drive. The desk­top boots ex­tremely fast and is able to sup­port ad­di­tional ap­pli­ca­tions and hard­ware of the users choice. While Tiny Core al­ways re­sides in ram, ad­di­tional ap­pli­ca­tions ex­ten­sions can ei­ther re­side in ram, mounted from a per­sis­tent stor­age de­vice, or in­stalled into a per­sis­tent stor­age de­vice.

We in­vite in­ter­ested users and de­vel­op­ers to ex­plore Tiny Core. Within our fo­rums we have an open de­vel­ope­ment model. We en­cour­age shared knowl­edge. We pro­mote com­mu­nity in­volve­ment and com­mu­nity built ap­pli­ca­tion ex­ten­sions. Anyone can con­tribute to our pro­ject by pack­ag­ing their fa­vorite ap­pli­ca­tion or hard­ware sup­port to run in Tiny Core. The Tiny Core Linux Team cur­rently con­sists of eight mem­bers who pe­ruse the fo­rums to as­sist from an­swer­ing ques­tions to help­ing pack­age new ex­ten­sions.

Join us here and on IRC Freenode #tinycorelinux.

NanoKVM is a hard­ware KVM switch de­vel­oped by the Chinese com­pany Sipeed. Released last year, it en­ables re­mote con­trol of a com­puter or server us­ing a vir­tual key­board, mouse, and mon­i­tor. Thanks to its com­pact size and low price, it quickly gained at­ten­tion on­line, es­pe­cially when the com­pany promised to re­lease its code as open-source. However, as we’ll see, the de­vice has some se­ri­ous se­cu­rity is­sues. But first, let’s start with the ba­sics.

As men­tioned, NanoKVM is a KVM switch de­signed for re­motely con­trol­ling and man­ag­ing com­put­ers or servers. It fea­tures an HDMI port, three USB-C ports, an Ethernet port for net­work con­nec­tiv­ity, and a spe­cial se­r­ial in­ter­face. The pack­age also in­cludes a small ac­ces­sory for man­ag­ing the power of an ex­ter­nal com­puter.

Using it is quite sim­ple. First, you con­nect the de­vice to the in­ter­net via an Ethernet ca­ble. Once on­line, you can ac­cess it through a stan­dard web browser (though JavaScript JIT must be en­abled). The de­vice sup­ports Tailscale VPN, but with some ef­fort (read: hack­ing), it can also be con­fig­ured to work with your own VPN, such as WireGuard or OpenVPN server. Once set up, you can con­trol it from any­where in the world via your browser.

The de­vice could be con­nected to the tar­get com­puter us­ing an HDMI ca­ble, cap­tur­ing the video out­put that would nor­mally be dis­played on a mon­i­tor. This al­lows you to view the com­put­er’s screen di­rectly in your browser, es­sen­tially act­ing as a vir­tual mon­i­tor.

Through the USB con­nec­tion, NanoKVM can also em­u­late a key­board, mouse, CD-ROM, USB drive, and even a USB net­work adapter. This means you can re­motely con­trol the com­puter as if you were phys­i­cally sit­ting in front of it - but all through a web in­ter­face.

While it func­tions sim­i­larly to re­mote man­age­ment tools like RDP or VNC, it has one key dif­fer­ence: there’s no need to in­stall any soft­ware on the tar­get com­puter. Simply plug in the de­vice, and you’re ready to man­age it re­motely. NanoKVM even al­lows you to en­ter the BIOS, and with the ad­di­tional ac­ces­sory for power man­age­ment, you can re­motely turn the com­puter on, off, or re­set it.

This makes it in­cred­i­bly use­ful - you can power on a ma­chine, ac­cess the BIOS, change set­tings, mount a vir­tual bootable CD, and in­stall an op­er­at­ing sys­tem from scratch, just as if you were phys­i­cally there. Even if the com­puter is on the other side of the world.

NanoKVM is also quite af­ford­able. The fully-fea­tured ver­sion, which in­cludes all ports, a built-in mini screen, and a case, costs just over €60, while the stripped-down ver­sion is around €30. By com­par­i­son, a sim­i­lar RaspberryPi-based de­vice, PiKVM, costs around €400. However, PiKVM is sig­nif­i­cantly more pow­er­ful and re­li­able and, with a KVM split­ter, can man­age mul­ti­ple de­vices si­mul­ta­ne­ously.

As men­tioned ear­lier, the an­nounce­ment of the de­vice caused quite a stir on­line - not just be­cause of its low price, but also due to its com­pact size and min­i­mal power con­sump­tion. In fact, it can be pow­ered di­rectly from the tar­get com­puter via a USB ca­ble, which it also uses to sim­u­late a key­board, mouse, and other USB de­vices. So you have only one USB ca­ble - in one di­rec­tion it pow­ers NanoKVM, on the other it helps it to sim­u­late key­board mouse and other de­vices on a com­puter you want to man­age.

The de­vice is built on the open-source RISC-V proces­sor ar­chi­tec­ture, and the man­u­fac­turer even­tu­ally did re­lease the de­vice’s soft­ware un­der an open-source li­cense at the end of last year. (To be fair, one part of the code re­mains closed, but the com­mu­nity has al­ready found a suit­able open-source re­place­ment, and the man­u­fac­turer has promised to open this por­tion soon.)

However, the real is­sue is se­cu­rity.

Understandably, the com­pany was ea­ger to re­lease the de­vice as soon as pos­si­ble. In fact, an early ver­sion had a mi­nor hard­ware de­sign flaw - due to an in­cor­rect cir­cuit ca­ble, the de­vice some­times failed to de­tect in­com­ing HDMI sig­nals. As a re­sult, the com­pany re­called and re­placed all af­fected units free of charge. Software de­vel­op­ment also pro­gressed rapidly, but in such cases, the pri­mary fo­cus is typ­i­cally on get­ting ba­sic func­tion­al­ity work­ing, with se­cu­rity tak­ing a back­seat.

So, it’s not sur­pris­ing that the de­vel­op­ers made some se­ri­ous mis­steps - rushed de­vel­op­ment of­ten leads to stu­pid mis­takes. But some of the se­cu­rity flaws I dis­cov­ered in my quick (and by no means ex­haus­tive) re­view are gen­uinely con­cern­ing.

One of the first se­cu­rity analy­sis re­vealed nu­mer­ous vul­ner­a­bil­i­ties - and some rather bizarre dis­cov­er­ies. For in­stance, a se­cu­rity re­searcher even found an im­age of a cat em­bed­ded in the firmware. While the Sipeed de­vel­op­ers ac­knowl­edged these is­sues and rel­a­tively quickly fixed at least some of them, many re­main un­re­solved.

After pur­chas­ing the de­vice my­self, I ran a quick se­cu­rity au­dit and found sev­eral alarm­ing flaws. The de­vice ini­tially came with a de­fault pass­word, and SSH ac­cess was en­abled us­ing this pre­set pass­word. I re­ported this to the man­u­fac­turer, and to their credit, they fixed it rel­a­tively quickly. However, many other is­sues per­sist.

The user in­ter­face is rid­dled with se­cu­rity flaws - there’s no CSRF pro­tec­tion, no way to in­val­i­date ses­sions, and more. Worse yet, the en­cryp­tion key used for pass­word pro­tec­tion (when log­ging in via a browser) is hard­coded and iden­ti­cal across all de­vices. This is a ma­jor se­cu­rity over­sight, as it al­lows an at­tacker to eas­ily de­crypt pass­words. More prob­lem­atic, this needed to be ex­plained to the de­vel­op­ers. Multiple times.

Another con­cern is the de­vice’s re­liance on Chinese DNS servers. And con­fig­ur­ing your own (custom) DNS set­tings is quite com­pli­cated. Additionally, the de­vice com­mu­ni­cates with Sipeed’s servers in China - down­load­ing not only up­dates but also the closed-source com­po­nent men­tioned ear­lier. For this closed source com­po­nent it needs to ver­ify an iden­ti­fi­ca­tion key, which is stored on the de­vice in plain text. Alarmingly, the de­vice does not ver­ify the in­tegrity of soft­ware up­dates, in­cludes a strange ver­sion of the WireGuard VPN ap­pli­ca­tion (which does not work on some net­works), and runs a heav­ily stripped-down ver­sion of Linux that lacks sys­temd and apt. And these are just a few of the is­sues.

Were these prob­lems sim­ply over­sights? Possibly. But what ad­di­tion­ally raised red flags was the pres­ence of tcp­dump and air­crack - tools com­monly used for net­work packet analy­sis and wire­less se­cu­rity test­ing. While these are use­ful for de­bug­ging and de­vel­op­ment, they are also hack­ing tools that can be dan­ger­ously ex­ploited. I can un­der­stand why de­vel­op­ers might use them dur­ing test­ing, but they have ab­solutely no place on a pro­duc­tion ver­sion of the de­vice.

And then I dis­cov­ered some­thing even more alarm­ing - a tiny built-in mi­cro­phone that is­n’t clearly men­tioned in the of­fi­cial doc­u­men­ta­tion. It’s a minia­ture SMD com­po­nent, mea­sur­ing just 2 x 1 mm, yet ca­pa­ble of record­ing sur­pris­ingly high-qual­ity au­dio.

What’s even more con­cern­ing is that all the nec­es­sary record­ing tools are al­ready in­stalled on the de­vice! By sim­ply con­nect­ing via SSH (remember, the de­vice ini­tially used de­fault pass­words!), I was able to start record­ing au­dio us­ing the amixer and arecord tools. Once recorded, the au­dio file could be eas­ily copied to an­other com­puter. With a lit­tle ex­tra ef­fort, it would even be pos­si­ble to stream the au­dio over a net­work, al­low­ing an at­tacker to eaves­drop in real time.

Physically re­mov­ing the mi­cro­phone is pos­si­ble, but it’s not ex­actly straight­for­ward. As seen in the im­age, dis­as­sem­bling the de­vice is tricky, and due to the mi­cro­phone’s tiny size, you’d need a mi­cro­scope or mag­ni­fy­ing glass to prop­erly des­ol­der it.

To sum­ma­rize: the de­vice is rid­dled with se­cu­rity flaws, orig­i­nally shipped with de­fault pass­words, com­mu­ni­cates with servers in China, comes pre­in­stalled with hack­ing tools, and even in­cludes a built-in mi­cro­phone - fully equipped for record­ing au­dio - with­out clear men­tion of it in the doc­u­men­ta­tion. Could it get any worse?

I am pretty sure these is­sues stem from ex­treme neg­li­gence and rushed de­vel­op­ment rather than ma­li­cious in­tent. However, that does­n’t make them any less con­cern­ing.

That said, these find­ings don’t mean the de­vice is en­tirely un­us­able.

Since the de­vice is open-source, it’s en­tirely pos­si­ble to in­stall cus­tom soft­ware on it. In fact, one user has al­ready be­gun port­ing his own Linux dis­tri­b­u­tion - start­ing with Debian and later switch­ing to Ubuntu. With a bit of luck, this work could soon lead to of­fi­cial Ubuntu Linux sup­port for the de­vice.

This cus­tom Linux ver­sion al­ready runs the man­u­fac­tur­er’s mod­i­fied KVM code, and within a few months, we’ll likely have a fully in­de­pen­dent and sig­nif­i­cantly more se­cure soft­ware al­ter­na­tive. The only mi­nor in­con­ve­nience is that in­stalling it re­quires phys­i­cally open­ing the de­vice, re­mov­ing the built-in SD card, and flash­ing the new soft­ware onto it. However, in re­al­ity, this process is­n’t too com­pli­cated.

And while you’re at it, you might also want to re­move the mi­cro­phone… or, if you pre­fer, con­nect a speaker. In my test, I used an 8-ohm, 0.5W speaker, which pro­duced sur­pris­ingly good sound - es­sen­tially turn­ing the NanoKVM into a tiny mu­sic player. Actually, the idea is not so bad, be­cause PiKVM also in­cluded 2-way au­dio sup­port for their de­vices end of last year.

All this of course raises an in­ter­est­ing ques­tion: How many sim­i­lar de­vices with hid­den func­tion­al­i­ties might be lurk­ing in your home, just wait­ing to be dis­cov­ered? And not just those of Chinese ori­gin. Are you ab­solutely sure none of them have built-in minia­ture mi­cro­phones or cam­eras?

You can start with your iPhone - last year Apple has agreed to pay $95 mil­lion to set­tle a law­suit al­leg­ing that its voice as­sis­tant Siri recorded pri­vate con­ver­sa­tions. They shared the data with third par­ties and used them for tar­geted ads. “Unintentionally”, of course! Yes, that Apple, that cares about your pri­vacy so much.

And Google is do­ing the same. They are fac­ing a sim­i­lar law­suit over their voice as­sis­tant, but the lit­i­ga­tion likely won’t be set­tled un­til this fall. So no, small Chinese startup com­pa­nies are not the only prob­lem. And if you are wor­ried about Chinese com­pa­nies oblig­a­tions to­wards Chinese gov­ern­ment, let’s not for­get that U. S. com­pa­nies also have oblig­a­tions to co­op­er­ate with U.S. gov­ern­ment. While Apple is pub­licly claim­ing they do not co­op­er­ate with FBI and other U. S. agen­cies (because thy care about your pri­vacy so much), some me­dia re­vealed that Apple was hold­ing a se­ries se­cre­tive Global Police Summit at its Cupertino head­quar­ters where they taught po­lice how to use their prod­ucts for sur­veil­lance and polic­ing work. And as one of the po­lice of­fi­cers pointed out - he has “never been part of an en­gage­ment that was so col­lab­o­ra­tive.”. Yep.

If you want to test the built-in mi­cro­phone your­self, sim­ply con­nect to the de­vice via SSH and run the fol­low­ing two com­mands:

* arecord -Dhw:0,0 -d 3 -r 48000 -f S16_LE -t wav test.wav & > /dev/null & (this will cap­ture the sound to a file named test.wav)

Now, speak or sing (perhaps the Chinese na­tional an­them?) near the de­vice, then press Ctrl + C, copy the test.wav file to your com­puter, and lis­ten to the record­ing.

While LLMs are adept at read­ing and can be ter­rific at edit­ing, their writ­ing is much more mixed. At best, writ­ing from LLMs is hack­neyed and cliché-rid­den; at worst, it brims with tells that re­veal that the prose is in fact au­to­mat­i­cally gen­er­ated.

What’s so bad about this? First, to those who can rec­og­nize an LLM’s re­veals (an ex­pand­ing de­mo­graphic!), it’s just em­bar­rass­ing — it’s as if the writer is walk­ing around with their

in­tel­lec­tual

fly open. But there are deeper prob­lems: LLM-generated writ­ing un­der­mines the au­then­tic­ity of not just one’s writ­ing but of the think­ing be­hind it as well. If the prose is au­to­mat­i­cally gen­er­ated, might the ideas be too? The reader can’t be sure — and in­creas­ingly, the hall­marks of LLM gen­er­a­tion cause read­ers to turn off (or worse).

Finally, LLM-generated prose un­der­mines a so­cial con­tract of sorts: ab­sent LLMs, it is pre­sumed that of the reader and the writer, it is the writer that has un­der­taken the greater in­tel­lec­tual ex­er­tion. (That is, it is more work to write than to read!) For the reader, this is im­por­tant: should they strug­gle with an idea, they can rea­son­ably as­sume that the writer them­selves un­der­stands it — and it is the least a reader can do to la­bor to make sense of it.

If, how­ever, prose is LLM-generated, this so­cial con­tract be­comes ripped up: a reader can­not as­sume that the writer un­der­stands their ideas be­cause they might not so much have read the prod­uct of the LLM that they tasked to write it. If one is lucky, these are LLM hal­lu­ci­na­tions: ob­vi­ously wrong and quickly dis­carded. If one is un­lucky, how­ever, it will be a kind of LLM-induced cog­ni­tive dis­so­nance: a puz­zle in which pieces don’t fit be­cause there is in fact no puz­zle at all. This can leave a reader frus­trated: why should they spend more time read­ing prose than the writer spent writ­ing it?

This can be nav­i­gated, of course, but it is truly per­ilous: our writ­ing is an im­por­tant ves­sel for build­ing trust — and that trust can be quickly eroded if we are not speak­ing with our own voice. For us at Oxide, there is a more me­chan­i­cal rea­son to be jaun­diced about us­ing LLMs to write: be­cause our hir­ing process very much se­lects for writ­ers, we know that every­one at Oxide can write — and we have the lux­ury of de­mand­ing of our­selves the kind of writ­ing that we know that we are all ca­pa­ble of.

So our guide­line is to gen­er­ally not use LLMs to write, but this should­n’t be thought of as an ab­solute — and it does­n’t mean that an LLM can’t be used as part of the writ­ing process. Just please: con­sider your re­spon­si­bil­ity to your­self, to your own ideas — and to the reader.

Z-Image is a pow­er­ful and highly ef­fi­cient im­age gen­er­a­tion model with 6B pa­ra­me­ters. Currently there are three vari­ants:

🚀 Z-Image-Turbo — A dis­tilled ver­sion of Z-Image that matches or ex­ceeds lead­ing com­peti­tors with only 8 NFEs (Number of Function Evaluations). It of­fers ⚡️sub-second in­fer­ence la­tency⚡️ on en­ter­prise-grade H800 GPUs and fits com­fort­ably within 16G VRAM con­sumer de­vices. It ex­cels in pho­to­re­al­is­tic im­age gen­er­a­tion, bilin­gual text ren­der­ing (English & Chinese), and ro­bust in­struc­tion ad­her­ence.

🧱 Z-Image-Base — The non-dis­tilled foun­da­tion model. By re­leas­ing this check­point, we aim to un­lock the full po­ten­tial for com­mu­nity-dri­ven fine-tun­ing and cus­tom de­vel­op­ment.

✍️ Z-Image-Edit — A vari­ant fine-tuned on Z-Image specif­i­cally for im­age edit­ing tasks. It sup­ports cre­ative im­age-to-im­age gen­er­a­tion with im­pres­sive in­struc­tion-fol­low­ing ca­pa­bil­i­ties, al­low­ing for pre­cise ed­its based on nat­ural lan­guage prompts.

💡 Prompt Enhancing & Reasoning: Prompt Enhancer em­pow­ers the model with rea­son­ing ca­pa­bil­i­ties, en­abling it to tran­scend sur­face-level de­scrip­tions and tap into un­der­ly­ing world knowl­edge.

We adopt a Scalable Single-Stream DiT (S3-DiT) ar­chi­tec­ture. In this setup, text, vi­sual se­man­tic to­kens, and im­age VAE to­kens are con­cate­nated at the se­quence level to serve as a uni­fied in­put stream, max­i­miz­ing pa­ra­me­ter ef­fi­ciency com­pared to dual-stream ap­proaches.

According to the Elo-based Human Preference Evaluation (on Alibaba AI Arena), Z-Image-Turbo shows highly com­pet­i­tive per­for­mance against other lead­ing mod­els, while achiev­ing state-of-the-art re­sults among open-source mod­els.

Build a vir­tual en­vi­ron­ment you like and then in­stall the de­pen­den­cies:

pip in­stall -e .

Then run the fol­low­ing code to gen­er­ate an im­age:

python in­fer­ence.py

Install the lat­est ver­sion of dif­fusers, use the fol­low­ing com­mand:

Click here for de­tails for why you need to in­stall dif­fusers from source

We have sub­mit­ted two pull re­quests (#12703 and #12715) to the 🤗 dif­fusers repos­i­tory to add sup­port for Z-Image. Both PRs have been merged into the lat­est of­fi­cial dif­fusers re­lease. Therefore, you need to in­stall dif­fusers from source for the lat­est fea­tures and Z-Image sup­port.

pip in­stall git+https://​github.com/​hug­ging­face/​dif­fusers

Then, try the fol­low­ing code to gen­er­ate an im­age:

im­port torch

from dif­fusers im­port ZImagePipeline

# 1. Load the pipeline

# Use bfloat16 for op­ti­mal per­for­mance on sup­ported GPUs

pipe = ZImagePipeline.from_pretrained(

“Tongyi-MAI/Z-Image-Turbo”,

torch_d­type=torch.bfloat16,

low_cpu_mem_us­age=False,

pipe.to(“cuda”)

# [Optional] Attention Backend

# Diffusers uses SDPA by de­fault. Switch to Flash Attention for bet­ter ef­fi­ciency if sup­ported:

# pipe.trans­former.set_at­ten­tion_back­end(“flash”) # Enable Flash-Attention-2

# pipe.trans­former.set_at­ten­tion_back­end(“_flash_3”) # Enable Flash-Attention-3

# [Optional] Model Compilation

# Compiling the DiT model ac­cel­er­ates in­fer­ence, but the first run will take longer to com­pile.

# pipe.trans­former.com­pile()

# [Optional] CPU Offloading

# Enable CPU of­fload­ing for mem­ory-con­strained de­vices.

# pipe.en­able_­mod­el_cpu_of­fload()

prompt = “Young Chinese woman in red Hanfu, in­tri­cate em­broi­dery. Impeccable makeup, red flo­ral fore­head pat­tern. Elaborate high bun, golden phoenix head­dress, red flow­ers, beads. Holds round fold­ing fan with lady, trees, bird. Neon light­ning-bolt lamp (⚡️), bright yel­low glow, above ex­tended left palm. Soft-lit out­door night back­ground, sil­hou­et­ted tiered pagoda (西安大雁塔), blurred col­or­ful dis­tant lights.”

# 2. Generate Image

im­age = pipe(

prompt=prompt,

height=1024,

width=1024,

num_in­fer­ence_steps=9, # This ac­tu­ally re­sults in 8 DiT for­wards

guid­ance_s­cale=0.0, # Guidance should be 0 for the Turbo mod­els

gen­er­a­tor=torch.Gen­er­a­tor(“cuda”).man­u­al_seed(42),

).images[0]

im­age.save(“ex­am­ple.png”)

Decoupled-DMD is the core few-step dis­til­la­tion al­go­rithm that em­pow­ers the 8-step Z-Image model.

Our core in­sight in Decoupled-DMD is that the suc­cess of ex­ist­ing DMD (Distributaion Matching Distillation) meth­ods is the re­sult of two in­de­pen­dent, col­lab­o­rat­ing mech­a­nisms:

* CFG Augmentation (CA): The pri­mary en­gine 🚀 dri­ving the dis­til­la­tion process, a fac­tor largely over­looked in pre­vi­ous work.

* Distribution Matching (DM): Acts more as a reg­u­lar­izer ⚖️, en­sur­ing the sta­bil­ity and qual­ity of the gen­er­ated out­put.

By rec­og­niz­ing and de­cou­pling these two mech­a­nisms, we were able to study and op­ti­mize them in iso­la­tion. This ul­ti­mately mo­ti­vated us to de­velop an im­proved dis­til­la­tion process that sig­nif­i­cantly en­hances the per­for­mance of few-step gen­er­a­tion.

Building upon the strong foun­da­tion of Decoupled-DMD, our 8-step Z-Image model has al­ready demon­strated ex­cep­tional ca­pa­bil­i­ties. To achieve fur­ther im­prove­ments in terms of se­man­tic align­ment, aes­thetic qual­ity, and struc­tural co­her­ence—while pro­duc­ing im­ages with richer high-fre­quency de­tails—we pre­sent DMDR.

Our core in­sight be­hind DMDR is that Reinforcement Learning (RL) and Distribution Matching Distillation (DMD) can be syn­er­gis­ti­cally in­te­grated dur­ing the post-train­ing of few-step mod­els. We demon­strate that:

If you find our work use­ful in your re­search, please con­sider cit­ing:

@article{team2025zimage,

ti­tle={Z-Im­age: An Efficient Image Generation Foundation Model with Single-Stream Diffusion Transformer},

au­thor={Z-Im­age Team},

jour­nal={arXiv preprint arXiv:2511.22699},

year={2025}

@article{liu2025decoupled,

ti­tle={De­cou­pled DMD: CFG Augmentation as the Spear, Distribution Matching as the Shield},

au­thor={Dongyang Liu and Peng Gao and David Liu and Ruoyi Du and Zhen Li and Qilong Wu and Xin Jin and Sihan Cao and Shifeng Zhang and Hongsheng Li and Steven Hoi},

jour­nal={arXiv preprint arXiv:2511.22677},

year={2025}

@article{jiang2025distribution,

ti­tle={Dis­tri­b­u­tion Matching Distillation Meets Reinforcement Learning},

au­thor={Jiang, Dengyang and Liu, Dongyang and Wang, Zanyi and Wu, Qilong and Jin, Xin and Liu, David and Li, Zhen and Wang, Mengmeng and Gao, Peng and Yang, Harry},

jour­nal={arXiv preprint arXiv:2511.13649},

year={2025}

We’re ac­tively look­ing for Research Scientists, Engineers, and Interns to work on foun­da­tional gen­er­a­tive mod­els and their ap­pli­ca­tions. Interested can­di­dates please send your re­sume to: jing­peng.gp@al­ibaba-inc.com

In 2002 I asked a num­ber of de­vel­op­ers/​Unix peo­ple for screen­shots of their desk­tops. I re­cently re­pub­lished them, and, see­ing the in­ter­est this gen­er­ated, I thought it’d be fun to ask the same peo­ple* again 13 years later. To my de­light I man­aged to reach many of them.

* Sans Dennis Ritchie and ito­jun, who are no longer with us.

So, with­out fur­ther ado:

Brian Kernighan (Unix leg­end, the K in K&R and AWK):

my desk­top is pretty bor­ing, since it con­sists of xterm win­dows to what­ever unix sys­tem i am us­ing at the mo­ment. the ma­chine it­self is likely to be run­ning some x-win­dow server like ex­ceed on some fla­vor of win­dows, though for many years i just used an x ter­mi­nal.

If you thought it was bor­ing last time, check this out!

I don’t know how to make a screen­shot, be­cause I nor­mally use my com­puter in text-mode. I have X and GNOME in­stalled, but I use them only oc­ca­sion­ally.

Under X, I use the stan­dard en­vi­ron­ment of Trisquel, but mostly I type at Emacs in a con­sole.

Well, my desk­top is quite bor­ing. I mostly work with four xterms and a few Netscape win­dows. The KDE bar hides au­to­mat­i­cally, you can only see a thin grey line at the bot­tom.

Here is the new one. You’ll see that, like be­fore, I have lots of xterms where I work on Vim, Zimbu and email. Now us­ing the Chrome browser, show­ing off the Zimbu home­page. But clearly every­thing has be­come big­ger!

Not that much has changed in 13 years. Still us­ing Linux. Still just a browser win­dow and a ton of ter­mi­nals hid­ing be­hind them. The main change is that switched from Pine to Thunderbird for email at some point. The OS on my lap­top here is Ubuntu with Unity al­though there are a lot of Debian pack­ages in­stalled so it is a bit of a hy­brid at this point. Oh, and yes, my son Carl is a lot older now.

Ah, my desk­top is pretty bor­ing, I used fvwm 1.24 as my win­dow man­ager and I try to have no more than 1 or 2 win­dows open per vir­tual desk­top. I use FreeBSD 4-STABLE as my op­er­at­ing sys­tem. I first came across Unix when I got an ac­count on a Pyramid 90x run­ning OSx. This had a dual-uni­verse setup: both AT&T and BSD-style en­vi­ron­ments, cho­sen by an en­vi­ron­ment vari­able. Initially I was given the AT&T en­vi­ron­ment, but my friends con­vinced me to ``come over” to BSD. Since then I’ve been a BSD af­fi­cionado.

After OSx, SunOS 3.5 and later SunOS re­leases, un­til 386BSD 0.1 came out and I started to run BSD at home. Then when 386BSD trans­mo­gri­fied to FreeBSD, I went with FreeBSD.

In terms of desk­top, I’m a com­mand-line guy, al­ways will be. My favourite ed­i­tor is vi, my favourite shell is tcsh (but ku­dos to rc for el­e­gance). So I don’t re­ally feel the need for GUI things like Gnome or KDE :-)

How things have (and have not changed). I’m still a com­mand-line junkie with at least two xterm win­dows open. I’m still us­ing a 3x3 vir­tual desk­top. However, in­stead of fvwm, it is now LXDE. I’ve also switched from FreeBSD to Linux and I’m run­ning Lubuntu as my dis­tri­b­u­tion.

There are a lot of in­dis­pens­able GUI tools that I use. These in­clude Firefox, lyx, Gimp, KeepassX, Shutter, viking, dia, Wireshark, cal­i­bre, au­dac­ity, Handbrake and VLC. But where pos­si­ble I still pre­fer to script things. My main de­vel­op­ment lan­guages are still shell, Perl and C.

My shell is now bash. The vi key­strokes are burned into my fin­ger­tips and, as long as vim can be ported to new sys­tems, that will be my text ed­i­tor un­til I pass on. My mail client is now mutt (definitely not a web client) and my mail is stored lo­cally, not on some­one else’s server.

The only is­sue I have is that, since a job change, I now have to deal with Windoze things. Thus, I have VirtualBox, li­bre­of­fice and Wine to help me do that.

I started with Unix on a Pyramid 90x. I now have a smart phone that blows the 90x out of the wa­ter on per­for­mance, RAM and stor­age. But I’m so very happy that, some­where down un­der­neath, there is still a Bourne shell and an op­er­at­ing sys­tem that does open(), close(), read(), write(), fork() and exec()!

Jordan Hubbard (FreeBSD co-founder, later Director of UNIX Technology at Apple; now CTO of iXsys­tems):

You’ll prob­a­bly be sad (or per­haps not) to hear that my desk­top has­n’t re­ally changed much at all - still OS X, though be­cause OS X has vir­tual desk­tops now I have mul­ti­ple “desktops” (6 of them) where Mail.app runs on one, Safari on an­other, Calendar, Slack, etc - all on sep­a­rate desk­tops. This makes it a bit bor­ing, but here’s the one I prob­a­bly spend the most time in - the ter­mi­nal win­dow desk­top. :)

There we go. Actually, that’s a con­den­sate in one work­space cause I usu­ally use about 4. Some of my favourite apps:

not on the shot, but worth noted

and of course a shot of RTCW

‘screenshot as code’, I main­tain my desk­top con­fig­u­ra­tion through salt­stack: https://​github.com/​TTimo/​linux-salted/​com­mits/​mas­ter

“I think that these days what we mean by “autism” is ba­si­cally “weird per­son dis­ease.””

“Accurate di­ag­no­sis re­quires con­sid­er­a­tion of mul­ti­ple di­ag­noses. Sometimes, dif­fer­ent di­ag­noses can over­lap with one an­other and can only be dif­fer­en­ti­ated in sub­tle and nu­anced ways, but par­tic­u­lar di­ag­noses vary con­sid­er­ably in lev­els of pub­lic aware­ness. As such, an in­di­vid­ual may meet the di­ag­nos­tic cri­te­ria for one di­ag­no­sis but self-di­ag­noses with a dif­fer­ent di­ag­no­sis be­cause it is bet­ter known.”

Sam Fellowes, Self-Diagnosis in Psychiatry and the Distribution of Social Resources

Unsurprisingly, these days I meet many peo­ple in the psy­chi­atric clinic who are con­vinced that they have autism, or sus­pect (with var­i­ous de­grees of con­fi­dence) that they have autism, or re­port be­ing di­ag­nosed with autism at some point in their lives by some clin­i­cian. And for a fair num­ber of such in­di­vid­u­als, I can­not say with rea­son­able cer­ti­tude that they have autism. The rea­sons they give for con­sid­er­ing autism vary widely, but tend to be along the lines of…

What’s in­ter­est­ing about many of the items above is that the num­ber one di­ag­nos­tic pos­si­bil­ity in my mind is an anx­i­ety dis­or­der of some sort. I re­mem­ber see­ing a woman who was a clas­sic ex­am­ple of some­one with high neu­roti­cism, poor self-es­teem, and se­vere so­cial anx­i­ety, and she had be­lieved for much of her life that she was autis­tic be­cause some ran­dom doc­tor some­where at some point (she could­n’t even re­mem­ber who or what sort of as­sess­ment this in­volved) had told her that she had autism, and she be­lieved it be­cause it fit in with her ex­pe­ri­ence of be­ing awk­ward-shy-weird.

It is com­mon for me to meet in­di­vid­u­als who think they have autism and find my­self think­ing, “schizoid,” “obsessive com­pul­sive,” “cluster B,” “social anx­i­ety,” “generalized anx­i­ety,” “trauma,” “socially awk­ward,”… None of these, how­ever, have the mimetic vi­ral­ity of autism.

I don’t want to come across as be­ing skep­ti­cal of the re­al­ity of autism as a di­ag­no­sis or as as­sert­ing that most peo­ple are mis­di­ag­nosed. Autism ex­ists, to the ex­tent that any psy­chi­atric dis­or­der ex­ists. Not every­one is mis­di­ag­nosed, per­haps even most peo­ple. I am not try­ing to say, “autism is bull­shit.” It’s not. I of­fer the di­ag­no­sis of autism as a clin­i­cian per­haps as of­ten as I find my­self doubt­ing it.

What in­trigues me is that peo­ple are drawn to autism as a di­ag­no­sis be­cause it seems to of­fer recog­ni­tion of some­thing they’ve lived with: they may be deeply awk­ward, ter­ri­bly shy, or bad with peo­ple, they may strug­gle with so­cial in­ter­ac­tions, they may find other peo­ple an­noy­ing, other peo­ple may find them weird, they may have a hard time con­nect­ing to oth­ers, they may have been bul­lied, and they may have di­rected their lone­li­ness or in­tro­ver­sion to­wards pe­cu­liar in­ter­ests or hob­bies. Autism seems to them to cap­ture all that. It seems like an apt and ap­peal­ing nar­ra­tive. But autism may also be the only rel­e­vant di­ag­no­sis they’ve heard of or are fa­mil­iar with. They haven’t seen any cool TikToks about be­ing schizoid. No one’s of­fer­ing them quizzes about be­ing schizo­typal. A ran­dom pe­di­a­tri­cian or pri­mary care doc is not go­ing to tell them they have an ob­ses­sive-com­pul­sive style of per­son­al­ity. So when some pro­fes­sional doubts that they have “autism,” they see it as a dis­missal or re­jec­tion of their “lived ex­pe­ri­ence.” Of course, I am weird-anx­ious-awk­ward. How can you say oth­er­wise? What they don’t know is that the choice is not be­tween autism or noth­ing, but rather be­tween autism and about a dozen other di­ag­nos­tic pos­si­bil­i­ties.

So for the sake of our col­lec­tive san­ity, let’s con­sider a few of them…

To be di­ag­nosed with autism spec­trum dis­or­der ac­cord­ing to DSM-5, a per­son must have on­go­ing dif­fi­cul­ties in so­cial com­mu­ni­ca­tion and in­ter­ac­tion in all three ar­eas: trou­ble with back-and-forth so­cial con­nec­tion, prob­lems with non­ver­bal com­mu­ni­ca­tion like eye con­tact and body lan­guage, and dif­fi­culty mak­ing or keep­ing friend­ships. They also must show at least two types of repet­i­tive or re­stricted be­hav­iors, such as repet­i­tive move­ments or phrases, need­ing things to stay the same, hav­ing very in­tense fo­cused in­ter­ests, or be­ing un­usu­ally sen­si­tive (or un­der-sen­si­tive) to things like sounds, tex­tures, or lights. These pat­terns must have been pre­sent since early child­hood (even if they weren’t no­ticed un­til later when life got more com­pli­cated), lead to sub­stan­tial im­pair­ment in func­tion­ing, and can’t sim­ply be ex­plained by in­tel­lec­tual dis­abil­ity (or other psy­chi­atric dis­or­ders).

To “have” autism is sim­ply to demon­strate this clus­ter of char­ac­ter­is­tics at the req­ui­site level of sever­ity and per­va­sive­ness. It does­n’t mean that the per­son has a spe­cific type of brain at­tribute or a spe­cific set of genes that dif­fer­en­ti­ates them from non-autis­tics. No such in­ter­nal essence ex­ists for the no­tion as cur­rently con­cep­tu­al­ized.

Autism spec­trum is wide enough to have very dif­fer­ent pro­to­types within it. On one end we have pro­found autism, rep­re­sent­ing some­one with se­vere autis­tic traits who is com­pletely de­pen­dent on oth­ers for care and has sub­stan­tial in­tel­lec­tual dis­abil­ity or very lim­ited lan­guage abil­ity. At the other end, we have suc­cess­ful nerdy in­di­vid­u­als with autis­tic traits and su­pe­rior in­tel­li­gence, of­ten seen in sci­ence or acad­e­mia, à la Sheldon Cooper. (Holden Thorp, ed­i­tor-in-chief of the Science jour­nals and for­mer UNC chan­cel­lor, for ex­am­ple, has pub­licly dis­closed his own autism di­ag­no­sis.) This wide range is con­fus­ing enough on its own, even with­out con­sid­er­ing other con­di­tions that can pre­sent with autism-like fea­tures.

Autism can­not be iden­ti­fied via med­ical “tests.” It is iden­ti­fied via clin­i­cal in­for­ma­tion in the form of his­tory, ob­ser­va­tion, and in­ter­ac­tion, and the less in­for­ma­tion avail­able or the more un­re­li­able the in­for­ma­tion pro­vided is, the more un­cer­tain we’ll be. To have autism is ba­si­cally a judg­ment call that one is a good match to a de­scrip­tive pro­to­type. We can get this judg­ment wrong, and we some­times do get it wrong. (There is noth­ing wrong with this fal­li­bil­ity as such, as long as we rec­og­nize it. Lives have been built on foun­da­tions less sturdy.)

Autism as a cat­e­gory or iden­tity has taken on a life of its own. I am aware that not every­one in the neu­ro­di­ver­sity crowd ac­cepts the le­git­i­macy of clin­i­cian judg­ments or clin­i­cal cri­te­ria as out­lined in the di­ag­nos­tic man­u­als, such as the DSM and ICD. There are other ways to ground the le­git­i­macy of self-di­ag­noses, in the­o­ret­i­cally vir­tu­ous ac­counts or prag­matic uses, which re­quire dis­tinct con­sid­er­a­tions of their own; I don’t re­ject that. But here, I am con­cerned with autism as a clin­i­cal di­ag­no­sis and the ac­cu­racy of autism un­der­stood in terms of align­ment with clin­i­cal di­ag­no­sis. Would com­pe­tent and knowl­edge­able clin­i­cians with ac­cess to all rel­e­vant clin­i­cal in­for­ma­tion con­cur that the per­son’s pre­sen­ta­tion meets di­ag­nos­tic cri­te­ria for autism? If you don’t re­ally care about that, this post is not for you.

Schizoid per­son­al­ity de­scribes peo­ple who have lit­tle de­sire for close re­la­tion­ships and pre­fer soli­tary ac­tiv­i­ties. Unlike peo­ple who are sim­ply shy or so­cially anx­ious, in­di­vid­u­als with schizoid per­son­al­ity style gen­uinely don’t find re­la­tion­ships re­ward­ing or nec­es­sary. They typ­i­cally ap­pear emo­tion­ally de­tached or cold, show re­stricted emo­tional ex­pres­sion, seem in­dif­fer­ent to praise or crit­i­cism, and have few if any close friends or con­fi­dants. They of­ten live qui­etly on the mar­gins of so­ci­ety, pur­su­ing soli­tary in­ter­ests or jobs. They keep their in­ner worlds (which can be quite rich) pri­vate and don’t seek emo­tional in­ti­macy with oth­ers.

In autism, so­cial dif­fi­cul­ties stem from gen­uine chal­lenges with pro­cess­ing so­cial in­for­ma­tion: dif­fi­culty read­ing fa­cial ex­pres­sions, un­der­stand­ing im­plied mean­ings, pick­ing up on so­cial cues, know­ing un­writ­ten so­cial rules, etc. In schizoid per­son­al­ity, the per­son typ­i­cally un­der­stands so­cial con­ven­tions but sim­ply is­n’t mo­ti­vated to en­gage with them. They with­draw from gen­uine dis­in­ter­est. Schizoid per­son­al­ity also lacks the ad­di­tional fea­tures of autism (repetitive or re­stricted be­hav­iors, var­i­ous sen­sory sen­si­tiv­i­ties).

Schizotypal per­son­al­ity de­scribes peo­ple who have odd or ec­cen­tric be­liefs, un­usual per­cep­tual ex­pe­ri­ences, and dif­fi­cul­ties with close re­la­tion­ships. Unlike schizoid per­son­al­ity (which in­volves sim­ple dis­in­ter­est in re­la­tion­ships), schizo­typal in­cludes strange ways of think­ing and per­ceiv­ing the world. People with schizo­typal per­son­al­ity might be­lieve in telepa­thy, feel they have spe­cial pow­ers, think ran­dom events have spe­cial mean­ing for them per­son­ally, or have un­usual per­cep­tual ex­pe­ri­ences (like feel­ing a pres­ence in the room or hear­ing whis­pers). They typ­i­cally have few close friends, ex­pe­ri­ence so­cial anx­i­ety that does­n’t im­prove with fa­mil­iar­ity, and may ap­pear para­noid or sus­pi­cious of oth­ers’ mo­tives. Both schizo­typal per­son­al­ity and autism can in­volve so­cial dif­fi­cul­ties and odd or ec­cen­tric be­hav­ior, but in schizo­typal per­son­al­ity, the pe­cu­liar­ity comes from mag­i­cal think­ing, para­noid ideas, and per­cep­tual dis­tor­tions.

Obsessive-compulsive per­son­al­ity de­scribes peo­ple who are pre­oc­cu­pied with or­der­li­ness, per­fec­tion­ism, and con­trol. These in­di­vid­u­als are rigid rule-fol­low­ers who want things to be done “the right way,” have dif­fi­culty del­e­gat­ing tasks, and get caught up in de­tails and lists to the point where they lose sight of the main goal. They tend to be worka­holics who ne­glect leisure and friend­ships, are in­flex­i­ble about mat­ters of moral­ity or ethics, and are of­ten stub­born and con­trol­ling. Both ob­ses­sive-com­pul­sive per­son­al­ity and autism can in­volve rigid ad­her­ence to rou­tines, rules, and spe­cific ways of do­ing things. In ob­ses­sive-com­pul­sive per­son­al­ity, the in­flex­i­bil­ity comes from anx­i­ety about loss of con­trol. The per­son is try­ing to, con­sciously or un­con­sciously, man­age anx­i­ety through con­trol and per­fec­tion­ism. In autism, the need for same­ness and rou­tine serves dif­fer­ent func­tions. It pro­vides pre­dictabil­ity in a world that feels con­fus­ing or it helps with sen­sory reg­u­la­tion rather than anx­i­ety-dri­ven per­fec­tion­ism.

Severe so­cial anx­i­ety is an in­tense, per­sis­tent fear of so­cial sit­u­a­tions where a per­son might be judged, em­bar­rassed, or hu­mil­i­ated. Social anx­i­ety dis­or­der in­volves over­whelm­ing fear that in­ter­feres with daily life. People with this con­di­tion worry ex­ces­sively about say­ing some­thing stu­pid, look­ing fool­ish, or be­ing re­jected. They of­ten avoid so­cial sit­u­a­tions en­tirely, which can lead to iso­la­tion, dif­fi­culty main­tain­ing em­ploy­ment, and prob­lems form­ing re­la­tion­ships. Both so­cial anx­i­ety and autism in­volve so­cial dif­fi­cul­ties and with­drawal. Social anx­i­ety usu­ally im­proves sig­nif­i­cantly in com­fort­able, safe en­vi­ron­ments (like with close fam­ily or friends), while autis­tic so­cial dif­fer­ences tend to be more con­sis­tent across all con­texts.

Borderline per­son­al­ity dis­or­der in­volves in­tense emo­tional in­sta­bil­ity, un­sta­ble re­la­tion­ships, fear of aban­don­ment, and a shift­ing sense of self, with peo­ple ex­pe­ri­enc­ing rapid mood swings and chaotic re­la­tion­ships that al­ter­nate be­tween ide­al­iza­tion and de­val­u­a­tion of oth­ers. While it can re­sem­ble autism through so­cial dif­fi­cul­ties, emo­tional dys­reg­u­la­tion, rigid think­ing, and feel­ing dif­fer­ent from oth­ers, the key dis­tinc­tions are that bor­der­line cen­ters on in­tense re­la­tion­ship pre­oc­cu­pa­tions and emo­tional chaos, whereas autism in­volves gen­uine dif­fi­culty un­der­stand­ing so­cial cues and com­mu­ni­ca­tion; bor­der­line fea­tures rapidly shift­ing iden­tity and re­la­tion­ship-trig­gered mood swings, while autism in­cludes sta­ble self-con­cept, sen­sory sen­si­tiv­i­ties, re­stricted in­ter­ests, and lit­eral com­mu­ni­ca­tion that aren’t pre­sent in bor­der­line; and bor­der­line symp­toms fluc­tu­ate dra­mat­i­cally with re­la­tion­ship sta­bil­ity while autis­tic traits re­main con­sis­tent across con­texts.

Social com­mu­ni­ca­tion dis­or­der is a con­di­tion in DSM-5 where some­one has sig­nif­i­cant, on­go­ing dif­fi­culty us­ing ver­bal and non­ver­bal com­mu­ni­ca­tion ap­pro­pri­ately in so­cial con­texts. People with so­cial com­mu­ni­ca­tion dis­or­der strug­gle with the “pragmatic” as­pects of lan­guage, that is, know­ing how to use lan­guage ef­fec­tively in so­cial sit­u­a­tions. They may have trou­ble un­der­stand­ing when to take turns in con­ver­sa­tion, know­ing how much de­tail to give, ad­just­ing their speak­ing style for dif­fer­ent sit­u­a­tions, un­der­stand­ing im­plied mean­ings or hints, pick­ing up on non­ver­bal cues like body lan­guage and fa­cial ex­pres­sions, and know­ing how to start, main­tain, or end con­ver­sa­tions nat­u­rally. This makes form­ing friend­ships and re­la­tion­ships dif­fi­cult and af­fects life func­tion­ing. The so­cial com­mu­ni­ca­tion prob­lems in so­cial com­mu­ni­ca­tion dis­or­der look nearly iden­ti­cal to the “Criterion A” fea­tures of autism. However, un­like autism, peo­ple with so­cial com­mu­ni­ca­tion dis­or­der don’t show repet­i­tive be­hav­iors, re­stricted in­ter­ests, sen­sory sen­si­tiv­i­ties, or the need for same­ness and rou­tine.

Social com­mu­ni­ca­tion dis­or­der is rarely di­ag­nosed in fa­vor of autism pri­mar­ily be­cause autism pro­vides ac­cess to crit­i­cal ser­vices, in­sur­ance cov­er­age, ed­u­ca­tional sup­port, and le­gal pro­tec­tions that so­cial com­mu­ni­ca­tion dis­or­der does not re­li­ably of­fer, cre­at­ing strong prac­ti­cal in­cen­tives for fam­i­lies and clin­i­cians to pre­fer the autism di­ag­no­sis. Additionally, autism has an es­tab­lished ev­i­dence base, val­i­dated as­sess­ment tools, clear in­ter­ven­tion pro­to­cols, and a large sup­port­ive com­mu­nity with a neu­ro­di­ver­sity-af­firm­ing cul­ture, while so­cial com­mu­ni­ca­tion dis­or­der has none of these. It has no com­mu­nity, min­i­mal re­search, no spe­cific treat­ments, and lit­tle pro­fes­sional aware­ness since it was only in­tro­duced in the DSM in 2013. Service de­liv­ery, in­sur­ance, and ed­u­ca­tional sys­tems are built en­tirely around autism rather than so­cial com­mu­ni­ca­tion dis­or­der, and since both con­di­tions re­quire sim­i­lar in­ter­ven­tions for so­cial-com­mu­ni­ca­tion dif­fi­cul­ties, there’s lit­tle prac­ti­cal in­cen­tive to make the di­ag­nos­tic dis­tinc­tion, es­pe­cially when the bound­ary be­tween them (whether re­stricted/​repet­i­tive be­hav­iors are truly ab­sent or just sub­tle) is of­ten un­clear and clin­i­cians are of­ten un­sure the dis­tinc­tion re­ally mat­ters.

Trauma-related dis­or­ders, par­tic­u­larly from early de­vel­op­men­tal trauma, se­vere ne­glect, or dis­rupted at­tach­ment, can mimic autism through so­cial with­drawal and avoid­ance of eye con­tact (defensive pro­tec­tion rather than so­cial pro­cess­ing dif­fi­cul­ties), com­mu­ni­ca­tion de­lays and dif­fi­cul­ties (from lack of lan­guage ex­po­sure or trau­ma’s im­pact on brain de­vel­op­ment), emo­tional dys­reg­u­la­tion and melt­downs (from emo­tional dys­reg­u­la­tion rather than sen­sory over­load), repet­i­tive self-sooth­ing be­hav­iors (anxiety man­age­ment rather than stim­ming), sen­sory sen­si­tiv­i­ties (hypervigilance rather than sen­sory pro­cess­ing dif­fer­ences), and rigid need for rou­tine (anxiety-driven safety-seek­ing rather than cog­ni­tive pro­cess­ing style).

Severe early de­pri­va­tion can cre­ate “quasi-autistic” pat­terns that can be gen­uinely dif­fi­cult to dis­tin­guish. The crit­i­cal dis­tinc­tions are that trauma-re­lated dif­fi­cul­ties typ­i­cally im­prove sig­nif­i­cantly in safe, nur­tur­ing en­vi­ron­ments and with ad­e­quate psy­cho­log­i­cal treat­ment, show more vari­abil­ity across con­texts (worse with trig­gers), are tied to iden­ti­fi­able ad­verse ex­pe­ri­ences rather than pre­sent from ear­li­est in­fancy, and lack the re­stricted in­ter­ests and gen­uine so­cial com­mu­ni­ca­tion pro­cess­ing deficits of autism.

Social awk­ward­ness refers to so­cial in­ept­ness with­out mean­ing­ful im­pair­ment that falls within what is con­sid­ered nor­mal or typ­i­cal hu­man vari­a­tion. This can be mis­taken for autism be­cause both may in­volve lim­ited friend­ships, pref­er­ence for soli­tude, con­ver­sa­tion dif­fi­cul­ties, re­duced eye con­tact, and in­tense in­ter­ests, par­tic­u­larly fu­eled by on­line self-di­ag­no­sis cul­ture and broad autism aware­ness. The key dis­tinc­tions are that so­cially awk­ward in­di­vid­u­als un­der­stand what they should do so­cially but find it dif­fi­cult or un­in­ter­est­ing (versus gen­uinely not un­der­stand­ing un­writ­ten rules), show sig­nif­i­cant im­prove­ment with prac­tice and ma­tu­rity, are more com­fort­able in spe­cific con­texts, lack the sen­sory sen­si­tiv­i­ties and re­stricted/​repet­i­tive be­hav­iors re­quired for autism di­ag­no­sis, and gen­er­ally achieve life goals de­spite awk­ward­ness rather than ex­pe­ri­enc­ing clin­i­cally sig­nif­i­cant im­pair­ment.

Selective Mutism, Intellectual Disability (without autism), Stereotypic Movement Disorder, Attention-Deficit/Hyperactivity Disorder (ADHD), Schizophrenia Spectrum Disorders, Avoidant Personality Disorder, Attachment Disorders, Generalized Anxiety Disorder, Obsessive-Compulsive Disorder, and Rett Syndrome (a char­ac­ter­is­tic pat­tern of de­vel­op­men­tal re­gres­sion af­ter ini­tial nor­mal de­vel­op­ment, typ­i­cally 6-18 months).

Comorbidity is pos­si­ble and ex­pected. Someone can be autis­tic and have mal­adap­tive per­son­al­ity pat­terns, trauma his­to­ries, or anx­i­ety dis­or­ders that com­pli­cate the pre­sen­ta­tion. Developmental con­text, re­sponse to re­la­tion­ships, and sub­jec­tive ex­pe­ri­ences are all very im­por­tant in look­ing be­yond the sur­face pre­sen­ta­tion to un­der­stand­ing the mean­ing and func­tions of be­hav­iors.

According to the Discourse, some­body killed perlThere’s been a flurry of dis­cus­sion on Hacker News and other tech fo­rums about what killed Perl. I wrote a lot of Perl in the mid 90s and sub­se­quently worked on some of the most traf­ficked sites on the web in mod­_perl in the early 2000s, so I have some thoughts. My take: it was mostly baked into the cul­ture. Perl grew amongst a re­ac­tionary com­mu­nity with con­ser­v­a­tive val­ues, which pre­vented it from evolv­ing into a ma­ture gen­eral pur­pose lan­guage ecosys­tem. Everything else filled the gap. Something to keep in mind, is that al­though this is my per­sonal take, and there­fore en­tirely an opin­ion piece, I was there at the time. I stopped do­ing Perl prop­erly when I left Amazon, I think this would have been around 2005. It’s based on the first hand im­pres­sions of some­body who was very deeply in­volved in Perl in its hey­day, and moved on. I have a lot of ex­pe­ri­ence, from both in­side and out­side the tent. What cul­ture? Perl al­ways had a sig­nif­i­cant amount of what you might call “BOFH” cul­ture, which came from its old UNIX sysad­min roots. All of those pas­sive ag­gres­sive id­ioms and in jokes like “RTFM”, “lusers”, “wizards”, “asking for help the wrong way” etc. None of this is lit­er­ally se­ri­ous, but it does en­code and in­form so­cial norms that are es­sen­tially tribal and in­tro­verted. There im­plic­itly is a priv­i­leged pop­u­la­tion, with a cost of en­try to join. Dues must be paid. Cultural con­ser­vatism as a first prin­ci­ple. This stems from the old locked-down data cen­tre com­mand cul­ture. When com­puter re­source was ex­pen­sive, cen­tralised, frag­ile, and man­u­ally op­er­ated, it was rigidly main­tained by gate­keep­ers, de­fend­ing against in­ap­pro­pri­ate use. I started my ca­reer as an ap­pren­tice pro­gram­mer at the very end of this era, (late 80s) pre-web, and be­fore mi­cro­com­put­ers had made much in­roads, and this re­ally was the pre­vail­ing view from in­side the fort. (This is a draw­back about fort-build­ing. Once you live in a fort, it’s slightly too easy to de­velop a siege men­tal­ity). Computers are spe­cial, users are in­con­ve­nient, dis­rup­tion is the main en­emy. An un­for­tu­nate feed­back loop in this kind of “perilous” en­vi­ron­ment is that it eas­ily turns pride­ful. It’s dif­fi­cult to thrive here, if you sur­vive and do well you are skilled; you’ve per­formed feats; you should mark your rites of pas­sage. This can be­come a dan­ger­ous cul­ture trap. If you’re not care­ful about it, you may start to think of the haz­ards and dif­fi­cul­ties, the “foot guns”, as nec­es­sary fea­tures - they teach you those es­sen­tial sur­vival skills that mark you out. More un­kindly, they keep the stu­pid folk out, and help pre­serve the high sta­tus of those who sur­vived long enough to be as­sim­i­lated. Uh-oh, now you’ve in­vented class pol­i­tics. The prob­lem with this think­ing is that it’s self-re­in­forc­ing. Working hard to mas­ter sys­tem com­plex­i­ties was gen­uinely re­ward­ing - you re­ally were do­ing dif­fi­cult things and do­ing them well. This is ac­tu­ally the same mech­a­nism be­hind what even­tu­ally be­came known as ’meritocracy′1, but the core point is sim­pler - if dif­fi­culty it­self be­comes a badge of ho­n­our, you’ve cre­ated a trap: any­thing that makes the sys­tem more ap­proach­able starts to feel like it’s cheap­en­ing what you achieved. You be­come in­vested in pre­serv­ing the bar­ri­ers you over­came. So the UNIX op­er­a­tor cul­ture tended to op­er­ate as a tribal mer­i­toc­racy (as op­posed to the UNIX im­ple­menter cul­ture, which fell out of a dif­fer­ent set of cul­tural norms, quite an in­ter­est­ing side bar it­self2), a cul­tural priest­hood, some­what self-re­gard­ing, re­ward­ing of clev­er­ness and knowl­edge hoard­ing, prone to feats of bravado, full of lore, with a de­fen­sive men­tal­ity of keep­ing the flame aloft, keep­ing the plebs happy and fed, and ward­ing off the bar­bar­ians. As we en­tered the 90s it was al­ready gen­tly in de­cline, be­cause cen­tralised com­put­ing was giv­ing way to the rise of the mi­cro­com­puter, but the sud­den ex­plo­sive growth of the WWW pulled in­ter­net / Unix cul­ture sud­denly back into the main­stream with an enor­mous and pub­lic op­por­tu­nity vac­uum. Everyone sud­denly has an ur­gent need to write pro­grams that push text off UNIX file-sys­tems (and data­bases) and into web pages, and Perl is uniquely po­si­tioned to have a strong first-mover ad­van­tage in this sud­denly vi­tal, novel ecosys­tem. But it’s cul­ture and val­ues are very much pulled across from this pre­vi­ous era. I re­mem­ber this ten­sion as al­ways be­ing tan­gi­bly there. Perl IRC and mail­ing lists were quite cliquey and full of ven­er­ated ex­perts and in-jokes, rough on naivety, keen on ro­bust, ver­bose de­bate, and a lit­tle sus­pi­cious of new­com­ers. And very cult-like. The “TIMTOWTDI” rule, al­though os­ten­si­bly lib­eral, lit­er­ally means ‘there is more than one way to do it in Perl’ - and you can per­haps in­fer from that that there’s lit­tle to no rea­son to do it us­ing any­thing else. Elevating ex­treme flex­i­bil­ity like this is para­dox­i­cally also an en­gine of con­ser­vatism. If Perl can al­ready do any­thing, flex­i­bly, in mul­ti­ple ways, then the lan­guage it­self does­n’t need to change - ‘we al­ready have one of those here, we don’t need new things’. This at­ti­tude de­ter­mined how Perl in­tended to han­dle evo­lu­tion: the core lan­guage would re­main sta­ble (a fort in­side a fort, only ac­ces­si­ble to high level wiz­ards), while in­no­va­tion was pushed out­ward to CPAN. You could add fea­tures out­side of core by writ­ing and con­sum­ing third party li­braries, you could bend lan­guage be­hav­iour with prag­mas with­out mod­i­fy­ing Perl it­self. The very best CPAN mod­ules could the­o­ret­i­cally be pro­moted into core, al­low­ing the lan­guage to evolve con­ser­v­a­tively from proven, widely-used fea­tures. On pa­per, this sounds rea­son­able. In prac­tice, I think it en­coded a fun­da­men­tal con­flict of in­ter­est into the com­mu­nity early on, and set the stage for many of the later growth prob­lems. I’m not go­ing to pre­tend that Perl in­vented de­pen­dency hell, but I think it turned out to be an­other one of those pro­found mis­fea­tures that their cul­tural phi­los­o­phy lead them to mis­take for virtue, and em­brace. An in­ter­est­ing thing I think has been missed dis­cussing the con­text of the orig­i­nal blog piece, about whether Perl 6 sig­nif­i­cantly im­pacted Perl growth, is the fact that Perl 6 it­self man­i­fested out of on­go­ing ar­gu­ments. Perl 6 is a schism. Here’s a oft-cited note from Larry Wall him­self about the in­ci­dent that sparked Perl 6, at OSCON 2000 We spent the first hour gab­bing about all sorts of po­lit­i­cal and or­ga­ni­za­tional is­sues of a fairly bor­ing and mun­dane na­ture. Partway through, Jon Orwant comes in, and stands there for a few min­utes lis­ten­ing, and then he very calmly walks over to the cof­fee ser­vice table in the cor­ner, and there were about 20 of us in the room, and he picks up a cof­fee mug and throws it against the other wall and he keeps throw­ing cof­fee mugs against the other wall, and he says “we are f-ed un­less we can come up with some­thing that will ex­cite the com­mu­nity, be­cause every­one’s get­ting bored and go­ing off and do­ing other things”. Perl 6 was re­ally a schism. Perl was al­ready un­der a great amount of strain try­ing to ac­com­mo­date the mod­ernising in­flux of post dot-com main­stream web ap­pli­ca­tion build­ing, along­side the en­trenched con­ser­vatism of the core main­tain­ers, and the main­te­nance bur­den of a few years ex­po­nen­tial growth of third-party li­braries, start­ing to build a frac­tal mess of slightly dif­fer­en­ti­at­ing, in­com­pat­i­ble ap­proaches of those mul­ti­ple ways to do things that were ef­fec­tively now table-stakes lan­guage fea­tures, as the de­ploy­ment land­scape started to tip­toe to­wards a more mod­ern, ubiq­ui­tous WWW3. So, while I agree that it’s wrong to gen­er­alise that ‘Perl 6 killed Perl’, I would say that Perl 6 was a symp­tom of the ir­rec­on­cil­able in­ter­nal forces that killed Perl. Although, I also in­tend to go on to point out that Perl is­n’t dead, noth­ing has ac­tu­ally killed Perl. Killed Perl is a very stu­pid way to frame the dis­cus­sion, but here we are. So… Perl 6 is cre­ated as a valve to off­set that pres­sure, and it kind of works. Up to a point. Unfortunately I think the side ef­fect re­ally is that the two branches of the cul­ture, in the process of fork­ing, dou­ble down on their en­coded norms. Perl 5.x beds down as the prac­ti­cal, al­ready solved way to do all the same things, with lit­tle need to change. Any re­quire­ments for more mod­ern ap­pli­ca­tion pat­terns that are emerg­ing in the broader web de­vel­op­ment en­vi­ron­ment, like idk, Unicode, REST clients, strict data struc­tures, asyn­chro­nous I/O, what­ever? That can ei­ther wait for Perl6 or you can pull things to­gether us­ing the CPAN if you want to move right now. Perl 6 leans the other way - they don’t need to ship im­me­di­ately, we have Perl 5 al­ready here for do­ing things, Perl 6 is go­ing to in­no­vate on every­thing, and spend it’s time get­ting there, de­sign­ing up-front.4 They spend at least two years writ­ing high level re­quire­ment specs. They even spin out a side-pro­ject try­ing to build a uni­ver­sal vir­tual ma­chine to run all dy­namic pro­gram­ming lan­guages that never de­liv­ers5 This is the land­scape where Perl’s cen­tral dom­i­nance of ‘back end’ web pro­gram­ming con­tin­ues to slip. Unfortunately, along­side the now prin­ci­pled bias to­ward cul­tural con­ser­vatism, Perl 5 has an ex­plicit ex­cuse for it. The fu­ture is over there, and ex­cit­ing, and mean­while we’re work­ing use­fully, and get­ting paid, and get­ting stuff done. Kind of OK from in­side the fort. Some day we’ll move to the newer fort, but right now this is fine. Not very at­trac­tive to new­com­ers though, re­ally. And this is also sort of OK, be­cause Perl does­n’t re­ally want those sort of new­com­ers, does it? The kind that turns up on IRC or fo­rums and asks ba­sic ques­tions about Perl 6 and sadly of­ten gets treated with open con­tempt. Meanwhile, over there­Ruby has sprouted “Ruby on Rails”, and it’s taken the dy­namic web build­ing world by storm. Rails is a sec­ond gen­er­a­tion web frame­work, that’s proudly an ‘opinionated web frame­work’. Given that the web ap­pli­ca­tion ar­chi­tec­ture is start­ing to sta­bilise into a kind of three-tier sys­tem , with a client as a web browser, a mid­dle tier as a mono­lithic ap­pli­ca­tion server, and a per­sis­tence layer as a re­la­tional data­base , and a split server ar­chi­tec­ture serv­ing sta­tic and dy­namic con­tent from dif­fer­ent routes, here is just one way to do that, with hugely de­vel­oper friendly tool­ing turn­ing this into a cookie-cut­ter so­lu­tion for the 80% core, and a plu­gin and client-side dec­o­ra­tion ap­proach that al­lows for the nec­es­sary per-site cus­tomi­sa­tion. Ruby is in­ter­est­ing as well. Ruby is kind of a Perl6 re­ally. More ac­cu­rately it’s a par­al­lel uni­verse Perl5 Ruby comes from Japan, and has de­vel­oped as an at­tempt to build some­thing sim­i­lar to Perl, but it’s de­vel­oped much later, by pro­gram­ming lan­guage en­thu­si­asts, and for the first ten years or so, it’s mostly only used in Japan. To my line of think­ing this is prob­a­bly im­por­tant. Ruby does not spring from decades of sysad­min or sysop cul­ture. Ruby is a lan­guage for pro­gram­mers, and is at this point an sen­si­ble can­di­date for build­ing some­thing like Rails with - a rel­a­tively blank can­vas for dy­namic pro­gram­ming, with many of the same qual­i­ties as Perl, with less legacy cruft, and more mod­ern niceties, like an in­te­grated ob­ject sys­tem, ex­cep­tions, straight­for­ward data struc­tures. Ruby also has adopted ‘friendliness’ as a core value, and the cul­ture over there adopts a prin­ci­pled ap­proach to ag­gres­sively wel­com­ing new­com­ers, pro­mot­ing eas­i­ness, and pro­gram­mer hap­pi­ness and con­ve­nience as strong first class prin­ci­ples. Rails is a huge hit. At this point, which is around about the time I stopped sig­nif­i­cantly us­ing Perl (2004-2005) (because I quit my job, not out of any core an­i­mos­ity to­ward it, in fact, in my day, I was re­ally quite a Perl fan), Rails is the most ap­peal­ing place to start as a new web pro­gram­mer. Adoption rate is high, com­mu­nity is great, ve­loc­ity of de­vel­op­ment is well-paced, and there’s a lovely , well-lit, on­board­ing pipeline for how to start. You don’t even re­ally need to know ruby. It has a one-shot in­stall tool, and gen­er­ates work­ing web­sites from tem­plates, al­most out of the box. It’s an ob­vi­ous start­ing point. Perl be­ing Perl, de­vel­ops sev­eral ana­logue frame­works to Rails, all of them in­ter­de­pen­dently com­pat­i­ble and in­com­pat­i­ble with each other and each oth­er’s de­pen­den­cies, all of them de­signed to be as cus­tomis­able and as user con­fig­urable as they pos­si­bly can be6 There are also the other ob­vi­ous con­tenders. PHP has been there all along, and it’s al­most com­ing up from en­tirely the op­po­site cul­tural back­ground of Perl. PHP is a users lan­guage. It’s built to be de­ployed by copy­ing script files to your home di­rec­tory, with min­i­mal server side im­pact or priv­i­leges. It’s barely de­signed at all, but it en­coun­ters ex­plo­sive growth all the way through the first (and through into the sec­ond) web era, al­most en­tirely be­cause it makes the bar­rier to on­board­ing so low as to be non-ex­is­tent. PHP gets a cou­ple of ex­tra free shots in the arm Because it’s ar­chi­tec­ture is so amenable to shared-server host­ing, it is adopted as the pri­mary im­ple­men­ta­tion lan­guage of the blog­ging boom. An en­tire gen­er­a­tion of web de­vel­op­ers is born of in­stalling and cus­tomis­ing WordPress and text-pat­tern et. al by in­stalling it di­rectly into your home di­rec­tory on a rented CPanel host ac­count. It’s the go-to an­swer for ’I’m not a pro­gram­mer re­ally but how do I get a per­sonal web site′7 This zero gate-keep­ing ap­proach keeps the PHP stack firmly on the table of ‘basic’ web pro­gram­mers all through the his­tory of the web up to the cur­rent day. Because of these ini­tially light­weight de­ploy­ment tar­gets, PHP scales like lit­tle else, mostly be­cause it’s ex­e­cu­tion model leans strongly to­wards idem­po­tent ex­e­cu­tion, with each web re­quest tear­ing up and tear­ing down the whole en­vi­ron­ment. In a sense, this is slower than keep­ing hot state around, but it does lend it­self ex­tremely well to shared-noth­ing hor­i­zon­tal scal­ing, which as the web user base in­creases gi­gan­ti­cally through­out the 2000s era, is the sim­plest route to scal­ing out. Facebook fa­mously, is built in PHP at this point in time. There is of course one other big horse in the race in this era, and it’s a par­tic­u­larly in­ter­est­ing one in many ways, cer­tainly when con­trasted with Perl. This is of course, Python. Python is a close con­tem­po­rary of Perl’s but once again, it’s roots are some­where very dif­fer­ent. Python does­n’t come from UNIX cul­ture ei­ther. Python comes from acad­e­mia, and pro­gram­ming lan­guage cul­ture. It’s kind of a for­got­ten foot­note, but Python was orig­i­nally built for the Amoeba op­er­at­ing sys­tem, and it’s in­ten­tion was to be a straight­for­ward pro­gram­ming lan­guage for script­ing this8. The idea was to build a lan­guage that could be the ‘second pro­gram­ming lan­guage’ for pro­gram­mers. Given that this is the 1980s, early 1990s, the pro­gram­mers would be ex­pected to be mostly us­ing C / C++ ,perhaps Pascal. Python was in­tended to al­low faster de­vel­op­ment for lighter weight pro­grams or script­ing tasks. I sup­pose the idea was to take some­thing that you might want to build in a shell script, but pro­vide enough high level struc­tured sup­port that you could cleanly build the kind of things that quickly be­come a prob­lem in shell scripts. So, it em­pha­sises data struc­tures, and scoped vari­ables, and mod­ules, and pri­ori­tises mak­ing it pos­si­ble to ex­tend the lan­guage with mod­ules. Typical things that ex­pe­ri­enced pro­gram­mers would want to use. The lan­guage was also de­signed to be portable be­tween the dif­fer­ent plat­forms pro­gram­mers would use, run­ning on the desk­tops of the day, but also on the server. As a con­se­quence, it had a broad stan­dard li­brary of com­mon portable ab­strac­tions around stan­dard sys­tem fea­tures - file-sys­tems, con­cur­rency, time, FFI. For quite a long time, one of python’s stan­dard mot­toes was ‘batteries in­clud­ed’. Python never set the world on fire at any par­tic­u­lar mo­ment, but it re­mained com­mit­ted to a clear evo­lu­tion­ary in­cre­men­tal de­vel­op­ment, and clean en­gi­neer­ing prin­ci­ples. Again, I think the key el­e­ment here is cul­tural tone. Python is kind of bor­ing, not try­ing to be any­one’s best lan­guage, or even a uni­ver­sal lan­guage. Python was al­ways a lit­tle fussy, maybe snobby, slightly ab­stracted away from the real world. It’s al­most as old as Perl and it just kept in­cre­men­tally evolv­ing, pick­ing up users, pick­ing up fea­tures, slowly broad­en­ing the stan­dard li­brary. The first time I saw Python pick up an un­de­ni­able main­stream ad­van­tage would also have been around the early 2000s, when Google pub­licly adopted it as one of their house stan­dard lan­guages. Never rad­i­cal, just calmly evolv­ing in it’s en­vi­rons. When I sketch out this land­scape, I re­main firmly con­vinced that most of Perl’s im­ped­ance to con­tin­ued growth were cul­tural. Perl’s huge mo­ment of rel­e­vance in the 90s was be­cause it cross-pol­li­nated two di­verg­ing user cul­tures. Traditional UNIX / data­base / data-cen­tre main­te­nance and ad­min users, and en­thu­si­as­tic early web builders and scalers. It had a cul­tural shock phase from ex­tremely rapid growth, the cen­tre could­n’t hold, and things slowly fell apart. Circling back though, it’s time to ad­dress the real ele­phant in the room. Perl man­i­festly did not die. It’s here right now. It’s in­stalled I think by de­fault, on al­most every sin­gle com­puter I own and op­er­ate, with­out me do­ing a sin­gle thing to make that hap­pen. It’s still used every day by mil­lions of peo­ple on mil­lions of sys­tems (even if that is­n’t de­lib­er­ate). It’s still used by many peo­ple en­tirely de­lib­er­ately for build­ing soft­ware, whether that’s be­cause they know it and like it and it works, or be­cause they’re in­ter­fac­ing with or work­ing on legacy Perl sys­tems (of which there are still many), or maybe they’re us­ing it still in it’s orig­i­nal in­ten­tional role - A ca­pa­ble POSIX-native script­ing lan­guage, with much bet­ter per­for­mance and a broader fea­ture-set than any shell or awk. I still oc­ca­sion­ally break it out my­self, for small scripts I would like to use more than once, or as parts of CLI pipelines. What I don’t do any more is reach for Perl first to make any­thing new. In my case, it’s just be­cause I typ­i­cally am spoilt for op­tions that are a bet­ter fit for most tasks, de­pend­ing on what­ever it is I’m try­ing to achieve. By the time I came to Perl, (1998-ish), I was al­ready on my third ca­reer phase, I had a strong UNIX back­ground, and had al­ready built real things in lisp, java, pas­cal, vi­sual ba­sic and C++. My at­ti­tude to lan­guages was al­ready in­formed by pick­ing a tool to fit the task at hand. Boy did I love Perl for a few years. The prod­uct/​mar­ket-fit for those early web days was just beau­ti­ful. The cul­ture did have too much of the neg­a­tive tropes I’ve been point­ing at, but that was­n’t re­ally a prob­lem per­son­ally for me, I’d grown up amongst the BOFHs in­side the data cen­tres al­ready, it was­n’t too hard for me to as­sim­i­late, nor pick up the core prin­ci­ples. I did oc­ca­sion­ally bounce off a cou­ple of abra­sive char­ac­ters in the com­mu­nity, but mostly this just kept me loosely cou­pled, I en­joyed how the lan­guage solved the prob­lems I needed solv­ing quickly, I en­joyed the flex­i­bil­ity, and I also en­joyed the way that it made me feel smart, and en-route to my wiz­ard’s robes and hat, when i used it to solve harder prob­lems in cre­ative ways, or de­signed ways around bugs and grem­lins. For a good 3-4 years I would have im­me­di­ately picked it as my favourite lan­guage. So as I say, I did­n’t fall out of it with any sense of pique, I just nat­u­rally moved to dif­fer­ent do­mains, and picked up tools that best fit. After Amazon, I spent t a lot of time con­cen­trat­ing on OS X and au­dio pro­gram­ming, and that in­volved a lot of ob­jec­tive C, C++. The script­ing tools in that do­main were of­ten in ruby, some­times python. For per­sonal hack­ing, I picked up lisp again9 (which I’d al­ways en­joyed in school). I dipped in and out of Perl here and there for oc­ca­sional con­tract work, but I tended to grav­i­tate more to­wards larger data­base stuff, where I typ­i­cally found C, java and python. The next time I was build­ing web things, it was all Rails and ruby, and then mov­ing to­wards the web ser­vices / REST / cloud era, the nat­ural fits were go, and of course node and JavaScript or Typescript. I’ve al­ways been a poly­glot, and I’ve al­ways been pretty com­fort­able mov­ing be­tween pro­gram­ming lan­guages. The truth of the mat­ter is, that the ma­jor­ity of pro­gram­ming work is broadly sim­i­lar, and the spe­cific im­ple­men­ta­tion de­tails of the lan­guage you use don’t mat­ter all that much, if it’s a good fit for the cir­cum­stances. I can’t imag­ine Perl dis­ap­pear­ing en­tirely in my life­time. I can re­mem­ber en­tire pro­gram­ming en­vi­ron­ments and lan­guages that are much, much deader than I can ever see Perl be­com­ing. Pascal used to be huge for teach­ing and also for desk­top de­vel­op­ment in the 8/16 bit eraOb­jec­tive C - only re­ally use­ful in­side the Apple ecosys­tem, and they’re hell bent on phas­ing it out. Before I got into the Internet, I used to build ap­pli­ca­tion soft­ware for 16 bit Windows (3.11) which was a vast mar­ket, in a mix­ture of data­base 4GLs (like PowerBuilder, Gupta/Centura SQLWindows) and Win16 C APIs. This en­tire uni­verse ba­si­cally no longer ex­ists, and is fully ob­so­lete. There must be many sim­i­lar cases.I mean who the hell re­al­is­ti­cally uses com­mon lisp any more out­side of legacy or en­thu­si­ast mar­kets? Less peo­ple than Perl I’m sure.Perl also got to be if not first, then cer­tainly early to dom­i­nate a new mar­ket par­a­digm. Plenty of things never man­age that. It’s hard to see Perl as any­thing other than an enor­mous suc­cess on these terms. Perl in­no­vated and in­flu­enced lan­guages that came af­ter in some truly sig­nif­i­cant ways. Tightly em­bed­ding reg­u­lar ex­pres­sions and ex­tend­ing reg­u­lar ex­pres­sions (the most com­monly used reg­u­lar ex­pres­sion di­alect in other tools is Perl)CPAN, for pack­age/​li­brary dis­tri­b­u­tion via the in­ter­net, with de­pen­dency res­o­lu­tion - and in­clud­ing im­por­tant con­cepts like sup­ply chain ver­i­fi­ca­tion with strong pack­age sig­na­turesA huge em­pha­sis on test­ing, au­to­mated test har­nesses, and CI. Perl test for­mat (TAP) is also widely found in other CI/harness sys­tems­Blend­ing the gap be­tween shell / script­ing / and sys­tem pro­gram­ming in a sin­gle tool. I sup­pose this is de­bat­able, but the way Perl ba­si­cally in­te­grated all the fun­da­men­tal POSIX/libc as na­tive built-ins with broadly the same se­man­tics, but with man­aged mem­ory and shell con­ven­tions was re­ally rev­o­lu­tion­ary. Before this, most lan­guages I had ever seen broadly tended to sit in one box, af­ter­wards, most lan­guages tended to span across sev­eral.Amaz­ing in­te­grated doc­u­men­ta­tion, on­line, in-tool and also man pages. POD is maybe the most suc­cess­ful ever im­ple­men­ta­tion of lit­er­ate pro­gram­ming ideas (although most of the real docs don’t in­ter­twingle the doc­u­men­ta­tion very much iirc)Just these points, and I’m sure there are many oth­ers that could be made, are enough of a legacy to be proud of. Counterfactuals are stu­pid (but also fun). If I squint, I can imag­ine that a Perl with a less re­ac­tionary cul­ture, and a health­ier ac­cep­tance of other ideas and en­vi­ron­men­tal change might have been able to evolve along­side the other tools in the web par­a­digm shift, and still oc­cupy a more cen­tral po­si­tion in to­day’s de­vel­op­ment land­scape. That’s not the Perl we have though, and that did­n’t hap­pen. And I’m very con­fi­dent that with­out the Perl we did have, the whole of mod­ern soft­ware prac­tice would be dif­fer­ently shaped. I do think Perl now lives in a legacy role, with a de­clin­ing in­flu­ence, but that’s re­ally noth­ing to feel shame or re­gret for. Nobody is go­ing to forcibly take Perl away as long as POSIX ex­ists, and so far as I can see, that means for­ever. In 2025 too, I can see the in­vis­i­ble hand creep­ing up on some of these other sys­tems I’ve men­tioned. Rust is slowly ab­sorb­ing C and C++. Ruby (and of course Rails) is clearly in de­cline, in a way that prob­a­bly con­signs it to be­come a sim­i­lar legacy state. From a cer­tain an­gle, it looks a lot like Typescript is slowly sup­plant­ing Python. I won’t be en­tirely sur­prised if that hap­pens, al­though at my age I kind of doubt I’ll live to see the day. 1 : Meritocracy is a fun word. It was orig­i­nally coined as a pe­jo­ra­tive term to de­scribe a dystopian mech­a­nism by which mod­ern i.e. Western / British so­ci­ety en­trenches and jus­ti­fies an un­fair and un­equal dis­tri­b­u­tion of priv­i­lege 2 : The UNIX im­ple­menter cul­ture, is sci­en­tific/​aca­d­e­mic and fell out of Bell Labs. I guess you could ex­tend this school of thought as a cul­tural sweep to­wards build­ing ab­stracted cloud op­er­a­tions, to­ward plan 9/ Inferno / go 3 : Web 2.0 was first de­fined in 1999 by Darcy DiNucci in a print ar­ti­cle , the term did­n’t be­come main­stream un­til it was picked up and pro­moted by Tim O’Reilly (then owner/​op­er­a­tor of perl.com, trivia fans), an as­tute in­side ob­server of the forces dri­ving web de­vel­op­ment 4: Another un­for­tu­nate bit of luck here. Right at the point of time that ‘agile’ starts get­ting some trac­tion as a more nat­ural way to em­brace soft­ware de­vel­op­ment - i.e. it­er­at­ing in small in­cre­ments against a chang­ing en­vi­ron­ment and re­quire­ments, Perl 6 de­cides to do per­haps the most wa­ter­fall open source de­vel­op­ment process ever at­tempted. . It is fif­teen years be­fore Perl 6 ships some­thing re­sem­bling a us­able pro­gram­ming lan­guage.

5 : The Parrot VM, a lovely quixotic idea, which sadly fiz­zled out, af­ter even Perl 6 stopped try­ing to tar­get it. Interestingly enough, both python and ruby both made rel­a­tively high pro­file ports to the JVM that were use­ful enough to be used for pro­duc­tion de­ploys in cer­tain niches. 6 : A side ef­fect of this de­gree of ab­strac­tion, is that as well as be­ing very hard to get started, it’s easy to fall foul of per­for­mance over­head. 7 : This ubi­tu­itious ecosys­tem of small foot­print word­press cus­tom in­stalls gives birth to the web agency model of com­mer­cial web­site build­ing / small ecom­merce sites, which thrives and is supris­ingly healthy to­day. Recent, and slighly op­ti­mistic sur­veys have pitched WordPress as pow­er­ing over 40% of all web­sites to­day. Now this is cer­tainly in­flated, but even if the re­al­is­tic num­ber is half of that, that’s still pretty damn healthy. 8 : It’s of­ten re­peated that Python was de­signed as a teach­ing lan­guage, but as far as I know, that’s not ac­tu­ally the case. The de­signer of Python, Guido Van Rossum was pre­vi­ously work­ing on a pro­ject that was a in­tended as train­ing lan­guage, called ABC, and many of ABC’s syn­tax and struc­tural fea­tures in­flu­enced or made their way into Python. 9 : Common lisp is a bet­ter an­swer to an in­fi­nitely flex­i­ble ‘everything’ chain­saw lan­guage than perl, IMHO

Accessibility bar­ri­ers in re­search are not new, but they are ur­gent. The mes­sage we have heard from our com­mu­nity is that arXiv can have the most im­pact in the short­est time by of­fer­ing HTML pa­pers along­side the ex­ist­ing PDF.

arXiv has suc­cess­fully launched pa­pers in HTML for­mat. We are grad­u­ally back­fill­ing HTML for arX­iv’s cor­pus of over 2 mil­lion pa­pers over time. Not every pa­per can be suc­cess­fully con­verted, so a small per­cent­age of pa­pers will not have an HTML ver­sion. We will work to im­prove con­ver­sion over time.

The link to the HTML for­mat will ap­pear on ab­stract pages be­low the ex­ist­ing PDF down­load link. Authors will have the op­por­tu­nity to pre­view their pa­per’s HTML as a part of the sub­mis­sion process.

The beta roll­out is just the be­gin­ning. We have a long way to go to im­prove HTML pa­pers and will con­tinue to so­licit feed­back from au­thors, read­ers, and the en­tire arXiv com­mu­nity to im­prove con­ver­sions from LaTeX.

Did you know that 90% of sub­mis­sions to arXiv are in TeX for­mat, mostly LaTeX? That poses a unique ac­ces­si­bil­ity chal­lenge: to ac­cu­rately con­vert from TeX—a very ex­ten­si­ble lan­guage used in myr­iad unique ways by au­thors—to HTML, a lan­guage that is much more ac­ces­si­ble to screen read­ers and text-to-speech soft­ware, screen mag­ni­fiers, and mo­bile de­vices. In ad­di­tion to the tech­ni­cal chal­lenges, the con­ver­sion must be both rapid and au­to­mated in or­der to main­tain arX­iv’s core ser­vice of free and fast dis­sem­i­na­tion.

Because of these chal­lenges we know there will be some con­ver­sion and ren­der­ing is­sues. We have de­cided to launch in beta with “experimental” HTML be­cause:

Accessible pa­pers are needed now. We have talked to the arXiv com­mu­nity, es­pe­cially re­searchers with ac­ces­si­bil­ity needs, and they over­whelm­ingly asked us not to wait.

We need your help. The ob­vi­ous work is done. Reports from the com­mu­nity will help us iden­tify is­sues we can track back to spe­cific LaTeX pack­ages that are not con­vert­ing cor­rectly.

HTML pa­pers on arXiv.org are a work in progress and will some­times dis­play er­rors. As we work to im­prove ac­ces­si­bil­ity we share with you the causes of these er­rors and what au­thors can do to help min­i­mize them. Learn more about er­ror mes­sages you may see in HTML pa­pers

We en­cour­age the com­mu­nity to try out HTML pa­pers in your field:

* Go to the ab­stract page for a pa­per you are in­ter­ested in read­ing.

* Look in the sec­tion where you find the link to the PDF down­load, and click the new link for HTML.

* Report is­sues by ei­ther a) click­ing on the Open Issue but­ton b) se­lect­ing text and click­ing on the Open Issue for Selection but­ton or c) use Ctrl+? on your key­board. If you are us­ing a screen reader, use Alt+y to tog­gle ac­ces­si­ble re­port­ing but­tons per para­graph.

Please do not cre­ate re­ports that the HTML pa­per does­n’t look ex­actly like the PDF pa­per

Our pri­mary goal for this pro­ject is to make pa­pers more ac­ces­si­ble, so the fo­cus dur­ing the beta phase will value func­tion over form. HTML lay­outs that are in­cor­rect or are il­leg­i­ble are im­por­tant to re­port. But we do ex­pect the HTML pa­pers to pre­sent dif­fer­ently than the same pa­per ren­dered in PDF. Line breaks will oc­cur in dif­fer­ent places and there is likely to be more white space. In gen­eral, the HTML pa­per won’t pre­sent as com­pactly. Intricate ty­po­graphic lay­outs will not be ren­dered so in­tri­cately. This is by de­sign.

HTML is a dif­fer­ent medium and brings its own ad­van­tages ver­sus PDF. In ad­di­tion to be­ing much more com­pat­i­ble with as­sis­tive tech­nolo­gies, HTML does a far bet­ter job adapt­ing to the char­ac­ter­is­tics of the de­vice you are read­ing on, in­clud­ing mo­bile de­vices.

If you are an au­thor you can help us im­prove con­ver­sions to HTML by fol­low­ing our guide to LaTeX Markup Best Practices for Successful HTML Papers.

If you are a de­vel­oper and have free de­vel­op­ment cy­cles, help us im­prove con­ver­sions! Our col­lab­o­ra­tors at LaTeXML main­tain a list of is­sues and wel­come feed­back and de­vel­oper con­tri­bu­tions.

If you are a pub­lisher, mem­ber of a so­ci­ety, or con­fer­ence or­ga­nizer you can help us im­prove con­ver­sions to HTML by re­view­ing the .cls files your or­ga­ni­za­tion rec­om­mends to au­thors for un­sup­ported pack­ages. Providing .cls files that use sup­ported pack­ages is an easy way to sup­port and sow ac­ces­si­bil­ity in the sci­en­tific com­mu­nity.

First, we want to share a spe­cial thank you to all the sci­en­tists with dis­abil­i­ties who have gen­er­ously shared their in­sights, ex­per­tise, and guid­ance through­out this pro­ject.

We want to thank two or­ga­ni­za­tions with­out which HTML pa­pers on arXiv would not be pos­si­ble: The LaTeX Project, and the LaTeXML team from NIST. We deeply thank each mem­ber of these teams for their knowl­edge, in­cred­i­ble work, and com­mit­ment to ac­ces­si­bil­ity.