No, not that I'm aware of.

I trust Debian to remove any non-free code from the kernel and Devuan draw their kernel from them.

Please open a new thread if you want to continue this discussion, it is off-topic here.

You should delete it if you want to use 20-modesetting.conf

Sorry, I should have said that.

Quoted for truth.

The UXA acceleration method is ancient, have you tried Xorg's built-in modesetting DDX driver?

/etc/X11/xorg.conf.d/20-modesetting.conf:

Section "Device"
        Identifier "Device0"
        Driver "modesetting"
EndSection

*blows raspberry*

That is strange, the configuration file should work (I think).

Is there anything in the logs?

It may be worth trying pavucontrol to see if changes made by that program "stick" for the next boot.

Or add the relevant pactl commands to your desktop startup file(s).

EDIT: try putting your configuration in ~/.config/pulse/daemon instead (if that's not where it already is).

Because Devuan derives it's packages from Debian and the extra content needed to play DVDs violates the DSFG and so cannot be included in the official repositories.

You would already know this if you spent your time researching the subject instead of whinging like a spoilt little baby.

You could try clearing the string by using

acpi_osi=

Reference: https://github.com/torvalds/linux/blob/ … s.txt#L153

I'm not really familiar with lshw(1) but could that be for an unused display output?

Can you post

lspci -knn | grep -iA2 'vga\|3d\|display'

Please use code tags when posting terminal output.

Seems like the error message given if you try that is quite sufficient.

Devuan is intended for competent GNU/Linux users, perhaps try one of the derivatives if you're finding it a challenge.

Try

# apt install libdvdread4

I think their criticisms of the firmware included with OpenBSD are not valid.

AFAIUI, the OpenBSD developers' attitude is that if the user has hardware that needs blobs to function then it should be installed automatically because if the user didn't want this then they wouldn't buy that hardware.

After all, any hardware that doesn't download the firmware from the operating system has the firmware installed at the factory instead so just de-blobbing the operating system does not fix the problem (this also applies to the Libreboot project).

Yes, HardenedBSD has some neat features but it's based on FreeBSD and the developers of that operating system have the same "features first" attitude as the Linux devs so the changes are a sticking plaster rather than a from-scratch "correct" implementation.

But I'm no expert

IMO this is an oxymoron due to the complexity of ZFS.

Yes, just read their scripts to see what they do

There are no non-free packages in OpenBSD.

The firmware included in the source tree for OpenBSD is CPU microcode, which is needed to prevent instabilities in the hardware so I don't think removing it would help.

I would be more worried about hard drive controllers and other components that don't upload firmware from the OS.

Yes, I am a big fan of Talos & POWER9, that architecture is much better than the x86 garbage.

If I was in the market for a desktop system then I would buy one of their Blackbird systems in preference to any of that Xeon nonsense.

But the problem of embedded firmware for the other components on the motherboard remains no matter what the hype from Talos may claim...

Use bootchart to analyse boot performance.

EDIT: typo.

The page was updated last year so it is quite old, check the commits to the KSPP repository since then to see if anything has changed.

Yes indeed, the kernel devs have never been very interested in security-related issues and the KSPP looks like lip-service to me (not that I'm qualified to judge).

I wouldn't use Linux for anything important, OpenBSD is my preferred choice for serious stuff.

I don't know.

The last freely-available grsec patches don't protect against Spectre or Meltdown so they're useless now.

No idea.