Archive for the ‘System Optimization’ Category

« Older Entries

Best Home Wi-Fi settings for Maximum Speed and Internet coverage in Europe

Tuesday, July 21st, 2026

best-home-wifi-settings-for-maximum-speed-and-internet-coverage-europe-simple-steps-to-improve-your-home-wifi-signal

A fast broadband subscription is only part of the equation to have excellent internet air connectivity configuration for a home / work Wi-Fi Internet Router.
Even if you pay for good stable gigabit fiber options connection, poor Wi-Fi configuration can reduce your real-world speeds by more than half which might make working with devices have annoying temporary slownesses or even disruptions, when exchanging data to internet.

Our modern homes are filled with smart TVs, streaming devices, gaming consoles, laptops, smartphones, and IoT devices – all competing to take over fastest and stablest connectivity to the wireless device bandwidth.
Thus optimizing Wi-Fi router connectivity settings is no longer optional but is kind oa  in year 2026.

This snall guide would covers most of the best practices for configuring a home Wi-Fi network for maximum speed, stability, and security across Europe.

1. Choose the Right Wi-Fi Standard

Your router determines the maximum performance of your wireless network.


Recommended standards:

  • Wi-Fi 6 (802.11ax): Best value for most homes
  • Wi-Fi 6E: Excellent if your devices support the new 6 GHz band
  • Wi-Fi 7: Future-proof and ideal for multi-gigabit internet connections

! Avoid, using older Wi-Fi 5 or Wi-Fi 4 equipment unless upgrading is not possible !

2. Use the Best Frequency Band

Modern routers typically broadcast multiple wireless bands.


2.4 GHz Advantages:

  • Longer range
  • Better wall penetration
  • Disadvantages:
  • Lower speeds
  • More interference
  • Congested in apartments


2.4GHz Ideal for:

  • Smart home devices
  • Printers
  • Cameras

5 GHz Advantages:

 

  • Higher throughput
  • Lower latency
  • Less interference
  • Ideal for:
  • Streaming
  • Gaming
  • Video conferencing
  • Workstations


6 GHz (Wi-Fi 6E / Wi-Fi 7) Advantages:

 

  • Extremely low interference
  • Highest available speeds
  • Very low latency


6Ghz Wifi is usual use is:

With most modern Devices, such as (IoT connected devices, Wifi Gaming PCs, High-performance laptops, For large files transfer), tech quipment that looking for best Internet connectivity via air.. 

3. Position Your Router Correctly

best-wifi-router-placement-location-position-your-wireless-router-correctly-for-optimial-internet-air-speed

Router placement has a greater impact than many people realize.

Best practices for Router Positioning:

  • Place the router near the center of your home.
  • Position it on a shelf or table rather than on the floor.
  • Avoid placing it inside cabinets.
  • Keep it away from large metal objects.
  • Maintain distance from microwaves and cordless phones.
  • Keep antennas vertical unless the manufacturer recommends otherwise.
  • In multi-story homes, position the router between floors whenever possible.

4. Select the Best Wireless Channel

Channel congestion is one of the biggest causes of slow Wi-Fi.

For Europe (European Union countries):

For 2.4 GHz Wifi;

Use signal spread only:

  • Channel 1
  • Channel 6
  • Channel 11


These channels minimize overlap.

For 5 GHz;

 

Enable automatic channel selection or manually choose a channel with low congestion using a Wi-Fi analyzer.

5. Use the Correct Channel Width

For 2.4 GHz WiFi


Use:
+ 20 MHz
Avoid:
– 40 MHz unless there are very few neighboring networks.

For 5 GHz

Recommended:
+ 80 MHz
+ Use 160 MHz only if:
+ Few neighboring networks exist
+ Your devices support it

For 6 GHz

Use:
160 MHz or wider when available.

6. Enable WPA3 Security


Best WPA3 selection:

WPA3-Personal


For older devices require Backwards compatibility (keep enabled):
WPA2/WPA3 Mixed Mode

Avoid:
– WEP
– WPA
– Open networks
– Strong security helps prevent unauthorized users from consuming bandwidth.


7. Separate IoT Devices in different network

Many smart home devices generate unnecessary wireless traffic.
Create seperate networks for:

  • Main networ
  • Guest network
  • IoT network

This improves performance and enhances security.

8. Enable OFDMA and MU-MIMO

Modern Wi-Fi 6 routers support technologies that improve efficiency.
OFDMA

Allows multiple devices to share wireless resources efficiently.
MU-MIMO
Enables simultaneous communication with multiple devices.

Both should remain enabled.

9. Update Router Firmware

Manufacturers regularly release updates that improve the Performance, Security, Stability, Compatibility.
As script kiddie "hackers" threaths raise seriously day by day, when possible always, do:

  • Enable automatic firmware updates whenever possible.

10. Use Quality of Service (QoS)


Use the router to QoS prioritizes important traffic
Usual candidates for higher priorty internet traffics configs are:

  • Streaming, Work VPN traffic
  • Gaming, Video calls


Se as Lower priority ones :

  • Downloads
  • Cloud automated backups, etc.

11. Disable Legacy Wi-Fi Modes


Older compatibility modes, has advantages for interoperability but does reduce network efficiency, so most people would like to disable it.

Disable wifi mode transmission:

– 802.11b
– 802.11g


For Performance use instead the newer transmissions:

+ 802.11n
+ 802.11ac
+ 802.11ax

12. Always Prefer Wired Connections for High-Bandwidth Devices

alwayes-prefer-wired-connections-for-high-bandwidth-devices-cable-network-connection-should-be-always-first-choice

Connect these devices via Ethernet whenever possible:

  • NAS systems (Storages), Desktop PCs (most important candidates for UTP connectivity)
  • Gaming consoles, Smart TVs, Streaming boxes (secondary but also important to not disrupt your fun time)


Note !:
 Every cable connected device would have possible impact on any other connected Wi-Fi devices such as Mobile phones.
Every wired device reduces wireless congestion!

13. Use Mesh Wi-Fi for large sized sq. meter homes

If your home exceeds approximately 150–200 m² or has multiple floors, consider a mesh Wi-Fi system instead of relying on a single router.


Benefits includes:

  • Better coverage
  • Seamless roaming
  • Higher overall speeds
  • Reduced dead zones

14. Monitor Network Usage


Many routers provide tools to identify bottlenecks. Some common ones are

  • Bandwidth-heavy devices, Weak connections

     

     

     

     

    Review these statistics as regular as possible to optimize your network and have decent internet connectivty.

  • Congested channels, Signal quality issues

15. Understand European Wi-Fi Regulations

European countries follow ETSI regulations for wireless spectrum.
Most routers sold in Europe automatically comply with regional requirements, including:

Permitted transmit power, DFS (Dynamic Frequency Selection), follow approved set wireless channels.

! Avoid changing the router's region setting, as this may violate local regulations and reduce compatibility. !

Example Configuration for a Modern European Home (Recommended Value Settings)
 

  1. Wi-Fi Standard    Wi-Fi 6 or newer
  2. Security    WPA3-Personal
  3. 2.4 GHz Channel    1, 6, or 11
  4. 2.4 GHz Width    20 MHz
  5. 5 GHz Width    80 MHz
  6. 6 GHz Width    160 MHz (if supported)
  7. Firmware    Automatic updates enabled
  8. QoS    Enabled
  9. OFDMA    Enabled
  10. MU-MIMO    Enabled
  11. Smart Connect    Enabled unless manual band control is preferred
  12. DNS    ISP, Cloudflare (1.1.1.1), or Google Public DNS (8.8.8.8)


Common mistakes to avoid

 

  • Placing the router inside a cabinet.
  • Using outdated firmware.
  • Running all devices on the 2.4 GHz band.
  • Selecting crowded wireless channels.
  • Leaving the default administrator password unchanged.
  • Using Wi-Fi extenders instead of a proper mesh system in large homes.
  • Connecting high-bandwidth devices wirelessly when Ethernet is available.

Conclusion

Optimizing a home Wi-Fi network involves more than purchasing a fast router. Proper placement, choosing the right frequency bands, selecting appropriate channels, keeping firmware updated, and enabling modern Wi-Fi features such as OFDMA and MU-MIMO can significantly improve speed, reliability, and coverage.
For most European households, a centrally located Wi-Fi 6 router configured with WPA3 security, 80 MHz channels on the 5 GHz band, and Ethernet connections for high-bandwidth devices provides an excellent balance of performance, security, and future readiness.

Tags: , , , , , , , , , , , , , , , , , , , , , , , ,
Posted in Curious Facts, Educational, Everyday Life, Hacks, Performance Tuning, System Optimization | No Comments »

Building a self-healing WordPress Monitoring shell Script using Systemd, Apache, MariaDB simple automation for Linux server Auto Recovery

Friday, May 22nd, 2026

linux-self-healing-wordpress-script-automation-how-to-auto-recovery-broken-apache-mysql-mariadb-wordpress-server-tux-logo

Running a WordPress website in production is not only about publishing content  it is also about keeping the server healthy 24 / 7 to have a good yearly Website Uptime and if needed fit an SLA.

Even on stable Linux systems, services occasional failures are common for a reasons like:

  • Apache Crash / stop responding (due to bug or whatever)
  • MariaDB Database server acts unstable after heavy load (or server overheat)
  • WordPress platform auto updates leaves the site stuck in maintenance mode (until manually fixed)
  • Network outage (or a DHCP server malfunction, IP / MAC conflics can disrupt network).

There is plenty of other things that can go wrong, but generally usually a website infrastructure running on a Linux server that counts for proper productivity on basically a web server (apache) / mariadb / postgresql (or whatever other service) and WordPress based website has a set of common issues faced. That require a sysadmin to partake simple steps to resolve it.
Temporary outages can become kind of permanent without proper monitoring and introduction of automatic recovery procedures.

Within the age of clouds and automation reducing outages is key to success!

To reduce downtime and avoid manual intervention, there is a lot of things a sysadmin can do but a lot of traditional options are mostly neglected or uknown by the the new and knowledgable SREs (Site Reliability Engineers), most of whom seem to be a Gen-Z 🙂

Thus an alternative approach to the new ways of working is to keep up to the old standards and use lightweight self-healing Bash monitoring script for my WordPress based site / blog. I use such script myself as a do have a self-hosted infrastructure, so decided to share it with hope someone can benefit of it.

The server-health-check-restore-wp-apache-mariadb.sh script continuously checks:

  • Apache health state
  • MariaDB availability
  • HTTP response code status equals 200 ( OK )
  • WordPress maintenance mode (is not disabled

As an auto healing steps It then partakes:

  • Restarts of found failed services
  • Cleans stuck . maintenance wordpress files
  • Reboots the entire server after repeated database failures

This approach provides a simple but highly effective watchdog mechanism without needing complex monitoring software.

1. The server-health-check-restore-wp-apache-mariadb.sh
automation self-healing Script

 

$ cat /usr/local/bin/server-health-check-restore-wp-apache-mariadb.sh

#!/bin/bash

URL="https://www.pc-freak.net/blog/"
MAINT_FILE="/var/www/blog/.maintenance"
KEYWORD="Briefly unavailable for scheduled maintenance"

APACHE_SERVICE="apache2"
MARIADB_SERVICE="mariadb"

MAX_DB_RESTARTS=5
RESTART_COUNT_FILE="/var/run/mariadb_restart_count"

log() {
    echo "$(date): $1"
}

# —- Apache check —-
if ! systemctl is-active –quiet "$APACHE_SERVICE"; then
    log "Apache is not running. Restarting…"
    systemctl restart "$APACHE_SERVICE"
    sleep 5
fi

# —- MariaDB check —-
if ! systemctl is-active –quiet "$MARIADB_SERVICE"; then
    log "MariaDB is not running."

    # Read restart count
    if [ -f “$RESTART_COUNT_FILE” ]; then
        RESTART_COUNT=$(cat "$RESTART_COUNT_FILE")
    else
        RESTART_COUNT=0
    fi

    RESTART_COUNT=$((RESTART_COUNT + 1))
    echo "$RESTART_COUNT" > "$RESTART_COUNT_FILE"

    log "Restart attempt $RESTART_COUNT of $MAX_DB_RESTARTS"
    systemctl restart "$MARIADB_SERVICE"
    sleep 10

    # Re-check MariaDB
    if ! systemctl is-active –quiet "$MARIADB_SERVICE"; then
        log "MariaDB still unhealthy after restart."

        if [ “$RESTART_COUNT” -ge “$MAX_DB_RESTARTS” ]; then
            log "MariaDB failed $MAX_DB_RESTARTS times. Rebooting server!"
            rm -f "$RESTART_COUNT_FILE"
            /sbin/reboot
            exit 0
        fi

        exit 0
    fi
else
    # MariaDB healthy → reset counter
    if [ -f “$RESTART_COUNT_FILE” ]; then
        log "MariaDB is healthy again. Resetting restart counter."
        rm -f "$RESTART_COUNT_FILE"
    fi
fi

# —- HTTP sanity check —-
HTTP_CODE=$(curl -L –max-redirs 5 -s -o /dev/null -w "%{http_code}" –max-time 10 "$URL")

if [[ “$HTTP_CODE” != “200” ]]; then
    log "Site returned HTTP $HTTP_CODE. Skipping WordPress maintenance cleanup."
    exit 0
fi

# —- WordPress maintenance check —-
PAGE_CONTENT=$(curl -L –max-redirs 5 -s –max-time 10 "$URL")

if echo "$PAGE_CONTENT" | grep -qi "$KEYWORD"; then
    if [ -f “$MAINT_FILE” ]; then
        rm -f "$MAINT_FILE"
        log "WordPress maintenance file removed."
    else
        log "Maintenance message detected, but .maintenance file not found."
    fi
else
    log "Site healthy. No maintenance mode detected."
fi

1.1. Make script executable

Store the script somewhere under /usr/local/bin/ and make it executable:

# chmod +x /usr/local/bin/server-health-check-restore-wp-apache-mariadb.sh

1.2. Schedule it to run via Cron job

Run the script lets say every 5 minutes with cron and make it log to a log file:

# crontab -u root -e

*/5 * * * * /usr/sbin/server-health-check-restore-wp-apache-mariadb.sh >> /var/log/wp_healthcheck.log 2>&1

2. What This Script Actually Does

The script acts like a mini watchdog daemon.

Instead of relying on heavyweight enterprise monitoring systems, it uses:

systemctl , curl , grep combined with simple scripting  logic.

The simplicity of solution advantage is for maintenance it is easy it is transparent and highly portable as it will run on virtually ever Linux server / VPS without the need to install anything additional.

2.1 Apache Health Checks

The first section checks whether Apache is running:

# systemctl is-active –quiet apache2

If Apache is down, the script automatically restarts it:

# systemctl restart apache2

This solves temporary crashes caused by:

  • memory exhaustion
  • bad PHP workers
  • failed reloads
  • temporary kernel pressure

A short sleep delay gives Apache time to recover before additional checks continue.

2.2. MariaDB Recovery Script Logic

The database layer is more critical than Apache.

A web server can recover instantly, but repeated MariaDB crashes often indicate:

  • corrupted tables
  • exhausted RAM
  • deadlocks
  • disk problems
  • InnoDB failures

Because of that, the script implements a restart counter.

2.3. Restart Counter Logic

The counter is stored in file:

/var/run/mariadb_restart_count

Every failed startup increments the counter:

RESTART_COUNT=$((RESTART_COUNT + 1))

If MariaDB recovers successfully, the counter is deleted.

This prevents accidental reboot loops.

2.4. Automatic Server Reboot if too many auto recovery attempts

If MariaDB fails too many times:

MAX_DB_RESTARTS=5

the script escalates to a full system reboot:

/sbin/reboot

2.5. Why use reboot at continuous services failure?

Well reboot might not always work and under some cases it can make things better, but in case if you have a multiple servers running the same set of service with Apache and Mysql  with Haproxy or other Load balancer in front this set of logic is just perfect:

  • kernel resources are exhausted
  • filesystem locks remain stuck
  • memory fragmentation becomes severe
  • hardware drivers misbehave

A clean reboot can recover the machine faster than manual debugging during production outages !

This kind of script can be especially useful on:

  • Rarely mainteinaed Linux / VPS servers
  • unattended cloud instances
  • remote hosting environments

2.6. HTTP Sanity Check

After validating services, the script checks whether the website actually responds correctly.

$ curl -L –max-redirs 5

The script expects as normal a return code of:

HTTP 200

Anything else:

  • 500 errors
  • redirect loops
  • gateway failures
  • CDN problems

will stop the maintenance cleanup logic.

This prevents accidental removal of WordPress maintenance files during unrelated outages.

2.7. Automatic WordPress Maintenance Mode Recovery

One of the most annoying WordPress problems happens during failed updates.

WordPress creates under its install directory say /var/www/ a file:

.maintenance

If the update crashes, the file remains forever and the site displays:

“Briefly unavailable for scheduled maintenance.”

The script detects this message directly from the webpage content with grep:

$ grep -qi "$KEYWORD"

If detected, it removes the stale file automatically:

rm -f "$MAINT_FILE"

This instantly restores the site without requiring manual SSH intervention.

3. Why Simple script approach Works well and is good idea

This setup has several advantages, among key one is It is Extremely Lightweight.

No additional complications of use of trendy stuff like:

  • Docker stack
  • Zabbix
  • Kubernetes
  • Prometheus
  • external monitoring agents etc.

Everything is handled with simple native well known Linux tools.

3.1. It is Easy to Debug

Everything is plain Bash.

No hidden automation layers.

Every action is visible and understandable.

3.2. Production Friendly

The script tolerates:

  • temporary outages
  • service crashes
  • failed WordPress upgrades

without requiring administrator interaction.

4. Possible future script Improvements

There are many ways to extend script setup further, here is few ideas.

4.1. Add Email Notifications

Send alerts when:

  • services restart
  • reboot occurs
  • maintenance mode is detected

4.2. Add Disk Space Monitoring

Automatically detect:

  • full disks
  • inode exhaustion
  • backup growth

4.3. Add simple MySQL Query Health Checks

Instead of only checking the service state:

mysqladmin ping

could validate actual database responsiveness.

4.4. Introduce systemd Integration

Instead of cron-based execution, you might want to make the script could be made native if you use :

  • systemd timer
  • systemd service

Close up Summary

In many cases, simple Linux automation still beats overengineered solutions.

Today overcomplication of monitoring is a trend especially for big companies however for home brew small projects on little budget, sometimes the best server automation is the simplest one.
 A few lines of Bash can improve as shown above could improve uptime and reduce operational headaches.

For small-to-medium WordPress / Website deployments, this kind of self-healing “watchdog “ guarantees you reliability , simplicity , transparency , relatively quick fast recovery in case of crashes without brining a any  unnecessary infrastructure complexity, plus this setup works with zero human interaction and if combined with a simple Slack / Discord monitoring python script you can sleep better.

 

Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,
Posted in Automation, Linux, Monitoring, System Administration, System Optimization | No Comments »

Why modern Linux systems feel Slow and how to Speed it up. Common RAM, CPU, and performance Linux problems in 2026 explained

Monday, May 18th, 2026

For years Linux we the Linux users proudly mocked Windows for bloated resource usage and that was a reason for many enthusiasts like me to start in the Linux realm.
There used to be the good old times where, lightweight distributions running comfortably inside 128MB of RAM were once common, and old computers and the hackers good old ThinkPads series were perfect for becoming a computer professional.

Fast-forward trip to 2026 and many modern GNU / Linux desktop's resource hunger has topped UP and a typical GUI environment such as Gnome is consuming as minimum 2 GB of RAM and often  4GB of RAM immediately after enters through the Login manager and machine. So many of the old computers if even running for 7-8 years and served well once updated or reused with Linux on a fresh install  prformance feels really bad. There of course work arounds to that as there are distributions such PuppyLinux / Tiny Core Linux / Linux Lite / Lubutuntu and even multiple articles online suggesting on how to place an ordinary Debian on Ubuntu and optimize it to work better on older hardware but still this article might be of help not only for old school Linux fans who install on old harware but also for sysadmins who has to deploy and install brand new Linux distributions and want to squeeze best of performance from the machine and make it as minimimalistic as possible in order to reduce the number of problems that might occur for system management.

So What happened, to make Linux performance degrade so dramatically over last 15 years ?

Old Hardware feels Slower Even With Linux

People often install Linux expecting miracles on ancient hardware.

Modern workloads assume:

  • SSD storage
  • multiple CPU cores
  • AVX instructions
  • GPU acceleration
  • large memory pools

Even lightweight Linux distributions struggle when rendering modern web applications on decade-old CPUs.

A 2007 machine browsing modern JavaScript-heavy websites experiences a fundamentally different workload than it did originally.

Web site use became computationally expensive.

 

Modern Linux Is Carrying the Weight of the development of Tech and Internet industry

A contemporary Linux desktop is no longer just:

  • X11
  • a window manager
  • a browser
  • a terminal emulator

Modern systems now run dozens of background services (as people run into complexity more and more instead of minimalism). Even a basic Linux install often runs by default things such as:
telemetry collectors, hardware abstraction layers, sandboxing frameworks, package management daemons, web server management platforms, indexing systems, GPU compositors, browser engines that resemble miniature operating systems and even with some specific distros embedded containers.

A typical desktop session environment on Linux today often includes as a base a bunch of software that is not always necessery such as:

  • systemd
  • dbus-daemon
  • pipewire
  • wireplumber
  • NetworkManager
  • xdg-desktop-portal
  • gvfsd
  • tracker-miner
  • udisksd
  • polkitd
  • bluetoothd
  • ModemManager
  • cupsd
  • flatpak-session-helper

Many younger users won't  never notice the burden of having those services running all time on the hardware as hardware today is mostly powerful and modern PC and notebooks often ship with 16GB or even some gaiming machines have 32 GB of memory.

As the default amount of memory on a laptop PC has become so abundant as 16GB RAM has become  "normal / standard ",  so software developers stopped aggressively optimizing memory consumption, plus the inclusing of AI vibe coding today and the abundant resource makes things with program optimization even more bloated.

The result of all this is more and more software entropy (the tendency of software systems to become more disorganized, complex, and harder to maintain over time).

The older UNIX philosophy no longer remembered by newer developers is completely forgotten. The old unix thinking was "Do one thing well.",
the new is "use everything no matter the efficiency if that would save you time"

As a result modern desktop applications instead ship entire browser engines for  simple things as displaying buttons.
This is exactly where Linux desktop gets heavily loaded and cause for whole system to work sluggish even on newer hardware. 
Very large part of those ineffiicient developed is caused by Electron:

Electron Framework for building Desktop apps worsened Linux performance

One of the largest reasons modern Desktop Linux / Windows systems is Electron (a framework for building desktop applications using JavaScript, HTML, and CSS).

Electron bundles essentially with:

  • Chromium
  • Node.js
  • V8 JavaScript engine
  • application runtime
  • UI rendering engine

and this is used in …inside many of the third party applications, which unfurtunately has to be used also on Linux, few examples that has heavy electron use are:

  • Discord client
  • Slack client
  • VS Code
  • Element 
  • Spotify
  • Visual Studio Code
  • Discord
  • Signal Desktop
  • Postman
  • Countless App launchers part of extra packages that one needs to use on Linux Desktop

…are frequently separate Chromium instances or use large part of chromium libs pretending to be native applications.

1. Finding top resource hungry Apps on Linux

To get a list of most memory heavy Apps on a Linux system:

# ps aux –sort=-%mem | head

 

You may discover that “lightweight desktop apps” and background services are consuming much more RAM than imagined.

Measuring Real Resource Usage Properly

Many users misunderstand Linux memory reporting.

Linux aggressively uses RAM for:

  • filesystem cache
  • buffers
  • inode caching

Note! Unused RAM is wasted RAM.

# free -h

Focus on:

  • available memory
  • swap activity
  • sustained pressure

Better command tools to optimize OS include:

htop
btop
smem
iotop
vmstat

Systemd  Useful but running default unused services

Mentioning systemd still starts wars on Linux forums.

Reality is nuanced.

Systemd solved real problems:

  • dependency management
  • predictable service startup
  • cgroup integration
  • journal logging
  • parallel boot
  • service supervision

However, it also dramatically expanded the scope of PID 1 responsibilities.

Leading to many Linux-es to now launch numerous services laying around, not known by the users and never (intially needed).

If you want to check and optimize systemd ecosystem to improve performance

2. Check systemd OS boot chain and disable unnecessery services

# systemd-analyze blame

And inspect active systemd units:

# systemctl list-units –type=service

Many Linux distributions has by default setup of unused:

  • printer services on systems without printers
  • modem services on desktops without modems
  • Bluetooth stacks on machines without Bluetooth devices
  • indexing daemons nobody uses

Disable unnecessary services carefully:

sudo systemctl disable –now ModemManager
sudo systemctl disable –now bluetooth
sudo systemctl disable –now cups


This alone will reduce memory usage and boot time.
A common set of unused Apps on Desktop and servers goes like this:
 

# Printing system (disable if you never use printers)

# systemctl disable –now cups.service cups-browsed.service

# Bluetooth support (disable if you don’t use Bluetooth devices)

# systemctl disable –now bluetooth.service

# Mobile broadband / modem support (disable if no 4G / 5G dongles)

# systemctl disable –now ModemManager.service

# Network discovery (AirPrint, LAN service discovery; disable if not needed)

# systemctl disable –now avahi-daemon.service

# Location services for apps/browser geolocation (disable if not used)

# systemctl disable –now geoclue.service

# Ubuntu crash reporting services (safe to disable for privacy/no reporting)

# systemctl disable –now apport.service whoopsie.service

# Desktop search indexing (GNOME file search; disable if you don’t use fast search)

# systemctl disable –now tracker-miner-fs.service tracker-extract.service tracker-store.service

 

For deeper analysis check out systemd cg groups use:

# systemd-cgtop

Or inspect slab allocator usage:

slabtop


3. Avoid using Flatpak and Snap for extra Apps

Flatpak and Snap Increase Isolation, provides many modern Apps that are not default shipped by Debian / Ubuntu / Fedora OS  etc (Deb / RPM) repos and keeps packages easily at latest but also puts great worthless overhead on system.
 

a) Modern packaging systems like Flatpak and Snap (Pros) prioritize:

  • sandboxing
  • dependency isolation
  • reproducibility
  • cross-distribution compatibility

This is good for security, however it comes at a cost.

b) Use of Flatpak and Snap pack. managers downsides

Flatpak applications frequently duplicate:

  • runtimes
  • libraries
  • graphics stacks
  • helper services

Snap packages compress applications into loop-mounted filesystem images which increase startup overhead and general memory fragmentation.

Inspect mounted Snap filesystems

# mount | grep snap


Inspect Flatpak runtimes:

# flatpak list


Considering that, traditional native packages remain significantly leaner in many cases.

4. Use Minimalistic GUI Desktop environment to reduce resource and use of complexity on Linux

Being mimimalist nowadays in a world of abundancy is considered wrong. However minimalism has its well known provent benefits. 

Wayland Is Efficient,  but X11 env with Minimalist GUI is better

Wayland itself is not inherently bloated.

However, modern compositors increasingly rely on:

  • GPU acceleration
  • animation pipelines
  • texture buffering
  • fractional scaling
  • HDR rendering
  • Vulkan / OpenGL abstractions

This improves:

  • smoothness
  • latency
  • security
  • multi-monitor support

…but increases baseline GPU and memory usage and still for performance cautious desktop users it is most likely not the best option.

For example, try to compare CPU / Mem / Disk use of:

  • Openbox on X11
  • KDE Plasma on Wayland with effects enabled

The performance difference is dramatic.


If you want to be a Linux Minimalist (benefit) and get astonishingly low resource usage try:

  • dwm
  • i3
  • bspwm
  • Openbox
  • Wmaker
  • XFCE
  • IceWM

Switching to one of those Linux ecosystem instead of the default heavy GNOME or KDE permits even further optimizations on Graphical environment level,  if users intentionally choose it. The downsides of that is twitching it will take you usually longer but if you setup one and the same desktop with the basic minimalist environment and you keep using it for daily work / development for years, invested time is worth.

5. Use browser extensions, habits or a lightweight  browser. 

Web browser a common source of slowness 

Web Browsers, became nowadays a fully featured Operating Systems. On many machines they are the largest consumers of RAM on Linux systems and on old computers main source of slowness. On older PCs try to use other small browser alternatives

A single browser tab may include:

  • isolated sandbox process
  • JavaScript runtime
  • GPU process
  • extension subsystem
  • video decoder
  • site isolation sandbox
  • service workers

a) Inspect Chromium process trees

# ps -ef | grep chromium

b) Inspect Firefox process trees

about:processes

 

A few “simple” tabs can easily consume several gigabytes.

The modern web itself is bloated:

  • gigantic JavaScript frameworks
  • endless analytics
  • autoplay video
  • AI scripts
  • tracking engines
  • real-time rendering

Shamefully, many websites today consume more RAM than entire operating systems from the early 2000s.

If you have to work on a PC with 4 or 8 GB with Linux maybe you can try to use a GUI browser only when necessery and for general reading and stuff use a minimalist version of browsers such as using a text / console web  browser and ones that are capable to support ncurses and javascript partially, a good candidate for a real console maniac or an old school hacker will be some of below:

  • Lynx (lightest, pure text)
  • w3m (text browser but supports javascripts partially)
  • Links / Links2 (fast, ultra-lightweight web browser works in both text and gui modes)
    NetSurf (graphical web browser built from scratch with its own independent layout and rendering engine, performs poor with javascript)
  • Browsh (can be often used instead of fully functional browser but buggy)

xlinks2-graphical-mode-lightweight-browser-linux

c) Use Lightweight Browsing Habits

Extensions matter enormously.

Block:

  • ads
  • trackers
  • autoplay
  • unnecessary scripts

uBlock Origin (free and open source browser block extension) alone can dramatically reduce CPU and RAM consumption.

Final words; the modern computing efficiency degredal

What a paradox, Modern hardware is unbelievably powerful, yet modern software consumes resources at almost the same rate hardware improves.

This phenomenon is partially explained by:abstraction layers, developer convenience, use of cross-platform frameworks, increased security isolation, the web technologies heaviness and reduced optimization pressure.

Even though the degredal in perforamance on old hardware, Linux itself remains extremely efficient at the kernel level.

The bloat largely exists and widens though in:

  • userland
  • desktop ecosystems
  • browser-centric software culture
     

The computing as we know it changed.

What once was: terminal-centric, native, lightweight,locally optimized, inter-dependent

turned over  last 10 years: browser-centricm, all time cloud-connected, sandboxed, abstraction-heavy, outer dependent

The good news is that GNU / Linux still gives users freedom, even though the freedom has reduced.

Even though the performance reduced,  Linux still remains one of the few environments where users retain meaningful control over their data and system complexity in the AI, Clouds era

 

Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,
Posted in Curious Facts, Educational, Hacks, Linux, Linux and FreeBSD Desktop, Performance Tuning, System Administration, System Optimization | No Comments »

Speed up Linux shell use keyboard command alias shortcuts to effiently work like a hacker

Friday, May 1st, 2026

speed-up-linux-shell-use-via-keyboard-command-alias-shortcusts-to-work-like-a-hacker-and-be-efficient

If you want to get truly fast in the Linux Bash shell, stop thinking in commands alone and start doing trivial command tasks by thinking it in keystrokes !
The biggest productivity gains don’t come only by learning new tools, they come from navigating and reusing what is embedded as default functionality, like editing commands , searching through them and shortcuts to run and reuse instantly without need to type again and again.

At the center of this approach is one habit, to try to never type the same command twice.

1. The Allmighty, Reverse Search (Ctrl + R)

If you learn only one shortcut for a begginning say hello to the King of all bash shortcut commands CTRL + R.

Press: 

Ctrl + R

Then start typing part of a previous command. Bash will search your history in real time and show the most recent match.

Example: 

(reverse-i-search)`ssh': ssh user@server

Press:
To cycle further one command match back:

Ctrl + R


again 

Edit before running use:

→ (right arrow)

To run found cmd simply press Enter.

This is dramatically faster than scrolling through history or retyping long commands. Over time, your shell history becomes a searchable command database.

2. Stop annoying re-typing: navigate the Line instantly

When editing a command, don’t hold arrow keys—jump instead:

Go to the beginning of line

Ctrl + A

Move to the end of command string:

Ctrl + E

Jump back one word

Alt + B

Jump forward one word ahead

Alt + F

These shortcuts let you fix mistakes or modify long commands in seconds.

3. Precise Delete strings

Precise deletion is just as important as movement:

Delete everything before cursor position:

Ctrl + U 

Delete everything after cursor position:

Ctrl + K

Delete previous word from cmd string:

Ctrl + W

Delete next word in command string

Alt + D 

Instead of holding backspace, you surgically remove chunks of text.

4. Reuse arguments without rewriting

Bash has built-in shortcuts for reusing parts of previous commands:

Repeat last command, type in shell

!!

Last argument of previous command

!$

Add all arguments from previous command to a command

!*


For example on use last argument from previous command: 

mkdir project
cd !$

This jumps into the directory you just created without retyping its name.
 

hipo@jeremiah:/usr/local/bin$ find . /usr/local/bin/ /bin/ /usr/bin -iname 'ls'

/bin/ls

/usr/bin/ls

hipo@jeremiah:/usr/local/bin$ echo !*

echo . /usr/local/bin/ /bin/ /usr/bin -iname 'ls'


To only get the file name of

5. Fix Mistakes Instantly hack

Made a typo? You don’t need to retype the whole command.

Use the shortcut: 

^old^new

Example: 

hipo@jeremiah: ~$ ls -al /bin/sl
ls: cannot access '/bin/sl': No such file or directory
hipo@jeremiah: ~$ ^sl^ls
ls -al /bin/ls
-rwxr-xr-x 1 root root 151344 Sep 20  2022 /bin/ls

Bash reruns the previous command with the correction applied.

6. Use history without running history cmd

The quick access to last and previous commands, is perhaps known by most but for novice people starting will shell it is worthy mention:

Scroll through commands:

Keyboard Arrow Up / Down keys ↑ / ↓

run command number n from history !n:

To re-run cmd from history line 10

$  !10

To lets say you want to get last 10 commands from history:

$ history 10

Instead of getting full comand history with

$ history

Use the Ctrl + R which is faster shortcut to arrow keys and walking through history.

7. Use Auto-Complete

The good old well known Tab key is well known one by almost all sysadmins, but I’ll mention it anyways.

Auto-complete file / command
Single Tab press

Show all matches
Press Tab twice

This reduces typing and prevents errors – especially with long file paths.

8. Edit the previous command straight in editor

For complex commands, use: 

Ctrl + X, Ctrl + E

This opens your last command in your default editor. You can comfortably edit multi-line or complicated commands, then save and execute.

9. Clear and Reset Quickly

Clear the screen (same as clear):

Ctrl + L

Cancel current command:

Ctrl + C

Exit shell:

Ctrl + D 

These keep your terminal clean and under control.

10. Background and Foreground Control

You can manage running processes with the keyboard too:

Pause (suspend) active running process on cmd line:

Ctrl + Z

Resume process in background:

$ bg

Bring back to foreground:

$ fg  

This is especially useful when you accidentally start something in the foreground.

11. Memorize shortcuts / improve shell habits

When these shortcuts become automatic, habit for you will soon reap the benefits.

You will then no longer need to, constantly retype long command lines, you will not loose time to point with the mouse, you save time on editing your command line:

Of course getting it as habit will take few hours to a day.

Start with just building two habits:

  1. Use Ctrl + R instead of retyping

  2. Use Ctrl + A / Ctrl + E instead of arrow keys

Once those stick, layer in the others.

 

12. Start using fzf fuzzy finder command utility

 

To get even better command line search and easier manage things with command line binds use fzf.
 

# apt install –yes fzf

$ source /usr/share/doc/fzf/examples/key-bindings.bash


The fzf command-line tool enhances Linux terminal productivity by replacing the standard, rigid Ctrl+R history search with interactive, real-time fuzzy matching.
It offers a visual interface for searching command history, file paths via Ctrl+T, and directories using Alt+C [Source]. Installing fzf enables a highly efficient workflow, allowing users to find and execute commands faster.

 For a complete use cases check GitHub fzf page.

Final Thought

Efficient command line use in Bash is not only about doing less typing, it is about doing more work with less effort, so you can have more time for the important stuff.
The keyboard shortcuts are already there for long time and computer hackers (i mean old school system programmers) has been using them for ages not only in bash but in ksh, zsh, csh and  waiting to remove friction from everything you do.
Master them, and the shell stops being a place where you type in like a secretary, but a enjoyable more fun place to spend time on.

 

Tags: , , , , , , , , , , ,
Posted in Linux, Linux and FreeBSD Desktop, Programming, System Administration, System Optimization, Various | 1 Comment »

Building a 10-Server FreeBSD Jail Cluster Running a LAMP (Linux / Apache / MySQL / Perl / PHP / Python) Stack

Wednesday, March 25th, 2026

building-freebsd-jails-cluster-running-linux-apache-10-cluster-high-availability-with-mariadb-perl-php-howto

Virtualization and workload isolation are foundational to modern infrastructure.
While most teams today default to container platforms like Docker and orchestration systems such as Kubernetes, an older and highly capable alternative exists in the form of jails from FreeBSD.

FreeBSD jails provide lightweight OS-level isolation, allowing multiple independent userland environments to run on a single host. Introduced long before containers became mainstream, jails were designed with a strong focus on security, simplicity, and performance.
Despite their maturity and robustness, they are less commonly used today, largely due to the rapid rise of container ecosystems and cloud-native tooling.

Choosing between jails and containers is not simply a matter of “old vs new,” but rather a trade-off between control and simplicity versus portability and ecosystem support.

Short Comparison of FreeBSD jails and Containers ( Pros and Cons )

Advantages of FreeBSD Jails

a. Strong, simple isolation

Jails provide a clear and tightly integrated security boundary within the FreeBSD kernel. Their design is straightforward, reducing the risk of misconfiguration compared to layered container security models.

freebsd_jails_infographic_diagram

b. High performance

Because jails operate very close to the base system, they deliver near-native performance with minimal overhead—especially beneficial for networking and I/O-heavy workloads.

c. Operational simplicity

There are fewer component moving parts (easier to maintain and debbug):

  • No separate container runtime
  • No image layers
  • No complex orchestration requirements

This makes jails appealing for stable, long-running systems.

d. Predictability and stability

FreeBSD’s conservative, design philosophy results in systems that are highly stable over long periods, that is ideal for infrastructure roles like: storage or networking.

Disadvantages of FreeBSD Jails

a. Limited portability

Not neceserry a huge disadvantage but still,
Jails are tied to FreeBSD. Unlike containers, they cannot be easily moved across different operating systems or cloud platforms.


b. Smaller ecosystem

FBSD Jails is not full equivallent to:

  • Container registries (like Docker Hub)
  • Massive orchestration ecosystems (similar things has to be done with scripts and customizations)
  • Broad third-party integrations

This can slow down a bit development and deployment workflows. Though for a matured Applications that are once well tuned with jails that can be not a real probblem.

Note that though a con, this can also be a pros, as once you tune up an App for it becomes easier to maintain.

c. Less automation tooling

While tools exist, they are not as standardized or widely adopted as container-based CI/CD pipelines.

d. Harder to find people for it
 

Most developers and DevOps engineers are trained in container technologies, making hiring and collaboration easier in container-based environments. However for senior hard core sysadmins and system engineers that could be also advantage as not so many people have an indepth insight with both freebsd and fbsd jails.

This guide walks through a practical, production-style setup: 10 FreeBSD servers, each running isolated jails that host a classic LAMP stack (Linux, here replaced by FreeBSD, Apache, MySQL/MariaDB, PHP).
However still the use of companies or individuals who choose freebsd jails aim to better focus is on repeatability, clean architecture, and operational sanity, not just getting it to run once.

Architecture Overview of sample FBSD Cluster

Our Goal:

  • 10 physical or virtual servers
  • Each server runs multiple jails
  • Each jail runs a LAMP app instance
  • Load balancing across nodes (to have a High Availability Cluster like setup)

Host Setup:

  • 2 × load balancer nodes (nginx or HAProxy)
  • 6 × application nodes (Apache + PHP in jails)
  • 2 × database nodes (MariaDB primary/replica)

All systems run FreeBSD, using native jails for isolation.

1. Base FreeBSD Installation (All 10 Servers)

Install FreeBSD on each machine (minimal install is fine).

Update system:

# freebsd-update fetch install
# pkg update && pkg upgrade -y

Install base tools:

# pkg install -y sudo vim bash git

2. Install Jail Management tool (iocage)

We’ll use iocage, a modern jail manager.

# pkg install -y iocage
# sysrc iocage_enable="YES"
# service iocage start

Activate ZFS (recommended):

# zpool create zroot /dev/da0

Initialize iocage:

# iocage activate zroot
# iocage fetch

3. Create a Reusable Jail Template

Instead of building each jail manually, create a golden template.

# iocage create -n lamp-template -r 13.2-RELEASE ip4_addr="vnet0|10.0.0.10/24" boot=off
# iocage start lamp-template
# iocage console lamp-template

4. Install LAMP Stack Inside the Jail

Inside the jail:

4.1. Install Apache

# pkg install -y apache24
# sysrc apache24_enable="YES"

4.2. Install MariaDB

# pkg install -y mariadb106-server
# sysrc mysql_enable="YES"

Initialize DB:

service mysql-server start
mysql_secure_installation

4.3. Install PHP pre-compiled ports

# pkg install -y php82 php82-mysqli php82-mbstring php82-opcache


Configure Apache to use PHP:

# echo 'LoadModule php_module libexec/apache24/libphp.so' >> /usr/local/etc/apache24/httpd.conf
# echo 'AddType application/x-httpd-php .php' >> /usr/local/etc/apache24/httpd.conf

5. Test LAMP Stack works OK

Create a test file:

# echo "<?php phpinfo(); ?>" > /usr/local/www/apache24/data/index.php

Start services:

service apache24 start

Visit the jail IP and confirm PHP (page output) works in Firefox / Chrome Browser.

6. Convert Template into Clones

Stop Jail and snapshot:

iocage stop lamp-template
iocage snapshot lamp-template@base

Clone for production:

iocage clone lamp-template -n app01 ip4_addr="vnet0|10.0.0.21/24"
iocage clone lamp-template -n app02 ip4_addr="vnet0|10.0.0.22/24"

Repeat across servers and once working create a small shell script to run as a cron job to create backups automated.

Each server might run 5 up to 20 jails depending on resources.

7. Networking Between Jails

Use VNET for proper isolation:

Enable bridge on host:

# ifconfig bridge0 create
# ifconfig bridge0 addm em0 up

Assign jail interfaces automatically via iocage.

8.  Load Balancing Layer

On 2 dedicated nodes, install nginx:

# pkg install -y nginx
# sysrc nginx_enable="YES"

Example config:

http {
    upstream backend {
        server 10.0.0.21;
        server 10.0.0.22;
        server 10.0.1.21;
        server 10.0.1.22;
    }

    server {
        listen 80;

        location / {
            proxy_pass http://backend;
        }
    }
}

9. Database Strategy

You have few options to choose from:

a. Use Centralized DB

  • Dedicated DB jails on 2 nodes
  • Primary + replica

b. Use Per-node DB (simpler)

  • Each jail has its own MariaDB
  • Use app-level replication if needed

10. Automation Across 10 Servers

Use tools like:

  • Ansible
  • SSH scripts
  • ZFS replication

Example (simple parallel execution loop) or use a set of scripts to handle updating with some Ansible Playbooks or Puppet:

# for host in server{1..10}; do
  ssh $host "pkg update"
done

Few more Operational Tips to consider

a. Tune up setup / Do Resource management

  • Limit jail CPU/memory using rctl
  • Avoid overcommitting RAM

b. Use Centralized Logging

c. Do regular jail Backups

  • Use ZFS snapshots to backup each of the Jails:

# zfs snapshot zroot/iocage/jails/app01@backup
…

d. Tighten Security

  • Disable root SSH
  • Use PF firewall on host
  • Keep jails minimal

e. Do a Further Scaling Strategy

  • Add more servers -> replicate template
  • Add more jails -> clone snapshots
  • Scale horizontally via load balancer

Summary and Last Thoughts

When Choose FBSD Jails and when Containers

  • Use jails when you control the infrastructure, need maximum efficiency, and value simplicity (e.g., appliances, CDNs, storage systems).
  • Use containers when portability, scalability, and integration with modern DevOps workflows are critical.

This setup plays to the strengths of FreeBSD jails:

1. Performance: near-native speed
2.Isolation: strong and predictable
3. Simplicity: fewer layers than container stacks

FreeBSD jails remain a powerful and efficient isolation mechanism, particularly well-suited for controlled, performance-sensitive environments. Containers, however, dominate in modern application deployment due to their flexibility and ecosystem. The choice ultimately depends on whether you prioritize system-level control or platform-level convenience.

You won’t get the ecosystem of tools like Docker or Kubernetes, but you gain control, stability, and efficiency, which is exactly why companies like Netflix still rely on this model in critical infrastructure.

 

Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,
Posted in Automation, Cloud services, Clusters, Curious Facts, FreeBSD, Linux, System Administration, System Optimization | No Comments »

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

Tuesday, 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 ! 🙂

Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,
Posted in Linux, Linux Audio & Video, Linux on Laptops, System Administration, System Optimization, Various | No Comments »

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

Friday, 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.

Tags: , , , , , , , , , , ,
Posted in DNS, Linux, System Administration, System Optimization, Various | No Comments »

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

Thursday, 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.

Tags: , , , , , , , , ,
Posted in Linux, Performance Tuning, System Administration, System Optimization | No Comments »

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

Thursday, 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.

 

Tags: , , , , , , , , , , , , , , , ,
Posted in Computer Security, Linux, System Administration, System Optimization | No Comments »

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

Tuesday, 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.

Tags: , , , , , , , , , , , ,
Posted in Linux, System Administration, System Optimization | No Comments »

« Older Entries