DEV Community: Sythos

From ClasseViva to Home Assistant: a dashboard architecture in practice / Da ClasseViva a Home Assistant: architettura di una dashboard in pratica

Sythos — Thu, 15 Oct 2026 14:29:10 +0000

English Italiano

English	Italiano
The challenge ClasseViva presents school information across different screens. CVV Dashboard brings averages, grades, noticeboard messages, agenda events, teacher annotations, published reports and homework into Home Assistant. The project has two parts: a Home Assistant integration that exposes the data, and a Lovelace card that presents it. The card discovers the integration’s entities automatically, so its configuration does not need a manually copied `entity_id`.	Il problema ClasseViva distribuisce le informazioni scolastiche su schermate diverse. CVV Dashboard le raccoglie in Home Assistant: medie, voti, comunicazioni in bacheca, agenda, annotazioni dei docenti, scrutini pubblicati e compiti. Il progetto ha due componenti: un’integrazione Home Assistant che espone i dati e una card Lovelace che li presenta. La card rileva automaticamente le entità dell’integrazione, senza dover copiare a mano gli `entity_id` nella configurazione.
One card, several views The card can show averages, grades, the noticeboard, agenda, notes, reports, homework or a combined view. This keeps the YAML configuration consistent while allowing a dashboard to focus on one kind of information at a time. The average view can show the overall average and school periods. The grade view includes subject averages and recent grades; noticeboard messages can show formatted text and attachments.	Una card, più viste La card può mostrare medie, voti, bacheca, agenda, note, scrutini, compiti oppure una vista combinata. La configurazione YAML resta coerente e la dashboard può concentrarsi su un tipo di informazione alla volta. La vista delle medie mostra la media generale e i periodi scolastici. Quella dei voti include medie per materia e voti recenti; nella bacheca le comunicazioni possono mostrare testo formattato e allegati.
Calendars stay separate Each student gets four Home Assistant calendars: Agenda: a summary of homework and annotations. Homework: assigned work only. Teacher notes: annotations, alerts and virtual classrooms. Room bookings: classroom reservations only. Keeping them separate makes each calendar independently selectable and colour-coded in Home Assistant.	I calendari restano distinti Per ogni studente Home Assistant riceve quattro calendari: Agenda: riepilogo di compiti e annotazioni. Compiti: solo i compiti assegnati. Note dei docenti: annotazioni, avvisi e aule virtuali. Prenotazioni aula: solo le prenotazioni delle aule. Separarli permette di selezionare ogni calendario indipendentemente e di assegnargli un colore in Home Assistant.
School years without duplicate accounts The card has a school-year selector. When data for a year is not already configured, it can fetch that year on demand using the active login and cache the result for 30 minutes. This makes it possible to browse previous years without adding the same account again just for that purpose. The automatic option follows the school year, which runs from September 1 to August 31. The first load of a past year can take a few seconds.	Anni scolastici senza duplicare gli account La card offre un selettore dell’anno scolastico. Se i dati di un anno non sono già configurati, può recuperarli al momento riutilizzando il login attivo e conservarli in cache per 30 minuti. Così si possono consultare gli anni passati senza aggiungere di nuovo lo stesso account. L’opzione automatica segue l’anno scolastico, dal 1° settembre al 31 agosto. Il primo caricamento di un anno passato può richiedere qualche secondo.
Multiple students and Home Assistant layouts A dashboard can select which student accounts to show, set their order and use custom display names. The same card can also be placed in a Lovelace Panorama view; separate cards can sit side by side when a household wants to compare different views or students. The project requires Home Assistant 2024.7.0 or later and HACS. The Lovelace card is included with the integration and loads automatically.	Più studenti e layout Home Assistant La dashboard può scegliere quali account mostrare, in quale ordine e con quali nomi visualizzati. La card si può usare anche in una vista Lovelace Panorama; card separate possono stare affiancate per mostrare viste o studenti diversi. Il progetto richiede Home Assistant 2024.7.0 o successivo e HACS. La card Lovelace è inclusa nell’integrazione e viene caricata automaticamente.
Project scope CVV Dashboard is an independent project and is not affiliated with or supported by Gruppo Spaggiari. Its documentation describes access to the signed-in user’s own ClasseViva account; the Home Assistant integration stores the account password there. Technical reference: source code and README This article was prepared with AI assistance and checked against the project documentation.	Ambito del progetto CVV Dashboard è un progetto indipendente, non affiliato né supportato da Gruppo Spaggiari. La documentazione descrive l’accesso ai dati dell’account ClasseViva dell’utente autenticato; l’integrazione Home Assistant salva lì la password dell’account. Riferimento tecnico: codice sorgente e README Questo articolo è stato preparato con l’assistenza dell’AI e verificato rispetto alla documentazione del progetto.

The challenge

ClasseViva presents school information across different screens. CVV Dashboard brings averages, grades, noticeboard messages, agenda events, teacher annotations, published reports and homework into Home Assistant.

The project has two parts: a Home Assistant integration that exposes the data, and a Lovelace card that presents it. The card discovers the integration’s entities automatically, so its configuration does not need a manually copied entity_id.

Il problema

ClasseViva distribuisce le informazioni scolastiche su schermate diverse. CVV Dashboard le raccoglie in Home Assistant: medie, voti, comunicazioni in bacheca, agenda, annotazioni dei docenti, scrutini pubblicati e compiti.

Il progetto ha due componenti: un’integrazione Home Assistant che espone i dati e una card Lovelace che li presenta. La card rileva automaticamente le entità dell’integrazione, senza dover copiare a mano gli entity_id nella configurazione.

One card, several views

The card can show averages, grades, the noticeboard, agenda, notes, reports, homework or a combined view. This keeps the YAML configuration consistent while allowing a dashboard to focus on one kind of information at a time.

The average view can show the overall average and school periods. The grade view includes subject averages and recent grades; noticeboard messages can show formatted text and attachments.

Una card, più viste

La card può mostrare medie, voti, bacheca, agenda, note, scrutini, compiti oppure una vista combinata. La configurazione YAML resta coerente e la dashboard può concentrarsi su un tipo di informazione alla volta.

La vista delle medie mostra la media generale e i periodi scolastici. Quella dei voti include medie per materia e voti recenti; nella bacheca le comunicazioni possono mostrare testo formattato e allegati.

Calendars stay separate

Each student gets four Home Assistant calendars:

Agenda: a summary of homework and annotations.
Homework: assigned work only.
Teacher notes: annotations, alerts and virtual classrooms.
Room bookings: classroom reservations only.

Keeping them separate makes each calendar independently selectable and colour-coded in Home Assistant.

I calendari restano distinti

Per ogni studente Home Assistant riceve quattro calendari:

Agenda: riepilogo di compiti e annotazioni.
Compiti: solo i compiti assegnati.
Note dei docenti: annotazioni, avvisi e aule virtuali.
Prenotazioni aula: solo le prenotazioni delle aule.

Separarli permette di selezionare ogni calendario indipendentemente e di assegnargli un colore in Home Assistant.

School years without duplicate accounts

The card has a school-year selector. When data for a year is not already configured, it can fetch that year on demand using the active login and cache the result for 30 minutes. This makes it possible to browse previous years without adding the same account again just for that purpose.

The automatic option follows the school year, which runs from September 1 to August 31. The first load of a past year can take a few seconds.

Anni scolastici senza duplicare gli account

La card offre un selettore dell’anno scolastico. Se i dati di un anno non sono già configurati, può recuperarli al momento riutilizzando il login attivo e conservarli in cache per 30 minuti. Così si possono consultare gli anni passati senza aggiungere di nuovo lo stesso account.

L’opzione automatica segue l’anno scolastico, dal 1° settembre al 31 agosto. Il primo caricamento di un anno passato può richiedere qualche secondo.

Multiple students and Home Assistant layouts

A dashboard can select which student accounts to show, set their order and use custom display names. The same card can also be placed in a Lovelace Panorama view; separate cards can sit side by side when a household wants to compare different views or students.

The project requires Home Assistant 2024.7.0 or later and HACS. The Lovelace card is included with the integration and loads automatically.

Più studenti e layout Home Assistant

La dashboard può scegliere quali account mostrare, in quale ordine e con quali nomi visualizzati. La card si può usare anche in una vista Lovelace Panorama; card separate possono stare affiancate per mostrare viste o studenti diversi.

Il progetto richiede Home Assistant 2024.7.0 o successivo e HACS. La card Lovelace è inclusa nell’integrazione e viene caricata automaticamente.

Project scope

CVV Dashboard is an independent project and is not affiliated with or supported by Gruppo Spaggiari. Its documentation describes access to the signed-in user’s own ClasseViva account; the Home Assistant integration stores the account password there.

Technical reference: source code and README

This article was prepared with AI assistance and checked against the project documentation.

Ambito del progetto

CVV Dashboard è un progetto indipendente, non affiliato né supportato da Gruppo Spaggiari. La documentazione descrive l’accesso ai dati dell’account ClasseViva dell’utente autenticato; l’integrazione Home Assistant salva lì la password dell’account.

Riferimento tecnico: codice sorgente e README

Questo articolo è stato preparato con l’assistenza dell’AI e verificato rispetto alla documentazione del progetto.

JS Barcode Universal 1.6.4: security hardening, real formats and a better Bun day

Sythos — Mon, 05 Oct 2026 10:32:08 +0000

There is a new release of Sythos JS Barcode Universal: v1.6.4.

It is not a dramatic “we changed every public API at 3 a.m.” release. It is the nicer kind: a focused security and delivery tune-up that makes the package safer to ship, keeps the runtime surface boring (in the best possible way), and gives Bun a little more room to prove it belongs at the party.

The short version

@sythos/js_barcode_universal@1.6.4 is an open-source MIT-licensed JavaScript/TypeScript SDK for generating and reading 1D and 2D barcodes. It runs in browsers, Web Workers, Node.js and Bun, with zero runtime dependencies.

The release keeps the public barcode API stable. The important changes are in the security and release plumbing:

the development-only brace-expansion resolution is now 5.0.12, covering the three reported GHSA advisories;
a CI lockfile guard checks vulnerable resolutions before dependencies are installed;
the green Dependabot updates for fast-check 4.10.2 and the CodeQL upload action 4.38.2 are included;
the npm package and GitHub release are aligned at 1.6.4, with build provenance attached;
the published SDK still has no runtime dependencies.

In other words: the barcode engine did not suddenly grow a secret subscription plan. The release makes the boring parts more defensible, which is exactly what boring infrastructure should do.

“Are all those formats actually usable?”

Short answer: yes, and the repository is deliberately specific about what “usable” means.

This is not a README that lists fifty impressive names and then quietly hands you a stub. The runtime exposes listFormats(), where writing and reading are reported as separate capabilities. The format table in the README shows the same distinction, so an application can ask the SDK what a format really supports instead of guessing from its name.

The library includes the familiar stuff — QR, Data Matrix, Aztec, PDF417, EAN, UPC, Code 128 and GS1 families — alongside postal formats, Micro QR, rMQR, MaxiCode, Han Xin, DotCode, colour experiments and structured payload helpers such as vCard, VIN, SEPA QR, Swiss QR-bill and AAMVA data.

The useful detail is the project’s honesty about the edges:

a format can be write-capable, read-capable, or both;
experimental and bounded profiles are labelled as such;
Pharmacode, for example, is intentionally write-only in the generic image reader;
payload conventions are documented as payload conventions, not magically renamed into new symbologies;
a format is not treated as finished merely because the project can round-trip its own output.

The verification story goes beyond “encode, decode, high-five.” The repository uses structural invariants, first-principles reference values, property-based tests, independent black-box implementations and, most importantly, real scanner/device evidence. A symbol that only its author’s decoder can read is not a victory lap; it is a very elaborate typo.

Security without pretending to be a magic shield

Barcode data is untrusted input. Pixels, camera frames, rendering options and decoded text all cross a trust boundary. Version 1.6.4 hardens the development dependency path and the CI guard, while the SDK itself keeps its runtime boundary explicit:

image dimensions and channel values are validated before decoder work;
render sizes, scales, margins and bar heights are bounded before allocations;
browser examples put decoded values in text nodes rather than interpreting them as HTML;
the published package carries no runtime dependency tree that can quietly grow behind it.

That does not turn a decoded URL into a trustworthy URL. If an application scans a code, it still has to validate destinations, identifiers and business rules for its own domain. The project says this plainly in SECURITY.md and the security guide, which is much healthier than promising that a barcode library is also a complete application security policy.

npm is current, not an afterthought

The package is published as @sythos/js_barcode_universal@1.6.4, and latest points at 1.6.4.

Install it with:

npm install @sythos/js_barcode_universal

The package is plain ESM, ships declarations, keeps its source and generated bundles visible, and has zero runtime dependencies. You can import the whole surface or use focused subpaths when you only need, say, the QR writer and SVG renderer.

The release also carries build provenance and the release page provides the generated bundles, the npm tarball and SHA256SUMS:

Bun gets a real compatibility check

Bun is not a decorative badge in this release. The repository has a dedicated bun-compat.yml workflow that runs the build and test toolchain under Bun on every push.

That workflow covers linting, TypeScript compilation, generated-output checks, browser bundle generation, focused format tests, core tests, property-based checks, documentation assertions, public type checks and the package-surface/zero-runtime-dependency validation.

The practical usage is pleasantly uneventful:

import {
  decode,
  encode,
  toImageData,
  toSVG,
} from '@sythos/js_barcode_universal';

const payload = 'Hello from a barcode that read the instructions';
const matrix = encode(payload, { format: 'qr', ecc: 'M' });
const image = toImageData(matrix, { scale: 8, margin: 4 });
const result = decode(image, { formats: ['qr'] });

console.log(result[0]?.text);

Run the same ESM file with either:

node barcode.mjs
bun barcode.mjs

No adapter circus, no native add-on, no hidden image codec. The application still owns camera capture and image decoding; the SDK stays focused on barcode encoding, decoding and rendering.

The paperwork lives where it should

The legal and provenance material is not sprinkled through random comments like confetti. It has its own, inspectable home:

licenses/ contains the per-format licensing and provenance notes;
NOTICE.md records origin, attribution and verification boundaries;
docs/guides/legal-exclusions.md lists formats excluded for licensing, patent, trademark or issuing-authority reasons;
LICENSE carries the MIT licence plus the informational specification/trademark appendix.

There is an important footnote here: engineering notes are not legal advice, and a provenance record is not a patent clearance certificate. The point is that the questions are visible, scoped and reviewable instead of being hidden behind a cheerful “MIT” badge.

So, what changed for a consumer?

If you already use the SDK, this is a low-drama upgrade:

npm update @sythos/js_barcode_universal

The public barcode API stays the same. You get the security dependency fix, the lockfile guard, refreshed development tooling, a current npm package and stronger Bun verification without having to rewrite your encoder or decoder calls.

If you are evaluating the project, start with the repository, inspect the release, read the security and legal notes, then generate a symbol and point an independent scanner at it. That last step is still delightfully old-fashioned — and still the most convincing demo.

Happy encoding, decoding and legally-aware pixel sorcery. 🧃

Disclosure: AI assistance was used for the editorial draft and for test/documentation workflow review. The release facts and links above are taken from the public repository and release metadata; the SDK itself does not add an AI runtime dependency.

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.