GitHub has been struggling with service availability in recent months as traffic on the platform has surged, driven in large part by AI-assisted coding and agentic development workflows. The code-sharing site has been trying to address those issues by expanding capacity and migrating more workloads to Azure infrastructure, but reliability remains uneven. In the May 2026 GitHub Availability Report, GitHub acknowledges nine incidents that degraded performance, one fewer than its April report. That's something. But Jakub Oleksy, SVP of software engineering at GitHub, says there's more to be done. "We are making structural changes that permanently remove failure modes," he said in the report. "We acknowledge that we have work to do, but we’re committed to getting it done and making GitHub reliable when and where you need it." Microsoft’s code hosting site also briefly halted new Copilot subscriptions to reduce the cost impact of its AI services and to adjust its Copilot pricing to account for shifting model provider policies. As noted in an April post, GitHub had planned to increase its capacity by 10x back in October 2025, but by February 2026 it had become evident that a 30x expansion would be needed to accommodate the surge of pull requests, commits, and new repos. Last year, GitHub reportedly handled 1 billion commits for the entire year. Now it receives 1.4 billion commits every month. “We’re now serving 40 percent of monolith traffic from Azure (up from 8 percent in February), with Git traffic at 30 percent and repository replication at 99 percent,” said Oleksy. “We’ve more than doubled our effective capacity in four months.” Oleksy notes that efforts to isolate GitHub’s primary database cluster by moving users, authentication, and authorization into separate domains should prevent failures that cascade across the system. That hasn’t quite solved GitHub’s ongoing availability challenges, in part because Azure has also confronted capacity problems recently. There were nine incidents in May compared to 10 incidents in April. And June is on pace for a similar number. The Missing GitHub Status Page, an unofficial project to track GitHub service problems, counts 12 incidents in May and reports uptime over the past 90 days at 87.26 percent. By month, the project puts GitHub availability at 78.33 percent in April, 93.86 percent in May, and 88.39 percent for June so far. GitHub's Official Status Page presents a far more flattering view of availability, with uptime figures mostly around 99.9 percent for the listed services. These figures depend upon what gets counted and the duration of the disruption. GitHub’s own incident history page cites 26 incidents in April, 23 in May, and 12 to date in June. ®

MX Linux 25.2 is here, now with kernel 7.0 if you choose – although the Raspberry Pi edition still needs some work. MX Linux has been quietly turning into one of the Reg FOSS desk’s favorite distros for a few years now. It has a number of desirable attributes, and with version 25.2 released late last month, some of the slightly bumpier parts of the major upgrade to version 25 are getting smoothed out. We looked at MX Linux 25 in November last year, and reported that one of the niftiest features in previous versions had been lost. In MX 23 and before, you could choose which init system the OS used every time it booted up: so, for instance, you could normally run with the classic sysvinit, but if you needed to install something which demanded systemd, you could temporarily boot up with systemd as the init, install your app, and then switch back. In our testing, we’ve found that some things require Agent P’s Swiss Army Knife of a “System and Service Manager” to install, but once they’re in place on your computer, they will run quite happily without it. Alternatively, if it’s something you only occasionally run, you can start up with systemd only when you need it. The way that MX Linux did this no longer works on kernel 6.12 or above. So, in order to continue to offer a choice of inits at all, MX 25.0 made you choose at install time: either pick the systemd version, or the sysvinit version. (And if you wanted KDE Plasma, it was only available in systemd form.) MX Linux 25.1 fixed that with a new, different, switchable-init system. However, that made upgrading from 23 to 25 tricky, and after we tried it, the OS still worked, but the handy suite of MX Tools didn’t. These aren’t essential, but they significantly facilitate common adjustments and tweaks such as installing extra external apps, switching repositories and mirrors, managing kernel versions, installing additional device drivers such as the eternally problematic Nvidia drivers, and much more. They’re one of the distro’s key advantages, and well worth having. We dug out the machine in our test fleet, which runs MX, and tried the option in the installation program that installs over the top of an existing copy of MX. It worked fine, with some caveats: it’s not quite as capable as Ubuntu’s in-place reinstall, which spares your home directory while reinstalling the OS around it. MX simply overwrites the old OS; it doesn’t pick up any config from it – but it’s quicker and easier than custom partitioning. We had to re-enable our swap partition, and add a user account that matched the old one, but everything worked fine. With the MX Tools, it was fast and easy to choose local repositories for updates, and reinstall some handy proprietary apps such as Google Chrome and Slack. The distro comes with Flatpak preinstalled, and we used that to install Gear Lever to make it easier to reinstall Panwriter. The new MX Linux version 25.2 optionally includes the new kernel 7.0, from the Liquorix project that we looked at in 2022. For the Xfce edition, you can choose the normal edition, with a Debian kernel, or the AHS edition with the newer kernel. The KDE edition only comes in AHS form, and the lightweight Fluxbox edition for low-end kit only offers the Debian kernel. There are any number of Debian and Ubuntu based remixes and meta-distributions out there, but MX Linux is perhaps the single most user-friendly distro we’ve seen that isn’t based on systemd. It’s fast, lightweight, and much easier to get configured and installed than Devuan, or even than Debian itself. It also has better tools for adjustment and customization than any member of the Ubuntu or Debian family, and rivals the best Arch Linux-based distros such as Garuda Linux. As we reported from the Ubuntu Summit, Canonical is beginning a push into AI. Since then, the roadmap for Ubuntu 26.10 “Stonking Stingray” has been published, including what it calls a Context-aware desktop – powered by LLMs. Similar changes have already come to Linux Lite 8.0, which is based on Ubuntu 26.04. This too bundles a local LLM for all your error-filled artificial-plagiarism needs. We suspect that such developments may yet drive a small exodus of Ubuntu users – and if you also want to get away from systemd at the same time, then MX Linux is an excellent place to start. Bootnote: MX Linux on the Raspberry Pi Finally, version 25.2 sees the Raspberry Pi respin updated to the new base OS. Until 25.2, the Pi version was still on MX version 22. As this rather outdated description says, this is a separate edition of MX Linux with Xfce, but built in part from the packages in the Raspberry Pi OS rather than directly from Debian – so it looks and works like MX, but is compatible with most Pis and most apps for PiOS. For instance, the Pi configuration commands, and EEPROM updater, work fine on MX on the Pi, but they don’t on (for instance) Alpine Linux. We tried MX Linux 24.2 for the Raspberry Pi on both 4 GB and 8 GB Pi 5 machines and on a Pi 4, but it wouldn’t get past the splash screen for us – but the previous release worked very well, so once it’s received a little more TLC, this could turn out to be a good option for Pi users wanting a more configurable desktop OS. ®