oh my god that article is so misleading
First off yes by definition when you run flatpaks you run a container with its own libraries that needs to be downloaded. Obviously, it can't use your system libraries because that would cause incompatibilities. Thus it pulls the required libraries.
It is no different than getting a bare arch system and installing kcalc on it. It will pull the required Qt and KF5 dependencies.
The applications themselves as pictured in the image right here are tiny in most cases.
With the only edge cases being applications that come with their own libraries in order to work properly(for example some latex editors will have huge flatpaks due to the fact that they come with latex) > oh but my hugeass updates
best part about all of this is that flatpaks actually do delta updates. they will do the best they can do download only the files that changed after an update.
Is it better when it comes to size to traditional packages? no is it better than snap/appimage while doing the same? hell yes.
>Obviously, it can't use your system libraries
this is why it's a shitty idea. For any given library, there should be exactly one version of it on the system. Upstream projects should not be just freezing their dependencies for all eternity.
>For any given library, there should be exactly one version of it on the system
there is literally no argument in favor of this except "muh bloat"
2 years ago
Anonymous
A wild CVE appears. Do you want it fixed once for everything, or require each individual upstream to notice it and update it, whereupon you get to update every single application using it?
>Upstream projects should not be just freezing their dependencies for all eternity.
usually the problem is that upstream wants to use newer dependencies but can't.
supporting bleeding-edge dependencies is fine, requiring them isn't
>Upstream projects should not be just freezing their dependencies for all eternity.
usually the problem is that upstream wants to use newer dependencies but can't.
>this is why it's a shitty idea. For any given library, there should be exactly one version of it on the system.
this is impossible. not because of any technical reason but because package managers litterally can only do so much for each distro. The amount of work that needs to be done is insurmountable for that level of support.
No distro right now has complete support for all packages but at least with flatpaks we can focus on a single platform. Not to mention it helps with its containerized design.
A wild CVE appears. Do you want it fixed once for everything, or require each individual upstream to notice it and update it, whereupon you get to update every single application using it?
[...]
supporting bleeding-edge dependencies is fine, requiring them isn't
>supporting bleeding-edge dependencies is fine, requiring them isn't
Because sometimes you want to use that new thing you've been waiting for quite a while and can't because some homosexuals want to stay a million dependencies back. So your choice is either lose the userbase or use flatpak and let it handle everything.
This puts more power to the application developers.
And sometimes some motherfrickers just package shit wrong(looking at you debian) or nearly abandon packaging(looking at you debian)
With flatpak you can have a reliable package you can be certain works everywhere, you dont have to deal with fedora keeping its ffmpeg stuff in a separate repo which causes issues to firefox viewing videos you dont have to deal with someone else just deeming some dependency non-necessary and the users complaining that parts of the application just don't work.
You also (and this is the best part) dont have to tell your users to install a fricking unofficial package which you haven't tested because you are not the package manager for the distro.
2 years ago
Anonymous
>No distro right now has complete support for all packages
Mine has packages for everything I need and if it doesn't I can easily create one. > but at least with flatpaks we can focus on a single platform
Which is not my platform, so it's shittier. >Not to mention it helps with its containerized design.
Pointless for normal desktop stuff.
2 years ago
Anonymous
It is your platform. You can easily use it in your system of choice.
2 years ago
Anonymous
>It is your platform. You can easily use it in your system of choice.
No, it's not. If it's not using my libraries it's not going to use my patches and customizations either. It's not my platform. It's shit.
>there should be exactly one version of it on the system
And that's why most Linux systems are either unstable messes or frozen in time.
I can't wait for native package managers to also be able to install multiple versions of dependencies as needed.
2 years ago
Anonymous
Nix can already do this.
2 years ago
Anonymous
Don't all apps need to be patched to work with it? Also, doesn't it need to compile from source in general?
Flatpak doesn't have this problem.
That's what I was saying, anon. Read the thread.
2 years ago
Anonymous
>Don't all apps need to be patched to work with it?
No, this is simply a matter of configuring the sources correctly during the build process. Nearly every software project supports arbitrary prefixes. Even Flatpak makes use of that feature to.some extent (the /app prefix). Those that don't support it can be made compliant through other means by the build process. This is a complete non-issue. >Also, doesn't it need to compile from source in general?
Yes, like literally every build system out there. That doesn't mean you can't distribute binaries with it. In fact, Nix makes it particulaely easy to distribute binaries.
2 years ago
Anonymous
So, if I were a dev of an arbitrary program and I wanted to support Nix, it would be as easy as making a deb or a rpm?
2 years ago
Anonymous
Generally, yes. Sometimes even easier (for example, languages like Go, Haskell or Rust are usually very hard to package cleanly with deb and rpm, but quite easy with Nix).
2 years ago
Anonymous
Flatpak doesn't have this problem.
2 years ago
Anonymous
Flatpak cannot be used as a host package manager so it isn't a viable solution to the problem.
2 years ago
Anonymous
Host package managers are obsolete. Image based distributions are the future.
2 years ago
Anonymous
The image-based distros + Flatpak concept is all just one massive cope workaround because the idea of a multi-version capable host package manager was somehow never conaidered by Red Hat engineers.
They're garbage. The basically main repo (flathub) is filled with shitty packages like repackaged debs. The entire thing is just a plot to make proprietary software distribution easier.
Use Guix if you want features like user packages and stuff. It does it much better anyways.
>The entire thing is just a plot to make proprietary software distribution easier.
A lot of proprietary software don't have viable FOSS alternatives at the moment. It helps to make the Linux experience easier for people who need that software.
>the point is to kill off that software
No, it's not.
The point is to not being locked to an unsafe and potentially compromised OS like Windows.
Using proprietary software within Linux is just fine.
I believe guix is one of those 100% foss distros so it doesn't apply to it. but pretty much everyone else's packages rely on unpacking and repacking from ubuntu.
if you install something terrible(i.e. Edge) on any distro that packages it its build using the deb file for ubuntu.
>Use Guix if you want features like user packages and stuff. It does it much better anyways
This. You can even install it as an additional package manager on top of your GNU/Linux distro. I'm using it on my Debian machine.
https://guix.gnu.org/manual/devel/en/html_node/Binary-Installation.html
In particular, the guix shell and guix pack commands are extremely useful to me:
https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix-shell.html
https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix-pack.html
Nix is what all these universal formats should have been. Nix's only disadvantage compared to them is its lack of sandboxing, which may not even be a disadvantage depending on who you ask. Flatpak only has sandboxing because it already wraps everything in a container to work around its lack of sane dependency management, so tacking on sandboxing was just convenient at that point.
Guix gets the odd thing or two right, such as having an integration for GTK icon cache updates, but is much worse than Nix in nearly every other aspect, including >being written in an obscure and slow as frick language >using that same obscure and slow as frick language for all the packaging code >having bad support for package composition and modification >having bad support for external repos >marrying the CLI to the package repo, making use of multiple versions of the package repo an extremely annoying task
Guile is an excellent language, and completely destroys Nix as a DSL and a general purpose language
2 years ago
Anonymous
>completely destroys Nix as a DSL
Enjoy your shitty string concatenation I guess >and a general purpose language
Nix isn't trying to be a general purpose language. Using a general purpose language for describing packages was a massive mistake as evident by the performance problems Guix has and the mitigations for it making the whole thing much more annoying to use than it needed to be, like how you need to import hundreds of modules one by one just to get to all the packages you need.
flatpak steam doesnt start because my music and videos folders are symlinks to ones on my hard drive. Have fun using your dogshit software and defending it
Then what was going on, homosexual? Or are you full of shit?
2 years ago
Anonymous
frick knows what was wrong, but that was the only and the last time i was making a script that removes my awesome symliks, launches steam and creates them again. suck me backwards "homosexual"
2 years ago
Anonymous
*the manual said "flatpaks just work" so people like you are the full of shit fricks that just say how awesome those dumpster fire android apps are. I feel like im having my time wasted any time i try using flatpaks
man even without flatpaks the steam app is just a mess no joke.
Do you know how many hacks steam needed to run as a flatpak?
it is single-handedly one of the worst applications to package in linux.
Also i guess you don't know but you are supposed to also change your default xdg directories and have them look at wherever you put that music and pictures
also no, not doing that. i want my xdg folders to be all pretty and shit in the home folder. if you have issues with that idgaf it works fantastically on plasma with all native apps
I use them, but they're poorly integrated into the OS so I suffer from VSCodium not having access to binaries such as npm and KeePass not being able to connect to my flatpak-installed browser.
Conceptually it seems good, but I fricking despise flathub.
Never download anything from flathub unless the developer provides a link to it.
Steam, Spotify, Discord ect are all packaged by a third party, adding yet another attack vector
generally the publishers of applications do provide flatpak packages on flathub on their own.
Proprietary applications are in fact packaged by third parties(mostly because those developers have not addopted it yet) but this is really no different to how it works on all distros that are not ubuntu/debian or rhel/fedora.
Good thing is all of these use the deb files directly from the developer.(again no different to how most other package managers do it on different distros)
And while it isn't perfect all flatpak GUI front ends will tell you if some permission changed.
direct-from-developer builds are garbage 100% of the time and any packaging "format" that blindly pulls from upstream is garbage by proxy
there is no point in having an app store if it's uncurated
i know like two developers of rather popular applications and they've both told me that all distros manage to package shit wrong which results in them getting issues in their github repo that they have no power over.
One of these can't do flatpak anyway because of the nature of the application. So he just asks for others(i.e debian) to not package it because its very important that it is the latest version.
The other asked everyone politely to stop packaging it and just use the flatpak since people frick it up.
>im getting oppressed by issue spam
yeah okay buddy
the only times i seen builds fail with regular build commands is when some developer tries to do something stupid with their build automation
modern languages have system-agnostic build chains and the languages that don't have defacto standard tools for this
something is wrong with your code if you have to significantly mess with that process to get a successful build
>the only times i seen builds fail with regular build commands is when some developer tries to do something stupid with their build automation
the developer does not build the application on distros dumbass, the distro packaging team does. If he fricks up the blame falls on the dev.
2 years ago
Anonymous
That's the point. The packaging team shouldn't have much trouble packaging the software, unless the software misuses its build system in a moronic way. Some applications do absolutely insane things like installing and auto-updating their own dependencies via pip install on startup. If the blame for that falls on the upstream devs, they very much deserve it. They should be made aware that their distribution mechanism is beyond moronic.
Honestly, they're a godsend. I use it as a backup in case a piece of software I want to use isn't in the repos. Also, it makes Linux elitists seethe so much it's hilarious.
I have no particular opinion either way, so far it more or less works. I find it odd that you don't need to be sudo to install a flatpak package which may or may not be a security problem.
Host package managers are obsolete. Image based distributions are the future.
The image-based distros + Flatpak concept is all just one massive cope workaround because the idea of a multi-version capable host package manager was somehow never conaidered by Red Hat engineers.
>i-image bad because i say so, alright?
Shut the frick up moron.
2 years ago
Anonymous
>>i-image bad because i say so, alright?
Yes they are, homosexual. Prove me wrong. Prove to me how downloading an entire pre-baked image that you can't modify and then downloading the exact same packages a second time within Flatpak is somehow superior to just having a good package manager that can do everything in one place.
2 years ago
Anonymous
>Prove to me how downloading an entire pre-baked image that you can't modify and then downloading the exact same packages a second time
System packages should be strictly off-limits from the userspace. It actually has stability unlike your snowflake troony packages.
2 years ago
Anonymous
Why do Flattrannies not realize that logical separation doesn't require physical separation? It's so simple even a toddler could understand it. If the exact package required by the application is already installed as part of the system, use the same package because it's already installed. If not, install the required version side by side. This is an extremely obvious optimization, yet Flattrannies refuse to see it.
2 years ago
Anonymous
I'm talking about image based core system stupid snowflake troony. Of course flatpak will deduplicate compatible libraries.
You troony morons can't even think straight. This is why nobody cares about your cult.
>Opinions on flatpaks >Do you like them why and why not? >simple prog/game that is advertised to be 300GB download and 800GB disc space
I don't know if it's a quirk of the system or it actually does carry the numbers, but I'm not exactly willing to test it.
In theory it's not so bad, the biggest part of the download is the runtime, which will be shared across multiple programs. However, if you install many programs, you will quickly find that they use a bunch of different runtimes. 10 programs will probably have 5 different runtimes and even with per-file deduplication they will take up a ton of space being installed simultaneously.
source distribution is the only correct distribution
everything else is just different shades of shit
just use windows or mac if you're so attached to binary blobs
Flatpak itself depend on these packages in the core system you fricking stupid snowflake troony. Do you think flatpak installs a different version of DRI/DRM/FUSE/GDbus you stupid snowflake troony? KYS.
Your troony snowflake brain has corroded and you think shit like python belongs to core system while it doesn't. Shut the frick up if you don't have any idea on what you are trying to say snowflake.
>Flatpak itself depend on these packages in the core system
That does not mean it uses those for applications. >Do you think flatpak installs a different version of DRI/DRM/FUSE/GDbus you stupid snowflake troony?
YES it does. Why do you think this shit keeps working on distros that use musl and other obscure shit? Flatpak installs separate versions of all those things, as well as glibc, GTK, Qt and other libraries Flatpak applications use. Sometimes I get the feeling the only reason Flattrannies aren't utterly repulsed by their own software is the fact that they have no idea how it even works.
https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/blob/master/elements/platform.bst
https://gitlab.gnome.org/GNOME/gnome-build-meta/-/blob/master/elements/sdk-platform.bst
https://github.com/KDE/flatpak-kde-runtime/blob/qt5.15lts/org.kde.Sdk.json.in
Great will be the day when Flattrannies and RedHat Black folk collectively ACK themselves.
https://gitlab.com/search?project_id=4339844&search=libdrm
https://gitlab.com/search?project_id=4339844&search=libfuse
https://gitlab.com/search?project_id=4339844&search=gdbus
gdbus is part of glib btw, moronic Flattroony who doesn't know xir own development stack.
2 years ago
Anonymous
None of these are a part of flatpak you braindead tranyy snowflake. Go weep and dilate.
^^this
its last resort solution for complex dependancy hell type of applications that just need to "work" ...otherwise its duplicate bloatware burning a hole in my drivespace
The biggest problem with "self contained" is that people generally assume this requires some form of containerization. Nix has proven that this can be achieved without containers, by simply eliminating global search paths and baking automatically generated absolute paths into the packages. This also means that Nix can act as a package manager for kernels, bootloaders, drivers, anything, whereas Flatpak is limited to GUI programs only.
Blender in my distro's repos is over 6 months out of date, while the Flatpak is on the current version. I think that's good enough for me.
you just unzip the blender from their website and it works
is this the iq of flatpakjeets?
You have to manually maintain the symlinks and PATH variables for every single update.
? you just cd blender/ and ./blender
>bloatpak
https://ludocode.com/blog/flatpak-is-not-the-future
oh my god that article is so misleading
First off yes by definition when you run flatpaks you run a container with its own libraries that needs to be downloaded. Obviously, it can't use your system libraries because that would cause incompatibilities. Thus it pulls the required libraries.
It is no different than getting a bare arch system and installing kcalc on it. It will pull the required Qt and KF5 dependencies.
The applications themselves as pictured in the image right here are tiny in most cases.
With the only edge cases being applications that come with their own libraries in order to work properly(for example some latex editors will have huge flatpaks due to the fact that they come with latex)
> oh but my hugeass updates
best part about all of this is that flatpaks actually do delta updates. they will do the best they can do download only the files that changed after an update.
Is it better when it comes to size to traditional packages? no is it better than snap/appimage while doing the same? hell yes.
>Obviously, it can't use your system libraries
this is why it's a shitty idea. For any given library, there should be exactly one version of it on the system. Upstream projects should not be just freezing their dependencies for all eternity.
>For any given library, there should be exactly one version of it on the system
there is literally no argument in favor of this except "muh bloat"
A wild CVE appears. Do you want it fixed once for everything, or require each individual upstream to notice it and update it, whereupon you get to update every single application using it?
supporting bleeding-edge dependencies is fine, requiring them isn't
my package manager takes care of it
>Upstream projects should not be just freezing their dependencies for all eternity.
usually the problem is that upstream wants to use newer dependencies but can't.
>this is why it's a shitty idea. For any given library, there should be exactly one version of it on the system.
this is impossible. not because of any technical reason but because package managers litterally can only do so much for each distro. The amount of work that needs to be done is insurmountable for that level of support.
No distro right now has complete support for all packages but at least with flatpaks we can focus on a single platform. Not to mention it helps with its containerized design.
>supporting bleeding-edge dependencies is fine, requiring them isn't
Because sometimes you want to use that new thing you've been waiting for quite a while and can't because some homosexuals want to stay a million dependencies back. So your choice is either lose the userbase or use flatpak and let it handle everything.
This puts more power to the application developers.
And sometimes some motherfrickers just package shit wrong(looking at you debian) or nearly abandon packaging(looking at you debian)
With flatpak you can have a reliable package you can be certain works everywhere, you dont have to deal with fedora keeping its ffmpeg stuff in a separate repo which causes issues to firefox viewing videos you dont have to deal with someone else just deeming some dependency non-necessary and the users complaining that parts of the application just don't work.
You also (and this is the best part) dont have to tell your users to install a fricking unofficial package which you haven't tested because you are not the package manager for the distro.
>No distro right now has complete support for all packages
Mine has packages for everything I need and if it doesn't I can easily create one.
> but at least with flatpaks we can focus on a single platform
Which is not my platform, so it's shittier.
>Not to mention it helps with its containerized design.
Pointless for normal desktop stuff.
It is your platform. You can easily use it in your system of choice.
>It is your platform. You can easily use it in your system of choice.
No, it's not. If it's not using my libraries it's not going to use my patches and customizations either. It's not my platform. It's shit.
>there should be exactly one version of it on the system
And that's why most Linux systems are either unstable messes or frozen in time.
I can't wait for native package managers to also be able to install multiple versions of dependencies as needed.
Nix can already do this.
Don't all apps need to be patched to work with it? Also, doesn't it need to compile from source in general?
That's what I was saying, anon. Read the thread.
>Don't all apps need to be patched to work with it?
No, this is simply a matter of configuring the sources correctly during the build process. Nearly every software project supports arbitrary prefixes. Even Flatpak makes use of that feature to.some extent (the /app prefix). Those that don't support it can be made compliant through other means by the build process. This is a complete non-issue.
>Also, doesn't it need to compile from source in general?
Yes, like literally every build system out there. That doesn't mean you can't distribute binaries with it. In fact, Nix makes it particulaely easy to distribute binaries.
So, if I were a dev of an arbitrary program and I wanted to support Nix, it would be as easy as making a deb or a rpm?
Generally, yes. Sometimes even easier (for example, languages like Go, Haskell or Rust are usually very hard to package cleanly with deb and rpm, but quite easy with Nix).
Flatpak doesn't have this problem.
Flatpak cannot be used as a host package manager so it isn't a viable solution to the problem.
Host package managers are obsolete. Image based distributions are the future.
The image-based distros + Flatpak concept is all just one massive cope workaround because the idea of a multi-version capable host package manager was somehow never conaidered by Red Hat engineers.
They're garbage. The basically main repo (flathub) is filled with shitty packages like repackaged debs. The entire thing is just a plot to make proprietary software distribution easier.
Use Guix if you want features like user packages and stuff. It does it much better anyways.
>The entire thing is just a plot to make proprietary software distribution easier.
A lot of proprietary software don't have viable FOSS alternatives at the moment. It helps to make the Linux experience easier for people who need that software.
the point is to kill off that software, not accommodate it
Make viable FOSS alternatives then. Kdenlive is not a viable replacement for DaVinci Resolve.
>kill it with no alternative
>the point is to kill off that software
No, it's not.
The point is to not being locked to an unsafe and potentially compromised OS like Windows.
Using proprietary software within Linux is just fine.
> Freetard preaches freedom
> Except for things he doesn't like
> In that case, let's kill it
I believe guix is one of those 100% foss distros so it doesn't apply to it. but pretty much everyone else's packages rely on unpacking and repacking from ubuntu.
if you install something terrible(i.e. Edge) on any distro that packages it its build using the deb file for ubuntu.
>Use Guix if you want features like user packages and stuff. It does it much better anyways
This. You can even install it as an additional package manager on top of your GNU/Linux distro. I'm using it on my Debian machine.
https://guix.gnu.org/manual/devel/en/html_node/Binary-Installation.html
In particular, the guix shell and guix pack commands are extremely useful to me:
https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix-shell.html
https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix-pack.html
I prefer snap
What about nix bros? Seems much saner than both snaps and flatpaks.
Nix is what all these universal formats should have been. Nix's only disadvantage compared to them is its lack of sandboxing, which may not even be a disadvantage depending on who you ask. Flatpak only has sandboxing because it already wraps everything in a container to work around its lack of sane dependency management, so tacking on sandboxing was just convenient at that point.
It's ok but it's a complete clusterfrick, Guix is similar but much cleaner and better designed
Guix gets the odd thing or two right, such as having an integration for GTK icon cache updates, but is much worse than Nix in nearly every other aspect, including
>being written in an obscure and slow as frick language
>using that same obscure and slow as frick language for all the packaging code
>having bad support for package composition and modification
>having bad support for external repos
>marrying the CLI to the package repo, making use of multiple versions of the package repo an extremely annoying task
Guile is an excellent language, and completely destroys Nix as a DSL and a general purpose language
>completely destroys Nix as a DSL
Enjoy your shitty string concatenation I guess
>and a general purpose language
Nix isn't trying to be a general purpose language. Using a general purpose language for describing packages was a massive mistake as evident by the performance problems Guix has and the mitigations for it making the whole thing much more annoying to use than it needed to be, like how you need to import hundreds of modules one by one just to get to all the packages you need.
Out of the 3 competitors in its class (Flatpak, Snap, AppImage) it is by far the best one. That doesn't make it good in general, not by a long shot.
flatpak steam doesnt start because my music and videos folders are symlinks to ones on my hard drive. Have fun using your dogshit software and defending it
Just give it permission to access your hard drive via Flatseal?
just suck me off? That wasn't even what was going on
Then what was going on, homosexual? Or are you full of shit?
frick knows what was wrong, but that was the only and the last time i was making a script that removes my awesome symliks, launches steam and creates them again. suck me backwards "homosexual"
*the manual said "flatpaks just work" so people like you are the full of shit fricks that just say how awesome those dumpster fire android apps are. I feel like im having my time wasted any time i try using flatpaks
man even without flatpaks the steam app is just a mess no joke.
Do you know how many hacks steam needed to run as a flatpak?
it is single-handedly one of the worst applications to package in linux.
Also i guess you don't know but you are supposed to also change your default xdg directories and have them look at wherever you put that music and pictures
also no, not doing that. i want my xdg folders to be all pretty and shit in the home folder. if you have issues with that idgaf it works fantastically on plasma with all native apps
bloatware
takes away user freedom
just use mac if you want a walled garden app store experience
I use them, but they're poorly integrated into the OS so I suffer from VSCodium not having access to binaries such as npm and KeePass not being able to connect to my flatpak-installed browser.
VS Code should remote-connect into Silverblue toolbox.
https://discussion.fedoraproject.org/t/toolbox-and-visual-studio-code-remote-containers/27987
Yes, I like having a designated proprietary street. I get open-source programs from the pkg mngr, and proprietary on flatpak.
Conceptually it seems good, but I fricking despise flathub.
Never download anything from flathub unless the developer provides a link to it.
Steam, Spotify, Discord ect are all packaged by a third party, adding yet another attack vector
Steam deck uses flatpak packaging
Which is a massive oversight on Valves part
Why? What's your alternative?
>Why? What's your alternative?
In a perfect world, emerge steam.
>just wait 5 hours to update your steam client bro
Like you could play any games on a machine where it takes anywhere close to 5 hours.
>who needs to play games when you see your machine overheating while updating the steam client for 5 hours bro!
Why are freetards like this?
Imagine being this moronic.
Shut up freetard. Nobody gives a frick about your special snowflake gentoo tinker troony setup.
Don't care, works on my machine. Without moronic workarounds like flatpak.
Head back to desktop threads freetard troony. People out here solving actual problems.
I don't have that problem.
Ok freetard. Go back.
have sex
Glow somewhere else.
tar -xf steam.tar.gz
cd stream
./configure
make
make install
You should really try a mac, I just move it into my applications folder.
Now recursively resolve all dependencies and keep that shit up to date.
Still use flat-packs, but actively encourage devs to upload their builds to flathub instead of relying on third parties to upload them
generally the publishers of applications do provide flatpak packages on flathub on their own.
Proprietary applications are in fact packaged by third parties(mostly because those developers have not addopted it yet) but this is really no different to how it works on all distros that are not ubuntu/debian or rhel/fedora.
Good thing is all of these use the deb files directly from the developer.(again no different to how most other package managers do it on different distros)
And while it isn't perfect all flatpak GUI front ends will tell you if some permission changed.
direct-from-developer builds are garbage 100% of the time and any packaging "format" that blindly pulls from upstream is garbage by proxy
there is no point in having an app store if it's uncurated
i know like two developers of rather popular applications and they've both told me that all distros manage to package shit wrong which results in them getting issues in their github repo that they have no power over.
One of these can't do flatpak anyway because of the nature of the application. So he just asks for others(i.e debian) to not package it because its very important that it is the latest version.
The other asked everyone politely to stop packaging it and just use the flatpak since people frick it up.
>im getting oppressed by issue spam
yeah okay buddy
the only times i seen builds fail with regular build commands is when some developer tries to do something stupid with their build automation
modern languages have system-agnostic build chains and the languages that don't have defacto standard tools for this
something is wrong with your code if you have to significantly mess with that process to get a successful build
>the only times i seen builds fail with regular build commands is when some developer tries to do something stupid with their build automation
the developer does not build the application on distros dumbass, the distro packaging team does. If he fricks up the blame falls on the dev.
That's the point. The packaging team shouldn't have much trouble packaging the software, unless the software misuses its build system in a moronic way. Some applications do absolutely insane things like installing and auto-updating their own dependencies via pip install on startup. If the blame for that falls on the upstream devs, they very much deserve it. They should be made aware that their distribution mechanism is beyond moronic.
Honestly, they're a godsend. I use it as a backup in case a piece of software I want to use isn't in the repos. Also, it makes Linux elitists seethe so much it's hilarious.
I look like that
it gets funnier every time you post that bruh
Half assed solution (of the linux packaging problem) for the least significant part of the ecosystem (that is linux desktop)
Snap is shit in its own way, but at least it can be used to package server side software and toolchains
There is nothing snap does that can't be done better and faster with something else.
Annoying as frick whenever you need to hunt down a specific file from an application. They're just added frustration.
I have no particular opinion either way, so far it more or less works. I find it odd that you don't need to be sudo to install a flatpak package which may or may not be a security problem.
This shit has been solved with package management. Stop inventing solutions nobody wants/cares about.
Flatpak solves the problems with legacy package managers
see
See
>i-image bad because i say so, alright?
Shut the frick up moron.
>>i-image bad because i say so, alright?
Yes they are, homosexual. Prove me wrong. Prove to me how downloading an entire pre-baked image that you can't modify and then downloading the exact same packages a second time within Flatpak is somehow superior to just having a good package manager that can do everything in one place.
>Prove to me how downloading an entire pre-baked image that you can't modify and then downloading the exact same packages a second time
System packages should be strictly off-limits from the userspace. It actually has stability unlike your snowflake troony packages.
Why do Flattrannies not realize that logical separation doesn't require physical separation? It's so simple even a toddler could understand it. If the exact package required by the application is already installed as part of the system, use the same package because it's already installed. If not, install the required version side by side. This is an extremely obvious optimization, yet Flattrannies refuse to see it.
I'm talking about image based core system stupid snowflake troony. Of course flatpak will deduplicate compatible libraries.
You troony morons can't even think straight. This is why nobody cares about your cult.
Love them, specially since it makes the morons in this site seethe
i can see the use as a last resort option or for proprietary software distribution, but i wouldn't use it in place of normal packages
>Opinions on flatpaks
>Do you like them why and why not?
>simple prog/game that is advertised to be 300GB download and 800GB disc space
I don't know if it's a quirk of the system or it actually does carry the numbers, but I'm not exactly willing to test it.
In theory it's not so bad, the biggest part of the download is the runtime, which will be shared across multiple programs. However, if you install many programs, you will quickly find that they use a bunch of different runtimes. 10 programs will probably have 5 different runtimes and even with per-file deduplication they will take up a ton of space being installed simultaneously.
source distribution is the only correct distribution
everything else is just different shades of shit
just use windows or mac if you're so attached to binary blobs
Flatpak itself depend on these packages in the core system you fricking stupid snowflake troony. Do you think flatpak installs a different version of DRI/DRM/FUSE/GDbus you stupid snowflake troony? KYS.
Your troony snowflake brain has corroded and you think shit like python belongs to core system while it doesn't. Shut the frick up if you don't have any idea on what you are trying to say snowflake.
>Flatpak itself depend on these packages in the core system
That does not mean it uses those for applications.
>Do you think flatpak installs a different version of DRI/DRM/FUSE/GDbus you stupid snowflake troony?
YES it does. Why do you think this shit keeps working on distros that use musl and other obscure shit? Flatpak installs separate versions of all those things, as well as glibc, GTK, Qt and other libraries Flatpak applications use. Sometimes I get the feeling the only reason Flattrannies aren't utterly repulsed by their own software is the fact that they have no idea how it even works.
https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/blob/master/elements/platform.bst
https://gitlab.gnome.org/GNOME/gnome-build-meta/-/blob/master/elements/sdk-platform.bst
https://github.com/KDE/flatpak-kde-runtime/blob/qt5.15lts/org.kde.Sdk.json.in
>no gdbus
>no libdrm
>no libfuse
I want to kill a snowflake troony today
Great will be the day when Flattrannies and RedHat Black folk collectively ACK themselves.
https://gitlab.com/search?project_id=4339844&search=libdrm
https://gitlab.com/search?project_id=4339844&search=libfuse
https://gitlab.com/search?project_id=4339844&search=gdbus
gdbus is part of glib btw, moronic Flattroony who doesn't know xir own development stack.
None of these are a part of flatpak you braindead tranyy snowflake. Go weep and dilate.
What is "these" supposed to refer to, schizo?
>why
it does the job when there's no alternative
>why not
duplicated functionality
^^this
its last resort solution for complex dependancy hell type of applications that just need to "work" ...otherwise its duplicate bloatware burning a hole in my drivespace
As far as the idea of self contained Linux executables goes, it's probably the best solution. However, the idea is flawed to begin with.
The biggest problem with "self contained" is that people generally assume this requires some form of containerization. Nix has proven that this can be achieved without containers, by simply eliminating global search paths and baking automatically generated absolute paths into the packages. This also means that Nix can act as a package manager for kernels, bootloaders, drivers, anything, whereas Flatpak is limited to GUI programs only.
>Packages: 2464 (rpm), 63 (flatpak)
seethe
They work fine. Except gzdoom flatpak is broken