Linuxsucks

People who start with Mint/Ubuntu/Fedora accumulate sunk cost slowly, so they generally quit earlier and with less emotional drama.

Arch/Gentoo users: The Identity‑Investment Trap. These users don't just install a distro - they install a persona. Hours spent reading the wiki, configuring dotfiles, fixing breakages, compiling, customizing, debugging, etc., creates a massive sunk cost early. (Think: the more money someone donates to a church).

They feel like they've earned Linux.

So, they stay, even when updates break their system, NVIDIA drivers regress, audio breaks, Wayland crashes, Steam stops launching, a kernel update nukes their initramfs, a DE update breaks extensions, a package gets orphaned, or a config file gets overwritten.

They're too much in it to just quit. -Classic Sunk Cost Fallacy

They typically last 6–18 months before burnout, and when they quit, it's more dramatic.

Mint/Ubuntu/Fedora users invest comparatively little upfront. -(Lower sunk cost -shorter duration of sticking with it, and less animosity). They don't feel like they earned Linux, or that quitting is failure.

So, when they get printer issues, game compatibility problems, audio glitches, DE weirdness, update breakage, and app availability gaps, they quit quickly.

They last about 2–8 weeks before deciding "This is annoying. I'm going back."

No drama. No identity crisis. No Reddit post. Just a quiet uninstall.

It's a cultural and technical coping mechanism that emerges from how Linux intersects with gaming, compatibility, and community identity.

Old games are the only domain where Linux is arguably 'better'. It's a psychological safe zone; an area where Linux doesn't lose! See: Progress‑Blocking, Game‑breaking, or Trust‑Destroying Failures of Proton

Modern games expose Linux's weaknesses: Anti‑cheat, kernel-level DRM, proprietary launchers, shader compilation stutter, GPU driver quirks, Wine/Proton edge cases, multiplayer compatibility, kernel input latency variance, VR stack fragmentation, and modding.

Linux culture will thus champion old games with propaganda like: "software that respects you / is hackable / lasts forever". Old games are lifted up as moral exemplars.

Linux has:

• almost no native AAA releases
• no major studios targeting it
• no first-party gaming platform
• no equivalent to DirectX's tight integration
• no unified graphics stack (Mesa vs proprietary drivers)

Communities thus pivot to what is available: "Look at these classics! They’re timeless!" -A reframing tactic.

When Linux fails at something modern, the community retreats into something old.

Reframing limitations as virtues:

• Can't run new Adobe apps leads them to "GIMP is enough / Adobe sucks."
• Can't match Windows UX is coped with "I prefer minimalism."
• Can't match hardware support is addressed by "I don’t buy unsupported hardware."

-Why buying only supported hardware is a huge issue.

FreeBSD doesn't hurt from lacking systemd or PulseAudio/PipeWire in the way Linux distros would, but it does pay a cost in desktop‑ecosystem compatibility, while gaining reliability and architectural sanity on the server side.

FreeBSD benefits from a clean, modular init system (rc + devd + jail infrastructure) No monolithic PID1 swallowing logging, networking, timers, cgroups, etc. FreeBSD’s rc system is stable across releases; systemd's behavior changes frequently.

Some Linux software hard‑depends on systemd, like some container tooling (Podman, systemd‑nspawn ecosystems), desktop environments that integrate systemd services (GNOME especially), and modern Linux service management tooling that assumes systemd units. FreeBSD can run GNOME, KDE, etc., but GNOME's systemd entanglement means FreeBSD's GNOME ports require patches or shims. -Collateral damage from Linux monoculture.

FreeBSD's audio stack is native: OSS (Open Sound System). It's simple, low latency, stable, and well‑integrated with the kernel with no daemon spaghetti. -FreeBSD can also support Pulse and Pipewire if desired.

Some Linux desktop apps assume PulseAudio or PipeWire is present by default. Some pro‑audio workflows expect JACK + PipeWire integration out of the box. FreeBSD can run all of them, you just need to install them.

OSS is often faster and simpler than PulseAudio’s historical mess. PipeWire is still evolving rapidly; FreeBSD avoids being tied to its churn and birthing pangs.

On servers, FreeBSD’s lack of systemd is a competitive advantage with ZFS integration, Jails, pf firewall, rc scripts that are readable and predictable. There are no systemd‑induced boot failures, induced service dependency hell, or logging weirdness.

FreeBSD's server reliability is one of the reasons Netflix, Juniper, and iXsystems use it. FreeBSD is what Linux users claim Linux is but isn't.

The answer to the title? -It must have to do with the commie GPL/copyleft cult.

The problem on Linux is about missing desktop services, not Hyprland itself. (It's always Linux fault)

On Linux, Hyprland is only a Wayland compositor. -It does not provide GNOME Keyring, KDE Wallet, Secret Service DBus API, Polkit agents, or Portal helpers. Apps expect a Secret Service provider (Chromium, VSCodium, Steam, Slack, etc.). What you get is "feature not supported on this OS" behavior.

Many Linux apps that store secrets simply aren't used the same way on FreeBSD. FreeBSD avoids the problem by not having the ecosystem that causes it.

If an app does try to use Secret Service on FreeBSD:

• It won’t find a provider
• It won’t fall back to plaintext
• It will either:
  • store nothing
  • store encrypted data in its own format
  • or disable the feature entirely

FreeBSD’s security defaults are stricter because it doesn't try to emulate Linux's keychain behavior.

Linux is useful, ubiquitous, and exposed (for criminals).

Linux has built‑in tools that cyber attackers love:

• ssh
• netcat
• nmap
• iptables
• Python preinstalled
• Bash scripting

They also bask in not having forced updates, or telemetry.

Cyber Criminals can "customize it", run it headless, embed malware into appliances, and make tiny distros for botnets.

Linux users hate to admit Linux’s culture of:

• "Run this random script from GitHub"
• "Disable AppArmor, it’s annoying"
• "Just compile it yourself"
• "Security through obscurity is bad, but also we don’t need antivirus"
• "The AUR/Flakes make Arch/Nix great!"

-making them vulnerable to attackers (ideal and ignorant victims).

Large criminal organizations, drug cartels, trafficking networks, money‑laundering rings have repeatedly been found running self‑hosted Linux email servers, Linux‑based encrypted messaging appliances, custom Linux routers for “dark” networks, Linux‑based VOIP servers. -Traditional criminals using Linux to avoid commercial surveillance.

Extremist groups using Linux for propaganda infrastructure. They weren’t “hackers.” They were using Linux because it’s the default OS for running a website without leaving a corporate trail.

Cults, and extremists have been found hosting internal communication systems, surveillance systems, file servers, and CCTV storage on Linux boxes because it doesn't require licensing and can be locked down or isolated. Btw, the “tech guy” who installs Debian once becomes the sysadmin for life.

Surveillance‑obsessed individuals (Epstein types) use it to control others, hide information, compartmentalize, and avoid commercial footprints. (Even though Epstein proved Windows is sufficiently private)

Financial criminals, fraudsters, and corrupt officials have been caught using Linux encrypted containers, laptops with custom partitions, Tails/Whonix for anonymous communication, and servers for offshore data storage

The Linux desktop has an upstream maintenance problem due to many reasons for it, such as the lack of paid work. No one is entitled to a volunteer’s free time apart from the volunteer themself. This is especially true to volunteers working on upstream projects, as they are at the mercy of downstream distributions, who have the final say. As an upstream contributor, you have no choice but to meticulously plead for any reasonable request to be granted by difficult downstreams, treating them as if they are some kind of deity. Not doing so with the utmost respect can get you on their naughty list, which they can then use against you just because the license ‘allows’ it and they can get away with it; even shamelessly use the ‘you chose the wrong license’ card when they have nothing else to add. We have seen several instances of downstreams misusing their power while simultaneously abusing upstreams’ generosity and free time to do whatever they want. This was especially true with XScreenSaver and Debian in the past, which Debian has since changed its policies to communicate better with upstreams, and more recently Bottles, OBS Studio, and Fedora. This article is specific to an even more recent incident we at GNOME Calendar have had with Linux Mint.

Contents of image a response to:

Inferiority Complex

Linus Torvalds when criticized for choosing a 'monolithic kernel' because it was 'out-dated', responded in defense with 'what do you expect for free', and 'it's a hobby project'. So, you're stuck with 3rd party amateur developed drivers in ring 0 (worse than kernel level anti-cheat btw, and which have caused huge problems unlike anti-cheat so far).

Richard Stallman eats crap off his feet in front of an audience while speaking, and defends necrophilia and pedophilia. His only notable software contribution is Emacs which took Derek Taylor (RMS fan) 2 years to learn. -Derek prefers Emacs to Vim btw (because the fonts are easier on his aging eyes). -Imagine that excuse for spending 2 years to learn a text editor!

Desktop Linux was NOTHING and would probably still be NOTHING without Lennart Poettering's contributions. Like many other great FOSS contributors, they were driven off by threats and harassment from people that are so deep in inferiority complex that they can't even make rational arguments for their positions. They resort to emotions and insults, putting others down to make themselves feel better.

LBT, and RMS aren't even original. RMS didn't start FOSS, LBT got his ideas from Minix and Unix which were created by far greater people: Dennis Ritchie, Ken Thompson, and Andrew Stuart Tanenbaum. -It's off the coat tales of these people that they're riding and they did it with a shitty base (monolithic kernel) and shitty cancerous license (BSD/MIT>GPL).

Opera relies on chromium-ffmpeg for proprietary codecs. Mint and Ubuntu don't ship chromium-ffmpeg in a way Opera can use. Flatpak, and Snap Opera bundle codecs differently.

Mint is Flatpak-first, Opera is historically .deb-first, Chromium codecs are inconsistent across packaging formats, and Snap bundles codecs in a way Opera can use.

Chrome's "plaintext fallback" isn't a distro bug. It's a session‑initialization failure. And Arch is the distro most likely to ship a session that's missing the parts Chrome needs.

Chrome/Chromium on Linux never stores passwords in plaintext by design. It stores them in GNOME Keyring (GNOME, XFCE, MATE), or KWallet (Plasma). Those keyrings only work if PAM unlocks them at login, the display manager initializes the session correctly, DBus is running, the keyring has a password, auto‑login isn't bypassing the unlock step, and the WM/DE actually starts the keyring daemon.

If any of those fail, Chrome logs: "Falling back to bsic text encryption". -This fallback uses a hardcoded key ("peanuts"). It's not literal plaintext, but it's effectively plaintext.

Arch's philosophy of giving you the pieces to assemble your own system makes this failure more likely. Arch users frequently end up with greetd instead of GDM/SDDM**, Hyprland/i3/bspwm** sessions without keyring integration**, No keyring package installed at all, PAM configs copied from wikis, Auto‑login bypassing keyring unlock, Custom session scripts that forget to start gnome-keyring-daemon, and Wayland sessions missing environment variables Chrome expects.**

Arch doesn't fix any of this for you. Arch doesn't warn you. Arch doesn't ship sane defaults.

Arch's rolling model increases breakage frequency. Even if you do configure everything correctly: PAM changes, keyring updates, display manager updates, session scripts, Wayland protocol changes, Chrome/Chromium updates, and systemd changes can break the chain at any time.

Fedora, Debian, Ubuntu, Mint, Pop, etc. ship stable PAM stacks, keyring integration, display manager configs, stable session scripts, stable environment variable setups. -Arch ships whatever upstream pushed yesterday.

Arch users disproportionately run DE-less setups. Chrome expects a real desktop environment. These window managers don't start the keyring daemon, unlock the keyring, export the right environment variables, integrate PAM correctly or initialize DBus properly. (Komorebi on Windows and Mac isn't just better than their TWM's, its' safer!

Arch's documentation encourages minimalism that breaks security. Arch Wiki pages often say things like: "You can disable gnome-keyring if you don't need it.", "You can remove PAM modules you don't use.", "You can use greetd for a minimal login experience.", and "You can start your session manually from .xinitrc."

-All true. All dangerous! Chrome depends on the “bloat” you removed.

Lookout for all DIY distros like Gentoo, Void/Artix, NixOS, Slackware, and Arch derived distros or anything with greetd. -I wouldn't even touch Linux at all knowing about their other desktop security issues though.

The Problem Doesn't Exist on FreeBSD

Lock-outs are very real and can happen, but they're not happening at the rate they're karma farming this template for. They're also always user-fault from sharing passwords (paid services) to using an OS that might store your password in the equivalent of a plain text file (like Linux).

LiGNUts will upvote these stories because it helps recruit people to 'free' garbage.

If people are worried about AI contaminating Linux with proprietary code, they're looking in the wrong direction. Linux is already GPL. The real licensing nightmare is what happens when GPL‑trained AI outputs GPL‑like code into non‑GPL projects.

Linux advocates up until Linus spoke out recently were largely anti-AI. Every few weeks you see: "AI will rewrite the kernel and accidentally include proprietary code, making Linux legally compromised." This fear misunderstands the GPL entirely.

Linux cannot be "infected" by proprietary code. Proprietary code can't override GPL terms. The proprietary code becomes GPL the moment it touches the kernel, not the other way around. -GPL is a one‑way valve. Linux is already the most license‑protected project on Earth.

If you use a GPL‑trained AI to generate code for an MIT project, and the AI outputs something structurally similar to GPL code, your MIT project is now a GPL project. If you use that same AI inside a proprietary company, and it outputs GPL‑derived logic, your proprietary project is now a GPL project.

-This is not a Linux problem. This is an everyone else problem.

AI models don't currently understand licensing boundaries. They don't know that a snippet "looks too much like the scheduler" or "resembles the VFS layer." -They just emit patterns. Most people including developers can't even identify kernel‑derived structures unless they've spent years reading kernel code (all eyes on code issue here).

Companies absolutely do not want accidental GPL obligations. The GPL requires source disclosure, redistribution rights, and derivative openness. -The exact opposite of what proprietary vendors want.

Companies should be terrified of AI models trained on GPL code, not because Linux will be harmed, but because they will be. Linux is the safest place for AI generated code. GPL is already bottom of the barrel; there is no worse.

I see a lot of Arch user bashing and I disregard it most of the time. Mint/Zorin/Bazzite/Cachy evangelists are more insufferable. Arch users flex, Mint users prescribe. Arch toxicity is performative elitism (really an inferiority complex symptom). Mint toxicity is paternalistic condescension.

Arch-user insufferability is self‑directed. If you ignore them, they keep monologuing to the void.

Mint advocates are insufferable in a different way:

• "Just use Mint."
• "You don't need to understand that."
• "Arch is too hard for you."
• "Mint is what normal people use."
• "You don't want to configure anything."

This is projection, or the same thing Linux advocates are doing to non-Linux users when they act like everyone should spend a whole weekend setting up and learning Linux, as well as wasting time fixing things (just because they don't mind it and have the time). They assume way too much like your skill level (many people start with Arch actually), your goals, preferences, tolerance for learning, desired workflow, and willingness to tinker. The distro is totally prescribed for you based on what THEY want.

To me it's saying, "You’re incapable." (I ran Arch for over a year, encountered all 4 breakages for that time period and fixed them within ~10 minutes). I also hand edited or configured DWM and adding 12 patches manually. I found Cinnamon desktop to be absurdly unintuitive. Changing the time from 24 hour to 12 for example was enough to get me to rage quit it and uninstall it. So, for those of us that know Arch, it's more annoying.

Mint/Zorin advocates often behave like tech support agents who didn't ask for your requirements, or parents deciding what’s "appropriate" for you. Arch users insult your competence indirectly (I see it as goading). Mint users insult your competence directly.

Arch users may overestimate you. Mint users underestimate you (and that to me is insultive).

It behaves consistently everywhere because it ignores the distro entirely, but that comes with tradeoffs. Nix doesn't integrate with your distro's package manager. It side‑steps it.

A Nix derivation for ffmpeg or neovim is the same regardless of what distro you're on.

nix-shell, flakes, and devShells behave identically across distros with no dependency hell, which is why people say Nix is great for development environments. However, anything that touches kernel modules. drivers, and low‑level system integration will behave differently depending on the host distro.

NixOS has a declarative service model. Non‑NixOS distros do not. Some proprietary apps assume a traditional Linux filesystem layout. Nix can handle this via nix-ld or FHS environments, but it's not seamless.

Nix GUI apps work, but desktop integration varies, icons/mime types can be messy, and sandboxing differences matter.

🔒 Security Issues

• maintainers not fully auditing updates
• auto‑updaters pushing malicious code
• binary cache trust issues
• cooldown proposals to slow updates

Nix is like AUR in terms of risk.

I can just see them writhing having to choose between AI and their beloved GPL! (BSD last I checked was against AI code)

If BSD ever threatened Linux's cultural dominance, the GPL evangelists would absolutely pivot into full‑blown anti‑BSD propaganda.

The "GPL cult" ignores BSD, and treats it like a toddler brother until it becomes a threat. Their behavior isn't random as it follows a predictable pattern:

• They only attack what threatens Linux's ideological position, not what threatens Linux technically.
• BSD doesn't threaten Linux's identity, because BSD is niche, quiet, and doesn't challenge the "Linux = FOSS flagship" narrative.

If BSD suddenly had Windows‑level market share or Android‑level influence, the tone would flip overnight:

• "BSD is corporate‑friendly, not truly free."
• "BSD allows proprietary parasites."
• "BSD is outdated UNIX legacy."
• "BSD is insecure because it doesn't force contributions back. (copyleft)"
• "BSD is anti‑community."

The talking points already exist, they're just dormant because BSD isn't perceived as a threat.

BSD's license model breaks the GPL worldview:

• BSD says: "Take it, use it, build on it, even make it proprietary; we don’t care."
• GPL says: "You can't take without giving back."

If BSD became dominant, the GPL ideology loses its moral high ground. -Linux would cease to be "the flagship of free software", or the "protector of user freedom". The narrative collapses because BSD proves you can have a stable, secure, cohesive OS without copyleft.

If BSD were big, the propaganda would be relentless. The same people who currently say "BSD is fine" would suddenly treat it like the devil. -Because the GPL cult's loyalty is not to technology; it's to ideology.

They're already losing their shit over this headline:

Linus Torvalds Reaffirms That Linux Is Not "Anti-AI" & Not A "Social Warrior" Project

-But they don't want to lift up their real leader: Richard Stallman either.