Spotify (official .deb package, spotify-client 1.2.95, Debian 13) no longer opens. No window, no message. From the launcher, nothing happens. From a terminal:

$ spotify
$ echo $?
1

With --enable-logging=stderr, a single line is printed:

INFO:cef/libcef/common/crash_reporting.cc:209] Crash reporting enabled for process: browser

Then the process exits with code 1.

False leads

• The GPU: --disable-gpu, --in-process-gpu, --ozone-platform=x11|wayland, --use-gl=egl change nothing, the exit code stays 1.
• The package: no recent Spotify update, the binary is intact.
• The config: ~/.config/spotify/prefs is readable and consistent.

A test with a clean profile (XDG_CONFIG_HOME and XDG_CACHE_HOME pointed to a temporary folder) did start. So the problem came from the existing profile, not from the installation.

The cause

Spotify is a CEF (Chromium Embedded Framework) application. Like Chromium, it only allows one instance per profile, with three symbolic links in ~/.cache/spotify:

SingletonLock   -> huntervcx-imac151-10745
SingletonCookie -> 11476635766705238864
SingletonSocket -> /tmp/org.chromium.Chromium.sCe4Pv/SingletonSocket

The content of SingletonLock is <hostname>-<pid>. At startup, Chromium reads this link:

• if the hostname matches the current machine, it checks whether the PID is still running and takes over the lock if it is dead;
• if the hostname differs, it assumes the profile is used by another machine (profile on a network share) and leaves everything alone.

Here, the lock had been left the day before by a session that hadn’t closed the app properly, under the old hostname huntervcx-imac151. In the meantime, the machine had been renamed iMac-Arthur. Spotify therefore saw a lock from “another machine” and quit silently.

The fix

Make sure no Spotify is running, then delete the three links:

pgrep -af spotify
rm ~/.cache/spotify/SingletonLock \
   ~/.cache/spotify/SingletonCookie \
   ~/.cache/spotify/SingletonSocket

These files contain only the lock: no account, no track cache, no preferences. Spotify starts normally again.

Key takeaways

• Changing the hostname while a Chromium/Electron/CEF app has crashed or is still open leaves an orphaned lock that the app can no longer recover from.
• The same symptom can occur with Chrome, Edge, VS Code, Discord, etc.: run ls -la on the profile folder and look at the Singleton* files.
• An exit code of 1 with no message is often a lock or a profile issue, not a GPU problem.
• If you change the hostname, close your applications first, or clean up the Singleton* files afterwards.

The symptom

Instance: ~/.local/share/PrismLauncher/instances/26.3/minecraft. 5120x2880 fullscreen display, guiScale:3. In logs/latest.log, when opening the creative inventory:

Too many items (64) in UI, some will be skipped! (Reached maximum texture size 512x512)

There is a quick in-game fix: F3+T (reload packs) brings the icons back, until the next time.

First lead: the icon atlas

The UI item icons are drawn into an atlas capped at 512x512 px. If not everything fits, the extra items are skipped: transparent icon. It doesn’t depend on the resource pack, and with a 5120x2880 display at guiScale:3 the icons are large, so the atlas fills up quickly.

My back-of-the-envelope hypothesis (not confirmed): an icon is 16 px x guiScale, so a 512x512 atlas holds 64 icons at guiScale:4 (64 px), about 100 at 3 and 256 at 2. It matches the logs: the message appeared on the 21st (14:07, 66 items) and the 22nd (22:30:53, 64 items).

Test: guiScale:2 helps, but the interface becomes too small. A workaround, not a fix.

Dead end: driver and kernel

• Kernel 7.2.11-imac5kstitch, amdgpu OK.
• OpenGL works on the system: eglinfo on Wayland reports radeonsi pitcairn, GL 4.6, and glxinfo on XWayland is accelerated.

But in Minecraft, before the window is even created:

GlBackend.loadLibrary ... Could not retrieve OpenGL functions

The game then falls back to Vulkan (RADV PITCAIRN, Mesa 25.0.7), and that works. The Requested swapchain extent ... not within allowed extent messages are just fullscreen resizing under XWayland, harmless.

The real problem: SDL falls back to XWayland

I had tried forcing OpenGL with preferredGraphicsBackend:"default" in options.txt (game closed, otherwise it rewrites the file). OpenGL still failed with the same error and the game went back to Vulkan: that test had never really happened.

The cause: SDL was falling back to XWayland, because my compositor doesn’t support fifo-v1. The fix is an environment variable on the Prism instance (instance settings, environment variables, with OverrideEnv=true):

SDL_VIDEO_DRIVER=wayland

Result

Test on 23 October at 10:25: OpenGL 4.6 radeonsi pitcairn, SDL window on wayland, guiScale:3, singleplayer world. No more icon problem and no more Too many items.

Still to check: on the server, with more items (multiplayer creative), once it is back up. If the warning comes back, I’ll have to see whether it comes from the server or from the backend. In the meantime, my take: the real culprit was the XWayland fallback, not the atlas size.

Takeaways

• If OpenGL fails in Minecraft while eglinfo and glxinfo work, check which backend SDL is really using.
• On a Wayland compositor without fifo-v1, SDL can fall back to XWayland. SDL_VIDEO_DRIVER=wayland in the Prism instance environment fixes it.
• A test is only worth something if you’ve checked it tests what you think it does (here, the “OpenGL test” was actually running on Vulkan).

The goal is simple:

arthur-perrot.example.com
        ↓
Current public IPv4 address

The machine regularly checks its public IP and, when it changes, automatically updates the matching DNS record at Cloudflare.

In this guide, we will set up this DDNS with a simple Bash script, the Cloudflare API and a systemd timer on Debian.

Prerequisites

You need:

• a domain whose DNS is managed by Cloudflare;
• Debian or another distribution using systemd;
• curl;
• jq;
• a Cloudflare API token.

Installing the dependencies:

sudo apt update
sudo apt install curl jq

In the examples, we will use:

DNS zone : example.com
Record   : arthur-perrot.example.com

1. Create the Cloudflare API token

From Cloudflare, create an API Token with only the permissions required on the relevant zone.

Recommended permissions:

Zone → DNS → Edit
Zone → Zone → Read

It is better to limit the token to a single DNS zone rather than giving it access to the whole account.

You can check that the token works:

export CF_API_TOKEN='cfat_xxxxxxxxxxxxxxxxx'

curl -s \
  -H "Authorization: Bearer $CF_API_TOKEN" \
  "https://api.cloudflare.com/client/v4/zones?name=example.com" | jq

Cloudflare should return, among other things:

{
  "success": true
}

The response also contains the zone identifier:

"id": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

Keep this Zone ID, we will use it directly in the script.

2. Create the DNS record

In Cloudflare, create an A record, for example:

Type : A
Name : arthur-perrot
IPv4 : 1.2.3.4
TTL  : Auto

The initial address does not matter: the script will replace it on its first run.

You can check the resolution with:

dig +short arthur-perrot.example.com @1.1.1.1

For example:

1.2.3.4

3. Create the DDNS script

Let’s create our script:

sudo nano /usr/local/bin/cloudflare-ddns

Content:

#!/bin/bash

set -e

TOKEN="$CF_API_TOKEN"
ZONE_ID="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
RECORD="arthur-perrot.example.com"

# Fetch the public IPv4 address
IP=$(curl -fsS -4 https://api.ipify.org)

# Look up the DNS record identifier
RECORD_ID=$(curl -fsS \
  -H "Authorization: Bearer $TOKEN" \
  "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records?type=A&name=$RECORD" \
  | jq -r '.result[0].id')

if [ "$RECORD_ID" = "null" ] || [ -z "$RECORD_ID" ]; then
    echo "Record $RECORD introuvable"
    exit 1
fi

# Fetch the address currently published
CURRENT=$(curl -fsS \
  -H "Authorization: Bearer $TOKEN" \
  "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records/$RECORD_ID" \
  | jq -r '.result.content')

# Nothing to do if the address has not changed
if [ "$CURRENT" = "$IP" ]; then
    echo "IP inchangée : $IP"
    exit 0
fi

# Update the Cloudflare record
curl -fsS -X PATCH \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records/$RECORD_ID" \
  --data "{\"content\":\"$IP\"}" \
  | jq -e '.success' >/dev/null

echo "$RECORD : $CURRENT -> $IP"

Make the script executable:

sudo chmod 700 /usr/local/bin/cloudflare-ddns

The logic is intentionally simple:

Fetch the public IP
              ↓
Read the Cloudflare record
              ↓
  Same IP?
        ↙           ↘
      Yes           No
       ↓             ↓
   Do nothing    Update
                 Cloudflare

4. Store the token separately

It is better not to put the Cloudflare token directly in the script.

Create:

sudo nano /etc/cloudflare-ddns.env

With:

CF_API_TOKEN=cfat_xxxxxxxxxxxxxxxxx

Then restrict the permissions:

sudo chown root:root /etc/cloudflare-ddns.env
sudo chmod 600 /etc/cloudflare-ddns.env

This way, only root can read the token.

5. Create the systemd service

Create:

sudo nano /etc/systemd/system/cloudflare-ddns.service

With:

[Unit]
Description=Cloudflare DDNS updater
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
EnvironmentFile=/etc/cloudflare-ddns.env
ExecStart=/usr/local/bin/cloudflare-ddns

Then reload systemd:

sudo systemctl daemon-reload

Let’s test the service manually:

sudo systemctl start cloudflare-ddns

Then:

systemctl status cloudflare-ddns

A result like this one indicates that everything works:

Starting cloudflare-ddns.service - Cloudflare DDNS updater...
arthur-perrot.example.com : 1.2.3.4 -> 203.0.113.42
Deactivated successfully.
Finished cloudflare-ddns.service - Cloudflare DDNS updater.

On subsequent runs, if the IP has not changed:

IP inchangée : 203.0.113.42

It is normal for the service to then show as:

inactive (dead)

This is a oneshot service: it does its job and then exits.

6. Run the DDNS automatically every 5 minutes

We can now use a systemd timer.

Create:

sudo nano /etc/systemd/system/cloudflare-ddns.timer

With:

[Unit]
Description=Update Cloudflare DDNS every 5 minutes

[Timer]
OnBootSec=30s
OnUnitActiveSec=5min
Persistent=true

[Install]
WantedBy=timers.target

Enable the timer:

sudo systemctl daemon-reload
sudo systemctl enable --now cloudflare-ddns.timer

Check its status:

systemctl status cloudflare-ddns.timer

You should get:

Active: active (waiting)

To see the next run:

systemctl list-timers cloudflare-ddns.timer

For example:

NEXT                        LEFT     UNIT
Tue 17:43:20 EDT            4min     cloudflare-ddns.timer

7. Check the logs

Script runs are recorded in the systemd journal.

Show the latest runs:

journalctl -u cloudflare-ddns.service -n 20

Follow the next runs live:

journalctl -fu cloudflare-ddns.service

To show only the events since the last boot:

journalctl -b -u cloudflare-ddns.service

8. Check after a reboot

The timer was enabled with:

sudo systemctl enable --now cloudflare-ddns.timer

so it will start automatically with Debian.

You can check:

systemctl is-enabled cloudflare-ddns.timer
systemctl is-active cloudflare-ddns.timer

Expected result:

enabled
active

About 30 seconds after boot, a first check will run. After that, the script will run every five minutes.

9. Check the result

Show the public IPv4 address:

curl -4 -s https://api.ipify.org
echo

Then check the DNS:

dig +short arthur-perrot.example.com @1.1.1.1

Both values must match:

203.0.113.42
203.0.113.42

The final flow is therefore:

                    ┌─────────────────┐
                    │   Debian PC     │
                    └────────┬────────┘
                             │
                      every 5 min
                             │
                             ▼
                    Current public IP
                             │
                             ▼
                    Compare with Cloudflare
                             │
                    ┌────────┴────────┐
                    │                 │
                  same            different
                    │                 │
                    ▼                 ▼
                 nothing       Cloudflare API
                                      │
                                      ▼
                         arthur-perrot.example.com
                                      │
                                      ▼
                             new public IPv4

The advantage of this solution is that it does not require any extra DDNS daemon: only curl, jq, a few lines of Bash and the native systemd mechanisms.

It is particularly suitable for a laptop that often changes networks: home, phone hotspot, public Wi-Fi, etc.

Keep in mind, however, that DDNS does not bypass NAT or network restrictions. The DNS name will point to the public IP address used by the laptop, but this does not guarantee that incoming connections to it are possible, especially behind CGNAT or on a network that blocks incoming connections.

Then:

• you close the lid,
• the terminal crashes,
• your SSH session disconnects,
• or VSCode restarts.

And the entire session disappears.

Context gone. History gone. Work gone.

The issue is not Claude Code itself.

The issue is that the agent is running directly inside your active terminal session.

When the terminal dies, the process dies with it.

Why tmux Completely Changes the Claude Code Experience

tmux lets you detach terminal sessions from your current terminal window.

That means:

• your Claude session keeps running even if the terminal closes,
• you can reconnect later exactly where you left off,
• Claude keeps its loaded context,
• and long-running tasks continue in the background.

This is especially useful:

• over SSH on VPS instances,
• for long-running sessions,
• in multi-project workflows,
• with multiple Claude agents,
• on remote servers,
• or simply to avoid keeping a MacBook awake 24/7.

The Setup: a cc Alias

The goal:

• automatically create a tmux session,
• launch claude remote-control,
• instantly attach your terminal,
• generate a unique session name per project.

Quick Installation

Bash

echo "alias cc='SESSION=claude-\$(basename \"\$PWD\")-\$(date +%s); tmux new-session -d -s \$SESSION \"cd \\\"\$PWD\\\" && claude remote-control\" && tmux attach -t \$SESSION'" >> ~/.bashrc && source ~/.bashrc

Zsh

echo "alias cc='SESSION=claude-\$(basename \"\$PWD\")-\$(date +%s); tmux new-session -d -s \$SESSION \"cd \\\"\$PWD\\\" && claude remote-control\" && tmux attach -t \$SESSION'" >> ~/.zshrc && source ~/.zshrc

Usage

From any project directory:

cc

The alias will:

1. create a dedicated tmux session,
2. launch Claude Code inside the current project,
3. automatically attach your terminal to the session.

Reconnecting to a Claude Session

Even after closing your terminal, the session remains active.

To list active sessions:

tmux ls

To reconnect to a session:

tmux attach -t session-name

Why This Matters for Engineering Teams

In real-world infrastructure and development environments, this approach helps:

• maintain persistent AI agents,
• reduce context loss,
• improve SSH workflows,
• streamline DevOps operations,
• run multiple Claude environments simultaneously,
• and avoid interruptions caused by user workstations.

It is especially useful for:

• Kubernetes,
• CI/CD pipelines,
• Linux administration,
• backend development,
• automation,
• cybersecurity,
• and long-running operational tasks.

Bonus: Clean Multi-Project Isolation

Because the session name automatically includes the current directory, every project gets its own isolated Claude environment.

Example:

claude-api-1748812941
claude-frontend-1748812958
claude-infra-prod-1748812972

You can work across multiple projects simultaneously without conflicts.

Conclusion

Most developers use Claude Code like an advanced terminal assistant.

But once paired with tmux, it becomes a persistent AI workspace.

The difference is immediate:

• fewer interruptions,
• fewer lost sessions,
• less context rebuilding,
• and far more stable workflows.

For advanced engineering workflows, it quickly becomes difficult to work without it.

Those who talk about hexagonal architecture, clean code, elegant patterns, strict separation of concerns.
And those who ship.

I’m exaggerating on purpose. But the debate does exist.

And I’ll say it loud and clear: I’m a bad developer.
Five years at Epitech taught me to code, but I don’t enjoy it. So I’m not the best.
Still, I outperform most of your devs, because this weakness is my biggest asset for my clients.

The Myth of Perfect Code

We’ve all come across this profile:

• 14 layers of abstraction,
• 12 interfaces for a single implementation,
• a “future-proof” architecture,
• zero visible features for the client.

Technically, it’s impressive.
Conceptually, it’s clean.

But meanwhile, the client is still waiting for the button to work.

The client doesn’t see:

• your refined dependency injection,
• your well-placed design patterns,
• your exemplary variable names.

They see:

“Does it work?”

On the Other Hand: the Cowboy Coder

Then there’s the other profile.

The one who writes fast.
Sometimes dirty.
Sometimes redundant.
But functional.

The product ships.
The client is happy.
The business moves forward.

And often, it’s that code that brings in the money.

The Truth Lies in Between

Saying that only the result matters would be wrong.
Technical debt exists. It’s real. It costs a lot.

But hiding behind “the perfect architecture” to delay delivery is also a form of avoidance.

The Pareto principle (which I’ve loved since my teens) is useful here:

20% of well-placed effort produces 80% of the value.

The extra 80% of effort to make the code “academically pure” doesn’t always produce 80% of additional value.

Sometimes, it produces 5% of intellectual comfort.

What the Client Really Buys

A client doesn’t buy:

• a pattern,
• an elegant structure,
• a well-organized repository.

They buy:

• a solution to a problem,
• time savings,
• cost reduction,
• a competitive advantage.

Architecture is a means.
Not an end.

But Be Careful: “Functional” Is Not an Excuse

The opposite argument is just as dangerous.

“It works” is not a sufficient argument if:

• nobody can maintain the code,
• every change breaks something else,
• scalability is impossible,
• refactoring becomes prohibitively expensive.

Throwaway code in production is a time bomb.

True maturity means knowing where to put the effort.

A Simple Rule

Before adding a layer of abstraction, ask yourself three questions:

1. Does this need really exist today?
2. Does it simplify future maintenance?
3. Will the client get measurable value from it?

If the answer is no to all three…
You may be coding for yourself, not for the product.

What I’ve Learned Over Time

A good developer is not the one who writes the most elegant code.

It’s the one who knows how to:

• ship fast when needed,
• structure when necessary,
• simplify instead of complicating,
• arbitrate between speed and cleanliness,
• and above all, stop the architectural masturbation.

Perfect code doesn’t exist.
Useful code does.

And in a project:

usefulness must always come before technical ego.

Stop reinventing the wheel.

And for God’s sake, stop reinventing the axe that will chop the wood to reinvent that goddamn wheel.

Churn out code that works, not code that shines.

When developing synchronization, indexing or file-processing tools (backup, directory scanning, etc.), recursive traversal of the file system quickly becomes a critical performance point.

In our tests, we wanted to concretely compare two common approaches in Python:

• os.walk() (historical method, widely used)
• os.scandir() (more recent, lower-level API)

The goal: a simple benchmark, without artificial optimization, run on real folders, with a few hundred to several tens of thousands of files.

The benchmark

The test consists of:

• recursively traversing a folder
• counting the total number of files
• measuring the execution time

Same logic, same machine, same business code.
The only difference: the traversal method.

Observed results

Here are some representative excerpts from the tests carried out:

👉 In every case, os.scandir() is about 2× faster.

And the larger the tree, the more significant the gap becomes.

Why this difference?

1. The hidden cost of stat()

os.walk() relies on a higher-level abstraction.
When it traverses files, Python makes many stat() system calls to determine whether an entry is a file or a folder.

These calls are:

• costly on disk
• even slower on network shares (SMB, NFS, NAS)
• multiplied by the total number of entries

2. os.scandir() works at a lower level

os.scandir() directly uses the information returned by the file system (via dirent on Linux).

Result:

• the type (file/folder) is often already known
• no systematic stat() needed
• far fewer kernel ↔ userland transitions

This is exactly what explains the massive performance gain.

“But doesn’t os.walk() already use scandir?”

Yes… internally, since Python 3.5.

But:

• os.walk() remains a general-purpose API
• it generates full tuples (root, dirs, files)
• it does more work than necessary in simple cases

👉 When you simply want to traverse quickly, using os.scandir() directly remains unbeatable.

Why choose Python, despite lower performance than some languages?

It is widely accepted that Python is, on a purely technical level, slower than compiled languages like C, C++ or Rust. This reality is not, however, a flaw in itself, but rather a deliberate trade-off. Choosing a language is never limited to raw performance alone: it involves considerations of budget, complexity, maintainability and long-term technical debt.

Python stands out above all for its simplicity of design and readability. Clearer code reduces development time, makes code reviews easier, limits errors and allows teams to ramp up faster. For the same budget, this translates into more features delivered, faster, and with a significantly lower project risk.

Moreover, not all projects require maximum optimization from the outset. In many cases, performance is not the main limiting factor, or can be improved locally, only where it is needed. Python precisely allows this progressive approach: start simple, then optimize in a targeted way, without premature over-engineering.

Finally, technical debt is often underestimated when more complex technologies are favored from the start. Very high-performing languages that demand more expertise can generate high costs in maintenance, recruitment and functional evolution. Python, by reducing this initial complexity, offers a lasting balance between efficiency, scalability and cost control.

In short, a bit of love for Python 😉

Critical use cases where the difference matters

In our projects, this kind of gain is far from theoretical. It is decisive for:

• 🔄 synchronization tools
• 📂 standalone folder scanners with several tens of thousands of files
• 🧾 data processing pipelines
• 🌐 file servers
• 🧠 indexing engines

Halving scan time means:

• less CPU load
• fewer disk I/O operations
• less perceived latency
• and better overall scalability

Recommendation

👉 For any new Python development involving recursive file traversal:

• prefer os.scandir() with explicit recursion
• reserve os.walk() for simple or non-critical scripts

This choice alone can turn an “acceptable” script into a truly industrial tool.

If you work on performance, storage, automation or large-scale file processing issues, I can support you from architecture all the way to low-level optimization.

📩 Got a project? Get in touch: Arthur Perrot, infrastructure & cybersecurity expert.

When I install a hard drive in our infrastructure that stubbornly refuses to spin, I don’t settle for a quick diagnosis. And in many cases — especially with Seagate Exos, HGST Ultrastar or Toshiba Enterprise — the cause isn’t the drive itself, but… the SATA power connector.

🔍 The culprit: the SATA 3.3 standard and the infamous 3.3 V pin

Since the SATA 3.3 standard, three small pins at the end of the power connector have had their role changed.

Enterprise drives, often designed for Dell, HP or Supermicro servers, interpret pin 3 as a disable command.
👉 Result: if your PC power supply sends 3.3 V on this line, the drive thinks it’s being told to shut down. It doesn’t spin, doesn’t heat up, and stays invisible in the BIOS.

⚡ Why some power supplies cause problems

Modern power supplies (such as the Corsair CV550, BeQuiet!, Cooler Master or consumer Seasonic) strictly follow the SATA 3.3 standard.
They therefore deliver the 3.3 V (the famous orange wire) to the SATA connector pins.
On a standard drive, no problem.
But on an Enterprise drive, this voltage activates the PWDIS signal, which blocks any startup.

And even if you remove the orange wire, some models still cause problems:

• the SATA connector can make mechanical contact with pins 1–3,
• an internal rail of the power supply can feed back a faint stray voltage,
• or the internal wiring keeps the pin active despite no visible wire.

👉 The drive therefore stays disabled, even without a visible orange wire.

🧠 Known (and tested) solutions

Okay, this isn’t actually Kapton, but it was just for testing!

🟡 Why Kapton is the best solution

Kapton (polyimide) is an insulating tape designed for electronics:

• it resists heat (up to +260 °C),
• it leaves no residue when removed,
• it’s ultra-thin, so the SATA connector slides on without forcing.

To neutralize the 3.3 V line, simply:

1. Cut a small rectangle (~5 × 3 mm),
2. Stick it over the first 3 pins on the left of the SATA connector (gold-contact side),
3. Reconnect the power cable.

Your drive will start up instantly — with no permanent change to the wiring.

🧩 Summary

🧰 Conclusion

This small design detail, invisible to the naked eye, explains hundreds of false “dead drive” diagnoses every year.

Around here, we prefer understanding over replacing.
So before sending back a “dead” drive, check your cables, your rails… and if needed, take out the Kapton tape.

💡 Tip: if you often work with Enterprise drives, always keep a few Molex → SATA adapters and a roll of Kapton tape in your workshop.
It will save you a lot of cold sweats.

A small French company that is a Horarys client, a consulting firm with about ten employees working partly remotely, contacted us: for roughly two weeks, several of its users connected via Bouygues Telecom Bbox Wi-Fi 6 or Wi-Fi 6E boxes had been experiencing significant instability on their WireGuard VPN connections. We helped them diagnose the problem.
The issue mainly affects the following configurations:

• Tunnel between a client on a public IPv6 address (Bbox) and a server on a fixed IPv4 address
• Access via a WireGuard bridge / routed local network
• UDP carrying TCP traffic (SMB, SSH, RDP, HTTPS)

🚨 Observed symptoms

• Ping works (ICMP not affected)
• RDP, SSH, SMB or web interfaces connect, then freeze or disconnect
• Heavy packet loss, abnormal latency on heavy TCP flows
• No apparent firewall blocking, and no TCP reset
• The problem is limited to clients behind Bouygues Bboxes, while other connections (Free, Orange, SFR, Bouygues 5G, etc.) remain stable

🔍 Probable cause

The network analyses carried out during the diagnosis indicate an effective reduction of the MTU on the WAN interfaces of Bouygues Bbox Wi-Fi 6 boxes since the latest firmware update.
This update also seems to force the activation of IPv6 (SLAAC / DHCPv6-PD), creating an IPv6/IPv4 mix that is not transparent for WireGuard tunnels.

As a result:

• WireGuard UDP packets exceeding ~1408 bytes are fragmented or lost
• Ping (small packets) continues to work
• Encapsulated TCP flows become unstable, especially on connections to fixed IPv4 servers.

🧰 Temporary workaround

Bouygues Telecom has not yet published any official communication, but the solution is simple and effective:

✅ On the WireGuard client (behind the Bbox)

Edit the configuration file:

[Interface]
MTU = 1380

Then restart the tunnel.

This single line forces the maximum WireGuard packet size to a threshold compatible with the new Bouygues MTU (~1408 effective bytes), immediately eliminating the losses and slowdowns.

💡 In addition

• Disable IPv6 on the Bbox (or on the client) if possible (not possible on consumer Bboxes; no feedback on the business side)
• Check that the DNS used is IPv4
• Do not change the MTU on the server side (pfSense or Proxmox) if the other clients work correctly

🧩 Typical example

In this case, a client machine with the WireGuard address 10.61.0.10 behind a Bouygues Bbox trying to reach a Proxmox server at 10.172.41.1 saw:

• Stable ping
• but the web interface (:8006) and SMB frozen.

After adding MTU = 1380, traffic immediately became smooth again.

🧠 Summary

🛡️ Our recommendation

I advise all my clients using WireGuard tunnels on Bouygues infrastructure to:

1. check tunnel stability with ping -f -l 1472 (Windows) or ping -M do -s 1472 (Linux),
2. adjust the MTU to 1380 if necessary,
3. temporarily disable IPv6 if instability persists.

I’m keeping a close eye on this behavior and will update this note as soon as an official Bouygues fix or a firmware change is confirmed.

💬 Need assistance?
I can audit your WireGuard tunnel or your multi-site interconnection.
👉 Get in touch: Arthur Perrot, infrastructure & cybersecurity expert.

Bits, bytes: the basics

• 1 byte (B) = 8 bits (b).
• Network speeds are generally expressed in bits per second (e.g. 1 Gb/s).
• Disk and file transfer speeds are expressed in bytes per second (e.g. 150 MB/s).

👉 Result: 1 Gb/s ≈ 125 MB/s in practice.

Throughput comparison table

Here is a simple table to better visualize the typical speeds of disks and networks, with their English and French equivalents:

Concrete example: a 1 TB backup

Let’s imagine a 1 TB (≈ 1000 GB) backup to transfer to a backup server. Here is how long it takes depending on the network:

• 1 GbE network (125 MB/s max):
  1000 GB ÷ 125 MB/s ≈ 2h15
• 10 GbE network (1250 MB/s max):
  1000 GB ÷ 1250 MB/s ≈ 13 minutes
• 40 GbE network (5000 MB/s max):
  1000 GB ÷ 5000 MB/s ≈ 3 minutes

👉 You can see the problem: on 1 GbE, a simple backup can take hours, and during that time your network is saturated.

The bottleneck

A key principle to remember: the final speed always depends on the slowest link.

Let’s take an example: you need to back up 4 TB of data.

• With NVMe SSDs capable of 3500 MB/s, a pure disk-to-disk copy could theoretically be done in under 20 minutes.
• But if your network is only 1 GbE (≈ 125 MB/s real), the transfer drops to:
  4000 GB ÷ 125 MB/s ≈ 9 hours.
• With a 10 GbE network (≈ 1250 MB/s), the same backup would only take:
  4000 GB ÷ 1250 MB/s ≈ 53 minutes.

👉 The takeaway: your disks can be ultra fast, but if the network is too slow, it will bottleneck overall performance.

How to size intelligently?

1. Assess your data flows: how many TB of backup each night, how many VMs replicated, what transfer times are acceptable.
2. Compare disk and network: make sure the network doesn’t throttle the disks, and vice versa.
3. Plan for headroom: with data growth, it’s better to slightly oversize.
4. Segment your usage: separate production traffic, backups and replicas to avoid overall saturation.

Conclusion

Properly sizing network throughput is just as critical as choosing the right servers.
I help companies audit, optimize and modernize their network and storage infrastructures. The goal: ensure your backups complete on time, without saturating your critical flows.

📩 Unsure about sizing your network?
👉 Get in touch: Arthur Perrot, infrastructure & cybersecurity expert.

1. useradd: the native command

useradd is one of the low-level user account management tools provided by the passwd package (often coming from the shadow-utils project in modern distributions).

• Role: create a user account by directly manipulating system files such as /etc/passwd, /etc/shadow, /etc/group and /etc/skel.
• Behavior: by default, useradd is quite strict and minimal. If no option is passed, the user can be created without a home directory and without a shell defined.
• Syntax: useradd -m -s /bin/bash newuser Here, -m forces the creation of the home directory and -s sets the default shell.

In short, useradd is a low-level tool, meant to be used in scripts or by experienced administrators who know exactly which parameters to provide.

2. adduser: the friendly wrapper

adduser is not a native command of the kernel or of the base utilities, but a Perl script (in Debian/Ubuntu and derivatives). Its goal is to make the experience simpler and more interactive.

• Role: provide a high-level interface to useradd.
• How it works: it acts as a wrapper: it calls useradd (and sometimes usermod) in the background, but adds validation logic and interaction with the administrator.
• Interaction: when you type adduser newuser, the script asks you questions: password, full name, additional information… then automatically creates the home directory, copies the files from /etc/skel, sets permissions, etc.

Why Perl?

Historically, in Debian and its derivatives, adduser was written in Perl in order to quickly benefit from a powerful and portable scripting language to add this ergonomic layer on top of the existing system tools.

• It made conditional and interactive logic possible, which would be harder to maintain in pure shell.
• With Perl, string handling, interactive forms and configuration are simpler.

3. Practical differences between useradd and adduser

4. Conclusion: which one to use?

• On Debian/Ubuntu and derivative distributions, adduser is recommended for most cases, as it is safer and prevents oversights (home directory, shell, etc.).
• On other systems like Red Hat, CentOS, Fedora, only the useradd command is available — which reflects its nature as a universal tool.

In practice, adduser is just a Perl wrapper around useradd, but it illustrates well the Debian philosophy: making administration more accessible while keeping the power of Unix tools in the background.

👉 When we automate account management in our client infrastructures, we favor useradd in scripts (predictable, universal), and adduser for daily manual administration (ergonomic, secure).

In a team, respecting a code style is essential.
One of VS Code’s simple tools is the ruler: a vertical line displayed in the editor at a given column (e.g. 80 characters).

It helps you keep track of how far you write on each line: better readability, consistency between developers, following best practices.

Minimal Configuration Example

Here is a settings.json configuration for VS Code, focused on the essentials:

{
    "editor.rulers": [80],
    "workbench.startupEditor": "newUntitledFile",
    "git.autofetch": true,
    "editor.detectIndentation": false,
    "editor.renderWhitespace": "all",
    "workbench.panel.defaultLocation": "right",
    "terminal.integrated.cursorStyle": "line",
    "terminal.integrated.fontFamily": "monospace",
    "window.menuBarVisibility": "toggle",
    "diffEditor.ignoreTrimWhitespace": false
}

Quick Explanations

1. "editor.rulers": [80]
   Displays a vertical guide at column 80 → ideal for keeping code readable and consistent.
2. "workbench.startupEditor": "newUntitledFile"
   VS Code opens an empty file directly on startup → saves time, you start coding right away.
3. "git.autofetch": true
   Automatically updates remote Git information → you always see the real state of the project without a manual fetch.
4. "editor.detectIndentation": false
   Prevents VS Code from trying to “guess” indentation → the editor follows your rules, not those detected in the file.
5. "editor.renderWhitespace": "all"
   Visually displays spaces and tabs → avoids invisible style errors.
6. "workbench.panel.defaultLocation": "right"
   Places the panel (console) on the right instead of at the bottom.
   👉 If you deliberately limit yourself to 80-column lines, it’s better to keep more vertical space than horizontal space.
   This remains a personal choice; everyone adapts to their own comfort.

A Clear Style, for the Whole Team

Setting up these simple rules in VS Code helps you:

• have more readable code,
• ensure consistency between developers,
• and avoid invisible errors (spaces, inconsistent indentation).

A small tweak to your settings.json, and you lay the foundations for a shared coding style across your projects.

When coding in C or C++, every .h file must be protected with a header guard (#ifndef, #define, #endif) to prevent multiple inclusions.
We have all done some mechanical copy-pasting… but VSCode lets you automate it with a very simple snippet.

The magic snippet

Here is an example of a snippet to add to your VSCode User Snippets (menu Preferences > User Snippets → choose cpp.json):

"C C++ Header": {
    "scope": "c, cpp",
    "prefix": "header",
    "description": "Add #ifndef, #define and #endif",

    "body": [
        "#ifndef ${TM_FILENAME_BASE/(.*)/${1:/upcase}/}_H",
        "#define ${TM_FILENAME_BASE/(.*)/${1:/upcase}/}_H",
        "",
        "$0",
        "",
        "#endif"
    ]
}

How does it work?

• Simply type header in a .h file
• Press Tab → VSCode automatically generates:

#ifndef MYFILE_H
#define MYFILE_H

// Your code here

#endif

The file name is picked up automatically and converted to uppercase. 🚀

Time and rigor savings

• No more writing guards by hand
• Guaranteed uniformity across all your headers
• Fewer multiple-inclusion errors

A small snippet, a big everyday comfort.

Just edit the file /etc/inputrc and add (or uncomment) the following line:

set bell-style none

Save, reload your session, and that’s it: no more unwanted beeps! 🎉

👉 Bonus tip: you can also replace the beep with a visual signal using:

set bell-style visible

python3 -m http.server 8000

By default, this command starts an HTTP server that makes the current folder accessible on port 8000.
Then simply connect to http://your_ip:8000 from a browser to download your files.

✅ Ideal for:

• sharing files on a local network,
• helping a colleague troubleshoot,
• accessing your data from another device.

⚠️ Warning: this server is basic and provides no security. Use it in a private or one-off context only.

Here is the magic command:

xclip -selection clipboard -out | tr \n \r | xdotool selectwindow windowfocus type --clearmodifiers --delay 25 --window %@ --file -

👉 Quick explanation:

• xclip: retrieves the clipboard contents.
• tr \n \r: converts line breaks to avoid bugs.
• xdotool type: simulates typing character by character, like a human on the keyboard.

Handy, simple and 100% effective for saving time!