They're a necessity, if implemented correctly they can give Linux a significant edge over Windows on certain practical matters.

I using it after having problem with newer version of Krita(probably Qt dependencies) and it work fine. I don't get the hate, you just download one main file compared with one main file and all its dependencies, that sound like an upgrade to me. Tho I'm just intermediate linux user, so probably missing out some evil element of flatpak.

>>416 Well, it does depend on polkit, which is yet another component of the Linux desktop which seems a bit superfluous. Even if it isn't, it's a bad sign that it has a Javascript interpreter for some damned reason. Flatpak also depends on dbus, so you need to install some bloat in order to have Flatpak. You need Pulseaudio to handle audio too, I don't think Flatpak lets you manage audio with pure ALSA... though I think that if your sound server of choice (JACK or sndio) uses socket files to communicate, you can make them work with programs within Flatpak. The thing is, it's coming from Red Hat, which are the masterminds behind Pulseaudio and systemd, that's my pseudo crutch with the thing. You never know what they'll make it depend upon in the future. Let's just hope it's only Poettering that wants to bloat up everything.

>>419 >dbus >bloat Let's play "spot the suckless tard". Dbus is shit, not bloat.

looks like they're trying to recreate the android user space, might as well call it linux for niggers. possibly motivated by wanting more proprietary software on linux, don't most people use it for piracy? the normal-niggers they want to attract will spend 10 minutes looking through flathub and laugh at it when they don't find google maps, tindr, instagram, facebook, or any mobile games that let them use their credit card on jpegs. at this point its basically the steam installer. its a distribution within a distribution designed to address issues with the perceived problems with unix desktop-space by creating more layers of abstraction. If dynamic libraries worked the way they should, private namespaces existed, build systems were simple almost none of this would be necessary. seriously almost all desktop software on flathub is a joke. We need this though so we can run such classics as KDE's "Potato Guy" without worrying about the 50 different shared objects or security threats (gotta run it in a container) but also so that we can still have full-desktop integration and system wide communication. Its a well designed bandaid placed on a cast on a broken arm that will never heal because the cast was designed by a committee that decided bones should be more flexible. I have a better idea, how about we distribute packages in qcow format and start each application through virt-manager?

I had to use them a lot when I used Kubuntu and Mint for my desktop and laptop respectively. The Ubuntu (of which both distros are based off of) is really pushing Flatpaks and AppImages. Not only does it feel forced, but they were just a pain in the ass to use. AppImages are slightly better though i must say.

>>427 >linux for niggers As if they'd care for backwards compatibility, which is my biggest beef with non-flatpack. What if I want some random program from 1995? I'm fucked 10 ways from sunday on regular linux.

>>433 No, Canonical's (the company who makes Ubuntu) not pushing Flatpaks, they're pushing Snap, which is their own take on the same concept. Arguably worse.

>>419 >pulseaudio and systemd Pulseaudio is actually good now lol And as for systemd, something like it was not needed. Personally I don't use it because muh unix philosophy and I like building houses of cards, but it's a godsend for normalfags and devs alike. Why else would distros hop on to it so fast? It simplifies a lot of stuff like daemons, like it takes a single systemctl enable to daemonise any service and it's neatly centralised, no mucking around with scripts. Is it a good thing from the perspective of do one thing and do it good? no. But is it a godsend for usability? fuck yes it is. I miss not having to fuck around with init scripts. Too bad i finally installed gentoo and nothing short of a catastrophic hardware failure would make me undo that herculean effort.

>>444 >Why else would distros hop on to it so fast? Is this bait? >It simplifies a lot of stuff like daemons Is this double bait? Nice digits btw.

>>413 bloat and noise most likely insecure (as in sandboxing is moot) just like all linux dekstop bullshit never used them fear the day when i have to use them at work you asked

>>487 >most likely insecure (as in sandboxing is moot) Bubblewrap's unprivileged by default and doesn't use setuid, unlike Firejail. >you asked Yeah, but you could elaborate a bit on why, low effort posts aren't what people come here for.

>>490 sandboxing shit on *nix never works. the idiots who run that shit cannot tell their ass from the elbow for instance literally none of the desktop based privilege isolation on gnome ever worked (gksu/sudo/su etc can merely be keylogged by running an x client that logs keys, or attacing strace to it, etc). IT LITERALLY MAKES YOU REMEMBER AND CONSTANTLY TYPE YET ANOTHER PASSWORD - ALL WITH THE USUAL INSUFFERABLE DELAYS AND 3 ATTEMPTS LOCKOUT - FOR NO REASON AT ALL. THERE IS NOT A MODICUM OF SECURITY ACHIEVED FROM THIS THAT CANNOT BE BYPASSED for instance literally none of the extremely basic privilege isolation on assdroid worked for instance SELinux never worked and is full of vulns (and of course missed API) buw why would you assume some new idea fag's project for sandboxing is good? its because you are not in the know DAY OF THE SEAL SOON

I've never used flatpaks, but I don't like the idea of them simply because they are yet another layer of complexity added on top of an already complex system. The idea of compartmentalizing software components from each other as a security measure is an old but good idea. However, it really should be done on an OS level instead of as an extra 3rd party layer. If on the other hand, the purpose is not security, but to avoid dependency hell, then the problem should be solved on the package management layer by the OS, not by a 3rd party component. However, since Linux is not an OS, but just a kernel, a proper fix is likely never going to happen, so we get these weird middleware solutions like flatpak instead. PS. Since I've never actually used them, I could have misunderstood the point of them completely, but OP's post seems to suggest that I am at least somewhat correct.

>>496 >FOR NO REASON AT ALL The reason is that Linux is designed by basement dwellers, and those people will go to great lengths to create complicate rituals which can kind of distract you from how shitty things reall are.

>>496 >you are not in the know >conflating gksu and sudo with sandboxing tools >not knowing that the nature of X itself is what allows keyloggers to grab those passwords, and Wayland actually solves this Geez, it's like you're not in the know.

>>504 >>not knowing that the nature of X itself is what allows keyloggers to grab those passwords, and Wayland actually solves this >what is alias >what is ptrace >what are the 9000 other ways to intercept password from sudo you are just proving why >>503 is right in 2000, infosec bros were already constantly explaining the sudo problem and lintards just ignore and continue cargo cult. after 20 years your solution is adding vsync? i will make a new prediction: linux will never have a way to do sudo that actually adds any real security, ever

>>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?