Heute habe ich meinen Filemanager, an dem ich seit einem Jahr arbeite, als Development Snapshot öffentlich gestellt. Ich hoffe, dass er auf Zustimmung trifft und weitere Entwickler zum Mitmachen begeistern kann.

NEF bedeutet „Noch Ein Filemanager“ und ich habe ihn geschrieben, weil ich unter Linux einen Filemanager vermisse, den ich so gestalten kann, wie ich möchte, ohne einen zehnten Norton-Commander-Klon zu schaffen.

Er befindet sich noch im Alpha-Status, ist aber an sich schon gut benutzbar. Allerdings existiert noch kein „make install“ oder sonstige Desktop-Integration, aber das ist auch nur eine Frage der Zeit.

Wer ihn ausprobieren möchte, kann ihn gerne aus dem Git-Repository auschecken und starten. Die nötigen Schritte stehen in der README.

Viel Spaß beim Testen.

Screenshots

NEF-Filemanager Einzelansicht

NEF-Filemanager Dual-Lister

NEF-Filemanager Multi-Lister

Links

• NEF-Filemanager Git-Repository bei codeberg.org

Linux's default scheduler (CFS/EEVDF, depending on kernel version and configuration) is a strong general-purpose choice. Still, a single scheduler cannot be optimal for every workload: interactive desktops, low-latency audio, latency-sensitive gaming, build servers, and throughput-heavy batch systems often want different trade-offs.

The sched_ext framework (often referred to as SCX) changes the game: it allows you to run a scheduler implemented as an eBPF program. The scx-tools project ships tooling and reference schedulers; scx-scheds is commonly used to describe the set of sched_ext scheduler implementations you can run and experiment with.

This article focuses on Arch Linux: what you gain with SCX schedulers, what options exist, and how to install, configure, and enable them as a service.

Why use an SCX scheduler? (Benefits)

1) Workload-specific tuning without patching the kernel

With sched_ext, you can switch schedulers (or update them) without maintaining kernel patch sets. In many cases you can:

• keep your standard Arch kernel (as long as it supports sched_ext),
• install a userspace scheduler binary,
• enable/disable it like any other service.

2) Faster iteration and experimentation

Schedulers can be developed and tuned much faster than traditional in-kernel scheduling code. This makes SCX attractive for:

• desktop responsiveness experiments,
• new heuristics for heterogeneous CPUs,
• latency reduction under load,
• research and benchmarking.

3) Better latency / responsiveness for certain setups

Many users try SCX schedulers for perceptible improvements in:

• UI smoothness during compilation or heavy background tasks,
• gaming frame-time consistency under load,
• audio production (glitch resistance),
• interactive shells and editors.

Actual results vary by kernel, CPU topology, power settings, and the chosen scheduler.

4) Observability and control via eBPF

The eBPF ecosystem makes it practical to introspect behavior and iterate on policies. Some schedulers expose parameters, logging, or statistics that can be monitored.

What options do you have? (Schedulers and approaches)

There is no single “best” SCX scheduler. Instead, pick a policy that matches your goals.

Common categories

• Balanced / general-purpose: aims to be a drop-in alternative focused on smoothness while staying robust across workloads.
• Latency-focused: prioritizes interactive tasks and wake-up latencies, often at some throughput cost.
• Throughput / batch: focuses on maximizing overall throughput for build servers and compute-heavy workloads.
• Experimental / research: meant for exploration, not necessarily daily-driver stability.

A quick “which one should I try first?” guide

Use this as a starting point, not as a universal truth:

Examples you will likely encounter

Depending on your installed package version, binaries may include schedulers such as:

• scx_rusty (often considered a good “daily driver” starting point)
• scx_lavd (commonly discussed for latency-focused behavior)
• scx_simple (often used for testing, debugging, or as references)

If your build includes scx_bpfland, it is often positioned as a desktop/gaming-oriented option. Treat it like any other scheduler: validate stability and benchmark on your own hardware.

Names and available schedulers differ by release. On your system, list what is installed:

ls -1 /usr/bin/scx_* 2>/dev/null
# or with scx-tools installed
scxctl list

If you see a loader or manager tool in your package (some releases include helpers), prefer that for starting/stopping schedulers. Otherwise, you can run a scheduler binary directly.

Prerequisites on Arch Linux

1) Kernel support for sched_ext

You need a kernel that includes sched_ext and has it enabled.

In practice, this usually means running a recent Arch kernel (or an alternative kernel package) that includes sched_ext. If sched_ext is missing, installing newer kernels (or trying an alternative kernel flavour) is the first step.

Quick checks:

uname -r

If CONFIG_IKCONFIG_PROC is enabled, you can check the running kernel config:

zgrep -E 'CONFIG_SCHED_CLASS_EXT|CONFIG_SCHED_EXT' /proc/config.gz

If that file does not exist on your system, check your kernel’s config in /usr/lib/modules/$(uname -r)/build/.config (if available) or consult the kernel package documentation.

2) eBPF capabilities

Schedulers typically need elevated privileges to load eBPF programs. Expect to run them as root via systemd.

3) Keep a fallback plan

If you are experimenting on a production machine, have a way to revert quickly:

• keep SSH access,
• keep a known-good kernel in the bootloader,
• know how to disable the service from a TTY.

Installation on Arch Linux

Option A: Install from official repos (if available)

Package availability changes over time. Start by searching:

pacman -Ss scx

If you find scx-tools / scx-scheds packages in your configured repositories, install them with pacman -S ….

Option B: Install from the AUR

If packages are not in the official repos, they are commonly provided via the AUR (often as -git variants).

Example using an AUR helper:

yay -S scx-tools-git scx-scheds-git

If you do not use an AUR helper, build using makepkg in the usual Arch way.

If you build from source, expect typical eBPF build dependencies (compiler toolchain and libbpf-related components). Package recipes usually document the exact list for Arch.

Verify installation

command -v scx_rusty || true
ls -1 /usr/bin/scx_* 2>/dev/null

Configuration and setup

SCX schedulers usually accept command-line flags for tuning. Because these flags can change by version, always consult the built-in help:

scx_rusty --help

A practical approach: start with defaults

1) Start one scheduler manually (root):

sudo scx_rusty

2) Use your system normally for a while (desktop use, compile something, game, etc.).

3) If it feels good and stable, move to a systemd service.

Tuning

Schedulers differ in what they expose:

• latency/throughput knobs
• CPU selection, NUMA or SMT considerations
• logging/telemetry levels

Treat tuning like performance engineering:

• change one setting at a time,
• benchmark under repeatable conditions,
• keep notes of kernel version, microcode, power governor, and BIOS settings.

Enable as a systemd service (recommended)

The cleanest method on Arch is a dedicated service that starts your chosen scheduler at boot.

Option A: Use scx_loader.service (preferred when available)

Many Arch packages ship scx-loader, a small manager that starts the configured sched_ext scheduler for you. When present, it is usually the easiest and most maintainable approach.

1) Understand the configuration search order

scx_loader typically looks for a configuration file in the following locations (first match wins):

1. /etc/scx_loader/config.toml
2. /etc/scx_loader.toml
3. /usr/share/scx_loader/config.toml
4. /usr/share/scx_loader.toml

On Arch, a vendor example (or an empty placeholder) is often installed under /usr/share/scx_loader/. Do not edit vendor files; create your own config under /etc/.

Useful command:

# Find packaged examples and paths
pacman -Ql scx-tools | grep -E 'scx_loader|config\.toml'

2) Create a minimal config

Create /etc/scx_loader/config.toml and start with a conservative scheduler choice. The exact schema can change; always verify against upstream documentation.

Upstream configuration reference:

• https://github.com/sched-ext/scx-loader/blob/main/crates/scx_loader/configuration.md

3) Start and enable the service

sudo systemctl enable --now scx_loader.service

4) Verify status and logs

systemctl status scx_loader.service
journalctl -u scx_loader.service -b

5) Disable (fallback)

sudo systemctl disable --now scx_loader.service

Option B: Run a scheduler binary directly (simple but less flexible)

If you do not have scx_loader, you can create a small systemd unit that runs a scheduler binary (for example, scx_rusty) with your desired flags.

For general systemd background on Arch, see:

• https://wiki.archlinux.org/title/systemd

Benchmarking: how to measure improvements

Scheduler changes can improve “feel” (responsiveness) while leaving traditional throughput benchmarks unchanged—or vice versa. Use a mix of metrics.

Recommended tools

• schbench (scheduler benchmark focused on latency)
• stress-ng (load generation, includes latency-related tests)
• perf and bpftrace (observability)
• Phoronix Test Suite (repeatable macro benchmarks)

Examples:

# Example: install benchmarking tools
sudo pacman -S --needed perf stress-ng

If schbench is not packaged in your repos, look for it in the AUR.

A simple methodology

1) Pick a baseline (default scheduler; disable SCX service). 2) Run 3–5 iterations of your chosen tests. 3) Enable the SCX scheduler. 4) Repeat the same tests. 5) Compare medians (not best runs).

What to watch

• frame-time consistency (for games)
• audio XRUNs/glitches (for pro audio)
• wake-up latency and tail latencies under load
• compile time vs interactive responsiveness trade-off

Troubleshooting

Service fails to start

• Check journalctl -u scx_loader.service -b for verifier errors or missing capabilities.
• Verify you are running a kernel with sched_ext support.
• Remove systemd hardening temporarily to rule out permission issues.

System feels worse

• Switch back to the default scheduler (stop the service).
• Try a different SCX scheduler (balanced vs latency-focused).
• Re-test with CPU governor settings fixed (e.g., avoid mixed power profiles during benchmarking).

External links (docs, code, discussion, and benchmarks)

• sched_ext / SCX upstream project (code and documentation):
  • https://github.com/sched-ext/scx
• scx-tools (repository entry points and tooling live in the same upstream org):
  • https://github.com/sched-ext
• Arch Wiki (systemd basics and service management):
  • https://wiki.archlinux.org/title/systemd
• Linux kernel scheduler documentation (general background):
  • https://docs.kernel.org/scheduler/index.html
• eBPF documentation (background and tooling):
  • https://docs.kernel.org/bpf/index.html
• Benchmarking and comparisons (independent sources):
  • https://www.phoronix.com/
  • https://www.phoronix.com/search/scx
  • https://www.phoronix.com/search/sched_ext
  • https://openbenchmarking.org/
  • https://flightlesssomething.ambrosia.one/
• Community discussion and background (useful for understanding trade-offs):
  • https://lwn.net/Search/DoSearch?words=sched_ext
  • https://wiki.cachyos.org/de/configuration/sched-ext/

Conclusion

SCX schedulers (sched_ext) give Arch Linux users a practical way to tune scheduling policy to their workload—whether your priority is desktop responsiveness, lower latency under load, or throughput for batch tasks. Start with a conservative scheduler, validate stability, enable it via scx_loader.service when available, and benchmark methodically before drawing conclusions.