Ubuntu is a Debian-based Linux distribution but it’s increasingly positioning snaps as the preferred way to ‘get’ software. The aim is, eventually, to default to a full-snap experience on the desktop.
With that plan in mind you won’t be mighty surprised (and if you are, welcome back to planet earth) to hear that showcasing DEB software will not be the primary aim of this new Ubuntu Software replacement.
Ubuntu’s Director of Engineering says the new hub will be a “snap-first app store” designed around snap metadata. If the same piece of software exists in the Ubuntu repository and the snap store the new store will only make it possible to install the snap version.
This is not a surprising move, but one that is sure to alienate at least some – including me. Not that I’d use Ubuntu any time soon anyway, but forcing Snaps down my throat certainly isn’t going to draw me back in.
My main problem with snaps is the speed, or I should better say slowness. Currently I’m on 22.04 and as with every version before that had snaps, I tried to use it a week or two before removing them completely from the system. The situation where GIMP (installed as DEB) starts in less than 4-5 seconds (while loading many plugins in the process) and something as simple as a calculator (installed as snap) needs 15-20 seconds to show up is unacceptable to me. So, my next Linux will definitely be something else.
Same here. I have been using Ubuntu for a decade. Now it is time to think about some replacement. I am going to leave Ubuntu ecosystem after building a new computer.
I wonder what are they going to do about third-party debs. Those usually depend on installed libraries.
Parodper,
I don’t know for sure, but my understanding from a previous announcement was that DEBs could still be installed only they would be wrappers for SNAP packages.
“apt-get install XYZ” installs the snap version of the package. This said, I haven’t personally used ubuntu recently enough to try this myself. Ultimately, once the snap transition is complete, support for DEB repos could be completely removed in a future major version of ubuntu and 3rd parties may just be expected to use snaps.
Including dependencies internally should actually make it easier to distribute packages that don’t depend on external resources. But of course there will absolutely be resentment over the inefficiency of these snaps. I haven’t investigated it much myself. I suspect most users will just go along with it, but in the case of services running ubuntu VMs the difference could be substantial enough to justify changing distros. If anyone knows of a link that analyzes the memory pressure of snaps in detail, please share it!
Well, though I really don’t like the way Ubuntu goes to full-snap, this decision could have a good consequence for non-debian-based distros users.
Right now, many editors consider that providing a deb package ensures “linux compatibility” for their software.
So… They’ll soon have to choose between 3 possibilites :
– stick to deb and risk losing ubuntu users,
– switch to snap, but it will mean they only support Ubuntu,
– or considering flatpaks, then ensuring a wider compatibility (even if flatpaks need tuning to be installed on ubuntu).
Since then, most of them have been deaf because they didn’t want to reconsider their choice. They’ll have to.
Snaps are an awesome concept for entreprise desktops application. It solves the entire shitty dependencies issues in an ugly, but working way. Extending this concept to an entire OS makes zero sense.
This proves that Mint Linux Debian variant was a frigging good idea. Never trust a distro done made by a single company.
Considering Ubuntu is forcing Snap and Fedora is forcing Flatpak. It will be interesting to see on where that leaves distributions still providing more traditional packages. Will for example Debian gain more users or on the long run lose them. Will for example general public just install Ubuntu or Fedora and enjoy latest versions of FOSS and proprietary applications provided as Snap or Flatpak. As this is news about Ubuntu in my opinion this move to force Snaps can succeed or it can fail. In order to succeed what needs to happen is a huge number of FOSS and proprietary applications must become available as Snaps. In that case general public should be OK with it. If the influx of FOSS and proprietary applications packaged as Snap will be slow. Then this effort will likely fail.
The difference between Snap and Flatpak is that Canonical still holds the keys to the kingdom with locking Snap to their distribution server. Going Snap is going full steam ahead with Canonical.
Despite all handwavey excuses about being able to make your own Snap server and effectively having to fork the Snap client to make it work, Snap is bound to Canonical’s proprietary server infrastructure. Breaking away from that would fracture the Snap App landscape and is thus undesirable.
Flatpak on the other hand is not bound to a single distribution server. You can add multiple servers. While Red Hat is going in heavy with Flatpak, it isn’t to use it as a means to lock you to them. Flatpak is distribution agnostic in that sense. The freedom aspect is far better with Flatpak.
It’s the same shit. That is Snap or Flatpak. Said that i remember when Ubuntu was peaking and there was really no reasonable explanation on why its market share isn’t rising. There was on the other hand a lot of excuses. So if a distro like Ubuntu ever wants to challenge Windows, iOS or Android. The very first thing it will need is to provide all necessary and unnecessary FOSS and proprietary applications. That is the latest version from some store. Majority of Android and all iOS users couldn’t care less if their app stores are unavailable to them. So maybe it’s time for one of the GNU/Linux distros to start targeting such users. And lets see how that goes. FOSS apps will still remain FOSS apps. Using a .deb package will remain an option in foreseeable future. Device drivers will further improve due to higher market share. It’s time i guess. For a major GNU/Linux distribution to take on App Store and Google Play directly. As most people are prepared to use App Store and Google Play and not whatever GNU/Linux distros are providing currently. That is something about 1% of users is happy about. And in foreseeable future that option will still work on Ubuntu.
“Traditional” packages mean a middle man package maintainer that repacks and ships the software. That means more payroll, outdated packages in repos he hasn’t gotten to yet, and whatever other problems that causes. “Traditional” will die a slow death as more and more commercial distros abandon the idea so they don’t have to pay people to do that. Hopefully they figure out how to make the Snaps/Flatpacks not use 2-3x the memory and disk space of traditional applications before then.
dark2,
I agree, the repo maintainers have traditionally put in a lot of work to build software, patch vulnerabilities, coordinate libraries, create default configurations, and create a comprehensive whole of a system such that users can install thousands of packages without doing any of the legwork themselves. Whether a distro is comprised of salaried workers or volunteers, this is a whole lot of work. Snap/flatpak/appimage/etc help move the packaging burden to upstream developers.
Short of using some kind of AI to do the coordination and patch work across projects, I don’t think this is going to get better as upstream devs become responsible for their own packages. Technically it wouldn’t be too hard to dedup common resources between packages, but the bigger challenge is enforcing that all package developers use the same same version of resources and not something older or newer. Without the central authority of a repo maintainer, everyone will end up using different versions and patches willy nilly and we’ll have to accept the inflated memory/disk requirements.
What the hell, is Shuttleworth getting a backpayment from Hynix or something?
Having said that the fundamental problem with DEB (and other linux package tech) is that it doesn’t really distinguish an user facing application from some component, library or even system module. This is a fundamental problem for users who want to be assured that they won’t break their system by trying out some app from the store.
The immutable, snap only system provides this assurance on an architectural level. Fundamentally its a choice between performance and being idiot proof. Apparently Ubuntu have made their choice for good or bad.
I expect they will loose the remaining tinkerers from the user base but that’s ok. Success of mac shows that developers and system tinkerers are not the same group (non-developers are really not the core audience of Linux). There are many distros in Linux space and competition is healthy.
“Competition is healthy”, yes, but the part people like to ignore is that’s only true when the competition is real competition. Simply existing in a tiny footprint isn’t enough.
friedchicken,
I can agree with that. existing at a subsistence level isn’t the same as healthy competition.
Ubuntu and redhat are the two most dominant linux distros, but at least they’re not so dominant that they’ve killed off the alternatives. I think IBM/redhat may be trying to do this, but time will tell where that goes.
It terms of DEB, while I’ve been using it forever, I don’t hold it sacred. I’m ok with distros trying something new. The thing I don’t like about SNAP though is that it’s hard coded to a proprietary service that canonical, behind closed doors, might intend to turn into an apple-like walled garden. This would be very bad for users & FOSS. I don’t see this happening short term, but it might be their long term goal to move into a position of control over users & devs.
This is definitely going Musk/Twitter way. Just breaking down well working thing. OK, whatever, Linux is choice, farewell Ubuntu, that was a good 10 years together.
So long and thanks for all the fish…