标签：#UX

When I started using Linux Mint , I spent quite a bit of time exploring small desktop customizations. One of the simple things I discovered was that Linux Mint Cinnamon lets you customize how the date and time are displayed on the taskbar. Instead of showing only something like: Sat Aug 22 07:10 PM you can change it to something that works better for you. For example: Sat, Aug 22 • 07:10 PM or: 22 Aug 2026 | 07:10 PM or even: Saturday, 22 August • 19:10 It is a small change, but it is a nice way to personalize your desktop. Where can I change it? On Linux Mint Cinnamon, right-click the clock/date area on the taskbar and open the calendar settings. You should find a Display section with an option called: Use a custom date format Enable it and you will see a field where you can enter your own date and time format. For example: % a % b % e | % I :% M % p The Cinnamon documentation provides a complete reference for these formatting codes. But what do these strange symbols mean? At first, the format looks a little confusing: % a % b % e | % I :% M % p Don't worry. Each % code simply represents a different part of the date or time. For example: Code Meaning Example %a Short weekday Sat %A Full weekday Saturday %b Short month Aug %B Full month August %d Day with leading zero 02 %e Day without leading zero 22 %m Month number 08 %Y Four-digit year 2026 %y Two-digit year 26 %H Hour, 24-hour format 19 %I Hour, 12-hour format 07 %M Minutes 10 %S Seconds 35 %p AM/PM PM %P am/pm pm %Z Timezone IST The complete Cinnamon reference also includes things such as week numbers, day of the year and fractional seconds. You don't need to remember all of them. Once you understand a few common codes, creating your own format becomes quite easy. My favorite date and time combinations Here are some combinations you can try directly in the Date format field. 1. Simple and clean % a % b % e % I :% M % p Result: Sat Aug 22 07:10 PM 2. More readable % a , % b % e • % I :% M % p Result: Sat, Aug 22

TrueNAS CORE has been the standard for open-source storage using FreeBSD and OpenZFS. The shift to TrueNAS SCALE, based on Debian, left some users needing alternatives. FreeCORE upgrades TrueNAS CORE to FreeBSD 15.0, restoring essential features like FreeBSD Jails. While it satisfies certain administrators' needs, its long-term sustainability and maintenance by a single individual raise concerns. By Olimpiu Pop

A six-week journey through source builds, CI pipelines, and one package pacman never mentioned. TL;DR: pacman -S whisper-cpp ggml-vulkan . That's it. That's the whole answer. Here's why it took me several weeks to find it. The setup I use whisper.cpp for local speech-to-text and as a part of my projects. I have a GPU utilization monitor permanently visible in my GNOME panel via the Vitals extension — so when whisper.cpp started detecting my GPU but running everything on CPU anyway, I noticed immediately. Went to fix it. What followed was several weeks of googling, building from source, writing a custom PKGBUILD, setting up CI, publishing an AUR-style repo — and eventually discovering that the actual fix is a single extra package that pacman never once mentioned to me. The investigation First thing I checked: is the official extra/whisper-cpp package compiled with Vulkan support? All search results said no — -DGGML_VULKAN is explicitly OFF, GPU code is absent from the binary. The app sees your GPU through vulkan-icd-loader but has no code to actually use it. That matched exactly what I was seeing. So the binary itself was the problem. At the time, a separate whisper-cpp-vulkan package had existed in the repos but kept appearing and disappearing — and right then it was gone from both extra and AUR. AUR pushes were also temporarily restricted due to a supply-chain incident. So the "just install the vulkan variant" path was closed, though it used to be available sometime. The obvious move: build from source with -DGGML_VULKAN=ON , package it up, done. I published whisper-cpp-vulkan-arch with a PKGBUILD and prebuilt binaries, wired up CI to track upstream releases automatically and rebuild correspondingly, and wrote a Reddit post explaining the situation. The post was dated August 13, 2026. The twist A few weeks later, someone commented on the post. They suggested installing ggml and vulkan-icd-loader . I started writing a detailed reply explaining why this was wrong: gg

The main action took place at Geneva Watch Days, but others dialed in remotely to make sure it wasn't just a Swiss party.

Have you ever watched a two-kilobyte write fail with No space left on device while df -h still showed free gigabytes? I did, and I spent the next forty-eight hours cleaning the wrong evidence. This is the reconstructed field notebook from that session, including the commands I ran, the ones that misled me, and the checklist I now run before I blame the disk. Nothing here is a benchmark, a quota promise, or a claim about hardware I did not measure. I was iterating on a small Python worker that dumped JSON sidecars next to each run. The worker itself was unremarkable. The failure mode was not. Hour 0: the write that should have been boring The first traceback looked like a disk problem, so I treated it like a disk problem. Would you have done anything else with ENOSPC staring at you from a three-line stack? I would not, and that is exactly how the next two days started. OSError: [Errno 28] No space left on device: 'runs/2026-09-05T07-12-04.json' I ran the obvious command, got a comforting number, and closed the wrong investigation. df -h reported plenty of space on the root filesystem, and /tmp looked equally relaxed. I even created a dummy file in $HOME by hand, which succeeded, so I told myself the worker path was special. df -h df -h /tmp /var /home touch ~/probe-ok.txt && ls -l ~/probe-ok.txt That last touch was the trap. Can a filesystem accept a file in one directory and refuse a tiny file in another while still having blocks to spare? Yes, and inode exhaustion is the boring reason. I did not ask that question for twelve hours. What I tried first, and why it felt reasonable I treated the symptom as log rot, because that is the story operators tell each other. I truncated worker logs, deleted old JSON sidecars I could see, and reran the job with a smaller batch. The write still failed, sometimes on file number twenty, sometimes on file number four. Truncated worker.log and debug.log with : > file instead of deleting the path. Removed a handful of large .jsonl fil

Managing files, running scripts, and executing terminal commands on your smartphone from a computer is much more convenient through a full SSH session, eliminating the need to switch between device screens. ​Installing OpenSSH Open Termux and install the package for the secure protocol: pkg update && pkg install openssh Configuration ​Set a password to secure the connection: passwd ​ Find your current username using the whoami command (usually looks like u0_a... ). ​Start the SSH server: sshd ​Connecting from a PC Find your smartphone's local IP address using ifconfig (look for the inet line under the wlan0 interface). Note that Termux uses a non-standard port 8022 by default instead of the standard 22. Connect from your computer (Linux, macOS, or Windows via PowerShell/PuTTY): ssh <username>@<smartphone_IP> -p 8022 After entering your password, you will gain full access to your phone's terminal directly from your PC. Autostarting the Server To avoid starting the server manually every time you open the app, add the command to your shell configuration: echo "sshd" >> ~/.bashrc This tool turns your mobile device into a fully functional remote node that is easy to manage over the local network when developing and testing lightweight projects. I share more simple and awesome smartphone IT projects on my Telegram channel: @termuxq

In what appears to be a follow-up to the mighty “CasiOak,” the rugged Japanese watch brand is expected to release an all-new luxury homage.

THE BRICK AND THE POST-IT My chemical plant's first vulnerability wasn't a bug, a piece of malware, or a port left open to the internet. It was a brick. In the computer room — the one with a door held open by a brick — I found a sticky note with credentials on it. They weren't even the right credentials for the system I wanted to break into. But they made me think the way whoever wrote them thinks, so I tried the most obvious pair in the world: admin / admin . And I was in. A brick propping open a door that should be locked. A sticky note guarding a password. A factory-default admin/admin. Three layers of security, three layers defeated — not by a genius hacker, but by a student on day one, carrying no tools at all. If that happens in the IT office, it's a problem. When it happens on a factory floor, where that same computer commands real pumps and valves, it's a different planet. The problem: learning OT without a factory I study computer security. Lately I've been drawn to OT — operational technology, the security of factories, power plants and industrial systems. The problem is simple: you can't learn to defend a factory from a book, and nobody will lend you theirs. Then I realized the answer was already inside the question: if you don't have one, you build one. The build: three commands and a lot of patience The lab is called GRFICSv3: an open source project that simulates an entire chemical plant — the PLC, the operator interface, the network, even the server rooms — inside Docker, on a home computer. Three commands and done: curl -O https://raw.githubusercontent.com/Fortiphyd/GRFICSv3/main/docker-compose.yml docker compose pull docker compose up -d "Three commands and done" is the story version. The real version includes my first error, arriving right on schedule at command number two: permission denied while trying to connect to the docker API at unix:///var/run/docker.sock If you hit this — and you will — here's the diagnosis: the Docker daemon is running fi

Disk full alerts at 2am? Learn the exact commands to find what's eating your Linux server's disk space and fix it fast. You get the alert: disk usage at 94%. Your app starts throwing errors, logs stop writing, and databases refuse to accept new rows. Finding the culprit fast matters — but on a server with millions of files, knowing where to look is half the battle. Here's a systematic approach to track down disk hogs in minutes, not hours. Start With the Big Picture: df Before you dig into directories, confirm which filesystem is actually full. Run: df -h — shows all mounted filesystems with human-readable sizes df -h / — focus on the root filesystem df -i — check inode usage (a filesystem can be 'full' even with free space if inodes are exhausted) Pay attention to the 'Use%' column. If you see 100% on /var or /home but not /, that tells you exactly which mount point to investigate. Inode exhaustion — df -i showing 100% — is easy to miss and causes the same symptoms as a full disk, so always check both. Drill Down With du Once you know which mount point is full, use du to find the largest directories. Start from the top of that mount point and work down: du -sh /* 2>/dev/null — sizes of every top-level directory, errors suppressed du -sh /var/* 2>/dev/null — drill into /var if that's the culprit du -ah /var | sort -rh | head -20 — list the 20 largest files and folders inside /var The pattern is always the same: run du -sh on the suspicious directory, find the largest subdirectory, repeat one level deeper. You'll usually hit the real culprit within three or four iterations. Common offenders are /var/log (runaway logs), /var/lib/docker (unused images and volumes), and /tmp (applications that don't clean up after themselves). Find Large Files Directly With find Sometimes a single enormous file is the problem — a core dump, a forgotten database export, or a log that rotated incorrectly. Use find to surface files above a size threshold: find / -xdev -size +500M -ls 2>/de

A background noise removal workflow is easy to describe and much harder to make trustworthy. The superficial version is: upload a file, run processing, download the result. The harder version is product design: what does a person need to know before committing to a result, paying for an export, or spending a limited processing allowance? A preview-first workflow answers that question by making uncertainty a first-class part of the system. Instead of asking people to trust a long-running operation, it gives them a bounded way to hear a representative outcome before they choose what happens next. This article lays out the design principles behind that approach for stored audio or video uploads. It is not a call-time or capture-time filter. The central workflow is: upload → compatibility check → preview → same segment before/after → export choice That sequence looks simple, but each boundary carries product and engineering consequences. Start with a decision, not a processing feature A preview should help a user make one specific decision: “Is this result useful enough for me to continue?” That framing prevents a common mistake: treating a preview as a small free version of the full product. A useful preview is not merely a shorter job. It needs to be comparable, understandable, and tied to the next action. For background noise removal, the most defensible comparison is a matched segment: The source and processed audio use the same time range. Playback controls make the comparison obvious. The user can choose whether to continue only after hearing that bounded example. If the before and after samples use different moments, the product is asking the user to infer too much. A quieter section in one clip can appear better even when the processing change was minor. Matching the segment removes that ambiguity and keeps the decision grounded in what the user actually heard. Put compatibility before expectation Compatibility belongs near the beginning of the workflow, before

Zack Bartel has developed Tether, an open-source project designed to integrate Apple Continuity features with Linux workstations. Tether allows users to send iMessages, sync clipboards, and view iOS notifications directly on Linux. It uses secure local network communication and a custom Bluetooth stack to ensure reliable connectivity and robust security in cross-platform interactions. By Olimpiu Pop

A Linux safety certification is a statement about one defined software configuration running on named hardware, assessed by a named body. It is not a statement about the Linux kernel, and it does not give your item its integrity level. The document describing how a component like the kernel enters an ISO 26262 argument at all is ISO/PAS 8926:2024, published on 29 January 2024, which moves the question away from code quality and towards classification, complexity and evidence. Red Hat's In-Vehicle Operating System is the clearest public example: certified by exida against ISO 26262 Edition 2 (2018) as a Safety Element out of Context at ASIL-B, with Renesas naming the R-Car S4 as the first platform to be certified. If you build vehicle software on Linux, a supplier will at some point hand you a claim that sounds decisive: this platform is certified. The engineer who has to integrate it then finds the claim carries almost no information on its own. A Linux safety certification is bounded by a configuration, a set of assumptions, a hardware list and an assessor. This article explains where those bounds come from, what changed in 2024, and what to ask before accepting such a claim into your own safety case. Why the kernel cannot be qualified Functional safety standards assume a particular kind of software. A classic safety component is written against a complete requirements specification, each requirement traced to a design element, to code and to a test, with structural coverage evidence at the end. That is workable for tens of thousands of lines written by one team for one purpose. The Linux kernel is not that: tens of millions of lines, contributed by thousands of people who never wrote a requirements specification for the automotive context, changing on a nine-week cadence. An earlier article here, Safety-Critical Linux: What Certifying It Actually Takes , sets out how a safety argument is assembled around Linux. This goes a level below it: by what defined mechanism

TL;DR — On a MSI Stealth A16 AI+ (Ryzen AI 9 365, XDNA2 NPU) running Arch, I got OpenAI's whisper-large-v3-turbo transcribing on the NPU — not the CPU, not the GPU — at RTF ≈ 0.18 (a 30 s clip in ~5.2 s) for roughly a tenth of the energy the same job costs on the CPU, plus an LLM answering on the same NPU through an OpenAI-compatible API. The whole path is local and offline. This is the write-up of the driver stack, the one real gotcha (memlock), and the runtime that made it a 20-minute job instead of a weekend. Why this is worth writing down AMD's "Ryzen AI" NPU (the XDNA / XDNA2 block in Phoenix / Hawk Point / Strix Point laptops) is marketed almost entirely around Windows: the Ryzen AI SDK, the ONNX Runtime VitisAI execution provider, Lemonade, and the demos all assume you're on Windows with the official stack. On Linux the picture in early 2026 is better than most people think — the NPU driver has been in the mainline kernel as amdxdna since 6.14 — but the "load a real model and run it" story still isn't well documented. Here's what actually worked, end to end. The hardware Part Detail Laptop MSI Stealth A16 AI+ A3HVGG APU AMD Ryzen AI 9 365 (Strix Point) NPU XDNA2, 8 columns, exposed as /dev/accel/accel0 NPU firmware 1.1.2.64 Kernel 7.1.9-arch1 ( amdxdna in-tree) OS Omarchy (Arch Linux) AMD quotes the Strix Point NPU at up to 50 TOPS, INT8 . 1. The driver stack Three pieces have to be in place before any runtime can touch the NPU: amdxdna — the kernel driver. In-tree from Linux 6.14; it's what creates /dev/accel/accel0 . Check it's bound: $ ls /dev/accel/ accel0 $ dmesg | grep -i amdxdna XRT (Xilinx/AMD Runtime) + the xrt-plugin-amdxdna shim. XRT is the userspace API; the plugin teaches it about the XDNA device. On Arch both are in extra : $ sudo pacman -S xrt xrt-plugin-amdxdna $ xrt-smi examine ... XRT Version : 2.21.75 NPU Firmware Version : 1.1.2.64 Device(s) Present |BDF |Name | |----------------|--------------| |[0000:66:00.1] |RyzenAI-npu4 | You want a D

The most useful thing my home server taught me was not how to install another Docker container. It was how quickly a problem stops belonging to one tidy layer. A service can be running while DNS is wrong. Plex can work while the machine doing the transcoding cannot reach the storage. A reverse proxy can be configured correctly while the network around it is a mess. When it is your own server and you actually want to use it, those boundaries become your problem. That is very different from the way many application-focused software-engineering jobs feel. You can spend years building applications without having to join Linux, storage, DNS, HTTPS and networking together yourself. The experiments that kept getting turned off Around the start of 2020, I got a Raspberry Pi and repeatedly installed Raspbian or Debian on it. I would add Sonarr, Radarr, maybe Prowlarr, a torrent client and Plex. Sometimes Pi-hole joined them. There was no reverse proxy and I was not putting my own domains behind it. It was primitive, and I learnt something each time, but it never stuck, right? I would decide to play with it and eventually turn it off again. The Pi proved that I could run these services. It did not give me infrastructure I depended on. That changed in summer 2024. I had an old i5 desktop lying around, knew it worked and could connect drives to it easily. Why the hell not? I installed OpenMediaVault and spent the next two or three months building the setup out. Docker-managed services were joined by Traefik as a reverse proxy, Tailscale , proper DNS and network sharing. The useful result was a repeatable path for a new service. I could put it behind HTTPS and decide whether it should be public or only reachable inside my network. The machine was no longer an experiment waiting to be unplugged. A second machine made the lessons real I also bought a separate OptiPlex with 4 GB of RAM and installed Debian. Its main job was Plex Pass transcoding, reading media over the network from

1. How this project started? I'm going to be honest, it's been ages since I have written something without the use of AI to fix my writing. English is not my first language so please bear with me! With the rapid rise of AI, I felt that I have been losing passion for what I used to love at some point: learning . Nowadays, we can quickly solve most of our problems with the use of AI, often times, not even reviewing if it correct or not. That's why I decided to take some time daily to learn something new without or minimal use of AI. The first step is deciding, what should I try to learn first? Well, it was quiet easy to find out what. If you are into Linux, you have probably heard of Omarchy at this point. Like it or not, there's no deny that it's getting more popular among developers. So, why not try to build a decent looking Arch workspace? Before continuing, I would like to mention that this is not a guide. There are lot of resources online that teaches you how to install Archlinux and other packages. 2. Why Archlinux? Archlinux has -or had- the reputation of being difficult to get started with. Most of us are used to booting into a nice-looking, functional operating system. Although I have some Linux knowledge, I wanted to have a better understanding of what it takes to have a decent workspace. 3. Installing Archlinux The first step is actually installing Arch on my device. The device I'm going to use is my trusty built PC that I currently use exclusively for gaming. There are a few things to consider before jumping into installing Arch: My PC has an Nvidia RTX 5050 and AMD Ryzen 5 CPU. Need dual boot to switch between Windows 11 and Archlinux. I don't want to change the BIOS options repeatively. With this in mind, I quickly created a bootable USB using RUFUS . 3.1. Booting the USB If you are a Windows 11 user and have dual boot, you may know that Windows requires Windows Secure Boot. In order to boot another operation system, you'll need to change your Secure Boo

A syndication job noticed before I did A scheduled task publishes one blog post a day to a developer community. It fetches the article from my own site, converts it, and posts it. At 10:00 it failed four times with this: Server error '521 <none>' for url 'https://neuragrowth.co/blog/schema-grammar-ceiling/' 521 is Cloudflare saying the origin server did not answer. So the interesting failure was not in the syndication job at all. My whole site was down, and had been for over three hours by then. The server itself was fine: four days of uptime, load under 0.2, disk at eight percent. But systemctl is-active nginx said failed , and nothing was listening on 80 or 443. nginx resolves your upstreams before it starts The journal had the whole thing in three lines: 06:49:54 systemd[1]: Stopping nginx.service... 06:49:54 nginx[36027]: [emerg] host not found in upstream "example-backend.tld" in /etc/nginx/sites-enabled/site:104 06:49:54 nginx[36027]: nginx: configuration file test failed Line 104 was a small proxy I had added months earlier so the public site could forward one form endpoint to a backend on a different host without revealing its name: location = /api/lead-capture { proxy_pass https://example-backend.tld/api/lead-capture ; proxy_ssl_server_name on ; proxy_set_header Host example-backend.tld ; } When proxy_pass contains a literal hostname, nginx resolves it while parsing the configuration , and treats failure as a fatal config error. That resolution happens inside ExecStartPre=/usr/sbin/nginx -t , so a name it cannot look up means the unit never starts. The config was not wrong. It was valid before the restart and valid after, and nginx -t passed by hand seven hours later. It was invalid for about one second. Why DNS was gone for exactly that instant Ten seconds of journal, reconstructed: 06:49:44 apt-daily-upgrade.service starts 06:49:53 "Reexecution requested ... (unit apt-daily-upgrade.service)" 06:49:53 systemd reexecuting (it had just upgraded itself) 06:49

Debian voted to allow developers to use AI tools in their contributions to the Linux distribution's "development, maintenance, [and] documentation." The new policy on AI acknowledges that "responsible" use of AI can improve developers' productivity, and goes on to say, "generative AI is neither exempt from nor subject to special rules beyond the standards already […]

In this episode, Scott Jenson, a veteran UX designer known for his work on the Macintosh, Google Maps, and Chrome examines the long-term stagnation of desktop operating systems and the limitations of current mobile and cloud-centric models. By Scott Jenson

Every self-hosted project I run starts the same way: a brand new VPS and about twenty minutes of setup before I install a single application. That twenty minutes is what separates "my server" from "someone else's crypto miner." A fresh box with a public IP starts getting probed within minutes, and the default configuration on most images is built for convenience, not safety. This is the secure baseline I set up on every new server, before Docker, before n8n, before anything else. It is also the starting point our production n8n guide assumes you already have. Every command below was checked against current Ubuntu LTS documentation, and I flag the parts that genuinely need a real server to verify. Key takeaways Never do daily work as root. Create a sudo user and log in as that instead. Use an SSH key and turn password login off, but only after you confirm the key works. Deny everything at the firewall by default, then open only the ports you actually use. Turn on automatic security updates so patches land while you sleep. If you plan to run Docker, remember that published ports skip UFW. Bind them to 127.0.0.1 . Prerequisites A VPS running a current Ubuntu LTS. Both 24.04 "Noble Numbat" and 26.04 "Resolute Raccoon" work well. I run long-lived boxes on Hostinger VPS hosting , which is also what powers the n8n guide. An SSH key pair on your own machine. If you do not have one yet, Step 3 creates it. A terminal, and a note of your provider's recovery console. Most hosts, Hostinger included, give you a browser based console in their control panel. That is your way back in if you ever lock yourself out, so find it before you start. Disclosure: some links in this guide, including the Hostinger link above, are referral or affiliate links. If you sign up through them we may earn account credit or a commission, at no extra cost to you. We only point at tools we actually run. Step 1: Log in and update the system Right after the server boots, log in with the credentials your pr

Hey all 👋 Last episode a power cut exposed an uncomfortable fact: my cluster's entire memory lived in one SQLite-flavored database, on one laptop, bound to one Wi-Fi address, guarded by one aging battery. Four single points of failure in a trench coat. The fix isn't making that database unkillable. The fix is making it unimportant . If every manifest lives in git and something reconciles the cluster against git continuously, then "the datastore died" stops being a tragedy and becomes a reboot with extra steps. So: Flux . Here's the setup, and the four ways I face-planted installing it. 🗂️ The Shape of the Repo clusters/homelab/ flux-system/ <- Flux writes this at bootstrap; hands off infrastructure.yaml <- points at infrastructure/ apps.yaml <- points at apps/ infrastructure/ controllers/ <- Longhorn + Envoy Gateway HelmReleases configs/ <- GatewayClass, Gateway, StorageClasses apps/homelab/ airflow/ <- the actual point of all this Three Flux Kustomizations, chained: infra-controllers → infra-configs → apps , via dependsOn . That chaining is not decoration. My GatewayClass can't exist until Envoy Gateway's CRDs exist, and the CRDs arrive with the controller's Helm chart. Without dependsOn , Flux sprints ahead, tries to create a GatewayClass into a cluster that's never heard of GatewayClasses, and fails with the enthusiasm of a golden retriever running into a glass door. dependsOn plus wait: true turns that into: install controllers, wait until healthy , then configs, then apps. Boring. Sequential. Correct. The three great virtues. 🔑 Sidequest 1: The Token Bureaucracy flux bootstrap github needs a GitHub token, and the docs-diving summary is: Classic PAT: repo scope. Needed if Flux should create the repo. Fine-grained PAT (pre-created repo): Contents read/write, Metadata read, and — the one everyone misses — Administration read/write , because Flux installs an SSH deploy key on the repo, and deploy keys are an admin operation. Here's the nice part: the deploy key is