标签：#Linux

By default, whenever you request a machine learning model, the underlying architecture saves gigabytes of tensor data into a hidden directory located directly inside your home folder ( ~/.cache/huggingface ). Because standard bare metal and virtual cloud configurations typically isolate the root operating system on a smaller, highly optimized boot drive, pouring 140GB+ of raw weights into the home folder guarantees absolute storage exhaustion. Here is the engineering blueprint to fix it cleanly on Linux. The Cache Location Trajectory When attempting to solve this problem, avoid outdated tutorials recommending deprecated parameters like TRANSFORMERS_CACHE . Environment Route Support Status Architecture Impact HF_HOME Active Master Route Safely redirects all models, datasets, and core assets globally. TRANSFORMERS_CACHE Deprecated Warning Fails to capture datasets and will be removed in version 5.0. HUGGINGFACE_HUB_CACHE Deprecated Warning Legacy routing path that creates unnecessary diagnostic warnings. 🛑 The Symlink Security Risk Creating symbolic links (symlinks) to trick the OS into routing files elsewhere is a common anti-pattern. Mapping these links improperly or running your workflow with elevated rights introduces privilege escalation vulnerabilities, compromising container and host security. Step 1: The Permanent Environment Override To change your Hugging Face cache directory on Linux permanently, target an expansive secondary storage array instead by appending a direct master route into your user profile configuration: # Create a dedicated folder inside your secondary storage array sudo mkdir -p /mnt/massive_drive/ai_model_cache sudo chown -R $USER : $USER /mnt/massive_drive/ai_model_cache # Append the master environment variable to your bash profile echo 'export HF_HOME="/mnt/massive_drive/ai_model_cache"' >> ~/.bashrc source ~/.bashrc Step 2: The Python Import Order Mandate If you declare your custom storage location programmatically inside an application

I have been working on building a private, secure network accessible from anywhere. The goal was to connect my mobile phone and my local development laptop using a WireGuard VPN , hosting the central gateway on a free-tier Google Cloud Platform (GCP) e2-micro instance. I wanted to access my self-hosted services, specifically my Docker-hosted Open WebUI , running on my local home Wi-Fi connected laptop, directly from my phone using mobile data. It sounded straightforward. But if you read my other from scratch journeys, you might have already guessed, it was not. The Setup My architectural plan was a simple hub-and-spoke topology: The Hub: GCP VM ( 10.66.66.1 ) with IPv4 forwarding enabled. Spoke 1 (My Phone): 10.66.66.2 Spoke 2 (My Laptop): 10.66.66.3 I wrote my server configurations, enabled IP forwarding ( net.ipv4.ip_forward=1 ), wrote the iptables rules to allow forwarding between peers, and started the interfaces. Then came the moment of truth. I tried to bring up the tunnel. Absolute silence. No packet moving from anywhere. Hurdle 1: The Classic Cloud NAT Trap (Internal vs. Public IP) Before I could even worry about routing packets between my phone and laptop, I couldn't even get them to handshake with the GCP server. Like many of us do when working inside a VM, I had run ip addr on the GCP instance to grab its IP address for my client configurations. I set up the WireGuard peers to point to this IP. Nothing connected. The Culprit: GCP (and AWS) operates on a 1:1 NAT mapping. The virtual network interface inside your VM only sees and binds to a private, internal cloud IP (e.g., 10.128.0.x ). The public IP assigned to your instance lives outside the VM at the VPC gateway level. By putting the internal IP into my client configs, my phone and laptop were trying to connect to a private address that didn't exist on their local networks. The Fix: I had to swap the internal IP in the client configurations with the GCP Ephemeral/Static External IP . Once the handshake

Creator says he will "very loudly ignore" those arguing for a ban on AI tools.

If you have ever built an autonomous mobile robot, you have likely run into the dreaded "Shuffled USB Port" problem. You boot up your robot, fire up your ROS 2 launch files, and... crash. Your LiDAR driver is trying to parse data from your IMU, and your IMU node is screaming about invalid serial frames. Because Linux assigns virtual serial paths like /dev/ttyUSB0 and /dev/ttyUSB1 based purely on which device initialized milliseconds faster, relying on default OS paths is a recipe for system instability. When you are scaling up to dozens of Jetson Orin nodes —each equipped with an RPLIDAR C1 and a Yahboom 10-axis IMU —manually hardcoding paths or writing rigid scripts on every individual machine isn't viable. Here is how production-grade robotics fleets handle plug-and-play USB binding dynamically using configuration-driven udev rules. The Core Concept: Vendor ID vs. Physical Port vs. Serials Linux's udev (device manager) allows us to dynamically create stable symbolic links (symlinks) like /dev/rplidar and /dev/imu when hardware is plugged in. How we identify those devices determines our fleet's flexibility: USB Serials: Unique to each individual chip. Highly secure, but requires registering every single replacement sensor in your codebase. Physical USB Ports ( KERNELS ): Tied to a physical slot on the carrier board. Great if you have identical sensors, but forces technicians to plug cables into highly specific, undocumented ports. Vendor ID (VID) & Product ID (PID): Identifies the USB-to-serial converter chip on the sensor board. Because the RPLIDAR C1 uses a Silicon Labs CP210x chip ( 10c4:ea60 ) and the Yahboom IMU uses a QinHeng CH340 chip ( 1a86:7523 ), they use completely distinct silicon. This means we can map them dynamically and reliably using just their VID/PID —allowing field technicians to plug them into any USB port on the Jetson without breaking the system. Step 1: The Configuration-Driven File ( devices.conf ) Hardcoding vendor rules inside shell scri

Hello, I'm Maneshwar. I'm building git-lrc, a Micro AI code reviewer that runs on every commit. It is...

Downloading an installer and immediately executing it as root collapses three operational decisions into one command: Which artifact? -> Did these bytes arrive intact? -> Should this host execute them? Separate those decisions and the install becomes reviewable, reproducible, and recoverable. A concrete source-review boundary At commit c58bcd4 , the MonkeyCode runner installation template selects x86_64 or aarch64 , checks AVX on x86, requires root, and downloads an architecture-specific installer before executing it. The reviewed template uses curl -4sSLk , so certificate verification is disabled by -k . It also downloads an unversioned path. I could not find a pinned version, digest, or signature check in that template. That is a statement about controls visible in one pinned file—not a claim that the release service is compromised or that no external release control exists. Put a manifest before execution For each release artifact, publish immutable metadata through a separately protected release process: { "version" : "1.2.3" , "architecture" : "x86_64" , "file" : "runner-installer-1.2.3-x86_64" , "sha256" : "<64 lowercase hex characters>" , "size" : 18439210 , "rollback" : { "previous_version" : "1.2.2" , "artifact" : "runner-installer-1.2.2-x86_64" } } SHA-256 detects bytes that differ from the manifest. It does not prove who authored the manifest. Serve the manifest over validated TLS, pin it through deployment configuration, or sign it and verify the signature with a trusted offline public key. Verify as an unprivileged staging step The companion verify-installer.mjs checks filename, exact size, digest, version, architecture, and rollback metadata: node verify-installer.mjs release-manifest.json fixture-installer.sh node test-verifier.mjs Expected output uses the fixture's actual digest: PASS 1.2.3-fixture sha256=<digest> PASS verified fixture; rejected tampered artifact before execution The negative test appends a line to the artifact and requires both size

Native XDP and generic SKB-mode XDP are not the same thing in practice. The same BPF program can pass the verifier and still behave differently depending on which mode the kernel uses, this could be a different verdict, different frame bytes, or different metadata. This post ships three things: an open differential test harness, a fixed eleven-packet corpus, and a simple way to classify the differences it finds. A tagged release lets anyone reproduce the virtio/veth baseline on Linux 6.8. The operational risk is straightforward. A firewall or rate-limiter validated only under native XDP can fall back to generic mode on an unsupported driver, a veth port, or after a reload. You keep the same bytecode, but behaviour can change, often without a clear error line. What this release includes: A harness loop: corpus → inject on the RX path → native vs generic sweep → xdpdump capture → compare.py manifest, comparing both the captured frame bytes and the XDP verdict ( PASS / DROP / TX / REDIRECT ). A deterministic corpus with eleven embedded test IDs ( 0xA001 – 0xA005 , 0xA007 – 0xA00C ; 0xA006 is intentionally omitted as a reserved gap in the generator). An operational divergence taxonomy (Class A / B / C). A virtio/veth smoke gate on Linux 6.8; now gating on frame bytes and verdict agreement that shows the full path is reproducible end to end. Scope for this post: native vs generic XDP on the virtio_vm profile only (five BPF programs, pinned manifests). This is part 1 of 2; it establishes the harness and an instrument-validity baseline; a follow-up post covers bare-metal divergence results. Physical NIC results are not part of this baseline. Ordinary conformance checks stop at “did the program load?” Differential testing asks a sharper question: given identical input packets, do the backends produce the same observable outcome at the hook? Background: native vs generic XDP Both modes load the same BPF object. They diverge at the hook point and in how the packet is represen

Developers flagged a freshly filed, reproducible issue that should make anyone running background agents pause: Claude Code's background Opus subagents intermittently stall on their first turn and, instead of producing useful work, emit system-prompt fragments — including text shaped like authorization data — as their only output. It's labeled a security issue, it has a reproduction, and it's open. That's enough to treat it as a real, if intermittent, class of failure. Here's the mental model that matters: a subagent is not a trusted subprocess. It's an autonomous loop with access to a context window, a toolset, and — too often — the same credentials as its parent. When that loop stalls and dumps its prompt instead of its result, anything that was in context is now in output. Authorization-shaped text leaking is the canary: if the prompt carried a token, a session string, or an internal endpoint, that's what surfaces. The fix is structural, not reactive. Three rules: 1. Scope credentials per subagent, not per session. A background agent that only needs to read a repo shouldn't hold deploy keys. Hand it the narrowest token that completes its task and revoke it when the task ends. If the tooling can't scope credentials, that's a gap to close before you scale subagents. 2. Treat subagent output as untrusted. Anything a subagent returns — including error text, logs, and especially "stalled" dumps — should be parsed and sanitized before it touches shared state. Don't pipe raw subagent output into a context that feeds other agents or into any log that leaves your machine. 3. Separate the system prompt from the working context. The leak happened because authorization-shaped content sat in the same window the subagent could echo. Keep credentials and internal routing data out of the prompt that a stalled loop might surface. Put them in a side channel the model can call, not text it can print. The deeper lesson is about failure modes, not one bug. Most agent setups assume th

The feed showed a new entrant worth watching: Tencent has launched Hy3, a coding-focused AI model, with input tokens priced at $0.14 per million. For developers who live in the terminal running coding agents, that price point lands well below the per-token rates most frontier models charge, and it puts a major lab's coding model into the "cheap enough to leave running" category. What makes this interesting isn't just the number — it's the positioning. Hy3 is being pitched specifically as a coding AI, not a general chatbot, which suggests vendors are starting to carve out developer-facing models with their own pricing tiers rather than forcing coders to pay general-purpose rates. Developers spotted the launch in the daily AI news roundup and immediately started comparing it against the cost of running their existing agents. The catch, as always, is what the headline price doesn't tell you: output token cost, context-window limits, and how the model actually performs on real repository tasks all remain open questions. A low input price is meaningless if output is expensive or if the model needs five retries to get a diff right. Still, a credible cheap coding model from a major player is exactly the kind of pressure that nudges the whole category toward per-token transparency. If nothing else, it gives every other vendor a new number to justify theirs against.

Notes from bringing up a PCIe WiFi module on i.MX8MQ; symptoms and how to diagnose them. Phy link never came up — what does this mean? This message is typically seen in dmesg as shown below. [ 3.828121] imx6q-pcie 33800000.pcie: iATU: unroll T, 4 ob, 4 ib, align 64K, limit 4G [ 4.807241] imx6q-pcie 33c00000.pcie: Phy link never came up [ 4.841482] imx6q-pcie 33800000.pcie: Phy link never came up [ 5.821279] imx6q-pcie 33c00000.pcie: Phy link never came up [ 5.830481] imx6q-pcie 33c00000.pcie: PCI host bridge to bus 0001:00 [ 5.854997] imx6q-pcie 33800000.pcie: Phy link never came up [ 5.862205] imx6q-pcie 33800000.pcie: PCI host bridge to bus 0000:00 It means one of the following The PCIe peripheral is not powered up. PCIe reset is not deasserted, so the chip is in reset. This could be because the DTB is deasserting an incorrect GPIO. Reference clock is not enabled Using the incorrect PCIe controller in the device tree. As we can see that both the PCIe controllers can report this. So first determine which controller is the peripheral hooked to. More on this in the next section. Which PCIe controller is my device on? ( &pcie0 vs &pcie1 ) The rule here is to match by address and not by label/name. If the schematic calls out controllers as PCIE1 and PCIE2, and the device tree lists pcie0 and pcie1, understand the mapping. The DTS label is arbitrary - match by register base ( @address in the node name), which is the same in the DTS reg and the reference memory map. For definitive addresses look in the .dtsi , as sometimes the manuals are misleading. Given below is a mapping table for i.MX8MQ DTS. | ADDRESS (in .dtsi) | Silicon (RM) Label &pcie0 | 0x33800000 | PCIe1 &pcie1 | 0x33c00000 | PCIe2 The addresses are listed in the chip’s memory layout are from processor reference manual. Below is snapshot from the i.MX8MQ reference manual, where the layout for the core A-53 is listed. Start Address | End Address | Size | Description 3381_0000 | 3381_3FFF | 4MB | PCIe-2 << inco

I got tired of SSHing into the box every time I shipped something, just to watch the logs come up. So I wanted a page in the admin panel where the lines scroll past as they happen, no dashboard, no Grafana, just the raw tail. The surprising part was how little I had to build for it, most of the pieces were already sitting on the server waiting for me to connect them. Here's the whole idea. The app writes JSON to stdout, systemd grabs that stdout and drops every line into the journal, and journalctl can follow the journal and hand the lines back live. All three of those already exist on an Ubuntu box. So the "live log viewer" is really just me spawning journalctl on the server and piping its output to the browser over an EventSource , which is a lot less code than it sounds like. journald is boring and well understood. SSE is boring and well understood (it's been in browsers since about 2011). Nobody gets excited about either one on its own. But snap the two together and you get a real-time log tail with no agent, no log shipper, no vendor, and nothing new to keep alive. Two defaults meeting each other and pretending to be a feature. Systemd thing People have opinions about systemd. Some of them are that you should avoid every part of it that you can, run your own supervisor, ship logs somewhere with your own daemon, and treat journald as a thing to route around. That's a fine hobby if you have the time for it. I don't. The box boots, systemd starts my unit, and when the unit writes to stdout the line ends up in the journal without me configuring anything. Being a purist here costs real hours and buys me a philosophy. Being pragmatic costs nothing and buys me a log tail. So this is the pragmatic path. If you're on a distro where journald is the default (Ubuntu, Debian, Fedora, most of them now) the setup below is basically free. Getting logs into the journal Here is the part most people overcomplicate. You do not "set up journald". You do not open a socket to it or p

Hello, I'm Maneshwar. I'm building git-lrc, a Micro AI code reviewer that runs on every commit. It is free and source-available on Github. Star git-lrc to help devs discover the project. Do give it a try and share your feedback. You've been using the terminal for months/ years. Maybe you cd into a folder, ls around, run your script, and call it a day. That's fine. That's like knowing how to boil water and calling yourself a chef. But the terminal has layers . It's basically an onion that occasionally makes you cry, usually around 12 AM when a script fails silently and you have no idea why. So grab your coffee and let's talk about the command line tricks that actually make your life better. Not the "did you know ls -la shows hidden files" tier tips. Your Terminal Has A Memory. Use It. Most devs mash the up arrow like it's 2007 and they're trying to beat a Flash game. Stop that. Press ctrl-r instead. It searches your command history live. Type a few letters, it finds the last matching command. Press ctrl-r again to cycle back further. Found it? Hit Enter to run it, or the right arrow to drop it into your prompt so you can edit it first. ctrl-r ( reverse-i-search ) ` docker run ` : docker run -it --rm -v $( pwd ) :/app node:20 bash Pair this with ctrl-w (delete last word) and ctrl-u (nuke the line back to the cursor) and you'll start editing commands like you're speedrunning a text adventure. And if you're the type who types a whole essay of a command and then realizes you forgot something at the start, ctrl-a jumps to the beginning of the line and ctrl-e jumps to the end. No more holding the left arrow key like it owes you money. Pro tip: if you're a TUI fan and ctrl-r's default search feels a bit flat, check out McFly xargs Is The Friend Who Actually Shows Up Pipes ( | ) are great. They pass output from one command into another. But sometimes you don't want to pass output as input , you want to pass it as arguments . That's where xargs comes in, and once you get it,

The Linux Foundation has launched Akrites, a new industry-wide initiative aimed at defending the world's most critical open source software against a rapidly evolving generation of AI-enabled cyber threats. By Craig Risi

Sparrow is Raku automation framework comes with useful plugins people can use to automate infrastructure. Scc plugin allows to check Linux essential configuration files for security compliance. Here some examples: Sysctl $ sudo sysctl -a | s6 --plg-run scc@check = sysctl 12:24:07 :: [task] - run plg scc@check=sysctl 12:24:07 :: [task] - run [scc], thing: scc@check=sysctl [task run: task.bash - scc] [task stdout] 12:24:08 :: abi.cp15_barrier = 1 12:24:08 :: abi.setend = 1 12:24:08 :: abi.swp = 0 12:24:08 :: abi.tagged_addr_disabled = 0 12:24:08 :: debug.exception-trace = 0 12:24:08 :: dev.cdrom.autoclose = 1 12:24:08 :: dev.cdrom.autoeject = 0 12:24:08 :: dev.cdrom.check_media = 0 12:24:08 :: dev.cdrom.debug = 0 12:24:08 :: dev.cdrom.info = CD-ROM information, Id: cdrom.c 3.20 2003/12/17 12:24:08 :: dev.cdrom.info = 12:24:08 :: dev.cdrom.info = drive name: 12:24:08 :: dev.cdrom.info = drive speed: 12:24:08 :: dev.cdrom.info = drive # of slots: 12:24:08 :: dev.cdrom.info = Can close tray: 12:24:08 :: dev.cdrom.info = Can open tray: 12:24:08 :: dev.cdrom.info = Can lock tray: 12:24:08 :: dev.cdrom.info = Can change speed: 12:24:08 :: dev.cdrom.info = Can select disk: 12:24:08 :: dev.cdrom.info = Can read multisession: 12:24:08 :: dev.cdrom.info = Can read MCN: 12:24:08 :: dev.cdrom.info = Reports media changed: 12:24:08 :: dev.cdrom.info = Can play audio: 12:24:08 :: dev.cdrom.info = Can write CD-R: 12:24:08 :: dev.cdrom.info = Can write CD-RW: 12:24:08 :: dev.cdrom.info = Can read DVD: 12:24:08 :: dev.cdrom.info = Can write DVD-R: 12:24:08 :: dev.cdrom.info = Can write DVD-RAM: 12:24:08 :: dev.cdrom.info = Can read MRW: 12:24:08 :: dev.cdrom.info = Can write MRW: 12:24:08 :: dev.cdrom.info = Can write RAM: 12:24:08 :: dev.cdrom.info = 12:24:08 :: dev.cdrom.info = 12:24:08 :: dev.cdrom.lock = 0 12:24:08 :: dev.raid.speed_limit_max = 200000 12:24:08 :: dev.raid.speed_limit_min = 1000 12:24:08 :: dev.scsi.logging_level = 68 12:24:08 :: dev.tty.ldisc_autoload = 1 12:24:08

Both vulnerabilities allow untrusted users to gain root privileges.

Lost an evening to this, so you don't have to. The fix everyone hands you is a single checkbox that quietly downgrades how your Mac stores its password. The clean alternative — Kerberos, the exact thing your iPhone already uses — is "impossible" according to three sources I dug up, one of them Apple's own Heimdal source. They're wrong. What follows is the whole path: why it breaks, why the popular fix is the bad one, and the two setups that actually work (a one-shot command and a hands-off automount). My Mac mini shares a folder over SMB. My iPhone mounts it fine. My Linux box: $ smbclient -L 192.168.0.153 -U tmlr%remote session setup failed: NT_STATUS_LOGON_FAILURE Same username, same password, rejected. Every "fix" on the internet ends with "turn on Windows File Sharing for that user on the Mac." That works, and it's the wrong answer. Here's why, and what to do instead. The problem The credentials are correct — the iPhone's connecting just fine. The handshake even completes; run it with -d3 and you'll see the full NTLMSSP exchange finish before the Mac rejects you. So this isn't networking, isn't the password, isn't the SMB dialect. It's authentication, and only Linux hits it. Why: two doors, one account macOS keeps several credentials for a local account, not one. Look: $ dscl . -read /Users/tmlr AuthenticationAuthority AuthenticationAuthority: ; ShadowHash ; HASHLIST:<SALTED-SHA512-PBKDF2,SRP-RFC5054-4096-SHA512-PBKDF2> ; Kerberosv5 ;; tmlr@LKDC:SHA1.XXXX ; LKDC:SHA1.XXXX ; Two things matter in there: HASHLIST is SALTED-SHA512-PBKDF2 (login) and an SRP verifier. There is no NT hash. There's a Kerberosv5 identity in a realm called LKDC:SHA1.<40 hex> . SMB auth has two doors into this account: NTLMv2 — validates against a stored NT hash. Linux smbclient and mount.cifs knock here. Kerberos — validates against the Mac's built-in Local KDC (LKDC), which every Mac runs. Apple clients knock here. Your iPhone walks through the Kerberos door and never touches the NT hash

I wanted to understand how malloc actually works under the hood. Most explanations I found online described what an allocator does, but completely skipped over the "why" behind its design decisions. Rather than stopping at theory, I decided to build a cross-platform allocator in C that implements malloc , calloc , realloc , and free from scratch. This article documents the design of that allocator, the architectural tradeoffs I faced, and the core concepts I had to learn along the way. Table Of Contents Design Decisions Architecture Modern Allocator Strategies Core Concepts What's Next Project Overview A custom memory allocator does not create physical memory. Instead, it requests pages of raw virtual memory from the operating system and manages how that memory is partitioned, reused, resized, and released by the application. The goal of this educational project is to implement C's core memory management API using a modular, cross-platform architecture inspired by design principles found in modern allocators, rather than relying on legacy, single-platform tricks. Design Decisions #1: Why I am Skipping sbrk While many classic tutorials use sbrk for educational implementations, I deliberately chose a 100% mmap -based approach for two major reasons: sbrk is a fragile global bottleneck. It works by moving a single pointer (the program break) up and down. This means the allocator assumes it owns a contiguous line of memory. If a third-party library or another thread in the program secretly calls sbrk behind the scenes, the allocator's memory layout can break instantly. mmap , by contrast, provides isolated, independent chunks of memory. Cross-Platform Symmetry. Windows has absolutely no equivalent to sbrk , but it has a direct equivalent to mmap : VirtualAlloc . If we used sbrk , our architectural abstraction ( os_alloc ) would become awkward because Linux would deal with a moving pointer while Windows dealt with independent pages. Using mmap keeps the abstraction perfec

If you've been monitoring Linux servers for any length of time, there's a good chance node_exporter was the first thing you installed. It's lightweight, reliable, and exposes a huge amount of machine metrics for Prometheus to scrape. For years, it has been the default answer. As your infrastructure grows, though, your monitoring stack usually grows with it. First comes log collection. Then traces. Before long you're running node_exporter , a log shipper, and maybe another telemetry agent. Each component has its own configuration, service unit, upgrade cycle, and failure modes. Grafana Alloy changes that by consolidating those responsibilities into a single telemetry agent. This post walks through migrating from node_exporter to Alloy on a real fleet, one server at a time, while maintaining continuous visibility throughout the process. These are the exact steps that survived contact with production on the Irin monitoring stack, not the idealized version that looks clean in a diagram. TL;DR If you're already running node_exporter , don't replace it overnight. Install Grafana Alloy alongside it, configure Alloy's built-in prometheus.exporter.unix component, verify that metrics are reaching your remote Prometheus instance, and only then retire node_exporter. Migrating one server at a time minimizes risk, preserves visibility, and positions your infrastructure for logs, traces, and future telemetry without deploying additional agents. The real difference is the direction of travel Before getting started, it's worth understanding what actually changes. This isn't simply replacing one monitoring agent with another. node_exporter is a server. It listens on a port, typically 9100,and waits for Prometheus to connect and scrape metrics. That means every monitored machine needs an open endpoint, network connectivity from Prometheus, firewall rules, and scrape configurations. Alloy flips that model around. Instead of waiting for Prometheus to connect, Alloy collects metrics loca

Installing Docker on Ubuntu should be simple, but in practice several Docker-shaped options compete for the same command name, each with different packaging, upgrade behavior, and security implications. This guide compares every major install path so you can pick the one that fits your machine. The options you will encounter include: docker.io from Ubuntu repositories docker-ce from Docker's official APT repository Docker from Snap Docker Desktop manually downloaded .deb packages the Docker convenience script rootless Docker Although they all provide container tooling, they are not interchangeable packages. The best choice depends on whether the machine is a developer workstation, a CI runner, a small server, a self-hosting box, or a production host. My default recommendation is calm but firm: for most technical users on normal Ubuntu machines, install Docker Engine from Docker's official APT repository. Use Ubuntu's docker.io only when distribution integration matters more than upstream Docker packaging. Avoid the Snap package unless you specifically want Snap behavior and understand its limits. Rootless Docker is worth knowing about, but it is not automatically the best default for every machine. This guide explains the tradeoffs, covers post-install security, and gives you clean installation paths for each method. Once Docker Engine is running, the Docker Cheatsheet is your daily command reference, and the Docker Compose Cheatsheet covers multi-container setups. Both sit alongside Git, VS Code, and CI/CD guides in Developer Tools: The Complete Guide to Modern Development Workflows . Quick Recommendation The table below summarizes which install path fits common scenarios. Use case Recommended install Developer workstation Docker official APT repo CI runner Docker official APT repo, version pinned if needed Small self-hosted server Docker official APT repo Production server Docker official APT repo, controlled upgrades Ubuntu-only conservative system Ubuntu docker.

Redpanda is a Kafka-API-compatible streaming platform written in C++ with no JVM and no ZooKeeper. This guide installs Redpanda on Ubuntu 24.04, secures it with a Let's Encrypt certificate and SASL/SCRAM authentication, tunes the kernel for production, verifies with a producer/consumer test, and exposes Redpanda Console behind Nginx basic auth. By the end, you'll have a secured, production-tuned single-node Redpanda cluster with a web console. Prerequisite: Ubuntu 24.04 server sized per Redpanda's CPU/memory requirements , non-root sudo user, and a domain A record (e.g. redpanda.example.com ). Install Redpanda $ sudo apt update $ curl -1sLf 'https://dl.redpanda.com/nzc4ZYQK3WRGd9sy/redpanda/cfg/setup/bash.deb.sh' | sudo -E bash Warning: Only run vendor setup scripts you trust — piped curl | sudo bash runs with root privileges. $ sudo apt install redpanda -y $ rpk --version Open the Firewall Port Service Purpose 9092 Kafka API Producer/consumer traffic 8082 Pandaproxy (HTTP) REST access for non-Kafka clients 8081 Schema Registry Avro/Protobuf schema versioning 9644 Admin API Monitoring, config, health checks 33145 Internal RPC Inter-node communication $ sudo ufw allow 9092,8082,8081,9644,33145/tcp $ sudo ufw allow 80/tcp $ sudo ufw allow 443/tcp $ sudo ufw reload Issue a Let's Encrypt Certificate Redpanda ships with plaintext networking by default, fine for a lab, not for anything else. $ sudo apt install certbot -y $ DOMAIN = redpanda.example.com $ EMAIL = admin@example.com $ sudo certbot certonly --standalone -d $DOMAIN --non-interactive --email $EMAIL Certbot stores certs under /etc/letsencrypt/live , readable only by root. Redpanda runs as its own redpanda user, so copy the certs into a dedicated directory: $ sudo mkdir /etc/redpanda/certs $ sudo cp /etc/letsencrypt/live/ $DOMAIN /fullchain.pem /etc/redpanda/certs/node.crt $ sudo cp /etc/letsencrypt/live/ $DOMAIN /privkey.pem /etc/redpanda/certs/node.key $ sudo cp /etc/letsencrypt/live/ $DOMAIN /chain.pem /etc/re