January 19, 2026
Windows blooms, forges feud
Radicle 1.6.0 – Amaryllis
Blooming dev tool goes local-first; Windows hint thrills, Codeberg vs P2P debate erupts
TLDR: Radicle 1.6.0 arrives with a switch to the popular mio engine, hinting at stronger Windows support for its peer-to-peer coding tool. Comments erupted into jokes, praise for the easy CLI, and a centralization vs decentralization feud, with one user declaring they’ve ditched GitHub for good.
Radicle just dropped 1.6.0 — code name Amaryllis — a peer‑to‑peer tool that lets developers collaborate without a central website. The flower “prefers the window,” and yes, that’s a wink: the team swapped its network engine to widely-used mio, setting up better Windows compatibility. After a holiday delay, 153 commits from 12 contributors landed, and the community instantly turned it into a show.
First, the jokes: one commenter mistook it for Radicale (a calendar server) and the name-confusion meme spread like wildfire. Then the hype: fans praised the CLI (command-line tool) because it makes sharing projects simple, fast, and actually fun. But the real drama? The centralization vs decentralization flame war. One voice asked why so many open‑source teams choose Codeberg, a hosted site, instead of Radicle’s local‑first vibe. The crowd split: convenience-lovers want a familiar home base; peer‑to‑peer purists want freedom and resilience.
And the plot twist: a self-declared GitHub escapee vowed they’re “never going back,” even promising to “steal” the idea and build more tools. With Windows support teased and community energy cranked to 11, Radicle’s bloom is part upgrade, part movement. Whether you’re in it for the memes or the mission, the dev garden is buzzing.
Key Points
- •Radicle released version 1.6.0 (Amaryllis) on January 14, 2026, resuming regular releases after a holiday hiatus.
- •The release includes 153 commits from 12 contributors and provides a curl-based installation command.
- •radicle-node’s network I/O layer was migrated from netservices/io-reactor/popol to mio.
- •Reasons for migration include popol’s Unix-only support, io-reactor’s limited implementations and dependents, and broader ecosystem support for mio (including tokio).
- •A noted trade-off of adopting mio is the need to use mio::Token; future alternatives like a10 (io_uring, Windows I/O rings) are acknowledged.