Open Source Software

What Is Linux? An Honest Guide to the Open Source Operating System

Thirty five years ago today, a 21 year old student in Helsinki posted a message to a Usenet newsgroup used by people running a small teaching operating system called Minix. He said he was writing a free operating system. He called it just a hobby and said it would not be big and professional. That last part has aged badly.

The software that grew out of that post now runs every one of the five hundred fastest supercomputers in the world. It sits underneath Android, which is the most widely used mobile operating system there is. It holds up an enormous share of the internet’s servers and almost all of the public cloud. It also runs on roughly four out of every hundred desktop computers, which is the figure people reach for when they want to argue that Linux lost.

Both things are true at once. The distance between them is the most interesting thing about Linux, and most explanations skip straight past it. This guide does not. It covers where Linux came from, what you are actually getting when someone hands you a copy, who pays for the work, what the licence obliges, how the security story really goes, and the specific situations where choosing Linux would be a mistake.

It is long. The links below will take you to whichever part you came for.

The short answer

Linux is a free, open source operating system kernel, first released by Linus Torvalds in 1991 and licensed under the GNU General Public License version 2. Around that kernel, thousands of separate projects supply everything else an operating system needs. A distribution is somebody’s opinionated assembly of the kernel plus that surrounding software into a thing you can install.

You can download any of it, read every line, change whatever you want, run it on as many machines as you like, and give your modified version to other people. Nobody can take that away or start charging you rent for software you already have. There is no licence key, no seat count and no audit clause.

What you are not getting is a single product with a single owner. Linux is a loose federation of projects with different funding, different priorities and occasionally open hostility toward each other. That federation is the reason Linux is so hard to kill and also the reason the desktop experience is uneven. Both effects come from the same cause.

Where Linux came from

Linux did not appear out of nowhere. By 1991 the Free Software Foundation had spent eight years building the GNU system, a Unix compatible operating system meant to be free of proprietary code. Richard Stallman had started the project in 1983. GNU had a compiler, a shell, an editor, a debugger and a large collection of the utilities a Unix system needs. What it did not have was a finished kernel, which is the part that talks to the hardware and decides which program gets the processor next.

Meanwhile Andrew Tanenbaum had written Minix, a small Unix like system for teaching. It came with source code you could read, which was unusual and valuable. Its licence did not let you do much with it, and its author had deliberately kept it simple for pedagogical reasons rather than useful for daily work.

The post

On 25 August 1991, Torvalds posted to the comp.os.minix newsgroup. The archived message opens with the line that has been quoted ever since.

I’m doing a (free) operating system (just a hobby, won’t be big and professional like gnu) for 386(486) AT clones.

He went on to say he had ported bash and gcc and that things seemed to work, that he wanted to know which features people would want, and that the system was not portable and probably never would support anything other than AT hard disks. He was wrong about the portability too. Linux now runs on more processor architectures than any other operating system in general use.

Torvalds wanted to call it Freax. In September 1991 he uploaded the code to an FTP server at Helsinki University of Technology, where a volunteer administrator named Ari Lemmke decided Freax was a poor name for a directory and called it linux instead. He did not ask. The name stuck, which is a reasonably good summary of how a lot of decisions in this world get made.

The licence change that mattered more than the code

The first releases carried a licence Torvalds wrote himself. It let people copy and modify the code but forbade distributing it for money. That sounds generous. In practice it was a dead end, because it made the code incompatible with the GNU tools everyone was already using with it, and it blocked anyone from selling the floppy disks and CDs that were how software actually reached people in 1992.

The release notes for version 0.12, still sitting on the kernel archives today, record the change in about forty words.

I’ve had a couple of requests to make it compatible with the GNU copyleft, removing the “you may not distribute it for money” condition. I agree. I propose that the copyright be changed so that it confirms to GNU – pending approval of the persons who have helped write code.

Otherwise The GNU copyleft takes effect as of the first of February.

That is the whole thing. The spelling of “confirms” is Torvalds’, preserved in the archived file. A short administrative note, written by a student, is arguably the single most consequential decision in the history of the project. Under the old licence Linux would have been a curiosity. Under the GPL, companies could build businesses on it without asking permission, and were legally obliged to publish their changes to the kernel. That combination is what turned a hobby into infrastructure.

Version 1.0 arrived in 1994. By then the shape of the thing was set. GNU supplied the userland, Linux supplied the kernel, and companies had begun packaging the two together and selling the result.

The years that shaped it

  • 1983. Richard Stallman announces the GNU Project, aiming to build a complete free Unix compatible system.
  • 1991. Torvalds posts to comp.os.minix on 25 August and releases the first kernel code in September.
  • 1992. The kernel moves to the GNU General Public License. Softlanding Linux System and other early distributions begin bundling kernel and userland together.
  • 1993. Slackware and Debian both appear. Debian is founded by Ian Murdock in August as an explicitly community run project.
  • 1994. Kernel 1.0 ships. Commercial Linux companies are forming, among them SUSE in Germany and Red Hat in the United States, building businesses on software they cannot stop anyone else copying.
  • 1998. Netscape releases its browser source code, the term “open source” is coined, and IBM and Oracle begin taking Linux seriously.
  • 2003. SCO sues IBM over claimed Unix code in Linux, beginning a legal saga that drags on for years and ultimately fails.
  • 2004. Ubuntu launches, funded by Mark Shuttleworth, with the explicit goal of making Linux usable by people who do not enjoy configuring things.
  • 2005. The kernel team loses access to the proprietary tool it had been using for version control. Torvalds starts writing Git on 3 April and it is hosting its own development within a week. Git goes on to dominate software development everywhere.
  • 2008. The first Android phone ships. The Linux kernel quietly becomes the most widely deployed operating system component on the planet.
  • 2014. Debian adopts systemd as its default init system after a long and unpleasant argument. A fork called Devuan is announced in November.
  • 2017. The last two non Linux systems drop off the Top500 supercomputer list. Munich votes to abandon its long running Linux migration in the same year.
  • 2022. Valve ships the Steam Deck running SteamOS, which is Arch Linux underneath, and Linux gaming stops being a joke.
  • 2023. Red Hat restricts public access to Enterprise Linux source, and the rebuild distributions split over how to respond.
  • 2024. A backdoor is found in the xz compression library days before it would have reached stable distributions. Schleswig-Holstein announces a migration of about 30,000 government workstations away from Microsoft software.

Linux is at least three different things

Most confusion about Linux comes from one word doing three jobs.

Linux the kernel is the actual project Torvalds started. It manages memory, schedules processes, drives hardware and enforces the boundary between programs. It passed forty million lines in early 2025, though any count like that shifts depending on whether you include comments, blank lines and the enormous tree of hardware drivers. It is the only part that is literally Linux, and we have a separate article on the kernel itself if you want the internals.

Linux the operating system is the kernel plus everything else you need before a computer is usable. Shell, C library, compiler, init system, package manager, network stack tooling, graphics stack, desktop environment. Most of that came from GNU and from projects with no connection to Torvalds at all.

Linux the distribution is one group’s assembly of all of the above, with decisions already made about which versions, which desktop, which init system, which security defaults and which release cadence. Ubuntu, Debian, Fedora and Arch are all Linux, and they can feel about as similar to each other as Windows feels to macOS.

There is no official Linux website

This one catches people out. No single site speaks for Linux, because no single organisation owns it.

The closest thing is kernel.org, run by the Linux Kernel Organization, a California public benefit corporation set up in 2002 to distribute the kernel to the public without charge. It is managed by the Linux Foundation, which provides the technical, financial and staffing support behind it. That is where the source code and the release announcements actually come from, and it is the site this article cites for version numbers.

Everything else is either a distribution’s own site, which is what you want when you are installing something, or a community site. Linux.org, despite the name, is an independently run help and discussion forum with no affiliation to the kernel project or the Linux Foundation. It is a perfectly reasonable place to ask a question. It is not an authority, and a great many people assume from the domain name that it is.

The naming argument

The Free Software Foundation asks people to say GNU/Linux for the complete system, reserving Linux for the kernel alone. The reasoning is that GNU supplied most of the userland and had been working toward exactly this system since 1983, and that the naming shorthand has erased that history. GNU’s own bulletin used the plain word Linux in June 1994 and had switched to GNU/Linux by January 1995.

Almost nobody outside the free software movement says GNU/Linux. Torvalds has been publicly dismissive of the request. The FSF’s underlying point is historically accurate and the practical usage is settled against it, and both of those can be true. This guide uses Linux for the system and says kernel when it means the kernel, which is what everyone actually does.

What the licence actually gives you

The kernel is under the GNU General Public License version 2. This matters more than most users realise, and it works differently from the permissive licences used by a lot of other open source software.

Free as in freedom, not as in zero dollars

The GPL grants four freedoms. Run the program for any purpose. Study how it works and change it, which requires access to the source. Redistribute copies. Distribute your modified versions. Nothing in there says the software must be gratis, and Red Hat has built a multi billion dollar business selling exactly this software. What the licence prevents is anyone taking the freedoms away from the next person down the line.

That last part is the copyleft condition, and it is the sharp edge. If you distribute a modified kernel, you must provide the source of your modifications under the same licence. You cannot take Linux, improve it, and ship the improvement as a closed product.

Companies that tried have lost. The clearest record is German, where the kernel developer Harald Welte ran a project called gpl-violations.org that brought a long series of actions against hardware makers shipping kernel code without meeting the conditions. A Munich court granted a preliminary injunction against Sitecom in 2004. A Frankfurt court ruled against D-Link in 2006. A Hamburg court found against Fantec in 2013. The obligation is not theoretical and it has been tested.

Version 2, and why the kernel stayed there

The Free Software Foundation published GPL version 3 in 2007. It added terms about patents and about hardware that accepts only manufacturer signed software, the practice sometimes called tivoisation after the TiVo digital recorder, which shipped Linux but refused to run modified builds.

The kernel did not move, and the same note that exempts user programs also closes the door on the version question.

Also note that the only valid version of the GPL as far as the kernel is concerned is _this_ particular version of the license (ie v2, not v2.2 or v3.x or whatever), unless explicitly otherwise stated.

Torvalds objected to the anti tivoisation terms, arguing that the licence should govern the code and not what people are allowed to do with their hardware. The practical obstacle is larger than the philosophical one. The kernel has thousands of copyright holders, many of them uncontactable and some of them dead, and relicensing would require permission from all of them. Linux is on GPLv2 permanently, and that decision is now effectively unchangeable.

The userspace boundary

A question people ask constantly. If Linux is copyleft, does software running on Linux have to be open source? No, and the exemption is written down. A note from Torvalds, carried with the kernel source and now kept in the file LICENSES/exceptions/Linux-syscall-note, says so in his own words.

NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls – this is merely considered normal use of the kernel, and does *not* fall under the heading of “derived work”.

The asterisks are his, marking emphasis in a plain text file. That single paragraph is why Oracle can sell closed database software that runs on Linux, and why proprietary graphics drivers exist in a legally awkward but tolerated middle ground.

The line sits at the kernel boundary. Change the kernel and you owe source. Write an application that runs on it and you owe nothing. The status of binary kernel modules that link against internal kernel interfaces, which is what Nvidia’s proprietary driver did for years, has never been settled in court and remains genuinely contested.

How a Linux system is put together

Understanding the layers explains almost every practical difference between distributions, and it explains why advice you find online sometimes does not work on your machine.

The bootloader starts first. Usually GRUB. It finds a kernel and hands control to it.

The kernel initialises hardware, mounts the root filesystem and starts exactly one program.

The init system is that one program, and it starts everything else. On nearly all mainstream distributions this is systemd, which also handles logging, device management, network configuration, timers and a good deal more. Alternatives exist. OpenRC, runit, s6 and dinit all have users, and Devuan, Void, Artix and Alpine ship them.

The C library sits between applications and the kernel. Almost always glibc. Alpine uses musl instead, which is smaller and stricter, and which occasionally breaks software that quietly relied on glibc behaviour. This is why an Alpine container sometimes fails in ways a Debian container does not.

The userland utilities are the commands you type. Mostly GNU coreutils, bash, and the rest of the toolkit that predates the kernel by years.

The package manager installs software and tracks dependencies. Debian and Ubuntu use apt with .deb packages. Fedora and Red Hat use dnf with .rpm. Arch uses pacman. openSUSE uses zypper. Newer cross distribution formats, Flatpak and Snap, bundle their dependencies and sidestep the whole problem at the cost of disk space and some integration rough edges.

The display server draws things on screen. X11 has done this job since the 1980s and is being replaced by Wayland, a change discussed further down because it is the biggest disruption to the Linux desktop in twenty years.

The desktop environment is the part you actually look at. GNOME and KDE Plasma are the two large ones and they have genuinely different philosophies. GNOME is opinionated and minimal and removes options on purpose. KDE gives you a settings panel for nearly everything. Xfce, Cinnamon, MATE, LXQt and others target lighter hardware or more traditional layouts. On a server there is no desktop environment at all, which is part of why Linux servers need so little memory.

Every one of those layers is swappable. That is the design. It is also why “how do I do X on Linux” often has six answers, four of which are wrong for your particular system.

The distribution families, and how to pick one

There are hundreds of distributions. Nearly all of them descend from a handful of ancestors, and once you know the families the choice gets much smaller.

The Debian family

Debian was founded by Ian Murdock in August 1993 and has never been owned by a company. It is run by its developers under a written constitution and a social contract, it ships an enormous package archive, and it moves slowly on purpose. Debian 13, codenamed trixie, was released on 9 August 2025 and gets full support until August 2028 with long term support to June 2030.

Ubuntu is built on Debian and funded by Canonical. It releases every six months, with a long term support version every two years. Ubuntu 26.04 LTS, called Resolute Raccoon, arrived on 23 April 2026 with security updates promised until April 2031. Ubuntu did more than any other project to make Linux installable by ordinary people, and it is also the distribution most likely to annoy experienced users, mainly over Snap packaging being pushed as the default for things that were previously plain apt packages.

Linux Mint sits on top of Ubuntu and removes the parts of it that irritate people. It ships a conventional desktop, avoids Snap by default, and is the distribution most often recommended to someone coming from Windows. Pop!_OS, Zorin OS and elementary OS occupy nearby territory with different aesthetics. Raspberry Pi OS is Debian too, which is why so much Raspberry Pi advice is really Debian advice.

The Red Hat family

Red Hat Enterprise Linux is the commercial standard in large organisations, sold as a subscription with long support windows and certification from hardware and software vendors. Fedora is the upstream community distribution where new work lands first. Fedora 44 was released in April 2026 with GNOME 50.

The free rebuilds of Enterprise Linux have had an eventful few years, covered in the governance section below. AlmaLinux and Rocky Linux are the two main survivors and they now take different technical approaches.

Arch, SUSE and the independents

Arch Linux is a rolling release, meaning there are no version numbers and you simply keep updating forever. It installs almost nothing by default and expects you to assemble your own system. Its documentation is the best in the entire Linux world and is used by people running completely different distributions. Manjaro, EndeavourOS and CachyOS give you Arch with the sharp edges filed down. SteamOS on the Steam Deck is Arch based as well.

openSUSE comes in two forms, Leap for stability and Tumbleweed for rolling releases, and its YaST configuration tool has no real equivalent elsewhere. SUSE Linux Enterprise is the commercial version and is particularly strong in European enterprise and in SAP environments.

Beyond those, Alpine is tiny and dominates container images, Gentoo compiles everything from source, NixOS builds the whole system from a declarative configuration file, and Void and Devuan exist substantially because their maintainers did not want systemd.

Choosing without agonising

  • Coming from Windows and want it to just work. Linux Mint, or Ubuntu LTS.
  • A server you want to forget about for five years. Debian stable, or Ubuntu LTS, or Rocky and AlmaLinux if you need Enterprise Linux compatibility.
  • A workplace that needs a vendor to shout at. Red Hat Enterprise Linux or SUSE Linux Enterprise. You are paying for support and indemnity, not for the code.
  • Newest software, willing to accept some breakage. Fedora, or an Arch derivative.
  • An old laptop with 4GB of memory. Any distribution with Xfce or LXQt. Linux Mint offers an Xfce edition.
  • Gaming. Bazzite, CachyOS and Nobara are all built for it, and plain Fedora or Ubuntu will also do fine.

The honest advice is that the choice matters far less than the forums suggest. The kernel is the same, the applications are the same, and the differences amount to defaults and update policy. Pick one from the list, use it for a month, and switch if it annoys you. Your files will still be there.

Where Linux actually runs

The popular framing of Linux as a niche alternative operating system is roughly the opposite of the truth. It is the default nearly everywhere except the desktop.

Supercomputers. All 500 machines on the Top500 list run Linux, and have done since the last two holdouts fell off in November 2017. There is no second place.

Servers and cloud. The major cloud providers run Linux as the host operating system and offer it as the default guest. Amazon, Google and Microsoft all maintain their own distributions or heavily customised builds. Microsoft, which spent the early 2000s describing open source in fairly hostile terms, is now among the larger contributors to Linux related projects and ships a Linux kernel inside Windows for its subsystem feature.

The web stack. The classic combination of Linux, Apache, MySQL and PHP is what most of the web was built on, and its modern descendants swap in Nginx, PostgreSQL or Node.js without changing the layer underneath. Every WordPress site you have ever visited was almost certainly served from a Linux machine.

Containers. Docker and Kubernetes are not merely software that runs on Linux. They are built directly on Linux kernel features, namespaces and control groups, which exist for no other purpose. Container technology as the industry now uses it could not have been built on any other kernel without inventing the equivalent first.

Phones. Android uses the Linux kernel. Google has added a great deal on top and the userland has almost nothing in common with a desktop Linux system, but the kernel underneath is the same project, and Android device drivers have pushed real changes back into mainline.

Everything else. Televisions, routers, cars, point of sale terminals, air traffic systems, medical devices, the in flight entertainment screen on the seat back in front of you, and both the International Space Station laptops and a very large number of industrial controllers. If a device is more complicated than a toaster and was designed after about 2005, the odds are good.

As of late August 2026 the kernel project was shipping mainline 7.2, released on 16 August 2026, alongside a stable 7.1.10 and six separate long term branches going back to 5.10, all updated on 23 August 2026. That release cadence, sustained for three decades across an ownerless project, is the part that should impress you.

Linux on the desktop, honestly

Now the awkward part. Linux won every computing category except the one people actually see.

The numbers, and why they are slippery

StatCounter’s worldwide desktop figures for June 2026 put Windows at 56.61 percent and Linux at 4.36 percent. Before anyone builds an argument on that, look at the third largest line in the same table. Unknown sits at 21.45 percent, covering traffic where the operating system could not be identified, which includes VPN users, hardened browsers and privacy settings. Those are exactly the populations where Linux is over represented. The same table also splits Apple into separate OS X and macOS rows, which tells you something about how the categorisation works.

So the real number is somewhere above four percent and nobody can say by how much. It has been climbing steadily for several years, which is a change from the long flat stretch before it. Valve’s Steam hardware survey, which measures a self selecting but very large population, showed Linux passing 5 percent for the first time in early 2026. Roughly a quarter of that was SteamOS on the Steam Deck, meaning the rest is ordinary desktop Linux.

What genuinely works now

Installation on typical hardware takes twenty minutes and asks fewer questions than Windows does. Wifi, bluetooth, webcams, suspend and resume and hidpi displays work out of the box on most machines, which was emphatically not true a decade ago. Web applications removed most of the software compatibility problem, since a browser is a browser. Battery life on well supported laptops is now competitive and sometimes better.

Gaming is the transformation nobody predicted. Valve’s Proton, a compatibility layer built on Wine, runs a large majority of the Windows games in the Steam catalogue without the user doing anything. Valve’s own verification programme had certified more than twenty thousand titles as playable on SteamOS by late 2025. For a fifteen year running joke, that is a remarkable turnaround, and it happened because one company with commercial motives paid engineers to fix it.

What still does not

Specific professional software. Adobe’s Creative Cloud does not run on Linux and Adobe has no interest in changing that. Microsoft Office runs only in a browser. AutoCAD, SolidWorks, Sibelius, Pro Tools and a long list of industry standard tools are absent. The open source alternatives are often good, occasionally excellent and sometimes not close. If your work requires a specific application and your clients require its file format, that argument ends there.

Anti cheat in multiplayer games. Several kernel level anti cheat systems either refuse to run on Linux or are switched off for Linux by the publisher. That single decision blocks a number of the most played online titles, and no amount of technical work on the Linux side can fix it.

Printers and scanners. Much better than the horror stories suggest, and still capable of consuming an entire afternoon when a manufacturer has shipped a driver only for Windows.

The Wayland transition. X11, the display system Linux has used since the 1980s, is being retired in favour of Wayland. KDE plans to drop its X11 session in Plasma 6.8, expected around October 2026, and GNOME is moving the same way. Wayland is genuinely better designed and closes real security holes in X11, where any application could read every other application’s window contents and keystrokes. The transition has also broken screen recording tools, remote desktop setups, automation scripts, colour management workflows and accessibility software, in some cases for years. Nvidia’s driver worked poorly with Wayland until explicit synchronisation support arrived in driver version 555, which fixed the flickering that was the most visible symptom. Older Nvidia hardware on legacy drivers is still better off on X11, and that hardware will run out of road when the X11 sessions go.

Accessibility. This is the weakest part of the Linux desktop and the part most often glossed over. Orca, the GNOME screen reader, was originally developed at Sun Microsystems and lost most of its corporate backing after Oracle’s acquisition, continuing for years on very thin resources. The consulting firm Igalia now funds work on it and both GNOME and KDE have made progress, but screen reader support across the Linux desktop still lags Windows and macOS by a considerable distance, and the Wayland move disrupted the accessibility stack at exactly the wrong moment. For someone who depends on assistive technology, this is not a preference question. It can be a straightforward reason Linux is not usable, and it deserves to be stated plainly rather than buried.

Fragmentation, the honest version

Choice is the standard defence and it is a real benefit. It is also a real cost. A developer who wants to ship a desktop application for Linux faces two desktop environments with different design conventions, three packaging formats, two display servers during a multi year transition, and a dozen distributions with different library versions. That is why so many companies ship an Electron application or a web page instead, and why so many ship nothing at all.

Flatpak has improved this considerably by letting a developer ship one bundle that runs everywhere. Snap does the same job with a different design and Canonical’s centralised store attached, which is the main source of the objections to it. Having two competing solutions to the fragmentation problem is, in a way that is almost too neat, itself an example of the fragmentation problem.

Two public sector migrations worth studying

Munich approved the LiMux project in 2003 and moved roughly 15,000 workstations to Linux and open source software over about a decade. City figures put the savings at around 11 million euros by 2013. In February 2017 the council voted 50 to 25 to end it and return to Windows. Karl-Heinz Schneider, who led the project, described the reversal as political rather than technical, and critics noted that Microsoft had moved its German headquarters to Munich in 2016 and that the mayor elected in 2014 had described himself as a fan of the company. Estimates of the cost of switching back ranged from about 50 million euros in council figures to around 100 million once integration work was counted. Munich later committed again to open source procurement.

The German state of Schleswig-Holstein is running the current large experiment. In April 2024 it made LibreOffice the standard office package for around 30,000 state employees, and made Open Document Format the official document standard from 1 August 2024. It completed a move from Microsoft Exchange and Outlook to Open-Xchange and Thunderbird on 2 October 2025, covering more than 40,000 mailboxes. Its open source strategy was published in November 2024, and support is handled through Dataport, a government owned IT provider, rather than left to individual departments.

The instructive difference is the support structure. Munich left a lot of the burden with the city’s own IT department and had no strong political protection when the administration changed. Schleswig-Holstein built the support arrangement first and wrote the strategy down. Neither case proves Linux migration works or fails. Both show that the deciding factors are organisational rather than technical, which is the finding people least want to hear.

Security when everyone can read the code

The standard claim is that open source is more secure because anyone can inspect the code. The standard counter is that attackers can read it too. Both are lazy. The truth requires looking at what actually happens.

What visibility really buys

Reading source code is not how most vulnerabilities are found. Fuzzing, static analysis and traffic observation find far more, and those techniques work on closed software as well. What open code changes is what happens after a flaw is found. You can verify a fix rather than take a vendor’s word for it. You can apply a patch yourself if the vendor is slow. You can audit before deploying. And critically, a vendor cannot quietly decide that a bug affecting only a few thousand customers is not worth fixing, because someone else can fix it.

The design of Unix like systems helps too, for reasons that have nothing to do with licensing. Ordinary users do not run as administrator. Software is installed from signed repositories rather than downloaded as executables from search results. Services run under separate accounts with limited permissions. Those habits prevent a large share of what actually goes wrong on desktop computers, and they are the reason Linux desktop malware is rare in a way that is only partly explained by market share.

The xz backdoor, and what the near miss showed

On 29 March 2024, Andres Freund, a developer at Microsoft, was benchmarking PostgreSQL on Debian’s unstable branch when he noticed SSH logins were taking about half a second longer than they should. He followed the anomaly into liblzma, part of the xz compression utilities, and found a deliberately planted backdoor. It was assigned CVE-2024-3094 with a severity score of 10 out of 10.

The details are worse than the code. An account using the name Jia Tan had spent roughly two years contributing legitimate work to the xz project, gradually earning trust, until the original maintainer, who was working alone and had publicly mentioned being under strain, granted co-maintainer status. The backdoor was then introduced into the release tarballs rather than the source repository, which is exactly where fewer people look. It targeted SSH servers on systems where a distribution had linked liblzma into sshd, and would have given anyone holding a particular private key remote code execution on a very large number of internet facing machines.

It was caught before it reached any stable distribution. It affected versions 5.6.0 and 5.6.1, which had reached testing and development branches only. The catching was luck, in the sense that it depended on one careful engineer noticing a 500 millisecond delay he had no obligation to investigate.

Read it the way you like. Open source advocates point out that the transparency of the build and the ability to read the commits is what made the discovery and the forensic reconstruction possible at all, and that an equivalent attack on closed software might never have been noticed. That is fair. It is also fair to say that a piece of infrastructure sitting underneath most of the world’s Linux servers was maintained by one unpaid person who was struggling, and that the attacker found that out and used it. Both of those readings survive contact with the evidence.

The Minnesota experiment

In April 2021 Greg Kroah-Hartman, one of the kernel’s most senior maintainers, banned all patch submissions from University of Minnesota email addresses. Researchers there had published a paper titled “On the Feasibility of Stealthily Introducing Vulnerabilities in Open-Source Software via Hypocrite Commits”, based on deliberately submitting subtly flawed patches to the kernel to see whether reviewers would catch them.

A subsequent review by kernel maintainers concluded that none of the deliberately buggy patches had reached a released kernel. The review process caught them. The episode is still cited in both directions, as evidence that review works and as evidence that the review process can be attacked by anyone willing to spend time building credibility. The second reading is the one the xz incident later reinforced.

What actually keeps a Linux machine safe

  • Install updates. Nearly every real world compromise exploits a flaw that was patched weeks or months earlier.
  • Install software from your distribution’s repositories or from Flathub, not from a script piped into a shell from a website you found in a search result.
  • Use SSH keys rather than passwords on anything reachable from the internet, and disable password authentication once keys work.
  • Do not disable SELinux or AppArmor because a forum post told you it would fix your problem. It probably will, and it will also remove a layer that was doing something.
  • Run as a normal user. Use sudo when you need to and read what you are agreeing to run.
  • Take backups you have actually tested restoring. This is the advice everyone ignores until the one time it matters.

Linux is not immune. Ransomware targeting Linux servers is a growing business, largely because that is where the valuable data sits. The operating system’s defaults are good. They are not a substitute for maintenance.

Who actually pays for Linux

The picture most people carry around is volunteers in bedrooms. That was accurate in 1993 and is badly out of date now.

Linux Foundation development reports have consistently found that more than 80 percent of kernel changes come from developers paid to write them, with the largest single contributors being companies like Intel, Red Hat, Google, AMD, IBM, Samsung and SUSE. The share from unpaid volunteers has fallen over the years rather than risen. The top handful of companies between them account for a majority of changes.

This is not a scandal and it is not hypocrisy. Companies contribute because carrying private kernel patches forever is expensive and getting your changes upstream is cheaper. The licence makes cooperation the rational choice even between direct competitors. Intel and AMD both improve the same scheduler. That is the mechanism working as designed.

The genuine risk is different, and it is not about the kernel. The kernel is well funded and heavily reviewed. The problem lives further down, in the hundreds of small libraries that every Linux system depends on and that are maintained by one or two people in their spare time. The xz maintainer was one of those people. So are the maintainers of a long list of things you have never heard of and use every day. Initiatives like the Sovereign Tech Fund and the Open Source Security Foundation exist to address this, and they are new, small relative to the problem, and unevenly distributed.

If you run a business on Linux, that is the part worth thinking about. The dependency you should worry about is rarely the famous one.

Governance, forks and the arguments that shaped it

Linux has no owner, which means disputes get resolved by argument, by forking, or by one party simply doing what it wants. Three episodes explain the shape of things better than any description of the governance model.

systemd

systemd replaced the old collection of shell scripts that started services at boot. It starts things in parallel, tracks processes reliably, handles logging and device management, and made a large class of fragile boot problems go away. It also grew to absorb functions that used to be separate programs, which is precisely the objection. Critics argue it violates the Unix convention of small tools doing one thing, that it concentrates too much of the system in one project, and that its adoption was driven more by distribution maintainers than by users.

Debian voted on it in November 2014. The general resolution on init system coupling failed to pass, which in practice left developers free to require systemd, and systemd became the default. The argument was bruising enough that some long serving Debian contributors stepped away from the project. In late November 2014 a group announced a fork called Devuan, which ships Debian without systemd and released its first stable version on 25 May 2017.

Ten years on, systemd is the default nearly everywhere and most of the technical criticisms have softened. The episode still matters because it showed the mechanism. There was no vote of users. There was a decision by the people doing the packaging work, an unhappy minority, and a fork as the only real avenue of appeal. That is how this system resolves disagreement, and whether you find it healthy or alarming probably depends on whether you were in the minority.

CentOS and the Red Hat source restriction

CentOS was a free rebuild of Red Hat Enterprise Linux, compiled from the published source, and it ran on an enormous number of servers belonging to organisations that wanted Enterprise Linux without the subscription. Red Hat acquired the project in 2014. In December 2020 it announced that CentOS Linux would be discontinued in favour of CentOS Stream, which sits ahead of Enterprise Linux rather than behind it, changing it from a stable rebuild into a development preview. Organisations that had built ten year plans on CentOS were given a much shorter runway than they expected.

AlmaLinux and Rocky Linux appeared to fill the gap. Then in June 2023 Red Hat announced that CentOS Stream would be the only public source repository for Enterprise Linux code, with the actual Enterprise Linux sources available to paying customers through the customer portal. Producing an exact rebuild became substantially harder.

The two projects diverged in their response. AlmaLinux dropped the goal of being identical to Enterprise Linux and now aims for binary compatibility, meaning software built for Enterprise Linux runs on it, while allowing itself to differ where that is sensible. Rocky Linux, along with OpenELA, a body formed by Oracle, SUSE and CIQ, continued pursuing exact compatibility using rights they argue the GPL gives them.

Nothing Red Hat did breached the licence. It has always been permitted to give source only to customers, and customers remain free to redistribute it. That is the point worth sitting with. The licence protected the code and did not protect the business model that thousands of organisations had quietly assumed would continue. Open source guarantees your rights to the software. It does not guarantee that a company will keep making its work convenient for you.

Who owns the name

The code belongs to thousands of copyright holders and cannot be taken back. The word is a different matter. Linus Torvalds personally owns the Linux trademark in the United States, the European Union, Germany and Japan, and it is administered on his behalf by the Linux Mark Institute, which the Linux Foundation now runs.

Approved applicants get a free, perpetual, worldwide sublicence to use the mark. In exchange they agree to attribute ownership properly and not to challenge Torvalds’ claim to it.

The arrangement exists because of what happened in the 1990s. William R. Della Croce Jr, who had no involvement in the project, filed a United States trademark application for the word Linux in August 1994 and obtained the registration in September 1995. In 1996 he began writing to Linux distributors demanding ten percent of their royalties. In November 1996 five parties petitioned to cancel it, those being WorkGroup Solutions, Yggdrasil Computing, Linux Journal, Linux International and Torvalds himself. Della Croce assigned the mark to Torvalds in August 1997 and the proceeding was dismissed. Holding the trademark defensively is how that stays fixed.

It is a useful thing to understand about open source generally. The licence governs the code and the trademark governs the name, and they are separate instruments with separate owners. You may fork the kernel and ship it tomorrow. What you may not do is call the result Linux without permission.

The fork as a governance mechanism

Forking is the constitutional backstop of open source. LibreOffice forked from OpenOffice.org, MariaDB forked from MySQL, Rocky and Alma forked from the Enterprise Linux lineage, Devuan forked from Debian, and every one of those happened because a group with the legal right to continue the code disagreed with the direction of travel.

Forks are expensive and most of them fail. The threat of a fork does most of the work, because a project leadership that behaves badly enough will find its contributors leaving with a full copy of the code. That is a weaker check than a vote and a stronger one than nothing at all, and it is the only check that exists.

Free software and paid support

Linux is free and there is a large industry selling it, which confuses people until you look at what is actually being sold.

Red Hat’s subscription buys support with contractual response times, ten years of security backports, certification that particular hardware and enterprise software is tested against it, legal indemnity against intellectual property claims, and someone to call at three in the morning. SUSE sells the same category of thing. Canonical sells Ubuntu Pro, which extends security coverage to a much wider set of packages and lengthens the support window, and gives it away free for personal use on a handful of machines.

None of that is a licence fee. Stop paying and the software keeps running. You lose the support and the patch stream, not the right to use what you have. This is a genuinely different relationship from proprietary licensing, where non payment can mean the software stops working or you are in breach of contract, and it is the practical reason organisations that have been audited by a proprietary vendor tend to become interested in Linux.

It also means the vendor’s incentive is to keep you happy rather than to keep you locked in. They can do the second thing through file formats, management tooling and certification requirements, and to be fair, some of them try. The floor is still higher than it is elsewhere.

Linux and open source in New Zealand

New Zealand is a small market a long way from anywhere, which is a reasonable argument for caring about software you are not locked out of.

Government policy here is more developed than most people realise. The New Zealand Government Open Access and Licensing framework, known as NZGOAL, covers how publicly funded material is licensed for reuse. Its Software Extension, NZGOAL-SE, gives agencies guidance on releasing publicly funded software under open source licences so that other agencies and the public can build on it. The consultation that produced it was run in the open using Loomio, a decision making tool built by Enspiral in Wellington, which is a small but genuine example of the thing working on itself.

On the commercial side, Catalyst IT is the best known New Zealand owned open source company, headquartered in Wellington and working across government, education and health both here and offshore. Its existence answers the question people ask about support. You can buy support for open source software from a company in your own time zone that pays tax here, which is not something you can say about most proprietary licensing arrangements.

The digital sovereignty argument has more weight in a country this size than in a large one. When the software running the public sector is licensed from vendors headquartered elsewhere, subject to another country’s law and priced in another country’s currency, the exposure is not theoretical. Open source does not remove that dependency by itself, since you can be just as dependent on a foreign cloud provider running open source software. What it removes is the specific risk that a licence is withdrawn, repriced or made conditional on terms you did not agree to.

For a small business or a school here, the practical case is duller and probably more persuasive. Old hardware stays useful for longer. There is no per seat cost that grows with headcount. There is no audit. And when a supplier relationship goes bad, the software does not leave with them.

The costs nobody mentions

Free software is not free to run. Anyone who tells you otherwise has not done a migration.

People who know it. The dominant cost of any Linux deployment. Windows administrators are common and cheap, and experienced Linux administrators are neither. If you have nobody in house you are buying support or hiring, and the saved licence fees can vanish into that in the first year.

Retraining. Munich’s experience is the standard case study. Staff who have used one office suite for fifteen years are slower on a different one for months, and the productivity dip is real even when the replacement is good. It is also finite, which organisations planning migrations routinely fail to explain to the people affected.

Interoperability at the edges. The document that arrives from outside with tracked changes and a complicated template. The industry portal that assumes a particular browser. The accountant who needs one specific file format. These are individually small and collectively the reason migrations stall.

Your own time. If you are a hobbyist this is fun. If you are running a business it is an expense, and time spent making a scanner work is time not spent on the thing that earns money.

Being your own vendor. Nobody is obliged to help you. Community support is often outstanding and sometimes unwelcoming, and it is always voluntary. If you need an answer within four hours, buy a support contract and treat it as the cost of doing business.

The economics still work out well in a great many cases, particularly on servers, particularly at scale, and particularly over long time horizons. They work out badly for a five person office with a Windows dependent line of business application and no technical staff. Both of those are ordinary outcomes and the honest answer depends on which one you are.

Seven common misconceptions

“Linux is hard to use”

Linux is hard to administer, which is a different claim. Installing Linux Mint and using it to browse, write and watch things is easier than it is on Windows, with fewer prompts and no advertising in the start menu. What is hard is the moment something breaks, because the fix will probably involve a terminal and a forum post from 2019. That gap between normal use and troubleshooting is much wider than on commercial systems, and it is the actual barrier.

“You need to know the command line”

For everyday desktop use, no. Graphical tools exist for software installation, updates, printers, network settings and everything else a normal user touches. The terminal is faster once you know it, and every piece of advice online is written in it because a command is unambiguous and “click the third icon” is not. That is a documentation habit, not a requirement.

“Open source means amateur”

The kernel is written largely by paid engineers at Intel, Google, Red Hat, AMD and IBM, reviewed publicly, and tested continuously across an enormous hardware range. The review process is stricter than at many commercial software companies, mostly because the review happens where everyone can see it.

“There is no support”

There is more support available than for most proprietary software, and it is unbundled. You choose whether to buy it and from whom, rather than having it included in a licence fee at a level of quality you cannot influence.

“Linux does not get viruses”

Linux desktop malware is genuinely rare. Linux server compromise is common and profitable, and ransomware groups target Linux systems specifically because that is where the databases live. The permission model helps and the software distribution model helps more. An unpatched internet facing server is an unpatched internet facing server whatever it runs.

“It is all free, so somebody must be losing money”

Almost every large contributor is commercially better off for contributing. IBM paid 34 billion US dollars for Red Hat in 2019, a company whose entire product line is software anyone may copy. The business is in support, certification and operational trust, and it is a perfectly ordinary business.

“The community decides everything democratically”

It does not. Torvalds has final say over the kernel. Debian has a formal constitution and elected leadership. Ubuntu is steered by Canonical. Fedora is shaped substantially by Red Hat. Arch is run by its maintainers. These are different governance models with different amounts of user input, and in several of them your input consists of the right to leave with a copy of the code. That right is real and it is not the same as a vote.

When Linux is the wrong choice

A page that only lists advantages is advertising. Here is where the answer is genuinely no.

  • You depend on specific proprietary software. Adobe’s suite, Microsoft Office with complex macros, industry design or engineering packages, professional audio with particular plugins. Compatibility layers exist and are unreliable for professional work with deadlines.
  • You rely on assistive technology. Screen reader support on Linux is materially behind Windows and macOS. If you depend on it, test very carefully before committing, and be prepared for the answer to be no.
  • You play competitive multiplayer games with kernel level anti cheat. Several of the largest titles will simply not run, and that is a publisher decision.
  • You have no technical capacity and no budget for support. A small business with no IT person and no willingness to buy help is a poor fit. Something will eventually need attention.
  • Your organisation is locked into a compliance regime that names products. Some regulated environments require specific certified software. Fighting that is a legal and procurement problem, not a technical one.
  • You need a machine to work perfectly on Tuesday and it is Monday. Do not migrate under deadline pressure. Ever.

None of these are permanent, and several have improved a lot in five years. They are the current state of things and pretending otherwise wastes people’s weekends.

How to try it without breaking anything

You do not have to commit to find out whether Linux suits you.

Run it from a USB stick. Nearly every distribution offers a live image. Write it to a USB drive, boot from it, and you get a full working desktop that touches nothing on your hard drive. It will be slower than an installed system because it is running from the stick. It will tell you within twenty minutes whether your wifi, graphics, sound and trackpad work, which is the question that matters.

Use a virtual machine. VirtualBox or the built in tools on your existing system will run Linux in a window. Good for learning the shell and trying distributions, poor for judging graphics performance or hardware support.

Use an old laptop. The best option if you have one sitting in a cupboard. A machine that is unbearable under a current version of Windows is often perfectly pleasant running a lightweight Linux desktop, and there is nothing on it you can break.

Dual boot last, not first. It works and it is the most common way people end up with a partitioning accident. If you do it, back up first, let the installer resize the partition rather than doing it manually, and accept that Windows updates occasionally overwrite the bootloader.

A sensible order is to try the open source applications on your current system before changing operating system at all. If LibreOffice, Firefox, Thunderbird, GIMP and VLC already cover what you do, the switch is mostly cosmetic. If they do not, you have learned that cheaply.

Common questions

Is Linux really free, with no catch

Yes. Download it, install it on as many machines as you want, forever, without registering or paying anyone. The catch, if there is one, is that responsibility for the system is yours unless you buy a support contract from someone.

Which distribution should a beginner use

Linux Mint if you are coming from Windows, Ubuntu LTS if you want the largest amount of written help available online. Both are good and the difference will not matter for months.

Can I run Microsoft Office or Adobe software

Microsoft Office runs in a browser and that works acceptably for straightforward documents. Adobe’s applications do not run on Linux and there is no reliable workaround for professional use. Wine and CrossOver run many Windows programs, with results ranging from flawless to unusable depending on the program.

Will my files transfer

Documents, photos, music and video move across without difficulty. Formats are the friction, not files. A complicated Word document with tracked changes and a custom template may not survive a round trip through LibreOffice intact, and email is straightforward if you were using a normal mail account and painful if you were using a proprietary archive format.

What is the difference between Linux and Unix

Unix is the older family of operating systems from Bell Labs in 1969, and the commercial descendants of it. Linux was written from scratch to behave like Unix without containing any of its code, which was the entire point and which is what allowed it to be freely licensed. macOS is a genuine Unix derivative through BSD, which is why so many commands work the same way on a Mac.

Does Linux collect my data

The kernel does not. Some distributions collect installation and hardware statistics, Ubuntu among them, and every one of those is documented and can be turned off, which you can verify by reading the code that does it. This is a meaningfully different position from an operating system whose telemetry you cannot inspect, disable completely or reason about.

What happens if Linus Torvalds stops

Very little, in the medium term. The kernel has a deep bench of subsystem maintainers, Greg Kroah-Hartman has effectively been the second in command for years, and the Linux Foundation exists partly to make the project survive individuals. There would be a period of jostling about who makes the final call on contentious changes. There would not be a crisis, and there is no scenario in which the code stops being available.

Is it true that Linux only succeeded because it was free

Price helped and it is not sufficient on its own, since several other free Unix like systems existed at the same time and none of them took over the world. What Linux had was a licence that made commercial participation safe, a maintainer who accepted patches from strangers quickly, and timing that put it in front of the internet boom exactly when cheap server operating systems were needed. Remove any one of those and the story is different.

Should I use Linux on my main work machine

If your work is software development, systems administration, data analysis, science or anything primarily done in a browser and a terminal, it is at least as good as the alternatives and often better. If your work depends on a specific proprietary application or on assistive technology, the answer is probably no today. Test it from a USB stick before deciding, because your hardware and your workflow are the only evidence that counts.

Where this leaves things

Thirty five years after a student said his hobby would never be big or professional, Linux runs the fastest computers on earth, most of the internet, and the phone in your pocket. It did that without a marketing budget, without an owner, and while giving itself away. The mechanism that made it possible was not idealism. It was a licence that made cooperation cheaper than competition for companies that had every reason to distrust each other.

The same structure produces the weaknesses. No owner means no one is responsible for making the desktop coherent, so it is not. Distributed maintenance means critical libraries can rest on one exhausted volunteer, and in 2024 someone worked out how to exploit exactly that. Corporate funding keeps the kernel healthy and concentrates influence in a small number of companies, and when one of them changes its mind about what to publish, the licence protects the code without protecting anyone’s plans.

What you get is not perfection and not a free lunch. You get software nobody can take away from you, a system you are allowed to understand, a support market with real competition in it, and hardware that stays useful until it physically fails. Set against that, you take on responsibility that a licence fee would otherwise have bought you out of.

For servers, that trade has been settled for twenty years and the entire industry agrees. For desktops, it depends entirely on what you do all day. The right way to find out is to boot it from a USB stick and see, which costs an afternoon and nothing else.

A note on how this was made. This article was drafted with the assistance of AI and reviewed before publication. Dates, version numbers and the sequence of events described were checked against primary sources where those were reachable. The wording of the February 1992 licence change is quoted directly from the version 0.12 release notes as archived at kernel.org, including the original spelling. The description of the Linux Kernel Organization comes from its own statement of purpose, and the trademark arrangement from the Linux Foundation’s published sublicensing terms. The two quotations from the kernel’s syscall note are taken verbatim from the published text of that file, with the original emphasis marks left as they appear. The 1991 newsgroup post is quoted as it appears in the archived message and in consistent secondary reporting. Kernel version numbers were taken from kernel.org on 25 August 2026. Desktop share figures are from StatCounter for June 2026 and are reported here with the measurement caveats attached, because a single percentage without those caveats would be misleading. Where a question is genuinely unsettled, such as the legal status of binary kernel modules, it is described as unsettled rather than resolved in either direction.