I use Linux because I want my computer to belong to me. I value inspectable software, open protocols, and an operating system that does not treat my attention as inventory. None of that requires pretending a blurry chat window or a dead laptop battery is acceptable.
Microsoft has given Linux an extraordinary opening. Required diagnostic data, Start menu recommendations, bundled distractions, and account funneling have turned Windows into an increasingly adversarial product. Microsoft’s Windows 11 requirements explicitly require internet connectivity and a Microsoft account during initial setup for Home and Pro for personal use.
Recall deserves precision rather than recycled outrage. It is an opt-in feature on supported Copilot+ PCs, with snapshots stored locally, not a mandatory cloud feed of everybody’s desktop. Microsoft documents its administrative controls and security model. Nevertheless, an operating system offering to continuously record visual activity is a remarkable direction for a platform already struggling with user trust.
Linux should be converting that distrust into durable adoption.
Sometimes it does. Excellent Linux desktops exist. Supported hardware, sensible distribution defaults, and compatible applications can produce an experience I would happily choose over Windows.
But too often, that experience is conditional on knowing which conditions matter.
The problem is not whether Linux has good components. It has exceptional components. The problem is whether those components reliably deliver the ordinary promises of a desktop computer: readable text, working meetings, predictable sleep, efficient video, and updates that do not dismantle yesterday’s workflow.
Wayland Is the Right Direction. The Transition Is Still Expensive.
Wayland began in 2008. Its practical desktop migration has consumed well over a decade, and users still encounter compatibility boundaries that should have become invisible years ago.
Replacing X11 was justified. X11’s permissive client model and accumulated assumptions were a poor foundation for modern isolation and heterogeneous displays. The mistake is treating a sound architectural direction as proof of a completed product.
Fractional scaling exposes the seams
A laptop panel at 150% scaling beside an external monitor at 100% is not an exotic configuration. It is ordinary office hardware.
Native Wayland applications can render appropriately scaled buffers. The fractional-scale protocol lets the compositor suggest a fractional scale, with viewport sizing connecting buffer pixels to logical surface dimensions.
That requires cooperation from the compositor, toolkit, rendering engine, and application.
An XWayland application can instead render a lower-resolution image that the compositor enlarges. Resampling already-rasterized text produces blur. Some compositors offer improved XWayland scaling modes, so this is not inevitable, but behavior remains configuration-dependent.
Nor is “Electron means X11” an accurate diagnosis in 2026. Modern Electron applications can use native Wayland. The relevant question is which runtime version and launch configuration the vendor actually ships.
Users should not need to answer that question to make Slack readable.
A protocol can be correct while the product remains inconsistent. “Supports fractional scaling” is not a meaningful platform promise if half the applications use a different path.
Screen sharing is an integration test disguised as a button
Wayland deliberately prevents ordinary clients from freely reading other applications’ pixels. That is a security improvement.
Capture therefore requires mediation. The ScreenCast portal establishes a session, obtains a source selection, and exposes PipeWire streams through a controlled connection. The application, portal service, desktop-specific backend, and compositor all participate.
Permission persistence adds another contract. Applications and backends must correctly implement restoration behavior; saving a token is not a universal guarantee of unattended access.
These portals are not exclusively for Flatpak applications. Native applications use them too.
Slack, Discord, and Zoom can share screens on supported configurations. The obsolete claim that “Wayland cannot screen-share” helps nobody. But a working browser client does not prove that an older desktop client, another package build, or another compositor works equally well.
When capture fails, the culprit might be an outdated application runtime, an incorrectly selected portal backend, or a compositor capability mismatch.
The user sees one broken Share button.
We improved the security boundary. We have not made the integration boundary consistently boring.
Closing the Lid Should Not Be an Experiment
Laptop suspend is where desktop reliability becomes physical.
A display going dark does not prove that the machine entered an efficient hardware sleep state. A successful suspend request does not prove that the laptop will spend the night asleep.
The kernel distinguishes several system sleep states. Two frequently encountered choices are:
s2idle, suspend-to-idle, which freezes userspace and suspends devices while allowing processors and compatible platforms to reach low-power states.deep, usually suspend-to-RAM, corresponding to ACPI S3 on platforms that support it.
This is not a contest between universally bad s2idle and universally good S3.
Modern laptops often expose only the S0 low-power-idle firmware model associated with Windows Modern Standby. Linux commonly uses s2idle on these machines, but it does not inherit Windows’s power-management policy stack.
On suitable hardware, s2idle can work very well. It does not mean “leave the CPU running at full power.”
The catch is coordination. A device, firmware defect, or driver interaction can prevent deep hardware residency or trigger unwanted wakeups. Resume introduces another failure surface as drivers restore device state, interrupts, and memory mappings.
Start with evidence:
cat /sys/power/mem_sleep
journalctl -b -k | grep -Ei 'suspend|resume|wakeup'
Brackets identify the selected mode. If the output is only [s2idle], adding mem_sleep_default=deep cannot conjure missing firmware support.
The kernel’s AMD suspend-debugging documentation explicitly distinguishes entering suspend from reaching hardware sleep, and documents residency and wake-source diagnostics.
Those are excellent engineering tools. They are also an absurd onboarding requirement for somebody who merely closed a lid.
Windows has Modern Standby failures too. That does not excuse Linux failures. Firmware qualified primarily for Windows is part of the explanation, not a satisfactory end-user remedy.
A laptop distribution needs measured overnight drain and repeated suspend/resume testing on supported machines. “The suspend command returned successfully” is not the acceptance criterion.
Hardware Video Decoding Is Not the Same as Having a GPU
A 4K YouTube video should primarily exercise the hardware decoder when the hardware supports the selected codec.
Yet “the desktop is GPU-accelerated” tells us almost nothing about whether video decoding is hardware-accelerated. Compositing, WebGL, decoding, and presentation are different paths.
The pipeline has several dependencies:
- The GPU must support the stream’s codec and profile.
- The appropriate userspace driver must expose that capability.
- The browser must select a compatible decoding backend.
- The sandbox must permit the required device access without abandoning isolation.
- Decoded frames must reach the compositor efficiently, ideally without unnecessary copies.
VA-API is a common interface on Intel and AMD Linux systems. VDPAU is another interface, not a universal switch that makes every browser consume NVIDIA’s decoding hardware.
And 4K is a resolution, not a codec. A GPU can decode VP9 while lacking AV1 decoding. Comparing two operating systems while YouTube serves different codecs is not a useful benchmark.
Hardware decoding already works automatically on supported Linux combinations. When it does not, software fallback can be quiet enough that users notice only the fan or shortened battery life.
vainfo can establish that a driver advertises decoder profiles. It cannot prove that the current YouTube stream uses them. Firefox’s about:support exposes capability information; Chromium’s chrome://media-internals helps inspect the active media pipeline.
Host diagnostics also do not necessarily describe the driver environment inside a sandboxed application package.
That distinction explains why copied about:config advice and Chromium launcher flags so often outlive the browser versions they targeted.
There is real progress. Mozilla’s 2026 tracking records Vulkan Video decoding work and a subsequently fixed sandbox compatibility bug.
The latter is also a warning: permanently setting MOZ_DISABLE_RDD_SANDBOX=1 is a security tradeoff, not a satisfactory desktop integration fix.
As for the familiar “3% CPU on Windows” claim, CPU normalization and browser-process accounting vary. No original cross-OS benchmark is being claimed here.
Chromium’s VA-API diagnostic guide includes a measured 2.63 W average SoC package-power example for 1080p VP9 on one ChromeOS device. That is a scoped measurement, not a 2026 Linux-versus-Windows result or a promise about 4K playback.
A serious comparison controls hardware, codec, frame rate, brightness, and workload duration, then records decoder selection, dropped frames, and power.
The engineering complaint survives without invented percentages: capable hardware should not require users to assemble the supported decoding path themselves.
The Packaging Civil War Has Real Costs
APT, DNF, and pacman integrate applications with distribution-managed dependencies. Flatpak decouples application delivery from much of the host’s release cycle. Snap provides another delivery, update, and confinement model. AppImage emphasizes portable application bundles.
These approaches solve different problems.
Native packages offer shared dependencies and coherent distribution maintenance, but application versions can be coupled to distribution releases. Flatpak and Snap give publishers more control over application delivery, while introducing additional runtime and integration responsibilities. AppImage usually does not provide automatic sandboxing or a centrally governed update lifecycle.
Pretending one format is ideal for every application is ideology masquerading as architecture.
The storage criticism also needs accuracy. Flatpak does not blindly install an entirely separate operating system for every application. Its OSTree-based internals support shared runtimes and file deduplication.
Nevertheless, multiple runtime branches can coexist. Add Snap bases, bundled application libraries, and AppImages, and duplication remains real. Deduplication within one repository does not create a universal dependency pool across packaging systems.
The nastier cost is behavioral inconsistency.
The FileChooser portal grants access to selected files outside a sandbox. An application that assumes this also grants unrestricted access to sibling files, arbitrary paths, or external helper programs can fail despite displaying a perfectly reasonable file picker.
Granting the entire home directory may hide the symptom. It does not repair the application contract.
Canonical’s policy deserves scrutiny too. Ubuntu 26.04’s chromium-browser package is a transitional package leading to the Chromium Snap. Installing through APT does not mean receiving a native browser package.
Canonical can choose that policy. Users can reasonably object to a familiar package-manager operation selecting a different delivery system.
Meanwhile, Discord added an automatic Linux updater and more native package formats in May 2026. That is progress, not evidence that Linux applications are abandoned. It also reinforces the need for clear answers about which component owns updates.
The useful debate is not “Which package format wins?”
It is “Who guarantees that this installation updates safely, opens files correctly, and behaves like the application the user thought they installed?”
Extensions Are Unsupported Until They Become Somebody’s Workflow
GNOME has a coherent design philosophy. It is entitled to one.
The difficulty is that many users obtain their preferred workflow through extensions that execute within GNOME Shell and hook implementation details rather than a stable external plugin interface.
Major upgrades can require porting or disable extensions that do not declare compatibility. Not every release breaks every extension, but the compatibility burden is structural.
The GNOME 45 migration to ECMAScript modules is a concrete historical example of changes requiring extension authors to adapt. Modernization was legitimate. So was the disruption experienced by users whose desktop depended on those extensions.
A dock, taskbar, tiling workflow, or window-management shortcut does not feel optional after somebody has built daily muscle memory around it.
“Extensions are unofficial” explains the support boundary. It does not make the lost workflow disappear.
No volunteer owes anybody indefinite maintenance. The responsibility belongs especially to distributions that ship or recommend extensions as essential parts of their desktop experience.
They have inherited a compatibility problem. They should fund maintenance, test upgrades, and publish supported combinations rather than outsource discovery to users on release day.
Choosing KDE or another desktop can be sensible. “Use something else” is still not an upgrade strategy for the desktop already being shipped.
The Missing Layer Is Product Ownership
Linux does not need one compulsory desktop, one package manager, or one organization controlling everybody else.
It needs stronger ownership of the combinations presented as finished products.
A browser team can correctly identify a driver problem. A compositor team can correctly identify an application bug. A distribution can correctly say that upstream owns the regression.
Everybody can be right while the user’s meeting remains broken.
Windows and macOS are not flawless. Their advantage is that mainstream hardware and software paths more often have identifiable vendors responsible for qualification. Linux’s component boundaries distribute that responsibility, sometimes until it effectively vanishes.
The repair is less glamorous than another desktop fork:
- Publish supported reference configurations. Qualify firmware, kernel, graphics stack, desktop, browser, and packaging together, with explicit hardware limitations.
- Gate releases on complete user journeys. Test mixed-DPI displays, capture permissions, browser decoding, dock transitions, repeated suspend/resume, and upgrades on physical hardware.
- Define compatibility contracts. Stabilize supported extension interfaces where feasible, document portal capabilities, and provide deprecation windows instead of surprise breakage.
- Assign and fund integration ownership. Somebody must own cross-project regressions until the user-visible failure is resolved, including coordination with OEMs and application vendors.
A distribution cannot realistically certify every laptop and every extension. A clear support matrix is more honest than an implied promise that everything should work because the kernel detects the hardware.
Some constraints are patent law, closed firmware, vendor neglect, and scarce engineering time. They are not all ideological purity.
But purity cannot substitute for usability testing either. Open defaults are valuable. Unexplained functionality gaps are not made less frustrating by the righteousness of the dependency policy.
Marketing and OEM distribution matter. They cannot compensate for an alternative that repeatedly asks newcomers to become integration engineers.
Linux’s defining desktop weakness is governance and integration prioritization, not insufficient enthusiasm.
The kernel, protocols, drivers, toolkits, and package systems deserve respect. They also deserve a product layer capable of turning their capabilities into reliable behavior.
I want Linux to win because software freedom matters.
That means holding the desktop to a higher standard than “a knowledgeable person can eventually fix it.”
Until closing a lid is boring, screen sharing is routine, and upgrades preserve ordinary workflows, “The Year of the Linux Desktop” will remain a punchline.
Microsoft has supplied the opening. Linux still has to supply the product.