Flathub in 2023, they have some big plans

For an example where flatpak is a good add-on look no further than musl based distros (Alpine for example). It provides me with a way to use proprietary software*, Spotify for example (and no, the web version doesn't work) which I would not be able to use otherwise.

On the downside I'm not fan of having to store multiple versions of gnome and other runtime software (total of 3.8GB) because I have two applications installed (330MB) when I also have to have a copy of gnome libs for non flatpak apps. But hey, storage is cheap right and bandwidth limitations are not a thing. (Though I'll admit that flatpak distribution is better than average)

As for monetization, I really don't see this being a thing that will work. Microsoft and Apple already tried it with their desktop OSes and neither had any traction despite the huge user base and lots of money to throw at the problem.
Now if we were talking about mobile OSes maybe this could work (but the linux/*bsd user base isn't very keen on spending money on software)

* Yes, I could install glibc and suffer many pains or try to help with gcompat and similar compatibility efforts.

Quoting: GuestI can't think of a single project that clashes with everything Unix more than Flatpak.

Um, Unix is not a religion nor the greatest thing ever created in the history of the entire universe, don't you think?


Last edited by user1 on 7 March 2023 at 7:07 pm UTC

Btw, I'd argue that Flatpak is much much closer to the Unix principle of "do one thing and do it well" than traditional package management because in Flatpak you have your regular apps and the different runtimes underneath (there are also separate runtimes for GPU drivers and separate runtimes for other system packages) and there is a clear separation between every single app and between every single runtime. With package management on the other hand, you only have this one monolithic chunk of packages with which there is no clear separation between system packages and regular apps. Everything is on the same level.

The same argument can be made about kernels - that Microkernels (that are barely used in the Unix or Unix like OS family) are actually closer to Unix philosophy than monolithic kernels...

So anyone whining about "but but muh Unix philosophy" doesn't even know what he's talking about.


Last edited by user1 on 7 March 2023 at 8:39 pm UTC

This is pollution, these containerized packaging systems.

It wastes/duplicates resources.

The applications are linked against someone else's stupid old libraries instead of my optimized ones.

You can STILL have compatibility problems when the system is using newer APIs than the libraries in the container or the common ones in the runtime that have to interface. Not ALL libraries are provided in the container environment.

The real motivation for this is borne from lazy distributors that don't want to provide the environment their users need to run applications and want to get out of compiling packages for third party software.

The biggest WHINERS are the commercial distros too, the ones that have the most resources. You don't see distros like Arch whining about providing a full environment with multilib dependencies for software and games. Hell I keep my applications running... flying by the seat of my pants even, so these hard done by commercial distributors certainly can keep things running too without resorting to this sort of kludgery.

I have real reasons why I hate this shit, it's not just philosophical objections.

Here's another personal example of running afoul of container environments. Even Steam's Proton builds give me problems because they are linked in stupid containers. This was like a revelation to me when I discovered the reason for the inconsistencies.

My proton-tkg builds use my toolchains and link against my system libraries with the exception of some in the Steam runtime to interface with Steam and run in its Proton container. Guess what? They work for every single game. I used to have to use multiple different Proton builds (some older, some newer, some upstream wine based) for different games because some code paths in them were always broken for something. For another example, the proton-media-converter (libprotonmediaconverter.so) for mediafoundation NEVER worked for me (I had to use mf-installcab to install the Microsoft libraries for Unreal 4+ games) until I compiled it with my own properly bootstrapped rustc, and linked against MY gstreamer libraries. All that time I just thought that was poo that didn't work. This is different from using the Proton-GE build system too, which does everything in podman containers now, downloading toolchains and everything from Valve and those builds suffered from the same problems, for me. (Worked for some things, not others, and protonmediaconverter NEVER worked)

No containers for me, that just won't work for my flow.


Last edited by Grogan on 7 March 2023 at 9:50 pm UTC

Quoting: Purple Library GuyOr I guess if there were open source applications that I needed, that were not available from my distro but were available from Flathub, I'd grumble and use it. But for most stuff I would prefer to use traditional package management integrated with my distro, and I will be unhappy if there is a general trend away from existing package management and I end up having to install everything as Flatpaks.

When I tried Fedora recently, I found the version of Anki offered in the official repositories was from 2-3 years ago. On Arch, I use the version of Anki built from the AUR, which also includes a much newer version of the database.

The only other ways to install Anki are through pip, the official binary installer on the website (not a great experience), or through Flatpak. The Flatpak way is quite easy. I assume most other distributions have an outdated version of Anki too, because they got sick of packaging it. I think FreeBSD is the only exception (and from memory, I believe most packagers were relying on the FreeBSD packager's work).

I know the one arena Flatpaks won't replace distribution-built packages is system-level packages like Linux, bash, and glibc. Installing browsers using Flatpak is also a dumb idea.

But...if it ever does get to that point, know that Gentoo, Nix and GNU Guix will welcome you with open arms :P


Last edited by pleasereadthemanual on 7 March 2023 at 11:42 pm UTC

I prefer Flatpak for most (not all) programs, myself. I like having a stable base with Firefox, Thunderbird, Steam and the like installed as Flatpaks. What I'm unsure about is having an immutable base + Flatpaks. I can understand the idea behind an immutable filesystem, but there have been times I needed to mess with the root filesystem.

Anyway, I'm not smart enough to start analyzing the long-term ramifications or whatever of all this. All I can say is that I like Flatpak, I like Flathub, and anything that helps both grow, and makes it easier for people to contribute, sounds good to me.

Quoting: pleasereadthemanual

Quoting: Purple Library GuyOr I guess if there were open source applications that I needed, that were not available from my distro but were available from Flathub, I'd grumble and use it. But for most stuff I would prefer to use traditional package management integrated with my distro, and I will be unhappy if there is a general trend away from existing package management and I end up having to install everything as Flatpaks.

When I tried Fedora recently, I found the version of Anki offered in the official repositories was from 2-3 years ago. On Arch, I use the version of Anki built from the AUR, which also includes a much newer version of the database.

The only other ways to install Anki are through pip, the official binary installer on the website (not a great experience), or through Flatpak. The Flatpak way is quite easy. I assume most other distributions have an outdated version of Anki too, because they got sick of packaging it. I think FreeBSD is the only exception (and from memory, I believe most packagers were relying on the FreeBSD packager's work).

I know the one arena Flatpaks won't replace distribution-built packages is system-level packages like Linux, bash, and glibc. Installing browsers using Flatpak is also a dumb idea.

But...if it ever does get to that point, know that Gentoo, Nix and GNU Guix will welcome you with open arms :P

Thing is, stuff like this suggests to me that what things like Flatpak are supposed to solve is quite different from what Flatpaks apparently do solve. If things that were packaged by distros end up getting packaged as Flatpaks, because packagers find they prefer packaging things as Flatpaks, because it's easier to do, that says the problem with existing package management systems is not the results but how easy they are to use from the packaging end.
The obvious solution would seem to be to make existing package management systems easier to package things with, and more automatable. Maybe there's some technical/theoretical reason why that's impossible, I dunno.

I'm just saying, if the reason users are ending up using Flatpaks isn't because they're more maintainable or because users are clamouring for sandboxing but just because there are newer packages, which in turn is because packaging debs or whatever is just harder/slower to do, then the solution isn't so much Flatpaks it's making packaging debs or whatever easier and faster.


Last edited by Purple Library Guy on 8 March 2023 at 12:32 am UTC

Quoting: Purple Library GuyThing is, stuff like this suggests to me that what things like Flatpak are supposed to solve is quite different from what Flatpaks apparently do solve. If things that were packaged by distros end up getting packaged as Flatpaks, because packagers find they prefer packaging things as Flatpaks, because it's easier to do, that says the problem with existing package management systems is not the results but how easy they are to use from the packaging end.
The obvious solution would seem to be to make existing package management systems easier to package things with, and more automatable. Maybe there's some technical/theoretical reason why that's impossible, I dunno.

In Anki's case, it was due to the developers changing the build system so many times that distribution packagers just got sick of doing it. The previous way (before they changed to the current build system, which is much simpler) was using Bazel, which few packagers were familiar with. Anki is complex software, but nothing compared to the pain that building Audacity used to be. That's why Audacity was years out of date on most distributions before Muse Group took over and started improving things.

As to why the Flatpak version exists...anyone can be a Flatpak packager; you don't have to go through the arbiters of any community. You also only need to do the work once.

Now, I'm not much of a developer, so don't take my word on any of that. This is just my even-keeled conclusion based on all I've read on both of these situations.

QuoteI'm just saying, if the reason users are ending up using Flatpaks isn't because they're more maintainable or because users are clamouring for sandboxing but just because there are newer packages, which in turn is because packaging debs or whatever is just harder/slower to do, then the solution isn't so much Flatpaks it's making packaging debs or whatever easier and faster.

Packaging takes the most time of any aspect of distribution maintainership from what I know. It doesn't move the distribution forward, but it takes so much time and effort from so many people just to keep all the software up-to-date. Hence a universal packaging format. If you want developers to be doing the packaging—and I do—you need a single format which works in as many places as possible. You also can't stand at the gates, turning away any software that isn't popular enough, or any developers that aren't worthy enough.

Some would argue that developers shouldn't be the one packaging their software; packagers should be doing that. They know the system the software is supposed to run on, so they should decide how it's packaged, which parts are compiled, and whether to apply any patches. I'm almost inclined to support this argument until I think about the absurd amount of work a group of packagers for a distribution has to do on a regular basis. I can understand that argument for critical parts of the system like Wayland, GNOME, Linux, glibc, bash, systemd, and networkmanager, but I don't think packagers should be responsible for userland software at a certain threshold.

Oh well; I'm not a packager, so I can't say one way or the other. Packaging .deb archives might be harder, but making packages for Arch is super easy. I don't think it's the difficulty in using packaging tools that's the problem; it's the build systems. And also getting people interested in keeping up with that. Arch has a community repository from which Anki was dropped last year because the Trusted User lost interest or didn't have enough time, or whatever. There were still people willing to keep up with the new build system, but they weren't Trusted Users, so the package was hosted on the AUR.

So you might say the real problem is that there is too much vetting going on to make sure the packagers are trustworthy.

This topic & comments have been a roller-coaster to read.

* People arguing for/against UNIX Philosophy and whether or not it's even relevant in modern times as user requirements have changed.

* Hatred of all things Containers

* Concern (Fear) of the destruction of something good (FlatHub) by changing it in new ways.

* Speculation on if package managers are inadequate and Flatpak is eating their lunch.

* Fear of Crapware Store Spam & a Linux Adpocolypse

* Lamentations over supporting Flatpak over AppImage in the past.

I'm surprised that I haven't seen any comments expressing fear over the GNOME origin since GNOME is infamous for having their own philosophy and yeeting user feedback.

This seems like another historical fork in the road and pivotal moment -- like when Valve created Proton, The Ubuntu Phone, Unity 8, Mir v Wayland v X. Systemd being mainlined in Debian.

--

Regarding Containerization. For most people nowadays Storage and RAM are cheap with huge excess, so that argument doesn't hold up.

Sure I understand that IDEALLY IF a program were to use System Libraries IN A PERFECT WORLD it would be great. But we live in a world where Content Creators -- people who make Apps build a thing, or for-profit companies build a thing, and then move on -- they don't baby their creation and adopt it forever updating it against GTK v57 ever 2 weeks until the end of time.

With that in mind I would argue that IF "security" or "portability" are key or if the parts are part of the OS Platform -- then using system libraries are optimal.

If however the program, app, game, etc... is CONTENT then I would argue that containerization is optimal as users really are not prioritizing Did the app get "security" patch v145 when they play CS:GO for example. Different use cases -- different goals, different targets.

Thus a web server, or email server, or bank server is going to look different from a home workstation.

I do worry that in changing FlatHub that they may fuck it up. However, acting out of fear is often not optimal -- so I'll give it my [ Fuck It ] stamp of approval and hope that they succeed and prove me wrong. We're gambling that the net effect will bring more paid products to Linux and carve out a marketplace. Hopefully such a marketplace isn't ever corrupted or used for sabotage, I just think the prospective benefits of the gamble are too big to ignore. In the same way that Proton literally increased the number of games on Linux above 10,000 or 20,000 or whatever it is in a very short time.

I will say that I do believe in a certain Survival of the Fittest and that Linux & FLOSS is so broad that there are many projects that are created and then die or fail, but out of those we have some BIG Winners that make the whole platform better than Windows & Mac and #1 for many users.

If FlatHub people are reading this -- I would hope they take a lesson from Gabe Newell when in 2013 he said their entire business model is built around "Removing Barriers" -- making it as easy as Possible for customers to be informed and get access to Content. Additionally when he talked about "Piracy is a service problem" as is seen with Netflix. People will pay for things but ONLY IF it's more convenient to exchange money to take the hassle away of getting it elsewhere or having to babysit / manage it.

And in the spirit of Open Source, if you don't like something -- fork it. Debian had Devuian -- if people want to take everything FlatHub is in 2023 and feel it's worth forking into a new website, go for it.

There's plenty of room for everyone, and we'll see how the future shapes up.

(I do hope that the the FlatHub Plus? /s business model steals a few pages from Valve's Employee Handbook figuratively and literally and distances themselves from The-GNOME-Way.)

One thing's for sure -- this is going to be very interesting.

Edit: I also wanted to add that Strict Political Agnostic Neutrality is critical to me buying on the store -- gatekeeping one dev or another because they are of the blood of a current enemy or have different ideology or beliefs contrary to popular public opinion will turn me cold so fast. Meanwhile a level of content curation is necessary -- I would hope users can tag content, and the curation process be agnostic. The only discrimination I am for is things like tags [ Has Telemetry ] and discriminating against any apps with [ Ads ] -- or scam shovelware disguised as content. If people want to declare a political or national association -- I have no problem with that but I want to be able to filter OUT content from my feed with specific declarations -- those decisions should be informed and made by ME the user and not on a per-store basis.

It's like Gabe Newell's argument for anime dating games on Steam -- 99% of customers don't want that content and so they filter it out. Then there are 1% of users who buy dozens or hundreds of that content -- and Gabe Newell and Valve don't make themselves Arbiters to promote content of one nationality and block content of another for example -- I the customer with the money get to discriminate with my money -- not the store. My money goes to the places I believe are merited or a fair exchange.

Edit 2: I write this as someone who makes decisions about thousands, tens of thousands and hundreds of thousands in business deals or purchasing equipment for clients, software and so on -- so please do understand I ALWAYS vote with my dollar -- even MORE so when it benefits FOSS and Linux connections.

(3 Steam Deck gifts later and I'm thinking of buying my 4th)

We must always vote with our dollar.


Last edited by ElectricPrism on 8 March 2023 at 3:15 am UTC

All these complicated comments meanwhile, all I think about when I saw the announcement was "More funding better flathub, better flathub more apps, more apps more good." Besides, I think @gradyvuckovic already expressed all of my worries, and I'm sure the flatpak (and related) devs are aware of those concerns.

I'll just use whatever's available, man. Testing out Vanilla made me not really fussy about what way I could get my apps, just use flatpak, if not work then either nix, container, or appimage, if not work then install natively or build it manually. It's, like, whatever man.