How to Make Easy Backups on Linux Using a GUI tools Deja Dup, TimeShift, BackinTime, Grsync, Vorta


February 2nd, 2026

Backing up your data on Linux doesn’t have to involve complex terminal commands or custom scripts. While the command line is powerful, many users prefer a simple graphical interface (GUI) that just works.

Luckily, Linux offers several excellent GUI-based backup tools that are easy, reliable, and beginner-friendly.

In this article, we’ll look at why backups matter, and then walk through some of the best GUI backup tools for Linux, along with basic setup tips.

Why Backups Are Important (Even on Linux)

Linux systems are known for stability, but unfortunately, no system is immune to:

  • Hard drive failures
  • Accidental file deletion
  • System updates gone wrong
  • Malware or ransomware
  • Laptop theft or damage

A proper backup ensures you can restore your files or even your entire system in minutes instead of losing everything.

What Makes a Good GUI Backup Tool?

For most desktop users, a good backup tool should :

  • Be easy to use (no terminal required)
  • Supports automatic scheduled backups
  • Allow restoring individual files
  • Work with different types of external drives or network storage
  • Be relatively actively maintained
     

Let’s look at the few tools to create backups with lesser effort.

1. Déjà Dup – The Simplest Backup Tool

Best for: Beginners and home users
Available on: Ubuntu, Linux Mint, Fedora, and others

Déjà Dup is one of the most user-friendly backup tools on Linux. It comes preinstalled on Ubuntu and integrates perfectly with the GNOME desktop.

Key Features

  • Very simple interface
  • Automatic scheduled backups
  • Supports local drives, external USB disks, and network locations
  • Optional encryption for security

# apt info deja-dup
Package: deja-dup
Version: 44.0-2
Priority: optional
Section: utils
Maintainer: Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
Installed-Size: 4,851 kB
Depends: duplicity (>= 0.7.14), dconf-gsettings-backend | gsettings-backend, libadwaita-1-0 (>= 1.2), libc6 (>= 2.34), libglib2.0-0 (>= 2.70.0), libgpg-error0 (>= 1.14), libgtk-4-1 (>= 4.0.0), libjson-glib-1.0-0 (>= 1.5.2), libpackagekit-glib2-18 (>= 1.1.0), libpango-1.0-0 (>= 1.18.0), libsecret-1-0 (>= 0.18.6), libsoup-3.0-0 (>= 3.0.3)
Recommends: gvfs-backends, packagekit, policykit-1
Suggests: python3-pydrive2
Homepage: https://launchpad.net/deja-dup
Tag: admin::backup, implemented-in::c, interface::graphical, interface::x11,
 role::program, scope::application, suite::gnome, uitoolkit::gtk,
 x11::application
Download-Size: 693 kB
APT-Sources: http://ftp.debian.org/debian bookworm/main amd64 Packages
Description: Backup utility
 Déjà Dup is a simple backup tool. It hides the complexity of backing up the
 Right Way (encrypted, off-site, and regular) and uses duplicity as the
 backend.
 .
 Features:
  * Support for local, remote, or cloud backup locations such as Nextcloud
  * Securely encrypts and compresses your data
  * Incrementally backs up, letting you restore from any particular backup
  * Schedules regular backups
  * Integrates well into your GNOME desktop

How to Use Déjà Dup

Using it is generally simplistic, you select the data folders to be backupped and then the media where to backup it. The program supports also encryption with a password which is nice if you want to keep the backed-up data secret (especially if you want to store the backup on Google Cloud or Microsoft Azure)

Open “Backups” from your application menu

  1. Choose folders to back up (e.g., Home folder)
  2. Select a backup location (external drive recommended)
  3. Enable automatic backups


Click on Back Up Now button

That’s it. Déjà Dup runs quietly in the background after setup.

Note ! that it is not a good idea to try to backup the whole Linux installation ! with deja-dup, as you will get a lot of issues with improper permissions errors and stuff and the OS backup won't get consistent, however for a basic backups of User Homes, Cictures and some Personal data situated within a single directory it is simple as it is easy to initially setup and run.

# apt install deja-dup

$ sudo deja-dup

 

deja-dup-backup-gui-tool-linux-screenshot

deja-dup-backup-gui-tool-linux-screenshot2

2. Timeshift – System Snapshots Made Easy

Best for: System recovery
Available on: Most Linux distributions

Timeshift focuses on system backups, not personal files. It creates restore points similar to Windows System Restore.

Key Features

  • Snapshot-based backups
  • Perfect for rolling back failed updates
  • Supports RSYNC and BTRFS
  • Clean and simple GUI
     

When to Use Timeshift

  • Before major system updates
  • After fresh OS installation
  • To recover from broken packages or configs

# apt info timeshift
Package: timeshift
Version: 22.11.2-1+deb12u1
Priority: optional
Section: utils
Maintainer: Yanhao Mo <yanhaocs@gmail.com>
Installed-Size: 3,231 kB
Depends: cron-daemon | cron, pkexec, psmisc, rsync, libc6 (>= 2.34), libcairo2 (>= 1.2.4), libgdk-pixbuf-2.0-0 (>= 2.22.0), libgee-0.8-2 (>= 0.8.3), libglib2.0-0 (>= 2.39.4), libgtk-3-0 (>= 3.16.2), libjson-glib-1.0-0 (>= 1.5.2), libvte-2.91-0, libxapp1 (>= 1.0.4)
Breaks: util-linux (<< 2.37.2~)
Replaces: timeshift-btrfs
Homepage: https://github.com/linuxmint/timeshift
Tag: uitoolkit::gtk
Download-Size: 617 kB
APT-Manual-Installed: yes
APT-Sources: http://ftp.debian.org/debian bookworm/main amd64 Packages
Description: System restore utility
 Timeshift is a system restore utility which takes snapshots
 of the system at regular intervals. These snapshots can be restored
 at a later date to undo system changes. Creates incremental snapshots
 using rsync or BTRFS snapshots using BTRFS tools.

# apt install timeshift

$ sudo timeshift-gtk

 

https://www.pc-freak.net/images/linux-gui-backup-tools-screenshot/timeshift-rsync-backup-gui-tool-linux-screenshot4

timeshift-rsync-backup-gui-tool-linux-screenshot5

timeshift-rsync-backup-gui-tool-linux-screenshot6

3. Use Timeshift alongside a file backup tool like Déjà Dup as a backup solution for OS and data

a. Set up Timeshift (system snapshots)

What to include

Snapshot type:

  • RSYNC → works on any filesystem (recommended)
  • BTRFS → if your root is BTRFS


timeshift-rsync-backup-gui-tool-linux-screenshot1

Include:

  • / (root filesystem)

Exclude home directories (important!)

In Timeshift settings:

  • Keep /root excluded
  • Do NOT include /home/youruser

timeshift-rsync-backup-gui-tool-linux-screenshot2

Timeshift is not meant to back up your personal files.

Schedule (typical)

  • Daily: 3–5 snapshots
  • Weekly: 2–3 snapshots
  • Monthly: optional

Store snapshots on:

A separate drive or partition if possible

b. Set up Deja Dup (personal backups)

Deja Dup is perfect for:

  • Home directory backups
  • Encryption
  • External drives, NAS, cloud (Google Drive, SFTP, etc.)

Folders to back up

Usually:

~/Documents
~/Pictures
(or similar)
Optional: ~/.config (only if you know why)
~/Videos
~/Projects

In Deja Dup:

Folders to back up → select what you actually care about

Folders to ignore → add

~/.cache
~/.local/share/Trash
~/Downloads
(optional)

Schedule

Daily or weekly backup is usually fine

Keep backups for “forever” or at least several months

c. Prevent overlap (this matters)

To avoid wasting space and time:

Tool

Should back up

Should NOT back up

Timeshift

/, system configs

/home

Deja Dup

/home/youruser

/, system files

Never:

  • Use Deja Dup to back up /
  • Use Timeshift to back up /home

That’s the #1 mistake you could do

d. Real-world recovery scenarios

Scenario 1: Bad update / system won’t boot

  1. Boot from live USB

  2. Restore with Timeshift

  3. System is back exactly as before

  4. Files untouched

Scenario 2: Deleted or corrupted files

  1. Open Deja Dup

  2. Restore specific files/folders

  3. Done

Scenario 3: New machine / fresh install

  1. Install OS

  2. Restore system apps/settings manually or via Timeshift (if compatible)

  3. Restore home data with Deja Dup

e. Optional pro tips (to avoid data loss)

  • Test restores once (seriously)
  • Label backup drives clearly
  • Keep Deja Dup backups offsite if possible
  • After major distro upgrades:
  • Make a Timeshift snapshot
  • Don’t restore old Timeshift snapshots across major versions unless you know it’s safe
     

4. Back In Time – More Control features tool to create GUI-Based backups on Linux

Best for: Advanced users who want flexibility

Available on: Most Linux distributions

Back In Time uses RSYNC but wraps it in a friendly GUI.

Key Features

  • Scheduled snapshots
  • Exclude files and folders easily
  • Restore files from any snapshot
  • Supports local and remote backups
     

# apt-cache search backintime


backintime-common – simple backup/snapshot system (common files)
# apt info backintime-qt
Package: backintime-qt
Version: 1.3.3-4
Priority: optional
Section: utils
Source: backintime
Maintainer: Jonathan Wiltshire <jmw@debian.org>
Installed-Size: 416 kB
Depends: backintime-common (= 1.3.3-4), libnotify-bin, pkexec, polkitd, python3-dbus.mainloop.pyqt5, python3-pyqt5, x11-utils, python3:any
Recommends: python3-secretstorage
Suggests: meld | kompare
Conflicts: backintime-kde4
Breaks: backintime-qt4 (<< 1.2.1-0.1~)
Replaces: backintime-kde4, backintime-qt4 (<< 1.2.1-0.1~)
Homepage: https://github.com/bit-team/backintime
Download-Size: 73.8 kB
APT-Sources: http://ftp.debian.org/debian bookworm/main amd64 Packages
Description: simple backup/snapshot system (graphical interface)
 Back In Time is a framework for rsync and cron for the purpose of
 taking snapshots and backups of specified folders. It minimizes disk space use
 by taking a snapshot only if the directory has been changed, and hard links
 for unmodified files if it has. The user can schedule regular backups using
 cron.
 .
 This is the graphical interface for Back In Time.

backintime-qt – simple backup/snapshot system (graphical interface)

# apt install backintime-qt

$ sudo backintime-qt

backintime-linux-backup-gui-easy-tool-screenshot-options

linux-gui-backup-tools-screenshot/backintime-linux-backup-gui-easy-tool-screenshot-options

backintime-linux-screenshot-options-menu

backintime-linux-screenshot-options3

linux-gui-backup-tools-screenshot

It’s slightly more complex than Déjà Dup, but still very manageable.
 

5. Backing Up your Data on Linux with Grsync (rsync GUI frontend backup tool interface)

Grsync is a simple yet powerful graphical tool for backing up data on Linux. It acts as a front-end for rsync, one of the most trusted file synchronization utilities in the Linux world, but removes the need to remember long command-line options. This makes Grsync ideal for users who want reliable backups without extra complexity.

grsync-gui-backup-rsync-tool-linux-screenshot1

With Grsync, you can easily select a source and destination folder, such as backing up your home directory to an external drive or a network location. It supports incremental backups, meaning only changed files are copied after the first run, which saves both time and disk space. Useful options like preserving file permissions, deleting obsolete files, and excluding specific directories (for example, cache or temporary files) can be enabled with simple checkboxes.

Another advantage of Grsync is its safety features. You can perform a dry run to preview what will be copied or deleted before actually starting the backup. This reduces the risk of accidental data loss and makes it easier to fine-tune your backup settings. For Linux users looking for a practical and dependable backup solution, Grsync offers a great balance between power and ease of use.
 

Best Backup Strategy for Desktop Linux Users

For most users, Deja Dup + TimeShift  combo should works perfectly:

  • Déjà Dup → Personal files (documents, photos, videos)
  • Timeshift → System snapshots

This way, you’re protected from both data loss and system failure.

Final Thoughts

Linux gives you freedom – and that includes freedom to choose how you protect your data.

With modern GUI backup tools, there’s no excuse not to back up regularly. Whether you’re a casual user or a hardcore PC freak, setting up backups takes just a few minutes and can save you hours (or days) of frustration later.

If you’re serious about your Linux system data,
backup early, backup often and you this 

will pay you back.

Installing Freedoom, Freedoom Phase 2, and Other DOOMs on GNU / Linux


January 29th, 2026

freedoom-game-on-linux-shot-killed-monster
You think good old DOOM game is Dead ? Think again. 

From graphing calculators and printers to ATMs, traffic signs, refrigerators, and even experimental brain-computer interfaces, DOOM has proven itself less a game and more a force of nature. For decades, developers and hackers have ported it onto devices never meant for fast-paced demon slaying, simply because they could. This strange tradition says as much about DOOM’s elegant design as it does about the creativity – and stubbornness – of the open-source community. Perhaps as a mean of extension people from the free realm decide to create a a playable and free remake of it.

If you want classic DOOM action game to have fun on Linux without proprietary game data, Freedoom is the answer.
It’s free, open source, and designed to be fully compatible with the original DOOM engine ,while still delivering you a monsters to kill, shotguns, and extremely questionable life choices.

This article walks you through installing Freedoom, Phase1  Freedoom Phase 2, and running them with popular DOOM source ports on Linux such as gzdoom and chocolate-doom and freedm.

What Is Freedoom (and Why Should You Care)?

Freedoom is a free replacement for the original DOOM game data (WAD files).

Freedoom comes in two main flavors:

  • Freedoom (Phase 1) – Doom-compatible (monsters, maps, weapons)
  • Freedoom Phase 2 – Doom II – compatible (bigger maps, more enemies, more chaos)
     

Think of them as DOOM and DOOM II, but liberated from copyright hell.

1. Install Freedoom on Linux

On most Linux distributions, Freedoom is available directly from the package manager.

Debian / Ubuntu / Linux Mint

# apt install freedoom

freedoom2-screenshot-linux-phase2

This installs:

  • freedoom1.wad (Phase 1)
  • freedoom2.wad (Phase 2)

You now officially own free DOOM. Congratulations.

$ freedoom1

$ freedoom2

 

freedoom2-linux-game-play-screenshot-with-doom-monsters-free-wad


 

2. Choose a DOOM Engine (a.k.a. Source Port)

Freedoom doesn’t run by itself- you need a DOOM engine to play it. Luckily, Linux has lots of excellent options.

2.1. Chocolate Doom (Classic Experience)

Chocolate Doom aims to recreate exactly how DOOM felt in the 1990s. Same physics, same limits, same pixelated glory.

Doom engines closely-compatible with Vanilla Doom

Chocolate Doom aims to accurately reproduce the original DOS version of

Doom and other games based on the Doom engine in a form that can be

run on modern computers. Unlike most modern Doom engines, Chocolate Doom

is not derived from the Boom source port and does not inherit its

features (or bugs).

 

chocolate-doom package contains:

* Chocolate Doom, a port of Id Software's "Doom" (1993)

* Chocolate Heretic, a port of Raven Software's "Heretic" (1994)

* Chocolate Hexen, a port of Raven Software's "Hexen" (1995)

* Chocolate Strife, a recreation of Rogue Entertainment's "Strife" (1996)

These games are designed to behave as similar to the original DOS version as

is possible.

Chocolate Doom supports all flavors of Doom, including The Ultimate Doom, Doom

2 and Final Doom as well as Chex(R) Quest, HacX, Freedoom: Phase 1 and Phase 2

and FreeDM.

All Chocolate game engines require game data to play. For Chocolate Doom,

free game data is available in the freedoom package. Commercial game data for

all four engines can be packaged using "game-data-packager".

To install it simply run:

# apt install chocolate-doom

Run Freedoom:

$ chocolate-doom -iwad /usr/share/games/doom/freedoom1.wad

Or Doom II–style:

$ chocolate-doom -iwad /usr/share/games/doom/freedoom2.wad

2.2. PrBoom+ (Classic but Smoother)

PrBoom+ keeps the old-school feel but adds:

  • Better performance
  • Higher resolutions
  • Fewer headaches

To install it:

# apt install dsda-doom

Run dsda-doom:

$ dsda-doom -iwad freedoom2.wad

 

freedm-game-entry-screen

Best for:

  • Vanilla gameplay with modern comfort
  • Speedrunners
  • People who want fewer crashes than 1993 allowed

2.3. GZDoom (Modern, Fancy, Wild)

GZDoom is DOOM after drinking several energy drinks:

  • Hardware acceleration
  • Mouse look
  • Mods, lighting, shaders, chaos

Add necessery repository:

$ rm –f /etc/apt/trusted.gpg.d/drdteam.gpg $ rm –f /etc/apt/sources.list.d/drdteam.list
# wget -P /etc/apt/sources.list.d https://debian.drdteam.org/drdteam-$(dpkg –print-architecture).sources
# apt update # apt install gzdoom

 

Run Original Doom WAD:

$ gzdoom -iwad /var/www/files/doom2.wad

doom2-original-wad-gzdoom-doom-linux-screenshot-entry-screen

doom2-original-wad-gzdoom-doom-linux-screenshot-plasma-gun-shot

 

If you need the original doom wads check out my earlier article DOOM 1, DOOM 2, DOOM 3 game wad files for download / Playing Doom on Debian Linux via FreeDoom open source doom engine
Run Freedoom WAD:

$ gzdoom -iwad freedoom2.wad

Best for:

  • Mods
  • Modern controls
  • Turning DOOM into something unrecognizable (but fun)

3. Installing Other DOOM Engines

Once you have an engine, you can play nearly any DOOM-compatible game by pointing it at a WAD file.

Popular options include:

  • FreeDM – A free deathmatch-focused DOOM experience
  • Heretic / Hexen – Fantasy DOOM (if you own the WADs)
  • User-made megawads – Thousands exist, ranging from brilliant to unhinged

Most engines let you load extra content like this:

$ gzdoom -iwad freedoom2.wad -file coolmap.wad

freedoom-exit-screen-cool-doom-text-ascii 3.1. Installing FreeDM Port


Install it with:

# apt install freedm
$ freedm

 

freedm-doom-linux-shot


3.2. Where Are the WAD Files located ?

Typically they are installed to:

/usr/share/games/doom/

Common files:

  • freedoom1.wad
  • freedoom2.wad
  • freedm.wad

You can copy them anywhere if you prefer a custom setup.

3.3. Keyboard, Mouse, and Sanity Settings

After launching:

  • Open Options → Controls
  • Enable mouse look (if using GZDoom)
  • Rebind keys (your pinky deserves mercy)
  • Increase resolution unless you’re feeling retro

Final Thoughts, DOOM A Forever Classic

Freedoom proves that DOOM isn’t just a game—it’s a platform, a culture, and for those born in the mid and beginning of 90s a travel back machine.

On Linux, you get:

  • Free game data
  • Multiple engines
  • Infinite mods
  • Zero DRM
  • Maximum demon destruction 🙂

Whether you want authentic 1993 vibes or modernized mayhem, Freedoom and Linux are a perfect match.
For old school fans and maniacs as well as IT tech guys with nostalgia or hard core angry system administrators this game is a real bliss
as it can be a true anti-stressor and a perfect for as a mean of anger management 🙂

Enjoy the Blast ! Happy Doom-Ing!

How to add Bulgarian language to GCompris Kids education software on Debian 12 GNU / Linux installing gcompris via flatpak next generation package distribution tool


January 26th, 2026

https://www.pc-freak.net/images/install-gcompris-on-linux-via-flatpak-package-distribution-sandboxed-framework.png

As I have a small currently 5.5 years old Kid Dimitar at home and i'm doing my best to make him learn new things and advance in different areas of life and knowledge.

Today Decided to introduce him to Linux4Kids gcompris a KDE educational set of games for small children.
Once installed with simple

# apt install gcompris-qt


It works fine and default version installable from default Debian distribution is fine, except it does not support Bulgarian.

That is again not a nice suprise, as even some pseudo languages like Belarusian are there to set but Bulgarian missing on the default installable pack:

# dpkg -l |grep -i gcompris
ii gcompris-qt 3.1-2 amd64 educational games for small children
ii gcompris-qt-data 3.1-2 all data files for gcompris-qt

After some tampering and unable to find a native .deb port of the latest release and my undesire to move from debian 12 (bookworm) Desktop Linux laptop at the moment to Debian 13 Trixie, i've finally found a way to install it via flatpak:

For those who never used snap package ecosystem or flatpak, here is a shortly synthesis on it:

Flatpak is an open-source, next-generation framework for building, distributing, and running sandboxed desktop applications on Linux.
It enables developers to package apps once and run them on any Linux distribution by including all necessary dependencies.
Flatpak improves security by isolating applications from the host system. 

Flatpaks are containerized applications. They require more space because the bring along their own versions of their dependencies instead of relying on system versions.

While a single application will have greater space requirements, the base images [and potentially overlays] will get shared between them and each successive flatpak will potentially require less overhead.

The pros to using them is that flatpaks are often more current than their distribution packaged versions and they are somewhat isolated from the base system. The cons are that they're not managed with the rest of your system packages, can have slower start times, occasionally have permissions issues, and take up more space.

In some cases, flatpak is a better choice. Sometimes, it's not, and there's no way we can really determine that for you.

Tried up to my best to install the newest version of gcompris which as of time of writting this blog post is gcompris 25.1

 # apt info flatpak|grep -i 'descr' -A8 -B8

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

Recommends: ca-certificates, default-dbus-system-bus | dbus-system-bus, desktop-file-utils, hicolor-icon-theme, gtk-update-icon-cache, libpam-systemd, p11-kit, polkitd | policykit-1, shared-mime-info, xdg-desktop-portal (>= 1.6), xdg-desktop-portal-gtk (>= 1.6) | xdg-desktop-portal-backend, xdg-user-dirs
Suggests: avahi-daemon, malcontent-gui
Conflicts: xdg-app
Replaces: xdg-app
Homepage: https://flatpak.org/
Download-Size: 1,400 kB
APT-Manual-Installed: yes
APT-Sources: http://ftp.debian.org/debian bookworm/main amd64 Packages
Description: Application deployment framework for desktop apps
 Flatpak installs, manages and runs sandboxed desktop application bundles.
 Application bundles run partially isolated from the wider system, using
 containerization techniques such as namespaces to prevent direct access
 to system resources. Resources from outside the sandbox can be accessed
 via "portal" services, which are responsible for access control; for
 example, the Documents portal displays an "Open" dialog outside the
 sandbox, then allows the application to access only the selected file.

 

 

# apt install flatpak

# flatpak remote-add –if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
# flatpak install flathub org.kde.gcompris
# flatpak run org.kde.gcompris


If you have sound glitches of gcompris on Older laptops install all necessery for pipewire run it like that:

# apt install pipewire pipewire-audio-client-libraries pipewire-pulse
 

Try to run it manually with:


# env PULSE_LATENCY_MSEC=60 ; flatpak run org.kde.gcompris

If still sound glithches are present a workaround is to tune PipeWire buffer/quantum size:

PipeWire buffer/quantum size too aggressive?
 

Many crackling issues come from too small quantum. Create ~/.config/pipewire/pipewire.conf.d/99-custom.conf

# vim ~/.config/pipewire/pipewire.conf.d/99-custom.conf
and add:textcontext.properties = {
    default.clock.rate = 48000
    default.clock.quantum = 1024
    default.clock.min-quantum = 512
    default.clock.max-quantum = 2048
}

#systemctl –user restart pipewire pipewire-pulse
 

Create a new wrapper script to run you gcompris easily
 

# vim /usr/local/bin/gcompris.sh

#!/bin/bash
# little hack script to make music streamed via pulseaudio to not have severe glitches when running gcompris latest release on debian 12
# through flatpak
# if not working run cmd
# systemctl –user restart pipewire
LANG=bg_BG.UTF-8
SDL_AUDIODRIVER=pulseaudio
#flatpak run –device=all –socket=pulseaudio org.kde.gcompris
flatpak override –user –env=SDL_AUDIODRIVER=pulseaudio org.kde.gcompris
flatpak override –user –filesystem=~/.config/pipewire:ro org.kde.gcompris
LANG=bg_BG.UTF-8 flatpak run –socket=pulseaudio org.kde.gcompris

# chmod +x /usr/local/bin/gcompris.sh


Hence I run the wrapper script and let the kid enjoy the nice educational stuff while I enjoyed the nice kiddish peaceful music !

# /usr/local/bin/gcompris.sh


install-gcompris-on-linux-via-flatpak-package-distribution-sandboxed-framework

P.S. ! If you get issues with pipewire (if you're using one instead of pulseaudio as I do with my Mate desktop environment you can restart it and relaunch the gcompris nice addition to  tux4kids (see my previous article Tux for Kids (Tux Math, Tux Paint, Tux Typing) 3 games to develop your children Intellect):

# systemctl –user restart pipewire

Enjoy Gcompris !
 

Using GeoIP on Linux: Country-Based Filtering, Logging, and Traffic Control


January 16th, 2026

geoip-on-linux-country-based-filtering-logging-traffic-control-logo

GeoIP is one of those technologies that quietly sits in the background of many systems, yet it can be extremely powerful when used correctly. Whether you want to block traffic from specific countries, analyze access logs, or add geographic context to security events, GeoIP can be a valuable addition to your Linux toolbox.

In this article, we’ll go deeper and look at real GeoIP usage examples for:

  • Log analysis
  • Firewalls
  • Apache HTTP Server
  • HAProxy

All examples are based on typical GNU/Linux server environments.

What Is GeoIP? 

GeoIP maps an IP address to geographic data such as:

  • Country
  • City
  • ASN / ISP (depending on database)

Most modern systems use MaxMind GeoLite2 databases (

.mmdb

format).

Keep in Mind ! :
GeoIP data is approximate. VPNs, proxies, mobile networks, and CGNAT reduce accuracy. GeoIP should be treated as a heuristic, not a guarantee.

1. Installing GeoIP Databases on Linux deb based distro

On Debian / Ubuntu:

#

apt install geoipupdate

Configure

/etc/GeoIP.conf

with your MaxMind license key and run:  

# geoipupdate

Databases are usually stored in:

/usr/share/GeoIP/

2. GeoIP for Log Analysis (to get idea of where does your traffic origins from)

GeoIP with Apache HTTP Server

Apache can use GeoIP in two main ways:

  1. To do IP origin Logging 

  2. Do Access control based on IP origin

An altenartive GeoIP common use is to post-processing logs to find out attempts to breach your security.

Lets say you want to

Find top attacking countries against your SSHd service.

# grep "Failed password" /var/log/auth.log | \
awk '{print $(NF-3)}' | \
while read ip; do geoiplookup $ip; done |
\ sort | uniq -c | sort -nr


This command will provide you a visibility on attack sources georaphical Country origin

3. Installing Apache GeoIP Module

For legacy GeoIP (older systems):

# apt install libapache2-mod-geoip

For modern systems, GeoIP2 is preferred:

# apt install libapache2-mod-geoip2

Enable the module:

# a2enmod geoip2
# systemctl reload apache2

4. Configure GeoIP Logging in Apache (basic config)

Add country code to access logs:

LogFormat "%h %l %u %t \"%r\" %>s %b %{GEOIP_COUNTRY_CODE}e" geoip
CustomLog /var/log/apache2/access.log geoip

This allows you to analyze traffic by country later without blocking users.

5. Country-Based Filter Blocking in Apache based on IP origin

Example: allow only selected countries:

<IfModule mod_geoip2.c>
SetEnvIf GEOIP_COUNTRY_CODE ^(BG|DE)$ AllowCountry
Deny from all
Allow from env=AllowCountry
</IfModule>

Use this carefully. Blocking at the web server layer is better than firewall-level blocking, but still risky if you have global users.

6. Apply GeoIP to Apache Virtual Host

You can apply GeoIP rules per site:

<VirtualHost *:80>
ServerName example.com
<IfModule mod_geoip2.c>
SetEnvIf GEOIP_COUNTRY_CODE CN BlockCountry >
Deny from env=BlockCountry
</IfModule>
</VirtualHost>

This is useful when only specific applications need filtering.

Firewall vs Application Layer GeoIP (Pros and Cons)

Layer

Pros

Cons

Firewall

Early blocking

Hard to debug

Apache

Flexible per-site rules

App overhead

HAProxy

Centralized control

Requires careful config

Logs only

Safest

No blocking

7. Apply GeoIP to HAProxy

HAProxy is an excellent place to apply GeoIP logic because:

  • It sits in front of applications
  • ​Rules are fast and explicit
  • Logging is centralized

a. Preparing GeoIP Filtering to HAProxy service

HAProxy supports GeoIP2 via Lua or native ACLs using

.mmdb

Example directory:

/usr/share/GeoIP/GeoLite2-Country.mmdb

b. GeoIP-Based Access Control Lists ( ACLs ) in HAProxy

Basic country-based blocking:

frontend http_in
bind *:80

acl from_china src -m geoip CN
acl from_russia src -m geoip RU

http-request deny if from_china
http-request deny if from_russia

default_backend web_servers

This blocks traffic early, before it hits Apache or nginx.

c. GeoIP-Based Routing across different haproxy backends

Instead of blocking, you can route traffic differently:


acl eu_users src -m geoip DE FR NL
use_backend eu_backend if eu_users
default_backend global_backend

This is useful for:

  • Geo-based load balancing
  • Regional content
  • Legal compliance separation

d. GeoIP Logging config for HAProxy

Add country code to logs:

log-format "%ci:%cp [%t] %ft %b %s %TR/%Tw/%Tc/%Tr/%Ta %ST %B %CC"

(%CC = country code)

This makes traffic analysis extremely efficient.

Keep in Mind !

Use HAProxy or web server level for enforcement, and firewall GeoIP only when absolutely necessary.

8. Fail2ban + GeoIP: Smarter Bans, Better Context

Fail2ban is excellent at reacting to abusive behavior, but by default it only sees IP addresses, not where they come from. Adding GeoIP allows you to:

  • Tag bans with country information
  • Apply different ban policies per region
  • Detect unusual behavior patterns

a. GeoIP-Enriched Fail2ban Logs

Fail2ban itself doesn’t natively evaluate GeoIP rules, but you can enrich logs post-ban.

Example action script (

/etc/fail2ban/action.d/geoip-notify.conf

):

 


[Definition]
actionban = echo "Banned from $(geoiplookup | cut -d: -f2)" >> /var/log/fail2ban-geoip.log
Enable it in a jail:
[sshd]
enabled = true
action = iptables[name=SSH] geoip-notify

Enable it in a jail:

[sshd]

enabled = true action = iptables[name=SSH] geoip-notify

Resulting log entry:

Banned 185.220.101.1 from Germany

This provides visibility without changing ban logic — a safe first step.


b. Use GeoIP-Aware Ban Policies 

You can also adjust ban times based on country.

Example strategy:

  • Short ban for local country
  • Longer ban for known high-noise regions

This is usually implemented via multiple jails and post-processing scripts rather than direct GeoIP matching inside Fail2ban.

Best practice:
Let Fail2ban do behavior detection — let GeoIP provide context, not decisions.

9. GeoIP with nftables (Linux Modern Firewall Layer)

iptables +

xt_geoip

is considered legacy. On modern systems, nftables is the preferred approach.

a. Using GeoIP Sets in nftables

nftables does not natively include GeoIP, but you can integrate GeoIP via generated IP sets.

Workflow:

  1. Convert GeoIP country IP ranges into nftables sets

  2. Load them dynamically

Example set definition:


table inet filter {
set geo_block {
type ipv4_addr
flags interval
}
}

Populate the set using a script:

nft add element inet filter geo_block { 1.2.3.0/24, 5.6.0.0/16 }

Then apply it:


chain input {
type filter hook input priority 0;
ip saddr @geo_block drop
}

b. Automating GeoIP ->  nftables

Typical automation pipeline:

GeoLite2 → country CSV → IP ranges → nftables set

Run this daily via cron.

Warning:

  • Large country sets = memory usage
  • Firewall reloads must be atomic
  • Test on non-production systems first

10. GeoIP Dashboard: Turning Logs into Insight

Blocking is optional — insight is mandatory.

a. Simple GeoIP Log Dashboard (CLI-Based)

Apache example:

# awk '{print $NF}' /var/log/apache2/access.log | \
sort | uniq -c | sort -nr

Where $NF contains country code.

Sample Result:

1243 US

987 DE

422 FR

310 CN

This already tells a story.

b. Visual Dashboard with ELK / Grafana

For larger environments:

HAProxy / Apache -> JSON logs Enrich logs with GeoIP

Send to:

  • ELK Stack
  • Loki + Grafana
  • Graylog

Metrics you want:

  • Requests per country
  • Errors per country
  • Bans per country
  • Login failures per country

This helps distinguish:

  • Marketing traffic
  • Legit users
  • Background Internet noise

11.  Create a Layered GeoIP Strategy

A sane, production-ready model using GeoIP would include something like:

  1. Logging first
    Apache / HAProxy logs with country codes

  2. Behavior detection
    Fail2ban reacts to abuse

  3. Traffic shaping
    HAProxy routes or rate-limits

  4. Firewall last
    nftables drops only obvious garbage

GeoIP is strongest when it supports decisions, not when it makes them alone.

12. Best Practices to consider

  • Prefer visibility over blocking
  • Avoid blanket country bans
  • Always log before denying

Combine GeoIP with:

  • Fail2ban
  • Rate limits
  • CAPTCHA or MFA
  • Keep GeoIP databases (regularly) updated
  • Test rules with real IPs before deploying

13. Common Mistakes to Avoid

Blocking entire continents Using GeoIP as authentication Applying firewall GeoIP without logs Forgetting database updates Assuming GeoIP accuracy

Close up

GeoIP is not a silver bullet against vampire attacks – but when used thoughtfully, it becomes a powerful signal enhancer and can give you a much broader understanding on what is going on inside your network traffic.

Whether you’re using it to filter out segment of evil intruders based on logs, routing traffic intelligently, or filtering obvious abusea, GeoIP fits naturally into a layered security model and is used across corporations and middle and even small sized businesses nowadays.

Used conservatively, GeoIP follows the classic Unix philosophy:

Small datasets, Simple rules, Real-world effectiveness, combined with rest of tools it gives info and ways to protect better your networks and server infra.

How to Easily Integrate AI Into Bash on Linux with ollama


January 12th, 2026

Essential Ollama Commands You Should Know | by Jaydeep Karale | Artificial  Intelligence in Plain English

AI is more and more entering the Computer scene and so is also in the realm of Computer / Network management. Many proficient admins already start to get advantage to it.
AI doesn’t need a GUI, or a special cloud dashboard or fancy IDE so for console geeks Sysadmins / System engineers and Dev Ops it can be straightly integrated into the bash / zsh etc. and used to easify a bit your daily sys admin tasks.

If you live in the terminal, the most powerful place to add AI is Bash itself. With a few tools and a couple of lines of shell code, you can turn your terminal into an AI-powered assistant that writes commands, explains errors, and helps automate everyday Linux tasks.

No magic. No bloat. Just Unix philosophy with a brain.

1. AI as a Command-Line Tool

Instead of treating AI like a chatbot, treat it like any other CLI utility:

  • stdin → prompt
  • stdout → response
  • pipes → integration

Hardware Requirements of Ollama Server

2. Minimum VM (It runs, but you’ll hate it)

Only use this to test that things work.

  • vCPU: 2
  • RAM: 4 GB
  • Disk: 20 GB (SSD mandatory)
  • Storage type: ( HDD / network storage = bad )
  • Models: phi3, tinyllama

Expect:

  • Very slow pulls
  • Long startup times
  • Laggy responses

a. Recommended VM (Actually usable)

This is the sweet spot for Bash integration and daily CLI use.

  • vCPU: 4–6 (modern host CPU)
  • RAM: 8–12 GB
  • Disk: 30–50 GB local SSD
  • CPU type: host-passthrough (important!)
  • NUMA: off (for small VMs)

Models that feel okay:

  • phi3
  • mistral
  • llama3:8b (slow but tolerable)
 

b. “Feels Good” VM (CPU-only but not painful)

If you want it to feel responsive.

  • vCPU: 8
  • RAM: 16 GB
  • Disk: NVMe-backed storage
  • CPU flags: AVX2 enabled
  • Hugepages: optional but nice

Models:

  • llama3:8b
  • codellama:7b
  • mixtral (slow, but usable)
 

Hypervisor-Specific Advice (Important)

c. KVM / Proxmox (Best choice)

  • CPU type: host
  • Enable AES-NI, AVX, AVX2
  • Use virtio-scsi
  • Cache: writeback
  • IO thread: enabled

d. If running VM on VMware platform

  • Enable Expose hardware-assisted virtualization
  • Use paravirtual SCSI
  • Reserve memory if possible

e. VirtualBox (Not recommended)

  • Poor CPU feature exposure
  • Weak IO performance

Avoid if you can

f. Local AI With Ollama (Recommended)

If you want privacy, low latency, and no API keys, Ollama is currently the easiest way to run LLMs locally on Linux.

3. Install Ollama

# curl -fsSL https://ollama.com/install.sh | sh


Start the service:

# ollama serve

Pull a model (lightweight and fast):

# ollama pull llama3

Test it:

ollama run llama3 "Explain what the ls command does"

If that works, you’re ready to integrate.

To check whether all is properly setup after installed llama3:

root@haproxy2:~# ollama list
NAME             ID              SIZE      MODIFIED
llama3:latest    365c0bd3c000    4.7 GB    About an hour ago

root@haproxy2:~# systemctl status ollama
● ollama.service – Ollama Service
     Loaded: loaded (/etc/systemd/system/ollama.service; enabled; preset: enabled)
     Active: active (running) since Mon 2026-01-12 16:43:30 EET; 15min ago
   Main PID: 37436 (ollama)
      Tasks: 16 (limit: 6999)
     Memory: 5.0G
        CPU: 13min 5.264s
     CGroup: /system.slice/ollama.service
             ├─37436 /usr/local/bin/ollama serve
             └─37472 /usr/local/bin/ollama runner –model /usr/share/ollama/.ollama/models/blobs/sha256-6a0746a1ec1aef3e7ec53>

яну 12 16:45:34 haproxy2 ollama[37436]: llama_context: Flash Attention was auto, set to enabled
яну 12 16:45:34 haproxy2 ollama[37436]: llama_context:        CPU compute buffer size =   258.50 MiB
яну 12 16:45:34 haproxy2 ollama[37436]: llama_context: graph nodes  = 999
яну 12 16:45:34 haproxy2 ollama[37436]: llama_context: graph splits = 1
яну 12 16:45:34 haproxy2 ollama[37436]: time=2026-01-12T16:45:34.959+02:00 level=INFO source=server.go:1376 msg="llama runner>
яну 12 16:45:34 haproxy2 ollama[37436]: time=2026-01-12T16:45:34.989+02:00 level=INFO source=sched.go:517 msg="loaded runners>
яну 12 16:45:35 haproxy2 ollama[37436]: time=2026-01-12T16:45:35.000+02:00 level=INFO source=server.go:1338 msg="waiting for >
яну 12 16:45:35 haproxy2 ollama[37436]: time=2026-01-12T16:45:35.001+02:00 level=INFO source=server.go:1376 msg="llama runner>
яну 12 16:55:58 haproxy2 ollama[37436]: [GIN] 2026/01/12 – 16:55:58 | 200 |    3.669915ms |       127.0.0.1 | HEAD     "/"
яну 12 16:55:58 haproxy2 ollama[37436]: [GIN] 2026/01/12 – 16:55:58 | 200 |   42.244006ms |       127.0.0.1 | GET      "/api/>
root@haproxy2:~#

4. Turning AI Into a Bash Command

Let’s create a simple AI helper command called ai.

Add this to your ~/.bashrc or ~/.bash_aliases:

ai() {

  ollama run llama3 "$*"

}

Reload your shell:

$ source ~/.bashrc


Now you can do things like:

$ ai "Write a bash command to find large files"

 

$ ai "Explain this error: permission denied"

$ ai "Convert this sed command to awk"


At this point, AI is already a first-class CLI tool.

5. Using AI to Generate Bash Commands

One of the most useful patterns is asking AI to output only shell commands.

Example:

$ ai "Give me a bash command to recursively find .log files larger than 100MB. Output only the command."

Copy, paste, done.

You can even enforce this behavior with a wrapper:

aicmd() {

  ollama run llama3 "Output ONLY a valid bash command. No explanation. Task: $*"

}

Now:

$ aicmd "list running processes using more than 1GB RAM"

Danger note: always read commands before running them. AI is smart, not trustworthy.

6. AI for Explaining Commands and Logs

This is where AI shines.

Pipe output directly into it:

$ dmesg | tail -n 50 | ai "Explain what is happening here"

Or errors:

$ make 2>&1 | ai "Explain this error and suggest a fix"

You’ve just built a terminal-native debugger.

7. Smarter Bash History Search

You can even use AI to interpret your intent instead of remembering exact commands:

aih() {

  history | ai "From this bash history, find the best command for: $*"

}

Example:

$ aih "compress a directory into tar.gz"

It’s like Ctrl+R, but semantic.

8. Using AI With Shell Scripts

AI can help generate scripts inline:

$ ai "Write a bash script that monitors disk usage and sends a notification when it exceeds 90%"

You’re not replacing scripting skills – you’re accelerating them.

Think of AI as:

  • a junior sysadmin
  • a documentation search engine
  • a rubber duck that talks back

9. Where Ollama Stores Its Data

Depending on how it runs:

System service (most common)

Models live here:

/usr/share/ollama/.ollama/

Inside:

models/

blobs/

User-only install

~/.ollama/

Since you installed as root + systemd, use the first path.

See What’s Taking Space

# du -sh /usr/share/ollama/.ollama/*

Typical output:

  • models/ → metadata
  • blobs/ → the big files (GBs)

10. Remove Unused Models (Safe Way)

List models Ollama knows about:

# ollama list

Remove a model properly:

# ollama rm llama3

This removes metadata and unreferenced blobs.

Always try this first.

11. Full Manual Cleanup (Hard Reset)

If things are broken, stuck, or you want a clean slate:

Stop Ollama

# systemctl stop ollama

Delete all local models and cache

# rm -rf /usr/share/ollama/.ollama/models

# rm -rf /usr/share/ollama/.ollama/blobs

(Optional but safe)

# rm -rf /usr/share/ollama/.ollama/tmp

Start Ollama again

# systemctl start ollama

Ollama will recreate everything automatically.

Verify Cleanup Worked

# du -sh /usr/share/ollama/.ollama

# ollama list

You should see:

  • Very small disk usage
  • Empty model list

Prevent Disk Bloat (Highly Recommended)

Only pull small models on VMs

Stick to:

  • phi3
  • mistral
  • tinyllama

Remove models you don’t use

# ollama rm modelname

Set a custom data directory (optional)

If /usr is small, move Ollama data:

# systemctl stop ollama

# mkdir -p /opt/ollama-data

# chown -R ollama:ollama /opt/ollama-data

Edit service:

# systemctl edit ollama

Add:

[Service]

Environment=OLLAMA_HOME=/opt/ollama-data

Then:

# systemctl daemon-reload

# systemctl start ollama

Quick “Nuke It” One-Liner (Use With Care)

Deletes everything Ollama-related:

# systemctl stop ollama && rm -rf /usr/share/ollama/.ollama && systemctl start ollama

API-Based Option (Cloud Models)

If you prefer cloud models (OpenAI, Anthropic, etc.), the pattern is identical:

  • Use curl
  • Pass prompt
  • Parse output

Once AI returns text to stdout, Bash doesn’t care where it came from.

12. Best Practices how to use shell AI to not overload machine

Before you go wild:

  • Don’t auto-execute AI output
  • Don’t run AI as root
  • Treat responses as suggestions
  • Version-control important scripts
  • Keep prompts specific
     

AI is powerful — but Linux still assumes you know what you’re doing.

Sum it up

Adding AI to Bash isn’t about replacing skills.
It’s about removing friction.

When AI gets easy to use from the command line it is a great convenience for those who don't want to switch to browser all the time and copy / paste like crazy.
AI as a command-line tool fits perfectly into the Linux console:

  • composable
  • scriptable
  • optional
  • powerful

Once you’ve used AI from inside your shell for a few hours, going back to browser-based AI chat stuff like querying ChatGPT feels… slow and inefficient.
However keep in mind that ollama is away from perfect and has a lot of downsides and ChatGPT / Grok / DeepSeek often might give you better results, however as ollama is really isolated and non-depend on external sources your private quries will not get into a public AI historic database and you won't be tracked.
So everything has its Pros and Cons. I'm pretty sure that this tool and free AI tools like those will certainly have a good future and will be heavily used by system admins and
programmers in the coming future.
The terminal just got smarter. And it didn’t need a GUI to do it.

How to Optimize Debian Linux on old Computers to Get improved overall Speed, Performance and Stability


December 30th, 2025

tuning-debian-linux-to-work-quickly-and-smooth-on-old-pc-laptop-hardware

 

How to optimize Debian version 12.12 Linux OS to work responsive on Old ThinkPad laptops like from year 2008 Thinkpad R61 with Window Maker, zram, SSD etc.

Old computers aren’t obsolete but most worthy if you dont want to spend on extra hardware.

With the right setup, Debian Linux can run smoothly on hardware that’s more than a decade old. This article walks through a real-world, proven configuration using a classic ThinkPad R61 (Core 2 Duo, 4 GB RAM, SSD), but the principles apply to many older PCs as well.

Why use Debian Linux on old hardware?

Debian Stable is ideal for old hardware because it offers:

  • Low baseline resource usage
  • Long-term stability
  • Minimal background activity
  • Excellent support for lightweight desktops
  • Flexible and well organized and relatively easy to tune

Paired with a minimal window manager, Debian easily outperforms many “lightweight” distros that still ship heavy defaults.

Hardware Baseline PC setup

Test system:

  • Laptop: ThinkPad R61
  • CPU: Intel Core 2 Duo
  • RAM: 4 GB
  • Storage: SATA SSD
  • Graphics: Intel X3100 / NVIDIA NVS 140M
  • Desktop: Window Maker

This is a common configuration for late-2000s business laptops.

1. Desktop Environment: Keep It Simple

Heavy desktop environments is the main factor to slow down an old PC.
Where possible dont use the Desktop environment at all and stick to console.

Recommended:

  • Window Maker (used by myself)
  • Openbox
  • Fluxbox
  • IceWM

Avoid:

  • GNOME
  • KDE Plasma
  • Cinnamon

Window Maker is especially effective: no compositing, no animations, minimal memory usage.

2. Terminal Choice Matters

For console-based applications (games, tools, system utilities), use a terminal that correctly reports its size. Lets say you use xterm:

$ xterm

You can force a usable terminal size like this:

$ xterm -geometry 80×32 &

This avoids common issues with console applications failing due to incorrect terminal dimensions.

Install urxvt (best choice for terminal productivity)

Open a terminal and run:

# apt update
# apt install rxvt-unicode

Optional (if you want tabbed terminal use suckless):

# sudo apt install suckless-tools

  • rxvt-unicode-256color → main terminal (n/a in debian) have to install third party  
  • rxvt-unicode-256color-perl → Perl extensions (tabs, URL click, etc.) (n/a in debian, installable via third party)
  • suckless-tools → includes tabbed, can be used as an alternative for tabs

a. Configure .Xresources

Create or edit ~/.Xresources:

$ vim~/.Xresources

Example for beautiful setup with tabs, transparency, and fonts:

! Basic appearance
! URxvt.font: xft:FiraCode Nerd Font Mono:size=12
 URxvt.background: [90]#1c1c1c
 URxvt.foreground: #c0c0c0
! URxvt.cursorColor: #ff5555
! URxvt.saveLines: 10000
! URxvt.scrollBar: false
! URxvt.borderLess: true

! Enable tabs using built-in tabbed extension
URxvt.perl-ext-common: default,tabbed

! Tab colors
URxvt.tabbed.tabbar-fg: 15
URxvt.tabbed.tabbar-bg: 0
URxvt.tabbed.tab-fg: 2
URxvt.tabbed.tab-bg: 8

! Keybindings for tabs
! Ctrl+Shift+N → new tab
URxvt.keysym.Control-Shift-N: perl:tabbed:new_tab
! Ctrl+Shift+W → close tab
URxvt.keysym.Control-Shift-W: perl:tabbed:close_tab
! Ctrl+Tab → next tab
URxvt.keysym.Control-Tab: perl:tabbed:next_tab
! Ctrl+Shift+Tab → previous tab
URxvt.keysym.Control-Shift-Tab: perl:tabbed:prev_tab
! Tabs keybindings
URxvt.keysym.Control-N: perl:tabbed:new_tab
URxvt.keysym.Control-W: perl:tabbed:close_tab

 

b. Apply .Xresources changes

Run:

$ xrdb ~/.Xresources

Then launch urxvt:

$ rxvt

  • Ctrl+Shift+T → new tab
  • Ctrl+Shift+W → close tab

c. Optional: Make it even cooler

  1. Install powerline fonts or Nerd Fonts (for fancy prompt icons):

# apt install fonts-firacode

  1. Enable URL clicking and clipboard (already enabled above)

  2. Combine with tmux for extra tabs/panes, session management, and more shortcuts.

3. Retain only last 500MB from journald

Retain only the past 500 MB:

# journalctl –vacuum-size=500M

This is exteremely useful as sometimes failing services might generate ton of unnecessery logs and might flood up the old machine hard disk.

4. Reduce journal memory footprint

# vim /etc/systemd/journald.conf

Set Storage=volatile
Set RuntimeMaxUse=50M

# systemctl restart systemd-journald

5. Trim services boot times

# systemd-analyze blame
# systemd-analyze critical-chain

This tells you which services slow down your boot the most.

6. Disable Unnecessary Services

Old systems benefit massively from disabling unused background services.

Check what’s enabled:

# systemctl list-unit-files –state=enabled

Common candidates to disable (if not needed):

# systemctl disable bluetooth
# systemctl disable cups
#systemctl disable avahi-daemon

#systemctl disable ModemManager

Each disabled service saves RAM and CPU cycles.

7. Dirty Page Tuning (Reduces Freezes)

Defaults favor servers, not laptops.

Edit:

# vim /etc/sysctl.conf

Add:

vm.dirty_background_ratio=5
vm.dirty_ratio=10

This forces writeback earlier, preventing sudden stalls.

8. Memory Tuning: zram Done Right

Does zram make sense with 4 GB RAM and an SSD?

Yes it could, but only in moderation.

zram compresses memory in RAM and acts as fast swap. On a Core 2 Duo, compression overhead is small and the benefit is smoother multitasking.

Recommended zram configuration

Install zram-tools deb package:

# apt install zram-tools

Edit:

# vim /etc/default/zramswap

Set:

PERCENT=15

This creates ~600 MB of compressed swap — enough to absorb memory spikes without wasting RAM.

9. Keep Disk Swap (But Small)

Even with zram, disk swap is useful as a fallback.

Recommended:

  • 1–2 GB swap on SSD
  • zram should have higher priority than disk swap

Check:

# swapon –show

10. Swappiness and Cache Pressure

Tune the kernel to prefer RAM and zram first:

# vim /etc/sysctl.conf

Add:

vm.swappiness=10
vm.vfs_cache_pressure=50

Apply:

# sysctl -p

This prevents early swapping and keeps the system responsive.

11. CPU Governor: A Hidden Performance Win

Older ThinkPads often run conservative CPU governors.

Install tools:

# apt install cpufrequtils

Set a balanced governor:

# echo 'GOVERNOR="ondemand"' | sudo tee /etc/default/cpufrequtils

# systemctl restart cpufrequtils

This allows the CPU to ramp up quickly when needed.

12. Power and Thermal Management (ThinkPad-Specific)

Install TLP:

# apt install tlp
# systemctl enable tlp
# systemctl start tlp

TLP improves:

  • Battery life
  • Thermal behavior
  • SSD longevity

Defaults are usually perfect – no heavy tuning required.

13. Disable Watchdogs (If You Don’t Debug Kernels)

Watchdogs waste cycles on old CPUs.

Check:

# lsmod | grep watchdog

Disable:

# vim /etc/modprobe.d/blacklist.conf

Add:

blacklist iTCO_wdt
blacklist iTCO_vendor_support

Reboot.

14. Reduce systemd Noise

systemd logs aggressively by default.

Edit:

#vim/etc/systemd/journald.conf

Set:

Storage=volatile
RuntimeMaxUse=50M

Then:

#systemctl restart systemd-journald

Less disk I/O, faster boots.

15. Use tmpfs for caching and Volatile Junk

Put garbage in RAM, not SSD.

Edit:

# vim /etc/fstab

Add:

tmpfs /tmp tmpfs noatime,nosuid,nodev,mode=1777,size=256M 0 0

Optional:

tmpfs /var/tmp tmpfs noatime,nosuid,nodev,size=128M 0 0
# mount -a

16. IRQ Balance: Disable It (might slow down machine)

On single-socket old laptops, irqbalance can hurt.

Disable:

# systemctl disable irqbalance

Test performance; re-enable if needed.

17. Reduce systemd Timeout Delays

Old laptops often wait forever on dead hardware.

Edit:

# vim /etc/systemd/system.conf

Set:

DefaultTimeoutStartSec=10s
DefaultTimeoutStopSec=10s

18. Strip Kernel Modules You Don’t Use

If you don’t use:

  • FireWire
  • Bluetooth
  • Webcam

Blacklist them:

# vim /etc/modprobe.d/blacklist-extra.conf

Example:

blacklist firewire_ohci
blacklist firewire_core
blacklist uvcvideo
blacklist bluetooth

 

Faster boot, fewer interrupts.

19. X11 Performance Tweaks (Intel Graphics)

Create:

# vim/etc/X11/xorg.conf.d/20-intel.conf

Add:

Section "Device"
Identifier "Intel Graphics"
Driver "intel"
Option "TearFree" "false"
Option "AccelMethod" "sna"
EndSection

20. Disable IPv6 (if not used)

Saves a little RAM and startup time.

Edit:

# vim/etc/sysctl.conf

Add:

net.ipv6.conf.all.disable_ipv6=1
net.ipv6.conf.default.disable_ipv6=1

21.Lower Kernel Log Level verbosity

Stop kernel spam.

# dmesg -n 3

Make permanent:

# vim/etc/sysctl.conf

Add:

kernel.printk=3 4 1 3

22.Scheduler Latency (Advanced)

For desktop interactivity:

# vim/etc/sysctl.conf

Add:

kernel.sched_autogroup_enabled=1

Helps UI responsiveness under load.

23.Kill Browser Bloat (Biggest Win)

For Firefox ESR:

  • Disable telemetry
  • Enable tab unloading

browser.sessionstore.interval = 300000

No kernel tweak beats this.

 

a. Enable tab unloading (automatic tab discard)

  1. Open Firefox ESR
    Type

  2. about:config

  3. in the address bar.
  4. Accept the warning: “This might void your warranty.”

  5. Search for the following preference:

browser.tabs.unloadOnLowMemory

  • Default: false
  • Set to: true
     

This enables Firefox to unload inactive tabs automatically when memory is low.

b. Optional tuning

Some other preferences you can tweak:

Preference

Description

Suggested value

 

browser.tabs.maxSuspendedTabs

 

Maximum number of tabs that can be suspended

10–20

 

browser.tabs.autoHide

 

Auto-hide tabs while suspended (older ESR versions)

true

 

browser.tabs.loadInBackground

 

Background tabs load in suspended state

true

 

browser.sessionstore.interval

 

How often session is saved (ms)

15000

These may vary slightly depending on ESR version.

24. Graphics Considerations

ThinkPad R61 models typically have:

  • Intel X3100 → works well out of the box
  • NVIDIA NVS 140M → use nouveau driver

Recommendations:

  • Avoid proprietary legacy NVIDIA drivers
  • No compositing
  • Simple themes only

25. Extremely for Geeks, Build a Custom Kernel (Optional)

Only if you have plenty of time and you have a developers background and maniacal tendencies 🙂

Benefits:

  • Smaller kernel
  • Faster boot
  • Fewer interrupts

Cost:

  • Maintenance burden

26. Application Choices Matter More Than Tweaks

Keep in mind the application choices matter more than tweeks.
Even the best-tuned system can be ruined by heavy applications.

Recommended software:

  • Browser: Firefox ESR
  • File manager: PCManFM
  • Terminal: xterm, rxvt
  • Editor: nano, geany

Limit browser tabs and disable unnecessary extensions.

27. Things Not to Do

Avoid:

  • Huge zram sizes (50%+)
  • Do not Disable swap entirely
  • Beware of Aggressive kernel “performance hacks”
  • Disable any Heavy desktop effects if choosing to run MATE or alike GUI environment

Stability beats micro-optimizations.

Final Recommended Configuration

For a ThinkPad R61 with 4 GB RAM and SSD perhaps the best Linux configuration would be:

  • Debian Stable
  • Window Maker
  • zram: 15%
  • SSD swap: 1–2 GB
  • swappiness: 10
  • TLP enabled
  • No compositor
     

This setup would deliver:

  • Smooth multitasking
  • No UI lag
  • Minimal CPU overhead
  • Long-term stability

Conclusion

Old PCs don’t need to be fast necessery, but can be made work slightly faster, though the limits if used in a proper way with the right software and without out the eye candy nonse of today, they be still fully functionally used.

With Debian, a lightweight window manager, and sensible memory tuning, even 15-year-old + old hardware remains useful today for common daily tasks, and makes it not only useful but fun and different especially if you are a sysadmin or a developer who needs mostly console and a browser.

It gives you another perspective on how to do your computing in a simplier and more minimalistic way.

Of course do not expect the Old Hardware PC to be the perfect station for youtube maniacs, heavy gamers or complete newbies, who dont honor the old PC limited resources and don't want to have a bit of experimental approach to the PC.

Anyways by implementing before mentioned tweaks, they will reward you with reliability and simplicity  – something modern over complicated OS and Apps often lack.

Enjoy and Happy Christmas 2025 and Happy New Year 2026 soon ! 🙂

How to Deploy Central DNS on Linux with 3 Authoritative Servers and 1 Recursive Cache


December 19th, 2025

unbound-centrall-dns-deployment-3-linux-authoritative-servers-and-1-caching-DNS

Centralized DNS is one of those services that must be always UP, predictable, and fast. When it isn’t, everything breaks in strange and unpleasant ways.

This article describes a robust central DNS architecture for Linux environments using:

  • 3 authoritative DNS servers
  • 1 dedicated caching resolver
  • Clear separation between authoritative and recursive roles

Architecture Overview

Roles

Server

Role

Purpose

dns-auth-01

Authoritative

Primary (master)

dns-auth-02

Authoritative

Secondary (slave)

dns-auth-03

Authoritative

Secondary (slave)

dns-cache-01

Recursive / Cache

Internal resolution

Why Separate Roles?

Authoritative and recursive DNS have very different workloads:

  • Authoritative DNS: predictable, zone-based, read-only
  • Recursive DNS: bursty, cache-heavy, user-facing

Mixing them increases attack surface, complexity, and failure impact.

Software Choices

Recommended stack:

  • BIND9 or NSD for authoritative servers
  • Unbound for caching/recursive resolver

Reasons:

  • Mature, well-understood behavior
  • Clear separation of responsibilities
  • Excellent Linux support
  • Scriptable and observable

Network Layout

Example internal layout:

10.0.0.10   dns-auth-01 (master)

10.0.0.11   dns-auth-02 (slave)

10.0.0.12   dns-auth-03 (slave)

10.0.0.20   dns-cache-01 (recursive)

All Linux servers point only to dns-cache-01 as their resolver.

Authoritative DNS Configuration

Master Server (dns-auth-01)

Zones are managed only on the master.

Example BIND zone definition:

zone "example.internal" {

    type master;

    file "/etc/bind/zones/example.internal.zone";

    allow-transfer { 10.0.0.11; 10.0.0.12; };

    also-notify { 10.0.0.11; 10.0.0.12; };

};

Key points:

  • Zone transfers restricted by IP
  • NOTIFY enabled for fast propagation
  • No recursion enabled

Disable recursion:

options {

    recursion no;

    allow-query { any; };

};

Slave Servers (dns-auth-02 / dns-auth-03)

Example configuration:

zone "example.internal" {

    type slave;

    masters { 10.0.0.10; };

    file "/var/cache/bind/example.internal.zone";

};

Slaves:

  • Never edited manually
  • Automatically sync zones
  • Serve as HA and load distribution

Caching Resolver (dns-cache-01)

Use Unbound as a dedicated recursive resolver.

Unbound Configuration

Minimal but effective setup:

server:

    interface: 0.0.0.0

    access-control: 10.0.0.0/24 allow

    do-ip6: no

    hide-identity: yes

    hide-version: yes

    prefetch: yes

    cache-min-ttl: 300

    cache-max-ttl: 86400

Forward Internal Zones to Authoritative Servers

forward-zone:

    name: "example.internal"

    forward-addr: 10.0.0.10

    forward-addr: 10.0.0.11

    forward-addr: 10.0.0.12

External Resolution

Either:

  • Use root hints (recommended for independence)
  • Or forward to trusted upstream resolvers

Example:

forward-zone:

    name: "."

    forward-addr: 9.9.9.9

    forward-addr: 1.1.1.1

Client Configuration

All Linux servers use the caching resolver only:

/etc/resolv.conf

nameserver 10.0.0.20

Or via systemd-resolved:

# resolvectl dns eth0 10.0.0.20

Clients never query authoritative servers directly.

High Availability Considerations

Resolver Redundancy

For production environments:

  • Deploy two caching resolvers
  • Use DHCP or systemd-resolved fallback ordering

Example:

nameserver 10.0.0.20

nameserver 10.0.0.21

Zone Management

  • Store zone files in Git
  • Increment SOA serials automatically
  • Deploy via CI/CD or Ansible

DNS changes should be auditable, not ad-hoc.

Security Hardening

Minimum recommendations:

  • No recursion on authoritative servers
  • Firewall restricts TCP/UDP 53
  • TSIG for zone transfers (optional but recommended)
  • Disable version disclosure
  • Monitor query rates

Monitoring & Validation

Useful tools:

  • dig +trace
  • unbound-control stats
  • rndc status
  • Prometheus exporters for BIND/Unbound

DNS that isn’t monitored will fail silently.

Final Thoughts

This setup scales well, is easy to reason about, and avoids the most common DNS mistakes:

  • Mixing recursive and authoritative roles
  • Letting clients query everything directly
  • Overcomplicating zone management

DNS should be boring.
If it’s exciting, something is wrong.

Why SSH Login Is Slow on Linux and How to Fix It


December 18th, 2025

openssh_debug-and-fix-slow-connections-to-linux-how-to-original-openssh-logo

Slow SSH logins are one of those problems that don’t look serious at first — until you realize every connection takes 20–30 seconds to respond. The shell eventually appears, but the delay is long enough to break automation, frustrate users, and make admins suspicious of deeper system issues.

This article walks through some common causes of slow SSH logins and how to diagnose them efficiently on Linux servers.

1. DNS Lookups: The Most Common Culprit

By default, sshd performs a reverse DNS lookup on the connecting IP address. If DNS is misconfigured or unreachable, SSH will wait.

How to Test

From the server (measure how many seconds it takes to do ssh to the machine):
 

$ time ssh localhost

If localhost logins are instant but remote logins are slow, suspect DNS.

Check /etc/ssh/sshd_config:

UseDNS yes

Fix

Disable DNS lookups (at least temporary to test):

UseDNS no

Then restart SSH:

# systemctl restart sshd

Note: This does not reduce security in most environments and is safe for the majority of servers.

2. Broken or Slow PAM Modules

PAM (Pluggable Authentication Modules) can introduce delays — especially if modules depend on:

  • LDAP
  • Kerberos
  • Network home directories
  • Smart card services

Debug with Verbose SSH

From the client:

$ ssh -vvv user@remote-server

Look for pauses during:

debug1: Authentications that can continue:

Test PAM Delay

Temporarily disable PAM in /etc/ssh/sshd_config:

UsePAM no

Restart SSH and test again.
If login becomes instant, inspect /etc/pam.d/sshd.

3. Entropy Shortage on Virtual Machines

Older kernels or low-activity VMs can run out of entropy, causing SSH key operations to block.

Check Entropy Level

# cat /proc/sys/kernel/random/entropy_avail

Values below 100 may cause delays.

Fix

Install an entropy daemon (if on Deb based distro):

# apt install haveged

or on CentOS / RHEL / Fedora

# yum install rng-tools

Then start the service:

# systemctl enable –now haveged

4. GSSAPI Authentication Delay

SSH attempts Kerberos authentication even when not used.

Symptom

Delay occurs before password prompt appears.

Fix

Edit /etc/ssh/sshd_config:

GSSAPIAuthentication no

GSSAPICleanupCredentials no

Restart SSH afterward.

5. Slow Home Directory or Shell Initialization

Sometimes SSH is fast, but the shell is slow.

Test with a Minimal Shell

$ ssh user@server /bin/sh

If this is instant, check:

  • .bashrc
  • .profile
  • .bash_logout

Common mistakes:

  • Network calls (curl, wget)
  • Mounted NFS home directories
  • Broken PATH exports
  • Commands waiting on unavailable resources

6. Logging and Timing the Login Process

Enable SSH debug logging in /etc/ssh/sshd_config:

LogLevel DEBUG

Then watch logs:

# journalctl -u sshd -f

or:

# tail -f /var/log/auth.log

This allows you to see exactly where the delay happens.

7. A Systematic Troubleshooting Checklist

  1. Disable DNS lookups (UseDNS no)
  2. Disable GSSAPI
  3. Test PAM
  4. Check entropy
  5. Test minimal shell
  6. Review auth logs

In practice, 90% of slow SSH issues are DNS or PAM related.

Conclusion

But wait there might be much more behind the SSH slowness such as misconfigured LDAP or other infrastructure in the middle.
Slow SSH logins are rarely “just SSH.", and though this guide should help you with some sporadic random server issues, if the issues is present on a complex infra with multiple ssh servers, then  that is almost always a symptom of:

  • Network misconfiguration
  • Over-engineered authentication
  • Broken assumptions about system dependencies

Approaching the problem methodically saves hours of guesswork and restores what SSH is supposed to be, work without glitches.

How to Harden a Linux Server in 2025 – Practical Steps for Sysadmins to protect against hackers and bots


December 11th, 2025

linux_server-hardening-practical-steps-for-sysadmins-protecting-machine-vs-hackers-and-bots-good-practices

Securing a Linux server has never been more importan than ever these days..
With automated attacks, AI-driven exploits, and increasingly complex infrastructure, even a small misconfiguration can lead to a serious breach.
But wait, you don't have to wait to get bumped by a random script kiddie. Good news is you can mitigate a bit attacks with just a few practical and pretty much standard steps, that can can drastically increase your server’s security.

Below is a straightforward, battle-tested hardening guide suitable for Debian, Ubuntu, CentOS, AlmaLinux, and most modern distributions.

1. Keep the System Updated (But Safely)

Outdated packages remain the #1 cause of server compromises.
On Debian/Ubuntu:

# apt update && apt upgrade -y

# apt install unattended-upgrades

On RHEL-based systems:
 

# dnf update -y

# dnf install dnf-automatic

Enable security-only auto-updates where possible. Full auto-updates may break production apps, so use them carefully.

2. Create a Non-Root User and Disable Direct Root Login
 

Attackers constantly brute-force “root”. Avoid letting them.
 

# adduser sysadmin

# usermod -aG sudo sysadmin

Then edit SSH:

# vim /etc/ssh/sshd_config

Set:

PermitRootLogin no

PasswordAuthentication no

And restart:

# systemctl restart sshd


Use SSH keys only.

3. Install a Firewall and Block Everything by Default

UFW (Debian/Ubuntu):

# ufw default deny incoming

# ufw default allow outgoing

#ufw allow ssh

# ufw enable

Firewalld (RHEL/AlmaLinux):

# systemctl enable firewalld –now

# firewall-cmd –permanent –add-service=ssh

# firewall-cmd –reload

Turn off any unneeded ports immediately.

4. Protect SSH with Fail2Ban

Fail2Ban watches log files for suspicious authentication attempts and blocks offenders.

# apt install fail2ban -y

or

# dnf install fail2ban -y

Enable:

# systemctl enable –now fail2ban

To harden SSH jail:

[sshd]

enabled = true

maxretry = 5

bantime = 1h

findtime = 10m

5. Enable Kernel Hardening

Install sysctl rules that protect against common attacks:

Create /etc/sysctl.d/99-hardening.conf:

kernel.kptr_restrict = 2

kernel.sysrq = 0

net.ipv4.conf.all.rp_filter = 1

net.ipv4.tcp_synack_retries = 2

net.ipv4.conf.all.accept_redirects = 0

net.ipv4.conf.all.send_redirects = 0

net.ipv4.conf.all.log_martians = 1

Apply:

# sysctl –system

6. Install and Configure AppArmor or SELinux

Mandatory Access Control significantly limits damage if a service gets compromised.

  • Ubuntu / Debian uses AppArmor by default — ensure it's enabled.
  • RHEL, AlmaLinux, Rocky use SELinux — keep it in enforcing mode unless absolutely necessary.

Check SELinux:

# getenforce

You want:

Enforcing but hopefully you will have to configure all your machine services to venerate and work correctly with selinux enabled.

7. Scan the System with Lynis

Lynis is the best open-source Linux security auditing tool.

# apt install lynis

# lynis audit system

It provides a security score and actionable suggestions.

8. Use 2FA for SSH (Optional but Highly Recommended)

Use Two Factor Authentication:

a. Freely with Oath toolkit – you can read how in my previous article how to set up 2fa free software authentication on Linux

or

b. Install Google Authenticator:

# apt install libpam-google-authenticator

# google-authenticator

Enable in /etc/pam.d/sshd:

auth required pam_google_authenticator.so

And in SSH config:

ChallengeResponseAuthentication yes

Restart SSH.

9. Separate Services Using Containers or Systemd Isolation

Even simple servers can benefit from isolation.

Systemd sandbox options:

ProtectSystem=full

ProtectHome=true

ProtectKernelTunables=true

PrivateTmp=true

Add these inside a service file under:

/etc/systemd/system/yourservice.service

It prevents processes from touching parts of the system they shouldn’t.

10. Regular Backups Are Part of Security

A secure server with no backups is a disaster waiting to happen.

Use:

  • rsync
  • borgbackup
  • restic
  • Cloud object storage with versioning

Always encrypt backups and test restore procedures.

Conclusion

Hardening a Linux server in 2025 requires vigilance, good practices, and layered security. No single tool will protect your system — but when you combine SSH security, firewalls, Fail2Ban, kernel hardening, and backups, you eliminate the majority of attack vectors.

 

Speed Up Linux: 10 Underrated Hacks for Faster Workstations and Servers


December 9th, 2025

make-linux-faster-underrated-hacks-cute-tux-penguin-toolbox-logo

 

Most Linux “performance tuning guides” recycle the same tips: disable services, add RAM, install a lighter desktop … and then you end up with a machine that feels basically not too much quicker.

Below is a collection of practical, field-tested, sysadmin-grade hacks that actually change how responsive your system feels—on desktops, laptops, and even small VPS servers.

Most of these are rarely mentioned (or uknown) by novice sys admins / sys ops / system engineers / dev ops but time has proved them extremely effective.

1. Enable zram (compressed RAM) instead of traditional swap

Most distros ship with a slow swap partition on disk. Enabling zram keeps swap in memory and compresses it on the fly. On low/mid RAM systems, the difference is night and day.

On Debian/Ubuntu:

# apt install zram-tools

# systemctl enable –now zramswap.service

Expect snappier multitasking, fewer freezes, and far less disk thrashing.

2. Speed up SSH connections with ControlMaster multiplexing

If you SSH multiple times into the same server, you can cut connection time to almost zero using SSH socket multiplexing:

Add to ~/.ssh/config:

Host *

    ControlMaster auto

    ControlPath ~/.ssh/cm-%r@%h:%p

    ControlPersist 10m

Your next ssh/scp commands will feel instant.

 

3. Replace grep, find, and ls with faster modern tools

 

The classic GNU tools are fine—until you try the modern replacements:

  • ripgrep (rg) → insanely faster grep
  • fd → user-friendly, colored alternative to find
  • exa or lsd → modern ls with icons, colors, Git info

# apt install ripgrep fd-find exa

You’ll be surprised how often you use them.

4. Improve boot time via systemd-analyze

Run cmd:

# systemd-analyze blame

This shows what’s delaying your boot. Disable useless services like:
 

# systemctl disable bluetooth.service

# systemctl disable ModemManager

# systemctl disable cups

Great for lightweight servers and old laptops.

5. Make your terminal 2–3× faster with GPU rendering (Kitty/Alacritty)

Gnome Terminal and xterm are CPU-bound and choke when printing thousands of lines.

Switch to a GPU-rendered terminal:

  • Kitty
  • Alacritty

They scroll like butter – even on old ThinkPads.

6. Use eatmydata when installing packages

APT and DPKG spend a lot of time syncing packages safely to disk. If you're working in a Docker container, VM, or test machine where safety is less critical, use:

# apt install eatmydata

# eatmydata apt install PACKAGE

It cuts install time by 30–70% !

7. Enable TCP BBR congestion control (massive network speed boost)

Google’s BBR can double upload throughput on many servers.

Check if supported:

sysctl net.ipv4.tcp_available_congestion_control

Enable:

# echo "net.core.default_qdisc=fq" | sudo tee -a /etc/sysctl.conf

# echo "net.ipv4.tcp_congestion_control=bbr" | sudo tee -a /etc/sysctl.conf

# sysctl -p

On VPS hosts with slow TCP stacks, this is a cheat code.

8. Reduce SSD wear and speed up disk with noatime

Every time a file is read, Linux updates its “access time.” Useless on most systems.

Edit /etc/fstab and change:

defaults

to:

defaults,noatime

Fewer writes + slightly better I/O performance.

9. Use htop + iotop + dstat to diagnose “mystery lag”

When a Linux system hangs, it’s rarely the CPU. It’s almost always:

  • I/O wait
  • swap usage
  • blocked processes
  • misbehaving snaps or flatpaks

Install the golden server stats trio:

# apt install htop iotop dstat

Check:

  • htop → load, processes, swap
  • iotop → who’s killing your disk
  • dstat -cdlmn → real-time performance overview

Using them can solve you 90% of slowdowns in minutes.

10. Speed up your shell prompt dramatically

Fancy PS1 prompts (Git branches, Python envs, emojis) look nice but slow down your shell launch.

Fix it by using async Git status tools:

  • starship prompt
  • powerlevel10k for zsh

Both load instantly even in large repos.

11. Another underrated improvement (if not already done), 
/home directory storage location

Put your $HOME on a separate partition or disk.

Why?

  • faster reinstalls
  • easier backups
  • safer experiments
  • fewer “oops I nuked my system” moments by me or someone else who has account doing stuff on the system

Experienced sysadmins and a good corporate server still does this for a reason.

Final Thoughts

Performance isn’t just about raw hardware—it's about removing the subtle bottlenecks Linux accumulates over time. With the changes above, even a 10-year-old laptop or low-tier VPS feels like a new machine.