Strong support for Snap and Ubuntu Core as Canonical meet IRL Canonical remains committed to its Snap format as the coverage at its first public gathering in a few years shows. Vulture Towers Central Europe are in Prague – which, handily, is also the location for Canonical's 2022 Ubuntu Summit. A significant amount of the coverage is devoted to the company's IoT offering, Ubuntu Core, …
Snaps or Flatpaks, they both have similar issues.
Canonical have been working on Snaps for some time, so probably don't want to lose that work. They were proposing that other distros also use Snaps, but it appears most have gone for Flatpaks, but many distros support both. They are both built on features that are available on many Linux distros, although the dependence on systemd by some snap packages is a bit of a constraint.
that is spreading everywhere. I stopped using any Canonical based distro when they decided not to feedback bug fixes into the kernel.
Now that you need to use Snap in order to get an HTTPS cert for your webserver if you go want to use a 'letsencrypt' cert, slowly but surely the Canonical SNAP disease will infect the rest of the Linux world.
F Canonical.
I wasn't aware of this. I'm continuing to successfully autorenew on an 18.04 Server box, and it's apparently not installed as a snap (the only thing I do have installed is an ffmpeg snap, which was my first and hopefully last experience of using the things).
Actually having looked into it a little I appear to be running an ancient version installed via apt…pip might still be an option to get up-to-date versions on newer Ubuntu releases though?
The autorenew bot? You can simply execute the script, you don't need to "install" it. The script is like 20 lines... a curl and a conditional cp.
Snap is Canonical's shitty proprietary attempt at locking commercial users in and it cowardly pretends all the other options portability and isolation don't exist to justify its own existence.
It's off topic but, I think Canoical is going to sell to Microsoft.
[Author here]
> Snap is Canonical's shitty proprietary attempt at locking commercial users in and it cowardly pretends all the other options portability and isolation
I want to address 4 things here.
> proprietary
It isn't. It's based entirely off FOSS code, uses tools like `squashfs` and systemd mountunits and loop filesystems, with code originally written in Python and now in Go. Nothing in it is proprietary, and the tools to build both snap packages *and snap stores* are included in the Ubuntu repos.
I know of at least 3 snap stores: Canonical's, Rudra Saraswat's LOL, and Screenly's internal one.
The story that there's only one and it's proprietary is 100% pure FUD.
> commercial users
Snapd is free of charge, the snap store is free to use -- not even a login is required -- and snapd runs on multiple OSes. It's not tied to any desktop or browser or anything. It's all FOSS all the way down.
> pretends all the other options... don't exist
AppImage works and I use it. It does use some rather old tools to build them, though.
Flatpak works, and I have used it. It's GUI only though. It is not possible to install flatpaks on a text-only machine, such as a server. You can't have a kernel flatpak for instance, as used in Ubuntu Core.
So, while Red Hat has Fedora CoreOS and Kinoite, they are GUI-only. For server stuff you must use containers. And while SUSE has MicroOS, again, it's for containers only.
*Only* Ubuntu's tooling can do cross-platform containerised apps on a text-only server, or on a minimalist embedded OS, e.g. for IoT, and still use these cross-platform apps.
It's not that Ubuntu pretends SUSE and RH solutions for this don't exist; it's that SUSE and Red Hat do not offer solutions for this. They have the OS, but they don't have an analogous packaging tool. On the RPM side of the fence, you will have to run Kubernetes and containerised workloads. This is perfectly doable and it's something both are selling, but it's harder.
Umm..... thanks for jumping in to these shark infested waters.
First, can *anyone* create their own snap store? Currently, anyone who wants to can create a PPA or repository to distribute software, can. As far as I know, short of using the --dangerous flag (designed for development use only) that isn't possible nor encouraged.
Second, I hate to contradict you, but Flatpak works just find *without* a GUI. I've set it up from a terminal, I've installed it from the terminal, I install applications from the terminal, I run them from the terminal, and I keep them updated from the terminal. Of course, if you install GUI applications, then you need a GUI. But, if you install CLI applications, they run just find from a terminal. Admittedly the 'use' of installed Flatpaks, especially from the command line could definitely be improved. I'm not recommending Flatpaks, I prefer native packaging, but I just wanted to point out that CLI Flatpak is definitely possible.
I've stripped all of the unwanted and unasked for Snaps from my Kubuntu installation. Canonical makes it needlessly difficult. To add insult to injury they *booby-trap* .debs to secretly install a Snap when you requested a native application. The final insult is to *remove* naively installed applications when upgrading Ubuntu family operating systems. Yes, I am referring to the now infamous Firefox replacement. It was wrong, Canonical should admit it and pledge never to do something like that again. I had to pack up my files, uninstall the unwanted Snap, rummage around for the *secret sauce* needed to install an actual .deb version of Firefox. As mentioned previously, Canonical has decided to go down the evil path of *booby-trapping* .deb files. That's something else that Canonical needs to apologize for and swear to stop doing. And *finally* reinstall the native Firefox that existed before I upgraded and Canonical so rudely pulled that stunt.
Finally, you really should not be conflating non-native application schemes, Snap, Flatpak, AppImage and containers management systems like Kubernetes. It comes across like comparing apples and monkeys.
Thanks for your time,
Google (or duck-duck or whatever) is your friend
See e.g.:
https://ubuntuhandbook.org/index.php/2022/04/remove-snap-block-ubuntu-2204/
To keep snap away permanently (quote from the above):
sudo gedit /etc/apt/preferences.d/nosnap.pref
When the file opens, paste lines below to refuse snapd from any repository:
<code>
# To prevent repository packages from triggering the installation of snap,
# this file forbids snapd from being installed by APT.
Package: snapd
Pin: release a=*
Pin-Priority: -10
</code>
"Snap and Flatpaks are just the symptom. Packaging software for Linux is a huge blancmange"
^ I fully agree with this. We have insane splittism in Linux when it comes to packaged format systems with Snap (The People's Front of Judea), Flatpak (Judean People's Front) and AppImage (Front of Judea's People) all trying to do the same thing.
I'd like to see the three commercial Linux distributions (RedHat, Ubuntu, SUSE) get their acts together to sort this unholy, anarchic mess out once and for all with a single agreed and recommended package format.
Unfortunately, it will never happen until Canonical stops chasing the 30% snap store $$$.
There are too many ways to package apps in Linux, this is a given. The main problem I as I see it is that both of the *major* Linux families are currently run by commercial entities, IBM (RedHat) and Canonical. Neither wants to give up the commercial advantages that come with controlling the package format.
There are many, mostly commercial, software packages that are only distributed as .RPM, just look at IBM, RedHat, Oracle as examples. Either you are running in the RedHat family, or here's you .tar.gz good luck.
On the .deb side, Debian, and by extension the community, controls it. Since Debian, the distribution, isn't all that user friendly, especially when you have non-free hardware (which is pretty much most hardware these days), most users are running second or third generation distributions based on Debian. Ubuntu is one such distribution. Canonical has made it one of the easiest to get started, supports the latest software, and seamlessly 'just works' on most people's computers. This has made the Ubuntu family probably the most popular distro-family based on Debian and the .deb package format.
Canonical doesn't control the .deb format. So they need a format that they control, preferably one where they have gatekeeper ability (see Apple and the App Store). Welcome Snaps. All they need to do is to replace .deb as the primary package format with snaps. Now when you try to install Firefox on the current Ubuntu, even when specifically using the .deb package, it silently replaces it with the snap version. Their large user base makes it attractive for developers to create snap versions of their packages, and other distributions have added support for snaps, though not to the level of Canonical products, to support their users desire to install applications that are increasingly being distributed only in the snap format.
Even without the control Snaps gives to Canonical, it's a poor format. The loop back file system means it's slower than it should be. The locked down nature means that snaps have difficulties integrating into the wider system. Snap Firefox already has issues, besides being slower, with many extensions. It's documented how it doesn't play well with the kernel and snap 'adjustments' aren't being incorporated into the mainline kernel. And as any non-native package system, you end up with a plethora of duplicated files, libraries, etc. strewn across your system. Good luck finding all of the next log4j packages.
Personally I think it's a very bad idea to allow any one company, even Canonical, to have this much power of the Linux community.
Ideally, everyone should have picked the same native format. .deb is a great choice as it's mature, widely used, and not controlled by a single company. It's too bad Debian's current philosophy means it's destined to be the playground of die hard tinkerers and the source of many other distributions.
If you want to create a non-native package system for "applications" (kernel, DE, etc. are all BAD use cases for non-native packaging) then choose one that runs fast, doesn't take up too much space, plays well with the rest of the system, and can be installed from *any* repository or store. Currently that leaves us with Flatpak and AppImage. Flatpak's for control, AppImage for 'portable apps'.
I don't believe Canonical is going to open up Snaps anytime soon. The lure of $$$$$ is just too great. Snaps are going to become a cancer that infects every aspect of the Ubuntu system corrupting every developer seduced by the lure of the currently enormous user base of the Ubuntu family of distributions.
It's too bad, Canonical had a good run. Time to look for a distribution that's neither an Ubuntu flavor nor based on Ubuntu. Wish me luck.
> [...] Now when you try to install Firefox on the current Ubuntu, even when specifically using the .deb package, it silently replaces it with the snap version. [...]
The most prevalent story behind that is that this was being pushed by Firefox maintainers, not Canonical. And the replacement PPA is run by a "team" that includes Canonical engineers, so that further deflates the Canonical == Great Satan hypothesis.
Doesn't matter who requested it, Canonical, as the operating system provider, should never allow it. If you request a Snap, your should get a Snap. On the other hand, if you request a native application via a .deb, you should get a native package installed via a .deb. The fact is that I can go to the Debian repository and still get an *actual* native .deb for Firefox. Actually, they've now got a properly named .deb to indicate that it's a snap. What Canonical seems to have broken is the dpkg/apt/apt-get subsystem on Ubuntu+.
The actual, real, Firefox deb is about 58 MB in size. The, now named, firefox_1snap1 deb is 71kB in size.
When you enter the command: "sudo apt-get install firefox", anywhere other than Ubuntu+ you get the 58MB real native application. Running the *exact* same command on a Ubuntu+ box will instead, silently, behind your back, install the Snap version.
If I wanted the Snap version I would have gone to the Snap store or typed the command: sudo snap install firefox.
The two aren't even close.
"sudo apt-get install firefox" should installed the native application.
"sudo snap install firefox" should install the Snap version.
If you are anywhere else, but Ubuntu+ that's what you get.
The most prevalent 'story' may be that the **Firefox maintainers** pushed for booby-trapped .deb files on Ubuntu+ and **only** Ubuntu+ machines, but I'm not buying it. They are producing native .deb, .rpm, Snap, Flatpak, and .tar.gz versions of Firefox. Probably some others as well. It's only on Ubuntu+ that "sudo apt-get install firefox" no longer does what it is expected and supposed to do.
I'm a partisan - I've been running Debian for a *very* long time - but at least much of the non-free firmware hassle with Debian should go away relatively soon with the outcome of the Debian General Resolution to include non-free firmware in the installer as from the next major release.
Fedora includes non-free firmware by default. Ubuntu includes firmware - but not necessarily non-free firmware.
I like .deb - but it's definitely because of software curation and because a lot of people are working very hard indeed to make it work behind the scenes. There's not much to choose from .rpm and .deb - the quality of software curation makes a big difference and the long tail of Debian or Ubuntu derivatives have too few developers to keep them all going.
"Ideally, everyone should have picked the same native format. .deb is a great choice as it's mature, widely used, and not controlled by a single company."
That would solve one of the problems with the various package managers, and it would be my strong preference, but there's another problem. Linux does not have something akin to Microsoft's WinSxS, where a binary that requires certain libraries can have those installed while the newer versions are still there. Microsoft goes out of its way to make sure that newer versions of Windows can continue to run much older software, but in Linux, the devs of many projects will break older ABIs for minor reasons, or just because it's Thursday. Some of them are Stallman types who think that all proprietary code (closed source) is bad, and everything should be distributed with the source code, allowing you to simply recompile whatever the thing is when needed. It suits their ideology of avoiding closed software at any cost, and they don't mind recompiling things.
Of course, another way of avoiding the issue is to statically link everything, but then you've addressed two problems, while the idea of Flatpak, etc., is to solve both at once.
[Author here]
> Canonical stops chasing the 30% snap store $$$.
It's free to use, just like Flathub.
30% of nothing is still nothing.
> Now when you try to install Firefox ... it silently replaces it with the snap version.
I have written here on the Reg about how to bypass that. I bypass it myself.
I also covered, in this story, how the win for the Firefox snap for Mozilla and for Canonical is that the same Firefox package runs on every version of Ubuntu from 14.04 to $CURRENT and future. So users of very old version of Ubuntu can get the same latest browser. That's good for users as well as the vendors, in this case.
> kernel, DE, etc. are all BAD use cases for non-native packaging
[[Citation needed]]
Why?
As I said in the story, it has benefits for Ubuntu Core distributing the kernel this way.
> doesn't take up too much space
As Oliver Grawert said to me: "don't look at the mount point, look at the file". Squashfs files are compressed. It is your choice, when you build the snap, whether they're heavily compressed (for a smaller size) or lightly compressed (for performance, as they now do with Firefox and the content snap it depends upon).
Looking at the actual host file in the filesystem, Snaps are considerably smaller than Flatpaks. The GNOME base snap is about 200MB and contains over a gig of files.
> plays well with the rest of the system
In what was doesn't it?
As I said: you can even uninstall snapd and existing snaps will still work.
> and can be installed from *any* repository or store.
There are at least 3 snap stores out there so far. I also gave Ubuntu's reasoning for its defense of hosting the only official public one.
I am not sure if your question is rhetorical.
The problem is there are already too many package formats for Linux. As I wrote, Snaps and Flatpaks and so on are just a symptom of this. Instead of making one package system to rule them all, people just keep inventing new incompatible ones. There is no need for this. It is a waste of time and effort. There should be a Linux movement called No More Package Systems.
I know the reasons behind these Snaps and whatever. They boil down to you know for sure which versions of dependencies are available for abc app rather than relying (or should I say not relying) on what is available in whatever repo a user happens to have configured.
Snaps are a symptom of broken Linux packaging. They are not a solution. They are now part of the problem. Developers sometimes like to use the word "elegant" for their solutions. Snaps are the antithesis of elegant. They are rotten mouldy blancmanges covering up failure in Linux packaging as a whole.
This post has been deleted by its author
[Author here]
> The problem is there are already too many package formats for Linux.
This is a common complaint about FOSS. Compare:
«
There are too many BSDs. It's pointless, it's confusing, and it just causes user confusion. There's NetBSD and DragonflyBSD and OpenBSD and FreeBSD and then there's GhostBSD and MidnightBSD and FuryBSD and PC-BSD and TrueOS... even in NAS distros there is TrueNAS and XigmaNAS and FreeNAS.
Why can't they just settle their differences and combine?
It's the licensing system that's at fault. The BSD licence just encourages forking. They should relicence it all as GPL and then they could settle it.
»
It sounds plausible but in fact it's an over-simplification that doesn't consider multiple factors.
There are as many packaging systems as their creators want. All of them had their reasons.
As a result, there was a need for cross-distro ones. So two of the big vendors made them, and one chap flying alone did 0install, and then someone else made 0install a bit more general and compressed the packages and made AppImage.
Now there are 3.
https://xkcd.com/927/
This is how FOSS works. It's like evolution. Different people and groups and teams try things, and then they compete, and the best ones win out.
Lions do not compete with seaweed. Mongooses do not compete with lichen. Yet they all had common ancestors, which did.
It is how FOSS works, and if you don't like it, then go run AIX or Oracle Solaris, and enjoy the licence fees.
Otherwise, stop complaining about it. Diversity and competition are _why we have_ good rich FOSS OSes and apps.
Oh get stuffed .....
"Instead of making one package system to rule them all, "
Thanks but the reason i use linux is because there is choice... what distro what package manager what desktop etc
You spound like a poty ring disciple ...
Ive used flatpack (dogshit slow) pip (could be risky)
I prefer appimage from sources i trust and snap works if you need a quik fix ..
If you want 1 ring use microsoft ... learn to compile from source or write a distro agnostic package installer/updater and make it open!
It's a competition. This is an Ubuntu conference, Snaps are tightly associated with Ubuntu, so of course the line pushed will be that Snaps are totally great and everything about them is awesome. You could say Liam could've put a bit more gloss on it, but hey, this is a conference-report article, not a Snaps-vs-Flatpaks article, so fine.
There's lots of between-the-linesing you can do with the article if you know the general 'battle lines', of course. Lots of the lines being pushed here are defences against common points made against Snap in the ongoing debates (the single official app store, the perception of being an Ubuntuverse-only thing, and so on).
If you're not a hardcore fan of either side, I wouldn't honestly worry about it terribly. One or the other will 'win', or they'll just coexist forever, like RPM and DEB, and it won't affect your life much either way.
...but as a long-term UNIX and Linux admin, I find Snap packages flawed.
They are heavy on system resources (each package has it's own copy of what are normally shared libraries that occupy space both on disk, and in memory), and have performance drawbacks. The very security features that are in Snaps also mean that for some types of package, their usability is also degraded, making them suitable for constrained packages, but generally annoying for general purpose applications.
I also find that he cluttered mount table is in itself undesirable.
But I know I am at odds with much of current thinking, and I can really see the advantages of having contained packages with all of their pre-requisite libraries and features shipped as part of the package and under the control of the package provider in a distro independent form. It's just not my cup-of-tea. I actually prefer the really old idea of statically linked binaries, with a sophisticated link-editor/loader that includes the required library routines (and nothing more) in the actual executable. This does not have the application isolation of Snaps, but that can be provided by other mechanisms (even the ones that Snaps use, they're just normal OS features) if required.
I can see a mix of non-Snap mainline OS packages and Snap applications as having benefit, especially if it enables commercial software writers an easier avenue to start supporting Linux, but Canonical, for general use, please, please don't make everything a Snap.
really old idea of statically linked binaries
You are not alone in liking this. The argument for linking to libraries is all very well but not really relevant in days of large memories and storage. I can't help feeling that a static build of a program at least enables one to have a working version of that program irrespective of other changes in the system libraries. It strikes me - on no evidence whatsoever - that a bugfix is far more likely to affect the delivered program than the libraries upon which it depends.
The problem with static linking is that you have immutable code in your binaries.
I won't parrot hypothetical security concerns with statically linked libraries that can't be updated in the application because that's only applicable in specific cases, where there actually is a problem. (i.e. show me a problem before you wag your finger at me)
However, static linking is all well and good, until the static code in your application no longer interoperates with other APIs on the system that have changed. For example, bundle or statically link harfbuzz, and your application will be broken when the system freetype API changes (recent example with Steam a few months ago). Statically link Cairo and your application may stop working when glib/gtk or X11 machinery changes (past example with Firefox). These are just personal examples off the top of my head.
So there are pros and cons to static linking. It MAY make your application more compatible and binaries more reliable with age, but it may end up being even more fragile (depending on circumstances). Often shared libraries are backwards compatible, they still support the old functions at the front end where the internals have changed, or the APIs it depends on have changed, and your application may not know the difference. Of course that's not always the case.
I was working in the industry back when shared libraries were being introduced, and I also remember before then when everything was statically linked. I really understand the arguments on both sides. Back when memory was scarse, only keeping one copy of the C library in memory, for example, was a big win, and of course you patch your shared libraries, and you patch all of the applications linking to that library. But you can break a lot of things if you don't keep the API to all of the shared libraries constant.
This last point is Linux's biggest problem when shipping packages, and Snap, Flatpak and App Image all try to cure this by shipping their own private, unshared copies of all of the libraries. This renders almost all of the benefits of shared libraries ineffective (as it has multiple copies common libraries in memory, and unpatched private copies of the libraries), while keeping all of the problems (you effectively include ALL of the library in your executable, making them bigger). So where is the difference with statically linked binaries?
Some of the cons of statically linking programs would be less of a problem if there was more stability in the the API of both the OS itself, and other packages that you may be running and trying to interface with.
And there are solutions. IBM's version dependent WPARs introduced a shim sitting between the old executable and the new kernel and utilities (although in IBM's case, this is a bit simplistic). You make the side of the shim facing the executable immutable, while keeping the OS side and the translation from one to the other side of the shim up-to-date. By doing this, IBM allowes binaries from quite ancient (in today's terms) versions of AIX still run on current versions of AIX.
In fact, this is not that different from the fundamental function of the Docker engine, so the technology actually already exists for Linux.
...and still work, even if snapd is no longer present.
It would be even better if systemd was no longer present.
Having things like snapd tied to what was originally said to be an init replacement really shows just how far systemd's tentacles have spread.
Luckily being a user of PCLinuxOS I am spared all this jostling to be the next Microsoft.
Although Canonical does not track downloads, installations, machines running snaps or anything else
An early-access version of the Steam game store has been available as a snap for about six months, and the company told us it has been installed over 100,000 times already, even before its official release.
I only have ubuntu machines left because they are legacy. When they are replaced they won't be ubuntu. Snaps are really annoying. I think most people avoid them where possible..
[Author here]
> Snaps are really annoying. I think most people avoid them where possible..
Which is why I wrote about Zinc and its Nala and Deb-get tools.
https://www.theregister.com/2022/10/13/zinc_ubuntu_remix/
(I interviewed the creator of deb-get this week.)
So, as an experiment, I installed deb-get on a couple of machines, and then I methodically went through my list of installed Flatpaks and Snaps, and one by one, I checked each app was in deb-get, and once I had confirmed it was, I removed each app and reinstalled a natively-packaged version with deb-get.
When I was done, all I had were library packages. So I removed them. Then I removed snapd and flatpak.
Result, no extraneous mount points, a bit more free disk space, and a cleaner list of packages.
Everything works exactly the same: Franz, Slack, Skype, etc. all present and correct.
Not only is this perfectly doable if you wish, it's quite easy and I have described how to do it on the Reg this year.
I suspect, but have not tried -- yet -- that it's considerably easier than doing it on Debian. Ubuntu's breadth of 3rd party support is richer than Debian's, as it has been for a decade.
But if you want Debian, I have written about MX-Linux, Linux Mint Debian Edition, Spiral Linux and other viable better-Debians-than-Debian.
Do please report back on how you get on.
Although Canonical does not track downloads, installations, machines running snaps or anything elseCanonical wouldn't have to be tracking downloads/installations to be able to get how many times software that requires an online connection to a single destination (Steam) to function. Canonical could have gotten the nformation from Valve via Valve reporting back to Canonical how many users are connecting to Steam via the Steam Snap package reporting to the Steam server metadata about the client - client version, O/S, etc.An early-access version of the Steam game store has been available as a snap for about six months, and the company told us it has been installed over 100,000 times already, even before its official release.
because the desktop version will by default only fetch snaps from this one source, snaps are considerably inherently more secure than the older Personal Package Archive external-repositories system for distributing software that isn't in Ubuntu's repos.
By default? Does that mean that it's possible to enable other Snap sources, just as it's possible to enable PPDs?
And how many of those downloads are because people opened Ubuntu’s version of the store/discover/whatever it’s called, searched for steam and Ubuntu returned their snap version as the default?
It’s a pointless metric because people who aren’t knowledgeable about .deb, snap, ppa repos will just take the path of least resistance to get steam
Canonical should just accept it’s not wanted, drop it and join the rest with flatpaks. I guarantee nobody will want to resurrect it like they did with unity. Unfortunately as mentioned this will be about walled gardens, control and money. After their inject adverts backfired on them they need something else to cling on to for future monetisation attempts
Pretty soon Linux Mint is going to have to go full LMDE because it is going to be way too much work to get a convenient, working system out of a Ubuntu base. Or they'll relent and have Snaps enabled by default. I find it unlikely, they are constantly making reversals from Canonical and they enable Flatpak by default over Snaps.
The worst thing that Canonical has done, in my humble opinion, regarding Snap, is the heavy handed way they are trying to force it on everyone.
Yes it was developed for Core, yes they feel it's the best thing since sliced bread, then let it stand on it's own.
They should have never corrupted the dpkg/apt/apt-get system (and using it to advertise is a sin for another time). They should have never replaced existing natively installed packages with Snap versions. And if they want to counter the $$$ grab accusations, they should let Snap Stores flourish like PPAs and deb repositories before them. Keep the Canonical Snap store as the default, but let folks keep installing software from wherever they want as easily as from the Snap Store. The 'security' issue is a red herring in my opinion. We've been installing signed .debs for a very long time, whether they come from a PPA or an old school repository.
Until Canonical starts putting the needs of their users before their commercial ambitions, I don't feel that I can really trust them as stewards of my operating system any more.
.. it refused to give a large chunk of Ubuntu's desktop users the latest version of Firefox for two days. A security update was available. Users were told that there was a security update. But a combination of throttling (i.e. rationing who gets security updates) and a bug (doing a command line 'snap refresh' was supposed to work, but didn't) meant that we couldn't actually get it.
If you're gong to effectively force people to use your snap store for critical software - yes Liam, I know you can work around that, but how many people do? - at least resource it properly.
Rationing updates to a software store or Spotify.. meh. Rationing security updates to a browser.. WTF?!?!?
It's not the first time this has happened, although I think two days is a new record, but it's caused me to ditch Ubuntu.
And the really cynical part of me wonders if that's a welcome side-effect for Canonical: servers are where the money is, not desktops. That it's often (usually?) desktop users who specify Ubuntu for the servers seems to be escaping them.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
