As far as I understand, Devuan ships unmodified firefox-esr from Debian (Security). However, this one does not seem to depend on pulseaudio:

https://pkginfo.devuan.org/stage/ascii/ … eb9u1.html

@golinux: I am not sure how the rdepends from your posting relates to that. Maybe this changed from Jessie?

I recommend using adapters that work with the ath9k driver and do not require any non-free firmware. They are supported well, however, they offer "only" 802.11n radio and I am not aware of any that use USB3 (actually, for the data rate USB 2.0 seems sufficient). You can find some listed on the FSF's giving guide (look for "cool devices"):

https://www.fsf.org/givingguide/v9/

The UHS specification is not very relevant and also the capacity matters. Here are some 4K random read/write values I measured:

- Sandisk Ultra A1 200 GB: 8.54 MB/s read, 5.13 MB/s write
- Sandisk Extreme A2 64 GB: 4.97 MB/s read, 3.05 MB/s write
- Sandisk Ultra A1 64 GB: 7.67 MB/s read, 2.84 MB/s write
- Sandisk Ultra C10 64GB: 5.26 MB/s read, 0.94 MB/s write
- Toshiba Exceria UHS-3 64GB: 3.82 MB/s read, 0.09 MB/s write

In this sample you can see with the Exceria UHS-3 card that there are extreme cases of cards that have good linear read/write performance with large block sizes of roundabout 100 MB/s but they suck extremely when it comes to 4K random read/write. But this is what actually matters for a system drive.

I had a more comprehensive list of measures on my blog that is currently offline. But you can find another comparison and a link to a recent 2018 update in Jeff Garling's blog over here (unlike me, he measured directly on the RPi's internal card reader):

https://www.jeffgeerling.com/blogs/jeff … crosd-card

Similar symptom but different failure: I was able to reproduce the "black screen" issue on a X200t running the Lenovo factory BIOS, but in this case I can't switch to the console as the screen stays all black. Failsafe and nomodeset do not help either. Double-checked with the T400s and another X200, but there it seems to work fine. So only the X200t seems to be affected so far.

Well, the Raspberry Pi is a bad example, but sunxi (Allwinner) and rockchip are much better ones, and in the meantime the GPU support is also getting better. Apart from that, the KGPE-D16 is one of the currently best options if you want to go for a cheap, powerful but also power-hungry x86 machine.

And no, I meant Raptor's "blackbird" POWER system that was for sale in Black Friday. It's like the TALOS 2 (lite), but in micro-ATX format with just two RAM slots and just one CPU socket, but apart from that still a real POWER machine. It's really a small board and not only targeted at servers.

@cynwolf: I don't see the big issue with using the mentioned 10 years old hardware. This last generation of hardware with removable ME / without PSP should be powerful enough for most people and use cases even today. Also, there are many very interesting options in the ARM world (where Devuan also ships proprietary firmware by default as part of the embedded images). Regarding tomorrow, I am convinced that RISC-V and POWER will be viable alternatives to move forward.

Regarding the firmware in other chips: Well these chips should have limited control and usually be controlled by the CPU (provided you have proper IOMMU isolation and limit DMA access). Thus, the last thing you want is proprietary firmware running as root in kernel space on the main CPU - not mentioning any chip that has control over the CPU (like the mentioned auxilliary chips such as BMC controllers or stuff like a management engine that runs on a chip inside the cpu package).

Back to topic: Eventually I will find some time around new year to look into the installer issue, but if anyone has the time to resolve it earlier I would appreciate it.

Again: The whole point is about choice and, therefore, asking users whether they want non-free firmware to be loaded or not. The question whether you have a choice is an essential part about freedom, just like the question whether you can choose your Init system or not. Imho, the choice should happen in an "opt-in" and not in an "opt-out" manner - especially if Devuan considers non-free firmware to be potentially harmful in terms of security or copyright issues (as discussed above).

Some older x86 hardware that does not require running non-free firmware on the main cpu (in kernel space) is listed on the Libreboot page:

https://libreboot.org/docs/hardware/#li … d-hardware

There is also other hardware such as the APU boards from PCEngines that ships with coreboot preinstalled (the older dual-core generation uses a cpu that did not have AMD's PSP built-in). Of course, there is other firmware that runs on auxillary chips (such as optical drives or NICs) but as far as I understood the discussion here is about non-free software/firmware that runs on the main cpu, not elsewhere.

It should be possible to not load it at install time already. If a users then realizes that this or that does not work they still have the option to use non-free firmware or to switch to hardware that runs without non-free firmware.

I am aware of the fact that Devuan does not have that many resources, but I am still confused why it was decided not to keep the stuff as it was in Debian (two flavors) instead of changing it - something that sounds to me like more work, not less.

I had a similar setup in the past. However, it should be noted that with this approach the decryption takes much longer, as the pbkdf2 implementation in GRUB is pretty slow. Also, you need to decrypt your disk twice, and apart from typing in the password two times you need to wait for iterTime to finish once more.

Regardless of these issues I don't see much of an security advantage in using this approach if you load GRUB from the same disk where your kernel lives. Instead of compromising the kernel, an attacker can simply compromise your GRUB.

If you load GRUB from elsewhere (e.g. from external flash or you use coreboot) the imho much better approach is to keep /boot unencrypted but to use public key cryptography to sign all binaries that live there (kernel, initrd) and to check their signatures on boot.

Are you aware of the `firmware-b43-installer` which is supposed to handle this automatically? Or is this a different chip? See also:

- https://pkginfo.devuan.org/stage/ascii/ … 019-3.html
- https://wiki.debian.org/bcm43xx#b43_and_b43legacy

However, I think the installer requires a net connection to download the blobs.