Firefox _cannot_ be recommended, I'm afraid. They have been collecting a lot of telemetry for a while; their internal governance is terrible and very oppressive; and now - they've indicated the intent to sell your data, or mine it and sell, or something along those lines - and are planning to have users give them explicit permission to do this; see this ArsTechnica coverage.

There is a patch re-enabling manifest-v3 support (it's quite trivial, i.e. the restriction is for socio-political reasons, not any technical necessity); it can also be applied on its own, but perhaps we (or Debian) should look into ungoogled chromium - which removes all of the call-home's and includes this patch and other privacy-oriented ones. I wish thaty could be a Devuan (or Debian) package.

@ralph.ronnquist : I'm not annoyed, I was just explaining why having individual users edit distribution files is not the appropriate response to this issue. Also, this issue goes waaay back, I remember experiencing it since probably Beowulf I think.

@golinux: As you may be aware, I have a bunch of FOSS that I work on on my spare time; with Devuan - the role I have the time to take is limited to reporting issues I encounter, or in other words - complaining... But you will note that I've mapped out what I see as the two remaining issues - in an effort to be constructive (comment #3).

So, one part of the problem, as explained by Stephen Kitt on StackOverflow, is that the distribution template files are missing an entry for Devuan Excalibur (!)

The template files are located at /usr/share/python-apt/templates/, and - there is a file for Devuan there - Devuan.info.

We can add to it an entry for Excalibur:

Suite: excalibur
RepositoryType: deb
BaseURI: http://deb.devuan.org/merged/
MatchURI: [a-z]{2}\.deb\.devuan\.org
MirrorsFile: Devuan.mirrors
_Description: Devuan 6 'Excalibur'
Component: main
_CompDescription: Officially supported
Component: contrib
_CompDescription: DFSG-compatible Software with Non-Free Dependencies
Component: non-free
_CompDescription: Non-DFSG-compatible Software

... unfortunately, that is not enough, two issues remain:

1. Case-sensitive comparison of "Devuan" and "devuan"  in /usr/lib/python3/dist-packages/aptsources/distro.py (probably, there should be a .tolower() call at some earlier point), and
2. The script parses the relevant meta-data wrong, concluding that the distribution's "codename" is excalibur ceres rather than just excalibur.

I'm not sure at this point how to fix that robustly; help is appreciated.

A belated congratulations from me as well -

--==[[ Happy 10th anniversay ]]==--

November 27th is also my birthday. Devuan was announced when I turned 34, and now I'm 44 (aw man... gettin' old.)

I've also made a donation today to celebrate this anniversay - and encourage others who have not donated in a while to do the same :-)

A positive review without taking an anti-systemd position. Nice! This is definitely an achievement for the project and congrats to fsmithred, golinux, and whoever else was involved from the Devuan side.

Yes, it's Nemo 4.8.6.

@golinux: Ok, fair enough in principle, but some of those descriptions are vague to the point of near-uselessness. For example:

home users also run home servers, so... not sure how they differ from non-home users. Plus, what does it mean, to build a distro with X people in mind? Do you write odes to these people in script comments? And "providing a simple layout" - what's a "layout" anyway? And does that mean it doesn't provide complex layouts? And doesn't Devuan itself "provide simple layouts"? ... None of this tells me what Refracta has or drops relative to Devuan. Maybe just different artwork, Desktop environment settings and icon arrangement?

But Devuan has OpenBox, so what's the spin? That OpenBox is on the installation media rather than other DEs?

Then how can it be based on Devuan, which has Debian's huge selection of apps? Or again, maybe it's a bootable image with some preinstalled apps?

etc.

Are there any new Devuan derivatives announced since last year?

Also, and more importantly - is there a one-liner description of what's the focus or speciality of each of these distros? Would be nice to see more than just a bunch of names.

@kjpetrie: There's an /etc/nftables.conf , and nothing in /etc/init.d.

I had a look at the man page for iptables-legacy and it didn't tell me much; are you suggesting rules be added using this binary? Ok, that sounds reasonable; but it's only half the answer: Where/how are the existing rules added?

....

Edit: Oh, I think I've found a partial solution. Your grepping suggestion gave me the idea:

# grep -r iptables *
default/ferm:# use iptables-restore for fast firewall initialization?
multitail.conf:# linux iptables firewall

the second line is a dud, but the first is part of a package called ferm, and its /etc/ferm/ferm.conf has syntax which would translate into almost all of the rules on my system:

domain (ip ip6) {
    table filter {
        chain INPUT {
            policy DROP;

            # connection tracking
            mod state state INVALID DROP;
            mod state state (ESTABLISHED RELATED) ACCEPT;

            # allow local packet
            interface lo ACCEPT;

            # respond to ping
            proto icmp ACCEPT; 

            # allow IPsec
            proto udp dport 500 ACCEPT;
	    @if @eq($DOMAIN, ip) {
	      proto (esp ah) ACCEPT;
	    } @else {
	      proto (esp) ACCEPT;
	    }

            # allow SSH connections
            proto tcp dport ssh ACCEPT;
        }
        chain OUTPUT {
            policy ACCEPT;

            # connection tracking
            #mod state state INVALID DROP;
            mod state state (ESTABLISHED RELATED) ACCEPT;
        }
        chain FORWARD {
            policy DROP;

            # connection tracking
            mod state state INVALID DROP;
            mod state state (ESTABLISHED RELATED) ACCEPT;
        }
    }
}

I think only the SSH port being open is unaccounted for in this file. Where could it be coming from?