Oh Snap... Desktop Ubuntu Core to arrive in 2024 Initially leaked in a forum comment, it has been confirmed in a blog post: Canonical will soon snappily jump aboard the immutable distro bandwagon. Lead Snap developer Oliver Grawert casually dropped the announcement in a comment in a story on the popular OMG Ubuntu site, but the news was confirmed the very next day in a …
I still don't understand what "snap" or "flatpack" actually are or what they actually do. Or why they hell I would want/need to use them.
My distro already has two of "package managers". One with a GUI ( yast ). And one CLI ( zypper ), that lets me fuck things up if I want/need to. What more do I need? They have work fine for decades.
So .....................
They are designed for apps (as the article says). They bundle up the app and all its dependencies (libraries, servers, etc) in one file, and when the app is installed it gets its own copies of all those dependencies. If another app needs the same dependencies, it has its own copies of them (which may be different versions and/or different configurations).
It is like using a container for each app (and can even be implemented using containers).
Of course, that is very inefficient in storage (disk and memory) - but those are much less important than they used to be (they are dominated by the data they have to manipulate nowadays, not the code any more). And it certainly simplifies testing and release of the applications: no more worrying about App1 breaking because a library it uses was upgraded when App2 was installed. Probably the main downside is that when a serious bug is found in a library or a server (say a security breach) you are dependent on every app supplier to release a new package in order to be protected from it: you can't upgrade the library and have it fix all apps.
The idea isn't new - I remember discussing this same idea in the early 2000's as a solution to the problem of testing application combinations in Nokia's Maemo mobile phone OS. We quickly rejected it then as there just wasn't enough storage to waste on multiple copies of anything. But nowadays the inefficiency is not really a problem.
I am too old to switch to this approach now - I will stick with apt. But I am beginning to hate flatpack/snap less than I used to.
[Author here]
> The idea isn't new [...] I remember discussing this same idea in the early 2000's
NeXTstep started doing it in 1988 (unfinished 0.8 demo version, September) with its `.app` bundles. Today, NeXTstep is called Apple macOS, iOS, iPadOS etc. and has billions of users.
NeXT arguably got this idea, and the Dock concept, from Acorn's RISC OS, which packages apps and all their dependencies into a folder tree whose name starts with `!`. !Edit, !Paint etc.
The first version was called "Arthur" and was released over a year earlier (June 1987, v0.20).
I interviewed its original developers last year:
https://www.theregister.com/2022/06/23/how_risc_os_happened/
This concept is older than Windows 3 or the first ever version of OS/2, and dates to before the 1990s let alone the 2000s.
I also have an issue with
On top of that, apps are also sealed units — they can be installed, updated, and removed again, all without making any change to the underlying OS. Because of this, when you get an OS update, you can safely install it knowing that it won't affect any of your apps.
Unless, of course, some dick changes an API or security model. It's great...until it isn't.
Unless of course if you want to modify something, which you then you have to learn the commands for this lock-in system.
The article states that snap isn't proprietary. Well, a proof of concept doesn't reflect reality (not even close) and lock-in isn't exclusive to proprietary.
Supposedly "billions" are giddy for Snap in the same way they were giddy for Google back in 2000. Hey, they're just trying help... it's just a little lock-in, don't worry people... sshhhhhhhhhh don't worry.
And it’s all very well existing developers creating snaps of their previous handiwork. But please, please, for the love of $DEITY document what the new commands are to configure things through the snap command line interface instead of config files. It’s really difficult trying to guess what the parameters and arguments might be.
OTOH as I’ve written elsewhere, I’m running a digital sign using Core 18 on an old desktop that doesn’t support UEFI. Running (and particularly maintaining) the same using Ubuntu desktop isn’t an experience I’d like to repeat. Self-updating big blobs of code make perfect sense here.
This article is a few days late, but it's the best piece on the new Ubuntu immutable desktop I've read so far!
I agree that Snap is wonderfully suited to an immutable desktop. I wonder how they'll fill the gap for stuff that doesn't exist as a Snap yet. Maybe you will be able to add apt or dpkg as a Snap?
I am fully on board with the idea of an immutable Linux. However, I absolute HATE Gnome, so my options are a limited at the moment.
Ubuntu -> probably has the cleanest/most suited technology for immutability (Snaps) but no KDE support yet. (although to be fair, Ubuntu's heavily modified version of Gnome is quite useable.) I guess you could package all the DEs that Ubuntu supports as Snaps, that could be very interesting, but it's not going to happen next year I guess.
openSUSE -> the brand name I prefer the most, might be due to nostalgia (SUSE was my first Linux) or the great logo (chameleon) or the fact that it's a bit of an underdog nowadays even though still much more popular than other has-beens like, say, Mageia or Slackware. As a non-immutable distro, I think Tumbleweed is the best there is, due to the combination of the newest Plasma desktop and superb reliability due to rollback with Snapper. But Kalpa is still "alpha" and the Aeon creator, R. Brown, hates KDE and wants it gone. Let's see what will happen.
Fedora -> I really don't like Red Hat nor GNOME and hence I would have never thought about using Fedora. And in terms of technology, I find it weird how Fedora Workstation uses btrfs but not Snapper! But Kinoite is probably the only actually useable immutable KDE distro. And furthermore, Kinoite appears as an equal to Silverblue on the website, not just as a Spin or something secondary. So... maybe Kinoite it is.
then along comes Canonical with the [redacted][redacted] and [redacted] POS called SNAP and forbid distros from using anything but this POS.
Ok, I am not the greatest fan of Canonical. In the beginning, Ubuntu was a breath of fresh air to many newbies. Now? They are IMHO up there with the worst of the idiotic practices that MS is tying down W11 with. They want to make their version of Linux the ONLY Linux left standing and naturally, a major part of their cunning plan is the POS called SNAP.
WAKE UP PEOPLE. Stop this insipid takeover that is designed to reduce choice in the Linux World.
This is a dark day and one that I hoped would never happen when I started using Slackware 1.1 all those years ago.
Canonical can suck on this --->>> [see icon]
>POS called SNAP and forbid distros from using anything but this POS.
Really? Let's see.
- Ubuntu & flavours: Snap preinstalled, Flatpak in repo
- Mint, pop_OS: Flatpak preinstalled, Snap in repo
- Solus, KDE Neon, Zorin: both Snap and Flatpak preinstalled
- Debian, Fedora: both Snap and Flatpak in repo but not preinstalled
- openSUSE, Arch, RHEL: Flatpak in main repo, Snap available via OBS/AUR/EPEL
- Mageia, OpenMandriva, PCLinuxOS, Void, Alpine: Flatpak in repo, Snap not available at all
Ubuntu, Debian, Arch, Void and Alpine also have Nix in their repo by the way, and it should work on all the others via the Nix installer script.
Then there's Appimages, and of course the native DEB/RPM/PKG.TAR.ZST are also working.
Where does Canonical force distros to use Snap and forbid them from using anything else?
See article. Ubuntu derived distros (ie remixes) are now barred from shipping with Flatpak preinstalled.
Snap is stupid in that you cannot tell it to not keep an older version around, at minimum it insists on keeping at least one older version. At best that's dead weight eating up space on your very expensive NVMe drive. At worst it's an exploit waiting to happen. Yes you can use a cronjob combined with a script to delete old versions on a periodic basis, but that's just plain stupid and an unnecessary waste of CPU cycles.
Also the snap backend is proprietary and there can only be one snap repository, and it's owned wholly by Canonical. Compare flatpak which supports multiple repos and you'll see how that is bad.
>>Also the snap backend is proprietary and there can only be one snap repository, and it's owned wholly by Canonical
Did you actually read the whole article? Here, I will paste it in to this comment to save you the clicks... CBA to recreate the links from the paragraph so if you want them you will have to go have a look for yourself.
Bootnote
Don't believe the FUD. Sure, there is only one official public Snap store, but having a single public outlet does not mean that Snap is proprietary: It isn't. We have already covered a proof-of-concept independent public snap store, although it's gone now. At the Ubuntu Summit, we also spoke to representatives of companies running their own private Snap stores to deploy software and updates to fleets of Ubuntu Core instances. It's perfectly possible to create, sign, publish and distribute your own Snaps, and all the tools to do it are included in the distribution, and they're all open souce.
TBF I think this article is what Steve Davies 3 was referring to:
By order of Canonical: Official Ubuntu flavors must stop including Flatpak by defaultCanonical 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 sanctions and endorses what is an official flavor, and what isn't. And Canonical has spoken: From the next release, no official variant shall support Flatpak any more. Canonical has its own official cross-platform packaging format, Snap, and as from version 23.04, only Snap is to be built in. The Flatpak plugin for the Software store will be removed too.
...
If you like Flatpak – and a lot of people do – then you needn't worry. The Flatpak tooling will remain in Ubuntu's repositories, so you will be able to add it back in very easily, as described on Flathub. There are just three steps, and you can even skip one of those if you don't use the graphical software store.
Yeah, I would so dump Ubuntu in a heartbeat if OBS would officially support other distros. So far they only support Ubuntu, and the other versions are community maintained and crippled to some degree (most versions don't have Streaming Service Integration ie Chat and statistics and web-based signin, instead requiring you to enter the stream key and server name manually). Also, some distro like OpenSuSE patches their OBS (in OpenSuSE's case the patch is to revert it to use Qt5 when the official OBS has moved on to Qt6. This breaks any third party plugins that have rebased to Qt6 following the official OBS, and also older plugins because OBS has had a massive API change when they moved to Qt6. As a result the build is incompatible with both new and old plugins).
Calm down. There is a contest of technologies here. This article, surprisingly perhaps, make the case the Canonical has the best tech for the job, and the job is a safe, sealed-unit OS like Android or iOS. This will put desktop linux well ahead of Windows. And there will always be Arch.
-> perhaps ones looking to repurpose existing fleets of desktop machines and thin clients which used to run Windows. For example, subsequent to a ransomware attack — a window of sales opportunity exists which Google has used to its advantage to sell its ChromeOS Flex offering before now
I wonder how many companies have actually done this - moved to Linux desktops due to ransomware attacks which were effective due to Windows security issues. The usual problems of Linux on the desktop still apply - the lack of 'standard' applications.
Lack of standard applications?
Open Office - done
Firefox - done
Video editing - done
Image editing - done
Android dev - done
3D - done
Basic website authoring - well that one leaves a lot to be desired for sure
Oh, did you mean MS products not being ported? Screw MS. All the above also run on Windows machines. Seems pretty standard by definition.
Or were you referring to the usual complaints from uninformed users? (No snark, I honestly think you were)
>>Teams is a bit odd/clunky but that's the same for the ones using Windows.
Certainly for Manjaro (and presumably Arch) the AUR Teams application seems to work just fine for me (not one of the many web wrapper versions available, a Teams client that is actually a client). It did have a hiccough for a while but got its act back together.
IMHO Web based Teams is a PoS that should be consigned to the great bit bucket in the sky. Some might argue that Teams itself should have the same fate.... and Microsoft unbundling it form Office may just do that.
Video editing, maybe for a light home user sure, but if it doesn't run Premier or Pro Tools that's the userbase it's going to stay with. Have you tried editing 4K video with 7.1 Dolby Surround on a Linux app? How was the video-audio latency? Was it less than 2ms? If not, get off my lawn. If there's one that's capable of it and can export to industry standard formats I'd love to know what it is.
Same for photo editing, Lightroom and Photoshop are in a different galaxy than anything available on Linux. Yes I've tried them all, I'm a semi-pro photographer. I don't *want* to pay rent on my software to Adobe, but the competition leaves me no choice.
Desktop publishing? Thought not.
And yes, the MS apps are very important. Obviously not to you, but to the millions of users around the world who use them for business, there are no alternatives. Office 365 is really good, but it doesn't cover all bases.
These are the "standard apps" that people are talking about when they use that phrase. They don't want alternatives, they want the ones they know how to use, the ones they know can do the job - because it's not about the OS. It's not even about the apps. It's about getting stuff done.
> Video editing, maybe for a light home user sure, but if it doesn't run Premier or Pro Tools that's the userbase it's going to stay with. Have you tried editing 4K video with 7.1 Dolby Surround on a Linux app?
If Blackmagic's DaVinci Resolve doesn't satisfy your needs, what do you want? It's widely regarded as one of the best NLA/VFX/grading packages in the industry. It p****s all over Premiere while laughing. And while only free in the sense a beer might be, I'll take that any day over Adobe's virtual prison.
I'll also throw Blender in the ring, because it too has little trouble knocking out Adobe's and Apple's contenders when it comes to video editing. And that's free in both senses.
This post has been deleted by its author
-> Open Office - done
Until/unless Open/LibreOffice works 100% with MS Office documents, it is not done. That is the truth.
You have a short list of applications. There are simply bazillions more 'standard' apps which are available on Windows. In the AV world you can use DaVinci Resolve. But there are more people who use Adobe Premiere Pro. That is the standard app. As is Photoshop and Illustrator. So your 'done' list is not done. Your done list is for people who do not need to interoperate with other people.
-> Open Office - done
Until/unless Open/LibreOffice works 100% with MS Office documents, it is not done. That is the truth.
I love the down votes on this but, in the enterprise, it is a fact. Nobody is using Open Office en-masse in the enterprise. Nobody wants to be sending out or reading mangled documents and nobody cares whether that's MS's fault or not. It is the de-facto, period. Major Governments bodies in Europe have done some to and fro on using other office suites but all it takes is one sweetheart licensing deal from MS and they're straight back on board as it means they don't need to deal with "this doesn't look right" and "I used to be able to do...." and can just concentrate on all the other issues Office gives you.
Open Office in 2023 is essentially a dead project now having had virtually no updates in years. I know you can argue that office software doesn't need that many updates and that MS Office 2007 can do the majority of stuff that Office 356 can do. But unless you really need a legacy office suite which has essentially not updated in almost 10 years you are much better off with Libreoffice, as there have been a lot of improvements made to the code base since Libreoffice forked from Openoffice.
And going forward we will mostly likely start to see more AI tools implemented into Libreoffice to help people create better MS compatible documents, something I don't see happening with Openoffice.
The only thing it has kept Openoffice still relevant is its name which has been around longer than Libreoffice. They should really merge the projects back to one now since Oracle is out of the picture and that was the only reason it was forked in the first place. And let Libreoffice use the Openoffice name for their project going forward.
[Author here]
> Nobody is using Open Office en-masse in the enterprise.
You missed the point. Actually, you missed 2.
[1] Open Office is dead. The corpse just twitches a bit. LibreOffice is the living offspring.
[2] It's irrelevant. You're right, business isn't using it in volume, but the real point is, they *are* using web apps in real volume... volume enough to support multiple major development efforts: Google Apps, and Microsoft 365, and smaller FOSS efforts such as OnlyOffice and Collabora.
The locally-installed rich office suite is irrelevant now. Which is what I said in the article.
[Author here]
> That is the truth.
No it isn't.
As the article spells out: it's irrelevant. That is why RH is removing it.
Users can use MS365, including for free, in the browser -- any browser, not just Chrome -- and get perfect fidelity. They can also use Edge on Linux.
There is even an unofficial flatpak:
https://flathub.org/apps/com.microsoft.Edge
Also see:
https://flathub.org/apps/com.google.Chrome
The argument, and the fight you want to have, has moved on. It's not over: it's just not important any more.
We gave up on using OpenOffice because of Excel macros. Parts of our organization above us use way too many of them and some of those spreadsheets are mandatory for us. The other problem was that nobody really liked OO. It was just different enough from Office, and just slow and crash-prone enough, to turn people against it. It has a sort of dated, amateurish feel to it somehow.
The reasonably large corporation I work at uses a combination of Citrix server sessions for standard users and VDIs for those that require a little extra. More controlled, better continuity, access from anywhere etc. It is a much more logical way for an enterprise to work.
[Author here]
> I wonder how many companies have actually done this
I interviewed one last year but they decided that they did not want tech details to be published, which is fair enough but unfortunate for me.
https://www.wsj.com/articles/inside-a-ransomware-hit-at-nordic-choice-hotels-11641983406
https://9to5google.com/2022/01/07/chromebook-cloudready-windows-malware/
ChromeOS is bigger than most of the industry realizes or acknowledges. Chromebooks outsell Macs, by financial value. Since the average Mac is 5-10x more expensive, that means they outsell Macs by 10:1 or so.
Linux arrived on the desktop years ago and it has hundreds of millions of happy users. Many more than Macs, and macOS on the desktop is 10x the size of all existing Linux desktops... meaning that all existing desktop Linux is under 1% of the ChromeOS user base.
(I suspect, but cannot prove, the other half of the desktop Linux user base is in China and its neighbouring countries.)
ChromeOS Flex lets companies move existing hardware to ChromeOS, for free, so long as they use Google's existing fleet management tools -- but only so long as they use Google Apps for Business, which many businesses already do. You can use other cloud apps and suites of course but they must use Google Apps to authenticate. Nothing else is supported.
...Just like there is there is only one PyPi. That is what scares me about Snap and Flatpack. Who is watching the watchers? Is anyone really watching? I learned when I was a child not to put my all of my eggs in one basket. So why should I trust a distro that asks me to do that?
I had to get halfway down the article to learn what an immutable distribution is but..
This is not something I'd ever use. Phones are boring because you can't get in and mess about with the OS. But then I'm not a typical computer user, in the same way that a car enthusiast who likes to tinker with his car on weekends isn't a typical driver. What most people want is an appliance, and this, it seems, gives them that. This almost sounds like something my elderly parents could cope with, they've just about grasped how to install apps on an iPhone, and the fact they can't bugger up the OS by doing it means I don't get a lot of "support calls".
Be interesting to see how it pans out.
I had to get halfway down the article to learn what an immutable distribution is
But it still doesn't explain how this works, besides a few casual references to COW.
For the principal notion in the article, this is disappointing, considering that less important things do get explanation.
What I have wanted for a long time is a clear separation of system and userland, so that the system can be reinstalled but my personal configurations are preserved. I guess M$ is the root of this evil. Often nowadays "applications", or at leasy huge config files, get installed in userland.
My ad hoc solution is a load of symbolic links from /home/pt, which is nowadays full of this crud, into /paul, which is my own filespace. Of course this doesn't work if you're sysadmin even for a small group, let alone a company.
[Author here]
> But it still doesn't explain how this works, besides a few casual references to COW.
I have written about this extensively on the Reg.
In 2021, the problems:
https://www.theregister.com/2021/11/26/linux_software_installation/
https://www.theregister.com/2021/12/03/nixos_linux_os_design/
This year, the various solutions:
https://www.theregister.com/2023/02/14/make_linux_safer_p1/
https://www.theregister.com/2023/02/16/bulletproof_linux/
[Author here]
> I had to get halfway down the article to learn what an immutable distribution is but..
OK, my bad. I & my colleagues have written about them so much I took it as a given. My mistake.
2021:
(Before I joined)
https://www.theregister.com/2021/02/18/kinoite_immutable_fedora/
(After, by me)
https://www.theregister.com/2021/11/26/linux_software_installation/
https://www.theregister.com/2021/12/03/nixos_linux_os_design/
2022:
https://www.theregister.com/2022/05/12/fedora_36_released/
2023:
https://www.theregister.com/2023/01/12/endless_os_5/
And many more.
As an IT professional, I'm in a funny place here. I spend all day working with Linux servers. But I don't run Linux on my laptop, because my laptop is a *tool* and I need it to work; I can't be fighting it when I'm supposed to be fixing something else. It needs to just *work*. This is why as soon as OS X came out half the sysadmins I knew bought MacBooks.
Likewise, I don't run Linux on my computer at home. Because working with Linux is my day job; I don't want to do it recreationally.
Also an it professional. I daily Linux for both work and home use. When I've been required to use osx, I've found it too restrictive and locked down for my needs. It would continually place roadblocks in my way, making me waste time to work around them, where Linux just gets out of the way and lets me do my job.
I guess I've just never found Linux and laptop hardware to be a good mix. Every OS update would break something, usually sound or wifi. I got tired of chasing it down. But it does depend on what you're trying to do. My needs in a laptop are not complex; I mostly just need a good terminal emulator, SSH, and an X server. macOS with XQuartz fills the need pretty well. If I were installing complex packages the locked-down nature of it might matter more, but as it is it just means there are fewer ways it can break.
So, supposedly having the OS "immutable", and the apps isolated, will prevent insecurity. Just like it does on Android. /s
But, to be useful the apps must communicate. So there still exists the possibility that an app could be malicious, or that an app might be compromised by externally sourced content, and exfiltrate information. You simply move the hacker's target from the underlying OS to the user application subsystem.
I think it's more about clear lines of separation. If an app has a vulnerability you can replace just that app. If the system has a vulnerability you can just update the system. And in either case (at least in theory) you don't get into dependency hell where one update triggers 200 more.
Also if the system is immutable you can do some neat tricks, like making it completely read-only except during updates. (Apple does this on recent macOS versions.) This makes things like rootkits harder to install.
". If an app has a vulnerability you can replace just that app."
*Just* that app? For example Firefox snap is larger than whole OS running it. Multiply that with the amount of applications and you *will* replace 10 to 50 times *more* code than single OS library.
And it's 'when', not if. Applies to everything, ever.
"Snap keeps them whole and loop-mounts them to run their contents."
So every snap has gigabytes of compressed libraries you have to uncompress and load into memory before the program can even start.
Amount of wasted IO alone is staggering. You'll also have gazillion copies of same libraries in the memory (for gazillion different programs) just because that's the way it's built.
Start-up times are measured in minutes instead of milliseconds, because of said IO -requirements. When you need to update a library, you need to download gazillion snaps as they don't have *anything* in common.
Basically you run whole wirtual machine *for each program*. Vzkernel did that, but even that used actually common libraries, despite every virtual machine believed they had their own. Snap or Flatpack aren't able to doeven that, so they are *worse* than vzkernel.
And then some moronic developers believe this is a *good* idea for end users: It's not. It never has been and never will be.
Huge amount of wasted resources *just* because some idiot developer saves 10 minutes of effort to create 2 or 3 different packages for different distros. Absolutely bonkers.
>> *just* because some idiot developer saves 10 minutes of effort to create 2 or 3 different packages for different distros.
"Just"? You ever tried to learn how to build a deb, and rpm, and whatever the fuck Arch uses? Ever spent the time setting up multiple build environments "just" to support each distro? Ever realised you need to support multiple versions of each distro, and you need to produce new packages every time each distro brings out a new release, so you're compatible with whatever versions of the libraries they've decided to release? 2 or 3 different packages? More like 30. Life's too bloody short.
The real solution to this is not Snap, or Flatpak. The real solution is for everybody to use Ubuntu, or whatever, so we can all use the same packaging tools and only have to do it once.
Also, I'm not an idiot.
All the successful examples are very constrained, OEM-supported affairs with system images designed specifically for the hardware they are installed on to ensure that everything “just works”. This model does not work on your typical Linux distro, where a combination of proprietary firmware, proprietary drivers and software dependent on custom kernel modules is often needed for systems to work as intended.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
