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

[ssokolow]

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.

The primary point that was made is that, like systemd and PulseAudio, Flatpak is "You've had 20 years. We're tired of you telling us to wait until you get it right. We're not waiting any longer. We're making our own solution that actually solves the problems we care about that you seem not to."

[ssokolow]

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'm on Kubuntu 20.04 LTS with the Flatpak PPA to upgrade the Flatpak components and Flatpak has worked perfectly for me, aside from a couple of minor warts caused by the KDE backend to the portal host not being covered by the PPA's upgrades, so I'd say that's more on Silverblue than Flatpak.

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

My issue with Appimages is that they're basically GOG.com's "bundle the dependencies and a start.sh", but making it harder to delete that library which shouldn't have been bundled and is guaranteed to cause at least one of my games to start segfaulting with each distro update.

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.

Part of the problem is that Flatpaks are closer to running the program in a chroot and then bind-mounting the stuff you grant into it. Currently, you can't grant Flatpak applications access to your /usr because the Flatpak runtime image is mounted over top of it.

[onlyLinuxLuvUBack]

I'm on Kubuntu 20.04 LTS with the Flatpak PPA to upgrade the Flatpak components and Flatpak has worked perfectly for me, aside from a couple of minor warts caused by the KDE backend to the portal host not being covered by the PPA's upgrades, so I'd say that's more on Silverblue than Flatpak.



My issue with Appimages is that they're basically GOG.com's "bundle the dependencies and a start.sh", but making it harder to delete that library which shouldn't have been bundled and is guaranteed to cause at least one of my games to start segfaulting with each distro update.



Part of the problem is that Flatpaks are closer to running the program in a chroot and then bind-mounting the stuff you grant into it. Currently, you can't grant Flatpak applications access to your /usr because the Flatpak runtime image is mounted over top of it.

[your desktop of choice] with distrobox running ubuntu running the flatpak ?

[Paradigm Shifter]

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.

Sucks for Octave, too, if you want to use any additional packages. After wasting a day getting the Octave flatpak to actually acknowledge that I had installed packages like signal and image, I then needed a few GNU maths libraries for ltfat to compile, but it wouldn't see system libraries at all. After some rigmarole, I did manage to get it working, but everything broke the next time the flatpak updated the major version and I simply couldn't be bothered with the hassle.

Considering how many complex dependencies Octave has, it is rather damning that it was/is easier to compile it from source than to get Octave packages to work in the flatpak.

I've no idea what the state of the Octave flatpak currently is, because now I just compile it myself. Yeah, sure, not something for a non-technical user, but then I would argue that a non-technical user probably won't be wanting to use Octave; if they need to use such a thing at all, they'll be using MATLAB.

...

As for snaps... well, I recently decided to try Ubuntu 22.04 on my RPi4. Less said about that the better.

[ssokolow]

Sucks for Octave, too, if you want to use any additional packages. After wasting a day getting the Octave flatpak to actually acknowledge that I had installed packages like signal and image, I then needed a few GNU maths libraries for ltfat to compile, but it wouldn't see system libraries at all. After some rigmarole, I did manage to get it working, but everything broke the next time the flatpak updated the major version and I simply couldn't be bothered with the hassle.

Considering how many complex dependencies Octave has, it is rather damning that it was/is easier to compile it from source than to get Octave packages to work in the flatpak.

I've no idea what the state of the Octave flatpak currently is, because now I just compile it myself. Yeah, sure, not something for a non-technical user, but then I would argue that a non-technical user probably won't be wanting to use Octave; if they need to use such a thing at all, they'll be using MATLAB.

To be fair, the approach they're taking with Flatpak is "Easier to start out only viable for certain packages and then incrementally broaden our scope of utility than to start out like X11 and try to push apps like Chrome to retrofit support for the SECURITY extension."

Currently, one of the things they're working on is hammering out an extension to allow packages to declare that they contain browsers or WebExtensions native messaging clients that need to be made visible to each other. so it's feasible to distribute things like KeePassXC or download managers via Flatpak and have their browser integrations Just Work.

[domih]

Ubuntu 22.04.1 LTS with kernel 5.19.0-051900-generic running on a TR 2950X here.

I don't have a particular opinion about snap. HOWEVER, moving Firefox from apt to snap breaks the integration with ExpressVPN :-(

I worked around the issue by moving to the apt version Firefox. ExpressVPN integrates again. Case closed.

Note: there are already plenty of HOWTO on the web explaining how to remove the snap Firefox and install the "real/pure" apt Firefox instead on 22.04 LTS.

CONCLUSION: Don't you love it when something "new" breaks something that was working perfectly? Plus the time to fix it.

[stormcrow]

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".

Gonna call utter BS on this. "Normal" people don't use desktop Linux as a rule (save a bare few who were introduced by a techy friend or family member). They use Windows. They install a program, and unless that program has an auto-update function they never update it again until they buy a new computer or replace a storage device. How do I know? Cuz I have supported more than enough Average Joes that don't even know updates are a thing on desktops, and they really hate it when they have to update anything including their phones. That's the vast majority of computer users by far which makes them the norm.

As such, they'd be perfectly fine with the basic LTS install, if they could actually use it, because they literally wouldn't have to think about dealing with any of it. Their program would only get a security fix, or the rare serious bug fix and that's it. It's UI would never change for the life of the LTS install - and that's what the majority of "normal" people want. As such, flatpak, snap, etc aren't for normal people. They're for people that like to have the latest single applications without potentially sacrificing the stability of the entire Linux system - not normal people. Not even close.

I prefer appimages when I can get them, but all of these systems are a kludge to fix the problem with the breakneck pace of individual FLOSS development without breaking people's basic every day OS functionality on a largely static base. Funny how the BSD, Windows, and MacOS people figured out how to make this work while Linux desktop and server is still flailing around chasing kludge after kludge. (And the BSD folks having to work around Linux kludges.)

[domih]

The teams behind apt, yum, dnf, zypp, urpmi, pacman, slat-get, smart, flatpack, snap, etc need to be put in a room.

They should:
1. Put pride, love, hate and the past behind them.
2. Define what a common package manager for the next 20 years should be.
3. Swear on their family lives that they will all adopt it and abandon the old ones.
4. Publish a standard for public review.
5. Rinse and repeat until a final common standard is approved.
6. Implement it without adding new stuff or modifications proper to a distribution. Instead use the standard committee to approve changes and additions.

Simple, no?

[domih]

Survival kits for users moving between distributions

- https://distrowatch.com/dwres.php?re...age-management
- http://johnmeister.com/linux/PDF-inf...CheatSheet.pdf

The simple fact that these exist reflects on the Ms FUBAR meets Mr SNAFU nature of the situation from a user viewpoint.

[hamishmb]

To be fair, the approach they're taking with Flatpak is "Easier to start out only viable for certain packages and then incrementally broaden our scope of utility than to start out like X11 and try to push apps like Chrome to retrofit support for the SECURITY extension."

Currently, one of the things they're working on is hammering out an extension to allow packages to declare that they contain browsers or WebExtensions native messaging clients that need to be made visible to each other. so it's feasible to distribute things like KeePassXC or download managers via Flatpak and have their browser integrations Just Work.

I use a few Flatpak apps with browser integration (Firefox) without issue. Is this a problem with Chrome?