标签：#linux

I have no idea what I'm f*cking doing. Something I keep questioning: Why the hell am I building an operating system for this? Seriously. Every couple of weeks I look at ShrekOS, look at the amount of work involved in building an actual Linux distribution, and have basically the same reaction. This is f*cking ridiculous. I wanted a safer way to run AI agents on my computer. Somehow that turned into an immutable Debian system with isolated workloads, capability grants, controlled egress, verified updates, a desktop policy layer, an installer, and enough architecture documents to make me question every decision that led me here. There has to be an easier answer. There has to be some tool I missed. Run the agents in Docker. Use Podman. Use a VM. Use a better agent harness. Install some security middleware. Find a desktop application that manages all of this. Anything other than: Build a f*cking operating system. So I keep trying to prove that ShrekOS does not need to exist. And the annoying part is that every time I do, I eventually end up back at the same problem. I already know containers exist I already wrote the technical version of this question in Why I'm Building ShrekOS When Containers Already Exist . I am not going to repeat that whole argument here. Containers are useful. I use them. The Bench system in ShrekOS literally runs on rootless container technology. I did not invent a magical new isolation primitive because AI showed up. Namespaces exist. Seccomp exists. Landlock exists. Containers exist. Virtual machines exist. Linux already has an absurd number of ways to restrict a process. That is not the thing I keep getting stuck on. The thing I cannot seem to find is the user space around all of it . Not userspace in the kernel terminology sense. I mean the actual space where the human uses the computer. The desktop. The workflow. The place where I can run several autonomous things on my machine and understand, at a glance, what each one is allowed to do. I wa

CERN engineers announced a shift from Red Hat-based distributions to Debian for its accelerator control systems. This decision stems from Red Hat's tightening compiler mandates, which threatened legacy hardware. The transition, focused on 2,200 specialized control machines, is set for completion in late 2026, while CERN's other systems will remain with Red Hat and AlmaLinux. By Olimpiu Pop

A program of mine hung for forty minutes. Not spinning at a thousand loops a second: at zero percent CPU . It wasn't doing too much work; it wasn't doing any work at all. And still it wouldn't finish. The program does something common: it orchestrates external command-line tools. It launches one, reads what it writes to standard output, and moves on to the next when it's done. So it doesn't get stuck when a tool drags, each one has a timeout: when it fires, the process is killed and we carry on. That's the part that failed, and it failed where no one looks: after killing the process. Killing the process doesn't close the pipe When you read a subprocess's output, you read from a pipe : one end writes (the subprocess), the other reads (you). Your reader doesn't finish when the subprocess dies. It finishes when EOF arrives, and a pipe's EOF arrives only when the last write end is closed. Almost always they coincide: the subprocess is the only writer, it dies, its end closes, EOF arrives, your reader finishes. All in microseconds. But "almost always" isn't "always". The tool I launched launched another one in turn —a grandchild—. And that grandchild inherited the pipe's write end, because on Unix a child inherits its parent's open descriptors unless told otherwise. So when the timeout fired, I killed the child. Its end closed. But the grandchild was still alive , with its copy of the descriptor open. The last write end hadn't closed. EOF never came. And my reader sat waiting for an EOF that would never arrive —at zero percent CPU, blocked in a read() , indistinguishable from slow work—. The symptom that deceives What makes this failure so hard to see is that it doesn't look like a failure . An infinite-loop hang burns CPU: you see it in top instantly. This one spends nothing. The thread is asleep in the kernel waiting for data that isn't coming. In the process list it looks healthy. In the metrics it looks like it's "taking a while". The only way to tell "hung forever"

Well...Well...Well... You’re probably tired of Windows, too—or maybe you just want something new , And you think Linux is an interesting option, you HAVE to read this What do I want to talk about? You have likely already heard the name of the best distribution for beginners, but I will list a few options for you to choose from to get started. (We'll talk more about choosing a distro in another post.) Linux mint (Cinnumon Recommended) Pop_!OS Ubuntu Zorin OS MX linux Choose one to get started. How do we use them for the first time? NEVER install Linux fully on your computer. You have two options: Virtual machine (recommended) Dual boot Dual-booting requires more complex steps—such as creating a bootable flash drive or partitioning the disk—but it leaves all the computer's resources available, allowing you to use the system normally. A virtual machine is like running Linux as if it were an application; however, it consumes more resources, so you need a more powerful computer. Installing them is simple, too—whether on a virtual machine or in a dual-boot setup. You can easily learn how to install it by watching a YouTube video and talking to an AI. Important note: For a dual-boot installation, be sure to check the internet connection, audio, keyboard, mouse, and display within the live-USB before starting the installation. And make sure the USB drive is in good working order and has at least 8 GB of space. Okay, I've installed it. How do I use it? First of all, the basic terminal commands. (on linux yo have to learn it , else you are NOT a linux user) Package manager All the distributions mentioned here use the apt package manager. If you are using a different distribution, search online to find out how to use its package manager. Knowing how to search is a skill in itself! (Discussing package managers would take too long, so I won't talk about them.) However, if you are using these distributions, you should know these commands for removing, installing, and updating. fo

If you use Windows or Linux, you may have created a bootable USB at some point. For example, if you want to install Windows 11 or Linux Mint , you can download the ISO file and use a tool like Rufus to create a bootable USB. Rufus works very well. But recently, while using Linux Mint, I discovered another tool called Ventoy . At first, I wondered: If Rufus already creates bootable USBs, why would I need Ventoy? After understanding how Ventoy works, I realized that the two tools solve slightly different problems. Let's look at it in a beginner-friendly way. What is Rufus? Rufus is a popular tool for creating bootable USB drives. For example, suppose you download the Linux Mint ISO: linuxmint.iso You open Rufus, select your USB drive and the ISO file, and Rufus prepares the USB so that you can boot your computer from it. The process looks like this: Linux Mint ISO ↓ Rufus ↓ Bootable USB ↓ Install Linux Mint The same idea works for Windows 11 and many other operating systems. Rufus is especially useful when you simply want to create one bootable USB for one ISO. Then what is Ventoy? Ventoy takes a slightly different approach. Instead of writing one ISO directly to the USB, you install Ventoy on the USB drive first. After that, you can simply copy ISO files to the USB like normal files. For example: Ventoy USB │ ├── Windows11.iso ├── LinuxMint.iso ├── Ubuntu.iso ├── Fedora.iso └── Clonezilla.iso When you boot your computer from this USB, Ventoy shows you a menu. You can then choose which ISO you want to boot. Something like: That's the main idea behind Ventoy. The biggest difference This is probably the easiest way to understand the difference: Rufus: ISO → Rufus → Bootable USB You normally repeat the process when you want to replace the ISO. Ventoy: Install Ventoy once ↓ Copy ISO files ↓ Boot from USB ↓ Choose an ISO You don't have to recreate the USB every time you want to use a different ISO. A simple real-world example Imagine you have a 64 GB USB drive. With Rufus,

When I started using Linux Mint , I spent quite a bit of time exploring small desktop customizations. One of the simple things I discovered was that Linux Mint Cinnamon lets you customize how the date and time are displayed on the taskbar. Instead of showing only something like: Sat Aug 22 07:10 PM you can change it to something that works better for you. For example: Sat, Aug 22 • 07:10 PM or: 22 Aug 2026 | 07:10 PM or even: Saturday, 22 August • 19:10 It is a small change, but it is a nice way to personalize your desktop. Where can I change it? On Linux Mint Cinnamon, right-click the clock/date area on the taskbar and open the calendar settings. You should find a Display section with an option called: Use a custom date format Enable it and you will see a field where you can enter your own date and time format. For example: % a % b % e | % I :% M % p The Cinnamon documentation provides a complete reference for these formatting codes. But what do these strange symbols mean? At first, the format looks a little confusing: % a % b % e | % I :% M % p Don't worry. Each % code simply represents a different part of the date or time. For example: Code Meaning Example %a Short weekday Sat %A Full weekday Saturday %b Short month Aug %B Full month August %d Day with leading zero 02 %e Day without leading zero 22 %m Month number 08 %Y Four-digit year 2026 %y Two-digit year 26 %H Hour, 24-hour format 19 %I Hour, 12-hour format 07 %M Minutes 10 %S Seconds 35 %p AM/PM PM %P am/pm pm %Z Timezone IST The complete Cinnamon reference also includes things such as week numbers, day of the year and fractional seconds. You don't need to remember all of them. Once you understand a few common codes, creating your own format becomes quite easy. My favorite date and time combinations Here are some combinations you can try directly in the Date format field. 1. Simple and clean % a % b % e % I :% M % p Result: Sat Aug 22 07:10 PM 2. More readable % a , % b % e • % I :% M % p Result: Sat, Aug 22

TrueNAS CORE has been the standard for open-source storage using FreeBSD and OpenZFS. The shift to TrueNAS SCALE, based on Debian, left some users needing alternatives. FreeCORE upgrades TrueNAS CORE to FreeBSD 15.0, restoring essential features like FreeBSD Jails. While it satisfies certain administrators' needs, its long-term sustainability and maintenance by a single individual raise concerns. By Olimpiu Pop

A six-week journey through source builds, CI pipelines, and one package pacman never mentioned. TL;DR: pacman -S whisper-cpp ggml-vulkan . That's it. That's the whole answer. Here's why it took me several weeks to find it. The setup I use whisper.cpp for local speech-to-text and as a part of my projects. I have a GPU utilization monitor permanently visible in my GNOME panel via the Vitals extension — so when whisper.cpp started detecting my GPU but running everything on CPU anyway, I noticed immediately. Went to fix it. What followed was several weeks of googling, building from source, writing a custom PKGBUILD, setting up CI, publishing an AUR-style repo — and eventually discovering that the actual fix is a single extra package that pacman never once mentioned to me. The investigation First thing I checked: is the official extra/whisper-cpp package compiled with Vulkan support? All search results said no — -DGGML_VULKAN is explicitly OFF, GPU code is absent from the binary. The app sees your GPU through vulkan-icd-loader but has no code to actually use it. That matched exactly what I was seeing. So the binary itself was the problem. At the time, a separate whisper-cpp-vulkan package had existed in the repos but kept appearing and disappearing — and right then it was gone from both extra and AUR. AUR pushes were also temporarily restricted due to a supply-chain incident. So the "just install the vulkan variant" path was closed, though it used to be available sometime. The obvious move: build from source with -DGGML_VULKAN=ON , package it up, done. I published whisper-cpp-vulkan-arch with a PKGBUILD and prebuilt binaries, wired up CI to track upstream releases automatically and rebuild correspondingly, and wrote a Reddit post explaining the situation. The post was dated August 13, 2026. The twist A few weeks later, someone commented on the post. They suggested installing ggml and vulkan-icd-loader . I started writing a detailed reply explaining why this was wrong: gg

Have you ever watched a two-kilobyte write fail with No space left on device while df -h still showed free gigabytes? I did, and I spent the next forty-eight hours cleaning the wrong evidence. This is the reconstructed field notebook from that session, including the commands I ran, the ones that misled me, and the checklist I now run before I blame the disk. Nothing here is a benchmark, a quota promise, or a claim about hardware I did not measure. I was iterating on a small Python worker that dumped JSON sidecars next to each run. The worker itself was unremarkable. The failure mode was not. Hour 0: the write that should have been boring The first traceback looked like a disk problem, so I treated it like a disk problem. Would you have done anything else with ENOSPC staring at you from a three-line stack? I would not, and that is exactly how the next two days started. OSError: [Errno 28] No space left on device: 'runs/2026-09-05T07-12-04.json' I ran the obvious command, got a comforting number, and closed the wrong investigation. df -h reported plenty of space on the root filesystem, and /tmp looked equally relaxed. I even created a dummy file in $HOME by hand, which succeeded, so I told myself the worker path was special. df -h df -h /tmp /var /home touch ~/probe-ok.txt && ls -l ~/probe-ok.txt That last touch was the trap. Can a filesystem accept a file in one directory and refuse a tiny file in another while still having blocks to spare? Yes, and inode exhaustion is the boring reason. I did not ask that question for twelve hours. What I tried first, and why it felt reasonable I treated the symptom as log rot, because that is the story operators tell each other. I truncated worker logs, deleted old JSON sidecars I could see, and reran the job with a smaller batch. The write still failed, sometimes on file number twenty, sometimes on file number four. Truncated worker.log and debug.log with : > file instead of deleting the path. Removed a handful of large .jsonl fil

Managing files, running scripts, and executing terminal commands on your smartphone from a computer is much more convenient through a full SSH session, eliminating the need to switch between device screens. ​Installing OpenSSH Open Termux and install the package for the secure protocol: pkg update && pkg install openssh Configuration ​Set a password to secure the connection: passwd ​ Find your current username using the whoami command (usually looks like u0_a... ). ​Start the SSH server: sshd ​Connecting from a PC Find your smartphone's local IP address using ifconfig (look for the inet line under the wlan0 interface). Note that Termux uses a non-standard port 8022 by default instead of the standard 22. Connect from your computer (Linux, macOS, or Windows via PowerShell/PuTTY): ssh <username>@<smartphone_IP> -p 8022 After entering your password, you will gain full access to your phone's terminal directly from your PC. Autostarting the Server To avoid starting the server manually every time you open the app, add the command to your shell configuration: echo "sshd" >> ~/.bashrc This tool turns your mobile device into a fully functional remote node that is easy to manage over the local network when developing and testing lightweight projects. I share more simple and awesome smartphone IT projects on my Telegram channel: @termuxq

THE BRICK AND THE POST-IT My chemical plant's first vulnerability wasn't a bug, a piece of malware, or a port left open to the internet. It was a brick. In the computer room — the one with a door held open by a brick — I found a sticky note with credentials on it. They weren't even the right credentials for the system I wanted to break into. But they made me think the way whoever wrote them thinks, so I tried the most obvious pair in the world: admin / admin . And I was in. A brick propping open a door that should be locked. A sticky note guarding a password. A factory-default admin/admin. Three layers of security, three layers defeated — not by a genius hacker, but by a student on day one, carrying no tools at all. If that happens in the IT office, it's a problem. When it happens on a factory floor, where that same computer commands real pumps and valves, it's a different planet. The problem: learning OT without a factory I study computer security. Lately I've been drawn to OT — operational technology, the security of factories, power plants and industrial systems. The problem is simple: you can't learn to defend a factory from a book, and nobody will lend you theirs. Then I realized the answer was already inside the question: if you don't have one, you build one. The build: three commands and a lot of patience The lab is called GRFICSv3: an open source project that simulates an entire chemical plant — the PLC, the operator interface, the network, even the server rooms — inside Docker, on a home computer. Three commands and done: curl -O https://raw.githubusercontent.com/Fortiphyd/GRFICSv3/main/docker-compose.yml docker compose pull docker compose up -d "Three commands and done" is the story version. The real version includes my first error, arriving right on schedule at command number two: permission denied while trying to connect to the docker API at unix:///var/run/docker.sock If you hit this — and you will — here's the diagnosis: the Docker daemon is running fi

Disk full alerts at 2am? Learn the exact commands to find what's eating your Linux server's disk space and fix it fast. You get the alert: disk usage at 94%. Your app starts throwing errors, logs stop writing, and databases refuse to accept new rows. Finding the culprit fast matters — but on a server with millions of files, knowing where to look is half the battle. Here's a systematic approach to track down disk hogs in minutes, not hours. Start With the Big Picture: df Before you dig into directories, confirm which filesystem is actually full. Run: df -h — shows all mounted filesystems with human-readable sizes df -h / — focus on the root filesystem df -i — check inode usage (a filesystem can be 'full' even with free space if inodes are exhausted) Pay attention to the 'Use%' column. If you see 100% on /var or /home but not /, that tells you exactly which mount point to investigate. Inode exhaustion — df -i showing 100% — is easy to miss and causes the same symptoms as a full disk, so always check both. Drill Down With du Once you know which mount point is full, use du to find the largest directories. Start from the top of that mount point and work down: du -sh /* 2>/dev/null — sizes of every top-level directory, errors suppressed du -sh /var/* 2>/dev/null — drill into /var if that's the culprit du -ah /var | sort -rh | head -20 — list the 20 largest files and folders inside /var The pattern is always the same: run du -sh on the suspicious directory, find the largest subdirectory, repeat one level deeper. You'll usually hit the real culprit within three or four iterations. Common offenders are /var/log (runaway logs), /var/lib/docker (unused images and volumes), and /tmp (applications that don't clean up after themselves). Find Large Files Directly With find Sometimes a single enormous file is the problem — a core dump, a forgotten database export, or a log that rotated incorrectly. Use find to surface files above a size threshold: find / -xdev -size +500M -ls 2>/de

Zack Bartel has developed Tether, an open-source project designed to integrate Apple Continuity features with Linux workstations. Tether allows users to send iMessages, sync clipboards, and view iOS notifications directly on Linux. It uses secure local network communication and a custom Bluetooth stack to ensure reliable connectivity and robust security in cross-platform interactions. By Olimpiu Pop

A Linux safety certification is a statement about one defined software configuration running on named hardware, assessed by a named body. It is not a statement about the Linux kernel, and it does not give your item its integrity level. The document describing how a component like the kernel enters an ISO 26262 argument at all is ISO/PAS 8926:2024, published on 29 January 2024, which moves the question away from code quality and towards classification, complexity and evidence. Red Hat's In-Vehicle Operating System is the clearest public example: certified by exida against ISO 26262 Edition 2 (2018) as a Safety Element out of Context at ASIL-B, with Renesas naming the R-Car S4 as the first platform to be certified. If you build vehicle software on Linux, a supplier will at some point hand you a claim that sounds decisive: this platform is certified. The engineer who has to integrate it then finds the claim carries almost no information on its own. A Linux safety certification is bounded by a configuration, a set of assumptions, a hardware list and an assessor. This article explains where those bounds come from, what changed in 2024, and what to ask before accepting such a claim into your own safety case. Why the kernel cannot be qualified Functional safety standards assume a particular kind of software. A classic safety component is written against a complete requirements specification, each requirement traced to a design element, to code and to a test, with structural coverage evidence at the end. That is workable for tens of thousands of lines written by one team for one purpose. The Linux kernel is not that: tens of millions of lines, contributed by thousands of people who never wrote a requirements specification for the automotive context, changing on a nine-week cadence. An earlier article here, Safety-Critical Linux: What Certifying It Actually Takes , sets out how a safety argument is assembled around Linux. This goes a level below it: by what defined mechanism

TL;DR — On a MSI Stealth A16 AI+ (Ryzen AI 9 365, XDNA2 NPU) running Arch, I got OpenAI's whisper-large-v3-turbo transcribing on the NPU — not the CPU, not the GPU — at RTF ≈ 0.18 (a 30 s clip in ~5.2 s) for roughly a tenth of the energy the same job costs on the CPU, plus an LLM answering on the same NPU through an OpenAI-compatible API. The whole path is local and offline. This is the write-up of the driver stack, the one real gotcha (memlock), and the runtime that made it a 20-minute job instead of a weekend. Why this is worth writing down AMD's "Ryzen AI" NPU (the XDNA / XDNA2 block in Phoenix / Hawk Point / Strix Point laptops) is marketed almost entirely around Windows: the Ryzen AI SDK, the ONNX Runtime VitisAI execution provider, Lemonade, and the demos all assume you're on Windows with the official stack. On Linux the picture in early 2026 is better than most people think — the NPU driver has been in the mainline kernel as amdxdna since 6.14 — but the "load a real model and run it" story still isn't well documented. Here's what actually worked, end to end. The hardware Part Detail Laptop MSI Stealth A16 AI+ A3HVGG APU AMD Ryzen AI 9 365 (Strix Point) NPU XDNA2, 8 columns, exposed as /dev/accel/accel0 NPU firmware 1.1.2.64 Kernel 7.1.9-arch1 ( amdxdna in-tree) OS Omarchy (Arch Linux) AMD quotes the Strix Point NPU at up to 50 TOPS, INT8 . 1. The driver stack Three pieces have to be in place before any runtime can touch the NPU: amdxdna — the kernel driver. In-tree from Linux 6.14; it's what creates /dev/accel/accel0 . Check it's bound: $ ls /dev/accel/ accel0 $ dmesg | grep -i amdxdna XRT (Xilinx/AMD Runtime) + the xrt-plugin-amdxdna shim. XRT is the userspace API; the plugin teaches it about the XDNA device. On Arch both are in extra : $ sudo pacman -S xrt xrt-plugin-amdxdna $ xrt-smi examine ... XRT Version : 2.21.75 NPU Firmware Version : 1.1.2.64 Device(s) Present |BDF |Name | |----------------|--------------| |[0000:66:00.1] |RyzenAI-npu4 | You want a D

The most useful thing my home server taught me was not how to install another Docker container. It was how quickly a problem stops belonging to one tidy layer. A service can be running while DNS is wrong. Plex can work while the machine doing the transcoding cannot reach the storage. A reverse proxy can be configured correctly while the network around it is a mess. When it is your own server and you actually want to use it, those boundaries become your problem. That is very different from the way many application-focused software-engineering jobs feel. You can spend years building applications without having to join Linux, storage, DNS, HTTPS and networking together yourself. The experiments that kept getting turned off Around the start of 2020, I got a Raspberry Pi and repeatedly installed Raspbian or Debian on it. I would add Sonarr, Radarr, maybe Prowlarr, a torrent client and Plex. Sometimes Pi-hole joined them. There was no reverse proxy and I was not putting my own domains behind it. It was primitive, and I learnt something each time, but it never stuck, right? I would decide to play with it and eventually turn it off again. The Pi proved that I could run these services. It did not give me infrastructure I depended on. That changed in summer 2024. I had an old i5 desktop lying around, knew it worked and could connect drives to it easily. Why the hell not? I installed OpenMediaVault and spent the next two or three months building the setup out. Docker-managed services were joined by Traefik as a reverse proxy, Tailscale , proper DNS and network sharing. The useful result was a repeatable path for a new service. I could put it behind HTTPS and decide whether it should be public or only reachable inside my network. The machine was no longer an experiment waiting to be unplugged. A second machine made the lessons real I also bought a separate OptiPlex with 4 GB of RAM and installed Debian. Its main job was Plex Pass transcoding, reading media over the network from

1. How this project started? I'm going to be honest, it's been ages since I have written something without the use of AI to fix my writing. English is not my first language so please bear with me! With the rapid rise of AI, I felt that I have been losing passion for what I used to love at some point: learning . Nowadays, we can quickly solve most of our problems with the use of AI, often times, not even reviewing if it correct or not. That's why I decided to take some time daily to learn something new without or minimal use of AI. The first step is deciding, what should I try to learn first? Well, it was quiet easy to find out what. If you are into Linux, you have probably heard of Omarchy at this point. Like it or not, there's no deny that it's getting more popular among developers. So, why not try to build a decent looking Arch workspace? Before continuing, I would like to mention that this is not a guide. There are lot of resources online that teaches you how to install Archlinux and other packages. 2. Why Archlinux? Archlinux has -or had- the reputation of being difficult to get started with. Most of us are used to booting into a nice-looking, functional operating system. Although I have some Linux knowledge, I wanted to have a better understanding of what it takes to have a decent workspace. 3. Installing Archlinux The first step is actually installing Arch on my device. The device I'm going to use is my trusty built PC that I currently use exclusively for gaming. There are a few things to consider before jumping into installing Arch: My PC has an Nvidia RTX 5050 and AMD Ryzen 5 CPU. Need dual boot to switch between Windows 11 and Archlinux. I don't want to change the BIOS options repeatively. With this in mind, I quickly created a bootable USB using RUFUS . 3.1. Booting the USB If you are a Windows 11 user and have dual boot, you may know that Windows requires Windows Secure Boot. In order to boot another operation system, you'll need to change your Secure Boo

A syndication job noticed before I did A scheduled task publishes one blog post a day to a developer community. It fetches the article from my own site, converts it, and posts it. At 10:00 it failed four times with this: Server error '521 <none>' for url 'https://neuragrowth.co/blog/schema-grammar-ceiling/' 521 is Cloudflare saying the origin server did not answer. So the interesting failure was not in the syndication job at all. My whole site was down, and had been for over three hours by then. The server itself was fine: four days of uptime, load under 0.2, disk at eight percent. But systemctl is-active nginx said failed , and nothing was listening on 80 or 443. nginx resolves your upstreams before it starts The journal had the whole thing in three lines: 06:49:54 systemd[1]: Stopping nginx.service... 06:49:54 nginx[36027]: [emerg] host not found in upstream "example-backend.tld" in /etc/nginx/sites-enabled/site:104 06:49:54 nginx[36027]: nginx: configuration file test failed Line 104 was a small proxy I had added months earlier so the public site could forward one form endpoint to a backend on a different host without revealing its name: location = /api/lead-capture { proxy_pass https://example-backend.tld/api/lead-capture ; proxy_ssl_server_name on ; proxy_set_header Host example-backend.tld ; } When proxy_pass contains a literal hostname, nginx resolves it while parsing the configuration , and treats failure as a fatal config error. That resolution happens inside ExecStartPre=/usr/sbin/nginx -t , so a name it cannot look up means the unit never starts. The config was not wrong. It was valid before the restart and valid after, and nginx -t passed by hand seven hours later. It was invalid for about one second. Why DNS was gone for exactly that instant Ten seconds of journal, reconstructed: 06:49:44 apt-daily-upgrade.service starts 06:49:53 "Reexecution requested ... (unit apt-daily-upgrade.service)" 06:49:53 systemd reexecuting (it had just upgraded itself) 06:49

Debian voted to allow developers to use AI tools in their contributions to the Linux distribution's "development, maintenance, [and] documentation." The new policy on AI acknowledges that "responsible" use of AI can improve developers' productivity, and goes on to say, "generative AI is neither exempt from nor subject to special rules beyond the standards already […]

Every self-hosted project I run starts the same way: a brand new VPS and about twenty minutes of setup before I install a single application. That twenty minutes is what separates "my server" from "someone else's crypto miner." A fresh box with a public IP starts getting probed within minutes, and the default configuration on most images is built for convenience, not safety. This is the secure baseline I set up on every new server, before Docker, before n8n, before anything else. It is also the starting point our production n8n guide assumes you already have. Every command below was checked against current Ubuntu LTS documentation, and I flag the parts that genuinely need a real server to verify. Key takeaways Never do daily work as root. Create a sudo user and log in as that instead. Use an SSH key and turn password login off, but only after you confirm the key works. Deny everything at the firewall by default, then open only the ports you actually use. Turn on automatic security updates so patches land while you sleep. If you plan to run Docker, remember that published ports skip UFW. Bind them to 127.0.0.1 . Prerequisites A VPS running a current Ubuntu LTS. Both 24.04 "Noble Numbat" and 26.04 "Resolute Raccoon" work well. I run long-lived boxes on Hostinger VPS hosting , which is also what powers the n8n guide. An SSH key pair on your own machine. If you do not have one yet, Step 3 creates it. A terminal, and a note of your provider's recovery console. Most hosts, Hostinger included, give you a browser based console in their control panel. That is your way back in if you ever lock yourself out, so find it before you start. Disclosure: some links in this guide, including the Hostinger link above, are referral or affiliate links. If you sign up through them we may earn account credit or a commission, at no extra cost to you. We only point at tools we actually run. Step 1: Log in and update the system Right after the server boots, log in with the credentials your pr