Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ubuntu stops shipping Flatpak by default

lwn.net

Post reply on HN
Print view View original

221–230 of 624 posts

Re: Ubuntu stops shipping Flatpak by default

#221

Post by jovial_cavalier »

coldpie wrote: post #201
jovial_cavalier wrote: post #175

Earlier quoted context omitted.

It's probably because you run updates every couple of days that you don't have the issue. For me, I have a laptop that can go untouched for up to a month, and it's not fun catching up on a month's worth of updates. Lots of packages have been replaced, I usually have to futz with the keyring, etc. Also worth pointing out - the fact that you can so easily perform a partial update with pacman and totally break your syst…

> If an upgrade fails, it should revert to a cached package database. I'm prettttty sure it does now? When did you run into this problem? It definitely used to be a problem, a long time ago (I ran into it once when I ran out of disk space mid-upgrade), but I think system updates are atomic now.

Happened to me a few months ago (whenever that big SSL 0-day was announced).

I use a 3rd party repo for ZFS drivers, which gets checked for compatibility with each new kernel release by the maintainers, so ZFS frequently stops me from upgrading, and crucially it stops me after I've already fetched the new package databases.

Running pacman -Sy and then installing an individual package isn't supported and it's understandable why.

Running pacman -Syu and having it break sticks you into this limbo where if you install anything before finishing the upgrade, you risk shooting yourself in the foot.

Re: Ubuntu stops shipping Flatpak by default

#222

Post by minimaul »

jovial_cavalier wrote: post #175
minimaul wrote: post #74

Earlier quoted context omitted.

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…

It's probably because you run updates every couple of days that you don't have the issue. For me, I have a laptop that can go untouched for up to a month, and it's not fun catching up on a month's worth of updates. Lots of packages have been replaced, I usually have to futz with the keyring, etc. Also worth pointing out - the fact that you can so easily perform a partial update with pacman and totally break your syst…

I do have a shell VM (accessed via SSH & xpra) that I update much less frequently and still don't have issues.

I think the main reason I have fewer issues compared to other comments here is I try to minimise my use of the AUR, and don't install third-party repos.

Re: Ubuntu stops shipping Flatpak by default

#223

Post by groestl »

CalRobert wrote: post #165
wilonth wrote: post #161

Wow they're still pushing snaps, the project with some the worst engineering I've ever seen. - Extremely slow at doing anything, even the most basic commands. - Ridiculous auto-update mechanism (you can't even disable it wtf). - Random, nonsense limitations (why can't I open dot files and dot directories???). So terrible that for most apps that I installed with snaps I end up installing the deb version later on. What…

Snaps are getting me off Desktop Ubuntu after 12 years of happily using it.

I left Ubuntu server and lxd because of it. Maybe a bit emotional, but f*ck that, I don't need this in my life.

Re: Ubuntu stops shipping Flatpak by default

#224

Post by sergiosgc »

timonoko wrote: post #115
sergiosgc wrote: post #47

Earlier quoted context omitted.

I never broke a Debian install beyond repair, and I've used it for a couple of decades. Even when doing some really off the charts stuff, including powering off a system mid dist-upgrade. Apt is really really solid and well documented/community supported.

Then community-solve this: $ sudo aptitude install wine-stable --- 5 pages of useless garbage removed and then: 62) wine32:i386 [Not Installed] Leave the following dependencies unresolved: 65) wine64 recommends wine32 (= 3.0-1ubuntu1) Accept this solution? [Y/n/q/?] In other word the suggested solution is: Do not install wine

    sergio@sergio-laptop:~ > sudo apt-get install wine
    Reading package lists... Done
    Building dependency tree... Done
    Reading state information... Done
    The following additional packages will be installed:
        fonts-liberation fonts-wine libcapi20-3 libodbc2 libosmesa6 libwine libz-mingw-w64 wine64
    Suggested packages:
        odbc-postgresql tdsodbc ttf-mscorefonts-installer q4wine winbind winetricks playonlinux wine-binfmt dosbox exe-thumbnailer | kio-extras wine64-preloader
    Recommended packages:
       wine32
    The following NEW packages will be installed:
       fonts-liberation fonts-wine libcapi20-3 libodbc2 libosmesa6 libwine libz-mingw-w64 wine wine64
    0 upgraded, 9 newly installed, 0 to remove and 15 not upgraded.
    Need to get 105 MB of archives.
    After this operation, 700 MB of additional disk space will be used.
    Do you want to continue? [Y/n]
No need to overcomplicate things by going multi-arch.

Re: Ubuntu stops shipping Flatpak by default

#225

Post by bionade24 »

dTal wrote: post #121
bionade24 wrote: post #103

Earlier 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…

First of of all, I don't like Snap or Flatpak. I'm only really interested rpm-ostree as used in Fedora CoreOS and Silverblue. I don't hate Appimages, you're claim that they're "fundamentally different" is just hypocritical.

> The purpose of an AppImage is simply to condense such a tarball to a single runnable file, for convenience - nothing more.

This still forces the user to learn the internals if the AppImage doesn't work. E.g. if MATLAB would use Appimage, I'd have to extract squashfs contents, fix the broken libraries inside and the repackage it. Or I would have to write a script to start the executable outside. It's a simpler from a pure technical standpoint when it's a tarball + wrapper script.

> Snap permanently runs a daemon, and Flatpak requires you to run programs with "flatpak run" - yuck!

Snap has many issues Canonical just refuses to solve (e.g. users without home under /home), so I just ignore that. What flatpak does is arguably exactly what Appimage does, a wrapper script. Maybe more complex, but with additional features and the it's the same script for all packages. If you have 100 AppImages installed, you have the same thing as "flatpak run" in up to 100 slightly different versions. I can't see how that reduces complexity.

Re: Ubuntu stops shipping Flatpak by default

#226

Post by groestl »

2b3a51 wrote: post #217
noloblo wrote: post #204

Earlier quoted context omitted.

Same here off Ubuntu and onto centos/fedora rpm dnf world

Glad you have something sorted out. Just interested: why not Debian? i.e. still deb based distro? I'm guessing the poster above you wants recent package versions as they went to Arch.

For me it's now Debian on the server (debs) and Arch on the desktop (rolling releases, AURs).

Re: Ubuntu stops shipping Flatpak by default

#227

Post by Steltek »

AnIdiotOnTheNet wrote: post #127
qbasic_forever wrote: post #67

Earlier quoted context omitted.

Hot take: package distributors are 'fake jobs' that don't need to exist, or exist only for the make-work of packaging. Tools like flatpak, snap, appimage, containerization, etc. have made the need for adapting software to different distributions unnecessary.

I agree. Maintainers are useless middlemen (at best) who only exist because of Linux userland's particular diseases and a desire for distros to rule over their own little repo fiefdoms. No other desktop OS has done it like Linux and for good reason. People have been citing this as a reason they don't want to use Linux as a desktop for decades to mostly deaf ears, who then turn around and wonder loudly why no one want…

I have no earthly idea what you are talking about.

For decades, Linux package managers have been the killer app for Linux. They made installing and updating every single one of your applications trivial. You didn't google for sketchy download sites and unsigned exe's. You didn't have to fight the system to cleanly uninstall things. Even release upgrades were the smoothest thing ever. In 25 years, I've never had a Debian release upgrade go wrong.

Anyone bitching about package managers as user hostile is a flat out idiot.

Re: Ubuntu stops shipping Flatpak by default

#228

Post by coldpie »

jovial_cavalier wrote: post #221
coldpie wrote: post #201

Earlier quoted context omitted.

> If an upgrade fails, it should revert to a cached package database. I'm prettttty sure it does now? When did you run into this problem? It definitely used to be a problem, a long time ago (I ran into it once when I ran out of disk space mid-upgrade), but I think system updates are atomic now.

Happened to me a few months ago (whenever that big SSL 0-day was announced). I use a 3rd party repo for ZFS drivers, which gets checked for compatibility with each new kernel release by the maintainers, so ZFS frequently stops me from upgrading, and crucially it stops me after I've already fetched the new package databases. Running pacman -Sy and then installing an individual package isn't supported and it's understa…

Interesting! How does the ZFS upgrade "stop" the package upgrade process, I wonder? Might be worth reporting a bug, maybe pacman can handle that kind of failure better, or maybe the ZFS package could be changed to fail more gracefully. I think the pacman devs would agree leaving the system in a partial-upgrade state is a bad thing to do.

Re: Ubuntu stops shipping Flatpak by default

#229

Post by bionade24 »

simon_o wrote: post #181
Kinrany wrote: post #142

Earlier quoted context omitted.

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

> want sandboxing to work by default Yeah, wake me up when Flatpak is remotely close to doing this. Most "apps" simply disable the sandbox. Not to mention I'm not going to trust "app" developers setting their own permissions. That's the job of package maintainers.

Afaik they disable filesystem sandboxing, not process namespaces. Still better if programs can't ptrace around, although this is indeed a big issue.

If someone knows why this sandboxing is better/worse than SELinux or AppArmor access rules, can you pls elaborate? I'd really like to know.

Re: Ubuntu stops shipping Flatpak by default

#230

Post by Steltek »

qbasic_forever wrote: post #67
creshal wrote: post #29

Earlier quoted context omitted.

The whole point of a distribution is that this job is done by the distributors, not the authors.

Hot take: package distributors are 'fake jobs' that don't need to exist, or exist only for the make-work of packaging. Tools like flatpak, snap, appimage, containerization, etc. have made the need for adapting software to different distributions unnecessary.

What's the base image for the containers? Do none of your Dockerfiles have apk or apt commands?
Post reply on HN