fairyglade/ly: a TTY display manager that does not need systemd

What Ly replaces, and who it is aimed at

A display manager is the process that presents a login prompt and then starts your session. Most of them assume systemd, or ship a graphical greeter that pulls in a toolkit. Ly takes the other path: it draws an ncurses-like interface directly in a TTY, authenticates through PAM, and hands the session off to the user's shell or xinitrc. The README states the design goal plainly: it is "designed with portability in mind and doesn't require systemd to run".

The audience follows from that. If you run Gentoo, Alpine, Void, Artix or FreeBSD, you already have an init system that is not systemd, and you may have fought with a display manager that wanted one. Ly's install instructions cover systemd, OpenRC, runit, s6, dinit, sysvinit and FreeBSD, each with its own service registration commands. The repository is organised as a Zig build with separate ly-core/ and ly-ui/ trees, so the UI layer and the session logic are not one monolithic blob.

It is not a general-purpose greeter. There is no theme engine in the traditional sense, no remote login protocol, no Wayland compositor of its own. The README points to a separate community repository for custom animations and scripts, which tells you where the project draws the line between core and extras.

How the TTY login and PAM handoff actually work

Ly runs on a virtual console, which is the single most important fact about its architecture. Because it occupies a TTY, the getty that would normally own that console has to be disabled, or the two will fight over it. The README is blunt about this: "you must disable the TTY service that Ly will run on, otherwise bad things will happen." On systemd that means `systemctl disable [email protected]`; on OpenRC it means `rc-update del agetty.tty2` plus commenting the matching line in /etc/inittab on Gentoo and Alpine.

Authentication goes through PAM, which is a compile-time dependency alongside libc and, optionally, xcb. The optional xcb dependency is what enables X11 session support, and the README warns that if Xorg sessions do not work you should check whether your distribution compiled Ly with Xorg. That is a packaging question, not a configuration one, and it is easy to misdiagnose as a session file problem.

Session discovery is file-based. Ly looks at /usr/share/xsessions and /usr/share/wayland-sessions for .desktop entries, and it does not rescan while running. The README says that if you install a desktop environment and it does not appear, you should restart the Ly service or reboot. It also supports per-Ly session files in /etc/ly/custom-sessions, which are visible only to Ly, and unlike most login managers it exposes both an xinitrc entry and a shell entry. Logging is split in two: ~/.local/state/ly-session.log for the session and /var/log/ly.log for the system, both configurable through /etc/ly/config.lua or /etc/ly/config.ini.

Building Ly from source and enabling the service

The build needs a release version of Zig 0.16.x. The README is explicit that you must check `zig version` does not carry a `-dev` suffix, so verify that before anything else. On Debian, the documented dependency line is one apt command; Fedora and FreeBSD have their own equivalents in the README.

# apt install build-essential libpam0g-dev libxcb-xkb-dev xauth xserver-xorg brightnessctl

That pulls in PAM headers, the xcb keyboard library, xauth and brightnessctl, which is a runtime dependency under the default configuration. With those in place, clone and build:

git clone https://codeberg.org/fairyglade/ly.git
cd ly
zig build

You can run the result in a terminal to check the interface, but the README warns that authentication will not work that way, and that running as root in a terminal emulator is not recommended. Use Ctrl+C to exit. The real install is the next step, and the init system is a build flag:

# zig build installexe -Dinit_system=systemd

The parameter defaults to systemd, so on OpenRC, runit, s6, dinit or sysvinit you pass the matching value. After that, disable the display manager you were using and enable Ly on a TTY. The README's systemd example uses tty2:

# systemctl disable lightdm.service
# systemctl enable [email protected]
# systemctl disable [email protected]

Those three commands are the whole first use. If you skip the third, you have two processes competing for the console. On FreeBSD the equivalent is a build with `-Dprefix_directory=/usr/local -Dconfig_directory=/usr/local/etc -Dinit_system=freebsd`, followed by an entry in /etc/gettytab and a modified command field in /etc/ttys. Note that FreeBSD TTYs start at 0, so the README's example edits ttyv1.

SELinux, missing sessions and the limits of a TTY greeter

The README carries a warning that distributions using SELinux, such as Fedora and openSUSE Tumbleweed, may hit issues including session launch failures. The documented diagnostic is `ausearch -m avc -ts recent`, looking for a denied process transition from `unconfined_service_t` to `unconfined_t`. The fix is to generate a local policy module with `audit2allow -M ly-local` and load it with `semodule -i ly-local.pp`. The README says this was confirmed on Fedora 39 and 44 and openSUSE Tumbleweed. Treat that as a real operational cost: you are maintaining a local SELinux module, and it persists regardless of filesystem permissions.

The second limitation is session refresh. Ly does not rescan session directories while it is running, so a freshly installed desktop environment is invisible until you restart the service or reboot. That is a deliberate simplicity trade-off, but it surprises people who are used to a greeter that picks up new entries immediately.

The third is the wrong-tool case. If you want a graphical login with a background image, a user list and a theme picker, Ly is not that, and the community animation repository is not a substitute for a greeter toolkit. If you want a display manager that manages seats, multi-monitor layouts or remote sessions, look elsewhere. Ly's scope is narrow on purpose: authenticate, start a session, draw a text interface.

Ly against LightDM and the systemd-integrated default

The README uses LightDM as its running example for disabling the previous manager, which is a fair comparison point. LightDM is a graphical greeter framework with a plugin architecture, a broad set of greeter front ends, and a seat-management layer. Ly is a single TUI binary that draws in a console. The difference is not cosmetic: LightDM can show a themed login screen on a graphical display, while Ly only ever appears as text on a TTY.

Against systemd's own login handling, the split is about dependencies rather than features. Ly does not require systemd, and its install path is a Zig build flag rather than a unit file you write yourself. That is the whole reason the project exists, and the README's per-init instructions for OpenRC, runit, s6, dinit, sysvinit and FreeBSD are where the value sits. If you are already on systemd and happy with your current manager, Ly offers you a smaller greeter and not much else.

The xinitrc and shell entries are the other practical difference. The README notes that unlike most login managers, Ly has both, which matters if you log into a bare shell or a hand-rolled X session rather than a desktop environment with a .desktop file.

Licence, maintenance and upgrade cost

Ly is released under the WTFPL, a permissive licence with no conditions on redistribution or modification. For most users that is the least restrictive option available, and it means you can vendor the source, patch the UI layer in ly-ui/ and ship the result without a notice file. It also means there is no warranty language to lean on if a session fails to start. This is a description of the licence text, not legal advice; if you are redistributing Ly inside a product, read the licence yourself.

The repository is not archived, and the last push was on 2026-09-08. The most recent tagged release in the repository is v1.0.3 from 2025-03-13, which means there is a gap between tagged releases and repository activity: fixes can land on master without a new tag. If you package Ly for a distribution, pin a commit rather than assuming a release tag reflects the current state of the tree.

Upgrade cost is dominated by the service file and the TTY assignment, not by the binary. Changing which TTY Ly runs on means editing the platform service file, and on OpenRC-based systems also /etc/inittab. The build flag `-Dinit_system=` has to match the target machine, so a package built for the wrong init will install a service file the host cannot use. The Zig version requirement adds a second constraint: a distribution shipping a `-dev` build of Zig cannot build Ly from source as documented.

Editorial conclusion

Adopt Ly if you run a non-systemd init (OpenRC, runit, s6, dinit, sysvinit) or FreeBSD and want a login prompt that lives in a TTY, and you are willing to disable the getty on that TTY. Do not adopt it if you expect a graphical greeter, or if you are on Fedora or openSUSE Tumbleweed and do not want to maintain a local SELinux policy module. Before installing, check that `zig version` reports a release build without a `-dev` suffix, confirm your distribution packages Ly with Xorg support if you need X sessions, and read the service file for your init system so you know which TTY it claims.

Frequently asked questions

Official sources

1. fairyglade/ly on GitHub
2. Issues
3. License: WTFPL
4. README
5. Releases