I think all that is needed is a short write-up on the different installation medias available, and what will be installed by each.  Most of the content needed for this write up has already been presented within this thread.   This write-up could also be as a single Read Me text file placed with the downloadable files.  A short explanation of each media would be informative and this would help new users.

golinux wrote:

https://www.kernel.org/doc/html/v4.10/s … river.html

That is a non-sequitur.  I think that something was lost in translation.  Alsa is here to stay.   apulse just allows apps to use alsa instead of pulseaudio where pulseaudio is a required dependency.

apulse is a tiny workaround, but it won't replace fully pulseaudio.

You may try to use a LInux desktop like Gnome, XFCE,... without pulseaudio.

golinux wrote:

spartrekus wrote:

If pulseaudio has such a not so good reputation, why not to rewrite another one, but better?

Why is an alternative needed at all?  What's wrong with alsa?  Though I've never tried, I understand that apulse can reinstate alsa functionality in applications that have a dependency on pulseaudio.   Will need to figure that out when Quantum is unavoidable.  There are notes in this forum and also on DNG.

Alsa is ok. Alsa cannot be avoided for graphical usage and multimedia from Linux kernel. Alsa takes crucial part in the kernel for audio.

https://www.kernel.org/doc/html/v4.10/s … river.html

If pulseaudio has such a not so good reputation, why not to rewrite another one, but better?

Whether pulseaudio is bad or not, it's a very different situation to systemd.  The main difference is that it was written as *nix software rather than "Linux proprietary", like systemd.  So it can be installed and run on e.g. the 'BSDs, Illumos, even macOS.

I agree with spartrekus that pulseaudio is crap. I avoid anything made by its author.

The risk of increased installation complexity required to solve ESR's challenge is why I suggest using a webpage as a pre-installation helper to select the correct installer type.  It also means we don't further complicate an already complex to build and complex to use set of installation images.  A web based tool as I've proposed is easier to develop, and extend, and if we collect installation reports with accurate descriptions, we can even look use them to inform more tailored installation options for specific hardware along with better documentation of quirks.

I actually like the idea of a simple webpage that can help newcomers to choose the right image to use. I think this would be a perfect concrete task to offer to anybody that is willing to help Devuan. I am pretty sure we could find in DNG at least a couple of people interested in leading on that front.

HND

KatolaZ

And please find below a more detailed explanation on the motivations
behind each image:

- netinst exist because it's the preferred way of installing minimal
systems and servers;

- the install DVD ISO exists because there are many users asking for a
single medium that they can download once and install many times
(e.g., due to bandwidth restrictions), and supports more than just
XFCE;

- the 3-cdrom set exists because we had many users asking for a
smaller footprint (again, bandwidth is not cheap everywhere) set of
images that they could use to install offline with a minimal XFCE
desktop;

- desktop-live exists because many people asked for a live Devuan
version which could be easily tried and installed. This is also the
preferred Devuan flavour used in reviews;

- minimal-live was thought as a recovery tool and has a specific focus
on accessibility (especially regarding visually-impaired and blind
users), and provides a full-featured console-based setup;

- so many embedded images exist because ARM vendors have not agreed on
a common standard;

- qcow, vagrant, and vcox images exist because many Devuan users like
to have ready-to-use images for their VMs;

- on top of those, there are also the usual mini.iso and netboot
images, although not advertised on files.devuan.org.

I tried a Devuan install from scratch on the NUC, failed due to the NIC problem, then did a Mint install from scratch.

The problem turned out to be that the Devuan ASCII kernel is too old. The list of vendor-ID/subtype pairs for the e1000 didn't include the subtype the NIC on the NUC has.

Panopticon wrote:

So if you have never done a Debian install, your frustration it seems is not really based on any facts is it, or am i missing something here?

He has tried a Devuan install:

The first, my wife's home-office machine, is "minx", an Intel NUC running Mint 19 - I've tried to Devuanize that and failed.