标签：#ubuntu

As I stated in my introduction , the first piece of work I did on Packet Sender was fix the Snapcraft build. What is Snapcraft? It has been a while since I've worked with Ubuntu, so I wasn't up to speed with how Ubuntu was now doing things like package management. As I understand it, apt and/or apt-get is still a thing, but Snapcraft is the new shiny. Snapcraft is more than just an app repository, though. It's a build system, dependency manager and a packager. Ergo, the vertical integration means you don’t have to keep multiple tools in sync. The Problem When building Packet Sender with Snapcraft, the product would build, link and run. But as soon as you ran it, it would crash with the following error message: /snap/packetsender/49/usr/local/bin/packetsender: error while loading shared libraries: libpxbackend-1.0.so: cannot open shared object file: No such file or directory .dll(s) and .so(s) I grew up in the '90s. This meant that, unfortunately, I grew up in the age of Microsoft, meaning I started on PCs. While I remember Windows 3.1's UI, I didn't really start using computers until Windows 95. My first machine was a Windows 98 box. I tell you this so you know that I grew up knowing what a .dll is because I grew up using Windows. Simply put, a .dll is a shared library . The idea was that instead of having to compile common libraries into executables and thus bloat the size of executables and the amount of memory they needed, vendors could deliver a shared library that would be loaded into memory once and could be called at run time by any running process that needed them. Of course, Microsoft being Microsoft, this was poorly engineered . .so s 1 are the same idea but on *nix. Thankfully, they had time to learn from Microsoft's mistakes. What does the error message mean? Simply put, what the error message was trying to tell us was that when the code was compiled, we assumed the .so files would be in a given place, but they weren't. One common way to fix this is with

How Linux file permissions actually work under the hood, why symbolic mode is your best friend, and how to stop blindly typing chmod 777. Every Linux engineer has been there. You write a brand-new bash script, try to run it from your terminal, and hit an immediate roadblock: $ ./backup.sh bash: ./backup.sh: Permission denied You open your search engine or ask a chat assistant for help. Within seconds, you find an answer that tells you to run: chmod 777 backup.sh You run the command, hit enter, and the script runs. Problem solved, right? Not quite. In fact, you just opened the digital front door of that file to every single user and background service on the entire operating system. When I started managing Linux servers years ago, permissions felt like a strange puzzle of three-digit math problems. People kept throwing numbers around: 755 for scripts, 644 for web pages, 600 for SSH keys, and 777 whenever something broke and nobody knew why. I memorized those numbers like cheat codes in a video game. But whenever I had to handle a real permission problem, like giving a development team write access to a shared log folder without letting them delete each other's files, memorized numbers fell apart. Here is the secret: you do not need to do binary math or memorize three-digit codes to master Linux permissions. Linux has a built-in, human-readable permission syntax called symbolic mode . Once you understand how Linux looks at files, who owns them, and what actions each permission controls, chmod becomes one of the most intuitive tools in your terminal. Let's break down how it all works step by step. 1. What chmod Actually Does The name chmod stands for change mode . In Unix and Linux systems, every single file and directory has a "mode". That mode determines who is allowed to read it, write to it, or run it. When you run chmod , you are simply updating those access bits inside the Linux filesystem inode. To see the current mode of your files, open any terminal and run ls

Introduction It was a perfectly normal day. I opened my laptop, ready to get some work done, and then... BAM. A black screen. Not a gentle fade to black, but more like my computer shouting, "I’ve had enough of your crap!" The same operating system that had been working perfectly just five hours earlier had suddenly decided it had had enough of life. I wasn't too worried though. After all, I had ChatGPT on my side. Three hours later... Yeah... my confidence crumbled faster than my phone battery at 2%. What followed was a three-hour rabbit hole involving NVIDIA drivers, multiple Linux kernels, Secure Boot, DKMS, Xorg, GDM, journalctl , systemd , and more terminal commands than I'd like to admit. Somehow, against all odds (and probably a little divine intervention), we managed to fix it. And honestly? I enjoyed every minute of the chaos. It was like a wild adventure—except with more curse words and less danger. So I decided to document the entire debugging journey—not just because it might help someone who runs into the same issue, but also because I deserve a little sympathy after spending three hours arguing with my laptop. (And if the solution seems painfully obvious to you... please let me enjoy my victory. Don't take this away from me.😤 The Problem After rebooting my laptop, I was greeted with just a black screen. No login screen, no desktop… just nothing.** At first, I tried to enter TTY using Ctrl + Alt + F3, but that wasn’t working either. Since I wasn’t able to reach TTY directly, I had to take a different route. By editing the GRUB boot entry and booting into multi-user.target , I forced Linux to start in text-only mode, giving me access to a terminal.** For this, I edited the GRUB boot entry and appended systemd.unit=multi-user.target to the end of the kernel command line (after quiet splash ). That was the first breakthrough, though. The operating system wasn’t completely dead… only the graphical interface was failing to wake up. First Clues and Initial Ass

There's a delightfully literal answer to "Kubernetes with Docker": kind — Kubernetes IN Docker. Each node is a Docker container running a full Kubernetes node image. On an Ubuntu workstation it gives you a real, throwaway, multi-node cluster in about 30 seconds. It's my default for local dev and for CI. Prerequisites on Ubuntu You need Docker Engine and kubectl . If you don't have Docker yet: sudo apt-get update && sudo apt-get install -y docker.io sudo usermod -aG docker $USER && newgrp docker # run docker without sudo Install kind (single static binary): curl -fsSLo ./kind https://kind.sigs.k8s.io/dl/latest/kind-linux-amd64 chmod +x ./kind && sudo mv ./kind /usr/local/bin/kind kind version A one-command cluster kind create cluster --name dev kubectl cluster-info --context kind-dev docker ps # you'll see a dev-control-plane container — that's your node kind wrote a kubeconfig context for you. Tear the whole thing down just as fast: kind delete cluster --name dev A realistic multi-node cluster Most bugs only show up with more than one node (scheduling, affinity, PodDisruptionBudgets). Define it in a config file: # kind-cluster.yaml kind : Cluster apiVersion : kind.x-k8s.io/v1alpha4 nodes : - role : control-plane kubeadmConfigPatches : - | kind: InitConfiguration nodeRegistration: kubeletExtraArgs: node-labels: "ingress-ready=true" extraPortMappings : - containerPort : 80 hostPort : 8080 protocol : TCP - role : worker - role : worker kind create cluster --name dev --config kind-cluster.yaml kubectl get nodes The extraPortMappings bit is the trick people miss: it forwards a port from your Ubuntu host into the control-plane container, so an ingress controller inside the cluster is reachable at http://localhost:8080 . Loading a locally-built image (no registry needed) This is kind 's best feature for the Docker workflow. Build with Docker, push straight into the cluster's nodes — no registry round-trip: docker build -t myapp:dev . kind load docker-image myapp:dev --name

minikube is the other "Kubernetes in Docker" option on Ubuntu, and with --driver=docker it runs the cluster inside a Docker container just like kind — but ships with addons (ingress, metrics-server, dashboard, a built-in registry) that make it feel more like a real cluster. Here's a practical setup and how it differs from kind . Install on Ubuntu You need Docker first ( sudo apt-get install -y docker.io , then add yourself to the docker group). Then: curl -fsSLo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64 sudo install minikube /usr/local/bin/minikube minikube version Start with the Docker driver minikube start --driver = docker # make it the default so you don't repeat the flag: minikube config set driver docker kubectl get nodes docker ps # a 'minikube' container is your node Size it for real work: minikube start --driver = docker --cpus = 4 --memory = 8g --disk-size = 40g The addons are the reason to pick minikube minikube addons list minikube addons enable ingress minikube addons enable metrics-server minikube dashboard # opens the web UI ingress gives you a working NGINX ingress controller with no manifest wrangling — genuinely useful when you want to test ingress routing locally. The Docker image workflow minikube runs its own Docker daemon inside the node container. The neat trick is pointing your shell's Docker CLI at that daemon, so images you build are immediately visible to the cluster with no push: eval $( minikube docker-env ) # your `docker` now talks to minikube's daemon docker build -t myapp:dev . kubectl create deployment myapp --image = myapp:dev # remember: imagePullPolicy: IfNotPresent so it doesn't try a registry pull Undo it when you're done so docker points back at your host daemon: eval $( minikube docker-env -u ) There's also a built-in registry if you prefer the push model: minikube addons enable registry Accessing services from Ubuntu Two common patterns: # quick tunnel to a single service (prints a

1. Introduction Hello from Japan! 🇯🇵 I am an active truck driver in Japan self-studying Python and Web technologies, leveraging my logistics domain knowledge to transition into a Web Engineer. (English is my second language, but I'm excited to share my progress with developers worldwide!) I started my learning journey on May 12, 2026. As of June 4, I have logged 24 days and 86 cumulative hours of study. This article documents my progress, learning roadmap, and project milestones chronologically. Check out my GitHub here👈️ (Note: Most repository documentation and commit messages are currently in Japanese.) 2. The 86-Hour Learning Roadmap A quick breakdown of my 86 hours: 80 hours were dedicated to hands-on development and implementation, and 6 hours were spent on environment configuration, documentation, and workflow optimization. Stages 1–3: Automation & Scraping Projects ① Fundamentals & Web Scraping (25 hours) Learned core Python syntax and built automated scripts to collect targeted web data. ② Puoppo Auto-Analysis System (15 hours) Implemented automated poll data retrieval and AI-powered text analysis on Lubuntu. ③ Bakery Sales Aggregation System (12 hours) Integrated web scraping with automated Excel processing to streamline sales data aggregation. Stage 4: Practical Ruby on Rails ④ rails_practice (23 hours) Explored MVC architecture in Ruby on Rails. Practiced configuration management and Git rebasing to build a solid foundation in web framework operations. Stage 5: Real-World System Integration ⑤ hiroshima-logistics-hub (5 hours) Built a web system to aggregate real-time weather and traffic conditions in the Hiroshima area. Technical Fix : To bypass build crashes on Render (Free Tier / 512MB RAM), I precompiled assets locally and configured SQLite3 database storage in writable directories before deployment. 3. Key Takeaways for Resource-Constrained Development Through these projects, I established three operational principles for developing efficiently within

Data preservation layouts are no longer just an exercise in handling routine disk failures; they are a direct line of defense in an active cyber-warfare environment. Far too many system administrators blindly default to writing simple, unencrypted shell scripts tied to legacy system utilities. Operating obsolete data-mirroring procedures introduces severe vulnerabilities to enterprise architectures. Traditional file sync tools completely lack client-side encryption barriers, leaving raw production data completely exposed to third-party infrastructure hosts. Furthermore, standard backup approaches consume vast amounts of unnecessary bandwidth by redundantly transferring identical files over and over again. Restic completely destroys this insecure paradigm. Written from the ground up in Go, Restic enforces client-side AES-256-CTR cryptographic encryption by default, ensuring no plain-text data ever traverses the network interface. Leveraging advanced content-defined chunking algorithms, it performs lightning-fast block-level deduplication to compress your overall storage footprint to a minimum. Phase 1: The Backup Orchestration Myth Understanding the architectural superiority of a native Go-compiled, client-side encrypted backup engine is critical before designing your disaster recovery pipeline: Architectural Metric Legacy Sync Tools BorgBackup Platform Modern Restic Engine Native Cloud S3 Support Requires Rclone Mounts Requires Third-Party Proxy Layers Native Compiled Support Default Cryptography None (Plain-Text Transmissions) Client-Side AES-256 AES-256-CTR Client-Side Data Deduplication File-Level Verification Only Content-Defined Block Level Content-Defined Block Level Cross-Platform Portability Variable Compatibility Strictly UNIX/Linux Constrained Single Static Go Binary Phase 2: The Append-Only Lock Paradox (IAM Fix) The most dangerous operational vulnerability found in generic Linux documentation involves key privileges. Amateurs store fully unconstrained ad

Amid all the noise about dockershim, one thing got lost: the everyday workflow of building an image with Docker and running it on Kubernetes never changed. Docker is still an excellent build tool, Kubernetes still runs OCI images, and on Ubuntu the loop is clean. Here it is end to end. 1. A build-friendly Dockerfile Multi-stage keeps the runtime image small and the attack surface low — this matters more on Kubernetes, where you pull the image onto every node that schedules the pod: # build stage FROM golang:1.22 AS build WORKDIR /src COPY go.* ./ RUN go mod download COPY . . RUN CGO_ENABLED = 0 go build -o /out/api ./cmd/api # runtime stage — distroless, no shell, tiny FROM gcr.io/distroless/static:nonroot COPY --from=build /out/api /api USER nonroot:nonroot EXPOSE 8080 ENTRYPOINT ["/api"] 2. Build and push with Docker on Ubuntu Use buildx (bundled with modern Docker) so you can build multi-arch — worth it if any nodes are arm64: docker buildx build \ --platform linux/amd64,linux/arm64 \ -t registry.example.com/api:1.4.2 \ --push . Tag with an immutable version, never rely on :latest . Kubernetes caches images per node; :latest makes "which build is actually running?" unanswerable and breaks rollbacks. 3. A deployment that behaves in production apiVersion : apps/v1 kind : Deployment metadata : name : api spec : replicas : 3 selector : { matchLabels : { app : api } } template : metadata : { labels : { app : api } } spec : containers : - name : api image : registry.example.com/api:1.4.2 # the exact tag you pushed imagePullPolicy : IfNotPresent ports : [{ containerPort : 8080 }] resources : requests : { cpu : " 100m" , memory : " 128Mi" } limits : { memory : " 256Mi" } readinessProbe : httpGet : { path : /healthz , port : 8080 } initialDelaySeconds : 3 livenessProbe : httpGet : { path : /healthz , port : 8080 } initialDelaySeconds : 10 The readinessProbe is the piece people skip and regret: without it, Kubernetes sends traffic to a pod before your app is listening, and

The wrong way to install Docker on Ubuntu is the one that looks easiest: sudo apt install docker.io . That package exists, it installs, and it runs a container. It is also whatever version happened to be frozen into the archive when 26.04 was cut, it lags the real releases by months, and it ships without the Compose and Buildx plugins you will want by the end of the week. Use Docker's own apt repository instead, and this is the post I keep open so I do not re-derive the repo setup from memory each time. This is short on purpose. The steps are the official ones, and the only place worth slowing down is step 5, where adding yourself to the docker group quietly hands out root. That tradeoff is the part most guides skip, and it is the one thing here actually worth reading twice. TL;DR Remove any distro docker.io / containerd packages, add Docker's GPG key and the deb822 .sources repo, then sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin . Verify with sudo docker run hello-world . Add yourself to the docker group to drop the sudo (it is root-equivalent, more below). Prerequisites Ubuntu 26.04 (Resolute Raccoon), server or desktop, on amd64 or arm64 . A user with sudo. If you are still on root, create a sudo user first . Outbound HTTPS to download.docker.com . 1. Remove the distro Docker packages first Ubuntu ships its own docker.io , docker-compose , and containerd packages, and any of them will fight the official ones over the same files and the same containerd socket. Clear them out before you add Docker's repo. This is safe on a fresh box because there is nothing to lose yet; on a box that already ran the distro Docker, it removes the packages but leaves your images and volumes in /var/lib/docker alone. sudo apt remove $( dpkg --get-selections docker.io docker-compose docker-compose-v2 docker-doc podman-docker containerd runc | cut -f1 ) The dpkg --get-selections wrapper is just so the command does not error out on pac

Installing Ubuntu Server 24.04 LTS in an offline mode (no LAN cable or WiFi connected) leaves you with an unmanaged network interface which requires manual configuration post-install. The interface enp4s0 is unmanaged by systemd-networkd and also the service itself is disabled. NOTE: This guide applies to Ubuntu server. On Ubuntu desktop you have the NetworkManager service installed and the steps would be different. To fix the problem follow the steps below: Create a Brand New Netplan Configuration File Look into /etc/netplan . You will probably see the dir is empty. This means the installer completely gave up on configuring the network and didn't create any profiles. Create a new file, e.g. vim /etc/netplan/01-netcfg.yaml . Paste the following configuration network : version : 2 renderer : networkd ethernets : enp4s0 : dhcp4 : true This makes the interface managed by networkd instead of the desktop NetworkManager. Fix permissions The new file needs to be readable only by root so fix it's permissions chmod 600 /etc/netplan/01-netcfg.yaml . Enable network service Enable the network service and make it start on boot: systemctl enable systemd-networkd systemctl start systemd-networkd Run netplan Finally, we need to tell Ubuntu to use our new configuration and activate the network netplan generate netplan apply Network should be up! ip a

My main work laptop is a Dell from 2017 with 8 GB of RAM. For weeks it had been crawling, freezing for whole seconds while I worked, and every so often it would simply switch itself off in the middle of a task. If you have ever lost unsaved work to a laptop that powers down on its own, you know exactly how frustrating that is. So I sat down and fixed it properly. The first thing I learned is worth saying up front: a slow, crashing laptop is usually two different problems wearing the same costume . Treat them as one and you will chase your tail. Separate them, and both become fixable. Everything below is free and copy-paste ready. It was tested on Ubuntu 24.04 LTS, and it applies to almost any older Linux machine. The honest disclaimer: Nobody can promise an old laptop will never lag. Software cannot add cores or memory that are not physically there. But you can absolutely stop the freezes and shutdowns completely and make everyday work feel smooth. That is the realistic, achievable goal. 0. Diagnose first, do not guess The biggest mistake is blindly applying "speed up Ubuntu" tweaks before knowing what is actually wrong. Spend five minutes measuring. Your lag has one of four common causes: heat, memory, disk, or a dying battery . Check temperature (the usual cause of random shutdowns): sudo apt install lm-sensors -y sudo sensors-detect --auto sensors Watch the Core temperatures while you work. If they spike past 90 to 100 °C right before a crash, you have a thermal problem, not a software one. Check memory (the usual cause of freezing): free -h sudo apt install htop -y htop In htop , watch the Mem and Swp bars during normal use. If memory pins near your limit and swap fills up, that thrashing is your freeze. Check disk space (a quiet killer): df -h / A root partition above 90% full makes Linux lag and turn unstable. Small SSDs fill up fast. Read the crash logs and battery health: # What went wrong during the previous (crashed) session journalctl -b -1 -p err --no-pa

QTRACTOR BIBLE Volume 1 — Foundations PART I — QTRACTOR CONCEPTS & WORKFLOW MODEL Chapter 1 — What Qtractor Is Quick Start Qtractor is a non-destructive, multi-track audio and MIDI sequencer designed primarily for Linux-based production environments. Unlike applications that attempt to integrate every aspect of the audio ecosystem into a single package, Qtractor focuses on recording, sequencing, editing, routing, mixing, and rendering while cooperating with external audio infrastructure and specialized tools. Qtractor is best understood as a timeline-centered production environment where audio clips, MIDI clips, plugins, automation, and routing configurations are organized into sessions. Common uses include: Music production MIDI composition Podcast production Voice recording Sound design Film scoring Hybrid hardware/software studios Live backing-track preparation Design Philosophy Qtractor follows several fundamental principles: Non-Destructive Editing Source media files remain unchanged. When a clip is trimmed, split, faded, moved, stretched, or processed, Qtractor modifies references and parameters rather than rewriting the original recording. Benefits include: Unlimited experimentation Reversible editing Reduced storage requirements Safer project management Session-Based Workflow Every operation belongs to a session. A session contains: Track definitions Clip placements Bus configurations Plugin assignments Automation data Routing information Tempo maps Markers Audio and MIDI source files remain separate from session instructions. Timeline-Centered Production The timeline is the primary workspace. Nearly every task ultimately relates to a position on the timeline: Recording Editing Automation Arrangement Export Qtractor is optimized for linear productions rather than clip-launching performance systems. Open Ecosystem Integration Qtractor assumes cooperation with: Audio servers MIDI systems External synthesizers External samplers Video playback tools Modular audi

Complete First-Time Setup Guide for Qtractor on Ubuntu 26.04 install and prepare the system verify audio works configure PipeWire/JACK configure Qtractor record audio record while playing other tracks export projects tune latency troubleshoot problems Qtractor is a lightweight Linux DAW (Digital Audio Workstation) for audio and MIDI recording. On Ubuntu, most problems come from: JACK / PipeWire / ALSA conflicts Permissions Wrong audio device selection Monitoring setup Sample-rate mismatches USB devices reconnecting Tracks not armed correctly This guide walks through a strategic / systematic / stable setup from zero, and covers the common failure cases along the way. PART 1 QUICK START SETUP 1. Understanding the Linux Audio Stack Modern Ubuntu audio typically works like this: Applications PipeWire JACK compatibility layer ALSA drivers Audio hardware For Qtractor, the recommended setup is: PipeWire enabled JACK compatibility enabled Qtractor using JACK mode through PipeWire 2. Install the Required Packages Install everything needed: sudo apt update sudo apt install \ qtractor \ pipewire \ pipewire-audio \ pipewire-pulse \ pipewire-jack \ wireplumber \ qpwgraph \ helvum \ pavucontrol \ alsa-utils \ jackd2 \ qjackctl \ ffmpeg Useful tools: Tool Purpose qtractor DAW qjackctl JACK control panel qpwgraph audio routing graph helvum simpler routing pavucontrol audio device management alsa-utils microphone troubleshooting 3. Reboot After installation: reboot This ensures all audio services start cleanly. 4. Verify the Audio System Is Running Check PipeWire: systemctl --user status pipewire Check WirePlumber: systemctl --user status wireplumber Check Pulse compatibility: systemctl --user status pipewire-pulse You should see: active (running) 5. Verify Audio Devices Exist Check Playback Devices aplay -l Check Recording Devices arecord -l Check PipeWire Audio Nodes wpctl status You should see sections like: Audio Devices Sinks Sources Typical onboard audio may appear as: Built-i