In August, Linux turned thirty-five. A Finnish student's "just a hobby" now runs most of the internet, most of the cloud and, for a few months this year, more than five per cent of Steam's gamers [1] [2].
But 2026 was not a quiet birthday year. The kernel wrote down what happens after Linus Torvalds. It reached version seven. It let AI help write code, made a human sign for it, then started changing the rule again. Attackers went after the tools developers trust most. Europe started treating Linux as a question of sovereignty, not just cost. By the time the cake came out in August, the year had already decided what it was going to be about.
I have spent thirty years of my career on this operating system, from compiling kernels on hardware that is now a museum piece to running a New Zealand Linux distribution that, for a few months in 2003, was the most-downloaded thing on DistroWatch. Every Wednesday this year I have told one piece of that history. This is the year itself, in order, with the arguments that fell out of it once I lined all ten months up next to each other.
Ten Months, Ten Headlines
Thirty-five years ago the headline was a single Usenet post from a student who said his project was nothing big and professional. This year the headlines came from the European Commission, the maintainers of a security scanner, Linus Torvalds himself, a JavaScript library downloaded four hundred million times a month, a French government directorate, and Valve's own hardware survey, twice, in opposite directions. None of those institutions existed in any recognisable form in 1991. All of them now depend on code written under a licence that was never supposed to make anyone rich, and several of them spent 2026 finding out exactly how much that dependency costs when something goes wrong.
January to March: The Plan for After
The year opened in Brussels, not in a terminal window. In early January the European Commission put out a public consultation on a new open source strategy, asking a blunt question: could European open source projects grow into genuine commercial alternatives to the dominant American technology providers [3]? A consultation commits nobody to anything. But it set the register for a year in which open source stopped being treated as only a technical choice, and this special keeps that international and historical framing throughout, for the same reason the Topical Filter governing Linux Wednesday always has: this is community history and commercial consequence, not New Zealand government policy.
Two weeks later a much smaller project made a much louder point about where the strain of 2026 was actually landing. curl is the library that moves data across the internet inside billions of devices, from cars to phones. On 21 January its maintainer, Daniel Stenberg, ended curl's bug bounty programme, effective from the end of that month [4]. The reason was not the money. It was the noise: AI-generated security reports, most of them wrong, were arriving faster than a small team could read them. The first open source casualty of the AI era, in other words, was not a codebase. It was a maintainer's attention, which is the one resource a volunteer project cannot buy more of.
Then, on 27 January, the kernel did something it had spent thirty-four years avoiding. It wrote down what happens after Linus Torvalds. A document nicknamed "the conclave" sets out how the kernel's maintainers would decide the way forward if Torvalds could no longer lead the project [5]. Nobody suggested he was leaving. That is precisely why it matters: you write a succession plan while you still have the luxury of not needing one, and a volunteer community with no board, no chief executive and no shareholders had never had to answer the question of who holds the keys if the one person everyone trusts is gone.
What it was, why it mattered, what followed. The conclave document is not a legal instrument. Nobody can enforce it, and nobody voted on it in the way a company's board votes on a succession plan. It is a written statement of intent from the kernel's most senior maintainers about how decisions would be made in an emergency, produced because the alternative, having no answer at all, had become the more frightening option after thirty-four years of informal trust in one person's judgement.
Compare that to how a company handles the same question. A board has lawyers, a governance committee, a confidentiality agreement and, usually, a named deputy waiting in the wings before the announcement is ever made public. The kernel has none of those structures. What it has instead is a document that a group of unpaid and salaried volunteers, answerable to no single employer, chose to write anyway, because the project had grown too large and too depended upon to leave the question unanswered. That is a genuinely unusual thing for an organisation with no formal organisation to do, and it followed a year in which the AI tooling discussed below put new strain on exactly the kind of informal trust the kernel has always run on, which is the thread this special returns to at the end.
The code kept moving regardless of what was being written about it in January. On 8 February, Linux 6.19 became the first kernel release of 2026. Older AMD graphics cards from the GCN 1.0 and 1.1 generations moved to the modern AMDGPU driver by default, and a colour pipeline interface backed by Valve was merged into the kernel, laying groundwork for better HDR support on Linux gaming hardware [6].
On the desktop, March brought a cleaner break. GNOME 50 arrived as a Wayland-only desktop on 19 March. The X11 display system that Linux desktops had leaned on for decades was removed outright from the default session; older applications still run through the XWayland compatibility layer, but the direction is now settled. GNOME also added parental controls and better HDR and colour management in the same release [7].
Then the attackers arrived, and they were not aiming at Linux itself. They were aiming at the tools built around it. On 21 March a group identified as TeamPCP pushed credential-stealing malware through official releases of Trivy, a widely used open source security scanner, and rewrote seventy-five of the seventy-six version tags in its GitHub Action [8]. The tool organisations run to check their own software for problems had itself become the problem, for anyone who trusted its tags without checking them.
Ten days later the same pattern repeated at a far larger scale. Two malicious versions of Axios, a JavaScript library downloaded more than four hundred million times a month, installed a remote access trojan on Windows, Linux and macOS machines that pulled it in [9]. The compromised versions were live for about three hours before they were caught. In a build pipeline that updates dependencies automatically, three hours is more than enough time for the damage to be done before anyone notices.
What it was, why it mattered, what followed. Axios is not a niche package. It sits inside build chains that most developers never look at directly, which is exactly why a three-hour compromise window reached so far before anyone caught it. Four hundred million monthly downloads is not a figure that describes careful, individually considered installations; it describes a dependency that thousands of other projects pull in automatically, without anyone re-reading it each time a build runs. It mattered because it confirmed that 2026's attackers had worked out the same lesson curl's maintainer had already learned the hard way in January: the cheapest way to compromise a system built on trust is to attack the trust, not the code. Breaking a library used by a handful of specialists takes skill and buys little. Breaking a library pulled in by everyone's build pipeline takes the same skill and buys three hours inside an unknown number of other people's systems. What followed, across the rest of the year, was a steady drumbeat of the same move against different targets, discussed in the chapters below.
April to June: Version Seven
April opened with a number Linux gamers had waited a long time to see. Valve's hardware survey for March 2026 put Linux at 5.33 per cent of Steam users, the first time the platform had passed five per cent [2]. Nearly a quarter of those Linux installs were running SteamOS, Valve's own system. Hold on to that number. It does not stay there, and this special comes back to it in October.
The same week, Linux became a matter of state rather than a matter of preference. On 8 April, France's digital directorate, known as DINUM, announced at an interministerial seminar on sovereign technology that it would move its desktops from Windows to Linux, and asked every ministry to plan for alternatives to American technology providers [10]. I traced the beginning of this story in an earlier episode of this series, "Regaining the Keys," on the French government's move away from Windows; the point worth adding here is scale. A single consultation in Brussels in January had asked whether Europe could build commercial alternatives to American technology. By April, one of Europe's own governments was answering that question with its own desktop fleet.
What it was, why it mattered, what followed. DINUM's announcement was a statement of institutional intent, not a completed migration; the French government did not publish a timetable for every ministry in the same announcement, and this special does not claim one on its behalf. It mattered because it moved the sovereignty argument from Brussels policy papers into an actual government's actual procurement decision, the first of the year's events to do so. A consultation can be shelved. A seminar attended by a national digital directorate, with every ministry asked to plan, is a harder thing to walk back from once it has been said out loud. What followed was the European Commission's own strategy, published in June and discussed below, arriving on the same sovereignty logic from the institutional side rather than the national one, and together the two events turned a question Brussels had only asked in January into something two layers of European government were answering by June.
Four days later, on 12 April, Linus Torvalds released Linux 7.0. The version number itself is cosmetic; Torvalds has said in the past that he bumps the major number when the minor numbers get unwieldy, and this release was no exception. What the release carried was not cosmetic. Rust support left experimental status, so code written in Rust became simply part of the kernel rather than a tolerated extra. The XFS filesystem gained self-healing capability, ARM and RISC-V support kept growing, and Torvalds noted that AI tools would keep finding edge cases in the code [11].
Linux 7.0 also shipped something that was not code at all: the kernel's first official policy on AI coding assistants. A human must sign off on every AI-assisted patch, and contributors were asked to add an "Assisted-by" tag naming which tool they used [12]. It is worth sitting with the shape of that rule for a moment. The kernel did not ban AI assistance, and it did not pretend AI assistance was not happening. It built a disclosure mechanism and left the accountability exactly where it has always sat: with the named human who signs off on a change. This special returns to that tag's own life story in October, because it did not stay the same for long.
What it was, why it mattered, what followed. Rust leaving experimental status is a technical milestone with a governance consequence: a second systems language inside the kernel means a second set of review norms, a second set of contributors fluent in a different safety model, and a second set of edge cases for maintainers to learn. It mattered because it set up the rest of the year's AI-contribution debate on genuinely new ground, not just the old C codebase that has carried most of the kernel's history. It also mattered because of what it said about Torvalds' own posture towards the tooling arriving underneath his project: not a ban, not silence, but a public acknowledgement that the tools would keep finding edge cases, followed two weeks later by an actual written policy rather than an informal expectation. What followed was six more months of the kernel testing, in public, whether a human-sign-off rule could keep pace with a tool that writes code faster than any previous generation of contributor, and whether the discipline of naming the tool on every patch would still feel necessary once the practice had become routine.
Later in April, the distributions caught up with the kernel's own direction. On 23 April, Canonical released Ubuntu 26.04 LTS, codenamed Resolute Raccoon. It ships GNOME 50 on Wayland and full-disk encryption backed by the TPM chip, with five years of standard maintenance [13]. For a great many organisations, this is the Linux release they will run until the end of the decade, which makes its choices, rather than any single kernel release, the ones that actually reach the most desks.
Fedora 44 followed about a week later, on 28 April, with GNOME 50, KDE Plasma 6.6, and a toolchain moved to GCC 16 and LLVM 22 [14]. Fedora is where Red Hat's future tends to show up first, and in 2026 it showed up on schedule, as it almost always does.
Security pulled focus again on 3 May. The United States Cybersecurity and Infrastructure Security Agency, CISA, added a kernel flaw nicknamed "Copy Fail" to its catalogue of vulnerabilities under active exploitation. CVE-2026-31431 lets an ordinary local user become root on distributions shipped since 2017. The fixes were already sitting in Linux 7.0 and the stable kernel branches [15]. The gap, once again, was between a fix existing and a fix actually being installed on the machines that needed it.
On 11 May, the supply chain story returned in an uglier form. A self-spreading worm called Mini Shai-Hulud moved through TanStack packages on npm. According to the security firm StepSecurity, it published malicious packages carrying valid build provenance by hijacking the projects' own release pipelines [16]. Provenance records were supposed to be the answer to exactly this kind of attack. This particular worm signed its own paperwork on the way through.
Enterprise Linux took its own step into AI assistance on 20 May, when Red Hat released Enterprise Linux 10.2 and 9.8 with an optional AI assistant for the command line that supports the Model Context Protocol, alongside updated toolchains including Rust 1.92 and Python 3.14 [17]. Red Hat kept the assistant optional. In a regulated environment, that single word, optional, is most of the governance decision.
In early June, the Brussels consultation from January became policy. On 3 June the European Commission published its own open source strategy as part of a Technological Sovereignty Package, setting out funding, procurement and maintenance measures [18]. Maintenance is the detail worth underlining. A funding announcement that only pays for new projects treats open source as a product line. A funding announcement that explicitly covers maintenance treats it as the infrastructure it actually is, the same infrastructure curl's maintainer was defending with his own attention back in January.
On 14 June, Linux 7.1 arrived with a new NTFS driver for reading and writing Windows-formatted disks, Intel FRED support for Panther Lake processors, and faster Arc graphics performance [19]. It closed a development cycle in which the volume of bugs reported by AI tools kept rising, a trend the kernel had been living with since the Assisted-by tag arrived two months earlier.
June ended with hardware rather than software. Valve set the price of its Steam Machine, a SteamOS-based console-style PC, at one thousand and forty-nine US dollars, with first purchase emails going out from 29 June and a separate reservation list for Australia [20]. It is a Linux computer sold as a living-room box, from a company whose own games catalogue was, for most of its history, built almost entirely for Windows.
What it was, why it mattered, what followed. Taken together, April to June is the quarter in which Linux stopped being treated as a technical substrate and started being treated, across several unrelated institutions at once, as a deliberate choice with consequences attached: a government chose it for sovereignty, a kernel maintainer chose to formalise AI's role in it rather than ignore it, a distribution vendor chose to make it the thing millions of organisations run for the next five years, and a games company chose to sell it in a box with no keyboard at all. None of those four choices required any of the others. None of the four institutions making them was coordinating with the rest. All four happened inside the same ten weeks, which is the kind of coincidence that stops looking like a coincidence once a whole year of it has gone past.
July to September: Thirty-Five
Mid-year is when old releases quietly retire, and 2026 kept to the calendar. On 12 July, Debian 12, bookworm, ended three years of regular security support and moved to the Debian Long Term Support team, who will cover it until the end of June 2028 [21]. Debian sits underneath Ubuntu and a long list of other distributions, so its own retirement calendar ripples outward well past anyone running Debian directly.
On 16 August, Linux 7.2 shipped on schedule, with cache-aware scheduling that helps modern processors keep related work physically close together, and HDMI 2.1 FRL support for AMD graphics [22]. Torvalds held the release date despite what he had already described, in public comments around the release, as a rising volume of AI-tool-assisted patches. The process held. That is not guaranteed on a project this size, and it is worth noticing precisely because it so easily could not have.
Then, on 25 August, an anniversary. In 1991 a Finnish student posted to a newsgroup that he was writing a free operating system, "just a hobby," nothing big and professional. Thirty-five years later, Linux runs on everything from fridges to the servers behind most of the cloud [1]. For some of us in this industry, the anniversary is also a personal one. That hobby turned into careers and companies, and in my own case, into a Linux distribution run out of New Zealand that spent a run of weeks in 2003 at the top of DistroWatch's weekly rankings, a story I told in full earlier in this series.
What it was, why it mattered, what followed. The anniversary itself changed nothing technical; the kernel did not behave differently on 26 August. It mattered because it gave every institution discussed in this special, the European Commission, the French government, Red Hat, Valve, a single shared reference point for a question none of them had been asking out loud: thirty-five years in, who is actually responsible for this thing, and what happens to that responsibility when the person most associated with it is no longer the only one holding it? Thirty-five years is long enough that almost nobody still working on the project remembers a time before it existed, and long enough that an entire generation of engineers, myself among them, built careers inside something that started as one person's side project with no plan to become anything else. The conclave document from January had already started answering that question before the anniversary arrived to make everyone else ask it too, and the two events, read together rather than eight months apart, are really one story: a project old enough to need a succession plan, and a project that wrote one before it was asked to.
On the last day of August, Debian 11, bullseye, reached the end of its supported life after five years. Some of its packages carry on through third-party Extended LTS arrangements, but for most organisations still running it the message was simple: if it is still running, it is now running unsupported [23].
On 16 September, GNOME 51 followed with smoother frame scheduling and offline maps. It also removed support for EGLStreams, an old NVIDIA-specific graphics path that had complicated Linux graphics support for years, and it is the desktop set to ship in Ubuntu 26.10 and Fedora 45 [24].
Five days later, on 21 September, CISA was back. It flagged three Linux kernel flaws under active exploitation, in AF_ALG, ebtables and kernel TLS. One of them, a race condition, had been sitting in the code for about fourteen years [25]. Old code does not become safe by virtue of being old. It becomes familiar, which is a different thing entirely, and familiarity is not a security property.
October: The Rules Change Again
October opened with a correction to April's celebration. Valve's survey for September 2026 put Linux at 3.05 per cent of Steam users, down from the 5.33 per cent recorded in March [26]. The drop came alongside a rise in Simplified Chinese-language responses, which shifts the composition of the whole sample, and CachyOS overtook SteamOS as the most-used Linux distribution in the survey for the first time. Survey shares move with who answers the survey. The trend worth watching is the one that survives a change in who is in the room, and six months is not long enough to know yet which trend this is.
Then, on 13 October, the kernel revisited its own AI rule. Six months after the Assisted-by tag arrived, a patch proposed removing the requirement to disclose AI assistance, after maintainers reportedly reached consensus on the change at the Maintainers Summit in Prague [27]. The human sign-off requirement stays. The disclosure label may not. There is a specific kind of normalisation in that sequence: when a tool stops being unusual, people stop naming it every time they use it, which is exactly what happened to version control systems, to compilers, and now, it seems, to AI-assisted patches.
What it was, why it mattered, what followed. The proposal to drop the Assisted-by tag is not a decision to stop reviewing AI-assisted code; it is a decision to stop tracking, line by line, which code was AI-assisted once a human has already reviewed and signed for all of it regardless. It mattered because it closed a six-month real-world experiment in mandatory AI disclosure with a result nobody had predicted in April: not that the disclosure was too burdensome to keep, but that it had stopped telling anyone anything they did not already assume. A tag that once distinguished one kind of patch from another stops being useful information the moment every patch is assumed to carry it, and that is a judgement about the state of the whole project's working practice, reached by the people doing the work rather than imposed on them. What followed, the next day, was a reminder that the kernel's AI question is one governance experiment among several running at once across the open source world, on wildly different timescales, with different projects reaching different, equally defensible answers to the same underlying question of who is accountable for a line of code nobody typed by hand.
The next day, KDE released Plasma 6.8, with Wayland polish, better multi-monitor and remote desktop support, and a new tool called kscreenctl, in the project's thirtieth year [28]. Two of the great Linux desktop projects, both decades old, both still shipping on a twice-a-year cadence that most commercial software vendors would envy.
And on 15 October, Canonical released Ubuntu 26.10, Stonking Stingray. It ships GNOME 51, a near-final Linux 7.3 kernel, desktop images for RISC-V, and a preview of speech-to-text. It also completed Ubuntu's migration of its core command-line utilities to Rust, the basic commands every Linux user types without thinking about what they are built from [29]. The language that left experimental kernel status in April was, by October, sitting underneath the most ordinary commands on the system.
What it was, why it mattered, what followed. Finishing the coreutils migration is not a headline the way a kernel version number is, but it is the quieter half of the Rust story this special has been tracking since Chapter 2. It mattered because it answered, in practice, the question Linux 7.0's Rust milestone had only answered in principle: does a second systems language actually reach the tools people use every day, or does it stay confined to the parts of the system most users never see? By October, the answer was reaching the command prompt itself. What followed is still unfolding; this special closes before the year does.
What 2026 Actually Meant
Line up ten months of releases, breaches and announcements and three things fall out of it, in the order they arrived across the year.
First, AI stopped being a debate inside open source and became a workload. In January, curl closed its bug bounty because AI-generated reports were drowning its maintainers. By April, the kernel had a written policy for AI-assisted patches, with a human required to sign for every one. By October, maintainers were proposing to drop the disclosure tag that policy had introduced, not because the human sign-off had failed, but because naming the tool every time had stopped adding information. That is not a retreat from scrutiny. It is normalisation. The live question by year's end was no longer whether AI touches a given patch. It is whether a named human still signs for it, which is precisely the question the kernel's own policy was built to answer from the start. A volunteer-run project reached that answer in six months of public argument, in full view of anyone who cared to read the mailing list. Most organisations I work with have not reached it at all, and few of them are arguing about it in public where the reasoning can be checked.
Second, the supply chain is the attack surface, not the kernel itself. Trivy is a security scanner. Axios is a library downloaded four hundred million times a month. Mini Shai-Hulud shipped malware carrying valid build provenance. None of the three attackers needed a kernel exploit to do damage. Each one went after the tools developers and organisations trust to keep them safe, which is a cheaper and more effective target than the operating system underneath it. The kernel itself, across three major releases this year, kept its own development process remarkably boring by comparison: scheduled, on time, argued over in public, occasionally slowed by AI-generated review volume but never derailed by it. The drama of 2026 was almost entirely one layer up, in the dependencies nobody audits every time they update.
Third, open source became a sovereignty decision rather than a procurement line item. France's digital directorate moved its desktops to Linux on stated sovereignty grounds. The European Commission published a strategy that funds maintenance, not only new projects. Set the geopolitics to one side and the signal for any organisation, anywhere, is the same: who controls your software toolchain is now a question a board asks, not a preference an IT department quietly makes on its own. A government that depends on a foreign vendor for its desktop operating system has, in effect, outsourced a decision about its own continuity to a company with no obligation to consult it. A government that depends on an open source project has outsourced the same decision to a community that, as this year showed in January, is at least willing to write down how it would handle losing its own most important person.
Under all three of those sits a quieter story that this special has been following since the first week of January. The kernel wrote a continuity plan for the day Linus Torvalds steps back from leading it, thirty-five years into a project that began as one person's hobby and now plans its own succession in writing. A great many organisations with far more at stake than a hobby project still have not done the same.
The open-source dimension of all this is the one the year itself kept answering without being asked. A continuity document with no company behind it, no board that voted on it and no legal department that drafted it is itself a piece of open governance: a distributed group of maintainers, nobody's employee in the same sense, writing down who decides what happens next because the alternative, silence, was the more dangerous choice. That same instinct, answer the "who decided" question in writing rather than leave it to informal trust, is what a software bill of materials exists to do at the component level rather than the leadership level. The same logic that makes a kernel's succession plan worth having makes a component-level record of who built what worth requiring.
The implication that gets less attention is on the procurement side. The United States National Security Agency and the Cybersecurity and Infrastructure Security Agency, working through the public-private Enduring Security Framework, publish recommended practices for suppliers specifically on managing open source software and software bills of materials, a structured list of every component inside a piece of software [30]. 2026's supply chain attacks on Trivy, Axios and TanStack's own package network are exactly the failure mode that guidance exists to make visible before the fact rather than forensically after it: a compromised dependency sitting unnoticed inside something trusted and widely redistributed. A software bill of materials does not stop an attacker from publishing a bad package. It stops an organisation from finding out, weeks later and by accident, that the bad package was running somewhere it had no idea to look.
So, three questions worth carrying into Monday morning. Who signs off on the AI-assisted code running inside your own systems, and would you be able to name them? Which open source packages, three dependencies down from the ones you can see, would hurt you most if they were quietly poisoned tomorrow? And if a key maintainer, inside your organisation or three dependencies outside it, walked away without warning, who has actually decided what happens next, and is that decision written down anywhere, the way the kernel's now is?
If a maintainer you depend on, inside your organisation or three dependencies down from it, walked away tomorrow, who would actually notice before something broke?
This is one of seven weekly series in The Hamberger Report. Subscribe on LinkedIn and the next one arrives in your feed.
The views expressed in this article are entirely my own, informed by more than 30 years of professional experience in architecture, security, and technology leadership in New Zealand. I write as director of Te Pono Limited; the views are personal and do not represent the position of any client, any government agency, or the New Zealand government. My commentary on legislation and policy is analytical, drawing on publicly available sources and my professional expertise in architecture, security, and AI governance, and it is politically neutral.
About the Author: Andreas Hamberger is a New Zealand-based enterprise architect and technology strategist. Over 30 years, he has moved from compiling kernels on a 486 to leading cloud, cyber, and AI transformation programmes across government, banking, transport, and aviation. He founded Yoper Linux, served as a technology specialist for Novell during the Linux Wars, and is the author of "Generative AI: Skynet or Heaven" and "Space Mafia." He can be reached at andreas@thehambergerreport.com.
This article was produced with AI assistance under my direction. Research, drafting and images pass through a pipeline I built and govern: automated gates for source verification, forbidden language and political neutrality, and my own review before anything is published. The tools include Claude, Gemini and Openart. The frameworks, arguments and editorial judgements are mine and are the same discipline I apply to the AI systems I audit for clients. AI accelerated the work; the thinking, and the responsibility for it, are mine.
[1] Linux Magazine. "Roll Out the Cake: Linux Turns 35." 25 August 2026. https://www.linux-magazine.com/Online/News/Roll-Out-the-Cake-Linux-Turns-35
[2] KitGuru. "SteamOS Propels Linux to Record 5.33% Share in Latest Steam Survey." 3 April 2026. https://www.kitguru.net/gaming/joao-silva/steamos-propels-linux-to-record-5-33-share-in-latest-steam-survey/
[3] Open Source For You. "EU Plans to Scale Open Source into Commercial Rivals to US Technology." 8 January 2026. https://www.opensourceforu.com/2026/01/eu-plans-to-scale-open-source-into-commercial-rivals-to-us-technology/
[4] The Register. "curl Ends Bug Bounty." 21 January 2026. https://www.theregister.com/2026/01/21/curl_ends_bug_bounty/
[5] The Register. "Linux Continuity Plan." 27 January 2026. https://www.theregister.com/2026/01/27/linux_continuity_plan/
[6] Phoronix. "Linux 6.19 Released." 8 February 2026. https://www.phoronix.com/news/Linux-6.19-Released
[7] The Register. "GNOME 50." 19 March 2026. https://www.theregister.com/2026/03/19/gnome_50/
[8] BleepingComputer. "Trivy Vulnerability Scanner Breach Pushed Infostealer via GitHub Actions." 21 March 2026. https://www.bleepingcomputer.com/news/security/trivy-vulnerability-scanner-breach-pushed-infostealer-via-github-actions/
[9] Dark Reading. "Axios npm Package Compromised: Precision Attack." 31 March 2026. https://www.darkreading.com/application-security/axios-npm-package-compromised-precision-attack
[10] The Register. "France Tech Sovereignty Plan." 13 April 2026. https://www.theregister.com/2026/04/13/france_tech_sovereignty_plan/
[11] The Register. "Linux Kernel 7 Released." 13 April 2026. https://www.theregister.com/2026/04/13/linux_kernel_7_releaseed/
[12] It's FOSS. "Linux AI Coding Assistants Policy." 13 April 2026. https://itsfoss.com/news/linux-ai-coding-assistants-policy/
[13] Ubuntu Discourse (Canonical). "Ubuntu 26.04 Resolute Raccoon LTS Released." 23 April 2026. https://discourse.ubuntu.com/t/ubuntu-26-04-resolute-raccoon-lts-released/80833
[14] Phoronix. "Fedora 44 Released." 28 April 2026. https://www.phoronix.com/news/Fedora-44-Released
[15] The Hacker News. "CISA Adds Actively Exploited Linux Root Flaw." 3 May 2026. https://thehackernews.com/2026/05/cisa-adds-actively-exploited-linux-root.html
[16] StepSecurity. "Mini Shai-Hulud Is Back: A Self-Spreading Supply Chain Attack Hits the npm Ecosystem." 11 May 2026. https://www.stepsecurity.io/blog/mini-shai-hulud-is-back-a-self-spreading-supply-chain-attack-hits-the-npm-ecosystem
[17] Phoronix. "Red Hat RHEL 10.2, RHEL 9.8." 20 May 2026. https://www.phoronix.com/news/Red-Hat-RHEL-10.2-RHEL-9.8
[18] Osborne Clarke. "New EU Open Source Strategy: Europe's Path to Digital Sovereignty Through Open Technologies." 3 June 2026. https://www.osborneclarke.com/insights/new-eu-open-source-strategy-europes-path-digital-sovereignty-through-open-technologies
[19] Phoronix. "Linux 7.1 Released." 14 June 2026. https://www.phoronix.com/news/linux-7.1-released
[20] Engadget. "Valve Steam Machine Starts at $1,049 with 512GB Storage and No Controller." 22 June 2026. https://www.engadget.com/2199144/valve-steam-machine-starts-at-1049-with-512gb-storage-and-no-controller/
[21] Debian Project. Debian 12 Moves to Long Term Support. 12 July 2026. https://www.debian.org/News/2026/20260712
[22] Phoronix. "Linux 7.2 Released." 16 August 2026. https://www.phoronix.com/news/Linux-7.2-Released
[23] Debian Project. Debian 11 Reaches End of Life. 31 August 2026. https://www.debian.org/News/2026/20260831
[24] Phoronix. "GNOME 51 Released." 16 September 2026. https://www.phoronix.com/news/GNOME-51-Released
[25] BleepingComputer. "CISA Alerts of Active Exploitation of Three Linux Kernel Flaws." 21 September 2026. https://www.bleepingcomputer.com/news/security/cisa-alerts-of-active-exploitation-of-three-linux-kernel-flaws/
[26] GamingOnLinux. "Steam Survey for September 2026 Shows a Drop in Linux, with Simplified Chinese Rising." 2 October 2026. https://www.gamingonlinux.com/2026/10/steam-survey-for-september-2026-shows-a-drop-in-linux-with-simplified-chinese-rising/
[27] Phoronix. "Linux Dropping Assisted-By Requirement." 13 October 2026. https://phoronix.com/news/Linux-Dropping-Assisted-By-Req
[28] Phoronix. "KDE Plasma 6.8 Released." 14 October 2026. https://www.phoronix.com/news/KDE-Plasma-6.8-Released
[29] Phoronix. "Ubuntu 26.10 Released." 15 October 2026. https://www.phoronix.com/news/Ubuntu-26.10-Released
[30] Enduring Security Framework (US National Security Agency, Cybersecurity and Infrastructure Security Agency and partners). "Securing the Software Supply Chain: Recommended Practices for Managing Open Source Software and Software Bill of Materials." Published via CISA, document dated December 2023. https://www.cisa.gov/sites/default/files/2023-12/ESF_SECURING_THE_SOFTWARE_SUPPLY_CHAIN%20RECOMMENDED%20PRACTICES%20FOR%20MANAGING%20OPEN%20SOURCE%20SOFTWARE%20AND%20SOFTWARE%20BILL%20OF%20MATERIALS.pdf