Ubuntu 22.04.1 LTS Delayed Due To An OEM Install Issue Leading To Broken Snaps

[pWe00Iri3e7Z9lHOX2Qx]

I'm indifferent. I see exactly zero reasons to use either Snap or Flatpak. Unnecessary complexity, increased RAM/disk/CPU usage, dubious benefits, a solution in need of a problem. Docker makes sense, these two? Barely any.

I see both of these and AppImage as solutions to the very real problem of significant time / effort required by volunteer package maintainers. If desktop Linux was just one distro with one release cadence this wouldn't be a big issue. But today you end up needing...

• Someone to maintain a Debian package
• Someone to maintain a Fedora / RHEL package
• Someone to maintain an Arch package
• Someone to maintain a a SUSE package because they've broken up dependencies differently than the Fedora / RHEL package did
• Someone to maintain a Solus package
• [...]

Mix in all the LTS releases which have vastly different versions of library dependencies available, and the whole thing is a mess and huge time suck.

It would be nice to have every package available on any version of any distro. They aren't panaceas of course. For Flatpak, I'd love to see...

• Clear indication when the flatpak publisher is / isn't the upstream maintainer
• Better inform the user of the permissions and let them adjust if needed
• Continued work on how well they can interact with the rest of the system via portals etc.
• [...]

[lyamc]

I've become somewhat disenchanted with flatpaks, snaps, appimage and what-not.

I don't know if anyone has tried Fedora SilverBlue, but I give you a week before you give up on it. The OSTree model sounds really cool, but maybe it's only good in small quantities (in addition to another package manager). I found that trying to install flatpaks from flathub through the software center would fail and then crash software center. I couldn't open it in a terminal to see what was happening under the hood either.

I like that snaps were designed to work better for more embedded systems and servers. I don't like that the initial mount of the snaps means that the initial start takes a while which seems like a problem that just won't be solved.

I like that appimages allow the developer to optimize the build to outperform the deb/rpm/pacman build.

I just switched to using pacman and really like the speed, but it's up to the user to configure some sort of aur GUI or CLI tool which is a bit of a pain.

----

There needs to be a decent way to take the current sandboxing of flatpaks and snaps with allow permissions for some things. One particular text editor I like has a built-in terminal and with the flatpak version, I didn't have any of my commands within the shell (gcc, g++) which is annoying. Until stuff like that is fixed, I'll stick with the rpm/deb/pacman.

[hamishmb]

I see both of these and AppImage as solutions to the very real problem of significant time / effort required by volunteer package maintainers. If desktop Linux was just one distro with one release cadence this wouldn't be a big issue. But today you end up needing...

• Someone to maintain a Debian package
• Someone to maintain a Fedora / RHEL package
• Someone to maintain an Arch package
• Someone to maintain a a SUSE package because they've broken up dependencies differently than the Fedora / RHEL package did
• Someone to maintain a Solus package
• [...]

Mix in all the LTS releases which have vastly different versions of library dependencies available, and the whole thing is a mess and huge time suck.

It would be nice to have every package available on any version of any distro. They aren't panaceas of course. For Flatpak, I'd love to see...

• Clear indication when the flatpak publisher is / isn't the upstream maintainer
• Better inform the user of the permissions and let them adjust if needed
• Continued work on how well they can interact with the rest of the system via portals etc.
• [...]

I agree with this and the previous comment - Flatpak isn't perfect, but as an app developer, and someone who wants newer versions of specific programs, it does the job well.

I also have similar disdain for Snap.

[birdie]

Wall of text

Sorry, haven't read. The problem is that Linux as a software platform doesn't exist (each distro is basically a completely different operating system which is bloody ridiculous) and LSB was buried a long time ago. Maybe Linux distros could instead approach the underlying issue instead.

[onlyLinuxLuvUBack]

I don't understand this issue, ubuntu has installer DLC update, why don't they just make a DLC ? ship it and fix it in a DLC that would be shiny and new for 22 ?

[tunnelblick]

I'm looking forward to observe snap haters here

Ah, the good old "haters" argument to shut down any legit criticism.

[AmericanLocomotive]

I'm sorry, but anyone who says things like Flatpak or Snap aren't necessary on Linux haven't actually talked to a "normal" person who uses a computer. Linux (as in, all distros) is a complete disaster on the software front for "normal" people.

People just want to be able to install things and have it work. Just like Windows, just like OSX. They want to download the thing, click it, and have it work. They just want to be able to have the "app store" automatically install the latest updates as the developers publish them, or the program have the ability to update itself as necessary.

They don't want to wait around for a distribution's package maintainer to get around to putting the latest version of their favorite application in the repositories. They don't want to have to mess around with endless dependency nightmares trying to manually install a program because their distribution doesn't have it in the repositories for some reason. ...and they sure as hell don't want to start messing around in the command line to install, update, or maintain anything.

As others mentioned, utterly absurd amounts of man-hours are wasted by these package maintainers duplicating the exact same work the guys next door are doing. Every time Firefox publishes an update, dozens of different teams need to compile it, package it up, and push it to their repositories. Then rinse and repeat for every piece of open source software that gets published. The classic Linux independent software repositories and package management made sense at one point. In 2022? It's idiotic. Give me a single file that contains and does everything necessary to make the application run.

Honestly, the amount of time wasted on different Linux distributions is mind-boggling as well. The "mainstream" distributions are all so similar in look/feel/use/configuration. Like seriously, the only major differentiating factors are their package managers, repositories and default desktop environment. I have two Linux systems: Desktop running Suse Tumbleweed and a Steamdeck with SteamOS 3.3 - both running the "stock" configuration with KDE. They look, feel, and operate essentially identically. There is no reason for these two "different" OSes to exist.

Linux users over here wondering why Linux isn't more popular as they're arguing about things like installers, init systems and the best command-line package managers. Then you have Apple OS and Windows over in the civilized world going "...what's a command line?"

There's a reason why the Steamdeck ships with Flatpak installed by default and flathub as the only software repository (outside of Steam). Valve seems to understand that if Linux wants to succeed in the desktop space, it just needs to "work".

[pWe00Iri3e7Z9lHOX2Qx]

I've become somewhat disenchanted with flatpaks, snaps, appimage and what-not.
I don't know if anyone has tried Fedora SilverBlue, but I give you a week before you give up on it. The OSTree model sounds really cool, but maybe it's only good in small quantities (in addition to another package manager). I found that trying to install flatpaks from flathub through the software center would fail and then crash software center. I couldn't open it in a terminal to see what was happening under the hood either.

For Silverblue (or any immutable offering like Kinoite or MicroOS), I think your better path forward is utilizing Distrobox. It's like Fedora's Toolbox but better, and without the dickhead leave my brain at home responses to very basic user needs.

https://github.com/89luca89/distrobox

You'd basically setup a Fedora 36 container with all your stuff in it, whether that was CLI or GUI. You can set a shell profile to default into the container as well. It's easy to export the .desktop launchers for the GUI stuff back out to the host.

[hamishmb]

Note that LSB itself stopped being worked on, but I did read something about more and more distros being interested at least in API and ABI compatibility, so maybe the spirit of LSB is still alive.

Sadly, I can't remember where that was.

[mdedetrich]

After reading through the bug it required a string of conditions to trigger it (system configured to start a snap on login, snap not properly configured to start correctly on OEM setup, snaps being downloaded and updated during the OEM setup phase). I would not say that this specific issue is an issue inherent snap/snapd. Just a weird bug that happened to involve it. Those can happen with any system.

It may or may not be a QA issue that it was detected this late (though again, string of specific conditions).

Disclaimer: I'm no snap lover. I use Arch Linux. I think Flatpak is superior to snap for desktop usage (lower start up times due to better architecture). Flatpak is also flawed (no questions popping up asking about using permissions, instead configured silently in the background on install). Sandboxing makes sense for some programs, but not others (I tried PyCharm in a flatpak. It failed to start the embedded terminal since I use zsh, which is not in the flatpak image. It did not fall back properly on bash, and even if it had that would have been a terrible user experience. Do not use editors and IDEs sandboxed!).

Yeah I use Intellij (same IDE as Pycharm just configured for Java/JVM langauges) and have the exact same issue, flatpak doesn't really work well when it comes to IDE's.