标签：#UX

You've probably seen this before: $ ping example.com 64 bytes from 93.184.216.34: icmp_seq=1 ttl=54 time=18 ms 64 bytes from 93.184.216.34: icmp_seq=2 ttl=54 time=17 ms So the network works, right? Then: $ curl https://example.com curl: (28) Connection timed out Or your browser spins forever. This is one of the most common traps in network troubleshooting: treating a successful ping as proof that "the network is fine." It isn't. ping answers one fairly narrow question. Your application depends on several other things succeeding after that. What ping actually proves Ping normally uses ICMP echo requests and replies. If a host responds, you've learned something useful: your machine has some working route toward the destination packets can travel across at least part of that path the destination, or something representing it, is responding to ICMP But an HTTPS connection needs much more. A simplified path looks something like this: Network interface | Routing | DNS | TCP connection | TLS handshake | HTTP | Application And real networks can add more: Proxy VPN Firewall NAT MTU problems IPv4 / IPv6 differences A successful ICMP echo doesn't prove all of those layers work. That's why "but I can ping it" often doesn't get you very far. DNS can still be the problem There are a few variations here. Suppose you run: ping 1.1.1.1 and it works. That says nothing about DNS. Try: dig example.com or: getent ahosts example.com If name resolution fails, applications using hostnames will still be broken even though you have basic IP connectivity. There's another wrinkle: your application and your diagnostic tool may not necessarily use DNS in exactly the same way. Your system resolver, a browser using encrypted DNS, a VPN-provided resolver, and a corporate DNS setup can produce different behavior. So "DNS works" can sometimes need a more specific question: Which DNS, resolving what name, from which environment? TCP can fail even when ping succeeds HTTPS normally needs a TCP connectio

By Cristhiam Leonardo Hernández Quiñonez (CLHQ) Founder – HormigasAIS | Sovereign edge computing ecosystem – San Miguel, El Salvador github.com/Thrumanshow/HormigasAIS 1. The Problem: Depending on the Cloud to Validate What's Real Most content-verification and edge-computing stacks today assume a baseline dependency: a cloud provider, a centralized API, or a third-party service sitting between your data and the claim that it's authentic. That dependency is convenient, but it's also a single point of failure and a single point of control. The question I kept returning to while building HormigasAIS was simple: can a verification system be sovereign? Not "self-hosted on someone else's cloud," but genuinely independent — running on infrastructure you own, from a device as unconventional as a phone. 2. The Solution: A Node Architecture Built on Sealing, Not Trust HormigasAIS approaches this with a node-based architecture rather than a service-based one. Three pieces anchor it: LBH cryptographic sealing — content is sealed using SHA-256 + HMAC-SHA256, with signed verification that doesn't require calling out to a third party to confirm integrity. barrera.js — an ethical/logical filter layer (informally, "decromatiza") that sits between raw input and the system's accepted state. humano.js — a small symbolic module declaring the human-language layer of the project: HormigasAIS = {{lenguaje-humano}} . It's less a functional API and more a positioning statement embedded directly in code — a reminder that the system is meant to stay legible to a human reader, not just to a machine. None of this requires a data center. The full development loop — writing, testing, sealing, deploying — happens from an Android device running Termux. 3. The Implementation: From a 404 to a Working Node The most concrete proof point is small on purpose. The repository Thrumanshow/HormigasAIS started as a set of governance and symbolic files with no public-facing page — visiting its GitHub Pages URL

I signed up for the Black IT Academy Linux Upskill Challenge. Twenty lessons, one server, a cohort in Slack, and a rule that you keep a public journal of what you did every day. Day 0 was today. The only goal was to have a server I could log into and to post a screenshot proving it. That took about ten minutes. Then a purple box showed up in my terminal and I sat there for a while. The setup I went with a DigitalOcean droplet. Ubuntu 24.04, the cheapest Basic plan, [password / SSH key] for auth. The challenge guide says do not spend Day 0 comparing hosting providers, and after my AWS bill situation I did not need convincing. First thing I did after the droplet came up was set a $10 billing alert. That is a habit now. Connected with ssh root@ and the IP. Said yes to the fingerprint prompt. Ran whoami and uptime and felt good about myself. Then I ran the standard sudo apt update && sudo apt upgrade -y because that is what you do on a fresh box. The prompt Halfway through the upgrade everything stopped and I got this: A new version of configuration file /etc/ssh/sshd_config is available, but the version installed currently has been locally modified. What do you want to do about modified configuration file sshd_config? With a menu. Install the package maintainer's version. Keep the local version currently installed. Show the differences. A three way merge option. My first reaction was confusion. Locally modified by who? I had owned this server for four minutes. I had not opened a single config file. What was actually going on sshd_config is the file that controls how the SSH server behaves. Which port it listens on, whether root can log in, whether passwords are allowed or only keys. It is the file that decides if you can get back into your own server. The reason it was "locally modified" is that DigitalOcean modified it. When a droplet gets built, their provisioning process writes SSH settings into that file so you can log in the way you chose in their dashboard. From

By keeping - secure boot :ON and Bit Locker :ON Step one : Download Linux mint – cinnamon edition 22.3 Step two : Download Rufus Step three : plug the pen drive and flash the Linux mint into pen drive Step four : Open disk management to partition the disk for Linux mint Step one : Restart the PC and Click the required key to open the boot menu Step six : click Linux mint Step seven : After the welcome screen appeared, Now install Linux mint Step eight : Follow the steps and when installation page comes choose separate space manually step nine : click the free space which u partition and split the space for root and home. step ten : click install

My browser sat there spinning on "connecting". The setup is common enough: x11vnc shares a screen on port 5900, and websockify forwards to it so a browser can connect. I checked the services. websockify was running. Everything was running. Nothing worked. The question I actually needed answered was simple: Who is using port 5900? That's normally ss -ltnp or lsof -i :5900 , and neither was installed on that box — which is why I'd written a small tool for this one question: $ portclue 5900 NOT EXPOSED LOCALLY TCP port 5900 127.0.0.1:5900/tcp [NOT_EXPOSED_LOCALLY] -> LISTEN ... bound to 127.0.0.1:5900/tcp -> OWNED PID 1087636 (x11vnc), systemd unit session-1911.scope -> LOOPBACK_ONLY 127.0.0.1 is reachable only from this network namespace An x11vnc had the port — just not the one I'd started. It was a leftover from a session days earlier that had never shut down, so the new one could never get the port, and websockify had been faithfully forwarding to a dead screen the whole time. (PortClue gave me the PID. ps is what confirmed the process was far older than everything around it — the tool doesn't report process age yet.) Why I reach for it Same facts ss would give you, but written out instead of encoded. 127.0.0.1 isn't a number you have to interpret; it says "reachable only from this network namespace". On a port bound to 0.0.0.0 it says ALL_INTERFACES , then reads your nftables or iptables rules to see whether anything is actually allowed through. If it can't read them, it says UNKNOWN instead of guessing. It gets all of that without ss or lsof installed, by asking the kernel directly. It's read-only: it never connects to the port you ask about, and it can't kill anything. Scope is Linux TCP listeners — that's the whole promise. Try it curl -fsSL https://raw.githubusercontent.com/pbxqdown/portclue/v0.1.2/scripts/install.sh | sh portclue # everything listening portclue 5900 # one port, explained https://github.com/pbxqdown/portclue

Helping someone troubleshoot a terminal problem remotely often involves a frustrating loop: “Run this command and send me the output.” Then you wait for a screenshot, send another command, and repeat the process. I built rsynx to make that workflow more direct. What is rsynx? rsynx is an open-source tool for sharing a live terminal between two people. It does not require: Exchanging SSH credentials or keys A public IP address Port forwarding Inbound firewall configuration The host remains in control of the session. A guest must be approved before joining, and typing access requires an additional approval. It can be useful for: Remote technical support Collaborative troubleshooting Pair debugging Helping someone manage a Linux machine Demonstrating terminal commands in real time Installation On Linux and macOS, run: curl -fsSL https://rsynx.ir/i | sh The installer downloads the appropriate binary and installs rsynx into your local binary directory. If you prefer not to pipe an installation script into your shell, you can inspect the script first: curl -fsSL https://rsynx.ir/i You can also manually download a binary from the project’s GitHub Releases page: Download rsynx from GitHub Releases Windows users can manually download the appropriate binary from the Releases page. How it works 1. Start a session The person sharing their terminal becomes the host : rsynx host rsynx creates a new session and displays: A six-digit session code A four-character password The host sends these temporary credentials to the guest through a trusted communication channel. 2. Join the session The guest connects using the session code: rsynx join <code> For example: rsynx join 123456 The guest is then asked to enter the four-character password. Providing the correct code and password does not automatically grant access. A connection request is shown in the host’s terminal. 3. Approve the connection The host can review the incoming request and either approve or reject it. Only after approv

De qué se trata esto Este es el segundo video del bloque de ciberseguridad. En el primero armé un SIEM gratis con Wazuh y Kibana. Acá le doy la vuelta: simulo un ataque completo contra mi propio lab, con las mismas herramientas que usa un atacante real, y muestro exactamente qué queda invisible y qué queda registrado del otro lado. Nada de esto corre contra infraestructura de terceros — todo el lab vive en una red virtual aislada (Host-only de VMware, 192.168.220.0/24 ), sin salida a mi red real ni a internet. El lab Dos objetivos, dos propósitos distintos: Metasploitable2 (una VM deliberadamente vulnerable, hecha para practicar) — solo para mostrar exposición real. No tiene el agente de Wazuh instalado (corre sobre Ubuntu 8.04, muy por debajo del piso mínimo que soporta Wazuh — Debian 10+). Un contenedor con el agente de Wazuh activo (SSH en el puerto 2222, Apache en el 8080), enrolado contra el mismo manager del video anterior. Este es el que "ve" todo. El stack de Wazuh en sí (dashboard, indexer, API) quedó atado únicamente a 127.0.0.1 en el host — ni Kali ni mi red real lo pueden alcanzar. Sin este detalle, cualquier escaneo contra mi propia máquina terminaría revelando el propio SIEM en los resultados, lo cual además de ser un problema de seguridad real, rompe la demostración. Fase 1 — Descubrimiento (no sabía nada todavía) nmap -sn 192.168.220.0/24 -sn le dice a nmap "no toques puertos, solo decime quién está vivo". Es el primer paso de cualquier reconocimiento: antes de elegir un objetivo, hay que saber qué hay en la red. Encontré 4 hosts — descartando mi propia Kali y el servidor DHCP de la red virtual, quedaron 2 candidatos reales. Fase 2 — Enumeración (¿qué corre en cada uno?) nmap -sV <IP> Sobre Metasploitable2, esto tiró 24 puertos abiertos — un inventario de dos décadas de software sin actualizar: vsftpd 2.3.4 (versión con una puerta trasera pública conocida), telnet sin cifrar, y un puerto literalmente identificado como Metasploitable root shell . Es l

COSMIC Epoch 1.8 is out, the latest release of System76's Rust-based desktop environment for Pop!_OS and other Linux distributions. Phoronix reported the release on September 10, 2026, noting it arrived just two weeks after version 1.7. COSMIC is System76's own desktop environment, built with Rust and its Iced GUI toolkit, rather than a fork of GNOME or KDE. The company ships it as the default on Pop!_OS and makes it available to other Linux distributions too. A two-week gap between minor releases is fast for a desktop environment; GNOME and KDE Plasma, by comparison, ship on cycles measured in months. What Phoronix reported as new According to Phoronix, COSMIC Epoch 1.8 adds three user-facing changes. XWayland windows, meaning older, non-Wayland-native applications running through a compatibility layer, can now start in a minimized state through the COSMIC Compositor, instead of always opening on screen. COSMIC Shell gains improved tablet support, including the ability to grab, or capture exclusive input from, a graphics tablet. COSMIC Settings now lets a user rename a connected Bluetooth device, instead of only seeing its default hardware name. What the official release page says The official GitHub release for epoch-1.8.0 tells a narrower story. As of publication, System76 marks the release a pre-release, and its own changelog is listed as "pending" rather than filled in. The text that is there describes the update as "translation updates and dependency updates for many projects" across the COSMIC codebase. The release page has drawn 21 community reactions so far. The two accounts do not contradict each other, but they do not fully match either. Phoronix describes specific new features. System76's own release notes, at the time of writing, describe only translation and dependency work and have not been filled in with feature detail yet. Both can be true if System76 simply has not finished writing up the release, which the "pending" label suggests. What this means

In 1993, Jakob Nielsen wrote three numbers that have quietly governed every UI ever since. 0.1 second. 1 second. 10 seconds. Under 100 milliseconds, an interface feels instant. Under 1 second, thought doesn't break. Past 10 seconds, users are gone. Thirty-plus years later, those thresholds are still baseline material in every UX curriculum, and Nielsen Norman Group still publishes the same three cliffs when they're asked about response times. They map cleanly to the web. They map badly to voice. The missing screen is what breaks the mapping. Take away the loading spinner and every one of Nielsen's thresholds contracts. Nielsen's thresholds are neurological, not screen-based The numbers weren't invented for computers. Nielsen was consolidating perception research going back to the 1960s: Miller in 1968, Card and colleagues in 1991, all trying to pin down how long humans stay "in the loop" of an interaction. 100 ms : the ceiling for perceiving something as a direct response to your action. Below this, the effect feels like it belongs to you. Above it, cause and effect start to separate. 1 second : the ceiling for uninterrupted thought. Between 100 ms and 1 second, users notice the delay but stay in flow; past a second, they drop out of the task and start waiting. 10 seconds : the ceiling for holding attention at all. Past this, minds wander to email, phones, other tabs. The numbers describe human cognition, and the hardware they were measured on has changed beyond recognition without moving them. The 100 ms figure is unchanged in 2026. The 1-second figure still describes when a web page starts feeling broken. But those numbers assumed there was something to look at while you waited. Voice has no spinner Voice interfaces strip out the entire "we're working on it" channel. There is no loading bar. No skeleton state. No progress percentage. No "typing..." indicator sitting under the previous message. The only signal the user gets between "I stopped talking" and "the agen

Koha Testing Docker on WSL: Common Setup Problems and Fixes While setting up Koha Testing Docker (KTD) on Windows using WSL and Docker Desktop, I encountered several problems related to Docker configuration, port conflicts, and accessing Koha through the browser. This guide summarizes the problems I encountered, how I diagnosed them, and how I fixed them. The goal is to provide a practical troubleshooting guide for anyone setting up Koha Testing Docker on Windows with WSL and Docker Desktop. Environment My setup consisted of: Windows WSL (Ubuntu) Docker Desktop Koha Testing Docker (KTD) 1. ktd pull Could Not Find Docker Problem When I initially ran: ktd pull KTD produced an error similar to: .../ktd: line 725: /usr/bin/docker: No such file or directory At first, this was confusing because Docker was already installed and working. I checked: which docker and received: /usr/bin/docker I also ran: /usr/bin/docker --version which successfully displayed the installed Docker version. Therefore, Docker itself was not missing. Cause The problem was related to how the KTD configuration was being read. The .env file was not being interpreted correctly, and it also contained Windows-style CRLF line endings. I checked the file using: cat -v .env If the output contains ^M at the end of lines, that indicates Windows-style line endings. For example: DOCKER_BINARY=/usr/bin/docker^M The ^M is the carriage-return character from Windows line endings. Fix I made sure that .env contained: DOCKER_BINARY=/usr/bin/docker I also converted the .env file to Unix-style line endings. After fixing the configuration, I ran: ktd pull again, and it worked successfully. Lesson When using configuration files between Windows and WSL/Linux, always check for CRLF line endings if a shell script behaves unexpectedly. 2. Port 8080 Was Already in Use Problem After successfully pulling the KTD images, I tried to start the environment: ktd up -d However, Docker returned an error similar to: ports are not avai

A reader searches for help opening a puzzle box. The result supplies the answer in its preview, includes a later character reveal in the heading, and never explains whether the solution was actually verified. A horror-game guide can fail in two separate ways: it can reveal more than the reader wanted, or express more certainty than its evidence supports. I would treat those as distinct content properties. Identify the two editorial decisions The puzzle page on The Skin Stapler Wiki https://theskinstapler.com illustrates the distinction. It publishes a numeric solution directly in its introduction and a section heading. Elsewhere, it explicitly leaves a tarot-card sequence unconfirmed because the available evidence does not establish the accepted order. It also distinguishes two possible contexts behind searches for a “blood puzzle.” These are useful observations for a design exercise. The page makes some uncertainty visible, while the direct answer placement suggests an opportunity to give readers more control over spoilers. My proposed design would answer two questions for every content block: How much does this reveal? What supports the claim? A verified answer can still be an unwanted spoiler. A vague hint can still be wrong. One label cannot stand in for the other. Model spoiler scope and evidence status separately For a small publishing system, I would begin with two independent fields. Spoiler scope might distinguish general orientation, a local puzzle hint, an exact solution, and a story reveal. Evidence status might distinguish an observed result, a published source claim, an editorial inference, and an unresolved question. These categories are proposed editorial choices, not descriptions of the site’s implementation. Consider a hypothetical puzzle entry. Its first paragraph points readers toward a nearby clue. Its second explains how to interpret that clue. Its third gives the accepted input. Those paragraphs have different spoiler scopes even if they all r

A player opens a warehouse guide because deliveries are not working. The page explains warehouses, lists equipment, and mentions staffing. Yet the player still has to work out which condition to check first. For developers building documentation sites, that gap is worth designing around: a reader needs an explanation that leads to a decision. Start with the question the page must resolve The warehouse page on my independent fan site, Big Ambitions Wiki bigambitionswiki.com, provides a concrete example. It presents a quick answer, then separates its content into an explanation, setup guidance, version limitations, and sources. It also links to related pages about warehouse layout, pallet shelves, and delivery. The opening explanation appears again in several places, including the quick answer and the main text. Those observations suggest a useful design exercise: keep the context, but make each subsequent section answer a different question. For a troubleshooting page, I would define the reader’s goal before choosing the template. “Understand warehouses” is broad. “Identify the next condition to inspect when distribution fails” gives the page a clearer job. That goal could produce three reading paths: Explain the purpose of the system. Walk through an initial setup. Diagnose an existing setup. These paths can share reference material while having different entry points. A reader troubleshooting an established operation should be able to reach the diagnostic section directly. Describe prerequisites as relationships A list of requirements leaves an important question unanswered: how do those requirements connect? For a hypothetical distribution guide, I would describe each dependency using four fields: Condition: what must be present or configured. Relationship: which other part of the workflow it connects to. Observation: what the reader can inspect. Next step: where to continue if the condition is missing. This is a proposed documentation model, not a description of

A while ago now, I entered a Bad UX competition, where a prize went to the worst date-picker. Since then I have finally found some time to polish it and make it safe to release to the public; here it is . I didn't win the contest, so I guess my demo wasn't bad enough. Is that a compliment? The idea was to parody a future where AI assistants are so widespread and overused that they become a hindrance rather than a help to the user. In this case, the date-picker form element is intercepted by a bot who insists on entering the date for you, and must establish your date of birth through tedious questioning; it refuses to simply accept the date when told directly. Besides showing it off, I thought I'd share some of the challenges I faced and lessons learned. This was my first time building an AI-powered application and my first time using the OpenAI API. Original architecture Initially, the conversation worked like this: sequenceDiagram participant C as Client participant S as Server participant O as OpenAI C->>S: Start conversation Note over S: Create session in memory S->>O: System prompt O-->>S: "What season were you born in?" Note over S: Store conversation history S-->>C: Reply + session ID C->>S: "Around Thanksgiving" + session ID Note over S: Retrieve conversation history S->>O: System prompt + history + answer O-->>S: "Was it early or late November?" Note over S: Update conversation history S-->>C: Reply When the user focuses the date field, the client makes a request to initialise the conversation. This creates a chat session in application-server memory and sends an initial request to OpenAI (specifically gpt-4o-mini), along with the prompt defining the rules of the challenge. The assistant's first response, containing its greeting and opening question, is returned to the client along with the session ID. The client includes that ID with each subsequent answer, allowing the server to retrieve the corresponding conversation history. Each new OpenAI request inclu

Before you read this I want to express that this is my first blog ever and I have no previous experience of writing blogs How it was decided I wanted to make something truly fascinating as a gift for my sister. She inspired me to start coding, and so I decided that I will build an Operating System for her. This was going to be hard so I decided that it was also going to be something I would work on after gifting it. And then began Project Leviathan What I chose I first took a look at the available options, I could try archiso which was nice to try but for me it wasn't something I would want to consider as mine. On the other end, trying to build a kernel, initramfs, and other core components of an OS all by myself was beyond what I could build in a week. So it was decided, using the linux kernel, but building the tty, drivers, graphics, and others by myself basically a Linux Distribution First steps First I began researching on what I really needed to build a Linux Distribution. For most of the research of it I used chatgpt. And even more importantly, I had to learn C. I settled with the basics, pointers, and other stuff. And then it began, I started with a simple directory and grub configurations along with MY own linux-6.8.0-138-generic kernel, so that grub would find and detect it. The TTY(TeleTypewriter) Since pretty much every part of it was still from my ubuntu installation, the first TTY was just a Busybox shell provided by my installation. But of course I had to change it. I started with a simple virtual TTY with just echo and cat, according to me quite a important feature. After quite a bit I got it working, and therefore had my first ever TTY. It still worked on busybox but the TTY only worked with my commands. Soon enough I removed Busybox entirely and at added other essential commands such as ls, rm, copy, mkdir, and pwd. The first graphics stack Since most of my TTY was done, I figured it was a good time to get started on the graphics stack. First it sta

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

You don't necessarily need more traffic. I know that's not what most growth advice tells you. Every ad platform and every "get more eyes" thread says the opposite. But after reviewing dozens of business websites across real estate, construction, hospitality, and retail, the uncomfortable truth is usually the same: the site isn't leaking customers because too few people show up. It's leaking them because the people who do show up leave within seconds, and nobody is asking why. If you've opened Google Analytics, seen respectable traffic numbers, and then looked at a disappointing lead count, this article is for you. Traffic Is Not the Same as Conversion Traffic measures attention. Conversion measures whether that attention trusts you enough to act. The gap between the two is where most of your lost leads live. A useful way to think about it is the conversion rate: the percentage of visitors who take your intended action (a form submission, a booking, a call, a purchase). If your conversion rate is 1% and you double your traffic, you now have 2% of a bigger number, but you're still losing 99% of everyone who lands on your site. Pouring more traffic into a website that fails the basics doesn't fix anything. It just means more visitors leaving faster, at a higher cost per click. The 10-Second Test Your Website Is Failing A new visitor isn't reading your site; they're scanning it. In the first few seconds, they're subconsciously asking three questions: What is this? Can I trust it? What do I do next? If your homepage doesn't answer all three quickly, they're gone. Not because they weren't interested, but because nothing gave them a reason to stay. That's not a traffic problem. That's a trust problem. Why This Keeps Getting Missed Here's the trap: trust doesn't show up as a line item in Google Analytics. There's no "trust score" sitting next to your sessions and impressions. So business owners chase what's measurable (clicks, reach, ad spend) because it feels like progress

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

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

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

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