I would guess that they’ll be sourcing a next-gen RISC-V processor ASAP, since those will enable virtualisation. If they stick one in a laptop shell I’d probably buy it pretty quickly. Doubly so if it has EFI.

I’m sure I’ll get shouted down for this suggestion by the haters, but I’m going to make it anyway because it’s actually really good:

Use an Ubuntu LTS flavour like Kubuntu. Then, add flatpak and for apps you want to keep up to date, install either the flatpak or the snap, depending on the particular app. In my personal experience, sometimes the flatpak is better and sometimes the snap is better. (I would add Nix to the mix, but I wouldn’t call it particularly easy for beginners.)

This gets you:

1. A reliable Debian-like base that you only have to upgrade to new releases every 2 years
2. Up-to-date apps, including confinement for those apps
3. New kernels every 6 months (if you choose - you don’t have to, though)

If there were an occasional thing where I looked at it and thought “wait, is this Loss?” that would be funny. But I see them way too frequently for them to be funny. They need to be subtle and occasional, taking one off guard. Instead they’re frequent and unsubtle.

Lol imagine a canonical employee using nixos

Unfortunately not

I also wanted to do this when my cat sent by Steam Deck flying across the room and cracked the screen

And they’re providing Ubuntu for free. If you were a paying customer and the contract you’d signed with them said they’d provide Firefox as a deb, that would be a different situation.

I agree, but unfortunately our opinions don’t move a gazillion finance bros

over the course of a few updates, they replaced half of your programs with snaps (without telling you),

You don’t need to lie. A full list of debs that have been transitioned to snaps is:

• Firefox
• Thunderbird
• Chromium

as you can see on other comments I’m not alone with that stance.

Being in the majority doesn’t necessarily make one right, as shown by [insert election result you disagree with here]. But if you actually are serious about that, you do realise how entitled it sounds to demand that someone do free work for you in the particular way you want it done?

And I believe you mean prerogative.

Because the separate installation means you can actually end up with both an apt installed and a snap installed.

This is something that can happen any time you have multiple package managers or even multiple repositories in the same package manager. Google’s official Chrome apt repo has debs for google-chrome-stable, google-chrome-beta and google-chrome-unstable, quite intentionally.

My comment about docker was a specific example of such a case, where vulnerabilities were introduced. It was actually a commonly used attack a few years ago to burn up other CPU and GPU to generate crypto

Can you provide a link to a source about that? I can’t find anything about it.

and you ended up with both a snap and apt installed docker

If you installed both the docker.io package from apt and the docker snap, yes you wound up with both. Just as if you install both google-chrome-stable and chromium you’ll end up with two packages of (almost) the same browser.

The fact that they are both packaged by Canonical is both irrelevant and a perfect example of the problem.

Then I’m gonna ask that you elaborate what specific problem you’re trying to explain here, because these seem pretty contradictory.

Yes, you are literally forcing me to accept your dollarinos, which, unless I exchange them MYSELF, are USELESS!

Hold on, have I fallen for Poe’s law?

In both cases, the packages are owned by the same people? (Fun fact: mozilla actually owns both the Firefox snap and the firefox package in the Ubuntu repos.) I’m non sure how that “potentially introduces vulnerabilities” any more than “having a package which has dependencies” does.

I’m not sure what you’re referring to with Docker. Canonical provides both the docker.io package in apt and the docker snap. Personally I use the snap on my machine because I need to be able to easily switch versions for my development work.

If you don’t want to explain, you’re perfectly welcome to not explain. But saying what amounts to “if you don’t know I’m not telling you”, especially when you weren’t specifically asked, is a pretty unkind addition to the conversation.

If I were giving you €50/month, and then one day I decided to give you USD$55 instead, am I “forcing” you to accept US currency? No, I’m choosing to give you something I don’t have to give you in the first place in a different form. You can always reject my offer. You can ask someone else to give you €50/month.

They’re choosing how they want to provide Firefox. If anyone else wants to provide Firefox differently, Canonical isn’t stopping them. In fact, Canonical literally hosts and does the builds for an unofficial Firefox repo with their free Launchpad service.

Distributions decide what they want to package and how to package it all the time. Pretty much every time, someone is upset. But that upset is generally based on an unreasonable sense of entitlement.

I don’t believe Flatpak has the ability to package something like node. It certainly can’t package kernels or system services (at least not without leaving the user with a ton of manual work to do that would make it not much better than getting a tarball).

sure, and convince people to switch. it’s been done before of course but it’s a big effort

I agree! But this, IMO, is a better argument for how flathub.org being (theoretically) open source doesn’t actually make it any better than snapcraft.io. The technical hurdle, either of writing another snap store or of setting up a flatpak host, pales in comparison to the social hurdle of getting people to switch. Which is likely why the previous open snap store implementation died. Nobody wanted to host their own and convince people to switch, because at the end of the day there wasn’t any benefit.

that does not mean that the particular developer agrees with or even approves of the snap thing.

Never said it did, although in the particular case of the developer I mentioned, he’s also an Ubuntu Core developer, which depends entirely on snaps. I can’t imagine he’d have put himself in that position if he were particularly anti-snap

steam was a big one that a friend had trouble with, and they just installed that though apt i’m pretty sure.

Ubuntu has never had a steam package in their apt repos, and the steam-installer package still behaves the same way as ever. Personally, I do use the Steam snap and haven’t had any issues with it, though I do know that others have.

Uhm… and why does the user have to transition to snaps?

They don’t. But Canonical will no longer be providing debs in primary Ubuntu repositories, so those transitional packages exist so that users don’t wind up with an abandoned, old version of Firefox.

Why does Canonical provide those transitional packages while there are perfectly valid debs for the same thing?

For the same reason neither Ubuntu nor Debian provide debs for Google Chrome, despite Google having an official apt repository? Those debs exist in somebody else’s apt repository. If you want to add that apt repository, you’re welcome to. But those external packages aren’t part of the system they provide.

you instantly refute yourself, kudos!

Your unwillingness to accept what I’m saying doesn’t make what I’m saying contradictory.

Canonical provides transitional packages for packages that they’ve decided to provide as snaps. They’re not forcing anyone to use snaps, they’re saying “if you want the default we provide you, we’re providing you with a snap.” KDE Neon (my current distro, which is downstream of Ubuntu) has decided that they want to use the deb packages from packages.mozilla.org, so they provide an override. If you want to use the deb from packages.mozilla.org, you could grab KDE Neon’s repository deb and install that, or just set up the mozilla repository and use the same pin file they already have.

This is like saying “Debian FORCES you to use libav” Debian moved from ffmpeg to libav for a while. No, they provided libav and made transitional packages for this drop-in replacement. Some people didn’t like that and made their own ffmpeg repos, and the process for using their separate ffmpeg rather than Debian’s transitional packages was the same as the process for using Firefox from a different repository. (I was one of the people used some third-party ffmpeg repositories, and I was glad when they switched back to ffmpeg and provided libav to ffmpeg transitional packages.)

Does the fact that the Ubuntu repositories don’t contain Keysmith mean “Ubuntu PROHIBITS you from using Keysmith?”

Because people who just want their daily Two Minutes’ Hate rather than actually having nuanced takes.

While Canonical’s particular snap store implementation is closed source, all of the client software as well as the store API are open, and snap isn’t even tied to using snaps from their store. One could easily make a client app that treats snapd much the way apt treats dpkg. (In fact given apt-rpm I think it would probably be feasible to quite literally use apt for that.)

KDE seems to upload their packages to the snap store for Neon, judging from their page.

KDE also maintains most of the flathub.org packages for KDE apps. Not sure what the point is here.

canonical are not the ones doing the maintenance for those apt packages. the debian team does that.

This is wrong in two ways. First, Canonical are the primary employers of a lot of Debian developers, including to do Debian maintenance or development. This includes at least one of the primary developers of apt. Canonical also upstreams a lot of their work to Debian. Second, of the three (!) whole packages that Canonical decided to make transitional packages to the snap, none were coming from upstream Debian. Firefox was being packaged by Mozilla (and Mozilla were the ones who decided to move it to the snap), Thunderbird’s package had been something Canonical was packaging themselves due to the Debian/Mozilla trademark dispute that they never moved back to syncing from Debian due to technical issues with the port, and Chromium was, at least at the time, remaining frozen at old versions in a way that was unacceptable to Ubuntu users.