Canonical has announced a change in the packaging defaults for the various "flavours" like Kubuntu, Ubuntu MATE, Ubuntu Budgie and so on to exclude Flatpak and stick with Snap. Yes that's flavours, not flavors but also flavors in the announcement.
This is no doubt going to be a hot topic, because name me a more intense argument in the Linux world than packaging. While Flatpak has been gaining many fans lately, partly because it's included as the official way to install extra packages in Desktop Mode on the Steam Deck, Canonical are sticking to their own Snap.
So what's going on? In short: Ubuntu flavours will no longer have Flatpak enabled or setup by default. However, users can still do it themselves as they're not being removed from any repositories. It's all about the out of the box experience, with Canonical and the flavours now sticking to deb and snap to maintain their focus on what is actually properly supported by them and gets the most attention.
Users who have Flatpak installed won't see any changes, it's just the out of the box new-install experience as of April 2023, with the release of Ubuntu Lunar Lobster.
This is, after all, why we have different distributions isn't it? They're free to make whatever decisions they wish, and people who don't like it can go elsewhere, or just change the defaults to their liking — Linux is open and configurable unlike certain other systems. Do what you want.
So while it's going to be controversial, it's not exactly a big deal is it? Sort of. It's still making the desktop Linux experience quite messy, especially for newer users since there's no single way of installing things across different Linux distributions. You can't usually just point people to this thing and say get that, unless you first know the exact distribution they're on.
If you have thoughts you can comment on the announcement and let them know.
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: sarmadIf 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.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.
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 GuyWell.. I know I'm the village idiot and all, but I'll try and explain it to as I knowQuoting: 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.
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: CatKillerQuoting: F.UltraQuoting: 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.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.
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.
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?
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.
Glad I dumped Ubuntu on my servers.
Last edited by ElectricPrism on 24 February 2023 at 2:23 am UTC
See more from me