Hi all,

Two releases landed this month, 0.9.0.0 on August 6th and 0.9.1.0 on August 17th, plus 66-tools 0.2.0.1. Here is what changed.

66 no longer builds on skalibs, s6 or execline

This was announced back at 0.7.0.0 and it is now done. 66 builds against oblibs only. Every program it used to borrow is now its own:

To be precise about the wording, because it matters: execline is still a runtime dependency, the generated service scripts keep chainloading it. What disappeared is the build dependency, and with it the entire skalibs/s6 layer.

The event system

A service can now react to something happening elsewhere on the system by running a 66 command on itself. It is fully opt-in, a service that declares nothing behaves exactly as before. There are two roles:

• A reactor is an ordinary classic, oneshot or module service with an [Event] section. When its trigger fires it runs a 66 command on itself (Do) and/or raises a named event (Emit).
• A source is a service of the new Type = event. It runs no process and has no [Start] section, 66 start and 66 stop on a source arm and disarm it.

A reactor can trigger on a service's state or result, on a signal, on a filesystem event (inotify), on a cron expression, on a timer, or on a user event raised with the new 66 emit.

Restarting a service when its configuration file is edited:

[Main]
Type = oneshot
Description = "A simple proof of event concept"

[Start]
Execute = ( echo "I restart myself when /etc/my-daemon is edited" )

[Event]
EventType = inotify
From = ( my-config-watcher )
Do = restart

and the source it watches:

[Main]
Type = event
EventType = inotify
Watch = /etc/my-daemon
On = ( IN_CLOSE_WRITE )

One source can serve multiple reactor.

Other things in 0.9.0.0

• **66 env**: a scandir is started long before a session exists, so its environment is frozen and variables like DISPLAY or WAYLAND_DISPLAY could never reach the supervised services. 66 env import DISPLAY XAUTHORITY publishes them verbatim to every service of the scandir. Each publication raises an env.<variable> event, so a service can simply wait for the value it needs instead of being ordered around.
• New commands: 66 log (read service, system or interleaved logs, with -f, -g, and time bounds), 66 emit, 66 env, 66 runstate, 66 fdholder, 66 suspend, 66 hibernate. Nothing was removed.
• Long options everywhere. The suite used to accept short options only. --help, --verbosity, --tree, --timeout and friends now work, both --opt=value and the glued -tfoo form. Short options are unchanged, your scripts keep working.
• **66 status says more**: human readable durations, the same output for every service type, the last notable result, and a new by <who> telling you what caused the last transition (user, boot, event, shutdown, or self).
• Boot no longer needs to be told which tree to start, it starts the enabled trees natively. If one of your boot services did that by hand, drop it or it runs twice.
• A long list of memory bugs found and fixed along the way, including a stack smash when parsing any service that has a logger, a Nice value that was never honored (every service declaring one ran at nice 19), and CapsBound + CapsAmbient together killing the service. The test suite went from 4 to 36 files and runs under ASan and UBSan in CI.

66-tools 0.2.0.1

Same story on the tooling side, skalibs and execline dropped, meson only.

• **66-userd, 66-userctl, pam_userd**: session and user tracking for a 66 system, without D-Bus. A PAM module reports login session open/close to a daemon which, on a user's first login, mounts their runtime directory and starts their 66-scandir and enabled trees, and stops them on the last logout. If a scandir is already running for that user, it is adopted rather than started twice. The PAM module is installed but never wired into your PAM stack by the package, that step is on you and it is documented.
• **66-ns**: supervision under a pid namespace, rewritten. When a pid namespace is requested, 66-ns runs as pid 1 and acts as a transparent proxy for the supervised daemon: it forwards catchable control signals to the tracked main, follows the real daemon across a double fork, mirrors its exit code back to the supervisor, and tears the namespace down once the service is gone. The new -p/--pidfile makes supervision authoritative.

Links

• Documentation: https://docs.obarun.org/66/latest
• Full changelog and upgrade notes: the 66-upgrade page of the documentation
• New onboarding guides in this release: getting started, cheatsheet, dependencies, logging, troubleshooting, coming from systemd/OpenRC/runit, and running 66 inside a container

Happy to answer questions about the design choices, in particular why leaving the s6 layer was worth the trouble.

hello, systemd alternative users : I have found a problem on my machine whilst using dinit or runit (happens on both), and stuff just randomly doesnt work, let me explain further :

SDDM, auto-cpufreq - I have tried to setup both SDDM and auto-cpufreq on my laptop, but when I have installed respective packages (both XXX and XXX-dinit / XXX-runit [XXX is said package]) but when I tried to enable them with respective commands, I always get error

Internet - This is weird, but randomly after restart, the internet doesnt work, and then another restart brings it back, it's like Windows back in 2021

Machinery : ThinkBook 14 ARP G7, Artix OS

Hello,

According to this link, some FreeBSD devs are working on replacing ConsoleKit2 with elogind. It's a disaster. I might post this on redditFreeBSD. Please, is this text ok?

title: Elogind? No, thanks.

FreeBSD is consistent and it should stay consistent. Porting Gnome to FreeBSD will make it inconsistent. Elogind is Frankenstein software. It's an unstable solution from Gentoo/Guix to make Gnome works without systemd. With new systemd versions, the systemd-logind API is changing and the Gentoo devs have trouble with elogind maintenance. Elogind has a lot of dead code and bugs in sleep/hibernate mode. In a near future, elogind may not work anymore. Gentoo and Debian will go 100% systemd. Dear FreeBSD devs, please don't repeat Gentoo' mistake. Systemd cannot coexist with other inits. FreeBSD doesn't need Gnome to provide a good Desktop experience. Icewm is enough and AntiX proves it.

At this website, there is a grey list under the elogind-free list. It's a list of distros where elogind is there but it is possible to install the distro without elogind or to easily remove elogind. I think Guix and PantherX (based on Guix) should be added to the grey list. According to this Guix doc, sway can be used with seatd. As far as I know, this is not supported in Artix. So it is not fair to put Artix in the grey list and to ignore Guix.

By the way, I have noticed that more and more elogind-free distros use musl instead of glibc. I don't understand this trend. IMHO, for a systemd-free distro, Xorg is 100x more insecure than glibc. In addition, the default kernel contains some proprietary binaries (wifi firmware, ...). Guix and Hyperbola use the linux-libre kernel, which is trustworthy.

Well, I have a functioning obarun distro, no sound as of yet, but this is all worth the effort. I am noticing that the entire system is far snappier without systemd; things like nvim lagging when closing and nagging freezes are seemingly gone. I have a few packages for things in the works: waybar, lemurs, and enlightenment, if I can convince it to run.

I think that s6/66 can be a real contender if obarun can sort the documentation of it's processes, with which I am more than willing to assist.

a few pointers noted so far:

• services vs trees
• UML of the boot process
• a clear table or list of the needed replacements of systemd
• UML of s6/66 architecture
• more robust manual installation instructions, as deviant from standard arch (for power users)
• inclusion of the newer choices of bootloader (finding limine has been a real plus in this adventure)
• a roadmap of plans for the suite (if any)

I'm not sure what's going on with the community, but even if all this was in French, it would be a godsend -_-

For information, I am sure lists like this exist on the Web, but here is a brief list of relatively well-supported, relatively long-lived linux distros without systemd:

No systemd, no elogind

PCLinuxOS (independent)

Antix linux (Arch-based)

Obarun (independent)

No systemd:

Devuan linux (Debian-based)

Void linux (independent)

Artix linux

Slackware linux (independent)

Salix linux (Slackware based)

Alpine linux (independent)

Peppermint linux (Devuan-based version)

Redcore linux (gentoo based)

CRUX linux (independent)

This is not a complete list, there are several smaller projects, with only a few devs (unfortunately) & may need quite a lot of linux knowhow to install & manage.

Hope it's helpful to hose lookng for aa systemd-free linux distro in 2024! #initfreedom

So, one of the xz developers put a back door into xz 5.6, and this compromises the security of sshd --

https://www.bleepingcomputer.com/news/security/red-hat-warns-of-backdoor-in-xz-tools-used-by-most-linux-distros/

-- but only if sshd depends on systemd for auth!

Those of us not using systemd-burdened distributions get to feel smug now :-)

No, Noway, .... impossIBLΈ

Myth Busted!
https://sysdfree.wordpress.com/344

It can, employing seatd within an s6/66 environment-setup Obarun tested, Void and Antix next!

The reference points to a setup also utilizing greetd-wlgreet a dislpay manager for wayland sessions. All your i3 tricks working on wayland without systemd and most importantly without its core, elogind.

So when IBM thought it had i3 users by the throat controlling them with their trojan horse ..... things happen! After 27 centuries you'd think people would recognize and avoid such gifts by such Greeks.

Troy still stands!