That ISO works fine in QEMU/KVM: https://dev1galaxy.org/viewtopic.php?pid=39677#p39677

No idea about Virtualbox but I would suggest that daedalus not working in that is a feature rather than a bug. You should thank the developers for steering you away from the worst virtualisation "solution" around.

The package versions for the stable release are frozen some time before the release. That's why it's called "stable". There are a few notable exceptions to this, such as firefox-esr & chromium, because of the security risks of an outdated version.

See https://www.debian.org/doc/manuals/debi … tml#s3.1.3 & https://wiki.debian.org/DontBreakDebian … f_Syndrome for further explanations as to why the latest version might not be the best option.

Don't forget the [testing], [community-testing], [multilib-testing], [kde-unstable] & [gnome-unstable] repositories.

Arch doesn't care about licencing. They don't even use SPDX identifiers in the license array. It is a user-centric distribution and so caters to the needs of the user rather than pandering to political principles.

The various repositories in Arch have very specific requirements, none of which are related to the licence: https://wiki.archlinux.org/title/Official_repositories

EDIT: and Arch tends to be bloated because the packages are usually compiled with most options enabled and they don't use split -dev packages, unlike Debian.

Why didn't you try the version from unstable?

This one seems to have those: https://github.com/mate-desktop/mate-me … -819028411

I think this would be better pursued in the bug report(s) rather than here. Sorry but I can't help otherwise.

EDIT: did you see the suggested workaround? The volumeicon-alsa package should also work in MATE if you can't get the native volume systray thingie working.

I think nftables should be the default backend for any "iptables" implementations.

See https://wiki.debian.org/nftables and run

for i in {ip{,6},arp,eb}tables ; do sudo update-alternatives --config $i ; done

All of the alternatives should be pointing to *tables-nft, change them if they don't.

Check for any extant iptables configuration with

# iptables-save

I'm pretty sure that should be blank.

/etc/init.d/nftables calls /usr/bin/nft -f /etc/nftables.conf so the file doesn't actually need a shebang.

EDIT: use this to check after the service starts:

# nft list ruleset

https://raphaelhertzog.com/2011/01/31/d … ion-files/

The browser is the single biggest potential vulnerability in a desktop system, which is why Debian actually update their firefox-esr & chromium packages even for the stable release. Using an outdated browser is a really bad idea.

That's pretty old.

If you really want to use a browser for which Debian support is non-existent then at least use the latest version:

https://dl.iridiumbrowser.de/fedora_37/

But it's still a really bad idea. How do you keep it updated against the steady stream of CVEs?

If you just want a firewall that only allows ports 22, 80 & 443 see https://wiki.nftables.org/wiki-nftables … r_a_server

ufw is bloat!

Perhaps check the Synaptic log as well but I thought all package management operations were collated under the dpkg log.

Those packages don't seem to have been added to the banned list.

Have you checked the logs?

zcat /var/log/dpkg.log.*.gz | cat - /var/log/dpkg.log | grep 'ufw'