DEV Community: Asher Buk

Why Hyprland on Fedora Needs Vendored Dependencies (0.55.0 Edition)

Asher Buk — Sun, 10 May 2026 11:13:57 +0000

Hyprland 0.55.0 just dropped with a new Lua-based config layer. Cool feature - except it requires Lua 5.5, and Fedora repos still ship Lua 5.4.

I maintain a COPR for Hyprland on Fedora that bundles all hypr-* library dependencies into a single build with zero external COPR deps. This Lua situation is a textbook example of why this approach exists - and why it fits Fedora better.

The Problem

Hyprland was orphaned after F42 (doesn't exist in official repos). On Fedora 43 and 44 the only way to install it is through COPR repositories or building from source.

Most Hyprland COPRs for Fedora follow the traditional approach inherited from solopasha's original repo: every hypr-* library (libaquamarine, libhyprlang, libhyprutils etc.) is packaged as a separate RPM with its own build cycle.

That means when you dnf install hyprland, you pull in 15+ individual packages. Each one is built independently, sometimes days apart. When you dnf upgrade, each updates on its own schedule. Now add Lua 5.5 to the mix.

The Atomic (Reproducible) Build Approach

In my COPR, Lua 5.5 is built from source with -fPIC and linked statically into the Hyprland binary. No new runtime dependency, no conflict with system Lua.

The same isolation principle applies to every hypr-* library. Instead of installing libaquamarine, libhyprlang, libhyprutils etc. as separate RPMs into /usr/lib64/, they're built as shared libraries into a private vendor prefix (/usr/libexec/hyprland/vendor/lib64/) and resolved via RPATH. They never touch system library paths, so there are no conflicts with other packages and no duplicates in dnf repoquery --duplicates.

Why This Matters

With the traditional approach, there's always a window where your system is in an inconsistent state. The maintainer rebuilds aquamarine on Monday, hyprland on Wednesday - between Monday and Wednesday, users who upgraded have a mismatched ABI. The compositor might crash on launch and the user has no idea why.

With vendor-clean builds, the update is atomic. One spec file builds the compositor, hyprlock, hypridle, and all library dependencies together. Everything is compiled against the same versions in the same build. It either all works or none of it ships.

It's the same philosophy behind how Go produces binaries - one static file, all dependencies inside, no dependency hell at runtime.

Where the Traditional Approach Works Fine

On Arch and other rolling release distros where all system libraries stay on the bleeding edge. Hyprland is officially supported on Arch, and AUR packages are built from source on the user's machine - so they link against whatever library versions are already installed. No version mismatch, no frozen dependencies.

The problem is specific to point-release distros like Fedora, where system libraries are pinned to a release version. When a bleeding-edge compositor like Hyprland moves faster than the distro's package set, something has to give. On Arch, the distro keeps up. On Fedora, you need to bring the dependencies with you.

Not a New Idea

This vendor-clean approach is a well-established pattern across the industry.

Go is the most obvious example. go build produces a single statically linked binary with all dependencies compiled in. No shared libraries - deploy one file and it runs. The Go team made this a deliberate design choice, and it's one of the reasons Go dominates in infrastructure tooling.

NixOS solves the same problem differently but with the same goal. Every package is built in isolation with its exact dependency tree, stored in /nix/store/ with a hash-based path. Two versions of the same library coexist without conflict. Hyprland is officially supported on NixOS precisely because Nix eliminates dependency hell by design.

Atomic/immutable distros like Fedora Atomic, Universal Blue, and Vanilla OS take yet another approach - the entire OS image is built and tested as a unit, then deployed atomically. No partial upgrades, no inconsistent state.

My COPR applies the same principle at the package level: one build, one atomic unit, all versions locked together. It's close to Nix/Go/Atomic philosophy, but implemented as an RPM spec file for a traditional Fedora install.

Install

sudo dnf copr enable ashbuk/Hyprland-Fedora
sudo dnf install hyprland

# Screen sharing support
sudo dnf install xdg-desktop-portal-hyprland

Source and spec files: github.com/AshBuk/Hyprland-Fedora

Vendor-clean Hyprland package for Fedora 43/44, currently serving 2,700+ users.

In the Age of AI, People Still Type With Their Hands

Asher Buk — Wed, 06 May 2026 17:58:05 +0000

About two months ago I submitted my typing trainer FingerGo to Flathub. I was genuinely curious - do people still type with their hands in the age of AI? Do they still train touch typing, or are they satisfied with a speech-to-text button and the occasional lazy two-finger hunt for the remaining keys? :D

Turns out - yes! You'd think a niche tool for desktop Linux wouldn't get much traction, but so far it's pulling 1,000+ installs per month.

I originally built this for myself. I got a split keyboard and started learning touch typing. As a developer, you need to type, stay in the flow, and not break focus. Also - my wrists started hurting. So I switched to a split keyboard and invested in proper touch typing. Within a few months I hit a comfortable 60 WPM on plain text and ~40 WPM coding. That's a solid average for touch typists - and pretty much unreachable for "hunters." I consider this a true hard skill and one of the best investments for anyone spending most of their day at a computer.

According to FingerGo's Flathub, the top countries interested in touch typing training are:

USA (largest desktop Linux user base), Germany (historically strong Linux community plus a culture of privacy and open source), India (growing pool of developers on Linux), and Brazil (active FOSS community).

System-Wide STT for Linux: Speak to AI

Asher Buk — Mon, 16 Mar 2026 14:08:34 +0000

The Linux speech-to-text landscape has grown a lot — these days you'll find a microphone icon and voice input in pretty much every chat app and code editor. But just a year ago? Almost nothing had decent STT support on Linux.

That's when I started thinking about a proper solution — and solved the problem at the system level. Speak to AI is a voice "keyboard" for any window (chat, terminal, editor, etc.) that works natively and fast. The core workflow is simple: speak → text appears wherever your cursor is. Beyond that, it supports scripts and integrations — next step is turning it into an STT hub for smart home and other automations.

Works on any Linux distro and any DE. No Electron, no browser tabs, no cloud dependencies — just a lightweight Go binary with whisper.cpp doing all the heavy lifting locally. Privacy first.

📦 Download from Releases — AppImage, ready to run

Arch Linux (AUR): yay -S speak-to-ai

Fedora (COPR): sudo dnf copr enable ashbuk/speak-to-ai && sudo dnf install speak-to-ai

Software Craftsmanship: The Three Hidden Pillars

Asher Buk — Thu, 15 Jan 2026 16:27:16 +0000

In this post, I want to briefly talk about how your environment (Linux), your hardware (keyboard & touch typing), and your tooling (shortcuts) form the three pillars of Software Craftsmanship.

Let’s be clear: these are not the most important skills for a developer, nor are they the primary way to evaluate a grade. They won’t replace business domain knowledge, solid architectural decisions, or problem-solving abilities. However, "Mastership is not just about WHAT you create, but also HOW you create it." By removing the friction between your mind and the screen, you free up space for pure creativity.

Here are my three pillars:

1. The Environment: Linux

Switching to Linux is more than just changing an OS; it’s a transition from being a "consumer of interfaces" to a "creator of systems." In Linux, the boundary between you and the running code fades away. You start to understand how the file system, processes, and networks actually work just by living in the environment.

For me, moving to Linux was a massive skill bump, even though many friends told me at the start that "the OS doesn't matter." The journey from being afraid of the terminal to confident mastery is incredibly rewarding.

The Rule: Anything you can do in a GUI (and many things you can't) can be done via the terminal—often much faster.
The Base: Terminal skills are "evergreen." They are portable and don't become obsolete when a new fancy app comes out.
The Perks: Native containers, Btrfs snapshots, and total control. Once you go Linux, you’ll only keep Windows around for the games that won't run elsewhere!

2. The Physicality: Split Keyboards & Touch Typing

This is about removing physical bottlenecks. When you don't have to look at your hands, code flows directly from your brain to the editor.

The Health Factor: A split keyboard is about longevity. Avoiding wrist pain is a professional necessity, not a luxury.
Touch Typing vs. "Hunt & Peck": An office "hunter" might peak at 50 WPM, while the average is closer to 20-30 WPM. A decent touch typist easily hits 60–80 WPM, and pros go well beyond 130–160+ WPM.
The Joy: Honestly, the biggest win isn't just speed—it's the feel. You start enjoying the process of typing itself. Even 40-50 WPM for plain text makes work remarkably comfortable.

3. The Tooling: Shortcuts & Flow

Shortcuts are all about the Flow State. Every time you reach for the mouse, you create a micro-interruption in your train of thought.

A quick disclaimer: Don't be a fanatic. If you get frustrated every time you touch a mouse, or if you insist on reading raw Markdown in a terminal just to look "pro"—that’s probably too much. I use VS Code, I don’t mind using the mouse when it makes sense, and I read my emails in a browser. Balance is key.

Bonus: My VS Code Navigation Toolkit

As a bonus, here is a snippet from my personal cheat sheet for VS Code navigation:

Using F-Keys (via Fn layer)

Action	Standard Binding	On Split Keyboard
Go to Definition	`F12`	`Fn + =`
Go to Implementation	`Ctrl + F12`	`Ctrl + Fn + =`
Rename Symbol	`F2`	`Fn + 2`
Next Error/Warning	`F8`	`Fn + 8`

Without F-Keys (The Essentials)

Action	Binding
Go Back	`Alt + ←`
Go Forward	`Alt + →`
Quick Open (File)	`Ctrl + P`
Symbol in File	`Ctrl + Shift + O`
Symbol in Workspace	`Ctrl + T`
Go to Line	`Ctrl + G`
Command Palette	`Ctrl + Shift + P`
Go to Bracket	`Ctrl + Shift + \`

Typical Workflow

Ctrl + P (Open File) → Ctrl + Shift + O (Find Function) → F12 (Go to Definition) → Alt + ← (Go Back).

Useful Additions

Action	Binding
Find in Files	`Ctrl + Shift + F`
Replace in Files	`Ctrl + Shift + H`
Toggle Sidebar	`Ctrl + B`
Toggle Integrated Terminal	Ctrl + `
Split Editor	`Ctrl + \`
Switch Editor Tab	`Ctrl + Tab`
Close Tab	`Ctrl + W`
Quick Fix / Code Action	`Ctrl + .`
Trigger Suggest	`Ctrl + Space`
Parameter Hints	`Ctrl + Shift + Space`

Conclusion

Craftsmanship is a journey. These tools won't make you a Senior developer overnight, but they will make the road there much more enjoyable and efficient.

*What does your "craftsman" setup look like? *

Hyprland 0.53.0 for Fedora

Asher Buk — Thu, 01 Jan 2026 12:57:21 +0000

Hyprland team bumped the version on December 29th. I didn't wait and updated my COPR repo.

After a day of driving, I can confirm: life in 2026 hasn't gotten worse — quite the opposite :)
Happy New Year, by the way! 🎉

Already a user?

The repo has 150 users at the time of posting. If you're among them:

# Refresh metadata
sudo dnf copr enable ashbuk/Hyprland-Fedora --refresh

# Upgrade
sudo dnf upgrade hyprland

Considering Hyprland on Fedora?

See my previous post for details.

Note: this COPR intentionally does not include optional Qt-based GUI helpers (welcome screens, crash dialogs, donation prompts).

Hyprland works perfectly without them. This aligns with my packaging approach: no extra functionality by default — anything missing can be added consciously.

What's Included

Package	Description
`hyprland`	Dynamic tiling Wayland compositor (includes `Hyprland`, `hyprctl`, `hyprpm`, `start-hyprland`)
`xdg-desktop-portal-hyprland`	Portal backend for screen sharing, file dialogs - separate spec

Hyprland includes a small set of upstream-vendored libraries (as shown on the image cover),
with proper $ORIGIN-based RUNPATH. No extra bundling beyond upstream defaults.

If it looks good:

# Enable the repo
sudo dnf copr enable ashbuk/Hyprland-Fedora

# Install core compositor
sudo dnf install hyprland

# Screen sharing support (recommended)
sudo dnf install xdg-desktop-portal-hyprland

Breaking changes ahead

Heads up: 0.53.0 comes with breaking changes — you'll need to update your config syntax.
New features:
🐕‍🦺 start-hyprland watchdog binary for crash recovery
🕸️ hyprwire IPC library for improved hyprctl communication

Review: Hyprland 0.53.0 Release Notes

Feedback or issues are welcome on the GitHub repo.

COPR: ashbuk/Hyprland-Fedora

Screen Sharing for Hyprland on Fedora 43

Asher Buk — Thu, 25 Dec 2025 21:02:45 +0000

I've already published a clean Hyprland build for Fedora 43 — now I've added xdg-desktop-portal-hyprland to the same COPR repository.

The Solution

xdg-desktop-portal-hyprland with proper RUNPATH pointing to the vendored libraries.

Install

sudo dnf copr enable ashbuk/Hyprland-Fedora
sudo dnf install hyprland xdg-desktop-portal-hyprland

Screen sharing tested in Discord, Google Meet, and other WebRTC apps via Firefox and Chrome.

Hyprland 0.52.2+ for Fedora — Clean COPR Build

Asher Buk — Thu, 18 Dec 2025 18:52:07 +0000

I’ve published my own Hyprland COPR repository for Fedora

This is a clean, spec-compliant build, following Fedora RPM best practices:

correct RPM packaging
no duplicated system libraries
Hyprland-specific libraries vendored and isolated under /usr/libexec/hyprland/vendor
proper RUNPATH set at build time (no LD_LIBRARY_PATH hacks)
runtime verified with ldd, readelf, and duplicate checks

Motivation

The motivation was purely practical.

Hyprland 0.45 was available in Fedora 42, but it is not currently shipped in Fedora 43 official repositories; upstream is already at 0.52+.

I needed a newer compositor with fresh Hyprland features to unblock my own experiments — especially around Wayland and Rust-based tooling.

I solved this problem for myself first, and then decided to share the result with the community.

If you care about clean builds, reproducibility, and no ABI conflicts, this repository is for you. (stable recent releases, updated as needed — not automatically tracking every upstream commit)

Proofs / Technical Guarantees

Vendor libraries are isolated and do not shadow system libraries
No parallel-install conflicts (dnf repoquery --duplicates is clean)
Dynamic linking is deterministic and auditable
Build avoids patchelf (which is known to corrupt ELF headers in this case)

All of this can be verified directly from the installed package.

Install from copr.fedorainfracloud.org/coprs/ashbuk/Hyprland-Fedora

sudo dnf copr enable ashbuk/Hyprland-Fedora
sudo dnf install hyprland

re-login and verify:

Hyprland --version
# Hyprland 0.52.2

What's Included

Package	Description
`Hyprland`	Dynamic tiling Wayland compositor
`hyprctl`	CLI control tool
`hyprpm`	Plugin manager

Bundled libraries (in /usr/libexec/hyprland/vendor/):

libaquamarine 0.10.0
libhyprlang 0.6.7
libhyprutils 0.11.0
libhyprcursor 0.1.13
libhyprgraphics 0.4.0

Use what you build, and ship it as open source

Asher Buk — Tue, 09 Dec 2025 11:46:22 +0000

You can use GitHub as a portfolio or a playground for experiments. But real value rarely extends beyond your own boundaries unless you're building something to meet a real need.

The most natural approach? Solve your own problem.

I run Fedora Linux with GNOME and Hyperland as my daily drivers.

But I needed a speech-to-text (STT) tool. An offline, private "voice keyboard" for everyday desktop interaction — chats, terminal, any window.

So I built my own.

It turned out other people needed it too.
Speak to AI is now finding its place in the community.

If there’s one takeaway, it’s this: build tools for yourself.
Solve real problems you actually have, use what you build, and ship it as open source.
Sometimes that’s enough for it to matter to others too.

> Cover image via: https://hear-me.social/@debby/115588019309116671

FingerGo Typing Trainer (don't hunt, type!)

Asher Buk — Wed, 03 Dec 2025 12:39:25 +0000

Still Hunting for Keys on Your Keyboard?

Real skill acquisition requires practice. And if you work on a computer, your practice almost always involves typing!

Believe me — as someone who switched from "hunt-and-peck" typing where you're constantly distracted, glancing at the keyboard, with attention continuously fragmenting, and a low typing speed ceiling (which impacts productivity overall)...

Our brains naturally take the path of least resistance, leading us to adopt incorrect techniques (whether it's keyboard typing or hand positioning when playing a musical instrument). This becomes both a narrow comfort zone and a limitation — sometimes even causing health issues!

If you work on a computer and type frequently (coding, for instance) — don't procrastinate. Start your transition to touch typing. It's a worthwhile investment!

I built a dedicated application for this: FingerGo.

✨ Key Advantages

Cross-platform — Works on Linux, macOS, and Windows
Lightweight binary
Designed to improve typing speed and accuracy with a user-friendly and intuitive interface
Eye-friendly Dark/Light themes with customization options
Hierarchical text/code library (plain text and code samples)
Productivity features: Shortcuts, Zen Mode, keyboard/stats toggle

🎯 Essential Touch-Typing Features

Real-time visual keyboard with finger mapping
Live statistics: WPM, CPM, accuracy, per-key mistakes tracking

🏗️ Tech Stack

┌──────────────────────┐                    ┌────────────────────────┐
│   GUI LAYER          │◄──── Wails ───────►│  INTERNAL LAYER        │
│   HTML/CSS/JS        │      Bridge        │  Go 1.25+              │
└──────────────────────┘                    └────────────────────────┘
         │                                              │
    Event-Driven                                   Repository
         │                                              │
    ┌────┴─────┐                                   ┌────┴─────┐
    │ EventBus │                                   │ Repos    │
    │ (pub/sub)│                                   │ (DI)     │
    └────┬─────┘                                   └────┬─────┘
         │                                              │
    Modular JS                                    Domain Models
                                                         │
                                                         ▼
                                           ┌─────────────────────┐
                                           │ JSON Storage        │
                                           │ ~/.local/share/...  │
                                           └─────────────────────┘

Backend: Go 1.25+ with Repository Pattern (DI)
Bridge: Wails v2 provides Go↔JS communication
Frontend: Vanilla JavaScript (ES6+) with Event-Driven Architecture (pub/sub EventBus)
Storage: JSON files in XDG directories
Platforms: Linux, macOS, Windows

Architecture Dive on ashbuk.hashnode.dev

Try It https://github.com/AshBuk/FingerGo

Start your journey to effortless touch typing! Your future self (and your productivity) will thank you.

Go: Learning Journey Through Algorithms

Asher Buk — Wed, 12 Nov 2025 10:02:30 +0000

I've been working with Node.js and its ecosystem. Now I'm diving deep into Go and I'm getting huge enjoyment from its approach — on one hand, simplicity and no syntactic sugar (you can get diabetes from all the sugar in JS, it's too sweet🙃), on the other hand, incredible capabilities and a greater sense of being "close to hardware."

I decided to document my learning notes in an open repo dsa-golang — specifically, implementations of classic algorithms in Go. This isn't production code, but educational examples with comments and Big O complexity analysis.

Sure, there are hundreds of similar repos... so what's the value in opening another one? 👇

Classic solutions to classic CS problems, without over-engineering or language-specific optimizations, for clear understanding of the algorithm.
Meaningful semantic naming
Aiming for simple and idiomatic Go code
Breakdowns and diagrams right in the comments

What's included:

algorithms/
├── search/
│   ├── Binary
│   ├── Linear
│   ├── Jump
│   ├── BFS Filesystem · BFS Graph Queue
│   └── DFS Filesystem · DFS Graph Recursive · DFS Graph Stack
├── selection/
│   └── Quickselect
└── sort/
    ├── Bubble
    ├── Selection
    ├── Insertion
    ├── Merge
    ├── Quick
    ├── Quick In-Place
    └── Heap

datastructures/
└── graph/
    └── Adjacency List

leetcode/
├── Two Sum #1
├── Merge Sorted Array #88
└── Valid Palindrome #125

interview_exercises/
├── Reverse
├── Duplicates
├── Whitespaces
└── Longest

informatica/
├── Factorial
├── Fibonacci
├── Prime
└── Table

I'm planning to expand it by adding data structures and more LeetCode problems.
If you're also learning Go or algorithms — I'd be happy if this helps you and to hear your feedback!

Repository: github.com/AshBuk/dsa-golang

Building Spark Slider: From AI Startup to Open Source

Asher Buk — Mon, 20 Oct 2025 14:26:41 +0000

Demo: spark-slider.vercel.app

GitHub: github.com/AshBuk/framer-motion-spark-slider

📦 NPM: @ashbuk/spark-slider

When I first shared Spark Slider with friends, the reaction was the same:

“Oh, another React slider.”

That’s not entirely wrong — but it’s not the full story either.

I originally built Spark Slider’s core while working at an AI startup. I wanted something minimal, fast, and visually fluid across laptops, phones, and kiosk screens — without the heavy abstractions of existing libraries like Swiper.

⚙️ What Makes It Different

Framer Motion animations — subtle blur, opacity, and depth transitions create natural focus.
Precision drag & swipe — smooth, momentum-free control.
Accessibility-first — full keyboard navigation and ARIA support.
Pure CSS — no Tailwind dependency, uses svh / svmin viewport units.
Lightweight core — ~12 KB gzipped, works with any React environment.

Under the Hood

The library follows a modular architecture with specialized hooks:

useSparkSlider — state & index logic
useSparkFullscreen — fullscreen mode
useSparkKeyboard — keyboard input
useSparkTransforms — dynamic transforms

All motion and interaction parameters are defined in a single source of truth:

config.ts.

Want to change how it feels? Tweak a few constants — and the slider’s behavior instantly adapts.

💡 A Thought on Open Source

It’s a valid takeaway — when a business model changes, it’s easy to just shelve the work and move on.
But making it open source gives that effort a second life — helping others build, learn, and create.

If this project resonates with you:

⭐ Star it on GitHub

🔗 Read the full deep dive on my AshBuk.hashnode.dev blog

🍒 The Cherry on Top of The Deadline

Asher Buk — Wed, 15 Oct 2025 19:21:12 +0000

“No,” Kenoros corrected him. “We have to learn how to do design more efficiently.”

This quote is from The Deadline by Tom DeMarco — one of my favorite books, and this is one of my favorite takeaways from it. That small printer’s ornament at the bottom of the page is not just decoration — it’s the cherry on top 🍒

In this scene, Mr. Tompkins meets the first programmer of Morovia, Kenoros Aristotle.

They talk about the process of creating software... and Kenoros looks at it not from the perspective of improving processes, but from reduction — how to reduce the amount of work while increasing quality and speed.

The book was written and published in the ’90s, but even in the age of AI this takeaway is absolutely relevant.

Planning software design and crafting specs (digital artifacts) is essential — and discussing them with AI can be both fun and useful.

Later, Kenoros calls high-level design just hand-waving, and suggests doing real design — low-level design — not “on the fly” while coding, but during the planning stage.

Otherwise, iterative refactoring and endless debugging are inevitable...(which, to be honest, they usually are anyway)😄

Obviously, this level of design skill is possible for engineers who have already planned and built many systems.

As for me, to start forming low-level design specs, I usually need to sit down with the code that’s already being developed from the high-level spec.

💭 What about you?

DEV Community: Asher Buk

Why Hyprland on Fedora Needs Vendored Dependencies (0.55.0 Edition)

The Problem

The Atomic (Reproducible) Build Approach

Why This Matters

Where the Traditional Approach Works Fine

Not a New Idea

Install

In the Age of AI, People Still Type With Their Hands

System-Wide STT for Linux: Speak to AI

Software Craftsmanship: The Three Hidden Pillars

1. The Environment: Linux

2. The Physicality: Split Keyboards & Touch Typing

3. The Tooling: Shortcuts & Flow

Bonus: My VS Code Navigation Toolkit

Using F-Keys (via Fn layer)

Without F-Keys (The Essentials)

Typical Workflow

Useful Additions

Conclusion

Hyprland 0.53.0 for Fedora

Already a user?

Considering Hyprland on Fedora?

What's Included

Breaking changes ahead

Screen Sharing for Hyprland on Fedora 43

The Solution

Install

Links

Hyprland 0.52.2+ for Fedora — Clean COPR Build

I’ve published my own Hyprland COPR repository for Fedora

Motivation

Proofs / Technical Guarantees

Install from copr.fedorainfracloud.org/coprs/ashbuk/Hyprland-Fedora

What's Included

Links

Use what you build, and ship it as open source

FingerGo Typing Trainer (don't hunt, type!)

Still Hunting for Keys on Your Keyboard?

✨ Key Advantages

🎯 Essential Touch-Typing Features

🏗️ Tech Stack

Architecture Dive on ashbuk.hashnode.dev

Try It https://github.com/AshBuk/FingerGo

Go: Learning Journey Through Algorithms

What's included:

Building Spark Slider: From AI Startup to Open Source

⚙️ What Makes It Different

Under the Hood

🍒 The Cherry on Top of The Deadline