标签：#archlinux

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

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

When testing opinionated Linux distributions, the ultimate benchmark isn't how smoothly they run on a workstation with 16 cores and a high-end GPU—it's how gracefully they perform on budget, resource-constrained hardware. Enter Omarchy , the "omakase" Arch-based distribution created by David Heinemeier Hansson (DHH) . Built around the Hyprland tiling window manager and explicitly tailored for modern developer productivity, Omarchy proves that a curated desktop environment doesn't require a heavy computing footprint. Running Omarchy 4.0.0 on an entry-level laptop built around an Intel Celeron N4020 CPU demonstrates how deliberate software curation turns modest hardware into a fast, highly capable development machine. 💻 Hardware & System Overview Below is the environment breakdown from our test run: Category Specification / Details Hardware / PC Model ASUS C204M Processor Intel® Celeron® N4020 (2 cores / 2 threads) @ 2.80 GHz Graphics Integrated Intel UHD Graphics 600 Display 11" Built-in Display (1366x768 @ 60 Hz) RAM Utilization 2.69 GiB / 3.68 GiB (~73% load) Storage / Root 15.66 GiB / 27.10 GiB (~58% used) on Btrfs OS & Kernel Omarchy 4.0.0-1 (Linux Kernel 7.1.8-arch1-3) Compositor Hyprland 0.56.2 (Wayland) 🚀 The Developer Experience: What Makes Omarchy Special Omarchy isn't just an Arch installer with custom dots; it's an opinionated operating system designed to eliminate setup friction and let you write code immediately. 1. Zero-Friction Language Setup via Menus Setting up language runtimes on a fresh Linux install often involves hunting down version managers (like asdf , nvm , or pyenv ), configuring shell initialization scripts, and managing system paths. Omarchy streamlines this entirely. Through its integrated menu system, installing a programming language or developer stack is as simple as launching the system menu, picking a language (Node.js, Ruby, Python, Go, Rust), and hitting Enter. The system automatically installs the necessary version managers, conf

Conteúdo 1. Apresentação - Omarchy 2. Praticidade 3. Agentes de IA 4. Desuso do Mouse 5....

How Linux file permissions actually work under the hood, why symbolic mode is your best friend, and how to stop blindly typing chmod 777. Every Linux engineer has been there. You write a brand-new bash script, try to run it from your terminal, and hit an immediate roadblock: $ ./backup.sh bash: ./backup.sh: Permission denied You open your search engine or ask a chat assistant for help. Within seconds, you find an answer that tells you to run: chmod 777 backup.sh You run the command, hit enter, and the script runs. Problem solved, right? Not quite. In fact, you just opened the digital front door of that file to every single user and background service on the entire operating system. When I started managing Linux servers years ago, permissions felt like a strange puzzle of three-digit math problems. People kept throwing numbers around: 755 for scripts, 644 for web pages, 600 for SSH keys, and 777 whenever something broke and nobody knew why. I memorized those numbers like cheat codes in a video game. But whenever I had to handle a real permission problem, like giving a development team write access to a shared log folder without letting them delete each other's files, memorized numbers fell apart. Here is the secret: you do not need to do binary math or memorize three-digit codes to master Linux permissions. Linux has a built-in, human-readable permission syntax called symbolic mode . Once you understand how Linux looks at files, who owns them, and what actions each permission controls, chmod becomes one of the most intuitive tools in your terminal. Let's break down how it all works step by step. 1. What chmod Actually Does The name chmod stands for change mode . In Unix and Linux systems, every single file and directory has a "mode". That mode determines who is allowed to read it, write to it, or run it. When you run chmod , you are simply updating those access bits inside the Linux filesystem inode. To see the current mode of your files, open any terminal and run ls

I Built a Git Sync Tool for My Obsidian Vault You write notes, you save them, you forget to push to GitHub. Then your laptop dies, and your notes are gone. I built a single Bash script that automates the entire sync workflow, and it works with any Git repo. If you use Obsidian (or any plain-text note-taking system) and sync via Git, you know the drill: write notes, stage changes, commit, fetch, check status, pull, push. Every time. It's 6 repetitive commands that you will inevitably skip until disaster strikes. I got tired of this and built git-sync , a single Bash script that does everything in one go. What It Does git-sync is a terminal-based Git sync tool that: Auto-commits all changes with a timestamp Fetches remote state Detects divergence (ahead/behind) Shows you only the relevant sync options Executes your choice with safety guard rails How It Works Run it from inside any Git repo: ./git-sync Phase 1 - Auto-commit: Staged or unstaged changes are committed automatically with a message like "Last Sync: Jun-12 (Arch)" . The device name is configurable. Phase 2 - Fetch & Detect: It fetches from remote, counts how many commits ahead and behind you are, and categorises the state: ahead, behind, diverged, or in-sync. Phase 3 - Smart Menu: Only relevant options are shown: State Options Ahead only Upload, Sync, Force push, Cancel Behind only Download, Sync, Hard reset, Cancel Diverged All six options Phase 4 - Execute: The chosen action runs with a spinner and status messages. Destructive operations (force push, hard reset) require explicit confirmation. Why It's Useful for Notes Syncing Obsidian + Git is a powerful combo. Your notes are plain markdown, version-controlled, accessible from any device. The friction is the sync ritual. git-sync removes it. Multi-device workflows: I run this on my Arch desktop (DEVICE_NAME="Arch") and my work laptop (DEVICE_NAME="Laptop"). The auto-commit message tells me exactly which machine made each sync, so I can trace conflicts back

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