Earlier quoted context omitted.
yeah lost a day this week to bloody snaps
Is there a single user who likes snaps?
Forced auto updates and a closed store mean I won't even try to like snaps. Those are the top two reasons I moved off Windows.
Ubuntu stops shipping Flatpak by default
141–150 of 624 posts
Re: Ubuntu stops shipping Flatpak by default
#142Earlier quoted context omitted.
No, an Appimage still ships a dynamically linked executable + lots of dynamically linked libraries, that only link against system libraries when strictly needed, e.g glibc and libGL. Those files are bundled in a squashfs and have a script setting a custom LD_LIBRARY_PATH to the squashfs content for the binary. Snap does use this technique, too, but does more, for worse. AppImages are not comparable with statically li…
I can't make out what you're disagreeing with - you seem to be arguing against something I didn't say? The point is that the contents of an AppImage - "a dynamically linked executable + lots of dynamically linked libraries" - works just as well without all the squashfs backflips. If you can ship an AppImage, you can ship a regular ol' tarball with a binary named "RunMe" inside. The purpose of an AppImage is simply to…
> But I've seen no justification why that should be co-mingled with package management.
Building sandboxing on top of package management makes a lot of sense because you want sandboxing to work by default, and for that you need to identify the sandboxable things without making the user point to each one individually.
Re: Ubuntu stops shipping Flatpak by default
#143Today VLC didn't start. No errors, no reason. Just didn't start.
Turns out snapd.apparmor, whatever that is, wasn't running. (I ran `vlc` on the cli to figure it out)
I love snaps, they're so convenient for the end user..
Re: Ubuntu stops shipping Flatpak by default
#144Earlier quoted context omitted.
Conversely, `pacman -Syyuu` doesn't complete reliably without user intervention, which is far from ideal. I say this as an Arch user - the expectation that I'm going to manually attend to package upgrades in practice leads to me using outdated packages
I'm genuinely curious about this, as I see people say it a lot but it's not my experience at all. I have an Arch Linux desktop (KDE + AMD), I update it every few days, and it's always fine. I also have a shell VM that runs IRC etc that often isn't updated in months, and I run `pacman -Syyu` and everything works fine. I've never had the infamous 'Arch updates are unreliable' issue. Is it certain packages that are more…
I haven't had it often but I've had stuff break sufficiently badly that I couldn't boot to a graphical environment before.
I agree with the other posters that a lot of the stuff that breaks is in the AUR, but practically most users rely on the AUR so if the AUR is prone to breakage so is the typical user's arch Linux environment.
I'll also freely concede that part of this stems from the common practice of treating the AUR and pacman packages interchangeably through helpers, but that's a practice that's almost necessary for reasonable use and is present on the official wiki.
I think ultimately Arch is just a UX which was designed in a simpler time when users could reasonably expect to account for all the packages they installed
Re: Ubuntu stops shipping Flatpak by default
#145Earlier quoted context omitted.
>> The problem with that model is that it puts the burden on the distro maintainers to package every possible application for their distro. That's kinda what the distros ARE. Also, if you're debian based and debian packages are not compatible with your distribution you're actively fucking something up for "reasons" - stop doing that. If an app can't use a standard .deb or .rpm then the distro is doing something wrong…
> That's kinda what the distros ARE. What things are can change, sometimes for the better. Imagine if distros maintainers could spend their time doing something more productive than doing the same work as hundreds of others are doing.
But if hundreds of distro maintainers don’t do it then millions of users have to do it.
Re: Ubuntu stops shipping Flatpak by default
#146Earlier quoted context omitted.
> The updates are currently awkward as they don't seem to work if the application is running The fix for this is currently being tested: https://bugs.launchpad.net/snapd/+bug/1980271 > before removing alternatives Alternatives remain available for install. They weren't removed.
That issue is related, but not quite what I meant. I would want the app to be updated in the background whilst it is running (which works fine for APT installed packages), so just closing it and re-opening it would get the newer version. That bug you linked to is the issue that after getting a visual prompt about a newer version of Firefox being available, the "snap refresh" isn't run immediately after closing it dow…
> I would want the app to be updated in the background whilst it is running (which works fine for APT installed packages), so just closing it and re-opening it would get the newer version.
The Firefox deb (such as in 20.04) became unusable and tabs crashed when the deb was updated without a restart.
It's really down to each individual app as to whether it will work being updated in the background or not.
AIUI the new snap implementation gets everything ready in the background, so the update on closing it and re-opening it is quick.
Re: Ubuntu stops shipping Flatpak by default
#147Re: Ubuntu stops shipping Flatpak by default
#148Earlier quoted context omitted.
What you are really saying is you want all software developers to publish Debian packages (no such thing as "apt" packages) compatible with your particular Debian distribution, even though they might be using a different Debian based distribution, a completely different altogether, maybe even a different architecture, even though that compatibility isn't their primary concern.
The original model is that software developers don't package their software for distributions at all, at best they provide helper scripts that the distribution maintainers can use to do that. That's why distributions are typically either giant volunteer-run organizations like Debian or companies like RedHat or Canonical.
For me, the "stop the world" distribution model is pretty broken, compared to FreeBSD Ports or similar. I don't ever want a maybe-years-old version of software, even with random security patches applied to it.
Re: Ubuntu stops shipping Flatpak by default
#149Earlier quoted context omitted.
Snaps/Flatpacks/other binary-containerised stuff is one of the major reasons why I abandoned Linux distributions after 22-odd years (1999-2022), and am now a happy Apple user (the other one being abandoning X11 in favour of Wayland, and a switch to laptop-first usage, on which Linux still has horrible power-consumption). Linux distros have a history of abandoning useful, well-understood technology for fads that then…
> Snaps/Flatpacks/other binary-containerised stuff is one of the major reasons why I abandoned Linux distributions after 22-odd years (1999-2022), and am now a happy Apple user (the other one being abandoning X11 in favour of Wayland, and a switch to laptop-first usage, on which Linux still has horrible power-consumption). Flatpaks/Snaps are almost exactly the same, conceptually, as apps on MacOS. Go look inside some…
> This is why "power users" aren't an important user model. Arch, Gentoo, Nix, and others exist if you want to be a "power user". Otherwise, extremely naive assumptions about the amount of effort expended by distro/package maintainers hand-wave the complexity away with "duh, just put it in Jenkins."
Surely distros could be based on top of Nix with carefully curated sets of packages with less effort than it takes to package everything for Debian.
Re: Ubuntu stops shipping Flatpak by default
#150Earlier quoted context omitted.
The original model is that software developers don't package their software for distributions at all, at best they provide helper scripts that the distribution maintainers can use to do that. That's why distributions are typically either giant volunteer-run organizations like Debian or companies like RedHat or Canonical.
This model doesn't necessarily work for software that developers don't want others shipping for them .
Just use AppImage then. Or create a good old tarball. Problem solved.
These should be absolute exceptions, not the rule, anyway.