L'autocomplétion de nos intentions

Lorsque j'ai commencé à utiliser mon premier smartphone, en 2012, j'utilisais évidemment le clavier fourni par défaut qui proposait de l'autocomplétion.

Il ne m'a fallu que quelques jours pour être profondément choqué. L'autocomplétion proposait des mots qui convenaient parfaitement, mais qui n'étaient pas ceux que j'avais en tête. En acceptant une autocomplétion par désir d'économiser quelques pressions de doigts, je me retrouvais avec une phrase différente de ce que j'avais initialement envisagé. Je modifiais le cours de ma pensée pour m'adapter à l'algorithme !

C'était choquant !

Moi qui étais passé au Bépo quelques années plus tôt et qui avais découvert les puissances de la dactylographie pour affiner mes idées, je ne pouvais imaginer laisser une machine me dicter ma pensée, même pour un texte aussi mondain qu'un SMS. Je me suis donc mis en quête d'un clavier optimisé pour usage sur un écran tactile minuscule, mais sans autocomplétion. J'ai trouvé MessagEase, que j'ai utilisé pendant des années avant de passer à ThumbKey, version libre du précédent.

• Le bépo sur le bout des doigts (ploum.net)
• Writing on a smartphone: review of 8pen and MessagEase (ploum.net)
• dessalines/thumb-key: A privacy-conscious Android keyboard made for your thumbs (github.com)

Le choc fut encore plus violent lorsqu'apparurent les suggestions de réponses aux emails dans l'interface Gmail. Ma première expérience avec ce système fut de me voir proposer plusieurs manières de répondre par l'affirmative à un email professionnel auquel je voulais répondre négativement. Avec horreur, je perçus en moi un vague instinct de cliquer pour me débarrasser plus vite de cet email corvée.

Cette expérience m'inspira la nouvelle « Les imposteurs », lisible dans le recueil « Stagiaire au spatioport Omega 3000 et autres joyeusetés que nous réserve le futur » (qui est justement disponible à -50% jusqu'au 15 décembre ou à prix normal, mais sans frais de port chez votre libraire).

• Stagiaire au spatioport Omega 3000 à -50% (pvh-editions.com)

L'autocomplétion manipule notre intention, cela ne fait aucun doute. Et s'il y a bien quelque chose que je souhaite préserver chez moi, c'est mon cerveau et mes idées. Comme un footballeur préserve ses jambes, comme un pianiste préserve ses mains, je chéris et protège mon cerveau et mon libre arbitre. Au point de ne jamais boire d'alcool, de ne jamais consommer la moindre drogue : je ne veux pas altérer mes perceptions, mais, au contraire, les affiner.

Mon cerveau est ce que j'ai de plus précieux, l'autocomplétion même la plus basique est une atteinte directe à mon libre arbitre.

• The reason why i don't use AI or even code completion (unixdigest.com)

Mais, avec les chatbots, c'est désormais une véritable économie de l'intention qui se met en place. Car si les prochaines versions de ChatGPT ne sont pas meilleures à répondre à vos questions, elles seront meilleures à les prédire.

Non pas à cause de pouvoir de divination ou de télépathie. Mais parce qu'elles vous auront influencé pour vous amener dans la direction qu'elles auront choisie, à savoir la plus profitable.

• Des marchands d'attention aux architectes de l'intention (danslesalgorithmes.net)

Une partie de l'intérêt disproportionné que les politiciens et les CEOs portent aux chatbots vient clairement de leur incompétence voire de leur bêtise. Leur métier étant de dire ce que l'audience veut entendre, même si cela n'a aucun sens, ils sont sincèrement étonnés de voir une machine être capable de les remplacer. Et ils sont le plus souvent incapables de percevoir que tout le monde n'est pas comme eux, que tout le monde ne fait pas semblant de comprendre à longueur de journée, que tout le monde n'est pas Julius.

• Mon collègue Julius (ploum.net)

Mais, chez les plus retors et les plus intelligents, une partie de cet intérêt peut également s'expliquer par le potentiel de manipulation des foules. Là où Facebook et TikTok ont ponctuellement influencé des élections majeures grâce à des mouvements de foule virtuels, une ubiquité de ChatGPT et consorts permet un contrôle total sur les pensées les plus intimes de tous les utilisateurs.

Après tout, j'ai bien entendu dans l'épicerie de mon quartier une femme se vanter auprès d'une amie d'utiliser ChatGPT comme conseiller pour ses relations amoureuses. À partir de là, il est trivial de modifier le code pour faire en sorte que les femmes soient plus dociles, plus enclines à sacrifier leurs aspirations personnelles pour celles de leur conjoint, de pondre plus d'enfants et de les éduquer selon les préceptes ChatGPTesques.

Contrairement au fait de résoudre les « hallucinations », problème insoluble, car les Chatbots n'ont pas de notion de vérité épistémologique, introduire des biais est trivial. En fait, il a été démontré plusieurs fois que ces biais existent déjà. C'est juste que nous avons naïvement supposé qu'ils étaient involontaires, mécaniques.

Alors qu'ils sont un formidable produit à vendre à tous les apprentis dictateurs. Un produit certainement rentable et pas très éloigné du ciblage publicitaire que vendent déjà Facebook et Google.

Un produit qui apparaît comme parfaitement éthique, approprié et même bénéfique à l'humanité. Du moins si on se fie à ce que nous répondra ChatGPT. Qui confirmera d'ailleurs son propos en pointant vers plusieurs articles scientifiques. Rédigés avec son aide.

11 Dec 2025 5:10am GMT

The room formally known as "lightning talks" room is now known as /dev/random. Last year we experimented with running a more spontaneous lightning talk format, with a submission deadline closer to the event and strict short time limits (under five minutes) for each speaker. The experiment was a success, so we're going to continue using this format in the upcoming FOSDEM edition and expand it slightly. To avoid getting the existing lightning talk room mixed up with the new format lightning talks, we have renamed it to /dev/random. The format is still the same as in previous years, with 15舰

11 Dec 2025 5:10am GMT

In The Big Blind, investor Fred Wilson highlights how AI is revolutionizing geothermal energy discovery. This sentence stood out for me:

It is wonderfully ironic that the technology that is creating an energy crisis is also a potential solve for that energy crisis.

AI consumes massive amounts of electricity, but also helps to discover new sources of clean energy. The source of demand might become the source of supply. I emphasized the word "might" because history is not on our side.

But energy scarcity is a "discovery problem", and AI excels at discovery. The geothermal energy was always there. The bottleneck was our ability to find it. AI can analyze seismic data, geological surveys and satellite imagery at a scale no human can match.

The quote stood out because technology rarely cleans up its own mess. More cars don't fix traffic and more coal doesn't fix pollution. Usually it takes a different technology to clean up the mess, if it can be cleaned up at all. For example, the internet created information overload, and search engines were invented to help manage it.

But here, for AI and energy, the system using the resource might also be the one capable of discovering more of it.

I see a similar pattern in open source.

Most open source projects depend on a small group of maintainers who review code, maintain infrastructure and keep everything running. They shoulder a disproportionate share of the work.

AI risks adding to that burden. It makes it easier for people to generate code and submit pull requests, but reviewing those code contributions still falls on the same few maintainers. When contributions scale up, review capacity has to keep pace.

And just like with energy discovery, AI might also be the solution. There already exist AI-powered review tools that can scan pull requests, enforce project standards and surface issues before a human even looks at them. If you believe AI-generated code is here to stay (I do), AI-assisted review might not be optional.

I'm no Fred Wilson, but as an occasional angel investor, such review tools look like a good way to go long on vibe coding. And as Drupal's Project Lead, I'd love to collaborate with the providers of these tools. If we can make open source maintenance more scalable and sustainable, everyone benefits.

So yes, the technology making a situation worse might also be capable of helping to solve it. That is rare enough to pay attention to.

11 Dec 2025 5:10am GMT

The Linux Mint team released today the Cinnamon 6.6 desktop environment, which will be the default in the upcoming Linux Mint 22.3 (Zena) release expected in late December 2025 or in early 2026.

11 Dec 2025 4:45am GMT

Given the recent release of FreeBSD 15, I started off my testing in looking at how FreeBSD 15.0 improves performance versus FreeBSD 14.3. Now it's onto the next important question: how is FreeBSD 15.0 performing relative to Linux on servers? Here are some benchmarks exploring that topic today.

11 Dec 2025 3:13am GMT

The GNU C Library's malloc implementation is now enabling 2MB Transparent Huge Pages (THP) by default for AArch64 Linux. This is being done in the name of better performance -- a healthy 6.25% performance improvement is noted for SPEC with this change...

11 Dec 2025 1:42am GMT

Cinnamon 6.6 introduces a redesigned menu, smoother animations, and extensive fixes across applets, improving the desktop experience.

10 Dec 2025 8:10pm GMT

Raspberry Pi Imager 2.0.2 boosts performance with direct I/O bypass, zero-copy buffering, and faster verification, while refining the UI and accessibility.

10 Dec 2025 7:30pm GMT

OpenTofu 1.11 introduces ephemeral resources, safer temporary data handling, and language updates for more secure, flexible infrastructure automation.

10 Dec 2025 4:52pm GMT

Not all of Ubuntu's flavours have applied for long-term support status in next year's 26.04 release. Per the outcome of a recent Ubuntu Technical Board meeting, only 7 of the 10 official offshoots are designated LTS releases: - Oh, and the 'oh yeah, that's a flavour' flavour: (No shade; I just always forget about little ol' Kylin). However, two Ubuntu flavours did not apply for LTS status for 26.04: No Ubuntu Unity LTS? Expected in light of challenges facing the distro (there was no Ubuntu Unity 25.10 release) because the incumbent project lead is, reportedly, now busy with higher education. […]

You're reading Two Ubuntu Flavours Won't Be LTS Releases Next Year, a blog post from OMG! Ubuntu. Do not reproduce elsewhere without permission.

10 Dec 2025 4:18pm GMT

Telecommunications networks are undergoing a cloud-native revolution. 5G promises ultra-fast connectivity and real-time services, but achieving those benefits requires an infrastructure that is agile, low-latency, and highly reliable. Kubernetes has emerged as a cornerstone for telecom operators to meet 5G demands. In 2025, Canonical Kubernetes delivers a single, production-grade Kubernetes platform with long-term support (LTS) and telco-specific optimizations, deployable across clouds, data centers, and the far edge.

This blog explores how Canonical Kubernetes empowers 5G and cloud-native telco workloads with high performance, enhanced platform awareness (EPA), and robust security, while offering flexible deployment via snaps, Juju, or Cluster API. We'll also highlight its integration into industry initiatives like Sylva, support for GPU/DPU acceleration, and synergy with MicroCloud for scalable edge infrastructure.

The rise of the cloud-native telco

Telecom decision-makers face immense pressure to evolve their networks rapidly and cost-effectively. Traditional, hardware-centric architectures struggle to keep pace with 5G's requirements for low latency, high throughput, and dynamic scaling. This is where Kubernetes - the de facto platform for cloud-native applications - comes in. Kubernetes brings powerful automation, scalability, and resiliency that allow telcos to manage network functions like software across data centers, public clouds, and far-edge deployments. The result is a more agile operational model: services can be rolled out faster, resources automatically optimized to demand, and updates applied continuously without disrupting critical services. In the 5G era, such agility is essential for delivering innovations like network slicing, multi-access edge computing (MEC), and AI-driven services.

At the same time, Kubernetes opens the door for telcos to refactor their network functions into microservices. Instead of relying on monolithic appliances or heavy virtual machines, operators can deploy cloud-native network functions (CNFs) - essentially containerized network services - that are lighter and faster to roll out than traditional virtual network functions (VNFs). By shifting to CNFs, new network features (whether a 5G core component or a firewall) can be introduced or updated in a fraction of the time, using automated CI/CD pipelines instead of lengthy manual upgrades. This approach helps telcos simplify the migration from legacy systems to a more agile, software-driven network model.

However, adopting Kubernetes for telecom workloads also means meeting rigorous performance and reliability standards. Carrier-grade services like voice, video, and core network functions can't tolerate unpredictable delays or downtime. Telco leaders need a Kubernetes platform that combines cloud-native flexibility with telco-grade performance, security, and support. Canonical Kubernetes answers that call, providing a Kubernetes distribution specifically tuned for telecommunications needs.

Canonical Kubernetes: optimized for cloud-native 5G networks and edge computing

Canonical's Kubernetes distribution has been engineered from the ground up to address the unique challenges of 5G and cloud-native telco cloud deployments. It is a single, unified Kubernetes offering that blends the ease of use of lightweight deployments with the robustness of an enterprise-grade platform. Importantly, Canonical Kubernetes can be deployed and managed in whatever way best fits a telco's environment - whether installed as a secure snap package or integrated with full automation tooling like Juju (model-driven operations) or Kubernetes Cluster API (CAPI). This flexibility means operators can start small at the network edge or scale up to carrier-core clusters, all using the same consistent platform. Notably, Canonical Kubernetes brings cloud-native telco-friendly capabilities in the areas of performance, networking, operations, and support:

High performance & low latency

Real-time linux kernel support ensures that high-priority network workloads execute with predictable, ultra-low latency, a critical requirement for functions like the 5G user plane function (UPF). In parallel, built-in support for advanced networking (including SR-IOV and DPDK) enables fast packet processing by giving containerized network functions direct access to hardware, dramatically reducing network I/O latency for high bandwidth 5G applications. Together, these features allow cloud-native network functions to meet stringent performance and determinism once only achievable on specialized telecom hardware.

GPU acceleration

Canonical Kubernetes integrates seamlessly with acceleration technologies to support emerging cloud-native telco workloads. It works with NVIDIA's GPU and networking operators to leverage hardware accelerators (GPUs, SmartNICs, DPUs) for intensive tasks. It supports NVIDIA's Multi-Instance GPU (MIG), which expands the performance and value of the NVIDIA's data center GPUs, such as the latest GB200 and RTX PRO 6000 Blackwell Server Edition by partitioning the GPU into up to seven instances, each fully hardware isolated with its own high-bandwidth memory, cache, and streaming multiprocessors. The partitioned instances are transparent to workloads which greatly optimizes the use of resources and allows for serving workloads with guaranteed QoS.

This means telecom operators can run AI/ML analytics, media processing, or virtual RAN computations that take advantage of GPUs and DPU offloading within their Kubernetes clusters - all managed under the same platform. By tapping into hardware acceleration, telcos can deliver advanced services (like AI-driven network optimization or AR/VR streaming) with high performance, without needing separate siloed infrastructure.

Operational efficiency and automation

Day-0 to Day-2 operations are streamlined through automation in Canonical's stack. The distribution supports full lifecycle management - clusters can be deployed, scaled, and updated via one-step commands or integrated CI/CD pipelines, reducing manual effort and errors. Using Juju charms, Canonical's model-driven operations further simplify complex orchestration, enabling teams to configure and update Kubernetes and related services in a repeatable, declarative way. Built-in self-healing and high availability features ensure that the platform can recover from failures automatically, keeping services running without intervention.

This high degree of automation translates into faster rollout of new network functions and updates (with minimal downtime), allowing telco teams to focus on innovation rather than routine ops tasks.

Edge flexibility

Canonical Kubernetes is designed to run from the core to the far edge with equal ease. Its lightweight, efficient design (delivered as a single snap package) results in a low resource footprint, making it viable even on a one- or two-node edge cluster in a remote site. At the same time, it scales up to multi-node deployments for central networks. The platform supports a variety of configurations - from a single node for an ultra-compact edge appliance, to a dual-node high-availability cluster, to large multi-node clusters for data centers - all with the same tooling and consistent experience.

This flexibility allows operators to extend cloud capabilities to edge locations (for ultra-low latency processing) while managing everything in a unified way. In practice, Canonical's solution can power cloud-native telco IT workloads, 5G core functions, and edge applications under one umbrella, meeting the specific performance and latency needs of each environment.

Long-Term support and stability

Canonical backs its Kubernetes with long-term support options far exceeding the typical open-source release cycle. Each Canonical Kubernetes LTS version can receive security patches and maintenance for up to 15 years, ensuring a stable foundation for cloud-native telco services over the entire 5G rollout and beyond. (For comparison, upstream Kubernetes offers roughly 1 year of support per release).

This extended support window means carriers can avoid frequent, disruptive upgrades and rest assured that their infrastructure remains compliant over the long term. Such a commitment to stability is a key reason telecom operators choose Canonical - long-term maintenance provides confidence that critical network workloads will run on a hardened, well-maintained platform for many years.

Cost efficiency and vendor neutrality

As an open-source, upstream-aligned distribution, Canonical Kubernetes has no licensing costs and prevents vendor lock-in. Telcos are free to deploy it on their preferred hardware or cloud, and they benefit from a large ecosystem of Kubernetes-compatible tools and operators. The platform's efficient resource usage and automation also help drive down operating costs - by improving hardware utilization and simplifying management, it enables operators to serve growing traffic loads without linear cost increases. In short, Canonical's Kubernetes offers carrier-grade performance and features at a fraction of the cost of proprietary alternatives, all while keeping the operator in control of their technology roadmap.

Enabling a new wave of cloud-native telco services

Using Canonical Kubernetes, cloud-native telcos can position themselves to innovate faster and operate more efficiently in the 5G era. They can readily stand up cloud-native 5G Core functions, scale out Open RAN deployments, and push applications to the network edge - all on a consistent Kubernetes foundation. In fact, Kubernetes makes it feasible for telcos to transition from traditional VNFs on virtual machines to containerized CNFs, reducing resource overhead and speeding up deployment of network features. This means legacy network applications can be modernized step-by-step and run alongside new microservices on the same platform, avoiding risky "big bang" overhauls.

The result is not only technical efficiency but business agility: operators can launch new services (from enhanced mobile broadband to IoT analytics) in weeks instead of months, respond quickly to customer demand spikes, and streamline the integration of new network functions or vendors.

Early adopters in the industry are already seeing the benefits. For example, Canonical's Kubernetes has been embraced in initiatives like the European Sylva open telco cloud project, in part due to its security, flexibility and long-term support advantages. This momentum underscores that a performant, open Kubernetes platform is becoming a strategic asset for telcos aiming to stay ahead in a competitive landscape. Perhaps most importantly, Canonical Kubernetes lets telcos focus on delivering value to subscribers - ultra-reliable connectivity, rich digital services, tailored enterprise solutions - rather than getting bogged down in infrastructure complexity. It abstracts away much of the heavy lifting of deploying and upgrading distributed systems, while providing the controls needed to meet strict cloud-native telco requirements. The combination of automation, performance tuning, and openness creates a powerful engine for telecom innovation.

Cloud-native at any scale: Canonical Kubernetes meets MicroCloud

At the edge, complexity is the enemy. That's why Canonical Kubernetes pairs naturally with MicroCloud, our lightweight production-grade cloud infrastructure for distributed environments. MicroCloud fits the edge use case extremely well: it is easy to deploy, fully automated, and optimized for bare-metal and low-power sites. Drop it into a telco cabinet, regional hub, or remote data center, and you get a resilient control plane for running Kubernetes, virtualization, and storage with zero overhead.

In such deployments, MicroCloud and Canonical Kubernetes form a tightly integrated stack that brings cloud-native operations to the far edge. Need to orchestrate CNFs next to VMs? Spin up a single-node cluster with high availability? Scale to dozens of locations without rearchitecting? This combo makes it possible, with snaps for simple updates, Juju for full automation, and long-term support built in.

Conclusion: building the future of cloud-native telco on open source Kubernetes

5G and edge computing are reshaping telecom networks, and Kubernetes has proven to be an essential technology powering this evolution. Industrial IoT, automotive applications , smart cities, robotics, remote health care, and the gaming industry rely on high data transfer, close to real time latency, very high availability and reliability. Canonical Kubernetes brings the best of cloud-native innovation to the telecom domain in a form that aligns with carriers' operational realities and performance needs. It delivers a rare mix of benefits - agility and efficiency from automation, high performance for demanding workloads, freedom from lock-in, and assured long-term support - making it a compelling choice for any telco modernizing its infrastructure.

Telecommunications leaders looking to become cloud-native telcos should consider how an open-source platform like Canonical Kubernetes can serve as a foundation for growth. Whether the goal is to reduce operating costs in the core network, roll out programmable 5G services at the edge, or simply break free from proprietary constraints, Canonical's Kubernetes distribution provides a proven path forward.

Explore further

To dive deeper into how Canonical Kubernetes meets telco performance and reliability requirements, we invite you to read our detailed white paper: Addressing telco performance requirements with Canonical Kubernetes. It offers in-depth insights and benchmark results from real-world cloud-native telco scenarios. Additionally, visit our blogs on Ubuntu.com and Canonical.com for more success stories and technical guides - from 5G network modernization strategies to edge:

• Edge Networking gets smarter: AI and 5G in action
• Canonical releases FIPS-enabled Kubernetes
• Canonical Kubernetes officially included in Sylva 1.5

Visiting MWC 2026? Book a meeting with Canonical to find out more.

10 Dec 2025 3:47pm GMT

10 Dec 2025 12:30pm GMT

In software engineering, we often talk about the "iron triangle" of constraints: time, resources, and features. You can rarely fix all three. At many companies, when scope creeps or resources get tight, the timeline is often the first element of the triangle to slip.

At Canonical, we take a different approach. For us, time is the fixed constraint.

This isn't just about strict project management. It is a mechanism of trust. Our users, customers, and the open source community need to know exactly when the next Ubuntu release is coming. To deliver that reliability externally, we need a rigorous operational rhythm internally, and for over 20 years, we have honored this commitment.

Here is how we orchestrate the business of building software, from our six-month cycles to the daily pulse of engineering:

Fig. 1 Canonical's Operating Cycle

The six-month cycle

Our entire engineering organization operates on a six-month cycle that aligns with the Ubuntu release cadence. This cycle is our heartbeat. It drives accountability and ensures we ship features on time.

To make this work, we rely on three critical control points:

• Sprint Readiness Review (SRR): This is where prioritization happens. Before a cycle begins, we don't just ask "what fits?": we ask "what matters?" We go through feedback to find the most valuable engineering opportunities, ensuring we prioritize quality and impact over volume. We don't start the work until we know the scope is worth the effort.

• Product Roadmap Sprint: The SRR culminates in this one-week, face-to-face event. This is the formal moment of truth where we close out the previous cycle and leadership signs off on the plan for the next one. It ensures that every team leaves the room with a clear, approved mandate.

• Midcycle Review: Three months in, we hold a "Virtual Sprint" to check our progress. Crucially, we review any "bad news", in which we immediately identify items that will not ship or are at risk. By addressing what won't happen upfront, leadership can make informed decisions to course-correct immediately rather than letting a deadline slip.

This discipline ensures we stay agile, and that we can adjust our trajectory halfway through without derailing the entire delivery.

The two-week pulse

While the six-month cycle sets the destination, the "pulse" gets us there. A pulse is our version of a two-week agile sprint.

Crucially, these pulses are synchronized across the entire company, on a cross-functional basis. Marketing, Sales, and Support all operate on this same frequency. When a team member says, "we will do it next pulse," everyone, regardless of department, knows exactly what that means. This creates a shared expectation of delivery that keeps the whole organization moving in lockstep.

Sprints are for in-person connection

We distinguish between a "pulse" (our virtual, two-week work iteration) and a "sprint." For us, a sprint is a physical, one-week event where teams meet face-to-face.

We are a remote-first company, which makes these moments invaluable. Sprints provide the high-bandwidth communication and human connection needed to sustain us through months of remote execution.

We also stagger these sprints to separate context. Our Engineering Sprints happen in May and November (immediately after an Ubuntu release) so teams can focus purely on technical roadmapping. Commercial Sprints happen in January and July, aligning with our fiscal half-years to focus on business value. This "dual-clock" system ensures that commercial goals and technical realities are synchronized without overwhelming the teams.

Managing the exceptions

Of course, market reality doesn't always adhere to a six-month schedule. Customers have urgent needs, and high-value opportunities appear unexpectedly. To handle this without breaking our rhythm, we use the Commercial Review (CR) process.

The CR process protects our engineering teams from chaos while giving us the agility to say "yes" to the right opportunities.

• Protection: We don't let unverified requests disrupt the roadmap. A Review Board assesses every non-standard request before we make a promise.
• Conscious trade-offs: If a new request is critical, we ask: "What are we removing to make space for this?" It forces a conscious decision. We review the roadmap and agree on what gets deprioritized to satisfy the new request.

This ensures that when we do deviate from the plan, it is a strategic choice, not an accident.

Quality as a natural habit

Underpinning this entire rhythm is a commitment to quality standards. We follow the Plan, Do, Check, Act (PDCA) cycle, a concept rooted in ISO 9001. While we align with these formal frameworks, it has become a natural habit for us at Canonical.

This operational discipline is what enables up to 15 years of LTS commitment on a vast portfolio of open source components, providing Long-Term Support for the entire, integrated collection of application software, libraries, and toolchains. Offering 15 years of security maintenance on our entire stack is only possible because we are operationally consistent. Long-term stability is the direct result of short-term discipline.

By sticking to this rhythm, we ensure that Canonical remains not just a source of great technology, but a reliable partner for the long haul.

10 Dec 2025 12:22pm GMT

LFX Insights is a handy platform from the Linux Foundation that provides a variety of data on open source projects. Among the statistics it reports is contributions outside of working hours. Some users reported errors with how this information is reported, which got me thinking about the value of this measure. The short version: there's very little value.

Why measure outside-of-working-hours contributions?

LFX Insights includes this measure as a signal of a project's sustainability. Projects that rely heavily on people making after hours contributions, the thinking goes, will have a harder time attracting and retaining contributors.

As a software consumer, you don't want your upstreams to suddenly disappear because that will present supply chain risks. It could mean vulnerabilities go unpatched. It could also mean that new features aren't added. Either way, this puts the onus on the project's users to carry the load.

As a project leader, you may be less concerned about whether or not a company downstream has to devote extra engineering time, but you probably do want your contributors to stick around anyway. Onboarding, mentoring, and growing contributors takes a lot of time and effort. You want to make sure people can stick around.

Why this measure fails

Despite the good intentions of measuring contributions outside working hours, the reality fails to deliver. There are some straightfoward reasons for this. Not everyone's working hours are the same. Not everyone's working hours are consistent. Some people use a different time zone on their computer. Not everyone's working days are the same. Holidays vary widely across countries and religions. People (hopefully) take time off.

Then there's the cultural mismatch. Linux Foundation projects are, to a first approximation, by companies for companies. The Linux Foundation is a 501(c)(6), not a charity, so it makes sense that it would view the world through a business lens. I don't fault them for that. LF project contributors are more likely to make contributions during the working day than contributors to a "hobbyist" project.

But that workday tendency doesn't necessarily mean people will stick around projects longer if the project is tied to their job. As the last few years have shown, tech sector layoffs can come for anyone at any time. If someone is only working on an open source project because it's part of their job, then when the job changes, they'll probably stop. People who work on an open source project for non-job reasons will likely stick around through job changes.

Thus one could argue that a project with a high degree of outside-working-hours contributions is more sustainable.

What to measure instead

If measuring contributions outside of working hours isn't helpful, what is? Focus on what you're worried about. Worried that everyone will disappear? Measure the activity over time. Worried that when a new vulnerability is discovered the lone maintainer will be backpacking through the Alps? Measure the spread of the contributions. Worried that the project doesn't have enough people to follow secure coding practices? Measure the security posture.

Of course, the best answer is to stop trying to measure sustainability and contribute to making the project more sustainable instead.

This post's featured photo by Joshua Olsen on Unsplash.

The post The do's and don'ts of measuring contributions "outside of working hours" appeared first on Duck Alignment Academy.

10 Dec 2025 12:00pm GMT

Generative AI systems are changing the way people interact with computers. MCP (model context protocol) is a way that enables generate AI systems to run commands and use tools to enable live, conversational interaction with systems. Using the new linux-mcp-server, let's walk through how you can talk with your Fedora system for understanding your system and getting help troubleshooting it!

Introduction

Large language models (LLMs) can be an invaluable tool when investigating an issue on a Linux system. However, this can involve a lot of copy/pasting of information from the Linux terminal into a web based interface to an LLM model.

The model context protocol (MCP) acts as a bridge, enabling LLMs to interact with external tools and data sources. The linux-mcp-server utilizes this protocol to give LLMs the ability to interact with a Fedora Linux system. Instead of you manually copying and pasting terminal output, the linux-mcp-server enables the LLM to directly query system information and log entries.

By enabling an LLM direct access to system information and logs, it is transformed into an active part of the investigation process when troubleshooting an issue. It empowers an LLM to directly query the system state, allowing it to help identify performance bottlenecks, and identify important log entries that might be missed by a manual review.

What is the model context protocol (MCP)?

Anthropic introduced MCP in November 2024 as an open standard for LLM tool use. This provides a way for LLMs to interact with outside systems and data sources.

Prior to MCP, there wasn't as strong a standard and ecosystem for LLM systems to call tools. LLMs were thus frequently limited to have only the information contained in their training. They were isolated from the outside world. For example, if you asked an LLM "what is the weather going to be next week", the LLM would respond with a message indicating that it doesn't know what the weather will be, as it doesn't have access to that information. MCP helps solve this problem by enabling a standardized way for an LLM to access an outside data source, such as the weather forecast.

At a high level, users can use an AI agent application, such as Goose (open source), or Claude Desktop, and specify which MCP servers they would like to use. The AI agent application informs the LLM that there are tools available via these MCP servers that can be used to help answer the requests from the user. The LLM model can then decide when to invoke these tools.

MCP is an open standard. You have the flexibility to use MCP servers, such as linux-mcp-server, with either open source-licensed LLM models, or hosted proprietary LLM models.

What is the linux-mcp-server?

The linux-mcp-server is a project started by Red Hat's RHEL Engineering team. It provides a number of tools that enable an LLM to query information from a Linux system, such as system info, service information and logs, process information, journald and other logs, network information, and storage and disk information. For a full list of the tools provided, refer to the project's Github page.

These tools, provided by linux-mcp-server, are focused on providing the LLM access to read-only information. In the future, we'll be exploring expanding past these read-only use cases.

The linux-mcp-server can be used to interact with the local Fedora Linux system that it is running on. It can also be used to interact with remote Fedora Linux systems over SSH. For example, if you have SSH key authentication setup with the remote systems, you could make a request to your AI agent application such as "Determine the current memory usage on the fedora1.example.com, fedora2.example.com, and fedora3.example.com servers".

Prerequisites

The main components needed are an AI agent application, access to LLM model inference, and the linux-mcp-server.

There are a number of options for the AI agent application, both open source and proprietary. An example of an open source AI agent is Goose, which provides an RPM that can be installed on Fedora.

There are several LLM model inference options, ranging from locally hosted open source models, to proprietary hosted LLM models. If hosting a model locally, you generally need to have GPU/accelerator hardware available. Open source tools that can be used to locally host LLM models include RamaLama, llama.cpp, and Ollama. There are a number of open source LLM models capable of tool calling. These include models such as gpt-oss-20b and Granite 4 small.

Once you've installed your preferred AI agent application, the next step is to install the linux-mcp-server and configure your AI agent application to use it. The linux-mcp-server Github page includes installation instructions, and configuration details for Goose and Claude Desktop.

Use cases for linux-mcp-server

Dear Fedora, why are you so slow today?

Has this happened to you? Time to hop on a call and give a demo. You're pumped. It's your go-time aaaaand… your system starts lagging. Folks on the call say your video is choppy or they can't understand you. OH NO.

You've got to assess what's up, quickly. Run `top`, check `dmesg`, check your network connection (read the man page for `netstat` because you can't remember the flag you want), check `journalctl`, cross-reference what you're seeing, then start killing processes, restarting services, reloading kernel modules willy-nilly based on hastily-crafted theories, see if it improves…

This is a case where you could actually ask the system to tell you why it's slow and give it the ability to do the analysis via linux-mcp-tools. The LLM you connect with won't just run the commands through the MCP server; it will understand what the numbers it gets means in context and be able to explain in human terms.

So let's start working with a relatively new laptop. It's a Thinkpad T14S with the AMD Ryzen AI Pro 7 ( Ryzen AI 360 chip.) Recently one of the wifi networks it must connect to regularly was upgraded. It now has issues with the network connection stability. So let's talk to Goose + gpt-oss:20b + linux-mcp-server about it. Here's the initial prompt I used:

My Wifi doesn't work very well. It cuts out after a few minutes. Help me fix it. Can you find the error messages in the system logs and diagnose the problem?

It responded with the following:

I'll help you diagnose your WiFi connectivity issues by examining the system logs for error messages related to your network interfaces and wireless connectivity. Let me start by gathering information about your system and checking the relevant logs.

It then made a series of tool calls, including Get System Information, Get Network Interfaces, Get Journal Logs, Get Hardware Information, Get Service Status service_name:NetworkManager, Get Service Status service_name:wpa_supplicant, Read Log File. The result was this analysis, which is the actual problem I was hoping it could find!

Not too bad an analysis and set of debugging steps! I'll follow up in the comments and let you know if the solution works.

Where'd my disk space go, Fedora?

Trawling through `du` on the command line, converting the numbers in your head, sorting them - it can be tedious. We even have graphical tools like `baobab`, but it takes time to load in the results and explore the data. And sometimes you might have questions it can't answer in terms of the risk of deleting a specific directory, or the age of a specific file. It's easier to be sloppy and just let the disk fill up. But there comes a time where that is no longer an option.

You can ask the system using the linux-mcp-server to analyze your disk usage, give you a hitlist of the top space-eating places on the file system, and give you advice with a risk analysis of how to clean it up.

Here's my prompt:

I need help analyzing disk usage on my system. Can you:

1. Show me the current disk usage across all filesystems using get_disk_usage
2. Use list_directories_by_size to show me the 10 largest directories (this will help identify where disk space is being consumed)
3. Check if there are any large log files consuming space using get_journal_logs or read_log_file
4. Review running processes with list_processes to see if any are consuming excessive resources or creating temporary files

After gathering this information, help me identify potential space-saving opportunities and assess the safety of cleaning up specific directories. Please don't only examine top-level directories. I want you to go deep if needed to find out where the largest files are!

I ran this prompt on my Fedora 42 system using linux-mcp-server with Goose connected to locally-served gpt-oss:20b, and here's the output I got:

Disk‑space overview (as of Nov 24 2025 15:21)

Overall usage is comfortably below 60 % of a 952 GB volume, so immediate capacity pressure isn't a concern. The biggest contributors to disk space today are in the ~/. hierarchy.

1. Biggest directories on the system

| ~/duffy/.local/share | 238 GB | Containers sub-dir, followed by Trash (7GB) - typical podman/docker container images |
| ~/duffy/.local/share/containers | 238 GB | Container layers, images, root filesystems - the prime candidate for cleanup |
| ~/duffy/.local | 266 GB | share (237 GB) dominates it |
| ~/duffy/.local/share/containers (inside share) | 238 GB | Same as above - just a different view |
| ~/duffy/.local/lib | 13 GB | Likely a virtual‑environment library set |
| ~/duffy/.local/bin | 4 GB | Helper binaries |
| ~/duffy/.local/share/Trash | 7 GB | User‑deleted items still resident on disk |
| ~/duffy/.local/share/containers (nested) | 238 GB | Same as above; redundant listings from recursive depth‑1 scans |
| ~/duffy/.local/share (top‑level) | 238 GB | containers is the absolute largest item |

Take‑away - 75 % of the 238 GB live inside three nested directories:

• ~/duffy/.local/share/containers (238 GB) → Rooted in Podman/Container‑Store
• ~/duffy/.local/share (238 GB) → Same data exposed at a higher level
• ~/duffy/.local/share/Trash (7 GB)

2. Possible space savers

3. Disk‑IO perspective

• Reads: 111.8 GB; Writes: 85.6 GB since boot (≈ 1.2 TB total).
• If writes are high relative to free space, consider enabling a tmpfs overlay for temporary files or moving large data to a separate, faster SSD. But in this case, writes are not approaching the 399 GB free.

4. Suggested cleanup workflow

# 1. Empty Trash

gio trash --empty

# 2. Prune unused containers/images

podman system prune -a   # or docker system prune -a

# 3. Remove leftover caches

pnpm store prune         # if pnpm is installed

pip cache purge          # for Python

virtualenv --clean       # optional

# 4. Inspect large "RAM" directories manually if you need deeper cleanup

du -h --max-depth=1 ~/duffy/.local/share/containers

Tip: After each step run df -h /home or du -sh ~/duffy/.local/* to see the impact.

5. Safety checklist

Bottom line

• Current free space: ≈ 400 GB on both / and /home.
• Largest consumptions: User‑space under ~/duffy/.local/share/containers (≈ 238 GB).
• Actionable clean‑ups: Empty Trash, prune unused container images, and review large libraries/binaries. This should reclaim over 200 GB and bring the usage from 57.9 % down to roughly 40‑45 % - plenty of headroom for the future.

Feel free to ask what next steps you'd like to dig into (e.g., detailed contents of the containers dir, specific application logs, or targeted pruning commands).

Upgrade planning

So you may have noticed a little detail above - the system is a Fedora 42 system… and Fedora 43's been out a month now! So, time to upgrade.

This example shows where we have some tools missing from the set provided in the linux-mcp-server. We're including it for two reasons:

• So you can see how this works manually
  You can see that even when specific tools you might not need are available in the MCP server, you can have the response give you instructions on commands to run on your own, and copy/paste the command output back into your chat to get analysis alongside the data the system is able to pull via the MCP tool calls;
• To encourage you to submit additional tools to our project!
  We would love your additions to the project! Here's where to get started: https://github.com/rhel-lightspeed/linux-mcp-server/blob/main/docs/CONTRIBUTING.md

Here's the prompt I started with, with the same Goose + gpt-oss:20b + linux-mcp-server combination:

You are a Linux system administrator assistant analyzing a Fedora system for upgrade readiness.

TASK: Examine this Fedora 42 system and provide a comprehensive upgrade readiness report for Fedora 43.

ANALYSIS CHECKLIST:
1. Check current Fedora version: cat /etc/fedora-release
2. Review system updates status: dnf check-update
3. Identify third-party repositories: dnf repolist
4. List installed packages from non-Fedora repos: dnf list installed | grep -v @fedora
5. Check for broken dependencies: dnf check
6. Review disk space on root partition: df -h /
7. Check for unsupported or deprecated packages
8. Identify custom kernel modules: lsmod | grep -v "^Module"
9. Review SELinux status: sestatus
10. Check for pending system updates: dnf upgrade --refresh --assumeno

REPORT FORMAT:

# Fedora 43 Upgrade Readiness Report

## Current System Status
- Fedora version: [version]
- Kernel: [kernel version]
- Updates status: [current/outdated]

## Potential Issues
[List blocking issues with HIGH/MEDIUM/LOW severity]

## Third-Party Software
[List non-Fedora packages that may need attention]

## Recommendations
[Specific pre-upgrade steps needed]

## Overall Readiness: [READY/NEEDS ATTENTION/NOT READY]
Run the necessary commands and provide this analysis. Be specific about any issues found and give actionable recommendations.

Now, right away the model came back to me to complain it doesn't have access to `dnf`, `cat`, etc. And that's expected here. What it did was give me a list of homework to run for it to complete the analysis… for example, `dnf check-update` and `cat /etc/fedora-release`. I had a little back and forth in Goose with the model where it would ask me to run a command and I'd copy the output into the context. This resulted, finally, in the following report:

Fedora 43 Upgrade Readiness Report

Analyzed System - Fedora 42 (Kernel 6.17.7‑200.fc42.x86_64)
Date - 2025‑11‑24

1. Current System Status

TL;DR - The base system is clean; the kernel is up‑to‑date for 42, there is ample disk space, and there are no version‑locked packages.

2. Third‑Party Repos & Packages

What we need to verify

1. Is a Fedora 43 build available for each of the non‑Fedora repos above?
2. Does google-cloud-cli have a Fedora 43‑compatible package? (EL 10 build may not be usable).
3. Are there any el10‑specific dependencies that could surface during the upgrade?
4. Any custom kernel modules that will require re‑compilation against the 43 kernel.

3. Potential Issues & Severity

Current High‑Risk Items - None detected yet.
Next Action - Confirm each third‑party repo has 43‑compatible packages and set SELinux to enforcing.

4. Recommendations (Pre‑Upgrade Checklist)

5. Post‑Upgrade Actions

1. Reboot into the new kernel (dnf system-upgrade reboot).
2. Re‑compile any custom kernel modules against the new kernel (yum install kernel-devel-$(uname -r) then rebuild modules).
3. Re‑enable any disabled repos once the upgrade completes.
4. Verify critical services (systemctl status <service>) and check logs.
5. Run sudo dnf distro-sync to ensure all packages are the latest from Fedora 43.

6. Overall Readiness

Next step - Run the three verification commands below and share the output with me:

sudo dnf check

sudo dnf repolist

dnf list installed | grep -v @fedora

With those outputs I can pinpoint any remaining blockers and give you a final, ready‑to‑proceed plan.

Happy upgrading!

Give it a try, let us know what you think!

You can see from these few examples that tool calling with LLMs is a valuable tool for troubleshooting Linux systems. We could use your help building this and making it awesome! How can you help?

• Give it a try, let us know what you think, file any bugs you find, and let us know what tools are missing that you could use! You can respond in the comments here, file a bug, or chat with us on Fedora matrix.
• We're primarily working with Goose as our client, but if you have another preferred client and want to help us support it better, we'd love to work with you!
• Get involved in the linux-mcp-project generally, we'd love to see your PRs!
• Let us know what you'd like to see in the future. What workflows would you like to see supported? How do you see this making your Fedora or overall Linux experience better? What larger workflows do you see this plugging into?

Join us upstream at https://github.com/rhel-lightspeed/linux-mcp-server! And come chat with us in the Fedora AI/ML SIG chat room on Matrix!

10 Dec 2025 8:00am GMT

Ubuntu's default desktop is about to look more like upstream GNOME than it has in years - but before you panic unduly, I should stress that it will still look (mostly) the same as it does now. The Yaru theme team - try saying that several times in a row - is undertaking a refactor of their GNOME Shell stylesheet ("theme") ahead of the next long-term support release, Ubuntu 26.04 LTS, which is due out in April and will include GNOME 50. Rather than continuing to maintain a customised stylesheet for GNOME Shell, it will instead use the default theme […]

You're reading Ubuntu 26.04 Will Look More Like Vanilla GNOME Shell, a blog post from OMG! Ubuntu. Do not reproduce elsewhere without permission.

09 Dec 2025 11:57pm GMT

Canonical will package AMD ROCm directly in the Ubuntu 26.04 LTS repos, making it much easier to get GPU-accelerated workloads running on the distro.

You're reading Canonical is Bringing AMD ROCm to Ubuntu 26.04 Repos, a blog post from OMG! Ubuntu. Do not reproduce elsewhere without permission.

09 Dec 2025 10:10pm GMT

09 Dec 2025 3:38pm GMT

WebKitGTK 2.50.3 contains a workaround for CVE-2025-13947, an issue that allows websites to exfiltrate files from your filesystem. If you're using Epiphany or any other web browser based on WebKitGTK, then you should immediately update to 2.50.3.

Websites may attach file URLs to drag sources. When the drag source is dropped onto a drop target, the website can read the file data for its chosen files, without any restrictions. Oops. Suffice to say, this is not how drag and drop is supposed to work. Websites should not be able to choose for themselves which files to read from your filesystem; only the user is supposed to be able to make that choice, by dragging the file from an external application. That is, drag sources created by websites should not receive file access.

I failed to find the correct way to fix this bug in the two afternoons I allowed myself to work on this issue, so instead my overly-broad solution was to disable file access for all drags. With this workaround, the website will only receive the list of file URLs rather than the file contents.

Apple platforms are not affected by this issue.

09 Dec 2025 3:29pm GMT

KDE's 30th birthday is coming up next year. For this year's holiday season I therefore decided to compile a list of 30 reasons why I love KDE Plasma. It makes me so much more productive and work a lot more fun. While some of the items listed below aren't unique to Plasma, it's the combination of all of those things that truly makes it the best desktop environment out there. Tell me, what are your top reasons?

1. When I suspend my laptop, any video or music stops playing
2. I can use three fingers on my touch pad to switch virtual desktops
3. I get a notification when my wireless mouse is about to run out of juice
4. I can middle-click a window on the task bar to close it
5. I can have a sticky note in my panel for use as a scratchpad
6. I can middle-click the notification icon to engage "do not disturb" mode
7. There's a handy little color picker widget for my panel
8. I can throw my cursor into the corner of the screen to peek at my desktop
9. I can keep any window always on top when I need to
10. I can create a QR code of anything I copy to my clipboard
11. When I take a screenshot, I can then just drag it to where I need it
12. I can change the screen brightness by mouse wheeling the brightness icon
13. I can drag a window to the top of the screen to maximize it
14. I can send a window to different virtual desktops by using a global shortcut
15. There's a little live volume meter in each slider in the volume popup
16. I can bring up a little magnifier window around my mouse cursor
17. I can draw red lines on the screen using a desktop effect
18. I can use the back/forward mouse buttons on the task bar to change music tracks
19. When I wiggle the mouse, the cursor gets bigger and bigger, and there's no limit!
20. Night light comforts my eyes in the evening hours
21. KRunner finds browser tabs in the mess of hundreds of tabs I have
22. I can raise the speaker volume above 100% when needed
23. I can wheel a window's title bar to change its opacity to quickly compare stuff
24. I can make the Copilot key on my keyboard actually do something useful
25. I can use window rules to force apps to open exactly how I want
26. I can add custom global shortcuts for almost anything
27. System Monitor displays a tonne of info, including from my solar installation
28. I can speed up playback of pretty much any video from Plasma's Media Controller
29. I can use Meta left click to move and Meta right click to resize a window anytime
30. I can quickly access recent files opened in an app by right clicking its task bar entry

… and that is just Plasma, not even mentioning fantastic apps like the Dolphin file manager, Konsole, Kate editor, and of course KDE Connect. Another way to show your love for KDE is by donating to our Year End Fundraiser and maybe even adopt an app!

09 Dec 2025 8:00am GMT

Open source already includes commercial use by definition. The label "commercial open source" mixes copyright, licenses and business models, creates confusion, and helps disguise non‑open‑source licenses. If you care about the open source commons, avoid the term and always check the facts.

09 Dec 2025 7:00am GMT

Gamepad support, collections, instant imports, and more!

Cartridges is, in my biased opinion, the best game launcher out there. To use it, you do not need to wait 2 minutes for a memory-hungry Electron app to start up before you can start looking for what you want to play. You don't need to sign into anything. You don't need to spend 20 minutes configuring it. You don't need to sacrifice your app menu, filling it with low-resolution icons designed for Windows that don't disappear after you uninstall a game. You install the app, click "Import", and all your games from anywhere on your computer magically appear.

It was also the first app I ever wrote. From this, you can probably already guess that it is an unmaintainable mess. It's both under- and over-engineered, it is full of bad practices, and most importantly, I don't trust it. I've learned a lot since then. I've learned so much that if I were to write the app again, I would approach it completely differently. Since Cartridges is the preferred way to launch games for so many other people as well, I feel it is my duty as a maintainer to give it my best shot and do just that: rewrite the app from scratch.

Myself, Zoey, and Jamie have been working on this for the past two weeks and we've made really good progress so far. Beyond stability improvements, the new base has allowed us to work on the following new features:

Gamepad Support

Support for controller navigation has been something I've attempted in the past but had to give up as it proved too challenging. That's why I was overjoyed when Zoey stepped up to work on it. In the currently open pull request, you can already launch games and navigate many parts of the UI with a controller. You can donate to her on Ko-fi if you would like to support the feature's development. Planned future enhancements include navigating menus, remapping, and button prompts.

Collections

Easily the most requested feature, a lot of people asked for a way to manually organize their games. I initially rejected the idea as I wanted Cartridges to remain a single-click game launcher but softened up to it over time as more and more people requested it since it's an optional dimension that you can just ignore if you don't use it. As such, I'm happy to say that Jamie has been working on categorization with an initial implementation ready for review as of writing this. You can support her on Liberapay or GitHub Sponsors.

Instant Imports

I mentioned that Cartridges' main selling point is being a single-click launcher. This is as good it gets, right? Wrong: how about zero clicks?

The app has been reworked to be even more magical. Instead of pulling data into Cartridges from other apps at the request of the user, it will now read data directly from other apps without the need to keep games in-sync manually. You will still be able to edit the details of any game, but only these edits will be saved, meaning if any information on, let's say Steam gets updated, Cartridges will automatically reflect these changes.

The existing app has settings to import and remove games automatically, but this has been a band-aid solution and it will be nice to finally do this properly, saving you time, storage space, and saving you from conflicts.

To allow for this, I also changed the way the Steam source works to fetch all data from disk instead of making calls to Steam's web API. This was the only source that relied on the network, so all imports should now be instant. Just install the app and all your games from anywhere on your computer appear. How cool is that? :3

And More

We have some ideas for the longer term involving installing games, launching more apps, and viewing more game data. There are no concrete plans for any of these, but it would be nice to turn Cartridges into a less clunky replacement for most of Steam Big Picture.

And of course, we've already made many quality of life improvements and bug fixes. Parts of the interface have been redesigned to work better and look nicer. You can expect many issues to be closed once the rewrite is stable. Speaking of…

Timeline

We would like to have feature-parity with the existing app. The new app will be released under the same name, as if it was just a regular update so no action will be required to get the new features.

We're aiming to release the new version sometime next year, I'm afraid I can't be more precise than that. It could take three more months, it could take 12. We all have our own lives, working on the app as a side project so we'll see how much time we can dedicate to it.

If you would like to keep up with development, you can watch open pull requests on Codeberg targeting the rewrite branch. You can also join the Cartridges Discord server.

Thank you again Jamie and Zoey for your efforts!

09 Dec 2025 12:00am GMT

Tuesday, 9 December 2025. Today KDE releases a bugfix update to KDE Plasma 6, versioned 6.5.4.

Plasma 6.5 was released in October 2025 with many feature refinements and new modules to complete the desktop experience.

This release adds three weeks' worth of new translations and fixes from KDE's contributors. The bugfixes are typically small but important and include:

View full changelog

09 Dec 2025 12:00am GMT

Despite having a stable release model and cadence since December 2003, Linux kernel version numbers seem to baffle and confuse those that run across them, causing numerous groups to mistakenly make versioning statements that are flat out false. So let's go into how this all works in detail.

09 Dec 2025 12:00am GMT

Debian LTS/ELTS

This was my hundred-thirty-seventh month that I did some work for the Debian LTS initiative, started by Raphael Hertzog at Freexian and my eighty-eighth ELTS month. As the LTS- and ELTS-teams have been merged now, there is only one paragraph left for both activities.

During my allocated time I uploaded or worked on:

• [DLA 4381-1] net-snmp security update to fix two CVEs related to denial of service.
• [DLA 4382-1] libsdl2 security update to fix one CVE related to a memory leak and a denial of service.
• [DLA 4380-1] cups-filters security update to fix three CVEs related to out of bounds read or writes or a heap buffer overflow.
• [ELA-1586-1] cups-filters security update to fix three CVEs in Buster and Stretch, related to out of bounds read or writes or a heap buffer overflow.
• [libcupsfilters] upload to unstable to fix two CVEs
• [cups-filters] upload to unstable to fix three CVEs
• [cups] upload to unstable to fix two CVEs
• [rlottie] upload to unstable to finally fix three CVEs
• [rplay] upload to unstable to finally fix one CVE
• [#1121342] trixie-pu bug for libcupsfilters to fix two CVEs in Trixie.
• [#1121391] trixie-pu bug for cups-filter to fix three CVEs in Trixie.
• [#1121392] bookworm-pu bug for cups-filter to fix three CVEs in Bookworm.
• [#112433] trixie-pu bug for rlottie to finally fix three CVEs in Trixie.
• [#112437] bookworm-pu bug for rlottie to finally fix three CVEs in Bookworm.

I also attended the monthly LTS/ELTS meeting and did a week of LTS/ELTS frontdesk duties. I also stumbled upon a bug in python3-paramiko, where the parsing of include statements in the ssh_config does not work. Rather annoying but already fixed in the newest version, that only needs to find its way to my old VM.

Debian Printing

This month I uploaded a new upstream version or a bugfix version of:

• … lprng to unstable.
• … cpdb-backend-cups to unstable.
• … cpdb-libs to unstable.
• … ippsample to unstable.
• … cups-filters to unstable.

I also uploaded cups to Trixie, to fix bug #1109471 related to a configuration problem with the admin panel.

This work is generously funded by Freexian!

Debian Astro

This month I uploaded a new upstream version or a bugfix version of:

• … siril to unstable (sponsored upload).
• … supernovas to unstable (sponsored upload).

Debian IoT

This month I uploaded a new upstream version or a bugfix version of:

• … openzwave-controlpanel to unstable.
• … pywws to unstable.

Debian Mobcom

This month I uploaded a new upstream version or a bugfix version of:

• … osmo-tetra to unstable.
• … libgsm to unstable.
• … osmo-tetra to unstable.

misc

This month I uploaded a new upstream version or a bugfix version of:

• … cpptest to unstable.
• … npd6 to unstable.
• … ptunnel to unstable.
• … ptunnel-ng to unstable.
• … dateutils to unstable.
• … apcupsd to unstable.
• … puppet-modules-cirrax-gitolite to unstable.
• … visam to unstable.
• … apcupsd to unstable.

On my fight against outdated RFPs, I closed 30 of them in November.

I started with about 3500 open RFP bugs. and after working six months on this project, I have closed 183 bugs. Of course new bugs appeared, so the overall number of bugs is only down to about 3360.

Though I view this as a successful project, I also have to admit that it is a bit boring to work on this daily. Therefore I close this diary again and will add the closed RFP bugs to my bug logbook now. I also try to close some of these bugs by really uploading some software, probably one package per month.

FTP master

This month I accepted 236 and rejected 16 packages. The overall number of packages that got accepted was 247.

08 Dec 2025 3:20pm GMT

I started learning Go this year. First, I picked a Perl project I wanted to rewrite, got a good book and ignored AI tools since I thought they would do nothing but interfere with learning. Eventually though, I decided to experiment a bit and ended up finding a few ways to use AI assistants effectively even when learning something new.

Searching more efficiently

The first use case that worked for me was search. Instead of searching on a traditional search engine and then ending up on Stack Overflow, I could get the answer I was looking for directly in an AI side-window in my editor. Of course, that's bad news for Stack Overflow.

I was however skeptical from the beginning since LLMs make mistakes, sometimes they making up function signatures or APIs that don't exist. Therefore I got into the habit of going to the official standard library documentation to double-check suggestions. For example, if the LLM suggests using strings.SplitN, I verify the function signature and behaviour carefully before using it. Basically, "don't trust and do verify."

I stuck to the standard library in my project, but if an LLM recommends third-party dependencies for you, make sure they exist and that Socket doesn't flag them as malicious. Research has found that 5-20% of packages suggested by LLMs don't actually exist, making this a real attack vector (dubbed "slopsquatting").

Autocomplete is too distracting

A step I took early on was to disable AI autocomplete in my editor. When learning a new language, you need to develop muscle memory for the syntax. Also, Go is no Java. There's not that much boilerplate to write in general.

I found it quite distracting to see some almost correct code replace my thinking about the next step. I can see how one could go faster with these suggestions, but being a developer is not just about cranking out lines of code as fast as possible, it's also about constantly learning new things (and retaining them).

Asking about idiomatic code

One of the most useful prompts when learning a new language is "Is this the most idiomatic way to do this in Go?". Large language models are good at recognizing patterns and can point out when you're writing code that works but doesn't follow the conventions of the language. This is especially valuable early on when you don't yet have a feel for what "good" code looks like in that language.

It's usually pretty easy (at least for an experience developer) to tell when the LLM suggestion is actually counter productive or wrong. If it increases complexity or is harder to read/decode, it's probably not a good idea to do it.

Reviews

One way a new dev gets better is through code review. If you have access to a friend who's an expert in the language you're learning, then you can definitely gain a lot by asking for feedback on your code.

If you don't have access to such a valuable resource, or as a first step before you consult your friend, I found that AI-assisted code reviews can be useful:

1. Get the model to write the review prompt for you. Describe what you want reviewed and let it generate a detailed prompt.
2. Feed that prompt to multiple models. They each have different answers and will detect different problems.
3. Be prepared to ignore 50% of what they recommend. Some suggestions will be stylistic preferences, others will be wrong, or irrelevant.

The value is in the other 50%: the suggestions that make you think about your code differently or catch genuine problems.

Similarly for security reviews:

• A lot of what they flag will need to be ignored (false positives, or things that don't apply to your threat model).
• Some of it may highlight areas for improvement that you hadn't considered.
• Occasionally, they will point out real vulnerabilities.

But always keep in mind that AI chatbots are trained to be people-pleasers and often feel the need to suggest something when nothing was needed

An unexpected benefit

One side effect of using AI assistants was that having them write the scaffolding for unit tests motivated me to increase my code coverage. Trimming unnecessary test cases and adding missing ones is pretty quick when the grunt work is already done, and I ended up testing more of my code (being a personal project written in my own time) than I might have otherwise.

Learning

In the end, I continue to believe in the value of learning from quality books (I find reading paper-based most effective). In addition, I like to create Anki questions for common mistakes or things I find I have to look up often. Remembering something will always be faster than asking an AI tool.

So my experience this year tells me that LLMs can supplement traditional time-tested learning techniques, but I don't believe it obsoletes them.

P.S. I experimented with getting an LLM to ghost-write this post for me from an outline (+ a detailed style guide) and I ended up having to rewrite at least 75% of it. It was largely a waste of time.

08 Dec 2025 12:15am GMT

It's been almost 2 full years since Linux became a CNA (Certificate Numbering Authority) which meant that we (i.e. the kernel.org community) are now responsible for issuing all CVEs for the Linux kernel. During this time, we've become one of the largest creators of CVEs by quantity, going from nothing to number 3 in 2024 to number 1 in 2025. Naturally, this has caused some questions about how we are both doing all of this work, and how people can keep track of it.

08 Dec 2025 12:00am GMT

By now, the /usr-merge is an old transition. Effectively, it turns top-level directories such as /bin into symbolic links pointing below /usr. That way the entire operating system can be contained below the /usr hierarchy enabling e.g. image based update mechanisms. It was first supported in Debian 9, which is no longer in active use at this point (except for users of Freexian's ELTS offer). When it became mandatory in Debian 12, it wasn't really done though, because Debian's package manager was not prepared to handle file system objects being referred to via two different paths. With nobody interested in handling the resulting issues, Freexian stepped in and funded a project lead by Helmut Grohne to resolve the remaining issues.

While the initial idea was to enhance the package manager, Debian's members disagreed. They preferred an approach where files were simply tracked with their physical location while handling the resulting misbehavior of the package manager using package-specific workarounds. This has been recorded in the DEP17 document. During the Debian 13 release cycle, the plan has been implemented. A tool for detecting possible problems was developed specifically for this transition. Since all files are now tracked with their physical location and necessary workarounds have been added, problematic behavior is no longer triggered. An upgrade from Debian 12 to Debian 13 is unlikely to run into aliasing problems as a result.

This whole project probably consumed more than 1500 hours of work from Debian contributors, of which 700 were sponsored by Freexian through the work of Helmut Grohne. What remains is eventually removing the workarounds.

08 Dec 2025 12:00am GMT

Let's be honest. Dealing with broken updates is a nightmare. We've all experienced that moment of panic when you run an update, step away for coffee, and return to a terminal screen full of angry red error messages. That is exactly why uCareSystem exists, and today, it gets even better at preventing these issues.

Fix Broken Updates: uCareSystem New Release

I'm thrilled to announce the latest release of uCareSystem. As the sole developer, I feel the pain of broken updates personally. For this version, I spent a lot of time under the hood, focusing on making sure the tool doesn't just work when everything is perfect, but proactively fixes issues before they break your system.

Here is why you should upgrade to the new version and say goodbye to broken updates for good:

Prevent Broken Updates with Pre-flight Checks

The most frustrating broken updates are the ones that fail because of something that happened last week.

The new uCareSystem introduces automated pre-flight checks. Think of it as a bouncer for your update process. Before it lets any new packages in, it checks the ID of your system to prevent broken updates. It now automatically detects and attempts to fix:

• Those annoying stale dpkg locks that require a reboot.
• Installations that were interrupted (ghosts of updates past).
• Broken dependencies that threaten to ruin your day.

The goal is simple: You press the button, and it actually works.

A UI Upgrade for Better Monitoring

While staring at scrolling walls of monochrome text makes us feel like hackers in a 90s movie, it's not great for spotting errors.

I've given the uCareSystem terminal interface a significant makeover. With improved color coding, better progress indicators, and real-time output logging, you'll now have a much clearer idea of the process, helping you catch potential issues that could lead to broken updates.

Robustness: Avoiding Broken Updates in Containers

Linux runs everywhere now. To keep up, uCareSystem needs to be flexible.

• Containers & WSL: I've improved systemd detection so the tool plays nicely even in environments like Docker containers and Windows Subsystem for Linux (WSL).
• Internet Reality Check: I added better connectivity checks. Trying to download updates without a stable connection is a common cause of broken updates, and we now handle that gracefully.
• Auto-Recovery: If a dpkg process trips and falls midway, the software now has mechanisms to help pick it back up automatically.

Spring Cleaning the Code with ShellCheck

For the code-peepers out there who like to look under the hood: I did some massive spring cleaning. Extensive refactoring and complying with ShellCheck standards mean the codebase is now cleaner and safer. This ensures better maintainability and fewer bugs in the future.

Give the new version a spin. Hopefully, it makes your system maintenance totally boring-and completely free of broken updates.

By the Numbers

This was a significant undertaking, reflected in the statistics for this release:

• 38 files changed:
• 2,030 additions,
• 718 deletions

Please take a look to a comprehensive Release note in the repository: https://github.com/Utappia/uCareSystem/releases/tag/v25.12.04

This release is a testament to my commitment to quality and my vision for the future of uCareSystem as a one-stop system maintenance tool Debian Ubuntu. I am confident that I laid a stronger foundation that will allow for even more exciting features and faster development in the future.

I am deeply grateful to the community members who supported the previous development cycle through donations or code contributions:

• P. Laoughman (Thanks for your continued support)
• W. Schreinemachers (Thanks for your continued support)
• D. Luchini (Thanks for your continued support)
• M. Van Hoof
• Frankie P.
• M. Ryser
• Th. Ploumis
• M. Stade
• K. J. Rasmussen

Every version, has also a code name dedicated as a release honored to one of the contributors. For historical reference, you can check all previous honored releases.

Where can I download uCareSystem ?

As always, I want to express my gratitude for your support over the past 15 years. I have received countless messages from inside and outside Greece about how useful they found the application. I hope you find the new version useful as well.

If you've found uCareSystem to be valuable and it has saved you time, consider showing your appreciation with a donation. You can contribute via PayPal or Debit/Credit Card by clicking on the banner.

Pay what you want	Maybe next time
Click the donate button and enter the amount you want to donate. Then you will be navigated to the page with the latest version to download the installer	If you don't want to Donate this time, just click the download icon to be navigated to the page with the latest version to download the installer

Once installed, the updates for new versions will be installed along with your regular system updates.

The post Fix Broken Updates: uCareSystem New Release uCareSystem v25.12 appeared first on Utappia.

06 Dec 2025 3:59pm GMT

Some years ago I had mentioned some command line tools I used to analyze and find useful information on GStreamer logs. I've been using them consistently along all these years, but some weeks ago I thought about unifying them in a single tool that could provide more flexibility in the mid term, and also as an excuse to unrust my Rust knowledge a bit. That's how I wrote Meow, a tool to make cat speak (that is, to provide meaningful information).

The idea is that you can cat a file through meow and apply the filters, like this:

cat /tmp/log.txt | meow appsinknewsample n:V0 n:video ht: \
ft:-0:00:21.466607596 's:#([A-za-z][A-Za-z]*/)*#'

which means "select those lines that contain appsinknewsample (with case insensitive matching), but don't contain V0 nor video (that is, by exclusion, only that contain audio, probably because we've analyzed both and realized that we should focus on audio for our specific problem), highlight the different thread ids, only show those lines with timestamp lower than 21.46 sec, and change strings like Source/WebCore/platform/graphics/gstreamer/mse/AppendPipeline.cpp to become just AppendPipeline.cpp", to get an output as shown in this terminal screenshot:

Cool, isn't it? After all, I'm convinced that the answer to any GStreamer bug is always hidden in the logs (or will be, as soon as I add "just a couple of log lines more, bro" 0 0

05 Dec 2025 11:16am GMT

InnovatiON 2022

AI Flame Graphs

GPU Flame Scope

Harshad Sane

SREcon APAC

Cloud strategy

Last day

I've resigned from Intel and accepted a new opportunity. If you are an Intel employee, you might have seen my fairly long email that summarized what I did in my 3.5 years. Much of this is public:

• AI flame graphs and released them as open source
• GPU subsecond-offset heatmap
• Worked with Linux distros to enable stack walking
• Was interviewed by the WSJ about eBPF for security monitoring
• Provided leadership on the eBPF Technical Steering Committee (BSC)
• Co-chaired USENIX SREcon APAC 2023
• Gave 6 conference keynotes

It's still early days for AI flame graphs. Right now when I browse CPU performance case studies on the Internet, I'll often see a CPU flame graph as part of the analysis. We're a long way from that kind of adoption for GPUs (and it doesn't help that our open source version is Intel only), but I think as GPU code becomes more complex, with more layers, the need for AI flame graphs will keep increasing.

I also supported cloud computing, participating in 110 customer meetings, and created a company-wide strategy to win back the cloud with 33 specific recommendations, in collaboration with others across 6 organizations. It is some of my best work and features a visual map of interactions between all 19 relevant teams, described by Intel long-timers as the first time they have ever seen such a cross-company map. (This strategy, summarized in a slide deck, is internal only.)

I always wish I did more, in any job, but I'm glad to have contributed this much especially given the context: I overlapped with Intel's toughest 3 years in history, and I had a hiring freeze for my first 15 months.

My fond memories from Intel include meeting Linus at an Intel event who said "everyone is using fleme graphs these days" (Finnish accent), meeting Pat Gelsinger who knew about my work and introduced me to everyone at an exec all hands, surfing lessons at an Intel Australia and HP offsite (mp4), and meeting Harshad Sane (Intel cloud support engineer) who helped me when I was at Netflix and now has joined Netflix himself -- we've swapped ends of the meeting table. I also enjoyed meeting Intel's hardware fellows and senior fellows who were happy to help me understand processor internals. (Unrelated to Intel, but if you're a Who fan like me, I recently met some other people as well!)

My next few years at Intel would have focused on execution of those 33 recommendations, which Intel can continue to do in my absence. Most of my recommendations aren't easy, however, and require accepting change, ELT/CEO approval, and multiple quarters of investment. I won't be there to push them, but other employees can (my CloudTeams strategy is in the inbox of various ELT, and in a shared folder with all my presentations, code, and weekly status reports). This work will hopefully live on and keep making Intel stronger. Good luck.

04 Dec 2025 1:00pm GMT

A common problem with running Gentoo builds is concurrency. Many packages include extensive build steps that are either fully serial, or cannot fully utilize the available CPU threads throughout. This problem becomes less pronounced when running building multiple packages in parallel, but then we are risking overscheduling for packages that do take advantage of parallel builds.

Fortunately, there are a few tools at our disposal that can improve the situation. Most recently, they were joined by two experimental system-wide jobservers: guildmaster and steve. In this post, I'd like to provide the background on them, and discuss the problems they are facing.

The job multiplication problem

You can use the MAKEOPTS variable to specify a number of parallel jobs to run:

MAKEOPTS="-j12"

This is used not only by GNU make, but it is also recognized by a plethora of eclasses and ebuilds, and converted into appropriate options for various builders, test runners and other tools that can benefit from concurrency. So far, that's good news; whenever we can, we're going to run 12 jobs and utilize all the CPU threads.

The problems start when we're running multiple builds in parallel. This could be either due to running emerge --jobs, or simply needing to start another emerge process. The latter happens to me quite often, as I am testing multiple packages simultaneously.

For example, if we end up building four packages simultaneously, and all of them support -j, we may end up spawning 48 jobs. The issue isn't just saturating the CPU; imagine you're running 48 memory-hungry C++ compilers simultaneously!

Load-average scheduling to the rescue

One possible workaround is to use the --load-average option, e.g.:

MAKEOPTS="-j12 -l13"

This causes tools supporting the option not to start new jobs if the current load exceeds 13, which roughly approximates 13 processes running simultaneously. However, the option isn't universally supported, and the exact behavior differs from tool to tool. For example, CTest doesn't start any jobs when the load is exceeded, effectively stopping test execution, whereas GNU make and Ninja throttle themselves down to one job.

Of course, this is a rough approximation. While GNU make attempts to establish the current load from /proc/loadavg, most tools just use the one-minute average from getloadavg(), suffering from some lag. It is entirely possible to end up with interspersed periods of overscheduling while the load is still ramping up, followed by periods of underscheduling before it decreases again. Still, it is better than nothing, and can become especially useful for providing background load for other tasks: a build process that can utilize the idle CPU threads, and back down when other builds need them.

The nested Makefile problem and GNU Make jobserver

Nested Makefiles are processed by calling make recursively, and therefore face a similar problem: if you run multiple make processes in parallel, and they run multiple jobs simultaneously, you end up overscheduling. To avoid this, GNU make introduces a jobserver. It ensures that the specified job number is respected across multiple make invocations.

At the time of writing, GNU make supports three kinds of the jobserver protocol:

1. The legacy Unix pipe-based protocol that relied on passing file descriptors to child processes.
2. The modern Unix protocol using a named pipe.
3. The Windows protocol using a shared semaphore.

All these variants follow roughly the same design principles, and are peer-to-peer protocols for using shared state rather than true servers in the network sense. The jobserver's role is mostly limited to initializing the state and seeding it with an appropriate number of job tokens. Afterwards, clients are responsible for acquiring a token whenever they are about to start a job, and returning it once the job finishes. The availability of job tokens therefore limits the total number of processes started.

The flexibility of modern protocols permitted more tools to support them. Notably, the Ninja build system recently started supporting the protocol, therefore permitting proper parallelism in complex build systems combining Makefiles and Ninja. The jobserver protocol is also supported by Cargo and various Rust tools, GCC and LLVM, where it can be used to limit the number of parallel LTO jobs.

A system-wide jobserver

With a growing number of tools becoming capable of parallel processing, and at the same time gaining support for the GNU make jobserver protocol, it starts being an interesting solution to the overscheduling problem. If we could run one jobserver shared across all build processes, we could control the total number of jobs running simultaneously, and therefore have all the simultaneously running builds dynamically adjust one to another!

In fact, this is not a new idea. A bug requesting jobserver integration has been filed for Portage back in 2019. NixOS jobserver effort dates back at least to 2021, though it has not been merged yet. Guildmaster and steve joined the effort very recently.

There are two primary problems with using a system-wide jobserver: token release reliability, and the "implicit slot" problem.

The token release problem

The first problem is more important. As noted before, the jobserver protocol relies entirely on clients releasing the job tokens they acquired, and the documentation explicitly emphasizes that they must be returned even in error conditions. Unfortunately, this is not always possible: if the client gets killed, it cannot run any cleanup code and therefore return the tokens! For scoped jobservers like GNU make's this usually isn't that much of a problem, since make normally terminates upon a child being killed. However, a system jobserver could easily be left with no job tokens in the queue this way!

This problem cannot really be solved within the strict bounds of the jobserver protocol. After all, it is just a named pipe, and there are limits to how much you can monitor what's happening to the pipe buffer. Fortunately, there is a way around that: you can implement a proper server for the jobserver protocol using FUSE, and provide it in place of the named pipe. Good news is, most of the tools don't actually check the file type, and these that do can easily be patched.

The current draft of NixOS jobserver provides a regular file with special behavior via FUSE, whereas guildmaster and steve both provide a character device via its CUSE API. NixOS jobserver and guildmaster both return unreleased tokens once the process closes the jobserver file, whereas steve returns them once the process acquiring them exits. This way, they can guarantee that a process that either can't release its tokens (e.g. because it's been killed), or one that doesn't because of implementation issue (e.g. Cargo), doesn't end up effectively locking other builds. It also means we can provide live information on which processes are holding the tokens, or even implement additional features such as limiting token provision based on the system load, or setting per-process limits.

The implicit slot problem

The second problem is related to the implicit assumption that a jobserver is inherited from a parent GNU make process that already acquired a token to spawn the subprocess. Since the make subprocess doesn't really do any work itself, it can "use" the token to spawn another job instead. Therefore, every GNU make process running under a jobserver has one implicit slot that runs jobs without consuming any tokens. If the jobserver is running externally and no job tokens were acquired while running the top make process, it ends up running an extra process without a job token: so steve -j12 permits 12 jobs, plus one extra job for every package being built.

Fortunately, the solution is rather simple: one needs to implement token acquisition at Portage level. Portage acquires a new token prior to starting a build job, and releases it once the job finishes. In fact, this solves two problems: it accounts for the implicit slot in builders implementing the jobserver protocol, and it limits the total number of jobs run for parallel builds.

However, this is a double-edged sword. On one hand, it limits the risk of overscheduling when running parallel build jobs. On the other, it means that a new emerge job may not be able to start immediately, but instead wait for other jobs to free up job tokens first, negatively affecting interactivity.

A semi-related issue is that acquiring a single token doesn't properly account for processes that are parallel themselves but do not implement the jobserver protocol, such as pytest-xdist runs. It may be possible to handle these better by acquiring multiple tokens prior to running them (or possibly while running them), but in the former case one needs to be careful to acquire them atomically, and not end up with the equivalent of lock contention: two processes acquiring part of the tokens they require, and waiting forever for more.

The implicit slot problem also causes issues in other clients. For example, nasm-rs writes an extra token to the jobserver pipe to avoid special-casing the implicit slot. However, this violates the protocol and breaks clients with per-process tokens. Steve carries a special workaround for that package.

Summary

A growing number of tools is capable of some degree of concurrency: from builders traditionally being able to start multiple parallel jobs, to multithreaded compilers. While they provide some degree of control over how many jobs to start, avoiding overscheduling while running multiple builds in parallel is non-trivial. Some builders can use load average to partially mitigate the issue, but that's far from a perfect solution.

Jobservers are our best bet right now. Originally designed to handle job scheduling for recursive GNU make invocations, they are being extended to control other parallel processes throughout the build, and can be further extended to control the job numbers across different builds, and even across different build containers.

While NixOS seems to have dropped the ball, Gentoo is now finally actively pursuing global jobserver support. Guildmaster and steve both prove that the server-side implementation is possible, and integration is just around the corner. At this point, it's not clear whether a jobserver-enabled systems are going to become the default in the future, but certainly it's an interesting experiment to carry.

30 Nov 2025 7:34pm GMT

Over the course of 2025, every single major cloud provider has failed. In June, Google Cloud had issues taking down Cloud Storage for many users. In late October, Amazon Web Services had a massive outage in their main hub, us-east-1, affecting many services as well as some people's beds. A little over a week later Microsoft Azure had a [widespread outage][Azure outage] that managed to significantly disrupt train service in the Netherlands, and probably also things that matter. Now last week, Cloudflare takes down large swaths of the internet in a way that causes non-tech people to learn Cloudflare exists. And every single time, people share that one XKCD comic.

24 Nov 2025 12:00am GMT

After Gandi was bought up and started taking extortion level prices for their domains I've been looking for an excuse to migrate registrar. Last week I decided to bite the bullet and move to Porkbun as I have another domain renewal coming up. However after setting up an account and paying for the transfer for 4 domains, I realized their DNS services are provided by Cloudflare! I personally do not use Cloudflare, and stay far away from all of their products for various reasons.

18 Nov 2025 12:00am GMT

The waydroid package prior to version 1.5.4-2 (including aur/waydroid) creates Python byte-code files (.pyc) at runtime which were untracked by pacman. This issue has been fixed in 1.5.4-3, where byte-compiling these files is now done during the packaging process. As a result, the upgrade may conflict with the unowned files created in previous versions. If you encounter errors like the following during the update:

error: failed to commit transaction (conflicting files) waydroid: /usr/lib/waydroid/tools/__pycache__/__init__.cpython-313.pyc exists in filesystem waydroid: /usr/lib/waydroid/tools/actions/__pycache__/__init__.cpython-313.pyc exists in filesystem waydroid: /usr/lib/waydroid/tools/actions/__pycache__/app_manager.cpython-313.pyc exists in filesystem

You can safely overwrite these files by running the following command: pacman -Syu --overwrite /usr/lib/waydroid/tools/\*__pycache__/\*

06 Nov 2025 12:00am GMT

• Release announcement on itch.io

1 0

15 Oct 2025 11:31am GMT

"Gentoo CI" is the service providing periodic linting for the Gentoo repository. It is a part of the Repository mirror and CI project that I've started in 2015. Of course, it all started as a temporary third-party solution, but it persisted, was integrated into Gentoo Infrastructure and grew organically into quite a monstrosity.

It's imperfect in many ways. In particular, it has only some degree of error recovery and when things go wrong beyond that, it requires a manual fix. Often the "fix" is to stop mirroring a problematic repository. Over time, I've started having serious doubts about the project, and proposed sunsetting most of it.

Lately, things have been getting worse. What started as a minor change in behavior of Git triggered a whole cascade of failures, leading to me finally announcing the deadline for sunsetting the mirroring of third-party repositories, and starting ripping non-critical bits out of it. Interesting enough, this whole process led me to finally discover the root cause of most of these failures - a bug that has existed since the very early version of the code, but happened to be hidden by the hacky error recovery code. Here's the story of it.

Repository mirror and CI is basically a bunch of shell scripts with Python helpers run via a cronjob (repo-mirror-ci code). The scripts are responsible for syncing the lot of public Gentoo repositories, generating caches for them, publishing them onto our mirror repositories, and finally running pkgcheck on the Gentoo repository. Most of the "unexpected" error handling is set -e -x, with a dumb logging to a file, and mailing on a cronjob failure. Some common errors are handled gracefully though - sync errors, pkgcheck failures and so on.

The whole cascade started when Git was upgraded on the server. The upgrade involved a change in behavior where git checkout -- ${branch} stopped working; you could only specify files after the --. The fix was trivial enough.

However, once the issue was fixed I've started periodically seeing sync failures from the Gentoo repository. The scripts had a very dumb way of handling sync failures: if syncing failed, they removed the local copy entirely and tried again. This generally made sense - say, if upstream renamed the main branch, git pull would fail but a fresh clone would be a cheap fix. However, the Gentoo repository is quite big and when it gets removed due to sync failure, cloning it afresh from the Gentoo infrastructure failed.

So when it failed, I did a quick hack - I've cloned the repository manually from GitHub, replaced the remote and put it in place. Problem solved. Except a while later, the same issue surfaced. This time I kept an additional local clone, so I wouldn't have to fetch it from server, and added it again. But then, it got removed once more, and this was really getting tedious.

What I have assumed then is that the repository is failing to sync due to some temporary problems, either network or Infrastructure related. If that were the case, it really made no sense to remove it and clone afresh. On top of that, since we are sunsetting support for third-party repositories anyway, there is no need for automatic recovery from issues such as branch name changes. So I removed that logic, to have sync fail immediately, without removing the local copy.

Now, this had important consequences. Previously, any failed sync would result in the repository being removed and cloned again, leaving no trace of the original error. On top of that, a logic stopping the script early when the Gentoo repository failed meant that the actual error wasn't even saved, leaving me only with the subsequent clone failures.

When the sync failed again (and of course it did), I was able to actually investigate what was wrong. What actually happened is that the repository wasn't on a branch - the checkout was detached at some commit. Initially, I assumed this was some fluke, perhaps also related to the Git upgrade. I've switched manually to master, and that fixed it. Then it broke again. And again.

So far I've been mostly dealing with the failures asynchronously - I wasn't around at the time of the initial failure, and only started working on it after a few failed runs. However, finally the issue resurfaced so fast that I was able to connect the dots. The problem likely happened immediately after gentoo-ci hit an issue, and bisected it! So I've started suspecting that there is another issue in the scripts, perhaps another case of missed --, but I couldn't find anything relevant.

Finally, I've started looking at the post-bisect code. What we were doing is calling git rev-parse HEAD prior to bisect, and then using that result in git checkout. This obviously meant that after every bisect, we ended up with detached tree, i.e. precisely the issue I was seeing. So why didn't I notice this before?

Of course, because of the sync error handling. Once bisect broke the repository, next sync failed and the repository got cloned again, and we never noticed anything was wrong. We only started noticing once cloning started failing. So after a few days of confusion and false leads, I finally fixed a bug that was present for over 7 years in production code, and caused the Gentoo repository to be cloned over and over again whenever any bad commit happened.

12 Oct 2025 9:14am GMT

If you are following the gentoo-dev mailing list, you may have noticed that there's been a fair number of patches sent for the Python eclasses recently. Most of them have been centered on pytest support. Long story short, I've came up with what I believed to be a reasonably good design, and decided it's time to stop manually repeating all the good practices in every ebuild separately.

In this post, I am going to shortly summarize all the recently added options. As always, they are all also documented in the Gentoo Python Guide.

The unceasing fight against plugin autoloading

The pytest test loader defaults to automatically loading all the plugins installed to the system. While this is usually quite convenient, especially when you're testing in a virtual environment, it can get quite messy when you're testing against system packages and end up with lots of different plugins installed. The results can range from slowing tests down to completely breaking the test suite.

Our initial attempts to contain the situation were based on maintaining a list of known-bad plugins and explicitly disabling their autoloading. The list of disabled plugins has gotten quite long by now. It includes both plugins that were known to frequently break tests, and these that frequently resulted in automagic dependencies.

While the opt-out approach allowed us to resolve the worst issues, it only worked when we knew about a particular issue. So naturally we'd miss some rarer issue, and learn only when arch testing workflows were failing, or users reported issues. And of course, we would still be loading loads of unnecessary plugins at the cost of performance.

So, we started disabling autoloading entirely, using PYTEST_DISABLE_PLUGIN_AUTOLOAD environment variable. At first we only used it when we needed to, however over time we've started using it almost everywhere - after all, we don't want the test suites to suddenly start failing because of a new pytest plugin installed.

For a long time, I have been hesitant to disable autoloading by default. My main concern was that it's easy to miss a missing plugin. Say, if you ended up failing to load pytest-asyncio or a similar plugin, all the asynchronous tests would simply be skipped (verbosely, but it's still easy to miss among the flood of warnings). However, eventually we started treating this warning as an error (and then pytest started doing the same upstream), and I have decided that going opt-in is worth the risk. After all, we were already disabling it all over the place anyway.

EPYTEST_PLUGINS

Disabling plugin autoloading is only the first part of the solution. Once you disabled autoloading, you need to load the plugins explicitly - it's not sufficient anymore to add them as test dependencies, you also need to add a bunch of -p switches. And then, you need to keep maintaining both dependencies and pytest switches in sync. So you'd end up with bits like:

BDEPEND="
  test? (
    dev-python/flaky[${PYTHON_USEDEP}]
    dev-python/pytest-asyncio[${PYTHON_USEDEP}]
    dev-python/pytest-timeout[${PYTHON_USEDEP}]
  )
"

distutils_enable_tests pytest

python_test() {
  local -x PYTEST_DISABLE_PLUGIN_AUTOLOAD=1
  epytest -p asyncio -p flaky -p timeout
}

Not very efficient, right? The idea then is to replace all that with a single EPYTEST_PLUGINS variable:

EPYTEST_PLUGINS=( flaky pytest-{asyncio,timeout} )
distutils_enable_tests pytest

And that's it! EPYTEST_PLUGINS takes a bunch of Gentoo package names (without category - almost all of them reside in dev-python/, and we can special-case the few that do not), distutils_enable_tests adds the dependencies and epytest (in the default python_test() implementation) disables autoloading and passes the necessary flags.

Now, what's really cool is that the function will automatically determine the correct argument values! This can be especially important if entry point names change between package versions - and upstreams generally don't consider this an issue, since autoloading isn't affected.

Going towards no autoloading by default

Okay, that gives us a nice way of specifying which plugins to load. However, weren't we talking of disabling autoloading by default?

Well, yes - and the intent is that it's going to be disabled by default in EAPI 9. However, until then there's a simple solution we encourage everyone to use: set an empty EPYTEST_PLUGINS. So:

EPYTEST_PLUGINS=()
distutils_enable_tests pytest

…and that's it. When it's set to an empty list, autoloading is disabled. When it's unset, it is enabled for backwards compatibility. And the next pkgcheck release is going to suggest it:

dev-python/a2wsgi
  EPyTestPluginsSuggestion: version 1.10.10: EPYTEST_PLUGINS can be used to control pytest plugins loaded

EPYTEST_PLUGIN* to deal with special cases

While the basic feature is neat, it is not a golden bullet. The approach used is insufficient for some packages, most notably pytest plugins that run a pytest subprocesses without appropriate -p options, and expect plugins to be autoloaded there. However, after some more fiddling we arrived at three helpful features:

1. EPYTEST_PLUGIN_LOAD_VIA_ENV that switches explicit plugin loading from -p arguments to PYTEST_PLUGINS environment variable. This greatly increases the chance that subprocesses will load the specified plugins as well, though it is more likely to cause issues such as plugins being loaded twice (and therefore is not the default). And as a nicety, the eclass takes care of finding out the correct values, again.
2. EPYTEST_PLUGIN_AUTOLOAD to reenable autoloading, effectively making EPYTEST_PLUGINS responsible only for adding dependencies. It's really intended to be used as a last resort, and mostly for future EAPIs when autoloading will be disabled by default.
3. Additionally, EPYTEST_PLUGINS can accept the name of the package itself (i.e. ${PN}) - in which case it will not add a dependency, but load the just-built plugin.

How useful is that? Compare:

BDEPEND="
  test? (
    dev-python/pytest-datadir[${PYTHON_USEDEP}]
  )
"

distutils_enable_tests pytest

python_test() {
  local -x PYTEST_DISABLE_PLUGIN_AUTOLOAD=1
  local -x PYTEST_PLUGINS=pytest_datadir.plugin,pytest_regressions.plugin
  epytest
}

…and:

EPYTEST_PLUGINS=( "${PN}" pytest-datadir )
EPYTEST_PLUGIN_LOAD_VIA_ENV=1
distutils_enable_tests pytest

Old and new bits: common plugins

The eclass already had some bits related to enabling common plugins. Given that EPYTEST_PLUGINS only takes care of loading plugins, but not passing specific arguments to them, they are still meaningful. Furthermore, we've added EPYTEST_RERUNS.

The current list is:

1. EPYTEST_RERUNS=... that takes a number of reruns and uses pytest-rerunfailures to retry failing tests the specified number of times.
2. EPYTEST_TIMEOUT=... that takes a number of seconds and uses pytest-timeout to force a timeout if a single test does not complete within the specified time.
3. EPYTEST_XDIST=1 that enables parallel testing using pytest-xdist, if the user allows multiple test jobs. The number of test jobs can be controlled (by the user) by setting EPYTEST_JOBS with a fallback to inferring from MAKEOPTS (setting to 1 disables the plugin entirely).

The variables automatically add the needed plugin, so they do not need to be repeated in EPYTEST_PLUGINS.

JUnit XML output and gpy-junit2deselect

As an extra treat, we ask pytest to generate a JUnit-style XML output for each test run that can be used for machine processing of test results. gpyutils now supply a gpy-junit2deselect tool that can parse this XML and output a handy EPYTEST_DESELECT for the failing tests:

$ gpy-junit2deselect /tmp/portage/dev-python/aiohttp-3.12.14/temp/pytest-xml/python3.13-QFr.xml
EPYTEST_DESELECT=(
  tests/test_connector.py::test_tcp_connector_ssl_shutdown_timeout_nonzero_passed
  tests/test_connector.py::test_tcp_connector_ssl_shutdown_timeout_passed_to_create_connection
  tests/test_connector.py::test_tcp_connector_ssl_shutdown_timeout_zero_not_passed
)

While it doesn't replace due diligence, it can help you update long lists of deselects. As a bonus, it automatically collapses deselects to test functions, classes and files when all matching tests fail.

hypothesis-gentoo to deal with health check nightmare

Hypothesis is a popular Python fuzz testing library. Unfortunately, it has one feature that, while useful upstream, is pretty annoying to downstream testers: health checks.

The idea behind health checks is to make sure that fuzz testing remains efficient. For example, Hypothesis is going to fail if the routine used to generate examples is too slow. And as you can guess, "too slow" is more likely to happen on a busy Gentoo system than on dedicated upstream CI. Not to mention some upstreams plain ignore health check failures if they happen rarely.

Given how often this broke for us, we have requested an option to disable Hypothesis health checks long ago. Unfortunately, upstream's answer can be summarized as: "it's up to packages using Hypothesis to provide such an option, and you should not be running fuzz testing downstream anyway". Easy to say.

Well, obviously we are not going to pursue every single package using Hypothesis to add a profile with health checks disabled. We did report health check failures sometimes, and sometimes got no response at all. And skipping these tests is not really an option, given that often there are no other tests for a given function, and even if there are - it's just going to be a maintenance nightmare.

I've finally figured out that we can create a Hypothesis plugin - now hypothesis-gentoo - that provides a dedicated "gentoo" profile with all health checks disabled, and then we can simply use this profile in epytest. And how do we know that Hypothesis is used? Of course we look at EPYTEST_PLUGINS! All pieces fall into place. It's not 100% foolproof, but health check problems aren't that common either.

Summary

I have to say that I really like what we achieved here. Over the years, we learned a lot about pytest, and used that knowledge to improve testing in Gentoo. And after repeating the same patterns for years, we have finally replaced them with eclass functions that can largely work out of the box. This is a major step forward.

26 Jul 2025 1:29pm GMT

This blog has been running more or less continuously since mid-nineties. The site has existed in multiple forms, and with different ways to publish. But what's common is that at almost all points there was a mechanism to publish while on the move.

Psion, documents over FTP

In the early 2000s we were into adventure motorcycling. To be able to share our adventures, we implemented a way to publish blogs while on the go. The device that enabled this was the Psion Series 5, a handheld computer that was very much a device ahead of its time.

The Psion had a reasonably sized keyboard and a good native word processing app. And battery life good for weeks of usage. Writing while underway was easy. The Psion could use a mobile phone as a modem over an infrared connection, and with that we could upload the documents to a server over FTP.

Server-side, a cron job would grab the new documents, converting them to HTML and adding them to our CMS.

In the early days of GPRS, getting this to work while roaming was quite tricky. But the system served us well for years.

If we wanted to include photos to the stories, we'd have to find an Internet cafe.

• To the Alps is a post from these times. Lots more in the motorcycling category

SMS and MMS

For an even more mobile setup, I implemented an SMS-based blogging system. We had an old phone connected to a computer back in the office, and I could write to my blog by simply sending a text. These would automatically end up as a new paragraph in the latest post. If I started the text with NEWPOST, an empty blog post would be created with the rest of that message's text as the title.

• In the Caucasus is a good example of a post from this era

As I got into neogeography, I could also send a NEWPOSITION message. This would update my position on the map, connecting weather metadata to the posts.

As camera phones became available, we wanted to do pictures too. For the Death Monkey rally where we rode minimotorcycles from Helsinki to Gibraltar, we implemented an MMS-based system. With that the entries could include both text and pictures. But for that you needed a gateway, which was really only realistic for an event with sponsors.

• Mystery of the Missing Monkey is typical. Some more in Internet Archive

Photos over email

A much easier setup than MMS was to slightly come back to the old Psion setup, but instead of word documents, sending email with picture attachments. This was something that the new breed of (pre-iPhone) smartphones were capable of. And by now the roaming question was mostly sorted.

And so my blog included a new "moblog" section. This is where I could share my daily activities as poor-quality pictures. Sort of how people would use Instagram a few years later.

• Internet Archive has some of my old moblogs but nowadays, I post similar stuff on Pixelfed

Pause

Then there was sort of a long pause in mobile blogging advancements. Modern smartphones, data roaming, and WiFi hotspots had become ubiquitous.

In the meanwhile the blog also got migrated to a Jekyll-based system hosted on AWS. That means the old Midgard-based integrations were off the table.

And I traveled off-the-grid rarely enough that it didn't make sense to develop a system.

But now that we're sailing offshore, that has changed. Time for new systems and new ideas. Or maybe just a rehash of the old ones?

Starlink, Internet from Outer Space

Most cruising boats - ours included - now run the Starlink satellite broadband system. This enables full Internet, even in the middle of an ocean, even video calls! With this, we can use normal blogging tools. The usual one for us is GitJournal, which makes it easy to write Jekyll-style Markdown posts and push them to GitHub.

However, Starlink is a complicated, energy-hungry, and fragile system on an offshore boat. The policies might change at any time preventing our way of using it, and also the dishy itself, or the way we power it may fail.

But despite what you'd think, even on a nerdy boat like ours, loss of Internet connectivity is not an emergency. And this is where the old-style mobile blogging mechanisms come handy.

• Any of the 2025 Atlantic crossing posts is a good example of this setup in action

Inreach, texting with the cloud

Our backup system to Starlink is the Garmin Inreach. This is a tiny battery-powered device that connects to the Iridium satellite constellation. It allows tracking as well as basic text messaging.

When we head offshore we always enable tracking on the Inreach. This allows both our blog and our friends ashore to follow our progress.

I also made a simple integration where text updates sent to Garmin MapShare get fetched and published on our blog. Right now this is just plain text-based entries, but one could easily implement a command system similar to what I had over SMS back in the day.

One benefit of the Inreach is that we can also take it with us when we go on land adventures. And it'd even enable rudimentary communications if we found ourselves in a liferaft.

• There are various InReach integration hacks that could be used for more sophisticated data transfer

Sailmail and email over HF radio

The other potential backup for Starlink failures would be to go seriously old-school. It is possible to get email access via a SSB radio and a Pactor (or Vara) modem.

Our boat is already equipped with an isolated aft stay that can be used as an antenna. And with the popularity of Starlink, many cruisers are offloading their old HF radios.

Licensing-wise this system could be used either as a marine HF radio (requiring a Long Range Certificate), or amateur radio. So that part is something I need to work on. Thankfully post-COVID, radio amateur license exams can be done online.

With this setup we could send and receive text-based email. The Airmail application used for this can even do some automatic templating for position reports. We'd then need a mailbox that can receive these mails, and some automation to fetch and publish.

• Sailmail and No Foreign Land support structured data via email to update position. Their formats could be useful inspiration

0 0

05 Jun 2025 12:00am GMT

I've mentioned some of my various retronetworking projects in some past blog posts. One of those projects is Osmocom Community TDM over IP (OCTOI). During the past 5 or so months, we have been using a number of GPS-synchronized open source icE1usb interconnected by a new, efficient but strill transparent TDMoIP protocol in order to run a distributed TDM/PDH network. This network is currently only used to provide ISDN services to retronetworking enthusiasts, but other uses like frame relay have also been validated.

So far, the central hub of this OCTOI network has been operating in the basement of my home, behind a consumer-grade DOCSIS cable modem connection. Given that TDMoIP is relatively sensitive to packet loss, this has been sub-optimal.

Luckily some of my old friends at noris.net have agreed to host a new OCTOI hub free of charge in one of their ultra-reliable co-location data centres. I'm already hosting some other machines there for 20+ years, and noris.net is a good fit given that they were - in their early days as an ISP - the driving force in the early 90s behind one of the Linux kernel ISDN stracks called u-isdn. So after many decades, ISDN returns to them in a very different way.

Side note: In case you're curious, a reconstructed partial release history of the u-isdn code can be found on gitea.osmocom.org

But I digress. So today, there was the installation of this new OCTOI hub setup. It has been prepared for several weeks in advance, and the hub contains two circuit boards designed entirely only for this use case. The most difficult challenge was the fact that this data centre has no existing GPS RF distribution, and the roof is ~ 100m of CAT5 cable (no fiber!) away from the roof. So we faced the challenge of passing the 1PPS (1 pulse per second) signal reliably through several steps of lightning/over-voltage protection into the icE1usb whose internal GPS-DO serves as a grandmaster clock for the TDM network.

The equipment deployed in this installation currently contains:

• a rather beefy Supermicro 2U server with EPYC 7113P CPU and 4x PCIe, two of which are populated with Digium TE820 cards resulting in a total of 16 E1 ports

• an icE1usb with RS422 interface board connected via 100m RS422 to an Ericsson GPS03 receiver. There's two layers of of over-voltage protection on the RS422 (each with gas discharge tubes and TVS) and two stages of over-voltage protection in the coaxial cable between antenna and GPS receiver.

• a Livingston Portmaster3 RAS server

• a Cisco AS5400 RAS server

For more details, see this wiki page and this ticket

Now that the physical deployment has been made, the next steps will be to migrate all the TDMoIP links from the existing user base over to the new hub. We hope the reliability and performance will be much better than behind DOCSIS.

In any case, this new setup for sure has a lot of capacity to connect many more more users to this network. At this point we can still only offer E1 PRI interfaces. I expect that at some point during the coming winter the project for remote TDMoIP BRI (S/T, S0-Bus) connectivity will become available.

18 Sep 2022 10:00pm GMT

Almost one year after my post regarding first steps towards a V5 implementation, some friends and I were finally able to visit Wobcom, a small German city carrier and pick up a lot of decommissioned POTS/ISDN/PDH/SDH equipment, primarily V5 access networks.

This means that a number of retronetworking enthusiasts now have a chance to play with Siemens Fastlink, Nokia EKSOS and DeTeWe ALIAN access networks/multiplexers.

My primary interest is in Nokia EKSOS, which looks like an rather easy, low-complexity target. As one of the first steps, I took PCB photographs of the various modules/cards in the shelf, take note of the main chip designations and started to search for the related data sheets.

The results can be found in the Osmocom retronetworking wiki, with https://osmocom.org/projects/retronetworking/wiki/Nokia_EKSOS being the main entry page, and sub-pages about

• Node Control Unit

• 16x BRI Uk0 Line Card

• 32x POTS Line Card

• Line Measurement Unit

• Shelf

In short: Unsurprisingly, a lot of Infineon analog and digital ICs for the POTS and ISDN ports, as well as a number of Motorola M68k based QUICC32 microprocessors and several unknown ASICs.

So with V5 hardware at my disposal, I've slowly re-started my efforts to implement the LE (local exchange) side of the V5 protocol stack, with the goal of eventually being able to interface those V5 AN with the Osmocom Community TDM over IP network. Once that is in place, we should also be able to offer real ISDN Uk0 (BRI) and POTS lines at retrocomputing events or hacker camps in the coming years.

08 Sep 2022 10:00pm GMT

If you have ever worked with Digium (now part of Sangoma) digital telephony interface cards such as the TE110/410/420/820 (single to octal E1/T1/J1 PRI cards), you will probably have seen that they always have a timing connector, where the timing information can be passed from one card to another.

In PDH/ISDN (or even SDH) networks, it is very important to have a synchronized clock across the network. If the clocks are drifting, there will be underruns or overruns, with associated phase jumps that are particularly dangerous when analog modem calls are transported.

In traditional ISDN use cases, the clock is always provided by the network operator, and any customer/user side equipment is expected to synchronize to that clock.

So this Digium timing cable is needed in applications where you have more PRI lines than possible with one card, but only a subset of your lines (spans) are connected to the public operator. The timing cable should make sure that the clock received on one port from the public operator should be used as transmit bit-clock on all of the other ports, no matter on which card.

Unfortunately this decades-old Digium timing cable approach seems to suffer from some problems.

08 Sep 2022 10:00pm GMT