Many people don’t want to use it (me included):
https://forums.theregister.com/forum/all/2023/06/09/will_flatpak_and_snap_replace/
@Teuniz that will all be dependent on the end user case…
On one side of the fence there are those that complain because apps are too old in Leap, so either look at running flatpaks (and flatseal to control), podman or distrobox to fulfill your use case. Folks complain about btrfs, so don’t use it, look at Tumbleweed?
So many different ways you can do things, I’m running MicroOS and use rpms, containers, flatpaks, podman, distrobox and kubernetes for my end use… I also use Leap (will switch to MicroOS) and Tumbleweed (Primary system) as well, all fulfill my needs…
Perhaps a user only has one system, so all they can do is read about this and that and no ability to test what works for them…
Considering Leap does not even have graphical Flatpak management on XFCE, I highly doubt they will.
The KDE Web Review posted this an hour or so ago – <https://blog.brixit.nl/developers-are-lazy-thus-flatpak/>.
Yes, MicroOS currently uses Flatpak – <https://news.opensuse.org/2023/05/31/microos-desktop-has-new-name/> …
- But the ALP sessions at this year’s openSUSE Conference were all talking about “Containers” – which excited the mangers of large Server systems – Flatpak seems to be not such a good solution for them – on the other hand “Containers” versus Virtual Machines is being viewed as being a method to reduce system resources – each Virtual Machine runs it’s own Kernel – each Container uses the machine’s Kernel directly – albeit with a couple of security issues …
Flatpak isn’t currently aimed at the server market. Canonical is doing some of it with snap on their end of things.
I don’t know if the folks behind flatpak have any server uses in mind, but as of right now, it’s primarily for Desktop Applications.
I don’t have any particular insight into the future, but I suspect you’ll see a fair number of upstream desktop application developers releasing through flatpak, and you will see the distribution packagers dropping those, so they can concentrate on the stuff that makes sense for a distribution to do. As a long time packager/maintainer on a number of distributions, there is a lot of overhead, chasing down bugs for weird edge cases, because one user has an ideosyncratic setup, or piece of hardware that isn’t fully supported.
I personally think this is a good step forward.
3 Likes
It’s not Leap, it’s XFCE thing. Some people advise to add GNOME software to XFCE for Flatpak/Flathub software management
1 Like
It’s purely speculation but I think it will and openSUSE will be one of the progressive distros to adopt it as the mainstream package solution.
Richard Brown the former chairman of openSUSE still does a lot of work for openSUSE and being the chaiman before, I’m sure he still has a lot of power in the the direction of the distribution. He is a big proponent of Aeon, having said before that “MicroOS is my baby”.
He was also the instigator of ALP’s concepts being introduced to the public, explaining how LEAP will not get the support it once did unless the community steps up.
I believe that the openSUSE devs are trying to replace LEAP with Aeon which will in turn focus package management into container platforms like flatpak.
Do I like it? Not really, but LEAP still exists and 15.5 is running great for me. 15.6 is supposed to be supported too. I will worry about these issues in the future when they are forced upon me. I test other distros from time to time on a different partition so I have an idea of what else is around and if I’m not happy up the road then I’ll just switch to a distro with a different vision.
1 Like
Thanks for the link, it confirms my worries and convinces me even more to stay away from
flatpak/snap/containers and similar solutions.
1 Like
Those are my thoughts as well. And Tumbleweed is not an option for me because I use
Leap also at work where things just need to work.
This is a really cool article! Especially the part that clarifies that you don’t have to package your application for every distribution, as it tends to get pulled in one way or another. And once in the repos, the dependencies patched regularly by distribution maintainers, as opposed to dependencies in Flatpak.
Yes, that article certainly makes one pause for thought; the potential security risks described are concerning. It seems to be following the path of convenience with significant cons.
More reading:
May be that’s why Fedora has it own flatpak repository alongside the Flathub?
And I still don’t understand the target auditory for the Aeon project. SUSE ALP conception implies “a whole virtual machine (VM) to run encrypted: encrypted memory (data in use), encrypted I/O (data at rest), encrypted networking (data in transit)” as Vojtěch Pavlík, SUSE’s newly appointed general manager of Business-Critical Linux, said. At the same time Aeon gives us a central flathub repository as package source, disabled firewall and remote authorization via SSH enabled by default. So we have a boarded-up front doors and wide open back door and a mixture of conception with tool for package developers (distrobox) and corporate workstation (FDE, lack of manually partitioning and SELinux)… Am I right?
@deano_ferrari and that differs from users adding random home repositories from the openSUSE Build Service via the likes of opi, one-click? 
That is why I always post links to my testing repos, users can review the code, what I have done etc before installing…
1 Like
Nobody, including Richard, is trying to replace Leap with Aeon, or anything else. This is pure speculation, and bad speculation at that. Nor does Richard have anything to do with “Being the Instigator of ALP’s concepts”. How exactly do you think Leap was built/is currently built? Leap is based on the SLE Commercial Product. A Product which either no longer exists, or is purely in maintenance mode.
The only reason that the openSUSE community has been “Introduced to ALP” is because that is what the SUSE Commercial Product is based on. Leap is based on that commercial product. So it’s not a hard line to draw, that in the future, Leap will be drawing from the ALP sources.
Apples and oranges - knowledgeable users generally stick to the official/trusted repos. With flatpak, what precautions will ensure safety? What kind of auditing will be done?
Everything on flathub is done in the open, anybody that cares to is more than welcome to go to their github repo, and audit the .json build files, or anything else.
I don’t see how this is any different than the current situation with OBS hosted RPM’s. It isn’t as if openSUSE packagers (myself included) are any sort of geniuses, experts, or even particular specialists in the packages we work on, in many cases.
Do the packages that get into Factory get more attention and testing (even if only OpenQA), than the random stuff sitting around in devel: or home: repositories? Sure. But it’s no guarantee of anything.
2 Likes
And there is flatseal for further tweaking.
1 Like
I look for Flatpak and Snap versions on rare occasions. I made the switch to Tumbleweed in 2016 and never looked back to Leap.
The author of »Linux« says in openSUSE 15.5:
“If you want to use openSUSE in combination with current software, you should take a look at the rolling release variant Tumbleweed. Personally, I think Tumbleweed is the “better” openSUSE.”
Blockquote Everything on flathub is done in the open, anybody that cares to is more than welcome to go to their github repo, and audit the .json build files, or anything else.
I’ve been using Linux since SuSE 7, almost a quarter of a century ago, and I still don’t know how to read a .json build file, whatever that is. People like me don’t trust scripts, we trust other people. I trust packman because I know it works since forever, I trust one particular “home” repository because I know it’s maintained by one of the developers of the only package on that repo. If you tailor “the Linux experience” to the people who are able to read .json build files, your users will be just the people that are able to read .json build files. That’s a quite limited target, I think.
And for moving to Tumbleweed, well, there is a huge difference between doing zypper dup once a year in that small window when no important work needs to be done and doing it once a week when you need to end that urgent task before Monday.
Different users, different needs, I suppose.
1 Like
@RGBsuse there were three updates the other day…
There is no requirement to update, review the changes and you can decide…