>>504 >and Wayland actually solves this What is LD_PRELOAD? Walyand alone offers no protection against userspace keylogging.

>>506 >linux will never have a way to do sudo that actually adds any real security, ever doas.

>>509 KEK, It's the same problem retard. What happens when an attacker compromises your unprivileged user and sets a sudo, doas, or even su alias to a program that phones home with your password? There's literally no point to using sudo (or anything like it) as a means of privilege separation. If you really wanted security, you would change vt and login as root on your second tty. That way, if an attacker wanted your password he would have to already have root privileges and compromise login or getty or something.

It's the only saving grace for trying to run any sort of somewhat complex application in a binary form. Most distro's don't manage their system in a widely compatable way with applications so often you'll get lib.so errors for even the most basic shit like ncurses ha arch Other distros keep a snapshot of every major system change making package distribution terribly broken up by minor version changes hah debian In this way, flatpaks/appimages/snaps are basically the only sane way to alleviate the issue. That being said... Gentoo has none of these issues you should just use that instead ;^)

>>1310 >Most distro's don't manage their system in a widely compatable way with applications so often you'll get lib.so errors for even the most basic shit like ncurses I don't know, ma. Void does deal with this adequately. Never had some lib.so error when using it. Seems like Void is Arch done right, and actually being minimal. Arch's a bunch of lies, really.

>>1314 https://docs.voidlinux.org/xbps/repositories/custom.html >The Void project does not support any third-party package repositories >This is only recommended for serving custom packages created personally

>>1319 And? Void has a shitload of packages on their official repos. More than 11000. Haven't really missed much. What's your point?

>>1320 You seem to not understand the subject of discussion.

>>1320 The problem is that once something is missing, it's missing, and you're fucked. Or if you need a particular version, you're fucked. This is what makes Debian and Ubuntu hell to actually use. The moment something has a bug but only a particular version is packaged you're going to run off to compile from source and then you need to find the twenty places to register various files for the system to use it instead of whatever is packaged. I've literally purged a package from the system, installed from source, and it will still insist the installed version is the officially packaged one. How? Arch got one thing right: the AUR. The only thing they have wrong is that the default package manager should be pacaur, not pacman. Gentoo and Arch have the right approach by making compiling from source a straightforward way to install. AUR makes it almost impossible to not find the software you need and have it installed in a single line. Can't say that about any non-rolling distribution. >>1310 Seconding this. Flatpaks and Snaps are a bandage for a problem that LTS distributions created for themselves. Just install Gentoo and your dependency hell days are over.

>>1320 Holy shit not even iToddlers are this retarded.

>>1322 >This is what makes Debian and Ubuntu hell to actually use. The moment something has a bug but only a particular version is packaged you're going to run off to compile from source and then you need to find the twenty places to register various files for the system to use it instead of whatever is packaged. Usually sid and testing have the latest packages and if something in stable has a bug and is not in the backports repo you can backport it yourself. For instance, the stable version of qBitorrent has a bug that makes it crash randomly and there's no backported version, but a (manually) backported version works perfectly fine. This also ties in nicely when doing distro upgrades.

>>1322 It's amazing how many issues go away just by using the damn source code. Although while better then most the AUR is still garbage. compared to ebuilds AUR lacks major functionality like: useflags, masks, overlays, sandboxing, compiler options, good dependency resolution across the board. You could probably manage like one or two applications from the AUR but you have to get into a mindset of "what is this pkgbuild going to do to my system?" where you will constantly check what the pkgbuild contains in it's instructions just to make sure it doesn't do something like... replace your running ffmpeg version and all the codecs it contains with a git pulled version making anything with audio from official repos unusable. **this happened once and i hated every second of trying to fix it* Overlays are so much better.

>>1324 This might be acceptable for desktop use. I ran into some dependency issues trying to create a very specific development environment. And god help you if you need packages built for anything but x86_64. I just about ragequit life when I found out the version packaged for the arch/release I needed was the only one suffering from a critical bug, but Debian's maintainers decided it "wasn't a security concern", so they refused to just package any of the versions that had been released in the last few years. It ended up just being easier to rewrite a couple files so the parsing bug didn't cause it to fail, but I got lucky the tags it was failing on were non-essential. Still, this is all a huge pain in the ass, even on personal desktops. Like >>1325 said >Overlays are so much better The issue of dependencies has practically been solved by Gentoo (and to a lesser degree, Arch) but we've still got these really popular distributions run by faggots who insists "no, really, you need this release cycle for stability". All their bullshit has ever done is make me do something rash to try shoving a square peg in the round hole they gave me, which is very much unstable. Conversely, I've never fucked an Arch or Gentoo install. At least, not for package management reasons. I'm willing to accept that fucking an install is my fault, but I think Debian and Ubuntu deserve partial blame for making the most straightforward solution difficult in the name of holding the hands of newbies who probably won't touch the terminal to begin with.

>>413 Flatpaks are a security problem. If one of the dependencies that's bundled inside the flatpak has a vuln in it, even if it's been patched, then until the flatpak dev updates the flatpak to include the patch for that dependency, it'll be vulnerable. Just use the package manager included with your distro. Learning how to use apt and pacman isn't hard.

>>419 As long as it isn't more bloated than Windows, it's a good thing for the growth of desktop linux

>all this fagshit when you can just compile from source I'm a fucking Windfag and I still understand that this is overall the best scenario. Why you faggots seem so adamant to throw away one of your biggest advantages over Windblows and Appleshit all for "muh convenience" is beyond me.

>>5705 >just compile from source >retard whos never compiled anything and doesnt know how linking works

>>5709 And like I said, even *I* understand that compiling from source is a far batter option than fucking around with all of this nonsense, despite that. Why you don't go get Windows 11 while you're act it, retard?

I use Flatpak to install all my programs to my /home partition, that way everything is preserved when I distrohop

>>9590 Nice concept, didn't think about it that way. t.KDE fedora and happy (eating bugs and all)

>>413 Flatpak is good for things like games or proprietary software (keep in a ghetto where it belongs!) but it also can have some problems: https://flatkill.org The problem with Snapd is that there is only 1 repo that's managed by Canonical Ltd (and the infra uses proprietary software)

Containerizing everything isnt real package management and is going around the issue instead of solving it

>>413 Flatpak is alright, kinda bloats up the file space. Appimage is the shit though.

>>413 >opinion Something would be necessary, but nobody cares to make it. >Is it bloat I don't care. It needs to work first. >the right way The right way would be the thing that's closest to portable programs on Windows. I recognize the merits of package managers, but the package manager fetishism in the Linux community is out of control. >Flatpak Flatpak had potential but as expected from freetards, they completely fucked up the entire thing. The most important thing it's lacking is a way to DOWNLOAD THE FUCKING INSTALLER of a program. Yes, you can install them from flathub, but there's no way to download a single file that can install your program. There are workarounds to extract the data but first you have to install the program. So if you want to download a version that's not for your architecture, you can't do it. Flatpak is also only used for graphical software, which is retarded. Linux desktop is a meme, and there's no reason not to provide CLI apps too. It should also have a way to be less sandboxed because I suppose that interferes with shit. >Docker This actually works and does what it's supposed to do. I like it and use it every day.

>>413 Is that Carmack with a nigger in a headlock lol Anyway I'm finishing up a cross platform GUI application (Pyside6), what's the least unacceptable way for me to package it for Linux?

>>413 >backwards compatibility Bingo. That's everything. I first heard the words "DLL hell" decades ago. Everyone wanted desperately to solve it, but THEY NEVER FUCKING SOLVED IT. I switched to Linux and was disappointed to see that they inherited DLL hell, except they renamed it ".so hell". Maybe 35 years ago it was important to minimize disk space and memory footprint, but now with 20TB disks and 64GB RAMs, it's not a concern. I just want shit to work, and if that means switching everything to flatpak or whatever, then I'm all for it -- just get the fucking problem solved already.

>>5705 >>all this fagshit when you can just compile from source Typically, when compiling from source, people get link errors because their code needs something from a newer lib version, or else they get a "identifier not found" error because their code assumes something in a different version of a .h file that's way down in /usr/include/linux somewhere. Compiling from source was an utterly failed experiment.

>>16251 >Containerizing everything isnt real package management and is going around the issue instead of solving it Containerizing is the only solution that actually works. Everything else has proven to be just another type of DLL hell.

>>18060 Why don't people make it so the compiler checks for dependencies and installs dependencies correctly in a sort of container if needed, isn't that the best of both worlds?

>>18057 >but THEY NEVER FUCKING SOLVED IT. They did though? Windows hasn't had the dll hell problem for a very long time. You can have multiple versions of MSVCRT installed without an issue. It's also trivial to ship dlls with your program, while it's basically impossible on Linux. You can also statically link on Windows.

>>18028 >Linux desktop is a meme >It should also have a way to be less sandboxed This is the biggest shit take I've ever seen.

>>18062 the real problem is there are too many distros and package managers and it takes effort to verify and fix your software whenever it breaks due the the distro updating. sure you could just make it work but doing so takes man hours.

>>18318 Could a small model AI (EG deepseek 2b) be trained to check system specifics as part of the OS?

>>18098 Isn't it the heavy sandboxing of flatpak that makes it unsuitable for normal CLI tools?

>>18092 what... linux/ld has had static linking and rpath forever. its just things installed from a package manager use system libraries since its all controlled in one spot

>>413 All of the containering nonsense just to avoid potential flakiness of dynamic linking of glibc and the LSB when musl and uclibc had static linking support for over a decade, and with Win32 now being a more accepted target than said LSB. Either ways the actual cure is to develop Hurd or a QNX/L4-like but that would require people to change dev mindsets so it's not happening soon. t. successfully ran a shell script as an 'executable' for Xonotic in 2013