9 posts tagged with "Linux"

When I watch teams evaluate open source projects, I notice most of them check two things: the license, and whether the project looks active. Commits in the last month, responsive maintainers, a reasonable release cadence, stars and contributors trending the right way. Both of those signals matter - a project without an OSI-approved license carries a different risk profile than one that has one, and a project that hasn't been committed to in a year is probably not a safe bet.

But those two signals, even taken together, don't tell you much about who actually controls the project, who gets to decide its direction, or what happens if the company behind it changes its mind. That's governance, and it's the signal most evaluations skip - not because people don't care, but because it's harder to check than licensing or commit activity, and nobody has really taught them where to look.

This post focuses on the CNCF and friends - the CNCF specifically, the Linux Foundation umbrellas nearby (LF Edge, NeoNephos), and a couple of LF projects that share governance DNA. That's the neighborhood I'm invested in at the moment. There are plenty of good governance stories in other foundations and in projects outside any foundation at all, but a full tour would make this post much longer than I want it to be. The questions I end up with transfer; apply them wherever you're evaluating.

What governance actually is, and why it matters now more than ever​

Governance is the set of rules determining who makes decisions about a project. Who merges code. Who decides the roadmap. What happens if maintainers disagree, or if the company behind the project is acquired or changes direction. These procedural questions are what determine whether software you depend on will still be serving you in five years.

Distributed governance - multi-vendor, auditable, with decisions made in public - has real benefits. The project outlives any one company's interest. Decisions get made by people with different perspectives, which generally produces better technical outcomes. You get a legible, predictable path for raising issues and having them addressed. And you get something harder to name: the quiet confidence that you're not betting your platform on one CEO's roadmap.

Concentrated governance - typically single-vendor, often implicit, usually fine right now - has its own benefits. Decisions are faster. Direction is clearer. There's no committee. A small team that knows what it's doing can move a project forward quickly, and plenty of excellent software has been built this way. The trade-off is that you're betting on that team's continued interest, alignment, and financial health. When those align with your own interests, it's a great bet. When they don't, you have limited recourse.

Neither are right or wrong. They are just different models that have different pros and cons in this context.

What has changed recently is that the volume of code available is about to increase dramatically. AI-assisted development is going to produce a lot more code - and a lot of that code will be published as open source by individuals or small groups who haven't put any governance structure in place, because there hasn't been time to. At the same time, existing open source projects are going to see more contributions flowing in than their maintainers can realistically review. In both cases, governance is the thing that helps. For new projects, governance is what distinguishes "published as open source" from "maintained as open source." For existing projects, the right governance structures are how you absorb a surge of contributions without losing the quality bar.

That shift is what makes governance checking more load-bearing now than it was a few years ago. "It's open source" used to carry an implicit governance signal - if something was open source, there was probably a person accountable to a community somewhere. As the total pool of open source code grows faster than the pool of accountable maintainers, that implicit signal weakens. Foundations are one of the more reliable ways to tell the difference between "open source with real stewardship" and "open source with whoever is around."

That's the context this post is set in.

I want to introduce kairos-lab, a small CLI built to remove friction from first-time Kairos experiments on macOS and Linux.

I've been working on ARM images lately. They are not application containers, but a distro-style image built from ubuntu:22.04 that installs large package sets, runs post-install scripts, enables services, and pulls NVIDIA repositories. It's much closer to OS assembly than a typical app container.

I wasn't surprised that building these images natively on ARM would be faster than doing it from an x86 machine using emulation. That part was expected.

What surprised me was how much faster it was.

Seeing a Raspberry Pi 5 consistently outperform a 3-year-old high-end Intel laptop by almost 2x forced me to re-evaluate some assumptions I had about build performance, hardware specs, and what "powerful enough" actually means when you're building ARM software.

Ten years ago I gave my first talk at FOSDEM. Back then I was pushing for better tooling to inspect systems, to avoid configuration drift, and for universal system descriptions (USD) — a way to consistently define Linux systems (see this talk).

When it comes to keeping your headless server synchronized with your Nextcloud server, setting up a reliable automated process is crucial. This guide will walk you through syncing top-level directories on an Ubuntu server. While this explanation uses Ubuntu, be aware that some commands, such as package installation, may vary on other Linux distributions.

When the Raspberry Pi5 is turned on, it will check on which device it is configured to boot. By default, this is the SD card, but you can change it to boot from an NVMe or USB drive while still fallback to SD. In my case, I’m using a USB SSD. Let’s take a look at how the disk is partitioned.

Linux has become the default operating system for running web applications. However, like any system connected to the internet, it is exposed to remote attacks. While public cloud environments and private datacenters offer some security from physical tampering, edge computing presents unique challenges.

Running the MNT Reform 2 from an SD card is not a bad solution. It's similar to the way a Raspberry Pi is run. However, I wanted to free the SD card slot. In this post I describe the whole process from picking and buying an NVMe SSD, to installing and configuring it.

This article will teach you how to run one or more Redis instances on a Linux server using systemd to spawn copies of a service.