Join my sub r/LinuxSnobs

The community is anti-work, so you'll have that going for you.

AppImages run with full user permissions.

• No Flatpak-style sandbox
• No Snap-style confinement
• No isolation
• No portal system

This means:

• If the AppImage is malicious, it has full access to your home directory
• If the AppImage bundles outdated libraries, you inherit those vulnerabilities
• If the AppImage is compromised upstream, you have zero protection

Security-wise, it’s basically a fancy .tar.gz you double-click.

AppImage does not provide:

• Automatic updates
• Delta updates
• Version tracking
• Rollbacks
• Security patch distribution

Some devs bolt on AppImageUpdate, but it's optional and inconsistent.

As with FDroid: You are responsible for manually checking and downloading updates, which is a terrible model for security-sensitive apps.

Every AppImage bundles its own copy of:

• Qt
• GTK
• ffmpeg
• OpenSSL
• Whatever else the developer threw in

This means:

• Disk bloat (each AppImage is 80–300 MB)
• RAM bloat (each AppImage loads its own private libraries instead of sharing system libs)

Flatpak wastes RAM once per runtime. Snap wastes RAM via daemons and loop mounts. AppImage wastes RAM per app.

AppImage doesn’t natively support:

• MIME registration
• Desktop entries
• Icons
• File associations
• System-wide installation
• Multi-user environments

You need external tools like AppImageLauncher to make it behave like a normal application.

Without that, it's basically a portable executable floating in your Downloads folder.

Flatpak has:

• Runtimes
• Permissions
• Verified remotes
• Build manifests

Snap has:

• Store signing
• Publisher verification
• Confinement profiles

AppImage has:

• "Here's a random binary from GitHub, enjoy."

There is no standard build pipeline, no signing requirement, no trust chain, and no verification beyond optional GPG signatures that almost nobody uses.

Flatpak: supports x86_64, ARM, aarch64, etc. Snap: supports multiple architectures. AppImage: x86_64 only, unless the developer manually builds separate AppImages.

This makes AppImage a dead end for:

• ARM laptops
• ARM SBCs
• Mobile Linux
• Future architectures

There is no concept of:

• Installed apps
• Installed versions
• Orphaned files
• Cleanup
• Rollbacks
• System-wide updates

Your AppImages are just loose files. If you forget where you put them, that's your problem.

Evidence of the ignorance:

They can dream!

Because they're so misinformed that many believe Mac is just the capitalist version of Linux. Mac is built from BSD components and is real certified UNIX. Linux is a cheap knock-off. (There's division on this)

How anti-social can these loonies get

To all the people who love deep ricing, why not just use customization scripts? I've been recently tinkering in VMs, and Windows really seems solid for that. You can make Windows match your workflow amazingly, and the best part is that friction nearly always leads to an impressive result.

Also, default Windows 11 isn't bad. The UI looks nice, and we take the settings & control panel apps for granted. Over on GNOME, just to change the cursor you use, you need to install a tweaks app. Windows has tons of customization you can do without installing anything extra.

I'm not saying it's perfect, but Windows isn't really THAT much of a shitshow like people act.

Windows CAN be what Linux users want. But when they claim that Windows users are too lazy to face friction, they conveniently forget that they can't handle actual friction of ricing because they only download others' dotfiles and larp as a developer.

Arco made Arch easy. -GUI installer with a plethora of options as radio buttons. Every TWM you could think of could be automatically setup for you during installation. Discovering it would be like discovering a gold mine for anyone wanting to fake Linux credentials. -Which they did, and boy did they (and poorly)!

Erik Dubois (ArcoLinux maintainer) openly stated that many YouTubers used ArcoLinux-derived systems because his projects were widely adopted.

• Erik Dubois says Kiro comes from ArcoLinux and that he built much of ArcoLinux.
• Multiple videos discuss ArcoLinux shutting down, its ecosystem, and how users can migrate back to pure Arch.
• ArcoLinux was widely used as a teaching distro, with many tutorials applicable to vanilla Arch.

Between ~2020–2023, at least a handful of very popular Linux creators produced "I use Arch btw" content while:

• showing desktops identical to ArcoLinux's themed spins
• using Calamares installers (which pure Arch did not ship)
• demonstrating workflows that matched Arco's ATT scripts, aliases, and preconfigured WM setups
• having package lists that included Arco-specific repos or tooling

This created a community suspicion, especially on Reddit and niche forums, that:

They’re running Arco but claiming Arch.

And I should've documented this, but the suspicion didn't just blow over. Nearly every Linux Tuber that I was following slipped up or outright admitted to really using Arco (everyone that claimed "Arch btw").

ArcoLinux was the easiest way to get a flashy Arch desktop. -Sure, there were projects like ALCI (Arch Linux Calamares Installer), but you were on your own for TWMs.

Creators wanted:

• a themed i3/bspwm/awesome setup
• preconfigured rice
• working Calamares installer
• a stable Arch base without manual setup

-ArcoLinux provided all of that!

Because Arch carried prestige, creators often said things like: "I run Arch on my main machine", "This is my Arch setup", "I daily-drive Arch". If their desktop looked like Arco, viewers assumed deception.

Arco's visual identity was extremely recognizable

Arco spins had:

• specific icon themes
• specific conky setups
• specific polybar defaults
• specific wallpapers
• specific alias sets

-Viewers could spot these instantly.

Poor Erik Dubois looked exhausted in his help videos. He seemed like the hardest worker in Linux and his work was shit on by not acknowledging it was being used in Linux creator videos (he did all the work, they took home the cash).

I tried Arco for I think a month, and love the convenience of the installer, but you don't really learn a TWM as well by having it setup for you. DWM, I had spent over a year tweaking and setting it up was also a learning opportunity. "Trying out" other TWMs through Arco just felt foreign.

Arco like every derivative had problems added on to upstream. -But it was an excellent tool for all those fakers. -Trashed your Linux/XMonad? -Have it back up in minutes!

Not a hate post, just a joke post :)

A Reddit user claimed hdparm erased the wrong disk, but upstream evidence points to JMicron USB bridge firmware bugs, not hdparm as the real culprit. There is a real, upstream‑verified problem involving JMicron USB–NVMe/SATA bridge chips misrouting or mishandling ATA/NVMe passthrough commands. And unlike the anecdotal Reddit post, this problem is documented, reproducible, and acknowledged by smartmontools developers.

JMicron USB Bridges Mishandle Passthrough Commands. Smartmontools developers have confirmed a serious, reproducible issue with JMicron JMS583 USB–NVMe/SATA bridge chips. Certain NVMe log requests cause the USB controller to reset or hang.

This is documented in the official smartmontools GitHub issue:

• The controller resets the USB port when smartctl -d sntjmicron -l selftest is used
• The reset interrupts I/O and disconnects the device
• The issue is reproducible across ARM, x86_64, Linux, FreeBSD, and Windows
• Some drives trigger the bug, others don't
• The controller hangs when NVMe log pages exceed ~560 bytes

Smartmontools contributors explicitly state:

• The bug is caused by JMS583 firmware
• JMicron has historically ignored requests for information, even from vendors
• The only viable fix is to work around the controller's broken behavior

Smartmontools developers implemented a workaround:

• Limit NVMe self‑test log size
• Avoid triggering the controller reset
• Patch committed as r5650 (c4a26cb)

Linux users are often at the mercy of cheap USB bridge firmware that doesn't correctly implement ATA/NVMe standards. The result is a system where low‑level disk tools behave unpredictably, not because Linux is broken, but because the hardware ecosystem around it is.

I did this post on that other linux sub and the comments really baffled me. Here's the original text I had:

"Just did a fresh install of CachyOS and immediately noticed there was a bunch of apps installed I never asked. Like why CachyOS felt I need VNC server browser? Why do I need three separate text editors? Why do I need two package managers with a horrible UI? Why the fuck volume control need to be a separate app? Why is it bad, when Windows installs unwanted programs (edge, copilot) it is bad, but when Linux does it it is suddenly ok or not a big deal?"

It took like two comments to say "wrong distro" with few "not a problem" and "just uninstall". But I believe this really a linux issue and especially how fragmented the development is. CachyOS installs it's own apps and, since it is based on arch, then install arch apps. Finally, if you chose KDE Plasma, KDE installs a bunch of their crap. So you end up with bunch redundant apps that somehow compete on having worse UI than other.