David Timothy

Posted on Sep 6

Windows Is Getting Worse. So Why Does Linux Still Suck in 2026?

#ai #programming #opensource #linux

It is 2026, Windows is becoming increasingly hostile to people who just want a predictable computer, and Linux still cannot close the deal.

That is absurd.

Windows 10 reached the end of normal support on October 14, 2025. Microsoft’s preferred answer is Windows 11, an operating system that increasingly feels like a delivery platform for Microsoft accounts, OneDrive, Copilot, recommendations, telemetry, subscriptions, and whatever AI feature was approved during last Tuesday’s product meeting.

Microsoft has openly described its goal as making every Windows 11 PC an AI PC.

Fine. Great. Wonderful.

But what if I do not want an AI PC?

What if I just want an operating system that launches applications, manages files, drives my hardware, stays out of the way, and does not treat every empty surface as an opportunity to recommend another Microsoft product?

This should be Linux’s moment.

Windows users are annoyed. Developers are tired of being nudged toward cloud accounts and ecosystem integrations. Power users are spending more time disabling things they never requested. Microsoft keeps adding layers to an operating system that already contains multiple generations of UI, configuration tools, compatibility systems, and historical baggage.

Linux should be standing there with a clean desktop, excellent hardware support, reliable applications, and a simple migration story.

Instead, it is standing there holding five package formats and asking which display server I use.

Windows is becoming the operating system nobody asked for

Windows is still extremely capable. That is part of what makes its current direction so frustrating.

It runs practically every mainstream desktop application. Hardware manufacturers target it first. Drivers generally arrive through a coordinated distribution channel. Gaming support is excellent. Development tooling is strong, and WSL gives developers a real Linux environment without leaving Windows.

The foundation is not the problem.

The problem is that Microsoft seems incapable of leaving the foundation alone.

Windows 11 increasingly wants to be involved in everything. It wants to connect your account, back up your folders to OneDrive, personalize recommendations, track application launches to improve Start, assign an advertising identifier, suggest content in Settings, and place Copilot at the center of the experience.

Many of these features can be disabled. Some are opt-in. Some have reasonable technical justifications. Recall, for example, now requires users to opt in, stores snapshots locally, encrypts its data, and uses Windows Hello protection.

That matters. Criticism should be accurate.

But the broader direction still sucks.

The problem is not that every individual feature is secretly evil. The problem is that the operating system has stopped acting like neutral infrastructure. It is becoming an opinionated client for Microsoft’s services.

Even the initial setup process makes the relationship clear. Windows 11 Home and Windows 11 Pro for personal use require internet connectivity and a Microsoft account during initial setup. Windows Backup is centered around that account and OneDrive. Device usage settings can influence the tips, recommendations, offers, and personalized ads shown to users.

You bought a computer. Microsoft sees an onboarding opportunity.

There is a difference between an operating system supporting cloud services and an operating system constantly trying to turn local computing into an extension of a cloud account. Windows keeps drifting toward the second model.

Developers notice this because developers tend to care about ownership, reproducibility, configuration, and boundaries. We know what a local file is. We know what a background service is. We know that “personalization” usually means data collection followed by somebody trying to sell us something.

We also know how ridiculous it is to buy a powerful machine and then spend the first hour removing widgets, disabling suggestions, rejecting cloud backup, changing privacy settings, uninstalling bundled applications, and making the Start menu less annoying.

The usual response is that power users can configure Windows however they want.

That misses the point.

A good operating system should not require a cleanup script before it becomes tolerable.

Linux should win this argument without trying

On paper, Linux is almost comically well positioned.

It is open source. It can run without a mandatory cloud account. It does not need an advertising identifier. It gives users meaningful control over updates, services, filesystems, networking, security, and the entire software stack.

For developers, the underlying environment is fantastic.

Package managers are scriptable. Containers fit naturally. SSH is normal rather than an optional feature somebody remembered to add. Filesystem behavior is predictable. Most deployment targets are already Linux. The shell is not treated like an embarrassing historical utility hidden behind a graphical interface.

Linux is also technically mature in ways that are easy to underestimate. The kernel supports an enormous range of hardware and workloads. Linux runs servers, cloud infrastructure, supercomputers, embedded systems, routers, phones, appliances, and a disturbing number of devices whose owners have no idea Linux is inside them.

This is not a toy operating system.

And yet the Linux desktop still feels like a collection of impressive components that occasionally agree to impersonate a product.

That is the gap.

Linux is technically powerful. A Linux desktop can be excellent. Neither statement means Linux is a genuinely great mainstream desktop operating system.

There is no Linux desktop

People talk about “the Linux desktop” as if it were one thing.

It is not.

Is the Linux desktop Ubuntu with GNOME and Snap?

Is it Fedora Workstation with GNOME, RPM, DNF, and Flatpak?

Is it Kubuntu with KDE Plasma?

Is it Linux Mint with Cinnamon?

Is it Arch with whatever the user assembled at 2:00 in the morning after reading six wiki pages?

Is it an immutable Fedora variant using image-based system updates, Flatpak applications, and containers for development tools?

These systems share a kernel and a lot of userspace technology, but that does not make them one desktop platform.

A Windows application developer targets Windows. A macOS application developer targets macOS. A Linux application developer targets a decision tree.

Which distributions?

Which versions?

Which package formats?

Which desktop environments?

Which display protocols?

Which portal implementations?

Which versions of system libraries?

Which filesystem layout assumptions?

Which sandbox permissions?

Which theme behavior?

Which installer story?

Linux supporters often call this choice.

Application developers call it support cost.

That distinction matters because fragmentation does not merely affect enthusiasts choosing a distribution. It affects every company deciding whether Linux desktop support is worth funding.

Adobe’s Creative Cloud desktop application still officially targets Windows and macOS, not Linux. That is not because Linux is technically incapable of editing an image. It is because “support Linux” means taking responsibility for a fragmented platform with a relatively small desktop market.

Linux users then blame Adobe, sometimes correctly, for refusing to support Linux. Adobe can blame the market and platform complexity. Distribution maintainers can say proprietary applications should use Flatpak. Flatpak developers can point to portals and sandboxing. Desktop projects can implement different portal backends.

Everyone has a technically defensible explanation.

The user still does not have Photoshop.

Choice becomes a tax when nobody owns the final experience

Choice is one of Linux’s greatest strengths. It is also one of the main reasons Linux has not produced an obvious Windows replacement.

Those two ideas are not contradictory.

Choice is excellent when I am intentionally building a system around my requirements. It is less excellent when I am trying to install an application and the official instructions begin with “Select your distribution.”

Even basic software installation can involve several parallel systems:

# Debian or Ubuntu
sudo apt install vlc

# Fedora
sudo dnf install vlc

# Arch Linux
sudo pacman -S vlc

# Flatpak
flatpak install flathub org.videolan.VLC

# Snap
sudo snap install vlc

A Linux enthusiast sees flexibility.

A normal user sees five answers to a one-answer question.

The commands are not the real problem. Most users can click an Install button in a graphical software center. The deeper issue is that these methods have different maintainers, update behavior, sandbox rules, integration details, permissions, dependency models, and failure modes.

Install the repository package and it may be old.

Install a third-party repository and now that repository participates in system updates.

Install a Flatpak and filesystem access may behave differently because the application is sandboxed.

Install a Snap and startup, theming, integration, or policy decisions may differ from the native package.

Download an AppImage and updates become the application’s problem.

Build from source and congratulations, you are now part of the package management system.

Flatpak is probably the closest thing Linux has to a credible cross-distribution desktop application model. Its runtimes, repositories, sandboxing, and portals solve real problems.

They also reveal how complicated the Linux desktop is.

XDG Desktop Portal exists partly because a sandboxed application needs a common way to request files, open links, print documents, capture screens, send notifications, and interact with the host desktop. The portal then relies on desktop-specific backends for GNOME, KDE, LXQt, wlroots, Cinnamon, and others.

That is smart engineering. It is also a compatibility layer designed to make several different desktops behave enough like one platform.

Linux keeps building infrastructure to compensate for the fact that nobody controls the whole experience.

Desktop environments are products built on shifting ground

GNOME and KDE Plasma are both serious desktop environments. They are not amateur projects stapled to a terminal. Both can provide attractive, productive, modern systems.

They also have different design philosophies, release schedules, extension models, configuration systems, default applications, and approaches to user customization.

GNOME tends to have strong opinions about how the desktop should work. KDE tends to expose enough settings to let users negotiate a peace treaty with every pixel.

Neither approach is inherently wrong.

The problem is that application behavior and integration can still depend on which environment is running underneath. File pickers, notifications, global shortcuts, screen sharing, theming, tray icons, window decorations, fractional scaling, and default application behavior can vary.

Standards exist. Freedesktop.org has spent years producing specifications for interoperability between desktop environments.

But it is not a formal standards body, and projects are not required to implement every specification.

That sentence explains a significant chunk of the Linux desktop experience.

There is a specification. Implementation varies. Your distribution packages a particular version. Your desktop environment supports most of it. Your application toolkit handles some of it. A portal handles another part. A compositor-specific protocol handles something else.

When it works, it is invisible.

When it does not, the user ends up searching for an issue containing the words “Wayland,” “portal,” “PipeWire,” “GTK,” “Qt,” and “environment variable.”

This is not what an obvious Windows alternative looks like.

Hardware support is excellent until it suddenly isn’t

Linux hardware support has improved enormously. On the right machine, installation can be almost boring. The kernel already contains drivers, the installer detects the hardware, Wi-Fi works, audio works, suspend works, and the desktop appears.

That is the good version.

The bad version is one component that technically works but not quite correctly.

Maybe suspend drains the battery.

Maybe the fingerprint reader is unsupported.

Maybe the webcam’s advanced features require vendor software available only on Windows.

Maybe switching between integrated and discrete graphics is awkward.

Maybe an external monitor behaves strangely after sleep.

Maybe the function keys do not map correctly.

Maybe the Wi-Fi chipset needs newer firmware than the distribution shipped.

Maybe the machine boots and runs perfectly, except the microphone array sounds terrible because the vendor’s audio processing stack only exists for Windows.

This is where Linux’s huge hardware support story becomes misleading.

Supporting a hardware device is not always the same thing as supporting the complete product experience.

A laptop is not just a CPU, GPU, storage device, and generic keyboard. It includes firmware, power management, thermal profiles, biometric devices, camera processing, audio tuning, docking behavior, special buttons, GPU switching, and vendor-specific quirks.

Windows benefits from an established hardware certification and driver distribution system. Manufacturers design, test, certify, and distribute Windows drivers through infrastructure built for that purpose.

Linux support often depends on drivers reaching the upstream kernel, firmware being redistributable, vendors participating in projects such as the Linux Vendor Firmware Service, and distributions shipping compatible versions at the right time.

The upstream kernel model has major advantages. A driver in the main kernel tree can be maintained alongside kernel changes. That is usually better than leaving users dependent on an abandoned binary blob.

But it also means out-of-tree drivers live a dangerous life. Linux intentionally does not promise a stable internal kernel interface for drivers. If a proprietary or external module is not kept current, a kernel update can expose the problem.

The usual advice is to buy hardware known to work with Linux.

That is sensible advice.

It is also an admission that Linux is not a drop-in alternative for the general PC market.

An operating system cannot become the default escape route from Windows if the migration checklist starts with researching whether the laptop’s sleep behavior is broken.

NVIDIA is not the whole hardware problem

Linux desktop discussions have spent years using NVIDIA as shorthand for every driver problem.

That is too simple now.

NVIDIA’s Linux support has changed significantly, and the company has increased its participation in Linux firmware infrastructure. AMD and Intel graphics can also provide excellent experiences. Modern distributions automate much more of the setup than they used to.

Still, graphics on Linux demonstrates the broader platform problem.

The user is not merely choosing a GPU. The final result can depend on the kernel, Mesa version, proprietary driver version, distribution packaging, display server, compositor, laptop GPU topology, firmware, and application.

When something goes wrong, every layer has just enough responsibility to make diagnosis annoying.

Windows has complicated graphics architecture too. The difference is that users usually experience it as one supported vendor path: install the vendor’s Windows driver or let Windows Update do it.

On Linux, the technically correct solution may depend on whether the driver is in the kernel, distributed as a package, built through DKMS, bundled in the distribution, delivered by a third-party repository, or waiting for a newer kernel.

That complexity is manageable for experienced users.

“Manageable for experienced users” is not the standard Linux needs to meet.

Linux gaming is a miracle, not a guarantee

Gaming on Linux is dramatically better than it used to be.

Valve deserves a ridiculous amount of credit for that. Proton allows many Windows-only games to run on Linux through Wine and a stack of related compatibility components. Steam’s Linux runtime also reduces distribution differences by running games against controlled runtime environments.

This is impressive engineering.

It is also worth noticing what had to happen.

Linux did not win broad native game support. Instead, Valve built increasingly sophisticated infrastructure to run Windows games and isolate them from differences between Linux distributions.

Again, Linux’s biggest desktop success stories often involve building a stable platform on top of the unstable boundaries beneath it.

Many games now work with almost no effort. Some run surprisingly well. But compatibility still depends on the game, graphics drivers, Proton version, launchers, copy protection, middleware, anti-cheat systems, and updates from publishers that may never test Linux.

A game working today through a compatibility layer is not the same promise as the publisher officially supporting the platform.

For some users, current Linux gaming support is more than enough. For others, one incompatible multiplayer game or peripheral utility makes the entire migration impossible.

That last ten percent matters.

Desktop operating systems are not evaluated by averaging every feature. They are evaluated by the one required thing that does not work.

Application compatibility is still the wall

Developers can do a huge amount on Linux.

The major browsers are available. Editors such as Visual Studio Code have Linux versions. JetBrains supports Linux. Container tooling is excellent. Git, compilers, language runtimes, databases, terminals, and infrastructure tools are at home there.

If someone’s work happens entirely in a browser, terminal, editor, and containers, Linux can be a fantastic development machine.

But developers do not use their computers only for compiling code.

They join video calls. They edit documents sent by clients. They use VPN software selected by an employer. They configure mice, keyboards, audio interfaces, capture cards, and other peripherals. They run design tools. They test commercial desktop applications. They interact with corporate security software.

This is where “there is an open-source alternative” becomes an inadequate answer.

An alternative application is not necessarily compatible with a required workflow.

GIMP existing does not make it Photoshop.

LibreOffice opening a document does not guarantee perfect behavior with a complex Microsoft Office workflow.

A browser version of an application is not always equivalent to the native desktop version.

Wine successfully launching an application does not turn it into an officially supported application.

The Linux community often responds to missing software by arguing that users should change software.

Sometimes that is reasonable. Sometimes the alternative is genuinely better.

But it is not a migration strategy.

A real desktop alternative has to adapt to users before demanding that users adapt to it.

Linux configuration is freedom with an invoice attached

Linux gives users extraordinary control.

That freedom has a cost, and the Linux community is often weirdly reluctant to admit it.

Configuration is not free just because it does not cost money. It costs time, attention, and cognitive energy.

The ability to replace a compositor, rebuild a package, override a systemd unit, patch a kernel parameter, select a different scheduler, or change the entire desktop environment is valuable.

It is not a substitute for good defaults.

There is a persistent idea that Linux problems are acceptable because they are fixable. If the fix exists in a wiki, forum post, configuration file, or shell command, then apparently the operating system has done its job.

No.

An operating system that requires users to discover and apply the fix is still providing a worse experience than one that works correctly by default.

The command might be trivial:

sudo systemctl enable --now some-service

But the user first has to know:

Which service is missing.
Why it is not running.
What package provides it.
Whether enabling it is appropriate for the distribution.
Whether the advice applies to the current release.
Whether the command creates a security or maintenance problem later.

The command is the easy part.

Knowing that the command is necessary is the product failure.

Stability depends on which Linux you mean

Linux can be extremely stable.

Linux can also turn a routine update into an educational weekend.

Both statements are true because “Linux” covers systems with completely different update philosophies.

An enterprise distribution may preserve older package versions and backport fixes for years. An LTS desktop distribution may prioritize stability but ship older applications. A rolling-release distribution may provide newer kernels, drivers, and desktops while exposing users to more frequent integration changes.

Immutable and image-based distributions try to improve this situation. Atomic updates, rollback support, containerized development environments, and Flatpak applications create cleaner boundaries between the base operating system and user software.

This is promising. It may be the most credible direction for a dependable Linux desktop.

It also adds another model users and developers need to understand.

Should a development tool be installed as a native package, layered onto the system image, run inside a container, installed through a language version manager, or downloaded as a standalone binary?

There are good technical answers.

There are several of them.

Windows users may hate the registry, installer leftovers, and random background updaters. Linux users get to debate the architectural purity of six different installation methods.

Nobody wins.

WSL is a devastating argument against desktop Linux

WSL might be Microsoft’s best developer feature and Linux desktop’s most embarrassing competitor.

With one command, Windows can install a real Linux environment:

wsl --install

Developers can run Bash, Linux binaries, package managers, databases, containers, language toolchains, and even Linux GUI applications while keeping Windows hardware support and commercial software compatibility.

WSL has trade-offs. File placement matters because crossing between Windows and Linux filesystems can hurt I/O performance. Networking, permissions, virtualization, and tool integration can still introduce complexity.

But the value proposition is brutally effective:

Keep Windows for the desktop. Use Linux for the parts Linux is good at.

That arrangement removes one of the strongest reasons developers once had to move entirely to Linux.

It also exposes the uncomfortable truth at the center of this whole argument.

Linux has won development infrastructure. It has not won the desktop.

Microsoft understood that developers wanted Linux tools more than they necessarily wanted a Linux desktop. So Microsoft brought the tools into Windows.

That was a smarter product decision than waiting for everyone to switch operating systems.

The Linux desktop does not have an engineering problem

Linux desktop projects contain plenty of strong engineers.

The problem is product ownership.

No single organization owns the complete Linux desktop experience across hardware, drivers, firmware, installation, updates, applications, packaging, support, documentation, and long-term compatibility.

Canonical owns Ubuntu, not Linux.

Red Hat and the Fedora community shape Fedora, not Linux.

Valve controls SteamOS on selected hardware, not the general-purpose Linux desktop.

GNOME controls GNOME.

KDE controls KDE Plasma.

The kernel community controls the kernel.

Hardware vendors control their firmware.

Application vendors decide which distributions, package formats, and environments they will support.

Freedesktop.org defines interoperability specifications, but it cannot force universal implementation.

Everybody owns a piece. Nobody owns the result.

Windows has plenty of organizational dysfunction, but Microsoft can decide what Windows is. It can define a driver model, ship an SDK, certify hardware, distribute updates, establish UI APIs, and tell application developers what platform they are targeting.

Apple takes this even further by controlling the operating system, hardware, processor roadmap, major frameworks, application distribution, and much of the ecosystem.

Linux has coordination rather than control.

That model is fantastic for open infrastructure. It is much harder for a consumer desktop product, where thousands of tiny integration details determine whether the system feels coherent.

SteamOS proves Linux works when somebody actually curates it

The success of Linux in tightly controlled products should tell us something.

Linux works extremely well when someone defines the hardware, controls the system image, chooses the update model, establishes the application runtime, tests the complete product, and limits the number of supported configurations.

That is why Linux succeeds in servers, appliances, embedded devices, Android phones, Chromebooks, and game consoles.

The kernel is not the problem.

The endless matrix is the problem.

A curated Linux desktop running on certified hardware can be excellent. The manufacturer can validate suspend, graphics, audio, firmware updates, input devices, power management, and recovery. The distribution can ship one desktop environment, one application format, one update mechanism, and one support path.

But that stops looking like the traditional Linux desktop dream, where users freely combine distributions, desktops, kernels, package sources, filesystems, and hardware.

The freedom remains possible underneath. It just cannot define the default product.

Linux does not need fewer possibilities.

It needs one boring, dependable path through them.

We need a Linux desktop that is willing to be a product

The obvious response is to recommend a beginner-friendly distribution.

That helps, but it does not solve the ecosystem problem.

A polished installer and pleasant desktop theme cannot fix missing commercial applications, inconsistent vendor support, packaging fragmentation, or the absence of a standard support target.

What Linux needs is not another distribution with a slightly different dock.

It needs a credible desktop contract.

That contract would probably include:

A stable, long-lived application platform.
One preferred desktop application format.
Reliable graphical updates with rollback.
Strong sandboxing that does not constantly break integration.
A standard permission model users can understand.
Certified hardware with complete firmware and power-management support.
Consistent handling of files, links, notifications, shortcuts, screen sharing, and default applications.
A clear compatibility policy across operating-system releases.
Documentation that does not assume the user already knows which subsystem failed.
Enough commercial incentive for major application vendors to treat the platform seriously.

None of this requires eliminating the distributions and desktops that already exist.

It requires someone to say, “This is the supported desktop platform,” and then do the unglamorous integration work for a decade.

Not for one release.

Not until the maintainers get bored.

Not until a newer packaging system becomes fashionable.

A decade.

Desktop trust is built slowly and lost quickly.

I do not want Windows to win by default

That is the part that bothers me.

I do not think Windows is becoming better for developers and power users. It is becoming more capable in some areas while becoming more intrusive, cluttered, and ecosystem-driven in others.

Those are not the same thing.

Adding another AI surface does not make file management better.

Adding personalized recommendations does not make the Start menu more predictable.

Connecting more folders to OneDrive does not improve local ownership.

Requiring an online account does not make the operating system feel like mine.

Microsoft keeps building a future where Windows is a smart, personalized, cloud-connected assistant.

I want an operating system.

Linux should be the answer. Technically, it has nearly everything required. Politically and structurally, it does not.

The Linux desktop still asks users to accept too many caveats:

It is great if your hardware is supported.

It is great if your applications are available.

It is great if your games work through Proton.

It is great if your employer’s tools support it.

It is great if you choose the right distribution.

It is great if you do not mind occasional configuration archaeology.

That is too many “ifs” for an operating system that is supposed to replace Windows.

Linux enthusiasts will correctly point out that millions of people use Linux desktops productively every day. Some systems are polished. Some hardware combinations work beautifully. Some developers would never willingly return to Windows.

I am not arguing that Linux is unusable.

I am arguing that “usable” is an embarrassingly low target in 2026.

The standard should be obvious, cohesive, predictable, and boring.

Linux is powerful enough. The kernel is mature enough. The desktop environments are capable enough. The packaging technology is sophisticated enough. The community has spent decades solving difficult engineering problems.

And somehow, after all of that, a developer escaping an increasingly irritating Windows experience still has to choose between Microsoft’s product agenda and Linux’s integration lottery.

Why the hell are we still having this conversation in 2026?

DEV Community