Abstract:

This article serves as a detailed tutorial for creating a basic service in the GNU Guix operating system, using the keyboard remapping tool kmonad as a practical example. The author documents the process of defining a new service-type, which involves researching Guix documentation, analyzing the source code of an existing service (wesnothd) for a template, and writing the necessary Scheme code. Key steps include extending the account-service-type to create a dedicated system user for the daemon and extending the shepherd-root-service-type to manage the process's lifecycle (start, stop, dependencies, and logging) via the Shepherd init system. The final code is packaged into a reusable module, and the article demonstrates how to integrate this new service into the main system configuration file.

A Guide to Writing a GNU Guix Service for kmonad

• Goal: The primary objective is to create a proper GNU Guix service to automatically start and manage the kmonad daemon, which is presented as the "right way" and a valuable learning exercise compared to simpler scripting methods.
• Initial Research: The process begins by exploring the official Guix documentation. The author identifies the concept of services and service-type but finds the official examples complex, leading to a search for a simpler, real-world example to use as a template.
• Finding a Template: The author inspects the wesnothd-service-type (for "The Battle for Wesnoth" server) within the Guix source code. This provides a clear, practical blueprint for defining a new service, its configuration, and its extensions.
• Defining a New Service Type: Following the template, a new kmonad-service-type is created. This involves defining how it "extends" existing system services:
  • Account Service: It extends the account-service-type to create a dedicated, non-login system user (kmonad-daemon) and group, a security best practice for daemons.
  • Shepherd Service: It extends the shepherd-root-service-type to allow the Shepherd init system to manage the daemon. This definition specifies dependencies (udev, user-processes), start/stop commands, the user/group to run as, and a log file location (/var/log/kmonad.log).
• Key Guix Concepts Explained: The tutorial introduces and explains core Guix concepts necessary for the task, including service-extension, G-Expressions (#~ and #$) for embedding low-level build code, and helper functions like make-forkexec-constructor.
• Packaging and Usage: The complete code is packaged into a self-contained Guix module (my services kmonad) for clean integration. The author then shows how to add the service to the operating-system configuration by importing the module and adding (service kmonad-service-type "/path/to/config.kbd") to the list of services.
• A Simpler Alternative: The article briefly mentions that a simple-service might be an easier alternative for basic daemons, potentially avoiding the need to define an entirely new service-type.

Hacker News Discussion Summary

• Sandboxing and Security: Commenters discuss Guix's security model. While the Shepherd init system is lean, Guix provides abstractions for containerization. Its long-term vision is an object-capability model, where services are explicitly given references to resources, which is contrasted with systemd's approach of "locking down" privileges.
• Guix vs. Nix: A significant portion of the discussion compares Guix with Nix.
  • Philosophy: Guix is seen as a "reimagining" of Nix using Scheme, with a stricter FOSS-only policy and the GNU Shepherd init system instead of systemd.
  • Learning Curve: Users agree the learning curve is similar for both, though some find Nix's domain-specific language simpler than Scheme.
  • Flexibility vs. Authority: An interesting tradeoff is noted: NixOS is more flexible, as any module can alter any other. Guix is intentionally more restrictive, adhering to the "principle-of-least-authority" to prevent arbitrary modules from gaining elevated privileges.
• Core Benefit of Guix: The primary benefit of Guix, shared with Nix, is identified as reproducibility—the ability to declare a system configuration and reliably reproduce it on any machine.
• Barrier to Entry: It is pointed out that a working knowledge of the Scheme programming language is a prerequisite for writing Guix configurations, and the concept of service extensions can be confusing for newcomers.