Learning Artix Linux - Core Concepts & Main Architecture

#Introduction

Episode 2 invites you to view an Artix machine from above: how the kernel, userland, and init system come together as a single whole. You'll understand that Artix isn't just Arch with systemd "cut out," but Arch reorganized with mature replacement components.

The key to reading this series lies in the architecture. If you understand which parts systemd handles on Arch and what replaces them on Artix, then the service commands in episodes 5 through 7 will feel logical. Let's break it down layer by layer.

#System Layer Architecture

#Kernel and Userland from Arch

The innermost part of Artix is exactly like Arch: the Linux kernel with a standard Arch build, the glibc toolchain, and the pacman package manager. The rolling release model is also fully inherited, so you enjoy continuous updates of the latest packages.

Because the userland is the same, applications that run on Arch almost always run on Artix. The difference is only in the lower layers: the init system, device manager, and session manager. This is why migrating from Arch to Artix is relatively smooth, as discussed in episode 18.

#PID 1: Your Init System of Choice

On Arch, process number 1 is systemd. On Artix, PID 1 is the init you choose during installation:

OpenRC  -> /sbin/openrc-init
runit   -> /sbin/runit
s6      -> /sbin/s6-svscan
dinit   -> /sbin/dinit

This init is the parent of all processes. When the system shuts down, the init makes sure services are stopped in the correct order; when a crash happens, the init handles it. Your init choice affects how you write services every day, so get to know it well.

#Components That Replace systemd

#eudev: Device Manager

systemd isn't just an init; it also provides udev for managing devices. On Artix, this role is taken by eudev, a standalone udev implementation that doesn't depend on systemd. When you plug in a USB device or add a disk, eudev creates the device nodes under /dev.

Check that eudev is running:

ps aux | grep eudev | grep -v grep
ls /dev/disk/by-id/

If the eudev daemon is active, the ls /dev/disk/by-id/ command will show the recognized disk symlinks. If there's no output, there's a problem with the device manager that must be fixed promptly.

#elogind: Session and Login Manager

systemd-logind manages login sessions, power management, and access rights for audio and devices. Artix replaces it with elogind — a port of logind that stands alone. Thanks to elogind, applications like volume controls and suspend work normally without systemd.

User groups such as seat and video still exist, so the desktop experience isn't much different from Arch. In episode 8 we'll take advantage of this when setting up access rights for the X server and Wayland.

#D-Bus and Other Basic Services

Many desktop applications depend on D-Bus for inter-process communication. Artix provides D-Bus as usual, started via your chosen init service. There's no behavior change from the application's point of view — only the way the service is run differs.

The pattern is consistent: Artix uses standard GNU/Linux components, then binds them to an init system. There's no longer "one daemon for everything" like systemd; each role is handled by a dedicated, replaceable tool.

#Artix Repository Structure

#base, world, and galaxy

Artix's repositories are arranged to replace Arch's repositories:

[base]
Include = /etc/pacman.d/mirrorlist
 
[world]
Include = /etc/pacman.d/mirrorlist
 
[galaxy]
Include = /etc/pacman.d/mirrorlist

base replaces core, world replaces extra, and galaxy replaces community. Every package in them is built without systemd and ships services for all four inits. Your full repository configuration lives in /etc/pacman.conf.

#Service Subpackages Per Init

When you install a service package like nginx, you'll see a choice of service subpackages:

pacman -Ss nginx-openrc
pacman -Ss nginx-runit
pacman -Ss nginx-s6
pacman -Ss nginx-dinit

Install the subpackage that matches your init. For example, for OpenRC: sudo pacman -S nginx nginx-openrc. This subpackage provides the init script and service configuration, so you don't write them from scratch.

#The AUR and AURIS Repositories

For applications not in the official repos, you can still use the AUR through yay or paru. What sets Artix apart is the addition of AURIS, an init-script repository providing official services for popular AUR applications. Both are covered in depth in episode 15.

#Boot Flow Without systemd

#From BIOS to Login

Understanding the boot flow helps with troubleshooting. The process goes roughly like this: firmware loads the GRUB bootloader, GRUB loads the kernel and initramfs, the kernel runs PID 1 per your chosen init, the init executes boot scripts/services, then enters the default runlevel, which starts networking, the display manager, and other services.

Check which services run at boot with each init's commands:

rc-status                        # OpenRC
sv status /etc/runit/runsvdir/*  # runit
s6-rc -l list                    # s6
dinitctl list                    # dinit

The rc-status output for OpenRC shows services in every runlevel along with their status. For other inits, use the command on the corresponding line. The same pattern applies throughout this series: commands follow your init.

#The Layers in Practice

#Observing Component Relationships

To prove all the layers are working, run three quick checks:

ps -p 1 -o comm= pid= comm=
ls /run/dbus/system_bus_socket
loginctl show-session $(loginctl) 2>/dev/null | head -n 3

The first line shows PID 1, the second proves D-Bus is active, and the third shows elogind managing sessions. If all three are healthy, your base Artix architecture works as expected.

#Connections to the Next Episodes

You'll keep using this architecture map: episode 5 goes deep into OpenRC as an init, episode 6 compares runit, s6, and dinit, episode 7 covers users and networking, and episode 18 explains migrating from systemd. Keep this big picture in your head.

#Conclusion

Episode 2 mapped out Artix's architecture: the Arch kernel and userland with your chosen init as PID 1, eudev as the device manager, elogind as the session manager, D-Bus for communication, and the base, world, galaxy repositories, all free of systemd.

Key takeaways:

• Artix = Arch kernel/userland + a non-systemd init system.
• PID 1 can be openrc-init, runit, s6-svscan, or dinit.
• eudev replaces systemd-udevd; elogind replaces systemd-logind.
• The base, world, galaxy repositories replace core, extra, community.
• Service subpackages per init follow each init's conventions.
• Boot flow: firmware, GRUB, kernel, init, runlevel, services.

In the next episode, episode 3, we'll get hands-on: installing and setting up Artix with basestrap, disk partitioning, mounting, fstab, chroot, and GRUB installation until the system boots for the first time.