hopsayer

Posted on Dec 18

Linux Advanced: Under the Hood - Philosophy And Usage Tips

#architecture #learning #linux

Linux Advanced: Under the Hood - Deep Dive

This is a continuation of "Linux Quick Intro" - covering the technical details, philosophy, and advanced concepts that were glossed over in the beginner guide.

In this article you will discover:

Why Windows is deliberately different - The historical truth behind drive letters and registry
Advanced Linux directories - /proc, /dev, /sys and the virtual filesystem concept
The FHS philosophy - Why standardization beats flexibility
Package management internals - How AUR transforms .deb into native packages
Configuration portability - Set up Linux once, keep it forever
Symlinks vs Windows shortcuts - Why .lnk is a toy and symlinks are serious tools
Wine demystified - It's not emulation (and why that matters)
Context menu sanity - How Linux saved right-click from bloat
Desktop Environment landscape - KDE, GNOME, and the choice that matters
Driver architecture - Why your Wacom "just works"

Part 1: Why Linux Works This Way (And Why Windows Doesn't)

The Historical Truth

Linux (and UNIX before it) came first. When Microsoft created DOS and later Windows, they deliberately made different design choices - not because they were better, but to avoid looking like UNIX. This isn't conspiracy theory - it's documented history.

The result? Drive letters (C:\, D:) instead of a unified root. Registry instead of plain-text configs. Arbitrary install locations instead of standardized paths. These aren't features - they're deliberately different implementations of solved problems.

The bitter pill: Windows only seems "intuitive" because we're conditioned to its quirks. It's like learning a language with irregular grammar first - you think that's normal until you see a properly designed one.

Why This Matters

Linux's standardized paths mean:

Programs know where to find each other's files
Updates don't break things (if you follow the rules)
You can backup your entire configuration in kilobytes
The system doesn't accumulate cruft over time

Windows's approach means:

Program A can't reliably find Program B's data
Every installer asks where to put things
Uninstallers leave registry debris
After 6 months, you "need" to reinstall for "performance"

Part 2: File System Deep Dive

The Directories You Skipped

/proc/ - Not real files. It's a virtual filesystem exposing kernel and process information. Want to see your CPU info? cat /proc/cpuinfo. Current process list? It's all in /proc/. You rarely touch this directly, but system monitoring tools read from here constantly.

/dev/ - Device files. Your hard drive is /dev/sda, partitions are /dev/sda1, etc. Graphics card, USB devices - everything hardware appears here as a file. "Everything is a file" isn't a metaphor in Linux.

/sys/ - Another virtual filesystem for device management and kernel modules.

Symbolic Links: The Right Way

Remember my warning about recreating Windows structure? Here's why it fails:

Bad approach (what beginners try):

# DON'T DO THIS
mkdir /mnt/games  # "My D: drive"
ln -s /mnt/games/* ~/.local/share/Steam/steamapps/common/

Why it breaks:

Steam updates can delete and recreate directories, breaking links
File permissions get confusing (who owns what?)
You now have TWO sources of truth (actual location vs standard location)
Backup tools might follow links or ignore them unpredictably

Proper approach (when actually needed):

# Move ONE specific huge game, link it back
mv ~/.local/share/Steam/steamapps/common/MassiveGame /mnt/games/
ln -s /mnt/games/MassiveGame ~/.local/share/Steam/steamapps/common/MassiveGame

Only redirect specific items. Keep the standard structure intact.

Part 3: Package Management - How It Really Works

Anatomy of a `.deb` Package

When you download a .deb for Ubuntu, it's just a .tar archive with a specific structure:

package.deb
├── bin/
│   └── program_binary
├── lib/
│   └── libsomething.so
└── usr/
    └── share/
        ├── applications/
        │   └── program.desktop
        └── icons/
            └── program.png

Manual installation (educational purposes only):

# Extract
ar x package.deb
tar xf data.tar.xz

# Copy files to matching system paths
sudo cp bin/* /usr/bin/
sudo cp -r usr/share/* /usr/share/

This works, but it's terrible because:

No dependency tracking
No clean uninstall
Updates won't work
You're now maintaining this manually forever

How AUR Actually Works

When you run yay -S onlyoffice-bin, here's the full process:

Download PKGBUILD script from AUR (stored in ~/.cache/yay/onlyoffice-bin/)
Script executes, which:
- Downloads the .deb from OnlyOffice's official site (URL in script)
- Verifies SHA256 checksum (security)
- Extracts the .deb
- Repackages it as .pkg.tar.zst (Arch format)
- Calls sudo pacman -U package.pkg.tar.zst (install local package)
Pacman tracks this in its database - now you can update/remove it properly

For source packages (no -bin):
The PKGBUILD instead:

Downloads source code
Installs build dependencies
Compiles the program (this is why your CPU spikes for 20+ minutes)
Packages the compiled binaries

This is why -bin versions are preferred when available - they skip compilation.

The `yay` vs `yay -S` distinction

yay package_name      # Search ALL packages, let you choose
yay -S package_name   # Install exactly this package name (must be exact)

Practical example:

yay discord
# Shows:
# 1. discord (official repo)
# 2. discord-bin (AUR)
# 3. discord-canary (AUR)
# 4. discord-ptb (AUR)
# Choose: 1

yay -S discord
# Immediately installs 'discord' from official repo, no questions

Part 4: Configuration Management - The .config Philosophy

Why `/etc/` Edits Get Overwritten

When you install a program, it creates default configs in /etc/. Example:

/etc/
└── grafana/
    └── grafana.ini

If you edit /etc/grafana/grafana.ini and later update Grafana, the package manager overwrites this file with the new default.

The Correct Workflow

# 1. Copy to user config
cp -r /etc/grafana ~/.config/

# 2. Edit YOUR copy
nano ~/.config/grafana/grafana.ini

# 3. Done - this won't be touched by updates

Why this is genius:

Your changes persist across updates
You can version-control ~/.config/ (Git)
Reinstalling the OS? Just copy ~/.config/ and ~/ - all your settings are back
Multiple users on one machine? Each has their own configs

Priority system:

~/.config/program/ (user config) - HIGHEST
/etc/program/ (system config)
Built-in defaults in the program itself

The Portability Dream

Your entire personalized Linux setup in one folder:

~/.config/        # 500 KB - hours of customization
~/.local/share/   # Personal data
~/Documents/      # Your files

Reinstalling? Switching distros? New machine?

# Old system
tar -czf my-linux-life.tar.gz ~/.config ~/.local

# New system (after creating same username)
tar -xzf my-linux-life.tar.gz -C ~/

Everything returns: keybindings, themes, application settings, menu customizations. This is why Linux users rarely "need" to reinstall.

Part 5: Desktop Files and Icons - The Separation Mystery

Why Are They Separate?

You asked why .desktop files and icons aren't bundled like Windows .exe + embedded icon. Two reasons:

Historical: Two competing standards (freedesktop.org vs older X11 conventions)
Practical: Icon themes. Change your system theme, ALL icons update without touching each program

The structure:

/usr/share/applications/     # Menu entries
/usr/share/icons/            # Icon theme system
/usr/share/pixmaps/          # Legacy single icons

Your user overrides:

~/.local/share/applications/ # Custom menu entries
~/.local/share/icons/        # Personal icons
~/.icons/                    # Additional personal icons

Creating Custom Launchers

Scenario: You downloaded a portable AppImage.

# 1. Move it somewhere permanent
mkdir -p ~/Applications
mv ~/Downloads/MyApp.AppImage ~/Applications/
chmod +x ~/Applications/MyApp.AppImage

# 2. Create .desktop file
nano ~/.local/share/applications/myapp.desktop

Contents:

[Desktop Entry]
Type=Application
Name=My Application
Exec=/home/yourname/Applications/MyApp.AppImage
Icon=/home/yourname/Applications/myapp-icon.png
Categories=Utility;

Wait 5 seconds. Open your application menu - it's there. No installers, no registry, just a text file.

Part 6: Gaming Deep Dive - Steam, Proton, Wine

How Steam Actually Launches Games

Native Linux game:

Steam → Steam Runtime → Game binary

Windows game:

Steam → Steam Runtime → Proton (Wine) → Game binary

Steam Runtime is a containerized environment with specific library versions. This ensures games work regardless of your distro's library versions - it's like a mini-OS for games.

Wine Is NOT Emulation

Common misconception: "Wine emulates Windows."

Reality: Wine implements Windows API calls natively on Linux.

Analogy: Imagine a program asking "give me file X from C:\Windows\System32\". Wine catches this request and responds: "Here's the equivalent Linux library." The program never knows it's not on Windows.

No CPU emulation = Native performance (often better than Windows due to lower OS overhead)

Why some games work better on Linux:

Example: GTA IV - 25-30 FPS on Windows, stable 60 FPS on Linux/Proton
Reason: Better GPU detection, less background bloat, more efficient memory management

Checking Compatibility

For games: protondb.com

Platinum: Works flawlessly, zero issues
Gold: Works with minor tweaks (usually just launch options)
Silver: Runs but has bugs
Bronze: Barely playable
Garbage: Doesn't work

For Windows programs: appdb.winehq.org (older, less active)

Pro tip: Ask an AI with web search: "What's the best Photoshop version for Wine on Linux?" - users have collectively tested this stuff extensively.

The Steam Filter "Issue"

You noticed the penguin icon filter doesn't change game counts anymore. This is intentional.

Old behavior:

Penguin icon = show only native Linux games
Game count changes based on filter

New behavior (since Steam Deck):

"Enable Steam Play for all titles" is default ON
Steam assumes EVERYTHING can run via Proton
Penguin filter now meaningless (shows all games)

Valve's logic: Proton compatibility is so good (~95%+ of games work) that distinguishing native vs. Windows games is pointless for users.

For enthusiasts: This is "dumbing down" - removes information. For normies: This is "just works" - they don't need to care.

Part 7: The Templates Feature - Right-Click Menu Control

Windows Hell vs Linux Zen

Windows:

Install Adobe Reader → 5 new right-click menu entries
Install WinRAR → 8 new entries
Install 20 programs → Context menu takes 3 seconds to load
No official way to clean this

Linux:

Programs don't automatically add menu entries
You control what appears via the Templates folder

How It Works

Everything in ~/Templates/ appears in "Create New..."

cd ~/Templates/

# Create a blank text file
touch "New Text Document.txt"

# Create a blank PNG
pinta  # (open Pinta, create 800x600 white canvas, save as "New Image.png")

# Create a spreadsheet template
libreoffice --calc  # (create, save as "Budget Template.ods")

Now right-click anywhere:

"New Text Document.txt" appears
"New Image.png" appears
"Budget Template.ods" appears

Advanced: Make templates actually useful. Put a pre-formatted resume, a blank D&D character sheet, your company's letterhead - whatever you create often.

Desktop Environment Differences

KDE (your system): May have some defaults pre-created
GNOME: Completely empty by default - Dark Souls mode
XFCE/MATE: Usually has a basic text file

Part 8: Hardware and Drivers

The `/lib/modules/` Path

Drivers live in /lib/modules/$(uname -r)/ where $(uname -r) is your kernel version.

You almost never touch this manually. Drivers install/update via:

sudo pacman -S linux-headers   # Build environment for drivers
sudo pacman -S nvidia-dkms      # NVIDIA drivers (example)

Wacom Tablets

You mentioned having a Wacom - it likely works out of the box. Linux has excellent Wacom support built into the kernel. No drivers needed.

Test:

xsetwacom --list devices

If it appears, it works. Pressure sensitivity included.

Configure:

KDE: System Settings → Input Devices → Graphic Tablet
GNOME: Settings → Wacom Tablet

Krita (the painting app I mentioned) has native Wacom support and is genuinely used by professional digital artists.

Part 9: The Mindset - Discipline and Standards

Why Linux Developers Are More Disciplined

You noted: "It's strange that Linux, being decentralized, has better standardization than Microsoft with its central control."

The reason: Open source = public accountability.

Microsoft: Internal teams don't see each other's mess. Politics protects bad code.
Linux: Everything is public. Bad design gets called out. Meritocracy (mostly) wins.

Example: The Filesystem Hierarchy Standard (FHS) is a document anyone can read. Everyone follows it because:

It makes sense
Breaking it makes your software incompatible
The community will roast you

The Learning Curve Investment

Timeframe for comfort:

Smart user, focused learning: 2 months
Casual use, learning as needed: 4-6 months
Just following guides blindly: May never truly understand

What changes when you "get it":

You stop thinking "I wish this was more like Windows"
You start thinking "Why isn't Windows more like this?"
You see the elegance in standardization
You trust the system instead of fighting it

When Manual Compilation Is Actually Hard

I've spent 3-6 hours on a single package compilation, sometimes days when dependencies were tangled.

Early attempts: ~20% success rate
After learning: ~90% success rate

But why bother? AUR already has 60,000+ packages. Someone else has already done this work. Use their PKGBUILD.

Only compile manually when:

Cutting-edge development version not in AUR yet
Specific patch you need
Learning/curiosity

Part 10: Practical Troubleshooting Patterns

"I Need Program X, But There's No Arch Package"

Step 1: Search official repos

pacman -Ss program_name

Step 2: Search AUR

yay program_name  # Will show all AUR results

Step 3: Google "program_name arch linux"

You'll find either:
- AUR package you missed
- Wiki page explaining alternative
- Someone's installation guide

Step 4 (rare): Check official website

Download .deb → Extract manually (last resort, unclean)
Download source → Create your own PKGBUILD (advanced)
Use Flatpak/Snap (containerized, bigger downloads)

When Things Break

Config got messed up?

# Don't reinstall the program - just reset its config
rm -rf ~/.config/program_name
# Restart program - fresh defaults

Want to cleanly remove a program?

sudo pacman -R package_name        # Remove program
sudo pacman -Rs package_name       # Remove + unused dependencies
rm -rf ~/.config/package_name      # Remove user configs
rm -rf ~/.local/share/package_name # Remove user data

System update broke something?

# Downgrade to previous version
sudo pacman -U /var/cache/pacman/pkg/package-old-version.pkg.tar.zst

Closing Thoughts

This guide covered what the Quick Intro skipped - the philosophy, the technical depth, and the "why" behind Linux's design decisions.

Key takeaways:

Linux's design isn't arbitrary - it's intentional and well-reasoned
Standards exist for your benefit, not to constrain you
The learning curve is real, but the payoff is a system you actually understand
"User-friendly" often means "hides complexity" - Linux respects your intelligence

What's next?

Part 3 could cover: Wine deep-dive, running Windows software, Photoshop/Office alternatives in detail
Part 4 could be: Customization - themes, window managers, making Linux truly yours
Part 5: Server use, self-hosting, why Linux dominates infrastructure

You've now gone from "What's a /usr/bin/?" to understanding the entire system architecture. That's not a small achievement. Most Windows users don't understand their own OS at this level.

Final wisdom: The frustrations you feel now (remembering paths, using the terminal) are temporary. The understanding you're building is permanent. In a few months, you won't remember Windows fondly - you'll remember it as the training wheels you've outgrown.

Welcome to the deep end. The water's fine once you stop fighting the current.