Ubuntu 23.10’s New Software App Will Demote Debs (Apparently)
omgubuntu.co.uk
omgubuntu.co.uk
Ubuntu has tried bold moves - like trying to replace Xorg with Mir. That failed because Mir was raw. But this one might just. Making deb packages second class citizens in a Debian derived OS is so unfortunate.
on the desktop side, I really just need a browser and a vim editor for 99% of what I do, Debian should be perfectly fine too.
As for proprietary drivers, the non-free repos have traditionally carried everything I need.
- "Please note that security updates for 'testing' distribution are not yet managed by the security team. Hence, 'testing' does not get security updates in a timely manner."[1]
- "Compared to stable and unstable, next-stable testing has the worst security update speed. Don't prefer testing if security is a concern."[2]
- "[Testing's] security updates are irregular and unreliable."[3]
Most Debian users should use Stable. If a user wants a newer version of some software, they should write a Bash script to install it from source. When I used Debian Stable on the desktop, my installers allowed me to have the latest versions of all of the software of which I wanted the latest versions.
If a Debian user wants up-to-date software but they don't want to write their own installers, they should consider using Fedora instead.
[1] https://www.debian.org/releases/testing/
Frankly, this kind of purist ideology--to the point of suggesting people use a different distribution--is simply ridiculous.
For servers I'm running on the open internet, yes, you are absolutely right. But in that case I just run stable.
The choices aren't some purist notion of "secure" versus "not secure".
Security is a spectrum of practical choices informed by threat models, and it's only one (certainly important!) aspect of the complex choice of selecting an operating system.
For example, I would absolutely advise my mother in law to write complex passwords on sticky notes. She's far more likely to fall victim to credential stuffing than to have her apartment broken into and her passwords stolen, and I accept that trying to get her to use a password manager would certainly fail and she'd just fall back on reusing simple passwords.
A security purist who thinks in terms of "secure" or "not secure" would scoff that this. Writing down passwords! That cannot be done!
But given the threat model and an acceptance of expected user behavior, it's a perfectly valid choice.
If I'm running a Linux desktop, I've already made a more secure choice by getting out of the firing line of typical untargeted malware.
With some additional basic security hygiene, the greatest threats are a) phishing/social engineering, for which zero days aren't the primary concern, or b) targeted attacks where clearly they are.
As I'm not a target of interest, I'm not too terribly worried about the latter. As for the former, distro choice doesn't make much of a difference.
So yeah, given that threat model, I'm comfortable waiting the few days it takes for security fixes to trickle down from sid to testing. And if I really cared, I'd follow the guidance mentioned in one of the links you posted, and just pull patches down from sid on an as-needed basis.
Switching to a completely different distro, by contrast, would be a ridiculous overreaction give the context and associated trade-offs.
The real power of Ubuntu has really always been as a server distro. I used to run desktop Ubuntu when I was younger and had more spare time to tinker with this nonsense, but nowadays I administer enough ubuntu servers at work, I don't need to do it at home too. Ubuntu server is great -- everything is very well-documented, LTS is stable, snaps are sometimes pretty useful (I recently had to quickly spin up redis temporarily for a project and it was a one-liner), and everything just works in general.
I used to run CentOS (rip) servers, and Ubuntu, whilst noticeably worse, is still great to administer. It's not all sunshine and rainbows for sure, but things generally work the way you expect them to and things are generally sane.
It's theoretically possible to use it in prod; I know that some companies (Netflix?) do it. But it's certainly not common and takes a lot of engineering resources to make it work.
Any competent Linux sysadmin could learn to admin a BSD in no time. The FreeBSD handbook and the man pages are excellent. In my opinion they are far better quality than their Linux equivalents.
You also won't have any issues if your server runs on an open source stack such as Python, PHP, Perl, Ruby, Java (OpenJDK), NodeJS, etc.
You're absolutely right about FreeBSD not having first party commercial support. If you need that, you're basically stuck with RHEL, SUSE, Ubuntu, or Oracle.
Many of the things I did as a traditional university sysadmin long ago probably works on FreeBSD, and if you wanted to deploy a LAMP (FAMP?)/Django/Ruby on Rails/etc stack it would probably be good enough, but the world has moved on since then. Once you want k8s, ansible, distributed filesystems, HPC, scientific, etc. it starts to break down really quickly. Many of the things I listed above may work, but it's the less documented, less supported, more annoying, and more likely to break path. The extra time spent getting it to work on FreeBSD and maintaining it is not time well spent unless there's a very specific reason FreeBSD is better, just grab RHEL/SLES/Ubuntu and skip all the hassle.
FreeBSD has its place in very limited scenarios and where you have the engineering resources to deploy it, but it should not be the default choice for a production deployment.
I don't know if I'm just lucky, but my last 4 HP computers (3 laptops and a desktop) have all worked perfectly on Linux since day 1, whereas Windows has been a complete shitshow, having to wait as long as 1 year for some peripherals to be supported. In one case, I didn't care, since it was the webcam, which I never use. In the other, it was a PITA since it was something graphics-driver related, and I couldn't reliably use an external 4k screen without doing a plug-unplug-replug-just-right circus. Sleep is hit-and-miss, with one laptop being almost guaranteed to wake up and crash at night while left asleep. The desktop PC still has unreliable thunderbolt support.
Then there's the UI that lags like no tomorrow, the windows jumping around when switching virtual desktops, new browser windows never showing up where you expect them, windows seemingly in the foreground not getting input, inconsistent input field behavior, etc. Oh, and half the dialogs are still from the windows 95 era, so it's not even "prettier" or more "cohesive" than my i3 / gnome frankendesktop. Also, the start menu search, aside from being slow, has a good probability of not finding the app I'm looking for.
But, the 10,000 ft view is that they reduce the amount of control I have over my system. They offer restrictions I chafe at while giving me no benefit that I care about.
I'm not going to sit here and say they shouldn't exist. That they're not to my taste doesn't mean that others who like them shouldn't have them. But they're not to my taste at all.
After seeing systemd getting widely adopted (also not to my taste), if snaps (or flatpacks, although I am less allergic to those) join the party then that's just a clear indication that the Linux world and I have diverged too much and I need to move on.
I moved to Qubes OS and like it.
But this bloatification is happening all over the place. Firefox is starting to have more and more dependency on flatpak’s daemons, even if you don’t use flatpak. These daemons are becoming the de facto standard for some interfaces too sadly. This also means that a lot of software is a lot less portable.
I'm saddened to hear that FF has dependencies on flatpack daemons, but I'm not surprised by it. The direction Linux is going seems very clear to me, and I expect more of that sort of thing as time goes on.
However, it depends on the implementation and Snap just sucks.
(Note that the default Unix assumption is that no users can be trusted but all applications can be trusted, which is wrong imho. Containers provide a way out of this, but things get messy very fast.).
Your other data, in other sandboxes, is protected though.
It is, but I also actively don't want every package to run in its own container. I'd rather containerize select applications that I choose.
Snaps allow you to hold updates indefinitely now: no forced updates any more. Use "snap refresh --hold <some snap name>". See https://snapcraft.io/docs/keeping-snaps-up-to-date#heading--....
- you're a hardcore oriented distro, you assume most things will be built from source, follow all of your dependencies and maintain the glue for your distro. Gentoo/Slackware style。
- you value convenience and go the snaps/flatpack route.
And you can still go the convenience path while building some specific apps from source, but there will be a bigger gap to bridge and it won't make sense formost applications.
I get the shift, as we're already seeing it, even outside the cloud, I think it's still the best of both worlds. I compare that to how I'm running a natively compiled postgres version but a containerized mysql because it was too much of a pain to match all the dependencies.
Reminds me of the early days of the tensorflow where everyone used whatever binary package worked an no one could run anyone else's code because people kept getting stale binaries somewhere in the stack.
For open source software, snap is the same software, but slower, more broken and with worse upgrades.
Snap's changed the firefox update process so I now have to run 'sudo snap refresh' and wait for a download, where before I just closed and reopened it. Maybe it'll make my running application's dock icon disappear, hope you always use alt+tab instead of the dock. Snap can install ffmpeg - but I can't feed a screen recording to vaapi for compression because whoever set up the sandboxing forgot to allow that. Good luck sharing anything from, say, ~/.config/ on, say, discord - you get a silent unexplained failure, because hidden folder access is blocked by the sandbox. Installing a browser? With snap you get three copies; you can adjust refresh.retain down to only keep 2 copies - but 1 copy is out of the question.
There's a reason canonical has to force snap down people's throats, and it's because nobody uses it by choice.
And btw SteamOS is absolutely not a sandboxed environment. It just has a read-only OS filesystem so they can safely blow it away upon upgrade.
The obvious answer is: vendor lock in. Once Ubuntu is snap-only you won’t be able to host your own package repositories, since it’s their secret code.
Uploading public applications is free. Uploading proprietary software is a business model.
It also pretty much locks Ubuntu users in, because no other project uses snaps, so if an app chooses snap for their distribution method (certbot, for example) it suddenly becomes a lot easier to just download Ubuntu than it is to install Snap for a foreign platform.
That's an exaggeration. It's about as easy to install snap support for a non-Ubuntu as it is to install any other third party app on that platform. And the latter case is exactly what you're trying to achieve by trying to install a third party app on that platform in the first place, so by definition it can't be significantly harder than any alternative method.
Not me, for programs that are not from the repos I do not like debs.
I needed to install dubious apps like Skype,Slack, Some Pdf Editor etc. With deb I would give them root , so I either find an app image or snap, or try to unpack the deb file and attempt to run the binaries without root.
I also installed one a server some CLI snaps, they did their job and I did not had to build them from source.
I agree from things that are in the repo I prefer the debs 99% of the time.
The main problem that Snaps solve is this latter case: when third parties are trying to ship directly into someone's distribution installation[1].
Often third party debs appear to work OK, but then break future distribution upgrades. By then users have forgotten about the third party software that has hacked itself into their system, and blame the distribution for their upgrade failure. The problem is that distribution debs are designed to provide metadata about what has changed so that the package manager can accommodate. But it's not possible for distribution debs to be aware of the third party debs to handle those changes. So things break.
The breakages caused by debs aren't just limited to future distribution upgrades. A bad third party deb package can break your entire system. We routinely get reports where it turns out that this is what happened to our users!
There's also the problem of dependencies. If a third party app needs a bunch of dependencies, then they can't realistically bump those dependencies on the system as a whole without regressing all the other apps that need older versions of that dependency. So they have to bundle their dependencies, and this is something else that regular deb tooling doesn't handle well. You can theoretically construct a deb that bundles all its dependencies, but then that's exactly what snaps and snap tooling handles better - that's half the point. Nix only partially solves the problem by better supporting concurrent installation of multiple versions of those dependencies. But those concurrent versions would still each have to be maintained; that's something that distributions try to avoid by picking one version of each dependency and making the entire distribution release work with just that one. Moving that maintenance responsibility to each third party app developer, and having the packages bundle their dependencies, is the other solution. This was already happening with deb packages like for Firefox. Firefox upstream bundles nearly everything, and the debs (eg. in Debian) do the same for most of their dependencies. Snaps just call a spade a spade and are designed around it.
You also wouldn't really expect a third party app to have access to everything on your system. Say for example you download and install some game app to try out. Do you really want it to have access to your online banking browser session? The game developer might not secure their development infrastructure as if someone's trying to steal their users' money, because that's expensive and they're only shipping a game. But if you install their game, then that's what you risk. That game developer's infrastructure is suddenly an attack vector for an adversary that wants to get to your online banking session. On iOS and Android, each app only has system-mediated access to everything outside its sandbox. Debs fundamentally cannot provide this separation, so if you install third party debs then you're giving all those third parties access to everything, which really is unacceptable in modern security practice. Snaps give you that sandboxing.
So that's what snaps are for: 1) bundling dependencies, because that's necessary in world of third party software that ships independently of the distribution; and 2) sandboxing, because that's necessary in a world of third party software if you don't want to give all those third parties and their adversaries root on your system.
If you don't want third party apps, and only want what your distribution ships in a curated manner, then you don't really need snaps. But consider that Firefox is essentially a third party, non-curated app, regardless of your distribution or how it was packaged! See [1] below.
Snaps are also immutable, which really helps with stability and upgrade and revert cases. This is more relevant for snap-only systems like in IoT, not the Ubuntu desktop. In an IoT deployment you can't tell the user to run "apt-get -f install" to fix up the system because power got interrupted during an upgrade - because that's how debs work.
In years gone by, Ubuntu tried really hard to make third party debs work. But it didn't work for various reasons. In the meantime, it became the norm for third parties to ship debs together with all of their problems, since there was nothing better possible at the time. This is what snaps solve.
Disclosure: I work for Canonical. But here I am speaking for myself, not my employer. I'm not involved in the design of snaps, but as a distribution developer, it's clear to me what problems they solve.
[1] Packages like Firefox also use snaps because even as a deb it's really not the case that Firefox is curated by the distribution and mostly unchanged after release any more. So it suffers from mostly all the same problems that third party debs do.
How so? Every dependency of every dependency is in the nix store and they’re all immutable. A nix package installed will work forever because its environment can’t change. Am I not right?
Bugs and security issues are found from time to time. When that happens, every occurrence in use needs an update. If ten different incompatible versions of a package are in use, they all need to be replaced. That's more work than one per traditional distribution release.
(What I'm getting at is: why does it make sense for Canonical to define its own sandboxed application format when another one already exists?)
Snaps solve a bunch of problems that are out of scope of Flatpaks, such as CLI apps and the packaging of kernels and other hardware-level pieces. This allows for an entirely snap-based system that is immutable and atomically updated, which is essential for IoT devices to be reliable.
If you look at the history of snaps, they are an evolution of click packaging, which were created for the Ubuntu phone that is no more. But the history goes back further than that - back to Ubuntu's App Review Board and (deb based) third party app packaging system, which failed for exactly the reason that deb is an unsuitable packaging format for third party apps.
If you look at the history of Flatpaks, you'll find that their initial release was at a similar time to snaps. But given that they don't solve a bunch of problems that snaps do, what was/is Canonical supposed to do? Ditch snaps entirely and drop their IoT support? Integrate IoT support into Flatpaks? Do Flatpak upstream even want that? Look at the history of Canonical wanting to ehnance GNOME, and the history of how Unity began, to see how that doesn't seem like it would be a practical way of delivering functionality to users in a reasonable period of time.
Consider that it is Ubuntu that is at the centre of this third party app packaging problem. It's Ubuntu that everybody targets first with their third party debs. For the same underlying reason, it's Ubuntu that gets more user support requests because of bad third party debs than every other distribution. It makes sense that Ubuntu developers are best placed to understand the problem and develop a solution.
So yes, we've ended up with two parallel contenders. But I don't think it's reasonable for Canonical to have done anything differently in regard to Flatpak. It appeared at the same time while Canonical had already been working away at the problem for years, doesn't solve or even try to solve all the problems that snaps are designed to solve, and those problems appear to be out of the scope of Flatpak anyway. As much as critics frame them as like-for-like options that Canonical could just decide to switch over, they simply aren't and thus "simply switching" doesn't even make sense.
As for "another one already exists", that statement could just as well apply the other way round: look at the timelines!
Care to elaborate?
But their adoption of systemd is something that makes me worried for the future. It's still avoidable for now, but the writing is on the wall.
I used ubuntu for years, but finally gave up on it when they started pushing snaps hard. I'm on PopOS now now but I'll go to mint debian edition or something else if I have to.
I compromise and install most of the software I use on a daily basis from Homebrew. So I have some crufty version of `ls`, but the latest version of Emacs.
https://iso.pop-os.org/22.04/amd64/nvidia/31/pop-os_22.04_am...
Works great on my machine with a RTX 2060.
"If you have NVIDIA graphics, download the ISO with the proprietary NVIDIA driver preinstalled."
There is also a non-Nvidia ISO:
https://iso.pop-os.org/22.04/amd64/intel/31/pop-os_22.04_amd...
As well as Raspberry Pi:
https://iso.pop-os.org/22.04/arm64/raspi/4/pop-os_22.04_arm6...
Before this, I used arch, until a simple update rendered my system unbootable. When I asked an arch dev why they were shipping a master branch grub build, I was told that if I couldn't easily recover a corrupted grub install I should consider another distro. I installed pop the next day. I've been very happy with it from that point forward. If I had to use something else it'd probably be mint.
in theory I like that snaps have a permission model w/ default confinement, in practice I keep getting asked to install in 'classic' mode
I was using Ubuntu Server everywhere, I stopped using it the moment they started forcing snaps. Snaps are inferior technology, I don't want to install a daemon just to install software on my server, I don't want an unpredictable auto upgrade technology and I don't want millions of mount points.
DEB and RPM have been around since forever, I can deploy software using those technologies and expect it to work in 10 years, the same cannot be said for Snaps, there is nothing there to guaranty that it won't just end up like: Upstart, Mir and Unity.
I can ship my software as a Docker container and have it work everywhere or I can put in a lot of work to ship a snap and have it only really work on Ubuntu, I don't even know what was Canonical thinking here. I don't care that I can install snapd on most distros, if it's not actively supported by the distro it does not count.
I use ubuntu on personal and servers and fedora for work,so picture me concerned.
I need a better distro for sure, because ubuntu lands with unattended upgrades enabled, which causes the server setup from my scripts to be unpredictable (sometimes is doing updates when booted the first time, but not always. Sometimes is also very fast). Recommendations for server distros that require minimal setup? I have only small applications running
Then, I was already thinking of moving to fedora on personal too, with KDE, but I am now concerned.
Any recommendations for personal desktop usage? I'd like low maintenance distros, so I'm not interested in massively recompiling things. And I have nvidia, which is why I chose ubuntu with kde and fedora where I would like to switch to kde. Gnome plugin policy is so bad that I don't upgrade fedora because of them
I think I'll try Linux Mint out. Or maybe it's time to go back to my beloved Debian, which I abandoned because of Ubuntu when Ubuntu was still not too filled with crap.
I really don't want to worry about this stuff on Ubuntu Server. Has anyone else moved to Debian?
Edit: I'm talking about this https://news.itsfoss.com/ubuntu-ditch-snap/
Oh JEEZ it was april fools. It seemed so reasonable. I thought they were coming to their senses.