^ Is the gnome-bluetooth package on the Devuan blacklist? I don't have time to check myself.

Did you check rfkill?

@all: sorry about my disruptive behaviour, I've been having a difficult time of things recently and I tend to act out as a coping strategy.

I won't do it again.

But they are optional. For example, can you name a single distribution that's actually using systemd-networkd?

I would agree that most features can be implemented with other tools but I like the consistency of the systemd tool set and also the fact that they're all being produced and maintained by the same team, just as you would find in real UNIX systems.

But there are some features that are unique to systemd. I've already mentioned masking units, another is hardening of services:

https://www.ctrl.blog/entry/systemd-ser … ening.html

Check this out:

empty@E485:~ $ systemd-analyze security --no-p
UNIT                                 EXPOSURE PREDICATE HAPPY
accounts-daemon.service                   9.5 UNSAFE    ?    
alsa-state.service                        9.5 UNSAFE    ?    
anacron.service                           9.5 UNSAFE    ?    
auditd.service                            9.5 UNSAFE    ?    
btrfs-scrub@-.service                     9.5 UNSAFE    ?    
colord.service                            8.7 EXPOSED   ?    
cron.service                              9.5 UNSAFE    ?    
dbus.service                              9.5 UNSAFE    ?    
emergency.service                         9.5 UNSAFE    ?    
gdm.service                               9.7 UNSAFE    ?    
getty@tty1.service                        9.5 UNSAFE    ?    
hddtemp.service                           9.5 UNSAFE    ?    
iwd.service                               5.7 MEDIUM    ?    
polkit.service                            9.5 UNSAFE    ?    
rc-local.service                          9.5 UNSAFE    ?    
rescue.service                            9.5 UNSAFE    ?    
rtkit-daemon.service                      6.9 MEDIUM    ?    
sysfsutils.service                        9.5 UNSAFE    ?    
systemd-ask-password-console.service      9.3 UNSAFE    ?    
systemd-ask-password-wall.service         9.3 UNSAFE    ?    
systemd-fsckd.service                     9.5 UNSAFE    ?    
systemd-initctl.service                   9.3 UNSAFE    ?    
systemd-journald.service                  4.3 OK        ?    
systemd-logind.service                    4.1 OK        ?    
systemd-networkd.service                  2.8 OK        ?    
systemd-resolved.service                  2.1 OK        ?    
systemd-rfkill.service                    9.3 UNSAFE    ?    
systemd-timesyncd.service                 2.0 OK        ?    
systemd-udevd.service                     8.3 EXPOSED   ?    
upower.service                            7.2 MEDIUM    ?    
user@1000.service                         9.1 UNSAFE    ?    
uuidd.service                             9.1 UNSAFE    ?    
empty@E485:~ $

Can you do that with sysvinit?

So what is your proposed solution to the problem of the encryption key being left in RAM during suspend operations?

I asked the same question over at the MX forums and one of their developers claimed that the "solution" was not to use suspend. And I think they were being serious

@tochiro: please post the output of

cat -v /etc/apt/sources.list

^ That should show any non-printable characters.

Or:

sed -n 'l' /etc/apt/sources.list

^ That should display most non-printable characters as the octal values.

For example the new lines will be marked with a $ symbol.

I'm bored.

Well systemd provides *many* optional features: networkd, resolved, timesyncd, bootd, nspawn, etc. No sign of any of them being made compulsory. In fact Fedora's very own Core version has recently dropped systemd-networkd as it's default networking tool.

Can you name any previously optional tools that have been made compulsory?

I can mask any services I don't want in buster and so prevent them from being started even by other services but I can't do that with sysvinit (or OpenRC or runit or s6) so it's pretty flexible in that respect.

How would systemd-homed be implemented on a server? Or even make any sense?

I suppose not but why is it such a problem that the systemd developers are attempting to provide a unified set of user space tools that are consistent across many distributions? That seems like a good thing to me. But perhaps I'm not using enough tin foil...

Do you not have a tl;dr? Or perhaps an opinion of your own?

I tried reading some of the thread but it just seems to be clueless idiots venting their spleen about things they can't control and don't understand.

I'm genuinely curious as to why an optional added feature for an init system you don't even use elicits "blistering condemnation". It's quite bizarre.

You do understand that is a purely optional feature[1], right? It only makes sense for laptops and it won't be the default. And it's actually rather useful, if you read the posts about it earlier in the thread.

[1] Like most of systemd's tools.

That is correct.

Don't use that, it is obsolete.

Try again with no X.Org configuration files at all (except those supplied by packages and stored under /usr/share/X11/xorg.conf.d/).

And you have installed the non-free firmware required by your video cards, right?

EDIT: and make sure there isn't a nomodeset kernel command line parameter applied, AMD cards won't work without kernel modesetting.

^ Remove that file and let X auto-configure.