By order of Canonical: Official Ubuntu flavors must stop including Flatpak by default Canonical has issued an official edict: the approved Ubuntu remixes must remove Flatpak support as of the next release. The various Ubuntu flavors are not Canonical products. Only the original Ubuntu, with the GNOME desktop, is the "real thing." Even so, the company does have some control as it's Canonical that officially …
The thing is, if you install everything from Source Code, it really does actually Just Work™.
What actually gets in the way of this, ironically, is package management systems; and this is because of a decision, made a long time ago in a very different landscape, to conserve resources that were precious them but are abundant nowadays, by splitting out files that were not necessary just to run a program -- but would become essential if you ever wanted to build another program from source to work with it -- into separate "development" packages.
The process goes something like this. You see something on GitHub that you want to get working. The author just says it depends on the "wibble" and "blah" libraries. And if you had installed those libraries from Source Code, it would just work. But if you are using a Fedora (.rpm)-based distro, you almost certainly will actually also need to install wibble-devel and blah-devel; and if you are using an Ubuntu (.deb)-based distribution, you almost certainly will need libwibble-dev and libfoo-dev. And if you don't know this, almost nobody seems to be explaining it. So you dutifully install wibble and blah via your distribution's package management system; you `git clone` the project repository; and it fails to build, complaining about missing dependencies wibble and blah -- which you thought you had just installed.
The message that sends is that building software from Source Code is some sort of black art.
And yet, it doesn't have to be this way. Ubiquitous broadband and multi-terabyte HDDs mean the original reasons for wanting to keep package sizes small no longer apply. Let's just retire development packages and merge the contents into the main packages. If somebody never compiles a program from Source Code, they are not going to notice the extra disk space taken up by the files that make it possible. But if even one person tries to build their first program from Source Code and it Just Works™, it will have been worth it.
...I am glad that this not a Systemd inspired power grab that I saw coming a few years ago. Man, it would really suck if a billion or more users had no choice but to upgrade while they learn how use another distro. I think this is totally innocent and will not at all fragment the FLOSS ecosystem into a civil war that might destroy it.
I mean...
"Man, it would really suck if a billion or more users had no choice but to upgrade while they learn how use another distro."
or, you know, they could just install Flatpak.
Look, man, I work *on Fedora* and I think that was an overreaction. All the pearl clutching about this has been great fun to read, honestly (makes a change from the daily Two Minutes Hate of systemd and GNOME around here), but good lord, it's not like they kicked it out of the repos. It is arguably a *bit* harsh to say that no "official Ubuntu" can include it, but I mean, that is the kind of decision distros make all the time. And to be fair, I don't think any Fedora spin includes snap OOTB either.
It’s a sop for lazy and / or fascist programmers.
The one time I encountered it was for an editor, which was pretty much useless sitting in its flatpack jail with no access to most of the network file system where the documents were. And don’t bother telling me the dance moves to make it work, the whole model is just broken.
Snap/flatpack needs to go away
Hallelujah!
It's drifting towards MS .Net (which release?) and Metro (ditto) and containers. Let's add another layer of abstraction - what's the downside? Everything becomes an entire environment to support what it needs with all the storage, memory & CPU overheads that implies. Never mind that they're all using the same libraries - they have to have to work to that specific version so have to have their own copy. How many loop mounts do you want?
Microsoft had 'DLL hell' and bodged around it. Linux doesn't have that problem - if a library has a breaking change it is bumped and both can co-exist.
Stick with apt or yum or ./configure && make && sudo make install. Otherwise I don't want your product.
I'm an arch- erm, Arch user but having been given a god-awful Dell xps13+ by my employer I was forced to install Ubuntu as it seemed to be the only distro with support for the new hardware.
It seemed to be OK on 22.04 although I was growing to hate the snaps. Then I submitted to the nagging and "upgraded". I was then subjected to regular crashes (after I managed to patch networkmanager to get it to work again); so regular that I eventually had to give up. I decided on Mint cinnamon and so far I've been pretty happy. Most things can be installed properly.
I'll probably still go back to Manjaro when I can though.
Is it overly paranoid to wonder about the future of apt / apt-get / dpkg and so on for .deb packages on Ubuntu? Or rpm on Fedora (et al), for that matter?
My home laptop is Debian so I'm not much affected personally by this Canonical move; but I expect to run into Ubuntu again at $job at some point, so I do try to keep an eye on their doings.
I've managed well enough to keep up with rpm / yum (er, dnf) on the Red Hat-flavored things, SUSE too, and apt for the Debian family. So I haven't had much call for snap nor flatpak to date.
But I wonder how long that will last. And as others (including TFA) point out, the various package management schemes don't inter-operate nor cope with each others' dependencies well (at all?). So it seems like a long-term boondoggle trying to maintain the "native" deb or rpm installation alongside snap or/and flatpak.
Aside from Firefox, Snap seems to mainly have replaced PPAs. It used to be that if you wanted the newer version of some obscure package you needed to find some potentially dodgy PPA and install that.
Now that's done through Snap, there's an official Snap store, and Snap packages are confined so they have limited access to resources.
It's useful for certain things, such as allowing one Firefox package to run on all Ubuntu versions instead of rebuilding it for each version. It's also good for obscure packages that that need to be kept up to date.
On the other hand, it's probably not going to replace the bulk of Deb packages, as there's no reason to do so. I have a handful of Snap packages installed (e.g. the Raspberry Pi imager), and I normally look for a Deb first before falling back to a Snap. In some cases without the Snap I would probably have to build from source.
The main targets for Snaps are actually applications from propriety vendors who traditionally had horrifically bad packages, and games, as game studios don't want to update their packages for each new release. You could also think of Snap as being an alternative to something like Docker when it comes to server applications.
Flatpack on the other hand seems to be pretty badly thought out. It only does GUI apps, doesn't handle server cases, and package management is pretty poor (as described on the article). Snap is what Flatpack should have been, and the only real reason why Red Hat and friends persist with Flatpack seems to be NIH. There's nothing to stop each distro from setting up their own Snap store the same way they do their Deb/RPM repos.
> It's useful for certain things, such as allowing one Firefox package to run on all Ubuntu versions instead of rebuilding it for each version.
What's wrong with a tarball that includes all the dependencies? Unless, of course, some distributions have started to remove 'tar' ?
Or how about a package that includes the software and a list of packages that may need installing and calls apt to do that. I reckon I've got about 30Gbytes of duplicate packages in various Snap crap and another 50Gbytes or so for various Python VMs. Its getting back to the good old days like brexit does.
[Author here]
> What's wrong with a tarball that includes all the dependencies?
Lots. How long have you got?
* What keeps track of what it puts where?
* How do you keep track of what depends on it?
* How do you know what it depends upon?
* How do you upgrade it if you don't know what it put, where?
* How do you uninstall it?
* How do you keep it online and know where to find it, so a million client machines or instances can fetch it when they need it?
There are good solid reasons why package management systems were invented. They fulfil a need.
https://www.theregister.com/2021/11/26/linux_software_installation/
The real question is not "why do we have them?" (which is easy) or "can we do better?" (which is contentious but manifestly defensible).
The real question that's *not* being asked is: was the original way of doing this on xNix the right way to do it? What alternatives are there, and what are their pros and cons? And if we decide that we didn't do it the right way in the 1970s -- and I personally feel we did not -- then what is the better way of doing it and how do we get there from here?
The Nix and Guix way of doing things has some strong advantages but it also has major drawbacks.
Me, personally, I like the GoboLinux way of doing things. I reckon that could be amenable to being enhanced a bit so that it could be automated, and we could have the best of both worlds: an automatic declarative way of managing software (like Nix) but also a human-readable, navigable filesystem.
> * What keeps track of what it puts where?
It's a tarball extracted into it's own tree, you don't need to keep track of what it puts where, as everything supplied in the tarball is under (for example) /opt/firefox, and if for some reason you need to keep track of it, thats what environment variables are for (FIREFOX_HOME=/opt/firefox).
> * How do you keep track of what depends on it?
It's an end-user application, a browser, nothing should depend on it, and it if does, that's what environment variables are for (put /opt/firefox/bin in your PATH).
> * How do you know what it depends upon?
Mozilla wrote and compiled Firefox, if they don't know what it depends on how did they compile it? Everything it depends on (libraries etc.) should be in the tarball, with all dependencies relative to the executable ( ../lib for example),
> * How do you upgrade it if you don't know what it put, where?
It's a tarball, you untar it over the top of the previous tree, "cd /opt; tar -xvaf ~/firefox.tgz ", done.
> * How do you uninstall it?
rm -rf /opt/firefox
rm -rf ~/.firefox (if you want to delete userdata as well)
> * How do you keep it online and know where to find it, so a million client machines or instances can fetch it when they need it?
Not sure what you mean by this, as 'keeping it online' is having a place to download it from, wget https://mozilla.org/releases/firefox/latest/firefox.tgz ? (made up URL, but you get the idea)
Being a tarball doesn't disable autoupdate (if that's your thing), as the autoupdate can download the latest version tarball and extract it.
We are talking about Snap and Flatpak specifically here, which (as I understand it) are basically used for application-type distribution/packaging, which basically include all the dependencies inside the bundle anyway. If you're going to do that, why re-invent the wheel? Just use a tarball.
I'm not saying there is no use for package maangers. I'm responding to the OP who said that using Snap means Mozilla doesn't have to have a different package build process for each flavour of Ubuntu, I'm pointing out that that advantage isn't limited to Snap. Can use a completely inclusive tarball, or do what IBM does and write their own cross-platform package manager (IBM Installation Manager) that they then support one package system (IBM Installation Manager) across Linux, Windows, AIX, irrespective of distribution.
I know, replying to own post, but hit post too quickly (even accounting for the fact I did edit the above post to add the last paragraph).
I was also being facetious in saying "Unless, of course, some distributions have started to remove 'tar' ?", pointing out that if they only want Snap to be used - hence banning Flatpack from out of the box installations - then they could take it further and ban 'tar' as well, as some people still do distribute tarballs, therefore tar shouldn't be available out of the box either.
The point of distributions like Ubuntu is to make average-user desktop Linux easier to use as a windows replacement for the masses than more hardcore distributions like Arch, Gentoo, LFS, etc. If that is the point, banning OOTB other package managers is going against that purpose. One would thing that to make a user-friendly Linux, that they'd want to include all the major package management options as part of the OOTB experience.
> * How do you know what it depends upon?Mozilla wrote and compiled Firefox, if they don't know what it depends on how did they compile it? Everything it depends on (libraries etc.) should be in the tarball, with all dependencies relative to the executable ( ../lib for example),
...and then, when a security vulnerability is discovered in a library that a dozen apps installed by tarball use, I get to update them all?
Seriously?
You've just re-invented downloading Windows apps off the Intarwebs.
Package managers are one of the things I love about Linux - I don't have to faff about with ensuring everything's up to date.
You are basically describing Oracle. You have $ORACLE_BASE, $ORACLE_HOME and so on. But Oracle manages to combine all of the worst of a tarball type install with all of the jankyness of a Java GUI installer. Plus different patch sets, one off patches and a separate patch installer tarball, which must be patched itself in order to install the other patches.
I read somewhere that to patch one $ORACLE_HOME takes an average of 4 hours. And based on many years of experience, that sounds about right.
> What's wrong with a tarball that includes all the dependencies?
Isn't that basically what macOS does? An application is just a directory (with a .app extension) that contains all the files needed to run the application. You just copy it into /Applications and run.
Unless, that is, you need to install system services, or drivers, or libraries, or settings, or.. er.. anything other than a basic GUI app - in which case you need a .pkg with an installer, which will copy things all over the blooming' place. Give me something walled-off in its own environment, like a Snap, any time over that.
Snap currently has a couple non-starters for me. Most notably the part about snapd requiring a local (not NFS et al) $HOME under /home/ .
I don't love the bind mounts per-package either.
Silently(?) using Snap for some packages (or dependencies?) when running 'apt install' seems like pulling the rug out. I haven't run into that myself but I've read other reports, so I'm wary.
I think my biggest issue is the sort of "walled garden" approach Canonical is apparently taking with Snapstore. I can't help feeling like there will be a bill attached or some other proprietary shenanigans at some point. This is less a technical issue than it is some distrust of Canonical.
To be fair, I don't trust Red Hat either.
Deb and rpm are just install files, run script, they will always be easy.
Snap restricts what you can do, so it will always be a ballache to package them because you have to rewrite the app with snap in mind.
And Ubuntu change the rules. Something possible with Snap one day becomes impossible the next, ruled by Canonical in the same way Apple decide what is possible in an app.
I tried an early snap and the next version made what I was doing impossible so I learned by getting burned early.
There is no benefit to users or devs of Snap. It's just pain. The benefit is to Ubuntu. You don't need root for some things with Snap, which is Ubuntu's wet dream because then they can own root like Apple do. But no Linux Desktop user will ever want that. And no dev either.
Why voluntarily put yourself in an Ubuntu jail? when packaging with debs is so easy.
[Author here]
> Can they remove Snap too?
If you want Ubuntu without Snap, then try Zinc. I thought it was pretty good.
Or there's Linux Lite, but I reckon they should lean in to the being-for-Windows-migrants thing (and the embrace of proprietary freeware) and install MS Edge as the default browser and WPS Office as the default office suite.
Eh? What machine have you managed to find that Debian outright didn't run on? Debian is probably the one single distro that has never failed to boot on anything for me, I've even managed to boot it on some weird exotic Android tablets. Takes some effort, in that case, but usually more time consuming than difficult.
Sure, you get the odd device that won't work occasionally...but that's usually a kernel thing not a distro thing and Debian is usually quite quick when it comes to backporting drivers for mission critical hardware...and since they are upstream from Ubuntu, that goes for Ubuntu as well. Stable branch is a bit slower, but for obvious reasons.
The last 2 machines I've tried to install Debian on didn't work (both Dell laptops). On one the WiFi adapter wouldn't work (and it didn't have ethernet and my USB-C ethernet adapter didn't work either). On the other, none of the USB ports worked at all. Ubuntu worked without fault and even offered me a BIOS update for one of them, which also worked. I don't want installing the OS to "take effort" - I want it to be done in 10 minutes so I can do something useful.
I hate snap too, but it has come to the rescue on a couple of projects for me in the past...specifically, I worked on a project recently and I needed to compile a BladeRF tool...the only working version of cmake that would actually build the code was only available via snap...because the version on the repos was "too new".
This probably says more about BladeRF and their tool chain etc than anything else.
I doubt we are ever going to see a situation where one packaging format wins out over the others, other than on Ubuntu snap is not widely supported, and as the article mentions even some distros which are based on Ubuntu such as Mint actively rip out snap support and replace it with Flatpak.
Maybe the solution would be some 3rd packaging tools that supports Snap, Flatpak as well as Appimage and can handle the multiple file dependencies across the different formats?
I mean, for systems like flatpak / snap the idea of "handling file dependencies" is a bit...wrong. On those systems, flatpaks/snaps depend on base images, which are never going to conflict with each other. You can install as many flatpaks and snaps as you like and they will never conflict with each other and will all work fine. The only thing is, you'll get a lot of disk space eaten up by different base images, and maybe a lot of RAM consumed by slightly different versions of the same libraries being loaded by different base images if you run a lot of apps based on different base images concurrently.
There's nothing a third-party tool could really do to "handle" this, because the base image requirement is inherent to the thing being deployed, there's nothing you can do to finesse it, you *need* it.
This post has been deleted by its author
Derivatives are free to do what they want with the software. If they want to use the "Ubuntu" trademark or get free infrastructure and other benefits though, then they have to stick to Ubuntu policies with regards to official "flavours".
Other distros do take the Ubuntu software and don't follow Ubuntu guidelines, but they don't get to call themselves "Ubuntu".
Try starting your own distro and calling it "Debian" without Debian's permission and you may find that Debian the organization may have a sense of humour failure. The same goes for Red Hat or Suse.
Ubuntu are probably the least restrictive of the major distros when it comes to derivatives.
How are people releasing derivatives leeching off Ubuntu? What they release is still basically Ubuntu, it's just tweaked and patched out of the box. You could take a vanilla Ubuntu install apply all the same tweaks and patches as Mint, install Cinnamon and it would be essentially the same. If anything they are eventually ensuring that at some point, people just install Ubuntu to save on faff.
I don't like Ubuntu, its bastard step children ("remixes"), or containerized packaging systems. It's the dictatorial attitude that irks me here, though.
These "official Ubuntu remixes" should just tell Ubuntu to get stuffed, send a message. Why do they even need any kind of endorsement from Ubuntu? Anybody could shit out a Ubuntu based distro if they wanted to and wouldn't have to ask anyone's permission and it could be better than anything official.
Use whatever you want. Get proficient so you can. With knowledge comes the power to tell people like Canonical to get stuffed, in the world of free software.
If this comes as a surprise to anyone at all, then you haven't been paying attention.
Canonical is desperate to increase 'profits' and has decided to travel down the well worn path of Oracle and Microsoft (Canonical's new bff). The author's cheerleading aside, there's no legitimate reason for them to go down this path excepting that they want to exert more control, to raise the wall of their walled garden even higher. It's one thing for Canonical to make this change in their distro Ubuntu, maybe it will end up working for them, maybe not. Wielding what control they have over remixes to force them to comply, that move just reeks of desperation. It shows the world that they don't believe Snap can stand on its own. That the only hope it has of 'winning' is to kneecap the competition. If downstream distributions enable Flatpak, or any other alternative package manager, by default then users will have the ability to judge for themselves. Canonical is banking on the 'power of the default', it knows that most people that use Ubuntu or one of the various remixes either; won't know how to add support, won't bother to stray from the default Snap, or won't even know that there's an alternative to Snap.
Personally, I believe that all we really need are .deb, .rpm, and the ubiquitous .tar.gz. If people believe that there are problems with one of these, then they should strive to improve the existing formats. But of course, Canonical wouldn't have a built in leg up if they did that. They wouldn't have the control, and from that control the ability to excessively monetize.
I'm just glad that the folks behind Debian finally voted to include non-free firmware in their official images. Debian bookworm should 'just work' on many more systems as a result. I'll probably be switching my systems back to Debian when it's officially released.
With any luck, current Ubuntu remixes will have the strength to either forego 'official' status and buck Canonical in this and the other user adverse decisions inevitably coming down the pike. Perhaps they'll even make the jump from being dependent on the whims of a commercial entity and instead opt to base their futures on the much more ethical Debian proper.
Most users won't encounter SystemD on a daily basis.
SNAP OTOH, is like that ex who won't take no for an answer. i.e. won't go away. Once your system has been infected there is no way to remove all of it.
I installed SNAP on my server because the ************* as Certbot decided to only produce a SNAP install package.
At the time, I needed to get the system running ASAP so... SNAP it was.
Later, I had the chance to remove it and replace certbot with a shell script that did all the work for me.
even now, bits of SNAP lurk on my system.
The next step is to get my backup server operational and then nuke the original box.
Canonical is IMHO acting more and more like big brother every day. Even members of my LUG are giving them the finger. Two of them run Linux based consultancies and have stopped recommending Ubuntu or any of the derivatives to their customers. Instead, they recommend, Debian or Rocky Linux.
I can't wait for MS to swoop in and put us all out of our misery and buy Canonical.
Fire at the...Canonical!
Danger, Danger...noob outrage!
Come on, who gives a shit if they remove Flatpak by default? People only use Flatpak and Snap when it is foisted on them or they use it by mistake. Now there is a 25% lower chance of ending up with a package you didn't want.
Snap was supposed to make for cleaner installs, but doesn't. The file management is chaos. Important app data, settings, binaries, temp files can caches are all over the place. Every time I use a Snap app, I have to pick through dozens of directories to include or exclude them from backups. A few weeks of real-time backups of cache directories is a great way to bloat your backup storage by a few TB.
My experience of all of these 'all-dependencies' installation systems (appimage/flatpak/snap) is that they don't work. Examples:-
Most can't see /tmp so you end up putting temporary files all over the place, making your machine look like a Windows one.
Some can't see the network. Just where do you put your files?
Some can't see printers. Like Inkscape (which I kinda understand as it's an icon generator, but).
Appimaged Audacity can't even produce sound! I wonder how that was tested?
Only apt seems to work properly with full access to resources. Unfortunately politics means that many applications are no longer available in that form. Why does Linux desktop have to be so difficult? Because it's free.
Changes by Canonical, like this, is why I stopped using Ubuntu 10 years ago. Even local Ubuntu groups, I have participated in, have a similar attitude of... "We know best".
I think canonical needs to re-read or change their sections labeled.... Freedom and Collaborative... In the URL link below.
https://design.ubuntu.com/brand/ubuntu-logo#:~:text=Ubuntu%20celebrates%20freedom.%20Freedom%20to%20choose%2C%20to%20change%2C,it%2C%20it%20is%20trustworthy%20and%20keeps%20its%20promises.
Snaps in Ubuntu were annoying (as in totally useless) and quickly created a huge mess of loop mounts. I had a total of 31 loop mounts on a system that I don't use any Snaps, but let them continue to invade because I didn't want to risk breaking the Ubuntu 20.04 installation by removing the Snap crap. I did a test install of Ubuntu 22.04 some time back and found that more and more Snap crap apps were being installed. I switched to Debian for most of my Linux needs and also use MX Linux. I realize Canonical wants to monetize their product, but they really need to concentrate on something that is productive. I have found nothing beneficial to the end user by using Snap apps, but unrealistically restrictive, making management of the system more challenging and trying to Snap schite to work like the original releases. I just don't have the time or desire to try to find solutions make their Snaps work. Canonical, you have successfully made it to the same la-la land as Microsoft software engineers and programmers to make you OS slow, inconvenient, buggy and call them features.
The best thing Canonical could do with Ubuntu is get rid of separate -dev packages, and leave all "development" files in the "main" packages.
Back in the days when HDDs were measured in megabytes and Internet access for mortals was by dial-up modem, it made some sense to omit from binary packages any files that were not necessary for day-to-day running of the software but would be needed by developers compiling other applications to work with them, and move them into separate "development" packages instead.
Today, there is no good reason to do this. HDDs are now into the tens of terabytes and broadband is everywhere. But everybody still has to install a package from the Source Code sooner or later; probably sooner, given the popularity of GitHub and the like. And the counter-intuitive step of having to install extra development packages on top of what the author's web site says is making this harder than it needs to be.
Acquiring a reputation for being the easiest distribution on which to install a package from Source Code surely could not hurt?
I have a 11.6 inch 2in1 laptop that use when I sit outside and sip my morning coffee. I like it allot. So far the only OS I can put on it , besides Windows 10/11, is Ubuntu 23.04 Desktop. It's a little weird in places, but it works pretty well. For now, I must use it... for the sake of my coffee. However, If I knew how to install Manjaro and make all the stuff that needs to work for Tablet Mode, I would FLUSH THIS $#!T SO FAST, that my poor little SSD would think..."Whoa Whoa Whoa! What just happened! I feel so different!... Wow!... Awesome!" There's just one person with the authority to say Thou shalt NOT" and it ain't Canonical Ltd. Few things set, what little hair I have, on fire!
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
