标签：#ux

As I'm observing engineers, I notice that most of them share the same characteristic: unending loads of curiosity. You, software developers, are deeply interested in how things work underneath; you implement, break, troubleshoot, fix, and break again. You create apps that people use everyday and by doing so, you shape the digitalised world we live in today. Now let me share something personal: I am terrified of breaking things. I am often terrified to such an extent that I find it hard to breathe. I am suffering from something called Generalised Anxiety Disorder (GAD), which basically means I am allergic to uncertainty. While most people see trying something new as exciting, for me it's a source of stress. Every unknown step, every unfamiliar process, every situation where I don't know what comes next — it triggers something. My brain immediately goes to the worst-case scenarios. "I can't do this." "I'll do it wrong." "What if something breaks?" These thoughts don't just pop up and disappear — they pile on top of each other until they become paralyzing. But this story isn't about anxiety — it's about how good UX can change a moment from overwhelming to manageable. And how you, as a software developer, can make a real change for people who are struggling. The app that saved my day A few months ago I decided to change my mobile operator. The alternative offer had much better terms that sounded really appealing to me. No long-term contract, competitive prices, support for eSIM for travellers abroad – in short: very flexible. Head held high, I went to the new operator's office to ask them to transfer my number. But the agent quickly wiped the smile off my face. "Yes, this offer is flexible, but you need to do all the operational work yourself in the app. I can only offer you a regular long-term contract," he said. He gave me my new SIM card, and I, with a long face, went to the nearby cafe. The thought that I had to transfer my number myself felt daunting. "What if I do

1. update WSL environment sudo apt update && sudo apt upgrade -y 2. install dependencies If you don't use -hf option, you don't need to install libssl-dev in this step. sudo apt install build-essential cmake git libssl-dev -y If nvidia-smi shows a GPU/GPUs on your terminal, you will need to install the tooklit. This will take some time. sudo apt install nvidia-cuda-toolkit -y 3. clone the repo Build llama-cli and llama-server. This step also will take some time. If you don't plan to use -hf option, you don't need to use -DLLAMA_OPENSSL=ON . git clone https://github.com/ggerganov/llama.cpp cd llama.cpp cmake -B build -DGGML_CUDA = ON -DLLAMA_OPENSSL = ON cmake --build build --config Release # no GPU git clone https://github.com/ggerganov/llama.cpp cd llama.cpp cmake -B build cmake --build build --config Release 4. run the model Run gemma-4-12b-it with cli and server. unsloth/gemma-4-12b-it-GGUF · Hugging Face We’re on a journey to advance and democratize artificial intelligence through open source and open science. huggingface.co ./build/bin/llama-cli -hf unsloth/gemma-4-12b-it-GGUF:UD-Q4_K_XL > hello [ Start thinking] The user said "hello" . The user is initiating a conversation. Respond politely and offer assistance. * "Hello! How can I help you today?" * "Hi there! What's on your mind?" * "Hello! Is there anything I can assist you with?" [ End thinking] Hello! How can I help you today? [ Prompt: 19.5 t/s | Generation: 11.8 t/s ] or run web-ui ./build/bin/llama-server -hf unsloth/gemma-4-12b-it-GGUF:UD-Q4_K_XL --port 8080 optional download model from huggingface mkdir -p models wget -O models/gemma-4-12b-it-UD-Q4_K_XL.gguf https://huggingface.co/unsloth/gemma-4-12b-it-GGUF/resolve/main/gemma-4-12b-it-UD-Q4_K_XL.gguf

This quick tutorial shows how to install ASDF Version Manager on Arch Linux and use it to install PHP 8.5. Install Required Dependencies First, install the required packages and build dependencies: yay -S base-devel libpng postgresql-libs re2c gd oniguruma libzip libsodium You may also want to install additional common dependencies: yay -S curl git openssl zlib libxml2 sqlite Install ASDF Clone the ASDF repository: git clone https://github.com/asdf-vm/asdf.git ~/.asdf --branch v0.18.0 Add ASDF to your shell configuration. Bash echo '. "$HOME/.asdf/asdf.sh"' >> ~/.bashrc echo '. "$HOME/.asdf/completions/asdf.bash"' >> ~/.bashrc source ~/.bashrc ZSH echo '. "$HOME/.asdf/asdf.sh"' >> ~/.zshrc echo '. "$HOME/.asdf/completions/asdf.bash"' >> ~/.zshrc source ~/.zshrc Verify installation: asdf --version Add the PHP Plugin Install the PHP plugin for ASDF: asdf plugin add php https://github.com/asdf-community/asdf-php.git Install PHP 8.5 List available PHP versions: asdf list all php Install PHP 8.5: asdf install php 8.5.0 Set PHP 8.5 as the global default: asdf global php 8.5.0 Reload your shell: exec $SHELL Verify the installation: php -v Expected output: PHP 8.5.x ( cli ) Useful ASDF Commands List installed PHP versions: asdf list php Install another PHP version: asdf install php 8.4.0 Switch globally: asdf global php 8.4.0 Switch locally for a project: asdf local php 8.5.0 Optional: Install Composer After installing PHP, install Composer globally: php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');" php composer-setup.php sudo mv composer.phar /usr/local/bin/composer rm composer-setup.php Verify: composer --version

"The whole conversation shifted from tokenmaxxing and 'go fast' to 'we need guardrails, how do we control this?'"

AI companies are using serif to project humanity. Critics are calling it “tasteslop.”

I used to think the best AI food logging flow would be simple: Take a photo, let the model identify the meal, confirm it, done. That works surprisingly well for a lot of meals. But while building MetricSync, I learned the awkward product truth: the best input method changes depending on what is in front of the user. A photo is great for a plate. A barcode is better for packaged food. Text is better when the user already knows what they ate or wants to fix one detail quickly. The mistake is treating one input mode like the whole product. Photos feel magical until the meal gets messy Photo logging is the most impressive demo because it removes the blank search box problem. The user does not need to know the exact database name for “rice bowl with chicken and avocado.” They can just show the app what they ate. But meals are messy. A photo might miss the sauce. It might not know if the drink is diet or regular. It might confuse a small serving with a large one. It might identify the food category correctly but still need a portion correction. That does not make photo logging bad. It just means the UX cannot end at “AI guessed something.” The real product is the correction loop. Can the user fix the meal without starting over? Barcode scanning is boring in the best way Barcode scanning is not as exciting as AI, but it is often the right tool. If someone is logging a protein bar, yogurt, cereal, or a packaged drink, asking an image model to infer the nutrition facts is silly. The barcode is more direct. That changed how I thought about the app. AI should not be the star of every interaction. Sometimes AI should get out of the way. The goal is not “use AI everywhere.” The goal is “make logging the thing in front of me take the least effort.” For packaged foods, that means barcode first. For mixed plates, that means photo first. For quick edits, that means text. Text still matters The more AI features you add, the easier it is to forget text input. But text is still the fas

The Setup I run a Proxmox 9 homelab (pve-manager/9.0.5, kernel 6.14.8-2-pve) and I needed to run Docker inside an LXC container — not a VM — to test a customer-style "bring-your-own-VPS" deployment path for a PaaS I'm building. The container had to act like a standard Ubuntu cloud VM: Docker, systemd, the works. LXC over a full VM gets me near-bare-metal performance, a fraction of the RAM overhead, and instant boots. The catch: the "Docker on LXC" recipes you'll find on most blog posts and Proxmox forum threads are out of date . They assume kernel 5.x and runc 1.1.x. On a modern Proxmox (kernel 6.14 + runc 1.2+ shipped with Docker 29) those recipes fail in two new and confusing ways before you even reach the workarounds we used to know about. This article walks through exactly what fails, why it fails, and the config that actually works in 2026 — plus an honest look at the security tradeoffs, because spoiler: the working config is privileged , and that matters. The Goal A Proxmox LXC container that can: Run docker run hello-world cleanly Pull and build complex images (multi-stage builds, overlay2 storage driver) Run nested containers with their own systemd Use systemd --user for per-service lingering processes Attempt 1: Unprivileged LXC (the path you "should" take) Conventional wisdom says: use unprivileged LXC. The container's root is mapped to an unprivileged UID on the host (typically 100000 ), so even a full container compromise can't escape to host root. Modern Proxmox makes this the default and recommended mode. I started with an unprivileged Ubuntu 25.04 container, added the now-standard features: pct set <vmid> -features nesting = 1,keyctl = 1,fuse = 1 Then inside the container, installed Docker from the official download.docker.com repo and ran: docker run --rm hello-world Here's what happened: docker: Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start

Wer täglich in anspruchsvollen Agenturprojekten arbeitet und zwischen Windows-Host und Linux-Umgebung wechselt, weiß: WSL 2 ist ein Gamechanger. Doch selbst wenn man das perfekte Setup einmal konfiguriert hat, kommt unweigerlich der Moment, in dem eine Distribution hängt, RAM freigegeben werden muss oder man ein Backup ziehen will. Anstatt jedes Mal Stack Overflow zu durchsuchen, habe ich mir angewöhnt, die essenziellen Konsolen-Befehle immer griffbereit zu haben. Hier sind die 5 WSL-Befehle, die ich in meinem Setup am häufigsten brauche: Wer täglich in anspruchsvollen Agenturprojekten arbeitet und zwischen Windows-Host und Linux-Umgebung wechselt, weiß: WSL 2 ist ein Gamechanger. Doch selbst wenn man das perfekte Setup einmal konfiguriert hat, kommt unweigerlich der Moment, in dem eine Distribution hängt, RAM freigegeben werden muss oder man ein Backup ziehen will. Anstatt jedes Mal Stack Overflow zu durchsuchen, habe ich mir angewöhnt, die essenziellen Konsolen-Befehle immer griffbereit zu haben. Hier sind die 5 WSL-Befehle, die ich in meinem Setup am häufigsten brauche: 1. Den Status aller Distributionen prüfen Der absolute Standard-Befehl, um zu sehen, welche Linux-Instanzen laufen und welche WSL-Version sie nutzen. wsl --list --verbose # oder kurz: wsl -l -v 2. Der Notaus-Schalter (RAM freigeben) Wenn Docker oder ein Node-Prozess im Hintergrund den gesamten Arbeitsspeicher blockieren, fährt dieser Befehl alle WSL 2 Instanzen sauber herunter. wsl --shutdown 3. Eine bestimmte Distribution als Standard setzen Wichtig, wenn man beispielsweise neben Ubuntu noch Debian installiert hat und festlegen will, was sich beim reinen Befehl wsl öffnet. wsl --set-default <Distributionsname> 4. Die WSL-Umgebung neustarten Es gibt keinen direkten "Restart"-Befehl. Die sauberste Lösung ist das Beenden (Terminate) der spezifischen Instanz. Beim nächsten Aufruf startet sie frisch. wsl --terminate <Distributionsname> 5. IP-Adresse der WSL-Instanz herausfinden Extrem hilfreich für be

There is a moment every embedded Linux developer hits eventually. You have spent days building something that works beautifully — a sensor pipeline, a streaming server, an MQTT client — and then you reboot the device and everything is silent. Nothing started. You SSH in, manually run your script, and it all comes back to life. The hardware is fine. Your code is fine. You just have no way of automatically running it. That is the gap systemd fills. It is the init system on virtually every modern Linux distribution, and on embedded Linux systems like the Raspberry Pi it is what decides what runs at boot, what gets restarted if it crashes, and where all the logs go. Once you understand how to write a service file, your applications stop being fragile scripts you need to babysit and start being first-class system services that survive reboots, network drops, and unexpected crashes. This tutorial builds up from the simplest possible service file to a production-ready configuration, explaining every line along the way. By the end you will have a service running your own Python application, logging to the system journal, and automatically restarting itself after failures. See Complete Tutorial in Github: Systemd Services Tutorial What systemd Actually Does Before writing any configuration, it helps to understand what problem systemd is solving, because the design of service files makes much more sense once you see the underlying model. When your Raspberry Pi boots, the Linux kernel starts and immediately hands control to process ID 1 — the very first user-space process. On modern systems, that process is systemd . Everything that happens next — mounting filesystems, bringing up the network, starting your application — is orchestrated by systemd. It reads configuration files called unit files that describe what should be started, when, in what order, and what to do if something goes wrong. A service file is just one type of unit file (there are also unit files for timers, so

Just released an open-source bash checker for CIFSwitch (CVE-2026-46243) — the 19-year-old Linux kernel LPE disclosed last week that lets any unprivileged local user get root by abusing the CIFS/SPNEGO upcall path. The script runs on bare-metal, VMs, and inside containers, and is CI/CD-friendly with JSON output and clean exit codes. It checks: ✅ Kernel version against patched thresholds (6.18.22 / 6.19.12 / 7.0+) ✅ cifs-utils presence and exploitable version ✅ CIFS kernel module load state and blacklist status ✅ Unprivileged user namespace sysctl (the pivot point for the exploit) ✅ Active request-key cifs.spnego rules ✅ SELinux / AppArmor enforcement ✅ Container capabilities (CAP_SYS_ADMIN) ✅ Kernel symbol verification for the fix commit Outputs human-readable or JSON for SIEM ingestion. Exit 0 = safe, exit 1 = action needed — drop it straight into a pipeline. CIFSwitch is the fourth Linux LPE in under six weeks (after Copy Fail, Dirty Frag, and Fragnesia). If you're running multi-tenant Linux, CI runners, or container build farms, now is a good time to audit. I have also updated the cve_checks.conf in my my K8s-container_escape_audit toolkit to detect this issue.

My father worked in IT for over thirty years, and growing up around that shaped how I thought about computers. The earliest memory I have is sitting in my father's lap as he does something on his computer. One of the oldest photos I have is of me sitting on a chair in front of a computer. I grew up idolizing him. I switched to Linux when I was 12, by myself. I taught myself scripting, picked up programming basics, and spent more time in a terminal than most adults I knew. I have memories of sitting on the roof at 13 with my laptop, trying to crack my neighbor's WiFi with aircrack-ng (they were aware of my endeavors). However, growing up in a politically volatile neighborhood (Lyari) also made me politically aware and literate from a young age. With that, I developed an interest in political science and philosophy. I sat my A levels in economics and sociology, and I did not look back. For the next few years, the technical side of my life became just a habit rather than a professional direction. Then I realized I do not have to choose one or the other. I can carry on doing both. Today, I am an academic and technical editor. The social sciences gave me the writing skills: reading long blocks of dense theory, explaining abstract concepts in plain language, writing long analytical essays. And I understand technical concepts well enough to work with them seriously. I thought of synthesizing both. When I started building a technical writing portfolio, cybersecurity documentation felt like a natural place to go. Not because I had operational experience, but because I had grown up adjacent to that world. I understood the culture, the tooling, and the mindset, even if I had never worked a SOC shift. I knew I wanted to cover security documentation. Security teams produce some of the most consequential written work in any organization, and most of it is poorly structured, inconsistently formatted, or written for the person who already knows the answer rather than the person who

Co to jest WCAG 2.1? WCAG 2.1 ( Web Content Accessibility Guidelines ) to międzynarodowy standard techniczny określający, jak tworzyć strony www i aplikacje mobilne, aby były dostępne dla osób z niepełnosprawnościami (wzroku, słuchu, ruchu, poznawczymi). Wersja 2.1 rozszerza wcześniejsze zasady o wytyczne dla urządzeń mobilnych oraz osób słabowidzących. Struktura WCAG 2.1 i poziomy zgodności Standard opiera się na 4 głównych zasadach. Dzielą się one na wytyczne, do których przypisane są konkretne kryteria sukcesu wdrażane na trzech poziomach: Poziom A: Absolutne minimum. Bez niego strona jest całkowicie niefunkcjonalna dla wielu użytkowników. Poziom AA: Standard rynkowy i prawny. Wymagany przez polskie i europejskie przepisy dla sektora publicznego i biznesu. Poziom AAA: Najwyższy stopień dostępności, trudny do wdrożenia w całym serwisie. Zasady POUR – Fundamenty WCAG 2.1 Wszystkie wytyczne WCAG 2.1 opierają się na czterech głównych zasadach tworzących akronim POUR : P erceivable ( Postrzegalność ) - Treść musi być dostarczana w sposób czytelny dla zmysłów użytkownika (wzroku, słuchu). O perable ( Funkcjonalność ) - Interfejs i nawigacja muszą być możliwe do obsługi za pomocą różnych urządzeń (np. samej klawiatury). U nderstandable ( Zrozumiałość ) - Informacje oraz obsługa strony muszą być jasne, logiczne i przewidywalne. R obust ( Solidność ) - Kod strony musi być poprawny i kompatybilny z obecnymi oraz przyszłymi technologiami (przeglądarki, czytniki ekranu). Kto musi spełniać standardy WCAG? Dostępność cyfrowa to już od dawna nie tylko "dobra praktyka", ale twardy wymóg prawny, który stale się rozszerza: Sektor publiczny (Obecnie): W Polsce urzędy państwowe i samorządowe, szkoły, uczelnie, szpitale oraz spółki skarbu państwa mają bezwzględny obowiązek spełniania standardu WCAG 2.1 na poziomie AA. Wynika to wprost z Ustawy z dnia 4 kwietnia 2019 r. o dostępności cyfrowej . Za brak zgodności grożą kary finansowe. Sektor prywatny i biznes: Na mocy Europejskiego Akt

The Scenario: The Help Desk Bottleneck From 2019 to 2021, while serving as Lead Backend Software Engineer at a fast-growing company, I occasionally support our Linux System Administration tasks. When the DevOps team encountered a critical bottleneck during an initiative to scale dozens of new server deployments, I stepped in to streamline the infrastructure processes. The DevOps team was being hampered by constant, fragmented requests from the help desk to manually create new Linux accounts for recruits testing the latest application. These interruptions were not only time-consuming but were directly preventing the team from focusing on the high-priority infrastructure deployments that define their core responsibilities. I realized that we weren't just struggling with a task; we were struggling with a scaling bottleneck. To regain the team's focus and ensure we hit our project deadlines, I decided to automate this workflow. The First Step: The Interactive Script My first objective was to develop a robust, automated shell script to efficiently create new Linux user accounts. I started with an interactive Bash script (create-user-interactive.sh) that prompted for input. This was a good educational exercise for learning the fundamentals of Bash—like useradd, passwd, and shell variables. However, I quickly learned that while interactive scripts are great for learning, they are rarely used in professional DevOps environments. Why Manual Scripts Don’t Scale As I transitioned into a more infrastructure-focused role, I realized that manual scripts fail for three key reasons: Lack of Automation: DevOps is about "Infrastructure as Code" (IaC). Asking an engineer to sit at a terminal and type prompts is slow, error-prone, and destroys the ability to automate. Lack of Centralization: In a real team, we aren't creating users on individual local machines. We manage identity across hundreds of servers. Security Risks: Hardcoding passwords or piping them through echo is a major red

This article was originally published on aifoss.dev --- title: 'Chroma vs Qdrant vs Weaviate 2026: RAG Database Compared' description: 'Compare Chroma, Qdrant, and Weaviate for local RAG in 2026: version snapshots, filtering tradeoffs, hybrid search, quantization, and a clear pick by use case.' pubDate: 'May 27 2026' tags: ["vectordb", "ai", "rag", "python", "opensource"] The three most commonly recommended open-source vector databases for RAG — Chroma, Qdrant, and Weaviate — are not interchangeable. Chroma is a prototyping tool that grew into a real product. Qdrant is a production workhorse written in Rust with the best filtering performance of the three. Weaviate is an enterprise-grade platform with hybrid search and the most built-in integrations. Using Weaviate when you need Chroma adds unnecessary ops overhead. Using Chroma when you need Qdrant means migrating under pressure when your collection outgrows it. Versions covered: ChromaDB v1.5.9 (May 2026), Qdrant v1.17.1 (March 2026), Weaviate v1.37 (May 2026). The quick answer Situation Best choice Local prototyping, notebooks, under 100K vectors Chroma Embedded in a Python process — no separate service Chroma Production RAG with filtering-heavy queries Qdrant Multi-user deployment, concurrent queries Qdrant Memory-constrained deployment at millions of vectors Qdrant Hybrid search (BM25 + vector in one query) Weaviate Multi-modal retrieval (text + images + audio) Weaviate Built-in re-ranking or generative AI modules Weaviate Kubernetes, team-operated, agentic MCP workflows Weaviate Getting from zero to working RAG in 10 minutes Chroma What each tool actually is ChromaDB (Apache 2.0, chroma-core/chroma ) started as a pure-Python embedded database and was rebuilt in Rust for the v1.0 release. The Rust core eliminates Python's GIL bottlenecks and delivers roughly 4× faster writes and queries compared to the pre-1.0 implementation — write throughput went from ~10K to ~40K+ vectors/second in server mode. Chroma's des

Most people use these technologies every day. Almost nobody knows they exist. Every time you open YouTube, browse Instagram, join a Zoom meeting, or play an online game, your router is quietly performing a series of networking tricks behind the scenes. Those tricks have names: NAT SNAT DNAT PAT Port Forwarding They sound intimidating. They're actually much simpler than they appear. Let's break them down using something familiar: your home Wi-Fi. The Problem the Internet Had to Solve Imagine a family of five living in one house. Everyone owns a device: Laptop Phone Smart TV Gaming Console Tablet Each device needs internet access. The problem? Your Internet Service Provider usually gives you only one public IP address . Something has to manage all those devices sharing a single internet connection. That's where NAT comes in. NAT: The Receptionist of Your Network NAT stands for Network Address Translation . Think of NAT as a receptionist in an office building. People inside the building have room numbers: Laptop = Room 101 Phone = Room 102 TV = Room 103 But when communicating with the outside world, everyone uses the building's main address. The receptionist keeps track of who sent what. Your router does exactly the same thing. What Happens When You Visit Google? Inside your home: Laptop 192.168.1.10 Your router: Public IP 49.x.x.x When you open Google: 192.168.1.10 ↓ Router ↓ 49.x.x.x ↓ Google Google never sees your private IP. It only sees your router's public IP. That's NAT in action. SNAT: Changing the Sender's Address SNAT stands for Source Network Address Translation . The keyword is: Source It changes the sender's address. Before leaving your network: Source: 192.168.1.10 After SNAT: Source: 49.x.x.x The router replaces your private IP with its public IP. Without SNAT, websites wouldn't know how to send responses back to you. Real-Life Example Imagine mailing a letter. Instead of writing your bedroom number as the return address, you write the house address. Tha

We talk about pagination as if it's purely a backend concern – the database does the heavy lifting, the API returns pages, and the frontend just renders them. But in 2026, that mental model is outdated. The frontend now owns more of the data-fetching lifecycle than ever: server components prefetch, client caches hydrate, optimistic updates mutate, and streaming responses trickle in chunk by chunk. The choice between cursor pagination and offset pagination has real consequences for how you write your React components, how your cache behaves, how scroll feels on the phone, and what happens when a user navigates back. This post is about those tradeoffs – from the frontend seat. The Landscape Has Changed A few things are different in 2026 that make this conversation more nuanced than it was three or four years ago: React Server Components are mainstream. Data fetching happens on the server in many apps, which shifts where pagination state lives and how navigation works. TanStack Query is the de-facto standard for client-side async state, with first-class infinite query support baked in. The "infinite scroll vs pagination" debate is mostly settled — infinite scroll wins for feeds and content-heavy apps; numbered pages win for dense data tables. Your pagination strategy should serve that decision, not fight it. LLM-powered search and filtering are becoming common, and those use cases have their own quirks around pagination stability. Edge caching and CDN-level pagination mean that certain offset-paginated responses can be cached by URL – a genuine advantage offset still holds. What Frontend Engineers Actually Care About When you strip away the SQL theory, here's what the pagination choice actually affects on the frontend: 1. Cache Key Design With offset pagination, the cache key is simple and predictable: posts?page=3&limit=20 . Every page is independently cacheable by URL — your CDN loves this. TanStack Query, SWR, and Apollo all handle this naturally. // Offset — clean,

When we started experimenting with AI translations, we assumed the biggest challenge would be accuracy. We were wrong. The harder problem was preference. Give two AI models the same sentence, and both translations can be technically correct. Yet people almost always have a favorite. One sounds more natural. One feels more human. One is the version they'd actually use. That observation eventually led us to build Parley , a simple game where players compare two translations and choose the better one. What happened next surprised us. People became highly engaged with a task that looked almost trivial. They started debating word choices, discussing tone, and noticing subtle differences between translations. Some users spent far longer interacting with translation examples than they ever would reading documentation or language-learning materials. It highlighted something interesting about AI products: evaluation can be more engaging than generation. Most AI interfaces focus on creating content. But humans are often much better at judging quality than producing it from scratch. Asking someone to choose between two outputs requires less effort while still training their intuition. The experiment also changed how I think about language learning. Traditional language apps often rely on memorization and repetition. But comparing alternatives forces you to think about meaning, context, and natural expression. You're not just learning vocabulary, you're developing taste. And in a world where AI can generate endless content, taste might become one of the most valuable skills we can build. Have you seen similar patterns in AI products where evaluation turns out to be more engaging than creation?

When managing production enterprise infrastructure, you rarely have direct root access via SFTP or SSH for security reasons. Instead, you often have to navigate multi-layered permissions—logging in as a standard user, transferring files locally, and escalating privileges via CLI to finalize configurations. In this tutorial, we will walk through the step-by-step procedure to safely renew an Apache SSL certificate under a restricted environment where WinSCP access is limited to a non-root user (sysops), requiring command-line intervention to complete the installation. Prerequisites A target Apache web server (CentOS/RHEL-based configuration using /etc/httpd/). A standard user account (sysops) with sudo privileges. The new SSL certificate (.crt) and CA bundle/chain file ready on your local machine. Step 1: Backup Existing Certificates Before making any changes to production security files, always back up the working configuration. Access the server via PuTTY using the sysops account, and switch to the root user or use sudo to create a backup of your existing keys: sudo cp /etc/httpd/server.crt /etc/httpd/server.crt.bak sudo cp /etc/httpd/server.key /etc/httpd/server.key.bak Step 2: Stage the New Certificates via WinSCP Because your WinSCP session cannot log in directly as root, you must stage the files in a directory your user owns. Open WinSCP and log in using your sysops credentials. Upload your new certificate files (nouveau_certificat.crt and nouveau_certificat_chain.pem) directly into your home directory: /home/sysops/. Step 3: Install and Replace the Certificates Now, return to your terminal session (PuTTY) to move the files from your staging directory to the protected Apache directory using elevated privileges. Copy the new primary certificate sudo cp /home/sysops/nouveau_certificat.crt /etc/httpd/server.crt Copy the new certificate chain / CA bundle sudo cp /home/sysops/nouveau_certificat_chain.pem /etc/httpd/server-ca.crt Step 4: Verify Permissions and Ownersh

fd vs find vs ripgrep: I Created 10,000 Files to Settle This Debate TL;DR: fd is ~2.5x faster than find for filename searches, rg demolishes grep by ~3x for content searches, and find + grep combined lose on every single benchmark I ran. But there's a catch: both fd and rg skip hidden files by default, which can bite you if you're not paying attention. Here are the receipts. Why I Did This Every time someone posts a shell one-liner using find on Reddit, there's always that guy in the comments: "jUsT uSe fD, iT's fAsTeR." Then someone else chimes in with "actually ripgrep can do that too." I got tired of the anecdotes. I wanted numbers. Real ones. On real files. So I fired up WSL, generated 10,900 files across 1,506 directories (~143 MB of mixed content), and ran actual benchmarks with hyperfine . No synthetic microbenchmarks, no "I feel like X is faster" — just cold, hard terminal output. Methodology The Test Bed I created a directory at /tmp/fd-benchmark containing: Category Count Details Plain text files 2,000 file_*.txt — 20 bytes each, contains "test content line N" Binary files 2,000 data_*.bin — 15 bytes each Log files 1,500 match_*.log — contains unique "match_this_test_N" strings Config files 1,000 nested_file_*.cfg Nested dir files 1,000 level1_*/level2/level3/deep_*.txt + level1_*/shallow_*.txt Hidden root files 1,500 .hidden_* + .config_*.yml Hidden dir files 500 .hidden_dir/subdir/deep_hidden_*.txt Git objects 500 .git/objects/obj_* Multi-ext source files 800 src_*.{py,js,ts,rs,go,java,rb,php,cpp,h,css,html,json,xml,yaml,md} (50 each) Large binary files 100 large_*.dat — 1 MB each (random data) Total 10,900 $ du -sh . 143M . $ find . -type f | wc -l 10900 $ find . -type d | wc -l 1506 Tools Tested Tool Version What It Does find (GNU) 4.9.0 The OG. Ships with every Linux distro. fd 10.2.0 Rust-based find alternative. Smarter defaults, colored output. grep (GNU) 3.11 Content search. Also the OG. rg (ripgrep) 15.1.0 Rust-based grep alternative. Respects .gi

A lot of Linux incident response starts with a login question, not a malware sample. Someone sees a spike of failed SSH attempts. A root login appears in the wrong time window. A service account logs in from an address nobody recognizes. A helpdesk ticket says "the server looks weird" and the only concrete clue is a username or IP address. At that point, the useful question is not "is this host compromised?" It is more boring and more important: Did anyone actually authenticate? Which account was involved? Was it password, key, sudo, su, or a scheduled task? Was the same IP seen in web logs, current sockets, process context, or command history? Did persistence, services, packages, or recent files change near the same time? Can another responder review exactly what evidence was collected? That last point matters. If you let an AI assistant freely run shell commands during the first pass, you can get speed, but you also create a new risk: the model may over-collect, mutate the host, or produce a confident answer that nobody can audit later. For a login anomaly, I prefer a read-only evidence loop. A practical first pass Start with the narrow clue if you have one. If the alert names a user: oi login --user root -s 7d If the alert names an IP address: oi login --ip 203.0.113.44 -s 7d If the alert is vague, start wider: oi login -s 7d oi scan -s 7d The goal of the first pass is not to prove every detail. The goal is to build a timeline that a human responder can challenge. For a suspicious SSH login, I want the initial report to answer five things. 1. Authentication pattern Look for the difference between noise and access. A server can receive thousands of failed SSH attempts from the internet. That is useful background, but it is not the same as a successful session. The first split should be: failed attempts only successful login after many failures accepted key from an unusual source login by an account that normally should not be interactive root login where root SSH