Question to experienced " Debian experiencied " people.
Are you using Flatpak and snapd to install apps not already in the official Debian repo ?
Or you don't dare doing it, risking to make your system unstable ?
As security/confidentiality and stability are important to me, I was wondering what people who have been with Debian for a long time, are doing, concerning those 2 Applications's installation standard that are cool to use for Linux Noobies/Green
My experience using snap to install e22 on Ubuntu definitely messed with my system making it unstable.
My advice: Test first on a disposableVirtualbox install, that's a fair copy of your system.
Before thinking about SNAP & flat -
we should better think at first 'bout
init - upstart - systemd
Then, when you are ready with this concept,
you might think about it - imo 
Next thoughts to this:
Which base is under the hood,
is it recommendable to use it with snap/flat -
then
which sources are reliable/worth to trust on?
You see,
words are easy, but then ... - like Linus said:
"show me the code...."
LOL. 
Both get messy but I have a tendency for flatpack too if I need a program that doesn't have Debian binaries like 'opencpn'.
For compatibility and giving the users the opportunity to use as much features as they want on elive, flatpacks & other things are by default working (on their own risk)
In the same way, "apt-add-repository" which is widely used/known on ubuntu also works on elive, so people can add any repo they want to use, this comes from the package software-properties-common, now im wondering how much we need this feature to be added on elive 
I mean, is there really any repo that can be used in debian systems? (they are normally made for ubuntu ones), do this feature should be removed?
I think adding ubuntu (or other 3rd party) repositories is asking for trouble, even if it's only the /usr/ versus /usr/share/ differences.
On top those repos (and PPAs) use different numbering and naming schemes that aren't compatible.
I think they shouldn't be used. Everything there can usually also be found as flatpack which might installs might flounder but won't destabilize the system ...... 3rd party .debs will, certainly if they're forced.
My vote is: Remove.
I think (if im not wrong) they are compatible in the sense that they cannot be added if they are not distro-named equivalent, but in any case I think that's not really going to be used by users in Elive (debian), so hum yeah, let's remove that for now...
Agreed - Bullseye doesn't support zstd-compressed packages, while Bookworm does, whereas Ubuntu's supported them for awhile so you get lovely things like "unknown compression type" on Bullseye. Which is annoying when a piece of software's Debian version is only through a PPA...
Ask me how I know.
On my work computer running Devuan I use AppImages for a few applications like Avidemux and Deflemask. Mainly because the former loads on the second or third try if I install it from deb-multimedia and is prone to crashing, while the latter is only available in this format. 
I tend to look at Flatpak and snapd as unnecessary bloat. You want to run an app that does a few simple actions and relies on GTK/Qt? Not a problem! Just install a Flatpak of the KDE/GNOME environment and keep it for the sake of this small app. I also remember one app having write access to my root folder even though Flatpaks were supposed to be sandboxed and thus isolated from the system. I'm guessing snaps should be a bit smaller in size but tied to systemd to work. Maybe I'm old fashioned, but I'm just not sold on the idea of running applications in a sandbox. Though I can see a value in containers for web applications.
To me it makes more sense to just use an alternative app, install a deb package outside of the default repos or compile the app (provided it isn't Chromium) 
Have you tried that on (de-systemded) Elive? I've never had any crashes there using the avidemux.deb.
Thanks for the suggestion! I believe I saw it preinstalled in the latest Elive beta.
I'll give it a try when I need to make light edits to videos
You can also use 'ffmpeg' directly from a terminal for minor edits:
I know and I've used ffmpeg in the past but with the help of avisynth scripts for some old family footage.
By itself, I don't think ffmpeg will trim videos for you which is the most common scenario for me. Avidemux does this but if you don't want to reencode the file, you need to trim so that the first and last frames are I-Frames. If you don't choose keyframes you might end up with a faulty file. LosslessCut does a similar thing but it also rounds up to the closest keyframes. Not always the best solution but it does help when you're in a hurry and your computer is too slow to reencode the file in time. 
I will need to do a test of installing all those "apps systems" in a tests environment and running an installation-with-upgrade-mode to see if they keep correctly installed
done