Why does flatpak make /g/ seethe?

I like it

I tried to like it, but installing them on a slow drive makes running anything in $PATH take several seconds longer

>>92989708 (OP)

Because it works and /g/ needs something that doesn't to so they can "fix" it and make something of their miserable lives

>>92989708 (OP)

it made me seethe because it doesn't the solve the problem it was made for.

if the issue was with dependencies then why not modify RPM or dpkg so that they can use older packages and keep the latest ones?

flatpaks also try to "solve" other issues by locking down the directories each app is allowed to access, we already had user permissions for that.

it's just redundant bloat.

>>92989708 (OP)

Slow, insecure and bloated. Even flatshit is better because at least they are maintained by the devs who make the software.

>zoomzooms reinvent static linking but a million times more bloated

It's all so very tiresome.

is this a bot thread? i think it's good. 

>hurr .2 second launch slowdown

have sex.

fairly sure most posts are ai nowadays to pump up traffic

>>92989708 (OP)

Only issue I have is the retarded command you need in order to run them ie. flatpak run com.github.someuser.someproject/main

just use bash alias?

Consider removing the flatpak exports from your path and just adding a few aliases to flatpak things instead. Or shit in local share applications

>>92989708 (OP)

Luke Smith says it's bad so it must be true.

I use it for apps I don't trust only, such as spotify and discord, at least it's not snap.

>>92989708 (OP)

Bloat king, it can't use OS libraries, encourages bad developer behaviour regarding maintenance, barely any packages have upstream support but that's not really the fault of flatpak 

For what it does it's closeish to being the best solution available and at least it mostly works

>>92989708 (OP)

flatpak and snaps style containerization is a waste of space and processing power



there's pretty much no situation in which just static linking libraries doesn't give you the exact same end result

Flatpak's sandboxing actually works decently, the problem is that its permission system is similar to Android pre-6 where apps will make you blanket allow so many permissions to the point it's effectively useless. In fact, all a flatpak application has to do to escape the sandbox is gain permission to your home directory and then sneak something into ~/.bashrc or similar.

Obviously the chances of this actually happening in the current Linux desktop scene is unlikely (who wants to target a bunch of neckbeards instead of the real deal server guys) but if a company like Valve really wants to push this as the new "standard", it's something that will have to be considered

Also, flatpak runs like shit anyway. I'm not waiting an extra two seconds for Chrome to start for some false sense of "security" or whatever

>>92989708 (OP)

- installs in my home

- doesn't use my theme

- doesn't export desktop files correctly

- doesn't export to PATH as normal program

>>92989708 (OP)

A lot of the hate for flatpak comes from people just not understanding it. It's a pretty good solution. Not perfect but significantly better than snap.

This is not static linking

>>92989708 (OP)

because it is ridiculous

>want to run bloat

>blame the package manager

silly you

It kinda works and there is potential for greatness but there are so many papercuts

Any other answer is autism

>>92989708 (OP)
