@aluma hey, nice work! That's great memory usage, especially considering you've got some KDE stuff running. I looked up the ps_mem utility you guys are using, and it gave me a chance to try out installing a Python package with pipx. Here's what I get with basically nothing but an xterm window open. Not sure why my Xorg is so memory-hungry. Maybe lots of fonts?

ntpd is a surprise. Maybe I should have installed the OpenBSD ntp daemon instead. dunst is supposed to be a lightweight desktop notification server. I guess it's lightweight compared to GNOME. I have no idea what's going on with exim4, it must be misconfigured. I just installed it because cron said it needed a mail handler for system alerts, and it's supposed to be the "light" version!

Private  +   Shared  =  RAM used       Program

148.0 KiB + 112.5 KiB = 260.5 KiB       seatd
224.0 KiB + 122.5 KiB = 346.5 KiB       sh
176.0 KiB + 184.5 KiB = 360.5 KiB       init
424.0 KiB + 124.5 KiB = 548.5 KiB       cron
388.0 KiB + 221.5 KiB = 609.5 KiB       dbus-launch
  1.0 MiB +  36.5 KiB =   1.0 MiB       ssh-agent
748.0 KiB + 486.5 KiB =   1.2 MiB       su
636.0 KiB + 691.0 KiB =   1.3 MiB       dbus-daemon (2)
  1.2 MiB + 113.5 KiB =   1.3 MiB       udevd
920.0 KiB + 994.0 KiB =   1.9 MiB       getty (6)
  1.9 MiB + 107.5 KiB =   2.0 MiB       dhclient
  2.2 MiB + 133.5 KiB =   2.3 MiB       rsyslogd
  2.0 MiB + 655.5 KiB =   2.6 MiB       sshd
  1.5 MiB +   1.6 MiB =   3.1 MiB       bash (2)
  1.7 MiB +   1.7 MiB =   3.5 MiB       xdm (2)
  3.4 MiB +  97.5 KiB =   3.5 MiB       iwd
  5.8 MiB +   1.1 MiB =   6.9 MiB       xterm
  8.5 MiB +   5.1 MiB =  13.6 MiB       dunst
 15.7 MiB + 140.5 KiB =  15.8 MiB       exim4
 15.8 MiB + 971.5 KiB =  16.8 MiB       ntpd
 14.1 MiB +   6.2 MiB =  20.3 MiB       x-window-manage
 95.0 MiB +   2.0 MiB =  96.9 MiB       Xorg
---------------------------------
                        196.0 MiB
=================================

Edit: sorry, I didn't know this would post so big. I can remove this if it's too big for the thread, just let me know!

dpkg: warning: This system uses merged-usr-via-aliased-dirs, going behind dpkg's
dpkg: warning: back, breaking its core assumptions. This can cause silent file
dpkg: warning: overwrites and disappearances, and its general tools misbehavior.
dpkg: warning: See <https://wiki.debian.org/Teams/Dpkg/FAQ#broken-usrmerge>.

I haven't seen this one before, is this new?  The phrase "going behind [one's] back" implies deception, which really crosses a line.

I kept searching the web for instances of the error message, and eventually I found something helpful:
empty runlevels overide LSB defaults
It turns out that re-installing a script without first removing it can result in this error. So I merely did the following, and it ran without errors, installing the symlinks in the proper locations:

# update-rc.d -f iwd remove
# update-rc.d iwd defaults

The manpage for update-rc.d says that running the `remove' directive while the script is still present in /etc/init.d will result in errors. However, that didn't happen for me. In fact, it was exactly what I needed to do to fix the problem. It removed the symlinks in /etc/rc*.d, which then allowed me to reinstall the script with the default settings.

[Edit to clarify this paragraph] The manpage doesn't mention that running update-rc.d with the `defaults' directive when symlinks are already present in /etc/rc*.d will result in errors. There is a paragraph that says it "does nothing" if files exist at /etc/rc*.d/[SK]??, and I think this information is meant to apply to the `default' action, although the wording isn't really clear. But that's not really what happened either. In my case, installed kill scripts all over the place.

It's all very confusing, but I think I have the proper procedure figured out now.

Thanks GlennW, I tried changing the runlevels, but I'm still getting the message about empty runlevels. For some reason update-rc.d is not properly parsing the file. It's so strange! I also had to install a script for nftables, and it worked fine.

I wish I'd looked at the rc directories before changing the iwd script to see if it was installed wrong from the start. That could have been the problem from the beginning.

I've got the orphan-sysvinit-scripts package on all my systems now, that's a good one to have.

Edit - update:

I used `update-rc.d iwd enable [runlevels]` to force the service to start when I wanted it to. It still doesn't explain why the default method fails, but at least it works now, and the service starts at boot!

Thanks, I believe we may already be using the same script, as the /etc/init.d/iwd script that was installed on my system says it was generated by sys2dv:

#!/bin/sh
# Generated by sysd2v v0.3  --  http://www.trek.eu.org/devel/sysd2v
# kFreeBSD do not accept scripts as interpreters, using #!/bin/sh and sourcing.

I think the sys2dv script would work fine as it is, if it weren't for the known bug with the Atheros hardware, which was apparently fixed for the newer chipset (ath10k) but not my older system (ath9k.) This is a really old system (2008) and I don't think anyone at iwd or the kernel cares about fixing it anymore. I'll have a look at the sysd2v script source and see if I can figure out where I need to introduce the 2-second delay that the systemd unit fix would normally provide.

Some systems have capacitors that will hold the CMOS memory for up to an hour after you remove the battery. Others have non-volatile memory, though, and can't be reset that way. I have an old Dell laptop with an unknown admin password and I haven't found any way to reset it.

I looked up the xfce4 metapackage because that was the way Danielsan cited it, but certainly, your minimal install would be a lot leaner, about 90% by the looks of it. I was actually considering xfce recently until I saw the elogind dependency. I'm not trying to change anyone's mind about the issue, but there's a thread about it here if anyone's interested:
https://dev1galaxy.org/viewtopic.php?id=5909
I haven't checked to see exactly which of those core packages is dependent on elogind, so it may be possible to use significant parts of xfce without elogind.

Why do you say that? The gitlab shows commits as recent as two weeks ago.
https://gitlab.freedesktop.org/xorg/app/twm

Don't you need to tell the package manager not to upgrade the package as well? I recently had to install an older version of a package, and I also told aptitude to put a hold on it. In my case, it was because newer versions of the wacom driver had pulled support for serial tablets, which broke a ton of older tablet PCs.

(I figure it's a good idea whenever such things are discussed to post a link to Don'tBreakDebian as a warning to those unfamiliar with the risks of such practices.)

I currently have cwm installed on all my Devuan machines. It takes a bit of time to get used to the complete lack of window decorations, but once you learn the keyboard shortcuts, it's really not an issue. Configuration is extremely easy via the .cwmrc file.

If you decide to try cwm, you'll probably want to replicate some of the functionality offered by DEs and more advanced WMs. I currently have some hotkeys bound to scripts that adjust my volume and screen brightness using amixer and brightnessctl. They call xosd to briefly display the current settings.

This behavior is due to the Debian alternatives system. When both `less` and `more` are available, man will default to using less as its pager, because it has a higher priority. If you remove less, the system will fall back to more. You can see information about pagers installed on your system with `update-alternatives --display pager`.

Unfortunately the LESS environment variable only applies to the less program, not more. more is extremely primitive, even the manpage mentions it, and steers uses toward less. dave doesn't explain why he wants to use more specifically, but I always assume people have their reasons in such situations.

I tried to replicate dave's issue on 2.39.3, and while more didn't clear the screen without the -c or -p option, I noticed a different issue. When I printed from redirected output (i.e., not from a regular file) the -c or -p option would not clear the screen. Everything worked as expected on 2.33.1, so I think it's another bug. It seems util-linux is all over the place lately.

I encountered the exact same error during my latest bootstrap. I got around it by bootstrapping with --variant=minbase, then installing the packages that required the systemd shim after chrooting into the new system. It wasn't really any extra trouble, as I had a substantial list of additional packages to install anyway.