Hello:

Yes.
That is how it is done if you want to install Devuan/Raspbian.

And there are Raspbian image files available in the downloads section at Dev1.

Yes, they are a mirror of the above.

But as I mentioned, I would like to install Devuan ascii ARM64 (not Raspbian) in my RPi 3B+ but I don't know how to use the files I found in the link mentioned in my OP.

ie:

../
cdrom/                                             08-May-2019 16:37                   -
device-tree/                                       08-May-2019 16:37                   -
netboot/                                           08-May-2019 16:37                   -
MANIFEST                                           08-May-2019 16:37                3947
MANIFEST.udebs                                     08-May-2019 16:37               11424
MD5SUMS                                            08-May-2019 16:37               22425
SHA256SUMS                                         08-May-2019 16:37               30533
udeb.list                                          08-May-2019 16:37                3390

Thanks for your input.

Cheers,

A.

Hello:

To trust Devuan?
A mistake?
Surely you jest ...

Devuan is as trustworthy as any OS can possibly get, there are absolutely no trust issues with Devuan.
Why should you not trust Devuan?

What you have is an issue with a set of applications which have been/are being crippled by the growing divergence between Debian & Devuan.
Which, like the OP noted, we owe to " ... the last debian resolution whether it is interpreted by maintainers in various ways wrongly or on purpose".

To this we must add that the Debian packager for the application you use understands that the systemd issue is a purely ideological one.

And acts according to his ideology: systemd is the way to go.
ie: the only one.

This growing trend means that Devuan developers/packagers have to work more and harder.
Which I am sure you understand, takes time and resources.
Both human and monetary.

I think that are so used to it that it is possible you have lost sight of a very important fact: that you have a first class OS running your boxes free of charge.

IMHO

Cheers,

A.

Hello:

Should?
There are a great many more reasons to go systemd-free.
I confess that I was not aware of (but suspected) "... much faster / less RAM usage".

Evidently it is something the people/developers at raspberripi.org don't care about or just cannot be bothered with.
The answer I got to my post exudes the shortsighted pragmatism often seen in some forums on the web regarding systemd and I'm really at odds as to how to question it successfully.

But I cannot shake the suspicion that there could well be a dyed-in-the-wool pro systemd stance behind such pragmatism.

eg:
... It's not supported on here.
... (and any quirks it may possess) ... <--- any quirks?

Cheers,

A.

Hello:

Right ...

Thanks a lot ..  =-)

I had to tailor it a bit ...

${execpi 5 sensors | awk 'NR==3{print $1 $2 $3} NR==4{print $1 $2 $3} NR==5 {print $1 $2 $3} NR==6 {print $1 $2 $3}' | fmt -24}

... gets me this:

But I have not found a way to separate the readouts.

eg:

It seems that spaces do not count and I don't see a tab or any other argument to use.

How do I separate them?

Thanks in advance,

A.

Hello:

Which one?
HoaS's windup or systemd?   8^D!

The won'tfix issues is my main and probably only issue with Linux/Linux maintenance.

They are the stuff problems down the line are made of, that end up festering in dark and unvisited corners of a distribution.
Till one day everything goes titsup because things that were not fixed in time because it seemed they did not matter were not properly evaluated.
And came back to bite, hard.

And then it is either too late or a real bitch to fix and get things back on track again.

Cheers,

A.

Hello:

You're welcome. =-)

Yes.
That website he's set up is great.
Really neat.

I have only used inxi which I find to be excellent, so I wanted to see about smxi, which I did not know about.

Indeed ...
But Debian also means (in some way, methinks) systemd related.

As I always try to avoid installing anything from outside the Devuan repositories, I went to synaptic expecting to find it there, just like inxi.
I did not find it so I went looking for it at https://pkginfo.devuan.org/ and it had not been / was not there either.

This called my attention, which is why I asked.

I'll install it from HH's site but maybe (?) it could be added to the stable/backport repositories in the future?

Thanks for your input.

A.

Hello:

Spoke too soon ...

The problem was still there.  =^ 7
ie: Rebooting with anything storage plugged in would screw up the conky readout.

I think/guess what using UUIDs in fstab does is link the drive's UUIDs to partitions but still that leaves eventual drive letter assignments in a dynamic state, so to speak.
ie: a UUID does not get permanently linked to a drive letter.

The solution then is to point conky to the drive's UUID.

eg:

TEMPERATURES
${hr 2}
${execpi 5 sensors | grep Core | awk '{print $1 $2 $3}' | cut -c1-15}
${hr 0.3}
/dev/sda: ${execi 60 hddtemp /dev/disk/by-uuid/d6841f29-e39b-4c87-9c52-3a9c3bafe2d3 | cut -c 81-84}
/dev/sdb: ${execi 60 hddtemp /dev/disk/by-uuid/49d1369c-ed70-4543-b0ee-ef65327e101b | cut -c 83-86}
/dev/sdc: ${execi 60 hddtemp /dev/disk/by-uuid/bdf33361-5929-433e-ac7f-1a626aa6e844 | cut -c 78-81}
/dev/sdd: ${execi 60 hddtemp /dev/disk/by-uuid/c722f26d-5c9a-42a9-8c2b-6dbdf926d865 | cut -c 83-86}
/dev/sde: ${execi 60 hddtemp /dev/disk/by-uuid/ca8dbded-819d-4e2b-b017-0981a75ea718 | cut -c 101-104}

... instead of what I was using before:

TEMPERATURES
${hr 2}
${execpi 5 sensors | grep Core | awk '{print $1 $2 $3}' | cut -c1-15}
${hr 0.3}
/dev/sda: ${execi 60 hddtemp /dev/sda | cut -c 35-55}
/dev/sdb: ${execi 60 hddtemp /dev/sdb | cut -c 37-57}
/dev/sdc: ${execi 60 hddtemp /dev/sdc | cut -c 32-55}
/dev/sdd: ${execi 60 hddtemp /dev/sdd | cut -c 37-55}
/dev/sde: ${execi 60 hddtemp /dev/sde | cut -c 55-65}

Now, independently of changing my fstab to UUID (or not) now conky will run hddtemp on drives by UUID.

Cheers,

A.

Hello:

I have not been able to find out where to change this.

As I have mentioned, the output of dmesg is highlighted but the output of dmesg | grep whatever is not.

As expected, dmesg --color=always | grep whatever is highlighted.

My reasoning is that there is a script or file somewhere that sets dmesg to dmesg --color=auto, otherwise the output would be in the default b+w.

I've looked at the dmesg and terminal-colors.d man files to no avail.

There are references to $XDG_CONFIG_HOME/terminal-colors.d or $HOME/.config/terminal-colors.d to override the global setting but what I would like to is to change the global setting from dmesg --color=auto to dmesg --color=always for all the cli utilities I use, not only dmesg.  eg: ls, dir, etc.

It seems that aliases could be generated to do that but I think it would be better to make the change globally.

Is that at all possible? 

Thanks in advance,

A.