Ubuntu flavours to drop Flatpak by default and stick to Snaps

Quoting: whizseI can't say I have a stake in this, but it's interesting to ponder that Ubuntu seems to have a habit of betting on the wrong horse, Mir and upstart, for example.

Except that this time around they are betting on the right horse. snap is more mature than flatpak (gives the user more granular control over permissions, can be used for cli apps, can be used for non-sandboxed apps, can be used with system services, etc), snapcraft is more mature than flathub (it takes me 10 minutes to update flatpak vs the less than a minute snap takes to update), and snap has much wider adoption from 3rd party app vendors.

Quoting: Purple Library GuyBut I don't see how, technically, it would be possible for Flatpak to even be able to tell if the software being packaged was CLI software. I suppose it would feel weird and backwards to use a GUI to install CLI software, but I don't get how they could make that not work.

If Flatpak supports CLI software, that would be welcome news to me.

I don't have a technical answer why it couldn't.

Quoting: sarmad

Quoting: whizseI can't say I have a stake in this, but it's interesting to ponder that Ubuntu seems to have a habit of betting on the wrong horse, Mir and upstart, for example.

Except that this time around they are betting on the right horse. snap is more mature than flatpak (gives the user more granular control over permissions, can be used for cli apps, can be used for non-sandboxed apps, can be used with system services, etc), snapcraft is more mature than flathub (it takes me 10 minutes to update flatpak vs the less than a minute snap takes to update), and snap has much wider adoption from 3rd party app vendors.

If they are betting on a horse at all, then I think it's the wrong one, not because of anything about the technology itself, but precisely because it is theirs. Their control, as I said in another comment, is too tight for it to get more widely adopted by other distros. And it seems they're quite open and clear about the importance to them of close control over the technology and packages built by it, as noted in the long developer quote posted by dziadulewicz. The only way Snaps become dominant is if Ubuntu grows and displaces the use of most other distros. And while there was a time when that seemed like it might happen, I feel that time has passed.

But I'm not convinced Canonical are "betting on a horse" at all. Apparently, they want a technology they can tightly control so they can release tightly controlled packages that will allow them to maintain very high stability (again, as quoted in dziadulewicz's post on p 3 of this discussion). As long as they get to use it to do that, I'm not sure Canonical care if Snaps are adopted anywhere else. It's fair enough, although I don't entirely approve of the attitude, which might be OK for Ubuntu but seems like it will promote fragmentation of Linux and not strengthen the overall platform in the long term.

Quoting: Purple Library Guy

Quoting: sprocketThe one argument I have for Snap over Flatpak is that Snap works for CLI software and system software. As of now, Flatpak is only Userland and GUI-based software.

Um . . . I can kind of see how Flatpak might only work for userland software. And I can see how Flatpak itself might have only GUI-based installation software, and no CLI-based tool for installing Flatpaks. But I don't see how, technically, it would be possible for Flatpak to even be able to tell if the software being packaged was CLI software. I suppose it would feel weird and backwards to use a GUI to install CLI software, but I don't get how they could make that not work.

Well.. I know I'm the village idiot and all, but I'll try and explain it to as I know

1) You can manage and install flatpak applications via CLI without any GUI software, in fact that's how I always manage them

List of options, based on the output of: flatpak --help:

QuoteUsage:
flatpak [OPTION…] COMMAND

Builtin Commands:
Manage installed applications and runtimes
install Install an application or runtime
update Update an installed application or runtime
uninstall Uninstall an installed application or runtime
mask Mask out updates and automatic installation
pin Pin a runtime to prevent automatic removal
list List installed apps and/or runtimes
info Show info for installed app or runtime
history Show history
config Configure flatpak
repair Repair flatpak installation
create-usb Put applications or runtimes onto removable media

Find applications and runtimes
search Search for remote apps/runtimes

Manage running applications
run Run an application
override Override permissions for an application
make-current Specify default version to run
enter Enter the namespace of a running application
ps Enumerate running applications
kill Stop a running application

Manage file access
documents List exported files
document-export Grant an application access to a specific file
document-unexport Revoke access to a specific file
document-info Show information about a specific file

Manage dynamic permissions
permissions List permissions
permission-remove Remove item from permission store
permission-set Set permissions
permission-show Show app permissions
permission-reset Reset app permissions

Manage remote repositories
remotes List all configured remotes
remote-add Add a new remote repository (by URL)
remote-modify Modify properties of a configured remote
remote-delete Delete a configured remote
remote-ls List contents of a configured remote
remote-info Show information about a remote app or runtime

Build applications
build-init Initialise a directory for building
build Run a build command inside the build dir
build-finish Finish a build dir for export
build-export Export a build dir to a repository
build-bundle Create a bundle file from a ref in a local repository
build-import-bundle Import a bundle file
build-sign Sign an application or runtime
build-update-repo Update the summary file in a repository
build-commit-from Create new commit based on existing ref
repo Show information about a repo

Help Options:
-h, --help Show help options

Application Options:
--version Print version information and exit
--default-arch Print default arch and exit
--supported-arches Print supported arches and exit
--gl-drivers Print active gl drivers and exit
--installations Print paths for system installations and exit
--print-updated-env Print the updated environment needed to run flatpaks
--print-system-only Only include the system installation with --print-updated-env
-v, --verbose Show debug information, -vv for more detail
--ostree-verbose Show OSTree debug information

2) Technically you can access a flatpak applications CLI. It's a little complex. But it can be done.

For a CLI only application, you could in theory just do "flatpak run org.app.Command -o options" or stick an alias for this in your local rc file to just have "command -o options".

You can also access a shell within a flatpak applications sandbox by doing: "flatpak run --command=sh --devel org.app.Command" and so on.

Typically you'd only do this for debugging.

More on that here:
https://docs.flatpak.org/en/latest/debugging.html

3) Often the complaint is not that flatpak cannot do CLI-only applications but rather, flatpak can't be used to install some more deeper system applications, for example a system wide daemon.

And lastly, there's lots of FUD being spread about flatpak out there by people who don't know it, use it, or understand it.

Quoting: CatKiller

Quoting: F.Ultra

Quoting: whizseI can't say I have a stake in this, but it's interesting to ponder that Ubuntu seems to have a habit of betting on the wrong horse, Mir and upstart, for example.

I wish that people would stop bringing up Upstart in discussions like these. Upstart predates systemd by 4 years and was at the time the best candidate to replace the ancient SysVinit which is why many, including Red Hat and Chromebooks, move over to Upstart.

The same is also true of snaps, Mir, and Unity. Snaps predate flatpaks and have features that flatpaks still lack. Wayland wasn't (and still isn't) a good choice for phones since it's for the desktop. There (still) isn't a convergent desktop environment that will work across phones, netbooks, tablets and the desktop, which was the aim of Unity.

Canonical's problem is that they want to push things forward but don't have Red Hat (IBM now) money.

And they did plan to use Wayland, and if I don't remember wrong they where about to be the first distro to use it (just like they where the first to use Pulse) but then they discovered that it wasn't fully functional yet so they moved that back and started to work on bringing Mir to the desktop instead.

People also tend to forget the sorry state of Gnome 3.0 when it was released that made every distro out there either keep using the old Gnome 2.0, switch to something else or create something new like MATE or Unity.

And now again people are up in arms because some variant of Ubuntu will not default install flatpack, while it will remain in repos so any one that wants it can install it. Sometimes our community is worse than The People's Front of Judea.

QuoteSo while it's going to be controversial, it's not exactly a big deal is it?

For the intended audience of desktop Ubuntu editions, that actually will be. Most of those users won't think to install Flatpak, which means they'll get less apps and ones that open slower than Flatpaks.

That pretty much leaves me on KDE Arch-based distros for the foreseeable future. Kubuntu & Ubuntu Studio are now officially out of consideration.

Quoting: Purple Library GuyIs it really a "competitor option"? I don't think Flathub is maintained by some specific other distro company. My understanding of Flatpaks is that they are just an independent piece of software, like LibreOffice or something. If Canonical were to start considering the whole open source ecosystem to be "competition" they would have problems.

On the other hand, for every other distro, Snaps really are a "competitor option" since they're created and maintained by not just a particular distro, but by a for-profit corporation, and Snap as currently written works with just one repository, Canonical's.

I think there is a disconnect between your two arguments here. Libreoffice is shepherded by Collabora; they sell support/development services for it, so I don't think that's a great example. But also, businesses can sell services for free software (and sell free software on its own as Ardour does, though this is rarer), so doesn't it make sense that anybody who offers a service which competes for their market is a competitor, regardless of whether they're earning money from it? I mean, Amazon lost money for years so they could service more of the market than competing companies.

And businesses can also sell competing services for the same software. Mumble is a great example of this. You'll see a lot of businesses offering Mumble servers.

I know there's a sense that free software organizations aren't competing with each other, and the fediverse is a good example of the collaboration that's possible between developers, but even if you aren't competing for profit, you can be competing for something else. Namely, funding. I seriously doubt anyone is going to consider funding Cinelerra-GG, because it has such a small slice of the market. Cinelerra got funding ~20 years ago when it was the only kid on the block, but Kdenlive, Olive, and Blender VSE are much more likely to get funding in these times because of their market share.

Even outside of free software, businesses will gleefully partner with companies in different industries for joint ventures, so cooperation and 'standing on the shoulders of giants' is not something unique to the free software community.

Quoting: Purple Library GuyThe only way Snaps become dominant is if Ubuntu grows and displaces the use of most other distros.

This is not necessarily true. Snaps are independent from Ubuntu. If you go to the snap store you'll see no Ubuntu branding there. Canonical is marketing snap as a Linux store, not as an Ubuntu store, much like Steam is a Linux gaming store regardless of which distro you're using. So, if people have no problem installing Steam, which is proprietary and tightly controlled by Valve, why would they have problem installing snap, which at least has an open source client?

stupid canonical being stupid.

who use package managers in 2023 anyway? we have steam!
seriously, shit like this will only harm canonical and linux in general, the only consistent way to install things on linux is using proprietary softwares like steam.

i think its time to find another distro, im tired of distro hopping, so i sticked with ubuntu for a while, but my patience have limits.

Free Vendor Lock? Pass.

Glad I dumped Ubuntu on my servers.


Last edited by ElectricPrism on 24 February 2023 at 2:23 am UTC