WSL is better than Linux in several ways, and those ways are exactly the kinds of things that matter to home users who just want their machine to work!

On bare‑metal Linux:

• Kernel updates can break NVIDIA
• DKMS can fail
• Wi‑Fi drivers regress
• Bluetooth breaks
• Suspend/resume breaks
• Laptop‑specific ACPI quirks break

On WSL:

• Windows handles all drivers.
• WSL never touches kernel modules.
• WSL sees only virtual hardware.
• No DKMS. No kernel panics. No “my Wi‑Fi died after update.”

WSL never has to deal with:

• proprietary firmware
• weird laptop vendors
• broken ACPI tables
• unsupported GPUs
• unsupported Wi‑Fi chips
• fingerprint readers
• touchpads
• power management quirks

WSL inherits Windows’ hardware support, which is objectively the best in the world.

Bare‑metal Linux has:

• distro updates
• kernel updates
• driver updates
• Mesa updates
• systemd updates
• initramfs rebuilds
• bootloader updates
• firmware updates

WSL has:

• Windows Update.
• Microsoft‑maintained WSL kernel.

You don't get the "update roulette" Linux users deal with (and fear).

GPU acceleration is easier and more stable on WSL. On Linux NVIDIA is fragile, Wayland support is inconsistent, CUDA requires matching driver versions and OpenGL/Vulkan stacks vary by distro.

WSL avoids:

• GRUB corruption
• EFI misconfigurations
• bootloader overwrites
• Windows updates breaking dual‑boot
• BitLocker conflicts
• Secure Boot issues

Bare‑metal Linux lets you:

• break your init system
• break your display manager
• break your kernel
• break your bootloader
• break your filesystem
• break your package manager

If you break your WSL distro, you delete it and reinstall it.
Your computer still boots. Your files are still safe.

WSL distros are just:

• folders
• VHDX files
• easily backed up
• easily cloned
• easily restored

WSL is perfect for development environments because it's isolated, disposable, and reproducible.

Linux kills SSDs faster, because parts of the Linux ecosystem (including systemd) generate unnecessary write‑amplification, and Linux is slower than Windows/BSD to adopt modern SSD‑preservation techniques.

Linux is fragmented, slow to standardize, and full of subsystems that thrash storage because nobody agrees on sane defaults.

Systemd isn't horrible, but it's extremely heavy on disk writing and Lennart Pottering is no longer involved with it. On a busy system, it produces continuous low‑level write thrashing, especially for laptops with flaky suspend/resume, desktops with misbehaving services, servers with noisy logs, and distros that crank journald verbosity up.

BSD, OpenRC, Runit, and s6 barely touch the disk unless something actually happens. Systemd touches it because something might happen.

Windows adopted SSD‑aware defaults early with automatic TRIM, write-coalescing, aggressive caching (why it sometimes appears to use more RAM), NTFS metadata batching, and predictable journaling.

Linux DEs generate pointless writes, like GNOME tracker indexing, KDE Baloo indexing, Flatpak metadata churn, Snap loop-mount spam, electron apps spamming logs, browser cache directories with no write-limits, and package managers re-writing entire meta-data trees.

Windows and macOS throttle background writes. -Linux does not.

Linux swap behavior is notoriously aggressive. Systemd‑oomd monitors memory pressure and writes state constantly. Cgroups v2 memory accounting causes extra metadata writes. Swappiness defaults are often too high. Zram is not enabled by default on most distros. Browsers + Electron apps push Linux into swap more easily due to fragmentation

When Linux hits swap, SSDs get hammered.

BSD didn't just ship TCP/IP it shipped the reference implementation that everyone copied.

• Sockets API — the universal abstraction for network programming. Every OS uses it.
• select() and later poll() semantics — core event‑driven I/O primitives.
• Routing sockets — foundational for dynamic routing daemons.
• ifconfig, netstat, route — canonical network tooling.
• BPF (Berkeley Packet Filter) — the ancestor of modern eBPF hype; still used in macOS, FreeBSD, OpenBSD, Linux.
• NFS (Network File System) — early implementations shipped with BSD.
• r-commands (rlogin, rsh, rcp) — insecure today, but historically important.

Linux inherited networking culture from BSD.

BSD's security lineage is absurdly influential:

• OpenSSH (OpenBSD) — the world’s default secure remote access tool.
• pf firewall — widely ported, admired for clarity and correctness.
• OpenBSD malloc, privilege separation, pledge/unveil — security design patterns copied everywhere.
• OpenBGPD, OpenNTPD, OpenSMTPD — secure-by-default network daemons.

Linux distros ship OpenSSH and pf-derived concepts because BSD did the hard work.

BSD's storage innovations are quietly everywhere:

• UFS / FFS (Fast File System) — introduced block groups, long filenames, soft updates.
• Soft updates — a correctness model Linux never adopted.
• ZFS (via FreeBSD) — the canonical implementation; Linux’s version is a port.
• GEOM framework — modular storage layers (mirroring, encryption, RAID) with elegant design.

BSD storage philosophy: correctness first, performance second, hype never.

A shocking amount of “standard Unix” tooling is actually BSD-origin:

• vi — the editor that shaped modal editing culture.
• csh and tcsh — early shell innovations.
• cron — job scheduling.
• syslog — universal logging infrastructure.
• top — process monitoring.
• dd, tar, cp, mv, ls — many canonical implementations originated in BSD.
• BSD init — simple, predictable startup system (before Linux’s systemd era).

If you’ve ever typed ifconfig, ps, kill, or netstat, you’ve touched BSD DNA.

BSD introduced architectural ideas that shaped modern OS design:

• Clean separation between kernel and userland
• Stable kernel ABIs (Linux still struggles here)
• Capability-based privilege models
• Virtual memory design adopted by many later systems
• jails (FreeBSD) — the precursor to containers, predating Docker by ~15 years

Linux containers are conceptually BSD jails with marketing.

BSD’s influence on the actual backbone of the internet is massive:

• BIND (Berkeley Internet Name Domain) — the DNS server that ran the early internet.
• sendmail — the mail transfer agent that dominated for decades.
• Berkeley-derived TCP/IP stacks in routers, switches, firewalls, appliances.

If it moved packets in the 80s, 90s, or early 2000s, it probably ran BSD code.

macOS, iOS, iPadOS, watchOS, tvOS — all built on:

• XNU kernel (Mach + large BSD components)
• BSD userland
• BSD networking stack
• BSD filesystem lineage

Every iPhone is a BSD descendant.

Consumer Electronics

• PlayStation 4 & 5 — FreeBSD-derived OS.
• Smart TVs, routers, NAS devices — BSD networking stacks everywhere.
• TrueNAS / FreeNAS — enterprise storage built on FreeBSD.

BSD-origin tools that became universal:

• libc implementations
• make (BSD make)
• diff, patch — essential to software development workflows
• rc scripts — the ancestor of init systems

BSD contributed ideas that shaped how engineers think:

• “Correctness over convenience.”
• “Security as a design constraint, not an add-on.”
• “Minimalism and clarity in code.”
• “Stable interfaces matter.”

Linux culture often prioritizes velocity; BSD prioritizes durability.

BSD didn’t just give the world TCP/IP — it gave the world the shape of modern computing: sockets, filesystems, logging, containers, security tooling, DNS, routing, storage frameworks, and the OS foundations inside every iPhone and PlayStation.

Torvalds is confronting a reality where AI‑augmented code discovery, bug surfacing, and exploit generation are now part of the ecosystem he maintains. He's adapting because the kernel can't pretend these tools don't exist anymore.

For 3 decades, kernel development has been shaped by human‑found bugs, written patches, and human‑paced review cycles. Modern LLM‑based static analysis and fuzzing pipelines can surface hundreds of potential issues in minutes, generate PoCs for exploit chains, mutate inputs faster than syzkaller ever could, and find "weird machine" states humans wouldn't think to test.

-Torvalds can no longer ignore that.

Ignoring AI became impossible once it started surfacing kernel‑relevant bugs. For years, Torvalds dismissed AI codegen as "garbage", "dangerous", and "not helpful". -Then AI tools started finding UB patterns, surfacing concurrency hazards, generating syzkaller-style crash reproducers, identifying memory-safety regressions, and flagging suspious pointer lifetimes... he could no longer treat it as noise.

-Linus was late to the party.

The kernel community was moving on without him. Maintainers were discussing AI‑generated patch floods, new tooling to triage AI‑found issues, stricter patch acceptance rules, more emphasis on reproducible test cases, more skepticism toward AI‑assisted contributions, and more automation around review queues.

-He adapts when the ecosystem forces adaptation. -He's not a visionary

Asahi didn't "fail". Asahi delivered exactly what a small, highly technical project could realistically deliver. What failed was the Linux community's fantasy projection. The Linux hype machine rewards potential, not outcomes.

When a project promises things like "full hardware support", "a new architecture", yadda yadda, it becomes the buzz on Reddit, Lemmy, and Hacker News immediately.

Reverse‑engineering culture creates unrealistic expectations. Linux users love the idea that "If we just reverse‑engineer it hard enough, we can beat the vendor." But reverse‑engineering is slow, fragile, and dependent on a tiny number of experts. Asahi had maybe 3–5 people doing the heavy lifting while the hype acted like it had 300.

The community treats every project like a Windows/macOS replacement. Even when the project itself says:

"This is experimental, incomplete, and not meant for daily use."

The GNU community of course hears:

"This will dethrone Apple."

It will happen repeatedly, predictably, and as long as Linux is a thing because the Linux ecosystem keeps generating the same conditions before reality arrives: 2-5 years of slow driver work, partial hardware support, niche usability, tiny contributor base, dev burnout, and 'it works' (but not better than the vendor OS).

Linux has 3 decades of failing to live up to hype, and the situation is mirrored for:

• Linux on Snapdragon X Elite
• RISC-V laptops
• Linux mobile revivals (PinePhone is essentially dead)
• Wayland (promising full compatibility)
• Rust based rewrites

Asahi didn't fail, Linux hype failed (as it always does.)

It's not like typical Linux users can afford a Mac, and those that could probably wouldn't gimp it with Linux. -2% of 2%

(They aren't worth catering to) -Even if they had stable ABI/API in the kernel (they don't.) The smarter question: why not BSD?

And it is NOT the 'entire' Internet.

TLDR: Valve/Steam has never issued a general warning to users about the frame‑pacing/timing‑logic issues in certain games that make them effectively unplayable or unbeatable on SteamOS despite "running."
-Not in patch notes, Proton release notes, Deck Verified criteria, store‑page warnings, and not in any public communication.

They do not test for timing bugs, broken physics, or unstable frametime behavior. Valve has never warned users about games that "run" but have broken timing logic under Proton/SteamOS. Major issues arise when there's physics tied to uncapped framerate, games that rely on Windows-specific timing APIs, games that behave differently at 40/60/90 Hz and games where frame pacing instability causes input desync or impossible difficulty spikes.

Valve does not mark these games as "Unsupported," even though the gameplay is functionally broken.

If the game launches and renders frames, Valve considers it "working." Even if the frametime graph looks like a seismograph, the game's logic runs too fast or too slow, boss fights become impossible, rhythm/timing games desync, cutscenes skip or break scripting, or a time trial becomes unbeatable mid-game.

No warnings. No labels. No store‑page notices.

Valve won't even tell you, "this game runs poorly on SteamOS, is broken under Proton, or "works better on Windows". If you want to find problems, you need to look at the fixes, but there are no 'heads ups'.

Linux doesn't have a native Layer‑7 application firewall API

Windows and macOS have OS‑level frameworks that:

• identify applications consistently
• track their network‑using threads
• enforce per‑app outbound rules
• integrate with code‑signing and sandboxing
• expose stable APIs for firewall vendors

Any Linux "application firewall" tries to work with mechanisms that were never designed for it.

Why Linux app firewalls break (OpenSnitch, Portmaster, etc.)

• OpenSnitch crashes games instantly
• It misidentifies processes or child processes
• UI becomes unusable with apps that spawn many children (browsers, Steam)

Linux apps spawn dozens or hundreds of short‑lived helper processes.
A firewall trying to track each one is fighting the OS. Windows/macOS utilize app identity or code‑signed bundles.

Games and anti‑cheat/DRM hate syscall interception. -These systems detect "unexpected interference" and bail. Outbound firewalling is also bypassable on Linux. It can inject itself into other allowed processes easier than it can on Windows.

Linux has a different security model, which handles the situation differently. It has AppArmor (per-process syscall restrictions), SELinux, fapolicyd/IMA, Firejail, and Flatpack permissions (toggles).

BSD has better security, load handling, network stack, documentation, cohesion, power efficiency, etc. -Try to explain why BSD isn't dominant on servers without mentioning the GNU/GPL cult.

Wasting 30-45% power isn't just about about laptops wasting power anymore, it's about datacenter‑scale inefficiency caused by architectural gaps in Linux’s power management stack.

CPU idle state handling is worse than Windows Server Linux often fails to enter the deepest C‑states under load patterns that Windows handles correctly.

• Windows Server uses vendor‑tuned ACPI tables, DPTF, and firmware hooks
• Linux relies on generic ACPI, often missing vendor‑specific power logic
• Result: CPUs sit in C2/C3 instead of C6/C7, wasting 20–40% power

This is especially bad on:

• Intel Xeon Scalable (Ice Lake, Sapphire Rapids)
• AMD EPYC (Naples → Milan → Genoa)

Linux scheduler inefficiency The Completely Fair Scheduler (CFS) is great for fairness, terrible for power.

• It spreads tasks across cores making more cores wake and using more power
• Windows Server aggressively core‑packs workloads with fewer active cores and lower power draw

This alone can cause 15–25% power waste under mixed workloads.

PCIe ASPM is frequently disabled On servers, Linux often ships with:

• ASPM off
• L1 substates off
• PCIe power gating off

Why?
Because vendors disable these features in firmware when Linux drivers don’t reliably support them.

That’s 5–10% wasted power across NICs, NVMe, HBAs, GPUs, accelerators.

Driver power gating is incomplete Windows drivers are vendor‑authored.
Linux drivers are:

• reverse‑engineered
• community‑maintained
• missing proprietary power hooks

This affects:

• Mellanox/ConnectX NICs
• Intel i40e/ixgbe
• AMDGPU/ROCm
• NVIDIA (even with proprietary drivers)
• NVMe controllers

Power gating gaps can add 10–20% inefficiency.

Kernel regressions are common and persistent A single kernel update can break:

• idle states
• turbo scaling
• NUMA balancing
• scheduler heuristics
• cpufreq governors

These regressions often sit unfixed for months, especially in LTS kernels.

The most rigorous measurement of support comes from analysis (2009–2021). In 2021, U.S. federal agencies invested ~$407 million in OSS development. Code.gov -This is OSS broadly, not Linux-specific.

A 2026 UN/UNESCO/Software Heritage report shows:

• 288,411 public repositories with at least one government contributor
• 92,831 distinct government contributors across 193 countries

-Demonstrating widespread global investment.

Linux-specific cost cannot be isolated because it's developed by corporations (Red Hat, Intel, Google, Meta, AMD), volunteers, universities (subsidized), and Nonprofits like Linux Foundation.

Government contributions aren't tracked by project, and are often indirect (unaccounted for), such as with funding research labs that contribute patches.)

The U.S. federal government spends over $100 billion/year on IT contracts. About $12 billion/year is software licensing & development (includes proprietary).

With Linux; you need to keep your whole system updated (which many don't do because it often causes breakage on Linux.) Windows doesn't even need a system update (and reboot) to update Windows Defender. Linux users bragging about uptime is really them displaying their ignorance concerning security.

-"We just distrohop or blame ourselves when something bad happens!"

Smartphones have banking, government ID, payment, messaging, and travel apps. Linux has none of these natively.

Phones have hardware-backed keystores, verified boot, mandatory sandboxing, mandatory app permissions, and automatic security patching.

Smartphones get first‑party vendor support, unified SDKs, guaranteed updates, and predictable APIs.

Desktop Linux breaks more often because it's not a controlled platform. Phones are appliances while Linux desktops are DIY kits.

Smartphones have updates tested against one hardware stack, drivers are unified, firmware is integrated, and apps are vetted.

With Linux, kernel updates can break drivers, DE updates can break extensions, Wayland/X11 fragmentation causes regressions, GPU stack varies by vendor, and Firmware flashing is riskier.

Smartphones have better power management

Phones have aggressive battery optimization (imagine money being incentive), hardware‑software co‑design, and unified sleep states. Thermal management is tuned per device.

Smartphones have better multimedia pipelines with hardware‑accelerated codecs, camera pipelines tuned per sensor, DRM is fully supported, and the audio stack unified.

What Linux did with NTFS (a janky, reverse‑engineered driver for a proprietary filesystem) is unique to Linux.

😈 BSDs supporting Linux filesystems

FreeBSD, OpenBSD, and NetBSD all support some Linux filesystems, but only the safe, well‑documented, and non‑proprietary ones.

• ext2/ext3 (read/write)
• ext4 (usually read‑only, limited)
• FAT/exFAT
• ISO9660/UDF
• ZFS (shared with Linux via OpenZFS)

They don't support:

• Btrfs
• XFS (write support is basically nonexistent)
• F2FS
• Bcachefs
• (Anything experimental)

BSD developers won't repeat Linux’s NTFS mistake of supporting a filesystem without full specs or stable kernel APIs. They only adopt filesystems that are fully documented, stable and not tied to Linux kernel churn.

🍎 macOS supporting other OS filesystems

MacOS supports:

• FAT/exFAT (read/write)
• NTFS (read‑only)
• ext4 (via third‑party drivers only)
• ZFS (third‑party only; Apple abandoned it)

Apple will not ship write support for:

• NTFS
• ext4
• Btrfs
• XFS

Apple refuses to take on the liability of writing to foreign filesystems. They don’t want to be blamed for corruption caused by undocumented formats, kernel instability, or third‑party metadata semantics.

🪟 Windows supporting other OS filesystems

Windows is even more conservative than macOS.

Windows supports:

• FAT/exFAT (native)
• NTFS (native)
• ReFS (native)
• ext2/ext3/ext4 (third‑party drivers only)
• ZFS (third‑party only)

🐧 Linux supporting other OS filesystems

Linux is the only OS that aggressively supports foreign filesystems.

• NTFS
• exFAT
• HFS/HFS+
• ISO9660/UDF
• FAT
• ZFS (out‑of‑tree)
• ReiserFS
• Minix
• Amiga FS
• HPFS
• UFS
• JFS
• F2FS
• Btrfs
• XFS
• Bcachefs
• dozens more

Linux culture encourages experimentation, reverse engineering, volunteer supplied garbage drivers, and distros exposing experimental features. This is why Linux ended up with janky NTFS, HFS, UFS drivers, etc.

NTFS on Linux was a disaster that took 20 years to sort out, and no other OS would subject its users to anything like it.

Mint is built on Ubuntu… which is built on Debian… which means it inherits every upstream problem and adds its own.

When Ubuntu breaks something, Mint breaks. When Debian freezes for 2 years, Mint freezes. When Ubuntu ships outdated packages, Mint ships outdated packages.

Cinnamon is a horrible technical dead end

Cinnamon is:

• ~~still tied to X11~~
• ~~not Wayland‑ready~~
• not modernizing at the pace of GNOME or KDE
• maintained by a tiny team
• unintuitive and more cumbersome than other DEs with CLI solutions

Mint's update philosophy is "don’t touch anything"

Mint intentionally avoids major updates to avoid breaking things.

• you get older kernels
• older drivers
• older Mesa
• older desktop stack

Great (j/k) for grandma’s laptop. Not great for gaming, new hardware, or anything performance‑sensitive.

Mint actively discourages Flatpaks and Snaps… but also can't provide modern packages

Mint hates Snaps (this actually makes sense for Desktop). Mint barely tolerates Flatpaks. Mint's repos are old. So, users end up in dependency hell or installing random .debs (binaries, or what Windows users used to be mocked for) from the internet.

“we don't like the App Store, but we also don't have our own."

Mint historically:

• delayed security patches
• had a compromised ISO mirror distributing a malicious ISO
• had a philosophy of "updates shouldn't break things," which meant delaying critical fixes

-Mint fans pretend these never happened.

Minimal hardware‑fault tolerance (no WHEA‑equivalent)

Linux avoids heavy hardware‑error mediation layers because they add complexity and overhead.
Sacrifice:

• No unified hardware‑fault recovery architecture
• Many errors escalate to freezes or kernel panics
• Non‑ECC RAM bit flips often cause silent corruption or crashes
• PCIe AER recovery is inconsistent and driver‑dependent

Aggressive kernel‑panic philosophy instead of subsystem restart

Linux chooses correctness over uptime.
Sacrifice:

• Kernel panics on corruption Windows would isolate
• GPU driver faults often freeze the session instead of resetting
• Audio/USB stack failures often require full reboot
• No equivalent to Windows TDR (reliable GPU reset)

Drivers run closer to the metal (less isolation, fewer guardrails)

Linux drivers are lean and often run in kernel space.
Sacrifice:

• Higher blast radius for driver bugs
• More crashes from flaky consumer hardware
• No mandatory driver verification framework like Windows HLK/WDF
• Volunteer‑written drivers with varying defensive coding quality

No hypervisor‑enforced kernel integrity (VBS/HVCI equivalent)

Linux avoids the overhead of virtualization‑based kernel protection.
Sacrifice:

• Kernel memory is not shadow‑protected
• Bit flips can corrupt kernel structures directly
• No hardware‑isolated code integrity enforcement

Simpler memory‑error handling (bad page retirement rarely enabled)

Linux can retire bad RAM pages, but distros rarely enable it because it adds overhead and complexity.
Sacrifice:

• Soft memory errors often kill processes or freeze the system
• No unified consumer‑grade memory‑integrity pipeline
• ECC is treated as the “real” solution

Windows compensates for bad RAM; Linux expects good RAM.

Less defensive user‑session architecture

Linux desktops are modular and lightweight.
Sacrifice:

• Xorg/Wayland sessions can collapse from minor driver faults
• Compositors crash more easily
• No unified fallback path for desktop recovery
• Freeze > crash > restart hierarchy is inconsistent

Lean system services (fewer watchdogs, fewer recovery daemons)

Linux avoids heavyweight watchdog frameworks.
Sacrifice:

• Fewer automated subsystem restarts
• More “silent hangs” with no logs
• More reliance on user rebooting manually

Assumption of server‑grade hardware

Linux’s design roots are in server environments.
Sacrifice:

• ECC assumed for correctness
• Stable power assumed
• Stable PCIe assumed
• Stable RAM assumed

Linux is 'often' lighter because it does less to protect you from bad hardware.