Hmm ...
I have so many, but the root cause to any of them has eluded me from an early age.

Most of them can be found in any edition of Jon Winokur's 'The Portable Curmudgeon'.

That is because I have gvfs installed and you do not.

I had to reinstall it.

Best,

A.

So it does work using extracted squashfs. The errors seem just warnings. It's there in the overlay. The overlay can be mounted in main system and new initrd copied to where the the relevant bootloader can find it.

But it doesn't work using fromiso/findiso (my preferred use case) without user intervention as noted. I don't see that mentioned in live-boot's manual.

I really appreciate that you take the time to delve into this stuff.
At present, I don't have the time myself, but it seems that clarifications and eventual workarounds may be helpful also to the upstream developers.

I assume you were obliquely referring to my comment, ralph.ronnquist, so I removed what is probably the part you found most objectionable.

But I have spent a great deal of my life trying to be polite and diplomatic, and I'm now at the age where I think a lot of the world's problems are caused by stupid people not being properly told they're being stupid. To that end, I've grown very fond of Linus Torvalds' occasional rants about "brain damage" in software, because that's what it is, and it needs to be called out. Politeness implies acceptance or at least tolerance, and stupid decisions should be greeted with neither.

Stupid decisions are stupid.

Here are the key security considerations and potential issues:

Socket Permissions and Access Control

• The control socket uses permissive permissions (0666) allowing connections from non-root users turnstiled.cc:47 , but relies on platform-specific credentials checking to verify the peer's UID/GID/PID utils.cc:25-111 . This design requires proper implementation on each supported platform.

Privilege Separation

• The daemon runs as root but service managers are executed with dropped privileges after proper setup exec_utils.cc:126-145

• Resource limits are sanitized before PAM session setup to prevent privilege escalation exec_utils.cc:106-124

Process Management and Timeouts

• Implements a 60-second timeout for service manager startup to prevent hanging logins turnstiled.cc:55 turnstiled.conf.5.scd.in:93-97

• Service managers that fail to signal readiness are terminated and runtime directories are cleaned up turnstiled.cc:1043-1054

Resource Management

• Runtime directories are created with proper ownership and permissions

• Cleanup occurs on logout unless lingering is enabled turnstiled.cc:1071-1075

Known Limitations

• When integrating with polkit, sessions may be treated as non-local
    unless polkit is patched, potentially affecting authentication README.md:110-122

• Root session management is disabled by default due to potential security implications turnstiled.conf.5.scd.in:99-104

Relying on the accuracy of code described by developers as a "work in progress" constitutes an unusual and risky security practice, as it introduces significant vulnerabilities due to incomplete testing, lack of peer review, and potential design flaws.
_https://github.com/chimera-linux/turnstile

Yes, the turnstiled deamon must run as root. This is explicitly documented and required for its core functionality.

Why Root is Required

The daemon performs privileged operations that necessitate root access:

1. System Directory Management: Creates directories in /run for session tracking turnstiled.cc:1276-1298

2. Runtime Directory Creation: Creates and chowns XDG_RUNTIME_DIR for users fs_utils.cc:55-124

3. Socket Operations: Binds to system paths and sets up the control socket turnstiled.cc:890-943

4. PAM Session Management: Establishes PAM sessions for users exec_utils.cc:316-322

Security Design

While running as root, the daemon implements:

• Credential verification: Only UID 0 can create sessions turnstiled.cc:297-300

• Privilege separation: Service managers run with dropped privileges exec_utils.cc:339-349

• Root checks: Verifies it's running as root before privileged operations exec_utils.cc:310

The README explicitly states: "It needs to be running as the superuser" README.md:78-81 .

Notes

The daemon accepts connections via a permissive socket (0666) but enforces security through platform-specific credential checking, allowing the PAM module to communicate while maintaining access control turnstiled.cc:47 .

Any daemon running as root is inherently an attractive target for attackers. Turnstiled is no exception.

Security Reality

Turnstiled runs as root and accepts connections via a 0666 socket turnstiled.cc:47 , making it a high-value target. A compromise could allow session hijacking or privilege escalation.

Mitigations in Place

The daemon implements several security measures:

1. Credential verification: Every connection is authenticated using platform-specific methods (SO_PEERCRED on Linux, LOCAL_PEERCRED on BSD, etc.) utils.cc:25-111

2. Access control: Only UID 0 can create sessions turnstiled.cc:297-300

3. Privilege separation: Service managers run with dropped privileges exec_utils.cc:339-349

4. Resource limits: Sanitizes rlimits before PAM session setup exec_utils.cc:106-124

Attack Surface

The primary attack vectors would be:

• Bugs in credential checking code

• Protocol parsing vulnerabilities

• Race conditions in process management

• Memory corruption in the daemon

Notes

While the design is deliberate for PAM integration turnstiled.cc:40-46 , it does increase the attack surface. The security relies heavily on the correctness of the credential verification implementation. Regular security audits and keeping the daemon updated would be essential for any deployment.

The documentation does present a tension between the "work in progress" status and the security requirements.

What the Documentation States

The README explicitly labels Turnstile as "a work in progress effort" README.md:3-5 while simultaneously stating it "needs to be running as the superuser" README.md:78-81 . There is no explicit security warning about this combination.

Security Considerations in Code

The code does implement security measures:

• Platform-specific credential verification for all connections

• Only UID 0 can create sessions turnstiled.cc:297-300

• Privilege separation for service managers

However, the design acknowledges accepting connections from non-root processes as a deliberate trade-off turnstiled.cc:40-46 .

Missing Documentation

What's absent from the documentation:

• No explicit warning about running Work-In-Progress (WIP) software as root

• No security audit status or review process mentioned

• No clear statement about production readiness

Notes

This is a valid concern. While the code implements standard security practices for a session tracker, users should be aware that running any "work in progress" daemon as root carries inherent risks. The documentation could be more transparent about these risks and the current security posture of the project.

• The project seems to place considerable faith in its users' understanding of the inherent risks involved.

• The users are invited to trust developers who have not fully disclosed the security risks associated with running work-in-progress (WIP) software with root privileges.

Transparency is a key pillar of trust in software development. 

In cybersecurity, trust must be earned through demonstrable actions, not assumed or invited. When developers work on software that requires elevated privileges like root access, the stakes are significantly higher. A lack of transparency about known risks, especially in Work-In-Progress (WIP) software, undermines user safety and ethical responsibility.

Transparency was, of course, something of a guiding principle in Linux and open-source software, and one rather hopes it might linger on.

$ cat /usr/share/alsa/alsa.conf
#
#  ALSA library configuration file
...
defaults.ctl.card 0
defaults.pcm.card 0
defaults.pcm.device 0
...
defaults.pcm.dmix.rate 48000
...

To improve sound quality with Firefox and YouTube, you can disable WebM (Opus) support in Firefox (media.mediasource.webm.enabled = false). This will automatically enable AAC (MP4) playback at a 44100 Hz sample rate.

To prevent resampling, set the default sample rate to 44100 Hz in ~/.asoundrc:

defaults.pcm.dmix.rate 44100

Firefox settings for better sound quality:

media.mediasource.webm.enabled              false
media.cubeb.backend                         alsa
media.resampling.enabled                    false
media.cubeb_latency_playback_ms             160

Configuration Editor for Firefox:
_https://support.mozilla.org/en-US/kb/about-config-editor-firefox

If you are using the fftrate resampler, you can configure it for the maximum sample rate supported by your sound card (e.g., 192kHz, 32-bit for Intel HDA on notebooks), as fftrate provides much better sound quality than the built-in resampler of your sound card.

Equalizers and Hearing Aids

The idea that a system-wide equalizer resembles a hearing aid stems from their shared function: adjusting sound frequencies to suit individual perception.  In theory, boosting certain frequencies (like high tones for age-related hearing loss) could help someone hear better, much like a hearing aid. However, while both tools manipulate audio, they differ fundamentally in design, precision, and purpose.

Despite their flexibility, system-wide equalizers fall short as hearing aids because they apply the same frequency adjustments to all volume levels.  Hearing loss, especially sensorineural types like presbycusis, involves loudness recruitment—a reduced dynamic range where soft sounds are inaudible but loud sounds become painful.

A fixed EQ cannot adapt gain based on input level. For instance, boosting high frequencies to hear whispers may make loud sounds uncomfortably piercing. Additionally, EQs lack features like noise reduction, feedback cancellation, and directional microphones found in modern hearing aids.

Modern digital hearing aids go far beyond simple EQs by using multi-channel, level-dependent compression.  Devices like the SONIC NATURA™ use nine independent compression bands at half-octave intervals, allowing different gain settings for soft (50 dB) and loud (90 dB) sounds—referred to as the '5' and '9' curves.

This dual-curve system compensates not only for frequency-specific hearing loss but also for abnormal loudness growth.  Unlike a static home audio EQ, this approach dynamically reshapes sound across intensity levels, mimicking the function of a healthy cochlear amplifier.

While a system-wide equalizer can mimic some aspects of hearing aid functionality, it lacks the adaptive, multi-dimensional processing required for effective hearing rehabilitation.  Hearing aids are medical devices designed for individual audiometric profiles, with dynamic gain control, noise management, and feedback suppression.

Health Risks

• Hearing damage is inevitable if output levels are excessive, especially with high-frequency boosts (e.g., 10–20kHz), which can accelerate cochlear hair cell loss and lead to permanent threshold shift (PTS).  Research confirms that overexposure to intense sound—particularly in high-frequency ranges—causes irreversible damage to hair cells and auditory nerve synapses, even if hearing thresholds appear to recover initially. The risk increases when EQ is used to boost already loud signals, potentially causing acoustic trauma through prolonged or extreme listening.

• Tinnitus sufferers may misuse EQ to compensate for hearing loss, inadvertently increasing loudness to dangerous levels. 

Conclusion

The reasonable approach is to disable all unnecessary sound processing (e.g., resampling) and low-quality codecs (e.g., Opus) that degrade sound quality and cause audio distortions. Then compare sound quality with that of macOS.  Afterward, you can decide whether you need an equalizer or a hearing aid.

Right, so the bluez-alsa packages in the official Devuan repository were built with --enable-systemd, which means they’ve picked up a systemd dependency — a bit of an oversight, really, given Devuan’s init-agnostic stance.

To address this, the packages were unpacked, the dependency manually adjusted, and then repackaged. They’ll install without complaint, though they might not function perfectly in the absence of systemd. It’s not ideal, but it’s a pragmatic fix.

The method used is a known workaround, documented here: 
_https://dev1galaxy.org/viewtopic.php?id=7157

Has anyone managed to build spacefm

https://codeberg.org/Matlib/SpaceFM/src/branch/next
branch next
Download links are under the ellipsis button on the right side.

./configure --with-gtk2 --prefix=/usr/local/spacefm --disable-video-thumbnails  --sysconfdir=/usr/local/spacefm/etc
make
make install

Video thumbnails need some extra libs. I disabled because I don't need that.

Also GIMP 2.10:

https://codeberg.org/Matlib/gimp2

Launch autogen.sh and follow instructions. I built it agains latest GEGL, but the one from packages should be fine too.

The obvious solution is to remove them both in one command.
Another obvious solution is to put them on hold.

Thanks for the answer and instructions.