jxself.org

Trials and Trisquelations

Sun, 12 Apr 2026

Trisquel version 12 (Ecne) officially launched on April 11, 2026, a little over three years after the release of version 11 (Aramo). In the modern tech landscape, three years between releases might sound like an eternity. But to me, that kind of pacing isn't a flaw - it's a feature.

When it comes to my operating system, I have a strict hierarchy of needs: First, it must be 100% free software. Second, it needs to be incredibly, predictably boring.

I want a stable, long-term support (LTS) environment where package versions are frozen at release. I don't want to wake up, run an update, and find out that a shiny new software version just broke my workflow. I want my OS to get out of my way so I can actually focus on my work. Trisquel has met those exact needs for me since I first started using it in 2010, and Ecne continues that proud tradition.

But producing a "boring" and stable OS is anything but easy. Behind the scenes, it requires a staggering amount of work to keep the system secure, modern, and uncompromisingly free.

The "Trisquelations"

Between the release of Aramo and Ecne, the core Trisquel package-helpers repository recorded nearly 400 commits. What's incredible is that just 7 contributors shouldered this massive undertaking.

The trials and tribulations - what I like to call the "Trisquelations" - that this small team persevered through to deliver Ecne are staggering. At a high level, here's what they were up against:

  • The Browser Treadmill: Keeping Abrowser (Trisquel's de-branded, privacy-respecting version of Firefox) updated is a relentless, never-ending battle. Because the modern web moves fast, the team had to constantly rewrite privacy patches, rip out undesirable stuff from upstream, and manually backport entirely new toolchains (like modern Rust and LLVM compilers) to get the browser to build on a stable OS base.
  • The Kernel Cat-and-Mouse Game: Upstream Linux is constantly changing, introduces proprietary blobs, and Canonical adds even more. Ensuring freedom means the Trisquel team had to meticulously update deblobbing scripts to scrub out unfree code and silence firmware warnings.
  • Improving the Base: Because Trisquel builds on top of an Ubuntu base, the team had to strip out an increasing number of commercial tie-ins. This meant ripping out Ubuntu Pro integrations, removing Snap enforcement, and preventing built-in tools from recommending non-free repositories.
  • The Fragile App Ecosystem: Modern, secure communication apps (like Jami, Telegram, and Nextcloud) have complex dependency chains. Getting these to work securely on an LTS base required untangling and backporting dozens of specific libraries.
  • Multi-Architecture Support: Let's not forget that the Titanic's still sinking. The team put in the hard work to ensure kernels, installers, and software continued to build for architectures like ARM and POWER.

The Unseen Heroes

While the commit logs highlight an immense technical effort, with the vast majority of those commits coming from Luis Guzmán (ark74), alongside Ruben Rodríguez, Jacob K, bill-auger, and dinomug, lines of code never tell the whole story.

There's an entire ecosystem of people whose work isn't necessarily attached to a Git commit, but is still vital. As the official release announcement perfectly puts it, making Ecne possible required a community contributing "through code, patches, bug reports, translations, and advice."

The release announcement gave special thanks to Luis "Ark74" Guzmán, prospero, icarolongo, Avron, knife, Simon Josefsson, Christopher Waid (ThinkPenguin), Denis "GNUtoo" Carikli, and the broader community that keeps the project alive and free.

Come In, The Water's Fine

Despite the mountain of interdependencies, upstream commercialization, and the relentless pace of web browser updates, this tiny team delivered. They shielded users from the chaos of modern software development and provided a sanctuary where our computers remain our own.

If you're tired of proprietary software, of your operating system fighting you, pushing advertisements, forcing updates, or serving as a telemetry-gathering tool for a massive corporation, I highly encourage you to make the switch to free software. Come on in; the water's fine. It's stable, it's free, and it stays out of your way.

A Call for Help (and Funding)

Trisquel survives on the dedication of a passionate community, but they shouldn't have to carry the weight of an entire distribution's freedom alone. Let's help make the next round of Trisquelations a little bit easier for them. Here's how you can pitch in:

  • Contribute financially: Server hosting, infrastructure, and the sheer time required to maintain a secure, free OS aren't free. If you have the means, please consider making a financial donation to the project. It is one of the most direct ways you can ensure this vital work continues.
  • Contribute your time: Please consider volunteering. Whether it's packaging software, managing patches, translating interfaces, testing, reporting bugs, or hanging out in the forums to help people, your time makes a difference.

Looking Ahead: The RISC-V Frontier

As much as I appreciate the stable, boring present that Ecne provides, I can't help but look forward to the future - specifically, the prospect of RISC-V support in Trisquel.

Of course, RISC-V is only an instruction set. A complete, functioning computer is much more than that just the instructions it understands. Modern systems require a complex web of secondary components, and even if the CPU's design is free, the surrounding silicon has lots of places where proprietary binary blobs love to hide. They lurk in memory controllers that require initialization firmware (such as DDR PHYs), power management co-processors, within integrated Wi-Fi, Bluetooth, or graphics chips, and more.

My next personal project will be finding the time to hunt down appropriate RISC-V hardware to run it on. That is, assuming a board currently exists that can truly be used in software freedom. The hardware landscape is notoriously tricky, and finding a RISC-V machine that doesn't rely on hidden, proprietary binary blobs to initialize the RAM or boot the system and can run with software freedom included is a challenge of its own, and there's no guarantee of success. The trials and tribulations continue.