Why Installing Linux on a MacBook Reveals a

A content creator recently spent nearly 30 minutes documenting their attempt to install Ubuntu on an older Intel MacBook. The video, posted by the channel Bog, was supposed to be about reviving aging hardware with lighter-weight software. Instead, it became an unintentional demonstration of how proprietary hardware design creates friction that shouldn't exist—and raises questions about whether current regulations adequately address the barriers device manufacturers build into their products.

The premise seemed reasonable: take a slowing MacBook, install Linux, gain performance. "Linux is known to be less bloated and faster, especially on older laptops," the creator notes at the outset. This isn't controversial. It's the documented experience of users worldwide who've extended hardware life by switching operating systems. What followed, however, was a cascade of compatibility failures that turned a straightforward installation into a multi-day ordeal.

The Technical Breakdown

The problems began immediately. After partitioning the drive and creating a bootable USB using standard tools (first Rufus, then Balena Etcher), the creator couldn't get the MacBook to recognize the installation media. The issue: Apple's Secure Boot had to be disabled entirely—"no security, which does not enforce any requirements on bootable OSs"—before the system would even acknowledge the USB drive existed.

Then came the hardware recognition failures. After successfully installing Ubuntu 24.04 LTS, the built-in keyboard didn't work. The trackpad didn't work. Wi-Fi didn't work. The creator had to juggle external peripherals—constantly swapping a single USB cable between keyboard and mouse—just to navigate the desktop environment.

"There's no way an average person would ever set this up," the creator observed after hours of troubleshooting. "I've installed Linux before and I'm having massive trouble."

The root cause: Apple's T2 security chip, introduced in 2018 Intel Macs, uses proprietary drivers that aren't included in standard Linux distributions. Getting basic functionality required:

Tethering an iPhone for internet access (Android instructions were readily available; iOS steps were not)
Downloading firmware extraction scripts from a community project called T2Linux
Running these scripts on macOS to extract firmware
Transferring files via USB to Linux
Running the scripts again in Ubuntu
Debugging when the Wi-Fi "magically stops working"

Eventually, the creator discovered that T2Linux offers modified Ubuntu ISOs with the necessary drivers pre-installed. This would have saved roughly two days. The information existed—scattered across forums, GitHub repositories, and community wikis—but wasn't discoverable through normal channels.

The Regulatory Silence

This isn't a story about poor documentation or user error. It's about design choices that create vendor lock-in through hardware incompatibility. Apple built a chip that serves legitimate security functions, then made the drivers needed to use standard hardware features—keyboard, trackpad, Wi-Fi—unavailable to alternative operating systems.

Current regulatory frameworks don't address this effectively. The Digital Markets Act in the EU targets software gatekeepers. Right-to-repair laws focus on physical repairs and parts availability. Neither directly confronts the question: should manufacturers be able to design hardware that effectively blocks users from installing alternative operating systems, even when that hardware is technically capable of running them?

The Federal Trade Commission has authority under Section 5 of the FTC Act to address unfair methods of competition. The Department of Justice Antitrust Division could theoretically examine whether these practices constitute anticompetitive tying. But no enforcement action has emerged targeting hardware-level OS restrictions.

Meanwhile, the burden falls entirely on community volunteers. The T2Linux project exists because enthusiasts reverse-engineered Apple's firmware and created workarounds. They did the labor that Apple could have done—providing drivers or at minimum documentation—at no cost to users. This model works until it doesn't. Projects get abandoned. Maintainers burn out. New hardware iterations require new reverse-engineering.

The Broader Pattern

Apple isn't unique here. Microsoft's Pluton security processor, now shipping in some Windows PCs, raises similar concerns. ARM-based devices often ship with locked bootloaders. The pattern is consistent: security features that happen to make alternative operating systems harder to install.

Manufacturers argue these measures protect users. Secure Boot prevents rootkits. Firmware validation prevents tampering. These aren't unreasonable positions. But the technical requirements for security don't mandate making Linux installation this difficult. Other manufacturers support both secure boot and Linux installation. The UEFI specification includes provisions for this.

The question regulators haven't grappled with: at what point does security implementation become a pretext for lock-in? How do you distinguish legitimate security architecture from anticompetitive design?

The European Commission's proposed regulation on interoperability requirements under the Digital Markets Act gets partway there—it could require designated gatekeepers to ensure operating system interoperability. But it applies only to the largest platforms. It wouldn't cover a scenario like T2 chip driver availability because Apple isn't (yet) designated as a gatekeeper in personal computer operating systems.

What's Missing

Three regulatory gaps emerge from this episode:

First, no requirement that manufacturers provide drivers or technical documentation for alternative operating systems when those systems could reasonably run on the hardware. The T2 chip works fine with Linux—once you have the right drivers. Apple possesses those drivers. They choose not to distribute them.

Second, no prohibition on security measures that disproportionately burden alternative OS installation relative to the security benefit provided. Secure Boot can work with Linux. Apple's implementation makes it harder than necessary.

Third, no recognition that relying entirely on volunteer reverse-engineering creates fragile infrastructure. When basic hardware functionality depends on unpaid hobbyists maintaining compatibility patches, that's a market failure masquerading as user choice.

The creator's final observation crystallizes the issue: "I think I should just do that. It's great that I've wasted two days trying to get this to work." Two days to install an operating system on hardware that technically supports it. Not because the hardware can't run Linux. Because the manufacturer designed it not to, absent significant user effort.

That's not security architecture. That's a business model—one that current regulations don't adequately address.

—Samira Okonkwo-Barnes