DEV Community: Sythos

IRC Never Died

Sythos — Fri, 25 Sep 2026 10:18:49 +0000

Every few years, somebody announces that IRC is dead.

Usually, the announcement comes from inside a JavaScript application that needs 800 MB of RAM to display three messages and a suspiciously animated emoji.

But IRC is not dead. It was merely waiting for the rest of the internet to remember how useful text can be.

A very short history of not disappearing

IRC — Internet Relay Chat — was born in 1988. It gave the internet channels, nicknames, operators, /join, /topic, /me, and the ability to enter a conversation without first building a personal brand.

Before feeds, followers, reactions, engagement metrics and notifications that sound like tiny emergency sirens, people joined a channel and talked.

That basic idea still works remarkably well.

A technical conversation on IRC can move at an almost suspicious speed:

Someone asks a question.
Someone else answers.
The first person asks a follow-up.
A third person pastes a log or a command.
Someone discovers the missing semicolon.
Everybody goes back to work.

No algorithm has to decide whether the question deserves visibility. No feed has to “boost” the answer. No one has to turn a debugging session into a personal-content strategy.

Text is not the poor version of a conversation. In technical communities, it is often the most efficient version.

Why IRC can be better than social media for technical work

I am not saying that IRC is better for every human activity. I am saying that, for technical discussion, it often has a much better signal-to-noise ratio than mainstream social platforms.

The conversation is immediate. The context is visible. The channel topic tells you what the room is supposed to be about. People can disagree, repair the answer, and move on without producing a 47-post thread explaining the disagreement.

There is also less ceremony.

You do not need to collect followers before asking a question. You do not need to format your message for an algorithm. You do not need to wait for a platform to decide whether your post is “engaging”.

And trolls? They still exist. IRC is not a magical troll-repellent crystal.

The difference is that IRC networks and channels usually expose more direct moderation tools. Depending on the network, you have channel operators, voice and half-operator roles, channel modes, bans, quiets, kicks, network operators, services and account controls.

The exact hierarchy varies, but the general idea is simple: moderation is close to the conversation.

That often means fewer drive-by disturbances and faster intervention than the classic social-media workflow of “report, wait, receive an automated message, wonder what just happened”.

Azzurra: the Italian starting point

If you are in Italy — or simply want to visit an Italian IRC community — Azzurra is the obvious place to look first.

Azzurra has been online since 1997 and remains one of the longest-running Italian IRC networks. It is Italian in history and atmosphere, but it is not a private club. Everybody is welcome.

The only thing worth bringing is a little patience.

Not every channel is primarily English-speaking, and not every conversation will magically switch language because one visitor arrived from another continent. Say hello, read the topic, watch the rhythm of the channel and ask politely. That is not a terrible protocol for real life either.

I would start by looking for:

#italia, for general Italian conversation;
#linux, for technical discussions around Linux and free software.

Check the current topic and channel availability when you connect. IRC channels evolve, sleep, wake up again and sometimes change personality without asking anybody for permission.

You can connect through the official Azzurra webchat or with any IRC client. Azzurra also presents Grappa as an independent third-party way to reach the network from a browser — useful, active, and not a replacement for the official webchat.

Libera.Chat and the international side

For a more international free-software crowd, Libera.Chat is the obvious reference point.

It hosts communities around open-source projects, programming languages, distributions, tools and documentation. You will find channels for Linux, Python, Rust, JavaScript, networking, compilers, editors and plenty of things that have never needed a venture-capital-backed emoji picker.

If neither Azzurra nor Libera.Chat feels close to your topic, search Google.

Seriously:

IRC network <your language>
IRC network <your country>
IRC <your project name>
IRC <your favourite programming language>

There are more networks and channels than any single directory can explain. Some are enormous, some are tiny, some are quiet until the exact right person appears.

That is part of the charm.

Enter the Grappa biome

The modern reboot that brought me back to this whole subject is grappa-irc, described in the origin story “grappa-irc: reinventing IRC for 2026”.

The idea is not to replace IRC with a shiny new protocol. It is to keep IRC and add the conveniences people now expect from modern software.

Grappa acts as an always-on bouncer. It stays connected to the upstream IRC network, keeps the conversation available, and exposes a modern REST and real-time interface to clients.

The web client does not need to parse raw IRC. It receives structured data, history and events through the server.

That is a surprisingly sensible boundary.

You keep the protocol, the channels and the network culture, but you get persistence, mobile access, notifications, history and a client that does not disappear every time your phone decides to save battery.

There is also an interesting AI thread in the project’s public story. The development pipeline openly describes AI-assisted sessions with a human holding the rulings, and the earlier project write-up talks about an IRC bot experiment.

The important part is the transparency.

AI here is most interesting as supervised tooling, testing and documentation support, plus clearly identified experiments. It should not become an invisible vacuum cleaner for everybody’s messages.

If you bring an LLM-powered bot to a network, read that network’s rules first. Libera.Chat’s current policy requires permission, transparency and human supervision for LLM-enabled bots. Do not drop an uninvited robot into #linux and call it community outreach.

Choose your glass

The Grappa ecosystem is becoming a small biome of clients and bridges.

Cicchetto is the integrated web PWA. It is installable from the browser, works well on phones and keeps the IRC-shaped experience without forcing the browser to speak raw IRC.
Shottino is the CLI counterpart, available inside the grappa-irc repository. With its IRC-server mode, old-school clients such as irssi, WeeChat or HexChat can connect to Grappa as if it were a normal IRC server.
Resentin is a native Android client built separately with Kotlin and Compose.
Bicchierino is an independent bridge project that exposes a stateless IRC-style facade to Grappa, useful when you want older clients to remain part of the conversation.
Cordiale is the newest arrival: a native desktop client written in Rust with Slint. It speaks Grappa’s REST and Phoenix Channels protocol instead of IRC directly, and the project includes links to the releases, the client protocol and the Cicchetto reference.

Different clients, same general idea: keep IRC’s simplicity, then choose the interface that fits your device and your tolerance for browser tabs.

There is a channel for almost everything

IRC is not only for Linux people arguing about init systems.

You can find channels for:

#linux;
#ai;
individual programming languages;
distributions and desktop environments;
self-hosting and system administration;
electronics and hardware;
art;
literature;
cinema;
music;
games;
local communities;
and wonderfully specific interests that would never survive a social-media recommendation engine.

Some channels are busy. Some are slow. Some are almost empty until somebody asks exactly the right question.

That is fine. IRC does not promise a constant stream of content. It offers a place where a conversation can begin.

So, is IRC back?

Maybe it never left.

It was still there while we were busy installing increasingly complicated chat applications to reproduce a room, a nickname and a scrolling list of messages.

Pick a network. Pick a client. Join a channel. Read the topic. Say hello.

Try Azzurra if you want an Italian starting point. Try Libera.Chat for international free-software communities. Search for other networks near your language or interests.

And if somebody tells you IRC is dead, send them a /me raises a glass.

The banner image was generated with AI for illustration. I am spectacularly bad at the artistic stuff, so I let the machine handle the neon, the robot and the suspiciously well-stocked bar.

[Boost]

Sythos — Mon, 07 Sep 2026 22:58:10 +0000

Felipe L

Aug 19

Debian Starts Voting on AI/LLM Contributions for Future Development

#debian #ai #llm #automation

2 min read

CERN Is Moving 2,200 Accelerator Systems to Debian 13 — No USB Stick Required

Sythos — Mon, 07 Sep 2026 22:07:02 +0000

This is one of those Linux stories that deserves attention even beyond the usual distro wars.

By the end of 2026, CERN plans to move more than 2,200 industrial computers and embedded systems to Debian 13 “Trixie”. These machines are connected to roughly 17,000 devices spread across an area of about 43 square kilometres.

So no, this is not a researcher replacing the operating system on a laptop between two coffee breaks. Linux is moving directly into one of the most complex scientific infrastructures on the planet.

The backstory matters

For many years, CERN lived in the Red Hat ecosystem: first with Scientific Linux, developed in part by CERN and Fermilab, and later with CentOS.

Then CentOS Linux changed direction. Red Hat discontinued the traditional model and moved the project towards CentOS Stream.

That was a perfectly legitimate business decision, of course. But when an organisation chooses CentOS specifically for its stability, predictability and long life cycles, a few eyebrows may go up.

Probably in Geneva too.

The CERN problem was very practical. Continuing down the expected migration path could have required changing not only software, but also a significant amount of specialised hardware.

A 2023 risk assessment considered a scenario involving:

roughly CHF 5.4 million in costs;
redesigning 11 electronic boards;
rack modifications;
extensive rewiring;
many hours of work from technicians and engineers;
and an estimated success probability of around 20%.

At some point, someone probably remembered an old and rather useful feature of software:

You can change it.

Hardware invoices are usually less flexible.

Change the software, not the accelerator

Instead of modifying a mountain of perfectly functional hardware to fit a new operating system, CERN chose the opposite direction.

The goal was to make its software less dependent on one specific Linux distribution and select a platform that fitted the existing infrastructure more naturally.

The choice fell on Debian 13 “Trixie”.

Naturally, this does not mean inserting a USB stick into 2,200 machines, clicking “Install Debian”, and going out for coffee.

The migration includes:

software distribution systems;
boot procedures;
drivers for specialised hardware;
and, most importantly, the gradual removal of distribution-specific dependencies.

There is another small detail: these systems control particle accelerators.

That means updates and migrations have to be coordinated with maintenance windows and the operational calendar of the accelerators.

The classic Friday afternoon deploy followed by “What could possibly go wrong?” is probably considered a crime against humanity here.

Debian at CERN does not mean “Red Hat is gone”

There is an important clarification behind some of the headlines: CERN is not abandoning Red Hat or its wider ecosystem completely.

The move to Debian focuses on industrial and embedded systems used for accelerator control.

Other parts of the infrastructure, including datacentres and systems used by the experiments, will continue to use platforms such as RHEL and AlmaLinux.

Still, the decision is significant.

Debian is a community distribution that has spent three decades prioritising stability, compatibility and predictability instead of reinventing itself commercially every few years.

Now it is going to run thousands of systems belonging to one of the most advanced scientific infrastructures in the world.

There is also a nice bit of irony here. After all the changes around CentOS, one of the world’s most important scientific organisations ended up choosing a distribution famous for a very simple philosophy:

It will be released when it is ready.

When you are controlling a particle accelerator, that may not be a bad philosophy at all.

Sources and further reading

Image note

The banner image was generated with AI for illustrative purposes. I’m hopeless at the artistic stuff, so I let the machine handle the drawing. It is not an official CERN photograph or communication.

Gulo Gulo: An Open-Source, Tenant-Isolated Mail-First Groupware Platform

Sythos — Sun, 06 Sep 2026 08:48:25 +0000

Gulo Gulo is an open-source, mail-first groupware platform built from a shared TypeScript core. It is designed for people who want mail, calendars and contacts to live in one tenant-aware service instead of being scattered across unrelated integrations.

One core, three deployment paths

The project supports three practical deployment targets:

Standalone for a Linux host under the operator's control.
cPanel for hosting environments where the panel already owns the account and DNS workflow.
Plesk for Debian or Ubuntu-oriented hosting environments.

All three targets are built from the same TypeScript source. The packaging boundary stays specific to the operating environment, while the groupware contracts remain shared and testable.

Mail, calendars and contacts

Gulo Gulo is mail-first, but it is not limited to a mailbox view. The platform brings together:

webmail and tenant-isolated mail operations;
calendars through CalDAV;
address books through CardDAV;
quotas, retention and audit policy;
tenant-scoped identity and data boundaries.

The CalDAV and CardDAV contracts cover interoperable iCalendar and vCard data, conditional writes, ETags, sync tokens and tombstones. Discovery endpoints provide the usual .well-known and service metadata, with a safe manual fallback when a client cannot discover the service automatically.

The browser surface keeps calendar and contact views deliberately readable, while the authenticated DAV endpoints provide the protocol surface for compatible clients. The project still documents the boundary honestly: real-world verification against every external mail server and every CalDAV/CardDAV client remains a deployment responsibility.

Working with existing hosting panels

If a domain already runs on cPanel or Plesk, Gulo Gulo can sit behind the existing panel rather than replacing the whole hosting account. The panel may continue to own hosting and DNS workflow; Gulo Gulo owns groupware policy, identity, mail, calendars, contacts, quotas, retention and audit.

That integration is deliberately tenant-bound and read-only today. Provider-specific reconciliation is kept separate from the core so that the boundary stays understandable and reversible.

Every deployment still needs a local SMTP/IMAP service reachable by the application. Gulo Gulo connects to that mail service as a client; it does not pretend that a package install alone creates a complete mail infrastructure.

A project that keeps its operational edges visible

The repository includes security, data, interoperability and operations contracts, along with install and upgrade documentation. The current distributable artifacts are operator-facing archives, and the README records where field verification is still required instead of presenting CI as proof of production deployment.

Gulo Gulo is released under the MIT License.

Transparency note

AI-assisted tools are used for test tools and documentation review, including GitHub test-workflow work. Gulo Gulo itself is not an AI product.

Explore Gulo Gulo

JS Barcode Universal SDK: Read & Write 1D and 2D Barcodes

Sythos — Wed, 02 Sep 2026 12:10:32 +0000

JS Barcode Universal SDK: Read and Write 1D and 2D Barcodes Anywhere

What started as a small JavaScript barcode experiment has grown into a full JavaScript and TypeScript SDK for creating, detecting, and reading barcodes across browsers and Node.js.

The goal was simple: keep barcode handling portable, transparent, dependency-free, and useful in real projects without tying it to a specific framework, operating system, or proprietary runtime.

Source code on GitHub

The complete source code, tests, examples, and release history are available here:

JS Barcode Universal on GitHub

Feel free to inspect the implementation, open an issue, or contribute.

From JavaScript to JavaScript plus TypeScript

The SDK started as a JavaScript-only project.

TypeScript support was added later, with declarations and typed APIs kept in sync with the JavaScript implementation. The result is a library that works naturally in both ecosystems:

JavaScript and ESM imports
TypeScript projects with typed APIs
Browser applications
Web Workers
Node.js services
HTML5 pages served by any standard HTTP server

The minimum setup is intentionally straightforward: use Node.js for server-side work, or serve an HTML5 page through an HTTP server for browser-based generation and reading.

No platform-specific barcode runtime is required.

One SDK for generation, detection, and reading

The project includes examples and reusable snippets for:

Creating barcodes
Detecting supported formats automatically
Reading barcode content
Processing image data from files, canvases, or cameras
Running repeated camera scans
Handling both monochrome and color barcode workflows

The examples are deliberately practical rather than decorative. They show the expected integration pattern without forcing a particular application architecture.

The SDK supports black-and-white barcodes, traditional 1D formats, matrix codes, and 2D color-capable formats. Generation, detection, and decoding are covered consistently, so color matrix and 2D formats are not treated as second-class citizens.

Modern browser rendering

When a modern browser exposes WebGPU, barcode generation can use its integrated GPU rendering pipeline.

If WebGPU is not available, the renderer falls back to WebGL. This keeps the same API usable across newer and older browser environments while still taking advantage of hardware acceleration where possible.

The idea is not to make every browser look like a game engine. It is simply to use the graphics capabilities already available in the browser when they are useful.

Zero runtime dependencies

The SDK does not require external runtime libraries.

It is fully open source, released under the MIT License, and distributed without hidden precompiled components. The shipped implementation is inspectable source code rather than a black box wrapped around a proprietary engine.

That makes it easier to:

Audit the implementation
Bundle it for web applications
Run it in controlled environments
Adapt it to internal tooling
Review the code before deployment
Keep production installations lightweight

Development and testing tools may be used during project maintenance, but the published SDK itself remains dependency-free at runtime.

Documentation and examples

The complete documentation is available on the project website:

JS Barcode Universal documentation

It includes:

Installation and import examples
Browser and Node.js usage
Generation workflows
Automatic detection
Camera reading
Supported formats and variants
TypeScript usage
Rendering options
Security and input-handling guidance
Licensing notes
Format-specific limitations

The repository also contains standalone examples for creating, detecting, and reading barcodes so you can start experimenting without first building an entire application around the SDK.

Available through npm

The package is publicly available on npm:

@sythos/js_barcode_universal on npm

Install it with:

npm install @sythos/js_barcode_universal

Then import the main API or the format-specific modules you need.

Format coverage and legal transparency

The formats included in the SDK were reviewed against public technical and licensing information to confirm that they could be used, reused, distributed royalty-free, or otherwise included without known blocking restrictions for this project.

That review is documented rather than hidden.

Some formats are intentionally not included because their patents, trademarks, licensing terms, or platform restrictions make them unsuitable for an MIT-licensed, independent SDK. The documentation identifies those exclusions and explains the reason for keeping them outside the core package.

Open source is much more useful when the boundaries are clear.

A small note about AI

AI was used extensively to help design and maintain the test suites and to keep the documentation under control. It was not used as the shipped runtime implementation of the SDK.

This project also comes with a slightly unusual historical footnote: for roughly one third of a century, I had not written a single line of source code. So yes, I leaned heavily on AI to keep up with testing, documentation, and the general paperwork surrounding the project.

I grew up with the old rule:

“If I struggle to write it, you’ll struggle to read it.”

Apparently, the industry eventually decided to give us better tools. About time.

Try it, inspect it, improve it

JS Barcode Universal is intended to be useful both as a ready-to-use SDK and as a readable foundation for developers who want to understand how barcode generation and reading work in JavaScript and TypeScript.

If you need a lightweight barcode toolkit that works in browsers and Node.js, supports both 1D and 2D formats, and does not hide the implementation behind precompiled binaries, give it a try.

The project is open, the license is MIT, and the documentation is waiting for your experiments.