@Grumpy, with all respect, it's kind of like contacting your bike manufacturer when you, on your way to the shop, find that there is a temporary road closure.

More precisely, the Temporary failure in resolving 'deb.devuan.org' notice is from the initial phase in the networking when the apt software (on your computer) attempts to find an IP address for that service. The service itself is not involved in that phase.

I don't know much of this either, but fwiw I agree with your observations.

You might be able to use amixer to toggle that 'HDMI/DP,pcm=3 Jack' control.
First you'd do

amixer contents

to see what is possible and the "names" of things, and then something like

amixer cset iface=CARD,name='HDMI/DP,pcm=3 Jack' toggle

to toggle that control.

The daedalus preview ISOs are currently only those that provide packages. Each is set up as a "repository" which most easily is used as a "file://" source in sources.list. I suppose some "cdrom:" line might work as well but I haven't had luck with those. So, my suggested hands-on is:

• mount the ISO at some file path /X

• add a line to sources.list (note the plethora of slashes):

  deb [trusted=yes] file::///X daedalus main contrib non-free

• then run apt-get update and so on

Those ISOs don't include any installer and are not bootable.

quick note: I think your IV and V are in wrong order: init executes /etc/init.d/rcS because that's what /etc/inittab says. That file is the configuration for init.

Please continue

EDIT: Actually, you skipped over the pre-pivot stage, which is the initial bootup (adding .1 to your III) using the initrd filesystem.

The kernel begins by running its /init which is a shell script, and that script will eventually pivot the root to the "real" filesystem and exec /sbin/init. The initrd scripting is held in /usr/share/initramfs-tools which is a configuration place for building an initrd, since the actual, running initrd is the cpio package loaded from /boot into RAM by the kernel (using the initrd= parameter).

afaik most linux systems have that 2-stage boot, to allow the bootup to be programmed generically even though every actual bootup is a specific host. It's quite possible to set up the bootup for the specific host without using an initrd stage but then typically it needs a specific kernel with the right modules compiled in.

Isn't it called mariadb in chimaera?

Respectfully, these "works for me" anecdotes seem rather small-minded and useless, pretty much  like the whole idea itself.

Personally I'm in no way confused by having multiple directories with programs and libraries, and I imagine that the likelihood of confusing something or someone is larger with making this kind of change than not changing.

The idea is a matter of choice, and the main stigma is in the question of who should make the choice.

In many ways it's similar to that choice of excluding /sbin and /usr/sbin from non-root user's default setup; a choice which in my view is equally stupid.

But I don't make these choices. I merely learn to live with them.

Use jitsi

@Altoid, quite possibly the MemAvailable measure has lost its most significant digit (it's rather unusual to have more free than available memory), and maybe you should consider replacing

with something else, like e.g.

_memavail=$(sed '/memavailable/I!d;s/[^0-9]*//;q' /proc/meminfo)    # OK no cats or cuts
_memfree=$(sed '/memfree/I!d;s/[^0-9]*//;q' /proc/meminfo)          # OK no cats or cuts

EDIT: (though maybe I'm wrong about what memfree and memavailable means?)

Usually "install linux beowulf" would mean to use an installer ISO which then kicks in already on the boot-up of the machine.

Presumably you think of doing something else and you may then need to explain in some more detail what you mean.

In particular "installation through the command line" implies you are running an OS. which?

Afaiui a destination phrase rsync://groucho@192.168.1.3:/stuff tells the rsync server to become user groucho and then interpret what the "stuff" module is. As man rsync tells me at (my) lilne 202: the first word of the "path" is actually a module name.

To that end rsync will want a declaration in the applicable rsyncd.conf at the server end which in particular would provide the desired path prefix /stuff for the stuff module, but presumably that doesn't exist. But from the log file, it looks like it results in the /stuff bit (the module bit) is consumed and then a destination path prefix / is used.

In short, you might have some luck using rsync://groucho@192.168.1.3:/stuff/stuff as destination path, on the idea that the first /stuff bit nominates the module and the second /stuff bit nominates the path suffix relative to the default module path prefix, /. Of course, if the server is happy with more random module name, you should use something else than /stuff just to reduce the confusion, maybe rsync://groucho@192.168.1.3:/X/stuff

Your sources.list point should have been fine for finding broadcom-sta-dkms in chimaera/non-free. It would be wrong to add deb http://deb.devuan.org/merged chimaera/non-free amd64 and apt-get would have told so upon update. So I'm afraid I cannot explain why the package seemingly appeared following your addition of that and not before-hand; possibly it was that you hadn't actually updated before or something.

Anyhow I think your previous idea about the source list points was more workable, and there is no difference in format or interpretation or use between Devuan and Debian.

As to architectures, normally apt will keep meta information for all installed architectures; most usually the single installed architecture, but nowadays many systems are of "multiarch" kind and thus having software for multiple architectures. If you would want it to keep meta information about other architectures than the installed one(s), you either mangle architecture parameters (in a square-bracketed phrase just after deb) on the source list lines, or you set up an APT::Architectures apt configuration setting.

It is also a point that Devuan offers all of Debian's packages except those that are noted in https://pkgmaster.devuan.org/bannedpackages.txt and in most cases the actual package files (the .deb) are directly retrieved from Debian's repositories. Only a few packages are rebuilt and repackaged so as to make them usable on systems without systemd, and only those packages are provided from Devuan's repository pool.

Your "long-winded install command" collapses into requesting 3 packages for installation. The command should work on a Devuan system in the same way as a Debian system; it installs:

• package linux-image-$ARCH for the architecture $ARCH of the running kernel,

• package linux-headers-$ARCH for the $ARCH of the running kernel, and

• broadcom-sta-dkms

I would suggest that it's not exactly the right thing to do, since it builds a broadcom kernel module for the default kernel version rather than for the current kernel version, and it also forces installations of those default image and header meta packages. If you e.g. would run a back-ported kernel, then the command wont install the headers for that and the subsequent kernel module building may find itself being in trouble.

Rather, you would use uname -r to print out the exact version $VERSION and then install the linux-header-$VERSION package for that before installing broadcom-sta-dkms.

Firstly, I have to assume that you prepared that startfvwm95 script/program to run the binary, which by default installs into /usr/local/bin/fvwm95. Probably fine.

Next you are obviously entering a software maintenance mode which involves fixing "bugs" in the software to adapt it to the current X11 environment, and that's not something I want to commit to be involved in. I see there is a readme file regarding FvwmTaskbar; possibly related.

Good luck.