Linux vendors are getting into Ubuntu – and Snap More than one Linux-adjacent vendor presented at the Ubuntu Summit, and a small but recurring theme is offering official Snap packages. Aside from relatively closed platforms such as ChromeOS and ChromeOS Flex, Ubuntu is the closest thing that the Linux world has to an industry standard – and Ubuntu is committed to its snap …
...it's Apparmor. It's a pain to control and debug when things are going wrong. And there seem to be a number of bugs which are driving me insane.... that's why I was running Mint for some time until they went that way as well.
Make apparmor easier, and that'll mark it a winner in my book.
(particularly giving apps permissions to things to access files which are on remote mounted SMB shares... but I think they may have fixed that.)
> Make apparmor easier,
It is already easier than SELinux, and that's why those not on RH's coat-tails chose it: Debian, Ubuntu, SUSE...
But now SUSE has dumped AppArmor (I still find it hard to skip the 'u'), that may weaken its support base, and the result may be it slips down the slope and starts spiralling the drain, I fear.
SUSE isn't a very major player, but 3 disparate supporters is a good base. Just 2 is much less so – and they're related, which is weaker still.
This post has been deleted by its author
<code>
# apt purge apparmor
# cat /etc/apt/preferences
Package: apparmor
Pin: release *
Pin-Priority: -1
# grep apparmor /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="apparmor=off"
</code>
There, fixed that for you...
p.s. ElReg, fix your ridiculous comment formatting restrictions, it isn't 1993 any more.
The issue I have with Snap and Flatpack is that they are the wrong solution to a problem
The problem being that the Linux environment - whatever you want to call it - is so chaotic in terms of library versions that running everything as individual “lite” containers becomes attractive in the first place
Snap and Flatpack have well documented issues too, in terms of inter-operability with stuff outside of the containers
But nobody is addressing the underlying problem with Linux in this respect. I’m not even sure it’s fixable. So if you are going to run everything as containers, the underlying OS becomes largely irrelevant anyway.
The BSDs avoid all this, of course, because they are all a coherent system with OS and matching userland
I can’t help feeling that Linux is starting to rot a bit. It has some issues (as does any system) and the “solutions” seem to be increasingly to add more gloop. Carry on like this and before we know it, it will be as hideous as Windows
It has ALWAYS been like this. Back around the year 2000, I often had to dig around rpmfind to get the exact version of a library to get something to work. Don't anybody say "it wasn't" or "I was holding it wrong" - I did my time patching and building kernels to get sound cards working. rpmfind existed because it was needed.
There have been efforts to fix it - LSB being one of them. I watched it with some hope, but it withered on the vine and became pointless. Flatpak, Snaps, exist because the Linux librarysphere is fluid. The number of dependencies for some software packages is gruesome. If I create some software today and link it, it might not work with tomorrow's update. Or, even worse, it might work on Debian but not on Ubuntu. Yeah, thanks for making my life difficult.
The BSDs are considerably better in this regard. There seems to be far less drama too.
> Back around the year 2000, I often had to dig around rpmfind to get the exact version of a library to get something to work
Me too, which is why I ditched RedHat for Debian, where apt actually figured out package dependencies and automatically downloaded and installed whatever you needed in addition to the package you were installing, without "RPM dependency hell"
So it's been done.
People just don't want to put forth the effort.
"The issue I have with Snap and Flatpack is that they are the wrong solution to a problem"
They're a solution to an already solved problem.
If you want to know how it's solved download LibreOffice from the project's download site and run the installer on it. Look at where and how it's installed. (Disclaimer - I'm only familiar with the .deb version but expect the .rpm will behave similarly.) That's been a solution for years but doesn't come with a trendy name.
If you want to know how it's solved download LibreOffice from the project's download site and run the installer on it.
The only reason I ventured into the world of Flatpack ("The world is flat, I tell ya!!") is because I couldn't download a LibreOffice update from the project's download site (or via the automatic updates). I got some indecipherable gibberish that passed for an error message (probably my fault because I hadn't drunk enough Kool-Aid and other magic potions to have been fully indoctrinated into the underlayers of Linux to decode them into proper action to fix the problem). But...the flatpack install for LO worked. Yeah, there were duplicate icons on the start menu (easily deleted), and the automatic updates would continue to fail until I learned to tell the automatic updates not to try to update LibreOffice. Those went away when Linux Mint "officially" embraced flatpack.
LO is still the only flatpack on my system. But it updates easily, and generally stays out of the way. So what's not to like?
Windows and macOS do the same thing via slightly different means, and have for a very long time.
On Windows the manifest specifies the versions of shared libraries to use, and the loader picks the right ones - including virtualised access in some cases. Then the rest of the libraries get installed in the same folder as the executable, even if they could have been shared.
On macOS, the loader specifies a version of the core OS libraries, and sticks everything else in a bundle. Access outside the bundle is virtualised, so it's not even technically plausible to share other libraries.
Don't let the perfect be the enemy of the good enough.
"Ubuntu event we weren't expecting to see a slide showing that Rocky Linux had some 80 percent of the Linux market in visual effects. Packer said that Moonray "was only designed to build and run on Rocky"."
That kind of doesn't surprise me as the industry standard for Linux in the visual effects sector used to be CentOS but that changed when Red Hat was taken over and stable CentOS was turned into CentOS Stream (I think that was a rather cynical, underhand and snaky thing to do by IBM-controlled Red Hat). For example, the Blackmagic Design DaVinci Resolve software's approved Linux distribution is also now Rocky Linux.
>> During the project's early days, Shuttleworth filed Bug #1 in the Ubuntu bugbase with a description that began, "Microsoft has a majority market share in the new desktop PC marketplace. This is a bug which Ubuntu and other projects are meant to fix."
And yet here we are, where Microsoft STILL has a majority market share in the new desktop PC market.
Changing the goalposts by including cell phones and tablets and declaring victory is typical fanboi boosterism. It's also dishonest. Valve has already done way more to fix Ubuntu's Bug #1 than Shuttleworth will ever do.
>> Valve has already done way more...
Oh really? Still < 3%. https://www.linuxjournal.com/content/valve-survey-reveals-slight-retreat-steam-linux-share.
Is 3% worth the time and effort? Let's be honest, it's a mediocre figure. I would wager there are more people who use Linux than the Valve figures suggest. So your snide comment doesn't hold water.
This post has been deleted by its author
> And yet here we are, where Microsoft STILL has a majority market share in the new desktop PC market.
Which is fine but the thing is that there are different ways to view this. Are we talking units, or revenue, or are we talking total profits, or profits per unit? I reckon the 1, 2 and 3 positions might change.
Units:
#1 MS, #2 ChromeOS, #3 Mac.
Profits per unit, definitely, and maybe total profits:
#1 Mac, #2 MS, #3 ChromeOS
> Changing the goalposts by including cell phones and tablets and declaring victory is typical fanboi boosterism.
No it's not. Phones outsell PCs by approaching 10:1. Trying to ignore or disguise that is boosterism IMHO. And it was not the case when Ubuntu launched in 2004.
2004: most people use Windows, a few use Mac, mostly desktops
2014: most people use phones, lots use Macs -- mostly notebooks -- and the rest use Windows
2024: most people use phones, the remainder use Chromebooks, and the rich use Macbooks. Desktops Macs are a rounding error.
> It's also dishonest.
No. Redefining 1 market as all that matters when others overtook you is dishonest. Mobiles sell in the billions a year. PCs and laptops and servers sell in the many hundreds of millions a year. *VAST* difference.
> Valve has already done way more to fix Ubuntu's Bug #1 than Shuttleworth will ever do.
For one sector of one market. A visible one but not a commercially massive one.
Remember Numpty Dumpty? "When I use a word,' Humpty Dumpty said in rather a scornful tone, 'it means just what I choose it to mean — neither more nor less"
You don't get to redefine terms / move the goalposts and say "mission accomplished." But this is EXACTLY what Shuttleworth and his apologists are doing.
It reflects poorly on everyone.
Valve's bazzite will probably surpass any other distro in terms of end users within 10 years. Because games, ease of installation, and compatibility mean more than a crap Gnome UI.
I'm lost here. Where has Windows gone in your 2024 breakdown? I would guess it remains more widely used than Chromebooks or Macbooks
> 2024: most people use phones, the remainder use Chromebooks, and the rich use Macbooks. Desktops Macs are a rounding error.
"including cell phones and tablets and declaring victory is typical fanboi boosterism."
Perhaps. But it's also a mistake to entirely ignore phones and tablets -- that's anti-boosterism, or whatever (something in the opposite but equally unhelpful direction).
Looking at the numbers and the details, understanding what they mean, and figuring out what you (generically, e.g. as Canonical or Red Hat or whoever) want to do from there, that's a different matter from mindless puffery and spin.
I'm no great fan of Canonical (or Red Hat/IBM) but I do hope when they consider topics like this, they're doing more than looking at the situation from a product marketing standpoint, and (worse) believing their own advertising.
Shuttleworth was VERY specific - the Windows DESKTOP market share. Not cellphones. Not tablets. Not IoT. Not TVs.
He failed. Bug #1 has NOT been fixed.
One of the reasons is crap hardware support. My latest pc cannot run Linux - too new, too much fancy hardware. Tried 10 different distros, including slakware, mint, ubuntu, suse - none of them support 3 gpus.
And it's the same with everyone else - solving 95% of an individual user's needs is not enough. And so many people have a different 5% of tasks where Linux doesn't work for them. So for them, it's either Windows or Apple.
My older pc (4 years old, still able to run the latest Windows, i5-12400K 128gb ram, 8 x 4TB hard drives, etc) couldn't run mx-linux properly, and fails to update, so while I haven't used FreeBSD in almost 2 decades, I know it will still do what I want, or I'll just buy another Windows license, because Linux might be ok for an old machine, it sucks when you push the envelope. It was better 25 years ago when it was my daily driver both at home and work. Even Delaware 30 years ago was better. Sure, might have to edit lifelines or modify a network driver for a new card, but it worked. It wouldn't undo any fixes on reboot.
Because it doesn't matter if Linux runs on PCs that are EOL - if it can't do what I want, on my hardware, then it is useless to me.
And I'm far from the only one in the same situation. And that's why bug #1 will probably never be fixed.
This post has been deleted by its author
My use of Linux began before the existence of debs and rpms and package managers and dependency resolution. I find it difficult to get excited about one packaging format versus another. As someone concerned only with my laptops, my only real Snap gripe has been that too many of those that interest me are outdated and built by someone who clearly isn't the person(s) who coded the thing. (Not that I find a name displayed on a page at Flathub much of an assurance of quality and security.) So, if Canonical gets some industry momentum going for Snaps, good for them.
Snaps have their good & bad points (good = all dependencies bundled - with the bad corollary of more disk space taken as everything bundled & so can "duplicates" (e.g. may have multiple snaps that have installed same required dependency instead of it just being installed once in non snap approach) & can be slow spin up time)
.. However, biggest issue (I found) was the auto update approach being on by default, discovered the hard way (since nobbled auto update so I can control what updates and when) - as on crappy copper (no fibre here in the sticks) so poor bandwidth & auto updates managed to coincide with partner streaming something which then became an unwatchable garbled mess for a while*.
* We generally coordinate things so if partner streaming I ensure no bandwidth heavy operations in progress on any of my machines.
> And again Linux will become more and more enshittified, now with systemd and snap.
Yes and no.
Snap depends on systemd. Flatpak, ironically enough as it's from the same camp, doesn't.
Saying that: I talked with Oliver Grawert, one of the creators and maintainers of snap and snapd, and he readily listed the handful of small systemd features snapd needs.
As he put it: if you implement them on anything else, snapd will be totally fine and then it will be independent.
*But*... this is the core thing here.
There are a bunch of projects that just eschew systemd and use older systems, but they do not try to outdo it.
FreeBSD seems to have solved any issues and it runs GNOME, Wayland, etc. Chimera Linux at least tries to replace systemd with FreeBSD init tools.
It's not good enough to just refuse it and ignore the functionality it brings, like seat management, handling video and sound and camera along with the plain old system console. There is no selective advantage in that.
Let's see some of the systemd-free distros do things *better* than systemd: do what it does, reproduce all its essential functionality, and do it better and faster and in less code. Then the world might listen.
Until then, just a "refusenik" attitude isn't enough.
I think that puts it rather well.
Setting aside my personal opinions about systemd, and for full disclosure they're not positive, it simply doesn't solve any problems I have.
And it's not a compelling feature on its own merits.
Aside from that, the way systemd does things is different than what came before. Arbitrarily, POLA violation, etc. Having to get used to 'systemctl <verb> <noun>' syntax after decades of '<noun> <verb>' was irritating enough on its own. At some point, why bother with the unnecessary friction, especially if it's not adding value for you.
>> shared libraries were and still are developed for RAM's sake, not for storage's sake.
RAM is also cheap. Just max the sucker out. No need for a swap file.
Also, shared libraries are great for enabling a supply chain attack, or screwing up existing programs that "well, it worked until I did an update.."
that's why static linking is so great. Unless you recompile (and why would you unless its to add new features) a statically linked binary will just work.
"Let's see some of the systemd-free distros do things *better* than systemd: do what it does, reproduce all its essential functionality, and do it better and faster and in less code. Then the world might listen."
I hope you're right, but I fear there should be a lot of emphasis on *might*.
That is, I think some of what drives systemd in Linux these days is some of what Microsoft has over PCs in general. Market control (extend embrace etc.), position, and perception.
At this point (years into systemd existence), market dominance is a factor. I.e. systemd is largely everywhere in Linux -- yes, I'm aware of (and quite appreciate) the likes of Alpine, Devuan, MX, etc. But they are a small slice overall in Linux distributions. Because systemd is so prevalent, and backed by the largest players, it's likely to continue.
Had Debian decided not to adopt systemd when Red Hat first foisted it on Linux, then maybe Ubuntu and the rest of the Debian family might have a separate/different leg to stand on, with some influence over ongoing Linux directions, and systemd wouldn't be the defacto standard for Linux, and BSD's et al wouldn't have to do extra things to get GNOME and such. Sadly that's not the way it went.
I don't expect to see a systemd-free Red Hat in my remaining lifetime, and likely the same story for Debian; though I would welcome both/either. Still, I'm doing okay with FreeBSD on most systems, and a couple remaining Debian with the minimum systemd units(?), so I'm fortunate that systemd generally hasn't been a huge impact on my own operations.
OpenRC-based Gentoo does literally *everything* better than systemd in my own experience: that is to say it just works and doesn't get in my way, over here, unlike systemd which doesn't work at all – frequently – and breaks – frequently – in arbitrary and impossible to debug ways. (I think that the cause of something breaking on Linux should lie pretty close to the thing that's breaking and, in the systemd world, everything is uselessly and hopelessly interconnected for no damn reason and so breakage is often in an entire different universe from the symptoms, making it simply impossible for me to think through!)
Sound, camera, desktop, logging in, screen-sharing, streaming all of it – even Flatpak apps (I use Steam via Flatpak) – all work JUST FINE without systemd.
I'm not a "refusenik", I just see absolutely no value that systemd adds and, conversely, I *do* see all the trouble it causes – it's just a negative value proposition with needless complexity and attack footprint, to say nothing of the real problem of consolidation of the Linux operating system and ecosystem towards a single point of control, dependency and risk!
"Ubuntu is the closest thing that the Linux world has to an industry standard"
I don't mind Ubuntu's success but this is just an awful take.
Linux is smack full of industry standards. Let me list some actual standards that most Linux Distros have built in:
1. IPv4/IPv6 are industry IETF RFCs standards
2. TCP, UDP, ICMP are also IETF RFCs standards
3. Ethernet, WIFi and most other networking standards are IEEE standards
4. SELinux is certified under ISO/IEC 15408
5. Then there is ISO/IEC 18974:2021 that is used for Mesa, POCL, OpenCL, ROCm, oneAPI
6. Then there is the Linux Standard Base ISO/IEC 23360:2006
And many many more.
I know that this is a figure of speech, but as Linux and lots of open source software is not only industry standard but also pioneering techs, its really kinda misleading to write something like that.
It’s also slightly ironic to use “Ubuntu” and “industry standard” together considering how much not-invented-here technology has come from Canonical over the years.
Yes most of it has been open source and some of it has even been useful. Good on them. But as far as distros are concerned it’s not like Ubuntu has a particularly strong history of standards compliance.
You can still desnapify a new install of 24.04. Gonna be curious to see if that remains the case in future LTS releases..
snap list
then sudo snap remove --purge [everything in list, gnome-42-2204 and snapd last because others rely on them]
sudo apt-mark hold snapd # prevents it being reinstalled as a dependency, will prevent installs of things only available as snaps
sudo apt autoremove --purge snapd
sudo rm -rf /snap
sudo rm -rf /var/cache/snapd/
sudo rm -rf /var/snap
sudo rm -rf /var/lib/snapd
rm -rf ~/snap
sudo vi /etc/apt/preferences.d/nosnap.pref
and paste in:
Package: snapd
Pin: release a=*
Pin-priority: -10
I possibly ran into something a bit along those lines. I had a low-end Atom ITX system onsite that I wanted to use as a backup DNS/DHCP/NTP and related network services server.
Likely any Linux could do the job, but I hadn't run Ubuntu for a while so I figured I'd give it a go again. This was some time ago, so probably Ubuntu 22.0something, I think.
As you'd expect, install was easy, and post-install was fairly straightforward too since I could adapt a lot of my Debian procedures. Plus this was a small headless server, so no mucking about with desktop config and apps. All good marks there.
After setup, I noticed the machine was always busy, never idle, even before it was really doing any services duty. So I started comparing it vs. the Debian primary counterpart, and first thing that jumped out to me was snap.
After some reading on snap in various forums, and concluding I simply had no need for it, I disabled snap (remove, purge, etc.) and that helped a bit, but looking back I'm not completely sure I got rid of it all. The system still felt laggy, still had persistent load avg even without really doing much, etc. Never really figured out why.
I gave up after a few days and just reinstalled with Debian, same hardware etc., and it behaved fine for a long time until the hw eventually gave out.
Maybe I'll revisit Ubuntu again someday, but my operational needs haven't changed much (ie. still no snap) so there's no very compelling reason. And if I wanted a pretty Linux desktop I'd probably do MX these days.
> So I started comparing it vs. the Debian primary counterpart, and first thing that jumped out to me was snap.
This does not add up to me.
It is over a week since I last installed an Ubuntu Server VM, but as I recall, Ubuntu Server has _zero_ snaps installed by default. None at all.
You said a headless server. You didn't install the desktop version on a headless server, did you?
Even if you do want a GUI on your server, you'd be better off with Xubuntu Core:
https://www.theregister.com/2024/04/30/xubuntu_2404_snapless_ubuntu/
If snap could install self hosted web apps easier than docker : store, centralized user management, desktop integration and auto update, that could be quite something. docker is good but still much more complex to setup a self-hosted app than a desktop app.
flatpak can stay.
I stopped using Ubuntu on the desktop when they rationed access to a browser security update for a couple of days, presumably because the snap store couldn't cope with the demand of everyone getting it at once.
Fuck that.
There is also far too little curation of what's on it. Canonical wanted 'number (of snaps) go up' and didn't much care what they were or if they'd be updated or left carrying the security issues snap was supposed to be a solution for.
I use Fedora. SELinux, not AppArmor, is standard on Fedora and all Red Hat-based systems. Snap is incompatible with SELinux. So, I can't and won't even try to use Snap. I use Flatpaks. I also use BoxBuddy/Distrobox to install packages with dnf and apt in containers. End of story.
In essence, while you can often install and run snapd on an SELinux-enabled system (sometimes requiring the snapd-selinux package), the robust security confinement that snaps are known for is only fully functional with AppArmor, leading to potential issues and degraded security on pure SELinux systems.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
