Glibc preserves backward compatibility, so if you build against the oldest version you want to support, the resulting binary will work with newer ones.
However that’s definitely not what I recommend to do. Better learn packaging and build native packages for distros you are going to support. OBS can make this a bit easier (if your software is FOSS), but any modern CI will also do the job.
Isn’t that video stream already compressed? Or you want to convert it using another codec/bitrate?
Is it still alive? I switched to LibreTube and happy with it.
The native directory sharing method for kvm is virtiofs. Have you tried it?
Why not use Privacy Badger to prevent usage of tracking cookies?
I recommend to throw away this drive because blocks that are readable and writeable now, may fail soon. But if you want to use it anyway, it is possible to collect a list of unaccessible blocks usong badblocks and pass it to mkfs to create a filesystem that ignores that blocks. IIRC this is described in man badblocks.
I have read this. There are no details about attacked projects, mail texts, addresses and github logins, nothing. It’s even impossible to ensure that attack attempts really took place. One may guess they occured before the xz attack disclosure and were performed by different actors because thay seem much more dumb.
Continue? There are no details on attack attempts published, even when they occured.
gksu and kdesu are unsupported for >10 years iirc, they were not more secure than sudo and that’s one of the reasons they were abandoned. I’ve never heard about sux. Polkit is a bit another thing that indeed replaced them, however it does not and can not separate GUI and non-GUI processes. The process itself has to fork, drop privileges and draw a GUI after that. There’s no difference between running it via sudo or pkexec, however polkit provide additional protections to prevent running unsafe apps with elevated privileges.
PAM and GVFS are not “privilege elevation frameworks” whatever you mean by this.
Idk what is bleachbit. But I know that “auth systems” can’t “handle GUIs in a secure fashion”. The app itself can be secure or not. By default they are not secure if they provide a GUI running in privileged process.
I know. Don’t do this. Read the manual.
It’s not when app was written. Wayland apps probably work with sudo, x11 don’t because sudo does not pass the $DISPLAYenvironment variable. It’s a correct behavior of sudo because running x11 apps with root permission you create a security hole.
Too many files in a directory?
Probably? They won’t run with sudo normally (in xorg at least). And only those explicitly allowed to be run with pkexec by maintainers will do. Of course it is possible to evade this restriction, but you definitely should not.
deleted by creator
Sysadmin GUI tools are designed to be secure by isolating GUI from privileged process. That is not true for a random GUI app.
Nope. Running GUI as root in the same X server as unprivileged apps is insecure because each of them can take control over privileged window. IDK if this issue has been addressed in Wayland, but anyway there are no wayland-only distros nowadays.
Don’t do this. I’m unsure if this works in any distro, but if it does, this is unsecure.
Don’t do this. I’m unsure if this works in any distro, but if it does, this is unsecure.
man jq