标签：#ux

Gradio is a Python library for wrapping any ML model in a web interface, ready to deploy and scale as an app. This guide builds a GFPGAN-powered face-restoration demo with Gradio on Ubuntu 22.04, runs it as a systemd service, and exposes it through Nginx with TLS. Prerequisites: a GPU-enabled Ubuntu 22.04 server, a domain A record (e.g. gradio.example.com ), non-root sudo access, Nginx installed. Set Up the Server 1. Install dependencies: $ pip3 install realesrgan gfpgan basicsr gradio realesrgan — background restoration gfpgan — face restoration basicsr — provides RRDBNet , the super-resolution architecture GFPGAN relies on gradio — the web interface 2. GFPGAN's pandas dependency needs jinja2 >= 3.1.2: $ pip show jinja2 Upgrade if it's older: $ pip install --upgrade jinja2 3. Create the project directory: $ sudo mkdir -p /opt/gradio-webapp/ $ sudo chown -R : $( id -gn ) /opt/gradio-webapp/ $ sudo chmod -R 775 /opt/gradio-webapp/ Build the Gradio App Uploads a face image and returns two enhanced outputs. $ cd /opt/gradio-webapp/ $ nano app.py import gradio as gr from gfpgan import GFPGANer from basicsr.archs.rrdbnet_arch import RRDBNet from realesrgan import RealESRGANer import numpy as np import cv2 import requests def enhance_image ( input_image ): arch = ' clean ' model_name = ' GFPGANv1.4 ' gfpgan_checkpoint = ' https://github.com/TencentARC/GFPGAN/releases/download/v1.3.4/GFPGANv1.4.pth ' realersgan_checkpoint = ' https://github.com/xinntao/Real-ESRGAN/releases/download/v0.2.1/RealESRGAN_x2plus.pth ' rrdbnet = RRDBNet ( num_in_ch = 3 , num_out_ch = 3 , num_feat = 64 , num_block = 23 , num_grow_ch = 32 , scale = 2 ) bg_upsampler = RealESRGANer ( scale = 2 , model_path = realersgan_checkpoint , model = rrdbnet , tile = 400 , tile_pad = 10 , pre_pad = 0 , half = True ) restorer = GFPGANer ( model_path = gfpgan_checkpoint , upscale = 2 , arch = arch , channel_multiplier = 2 , bg_upsampler = bg_upsampler ) input_image = input_image . astype ( np . uint8 ) cropped_fa

Nginx UI is an open-source web GUI for managing Nginx, single-node or clustered, with real-time stats, automatic Let's Encrypt TLS, performance monitoring, and even LLM-assisted config editing. This guide installs it on Ubuntu 24.04, puts it behind a reverse proxy with TLS, sets up ACME certificate management, and creates a virtual host through the dashboard. Prerequisites: an Ubuntu 24.04 server, non-root sudo user, a domain A record (e.g. nginx-ui.example.com ), Docker installed if you choose that install path. $ sudo apt update $ sudo apt install nginx -y Pick one of the two install methods below. Option A: Install via Script Runs Nginx UI as a system service, managing the host's Nginx directly. $ curl -O https://cloud.nginxui.com/install.sh $ sudo bash install.sh install $ nginx-ui --version $ sudo systemctl start nginx-ui $ sudo systemctl status nginx-ui Option B: Install via Docker Runs as a container — you won't be able to edit the host's Nginx configs directly through it. $ mkdir -p ~/nginx-ui-docker $ cd ~/nginx-ui-docker $ sudo mkdir -p /opt/nginx-ui/nginx $ sudo mkdir -p /opt/nginx-ui/config $ sudo mkdir -p /opt/nginx-ui/www $ nano docker-compose.yml version : ' 3.8' services : nginx-ui : image : uozi/nginx-ui:latest container_name : nginx-ui restart : always environment : - TZ=UTC volumes : - /opt/nginx-ui/nginx:/etc/nginx - /opt/nginx-ui/config:/etc/nginx-ui - /opt/nginx-ui/www:/var/www ports : - " 127.0.0.1:9000:80" networks : - nginx-ui-net networks : nginx-ui-net : driver : bridge $ sudo docker compose up -d $ sudo docker compose ps $ curl -X GET http://localhost:9000 Configure the Reverse Proxy Nginx UI listens on localhost:9000 . Put it behind a public vhost with WebSocket support (needed for live stats/terminal): $ cd /etc/nginx/sites-available $ sudo nano nginx-ui.conf map $http_upgrade $connection_upgrade { default upgrade ; '' close ; } server { listen 80 ; listen [::]:80 ; server_name nginx-ui.example.com ; location / { proxy_set_header Host $

Ghost is an open-source publishing platform with built-in newsletters, memberships, subscriptions, ActivityPub federation, and Tinybird-powered web analytics. This guide covers two install paths on Ubuntu 24.04: Ghost-CLI for a traditional host install, and Docker Compose for a containerized deployment with analytics. Prerequisites: an Ubuntu 24.04 server, non-root sudo user, a domain A record (e.g. ghost.example.com ). Option A: Install with Ghost-CLI Install Node.js Ghost requires Node v22 LTS — check compatible versions before installing elsewhere. $ curl -fsSL https://deb.nodesource.com/setup_22.x -o nodesource_setup.sh $ sudo -E bash nodesource_setup.sh $ sudo apt install -y nodejs $ node -v Install and Configure MySQL $ sudo apt install -y mysql-server $ mysql --version $ sudo mysql_secure_installation Walk through the prompts: enable password validation ( y ), pick strong policy ( 2 ), remove anonymous users ( y ), restrict root to localhost ( y ), drop the test database ( y ), reload privileges ( y ). $ sudo mysql mysql > CREATE DATABASE ghost_db ; mysql > CREATE USER 'ghostuser' @ 'localhost' IDENTIFIED BY 'Your_password2!' ; mysql > GRANT ALL PRIVILEGES ON ghost_db . * TO 'ghostuser' @ 'localhost' ; mysql > FLUSH PRIVILEGES ; mysql > EXIT ; Install Nginx $ sudo apt install -y nginx $ sudo ufw allow 'Nginx Full' $ sudo systemctl status nginx Install Ghost $ sudo npm install ghost-cli@latest -g $ sudo mkdir -p /var/www/html/ghost $ sudo chown $USER : $USER /var/www/html/ghost $ sudo chmod 775 /var/www/html/ghost $ cd /var/www/html/ghost $ ghost install The installer prompts for: Blog URL : https://ghost.example.com MySQL hostname : localhost MySQL username/password/database : from the setup above Set up Nginx? : y Set up SSL? : y (installs acme.sh ) Email for SSL : your address Set up Systemd? : y Start Ghost? : y Manage the Config $ nano /var/www/html/ghost/config.production.json $ cd /var/www/html/ghost $ ghost restart Or via systemd (replace ghost-example

phpBB is an open-source forum application for building discussion communities — user registration, moderation, permissions, and multiple boards in one interface. This guide deploys phpBB on Ubuntu 22.04 with an external MySQL database, an Apache virtual host, and Let's Encrypt TLS. Prerequisites: an Ubuntu 22.04 server with the LAMP stack installed, non-root sudo user, an external MySQL database, a subdomain A record (e.g. phpbb.example.com ). Create the Database $ mysql -h your-db-host -P 3306 -u dbadmin -p mysql > CREATE DATABASE phpbbdb ; mysql > USE phpbbdb ; mysql > CREATE USER 'phpbbuser' @ 'localhost' IDENTIFIED BY 'securepassword' ; mysql > GRANT ALL ON phpbbdb . * to 'phpbbuser' @ 'localhost' ; mysql > FLUSH PRIVILEGES ; mysql > EXIT ; Install phpBB 1. Install PHP modules: $ sudo apt install php-mysql php-xml php-mbstring -y 2. Download and extract — check the releases page for the current version: $ wget -O phpbb.zip https://download.phpbb.com/pub/release/3.3/3.3.11/phpBB-3.3.11.zip $ unzip phpbb.zip $ sudo mv phpBB3 /var/www/html/phpbb 3. Set ownership and permissions: $ sudo chown -R www-data:www-data /var/www/html/phpbb $ sudo find /var/www/html/phpbb -type d -exec chmod 755 {} \; $ sudo find /var/www/html/phpbb -type f -exec chmod 644 {} \; Configure Apache $ sudo nano /etc/apache2/sites-available/phpbb.conf < VirtualHost *:80 > ServerAdmin admin@example.com DocumentRoot /var/www/html/phpbb ServerName phpbb.example.com < Directory /var/www/html/phpbb > Options FollowSymlinks AllowOverride All Require all granted </ Directory > ErrorLog ${APACHE_LOG_DIR}/phpbb_error.log CustomLog ${APACHE_LOG_DIR}/phpbb_access.log combined </ VirtualHost > $ sudo a2ensite phpbb $ sudo a2enmod rewrite $ sudo systemctl restart apache2 Secure phpBB 1. Firewall: $ sudo ufw status $ sudo ufw allow 22 && sudo ufw enable $ sudo ufw allow 80/tcp $ sudo ufw allow 443/tcp $ sudo ufw reload 2. TLS via Let's Encrypt: $ sudo apt install snapd -y $ sudo snap install --classic certbot

A Patroni cluster needs an odd number of nodes to maintain quorum — with 3 nodes, losing 1 still leaves a majority, so the cluster keeps running. This guide builds a 3-node PostgreSQL cluster on Ubuntu 24.04 with Patroni handling replication and automatic failover, etcd as the coordination store, and HAProxy load-balancing client connections — all secured with TLS. Prerequisites: three Ubuntu 24.04 servers (2 vCPU / 4GB RAM minimum) with PostgreSQL installed, non-root sudo access, and a domain with three A records: node1.example.com , node2.example.com , node3.example.com . Replace these placeholders with your actual subdomains throughout. Install Dependencies Run on all three nodes unless noted otherwise. 1. Install packages: $ sudo apt update $ sudo apt install haproxy certbot pipx -y $ sudo pip3 install --break-system-packages 'patroni[etcd3]' psycopg2-binary psycopg 2. Install etcd: $ wget https://github.com/etcd-io/etcd/releases/download/v3.6.4/etcd-v3.6.4-linux-amd64.tar.gz $ tar -xvf etcd-v3.6.4-linux-amd64.tar.gz $ sudo mv etcd-v3.6.4-linux-amd64/etcd etcd-v3.6.4-linux-amd64/etcdctl /usr/local/bin/ 3. Open firewall ports — 80 (Certbot), 2379/2380 (etcd), 5432/5433 (PostgreSQL + Patroni-managed PostgreSQL), 8008/8009 (Patroni REST API): $ sudo ufw allow 80,2379,2380,5432,5433,8008,8009/tcp $ sudo ufw reload $ sudo ufw status Configure SSL Certificates 1. Request a certificate per node (run on each node for its own subdomain): $ sudo certbot certonly --standalone -d node1.example.com -m admin@example.com --agree-tos --no-eff 2. Create a cert-prep script on each node (set HOSTNAME to that node's subdomain): $ sudo nano /usr/local/bin/prepare-ssl-certs.sh #!/bin/bash HOSTNAME = "node1.example.com" # Update for each node CERT_DIR = "/etc/letsencrypt/live/ $HOSTNAME " ARCHIVE_DIR = "/etc/letsencrypt/archive/ $HOSTNAME " getent group ssl-users > /dev/null || sudo groupadd ssl-users for user in etcd patroni haproxy postgres ; do if ! id " $user " > /dev/null 2>&1 &&

Laravel is a popular PHP framework with routing, authentication, and database management built in. This guide deploys a Laravel app behind Nginx on Ubuntu 24.04, wires it to MySQL, secures it with Let's Encrypt, and builds a small dashboard that queries live data. Prerequisites: Ubuntu 24.04 with Nginx and MySQL installed, a non-root sudo user, a domain A record (e.g. app.example.com ). Create the Database $ sudo mysql mysql > CREATE DATABASE laravel_demo ; mysql > CREATE USER 'laravel_user' @ 'localhost' IDENTIFIED WITH mysql_native_password BY 'secure_password' ; mysql > GRANT ALL ON laravel_demo . * TO 'laravel_user' @ 'localhost' ; mysql > FLUSH PRIVILEGES ; mysql > EXIT ; Seed a demo table to query later: $ mysql -u laravel_user -p mysql > USE laravel_demo ; mysql > CREATE TABLE server_stats ( id INT AUTO_INCREMENT , server_name VARCHAR ( 255 ), region VARCHAR ( 255 ), cpu_usage DECIMAL ( 5 , 2 ), memory_usage DECIMAL ( 5 , 2 ), status ENUM ( 'active' , 'maintenance' , 'offline' ), last_updated TIMESTAMP DEFAULT CURRENT_TIMESTAMP , PRIMARY KEY ( id ) ); mysql > INSERT INTO server_stats ( server_name , region , cpu_usage , memory_usage , status ) VALUES ( 'app-01' , 'us-east' , 24 . 50 , 45 . 30 , 'active' ), ( 'db-01' , 'eu-west' , 12 . 75 , 78 . 20 , 'active' ), ( 'web-01' , 'ap-south' , 65 . 80 , 89 . 50 , 'active' ); mysql > EXIT ; Install Composer and PHP Extensions $ sudo apt update $ sudo apt install composer php php-curl php-fpm php-bcmath php-json php-mysql php-mbstring php-xml php-tokenizer php-zip -y $ composer --version $ php --version $ sudo systemctl restart php8.3-fpm php-fpm runs PHP as a service Nginx can talk to; php-mysql / php-mbstring / php-xml / php-tokenizer / php-zip cover Laravel's runtime requirements. Create the Laravel Project $ cd ~ $ composer create-project --prefer-dist laravel/laravel laravel-demo $ cd laravel-demo $ php artisan key:generate Edit .env : $ nano .env APP_NAME = laravel-demo APP_ENV = development APP_KEY = base64:APP

JDK 24 removed the monitor-related carrier-thread pinning that stalled Netflix and similar teams on Java 21. What has replaced it on JDK 25 LTS is downstream-resource saturation: The bottleneck moved and now demands explicit bounding in application code. This article maps the failure modes that surface after virtual-thread adoption and gives a practical sequence backed by a public benchmark. By Sandeep Bharadwaj

The biggest reason NVIDIA began providing GPL-licensed kernel modules is that its driver architecture evolved to the point where Linux integration, distribution, and maintenance could be greatly simplified while keeping the GPU's critical intellectual property in firmware and user-space components . To be precise, NVIDIA did not open-source its entire driver stack. The components that became open are primarily the following Linux kernel modules: nvidia.ko nvidia-drm.ko nvidia-uvm.ko nvidia-modeset.ko User-space components such as CUDA, OpenGL, Vulkan, and the GSP firmware remain proprietary. ( NVIDIA Developer ) 1. To make integration with Linux distributions easier Previously, NVIDIA's proprietary kernel modules had to be built, signed, and distributed separately from the Linux kernel. A DKMS-based workflow, which rebuilds modules after every kernel update, commonly led to problems such as: Kernel modules failing to build after kernel updates Unsigned modules being blocked by Secure Boot Linux distributions having difficulty maintaining the driver as an official package Increased complexity when integrating with custom kernels or cloud environments By publishing the source code, distributions such as Ubuntu, Red Hat, and SUSE can integrate NVIDIA's kernel modules into their own packaging, signing, and update infrastructure much more easily. NVIDIA itself cites tighter OS integration and simpler signing and distribution as key motivations. ( NVIDIA Developer ) 2. To improve debugging and security review Kernel modules interact with deep parts of the operating system, including memory management, interrupts, inter-process synchronization, PCI Express, and display subsystems. With the source code available, Linux distribution developers and enterprise users can: Trace where execution stops inside the kernel Analyze interactions between GPU events and workloads Fix incompatibilities with custom kernels Review security-related issues Submit patches to NVIDIA NVIDIA stat

Working with files in Linux isn't just about creating and editing them. Sometimes you need to: Archive multiple files into one Compress files to save disk space Share files with others Create backups Linux provides several tools for this, each with a different purpose. Let's simplify them. What is File Compression? File compression reduces the size of a file. Benefits: Saves disk space Faster file transfers Easier backups Reduces bandwidth usage Example: A 100 MB log file might become a much smaller compressed file, depending on its contents. Archive vs Compression Many beginners think they're the same. They are not. Archive Combines multiple files into a single file. Example: photos/ docs/ notes.txt ↓ backup.tar Compression Reduces the size of a file. Example: backup.tar ↓ backup.tar.gz 👉 tar archives files. gzip compresses them. 1. Create an Archive with tar tar -cvf backup.tar Documents/ #Create an archive tar -tvf backup.tar #View archive contents tar -xvf backup.tar #Extract an archive Options: c → Create v → Verbose (show progress) f → File name x → Extract Best for: Backups Bundling multiple files Moving folders 2. Compress with gzip Compress a file: gzip file.txt # Creates file.txt.gz # Result file.txt.gz gunzip file.txt.gz # decompress gzip -k file.txt # Keep original file Best for: Log files Large text files Saving disk space 3. Archive and Compress Together Most common command: # Create compressed archive tar -czvf backup.tar.gz Documents/ # Extract tar -xzvf backup.tar.gz Options: z → Use gzip compression 👉 This is one of the most common backup commands in Linux. 4. Working with ZIP Files # Create ZIP zip -r project.zip project/ # Extract unzip project.zip # List contents unzip -l project.zip Best for: Sharing files with Windows users Cross-platform compatibility 5. Compare the Tools Tool Purpose Best For tar Archive files Backups gzip Compress files Saving space tar + gzip Archive and compress Linux backups zip Archive and compress Sharing files across

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

Improved efficiency in EPP mode leads to ~32% jump in "1% low" frame rates.

Il y a quelques jours, j'ai réalisé un truc qui m'a un peu stressée : ma réunion de la semaine 4 avec ma mentor Endah Bongo approchait, et le programme prévoyait Linux et Git. Sauf que... je ne maîtrisais pas encore les différentes commandes utilisées. Plutôt que de paniquer, j'ai décidé de prendre les choses en main et de tout pratiquer en direct, une commande à la fois, jusqu'à ce que ça fasse sens. Voici ce que j'ai appris, dans l'ordre où je l'ai découvert. Se repérer dans un terminal Linux La toute première chose à comprendre avec Linux, c'est qu'on est toujours "quelque part" dans une arborescence de dossiers. Trois commandes suffisent pour s'orienter : pwd ( print working directory ) affiche l'endroit exact où on se trouve ls liste le contenu du dossier courant cd permet de se déplacer d'un dossier à l'autre Avec cd ~ , on revient direct dans son dossier personnel. Une astuce toute simple, mais qui change la vie quand on découvre le terminal. Créer et organiser des fichiers Une fois qu'on sait se déplacer, l'étape suivante c'est de manipuler des fichiers et dossiers : mkdir crée un nouveau dossier touch crée un fichier vide ls -la permet de tout voir en détail, y compris les fichiers cachés et les permissions C'est là que j'ai découvert les permissions Linux (ce fameux -rw-r--r-- qu'on voit à côté de chaque fichier), qui déterminent qui peut lire, écrire ou exécuter un fichier. Entrer dans le monde de Git Une fois les bases Linux en poche, place à Git. Première étape : configurer son identité, une seule fois pour toutes les utilisations futures. git config --global user.name "Ton nom" git config --global user.email "ton_email@exemple.com" Ensuite, j'ai transformé mon dossier de test en dépôt Git avec git init , puis j'ai découvert le cycle de base que tout développeur utilise au quotidien : Modifier un fichier git add pour l'ajouter à la zone de préparation (staging) git commit -m "message" pour valider les changements Entre les deux, git status est devenu mo

ViciDial "Campaign Has No Dialable Leads" — List & Hopper Troubleshooting Master the root causes of no dialable leads errors and regain full campaign productivity through systematic list validation, hopper configuration, and database troubleshooting. Prerequisites Before troubleshooting, ensure you have: SSH access to your ViciDial server with sudo privileges Access to the ViciDial web admin panel at /vicidial/admin.php MySQL/MariaDB command-line access to the asterisk database Understanding of basic ViciDial campaign structure (lists, dialers, agents) Root or asterisk-user permissions to check Asterisk processes Recent backups of your ViciDial database and configuration files A test campaign with known lead counts for validation The "Campaign Has No Dialable Leads" error typically appears when: The dialer attempts to initiate calls but the hopper queue is empty All records in the lead list have been exhausted or marked as non-dialable List settings conflict with campaign configuration The database connection between ViciDial and the dialer is broken Lead filtering rules remove all records from the dialable pool Understanding ViciDial List Architecture The Lead Lifecycle in ViciDial Every lead in ViciDial passes through status states that determine dialability. A lead is considered "dialable" if it matches specific criteria based on campaign and list configuration. Lead Status States: NEW — Fresh lead, never contacted QUEUE — Scheduled for dialing CALL — Currently being dialed LEFT MESSAGE — Voicemail was left CALLED — Contacted but not completed XFER — Transferred to another department XFER SEND — Pending transfer INCALL — Active call in progress CBHOLD — Callback hold status CBSCHED — Callback scheduled DNCC — Do Not Call Compiled DNCL — Do Not Call List The status field in the vicidial_list table controls whether a lead can be dialed again. Most campaigns set a maximum dial count limit to prevent redialing exhausted leads infinitely. Hopper Mechanism The ViciDial

A Live Linux system such as SystemRescue generally has the following structure: ISO9660 ├── EFI/, boot/, syslinux/, grub/ ← Bootloader ├── vmlinuz ← Kernel ├── initramfs ← Initial RAM disk └── airootfs.sfs / filesystem.squashfs └── Actual root filesystem Because SquashFS is read-only, the basic process is as follows: Extract the ISO ↓ Extract the SquashFS ↓ Edit the rootfs or enter it with chroot ↓ Rebuild the SquashFS ↓ Replace the SquashFS inside the ISO ↓ Rebuild it as a bootable ISO ↓ Test with BIOS and UEFI However, with SystemRescue, it is safer not to rebuild airootfs.sfs directly from the outset, but to select a method in the following order of priority: YAML configuration in sysrescue.d Overlay using an SRM (SystemRescueModule) Direct reconstruction of airootfs.sfs Full build from the SystemRescue source The official SystemRescue documentation also recommends sysrescue-customize for modifying ISO images. An SRM is an additional layer in SquashFS format, and files at the same paths in the SRM take precedence over those in the base rootfs. ( SystemRescue ) 1. Preparing the Working Environment It is easiest to perform this work on Linux. On Debian/Ubuntu-based systems, install the following: sudo apt update sudo apt install squashfs-tools xorriso rsync file It is also useful to install QEMU for testing: sudo apt install qemu-system-x86 ovmf The official SystemRescue customization script also lists xorriso and squashfs-tools among its main dependencies. It can also be run under WSL. ( SystemRescue ) Create a working directory: mkdir -p ~/work/systemrescue cd ~/work/systemrescue cp /path/to/systemrescue.iso original.iso Ensure that you have at least several times the original ISO size in free space. When rebuilding from within SystemRescue itself, the official documentation notes that the Copy-on-Write area may require approximately three times the ISO size. ( SystemRescue ) Method A: Use the Official SystemRescue sysrescue-customize Tool For SystemRescue, this

May 2026 There's a touchscreen mounted in my kitchen — I call it the WallScreen. It runs recipes, the chore board, a calendar, the usual smart-home clutter. One day I decided it should also pull in free over-the-air television. No subscription, no streaming app, just the local broadcast towers that have been beaming HD into the air for free this whole time. I had a Raspberry Pi 5, a $30 USB tuner, and what I assumed would be a boring afternoon. It was not a boring afternoon. The tuner that didn't want to work The tuner I grabbed was a MyGica A681 — a tidy little USB TV stick. Plug it into Windows, install the bundled software, done. Plug it into a Raspberry Pi running a current Linux kernel and you get… nothing. The computer notices a device is there and otherwise shrugs. Here's why, in two sentences: Linux has no built-in driver for the chips inside this particular stick. The manufacturer's driver only works on regular PC processors — and even then, only as a sealed, prebuilt file with no source code. A Raspberry Pi uses a different kind of chip entirely, so that driver is a non-starter. That's the whole problem. The hardware is great. It's just that on a Pi, this tuner is a paperweight — and you can't buy or download your way out of it. The only way out was to write the driver myself. What writing the driver actually involved A USB TV tuner isn't one chip — it's a little team of them working together. One chip is the "translator" that lets the computer talk to the device over USB. Another tunes to a channel, like turning a radio dial. A third converts the broadcast signal into video data the computer can use. The good news: for the parts that handle tuning and decoding the signal, I was able to build on existing open-source work from the broader Linux TV community — code other people had already written and shared for the chips inside this stick. (It's all credited in the project.) The missing piece — the part nobody had written — was the translator layer : the co

Johannes Schickling explores how he moved beyond the traditional three-tier web stack to a local-first approach. He shares his experience transitioning from Prisma to developing Overtone—a music curation app leveraging client-side event sourcing and SQLite. The discussion highlights the trade-offs between event sourcing and CRDTs. By Johannes Schickling

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

If you run GitOps with Flux, a broken manifest usually gets caught the slow way: it merges, the reconciler chokes, and you find out from a failing Kustomization. Flux Schema, the plugin that shipped with Flux 2.9, moves that check left into CI. It validates every YAML document against JSON Schema and CEL rules using the same evaluation logic as the Kubernetes API server, so a bad field fails the pull request instead of the cluster. Install and run it Flux Schema is a CLI plugin, not part of the core binary. Install it through the plugin system: $ flux plugin install schema $ flux schema --help Pin a version in CI so a new release never changes your gate's behavior mid-sprint: $ flux plugin install schema@0.5.0 Point it at a directory of manifests and it validates each document: $ flux schema validate ./manifests It ships with built-in schemas for Kubernetes, OpenShift, Gateway API, and the Flux CRDs, so a fresh install already knows your HelmRelease and Kustomization kinds without any setup. Strict validation flags unknown fields, wrong types, and missing required properties as hard errors, which catches the typos kubectl apply --dry-run=client quietly ignores. What CEL adds over plain schema checks JSON Schema catches shape problems: a string where an int belongs, a misspelled key. CEL rules catch logic problems. Because Flux Schema runs the x-kubernetes-validations rules embedded in CRDs through the same CEL engine the API server uses, a manifest that violates a cross-field constraint (say, a replica count that must stay below a limit, or two mutually exclusive fields both set) fails in CI with the exact message the cluster would have returned. You are testing against the real admission logic, not a stale copy of it. Wire it into a config file Drop a .fluxschema.yml at your repo root to control what gets checked. The file uses the schema.plugin.fluxcd.io/v1beta1 API and a Config kind: apiVersion : schema.plugin.fluxcd.io/v1beta1 kind : Config skipKind : - Secret s

I woke up to two emails that immediately caught my attention. One was from my website monitoring service (I use UptimeRobot, no affiliation) reporting that a client's website was down. The other was from my VPS provider informing me that they had suspended my VPS due to abuse. I logged into the control panel and immediately noticed a massive CPU spike. The server had gone from its usual 15–20% CPU usage to a sustained 100% for nearly four hours before the provider shut it down under their fair usage policy. My first clue was xmlrpc.php . It was consuming a significant amount of resources, so I started researching it. I'm not primarily a WordPress/PHP developer, and I was surprised to learn that XML-RPC exposes functionality for remote management of WordPress. I disabled XML-RPC, brought the VPS back online, and thought the problem was solved. It wasn't. The next day I woke up to the exact same two emails. This time my VPS provider had already imposed CPU limits on the server. I noticed a few kernel-looking processes consuming CPU, assumed they were related to the throttling, and restarted the VPS. A few hours later, it was offline again. At that point I knew I was dealing with a compromise rather than a performance issue. I began investigating the WordPress installation and immediately found obvious signs of infection. There were numerous malicious PHP files ( index.php , cache.php , etc.) buried inside recursively nested directories such as: image / image / image / image / cache . php The deeper I looked, the worse it became. The attackers had created: A rogue WordPress administrator account An unauthorized SSH key A root-level user on the VPS An administrator account inside CyberPanel This wasn't just a compromised website anymore. It was a full VPS compromise. My working theory was that the attackers exploited a vulnerable WordPress component (likely allowing arbitrary PHP upload or remote code execution), established persistence, and pivoted into the operating s

Every five minutes or so, my entire Windows machine would drop off the network for a few seconds — not just WSL, the whole host. Browser tabs would stall, calls would drop, and it only happened while WSL2 was running. This is the story of finding that, plus the WSL memory-tuning landmines I hit right alongside it. The flapping The symptom was a host-wide network blip on a short, regular interval, correlated tightly with WSL2 being up. The cause: WSL2's default networking mode creates a virtual NAT switch on the Windows side, and on this machine that virtual switch was intermittently conflicting with the real network adapter — enough to cause the whole host to briefly renegotiate its connection. The fix was switching WSL2's networking mode entirely, via .wslconfig (on Windows, not inside the Linux filesystem): [wsl2] networkingMode = mirrored dnsTunneling = true autoProxy = true Mirrored networking makes the WSL2 interface share the host's actual network identity instead of sitting behind a separate virtual NAT switch. You can confirm it actually took effect (rather than just trusting the config file) by checking, from inside WSL after a full restart, that its network interface holds the same IP as the Windows host, that the default route points at the real LAN gateway rather than a private NAT range, and that loopback carries mirrored mode's marker address rather than a 172.x NAT address. If any of those don't match, the setting isn't actually active yet. Worth noting: this requires a reasonably recent WSL version and Windows build. If you're on an older one, mirrored mode may not be available at all. The memory landmines, found the hard way Separately — and this had actually caused full VM crashes, not just hangs, at one point — I'd been carrying a few .wslconfig settings that looked reasonable and were each, individually, a documented source of instability: An explicit kernelCommandLine override. Resizing swap past a few GB, which forces WSL to rebuild its virtual