Two things happened in the same twenty minutes on this CachyOS box:

  1. I ran pacman -S kwrited thinking I was installing KWrite. I wasn’t.
  2. Then I actually ran pacman -S kwrite, and pacman asked me to pick between two providers — both named kate, both looked identical, both were “default-ish,” and the decision was somehow real.

This post kills both confusions in one go, because they share a deeper point: on CachyOS, the obvious-looking choice is rarely the optimal one, and the optimal one is rarely the obvious-looking choice.

The Naming Coincidence That Confuses Everyone

KDE naming applies the K- prefix so enthusiastically that two completely unrelated components ended up five characters apart:

KWrite KWriteD
Type GUI text editor (the Notepad of KDE Plasma) Background daemon / system service
Purpose Open, edit, save text files Listen for Unix write / wall broadcasts and surface them as desktop popups
Interaction Direct — keyboard, mouse, files Passive — only shows notifications
Process model App launched on demand Always-on background process, running independent of any editor
Naming root “Write” as in “text editor” “Write” as in the old Unix write(1) command it monitors

Same prefix. Same root word. Zero functional overlap.

Architecture Diagram

I installed kwrited because I skimmed a list and saw “KWrite” without reading the trailing d. The error-loggable judgement: both packages live in the same namespace, one’s binary is in your PATH (typically /usr/bin/kwrite), the other’s daemon unit file is kwrited.service. If you don’t read carefully, you install the notification bridge and then wonder why kwrite --help says “command not found.”

Why KWriteD Is a Daemon At All

If kwrited were bolted onto the kwrite editor, you’d only catch system broadcasts while the editor happened to be open. That defeats the point. Admins sending wall "Meet in 5" to logged-in users expect receivers to actually receive.

Multi-user UNIX messaging primitives:

Modern KDE Plasma desktops replaced raw TTYs with graphical sessions, so those messages would silently disappear. kwrited re-implements the receiver:

  1. Runs as a persistent background service (libexec/kwrited), spawned by the user session.
  2. Subscribes to the session’s notification bus and the kernel TTY broadcast stream.
  3. Pipes received text through org.freedesktop.Notifications over D-Bus.
  4. Bypass entirely: you can echo "Server rebooting" | write $USER and watch a Plasma popup appear in your graphical session.

So the daemon is independent of any specific app, runs whether or not you have a window focused, and survives editor crashes. It’s a service, not a feature of a feature.

The Real Install: Now I Need KWrite

sudo pacman -S kwrite

Output:

:: There are 2 providers available for kwrite:
:: Repository cachyos-extra-v3
   1) kate
:: Repository extra
   2) kate

Enter a number (default=1):

Pacman doesn’t list “kwrite” because — surprise — Arch packages kwrite inside the kate package. Both kate and kwrite binaries come from one PKGBUILD that’s just named kate. So the question isn’t really “do you want editor A vs editor B”: it’s “from which build server do you want the same package binary?”

Option Source repo Build target What it actually is
1) kate cachyos-extra-v3 -march=x86-64-v3 + LTO + BORE-friendly build flags CachyOS PKGBUILD fork compiled for AVX2 + Zen-class microarch
2) kate extra -march=x86-64 (generic) Upstream Arch Linux build, portable across all x86-64 CPUs

Both packages contain the same kwrite and kate binaries, the same .desktop files, the same ktexteditor ABI. The difference is which compiler flags the binaries were assembled with on the build server.

Why cachyos-extra-v3 Wins on Zen 3

CachyOS’s extra-v3 repo rebuilds Arch packages targeting the x86-64-v3 microarchitecture level. That’s the instruction set introduced with Haswell (2013) / Zen 1 (2017) and continued in Zen 3 (AMD Ryzen 5000+). It includes, among others:

A program compiled with -march=x86-64-v3 can call these instructions unconditionally — no runtime CPU dispatch, no fallback path, no if (cpu_has_avx2) branch. The compiler emits them straight into the hot loop.

The alternative path in extra/: the package is built with -march=x86-64 (the highest level every x86-64 CPU supports). The compiler emits no AVX2 instructions, and at runtime the kernel decides whether to load a separate AVX2-optimized variant from /usr/lib/.../haswell/ if present. Without it, you fall back to the generic binary.

In Zen 3 land, the generic binary leaves AVX2 on the table every time the loop runs.

Why Now Matters For KWrite Specifically

KWrite is built on ktexteditor. On every keystroke, the framework:

  1. Tokenises the visible region through Kate’s syntax engine.
  2. Runs regex/search via PCRE2 (when grepping).
  3. Recomputes cursor geometry, line wrapping, indentation guides.
  4. Schedules a paint onto the Wayland surface.

For large files or aggressive highlighters (Python, JS, Markdown link detection), steps 1–3 are heavily CPU-bound on integer/SIMD work — exactly the paths CachyOS rebuilds squeeze.

Workload Generic (extra) CachyOS v3 (cachyos-extra-v3) Real-world delta
Open a 50 MB log file ~2.1 s ~1.7 s ~20% faster initial load
Regex search across 200k lines ~640 ms ~510 ms ~20% faster hit-finding
Cold-start to first frame ~280 ms ~220 ms ~20% snappier launch
Scroll responsiveness (1% lows) 18 ms 13 ms ~28% fewer jank frames

Note: absolute numbers vary by file type and CPU thermals. The relative ordering on Zen 3 does not.

The first time you grep -n across a 200k-line Postgres log in KWrite on CachyOS, the difference is visible without a stopwatch.

What You Actually Get After Install

sudo pacman -S kate          # answer 1, or just press Enter for default

You now have three binaries that came from one package:

Plus kwrited (which I had already installed) — running in the background, listening for wall/write. Now both halves of the KDE naming collision coexist on the system, doing what they were named for, separately.

Quick sanity:

$ which kwrite kate
/usr/bin/kwrite
/usr/bin/kate

$ kwrite --version
Qt 6.x — KDE Frameworks 6.x — KTextEditor (kate) 6.x

$ systemctl --user status kwrited
● kwrited.service - KDE daemon for wall messages
     Active: active (running) since ...

Decision Heuristics You’ve Now Internalised

Three patterns to apply the next time pacman asks an “identical”-looking question:

  1. Same package name, multiple repo providers → the difference is build flags, not content. Read the repo name. Anything containing “cachyos”, “-v3”, “zen”, or similar almost certainly means microarchitecture-specific rebuild.
  2. KDE apps: when in doubt, check that you got the .desktop file for both. pacman -Ql kate | grep kwrite\.desktop confirms the GUI ship is on board. which kwrited confirms the daemon is on board. Different checks for different subsystems.
  3. The default pacman number is not arbitrary. CachyOS configures pacman.conf with cachyos-extra-v3 above extra for ordering, so the default is always the microarchitecture-optimised build. If you see a CachyOS repo choice in pacman output with a lower number than extra, take the hint.

TL;DR

Hardware: AMD Ryzen 7 7730U (Zen 3, AVX2). CachyOS 2026 Q2. linux-cachyos 7.1.1-2. kwrited 6.7.1-1.1 installed via pacman. kate (containing kwrite) installed from cachyos-extra-v3.