Live data from Hacker News

Ubuntu stops shipping Flatpak by default

lwn.net

111–120 of 624 posts

Re: Ubuntu stops shipping Flatpak by default

#111
post #83
post #34

Earlier quoted context omitted.

Ubuntu has a much more aggressive 6 months release cycle, it's not nearly as outdated as Debian sometimes can be.

But that means I have to update my OS and my application when I want a new version instead of just my application. Say what you want about Windows, but I can download and run the latest version of all my applications on Windows 7 without it missing a beat.

Yes, because either you, the user, must track down .NET Framework X.Y (less of a problem now that they're stabilized) or because the application packs all of it dependencies and shoves them into \Program Files or \Windows\System32 until it's eventually 30gb with 1000 copies of msvcpXXX.dll

That's not that different from the distribution model of Flatpaks/AppImage (or APK, or .app on MacOS/iOS). It's more that, traditionally, Linux packaging solutions try to only have ONE copy of glibc or any other library, and packages are recompiled from source so the symbols resolve. Something which isn't an option on Windows, as a generality.

Re: Ubuntu stops shipping Flatpak by default

#112
post #75
post #50

Earlier quoted context omitted.

To put things into context, snaps were created before flatpak: in a sense, RedHat wanted to go at it "alone" (or at least separately from Canonical) with xdg-app/Flatpak. These ideas were already present even before those times and outside of both RH/Canonical, so it was more of a who's committed first. Basically, Ubuntu phones were using click packages (predecessor to snaps) back in 2011 and 2012, with snapcraft shi…

And lets not forget an even more prominent example: Upstart by Canonical that RedHat replaced with Systemd. Basically, Canonical will start at a project first, but RedHat specifically will look for ways to not join them, and start their own project instead. Part of that is certainly due to Canonical itself, but I can't help but think a lot of it is RH making a call and then throwing more developers at something.

Upstart’s CLA was a non-starter.

Canonical has quite a history of the behavior you're dinging Red Hat for: Mir, Unity, LXD, Juju/Charms, Launchpad, and I'm sure I'm forgetting several.

Also it’s Orwellianly named “Harmony” effort to popularize CLAs because Canonical has long sought to control upstream technologies - and consistently failed because they do not play well with others.

Re: Ubuntu stops shipping Flatpak by default

#113

Earlier quoted context omitted.

>What distribution doesn't support at least half a dozen desktop environments these days? Most usually come out of the box with official support for only 2 DEs. Of course they can theoretically support every one out there if you manually install them.

You make it sound like so much work, "manual installing". It's as simple as apt-get install $DE

Try that command on Arch, Fedora or OpenSUSE and let me know how it works.

Also, having multiple DEs in parallels rarely plays well with most distros. That's why they usually give you a downloads with one or two options already setup and tested.

Re: Ubuntu stops shipping Flatpak by default

#114
post #29

Earlier quoted context omitted.

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

Is there a distribution (or whatever one would call it - a Linux) where the aim is to not be managing the whole end-user system of OS+Apps, but just the OS. E.g. similar to Windows, or Android?

No distribution forces you to use package managers for everything. Even before flatpak/snap, distributing (especially commercial) software as just archives or executable installers was/is perfectly possible.

The caveat is, there's no common baseline for libraries. Graphics libraries, the libc itself, GUI widget libraries etc. will appear in different version combinations in different distributions, since they have different release schedules.

So if you want to go the Windows/MacOS route and ship a readily compiled program for Linux, you have to vendor in a loooot more libraries, and they have a higher risk of breaking due to incompatibilities (kernel interface for your graphics driver changed, configuration file syntax for your font renderer changed, etc.)

Flatpaks/snaps try to solve this (poorly) by vendoring the entire kitchen sink and then some, which just creates more bloat and a worse DLL hell than Windows could ever have dreamed of. So using it for everything isn't really feasible still.

Re: Ubuntu stops shipping Flatpak by default

#115

Earlier quoted context omitted.

When your break your fancy apt-architecture beyond repair aka You have held broken packages (whatever it means), you will be very thankful for snaps and flatpaks.

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

Re: Ubuntu stops shipping Flatpak by default

#116

Earlier quoted context omitted.

This puts too much unnecessary burden on developers and maintainers. It doesn't make sense to adapt software to tens of distributions (and then to different OS like FreeBSD). Apt should be used only for system software (like init system, system libraries) but not for applications. Also apt allows to run scripts as root during installation and this is not secure.

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 something in /Applications/... The .app is a folder, with all of its deps.

> Linux distros have a history of abandoning useful, well-understood technology for fads that then cause power users all kinds of headaches later-on (e.g. by cluttering output of useful tools like mount). Eventually, power users just lose the will to adapt, and move on.

"Power users" have a history of complaining about distro maintainers abandoning useful, well-understood techology because the "power users" don't actually understand the technology, nor do the understand the enormous headaches it causes distro maintainers to put a sane face on 30 year old design philosophies and continue moving forward.

The goal of distro maintainers is to STOP investing endless man hours in trying to make X work with high DPI displays, scaling, high refresh rates, a fundamentally insecure design model, and so on. The goal of systemd is/was for distro maintainers to STOP wasting endless man hours on edge cases because sysvinit didn't have reasonable mechanisms for "if anything in this dependency chain is restarted or changed, re-evaluate it" or "don't try to start this service if the mount isn't available so systems stop hanging on startup if some NFS server isn't available" or whatever.

> In the time of Jenkins et al the burden of creating bistro-specific packages is negligible.

Under the assumption that they are ABI stable, which is a bad one. Otherwise, it's the same old kaleidoscope of mapping out whether it's `libfoo-dev`, `libfoo-devel` for build requirements, whether it's a distro with a completely different naming system, dissecting the ELF header or reversing depchains in Python/Node/whatever to try to find deps and what THOSE are named in some distro, or whether they're even packaged at all, then building for every possible supported version of RHEL, Debian, Ubuntu, Fedora, SuSE, and down the line.

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

Flatpak/Snap are essentially a re-invention of putting things in /opt and using LD_LIBRARY_PATH or chrooting. Disk space is much less of a concern than it was before, and sacrificing a little space to AVOID the mess of shit above is a good investment.

Re: Ubuntu stops shipping Flatpak by default

#117
post #44
post #9

Mir, Unity, now Snap. Ubuntu has a track record of wanting to go it alone. But, I'm all for competition, long may it continue. The only real negative here is that some apps will only release Snaps, others will only release Flatpaks and people will end up having to just revert to copr/AUR like before. Choosing a distro is basically choosing a DE and package manager these days anyway - a single unified packaging format…

> Mir, Unity, now Snap. Ubuntu has a track record of wanting to go it alone. This. Also bzr. They seem to want to control their projects completely and so even when they have good tech they lose out to more open, community developed, equivalents that build wide engagement and momentum. I honestly don't understand it, you would have thought they would have learned by now that they don't have the engineering resources…

Another way to look at this situation is that canonical comes up with innovative solutions that are reasonably well engineered out of the box but they are rejected just because they are from canonical.

I'm struggling to find a way to characterize the difference between Red Hat/IBM and canonical's approach to the community. The most succinct I can come up with is that canonical releases projects and assumes that they are the one responsible for their creation., Red Hat releases rough ideas and code. There also seems to be a heavy political/disinformation campaign going on tearing down any solutions by canonical.

In either case, none of us can resolve the conflict. It's a pissing contest between canonical and IBM/Red Hat. I will keep choosing solutions that let me get my job done and get paid which is all that matters.

Re: Ubuntu stops shipping Flatpak by default

#118

Earlier quoted context omitted.

Is there a distribution (or whatever one would call it - a Linux) where the aim is to not be managing the whole end-user system of OS+Apps, but just the OS. E.g. similar to Windows, or Android?

Fedora Silverblue https://silverblue.fedoraproject.org/ You're expected to run most apps as flatpaks.

I stopped distro-hopping a few years ago after landing on Silverblue a few years ago (back when it was still called Fedora Atomic Workstation). While it doesn't satisfy all use cases, I view it as a boring (in a good way) 80-percent solution that normally just works.

Re: Ubuntu stops shipping Flatpak by default

#119

Earlier quoted context omitted.

You make it sound like so much work, "manual installing". It's as simple as apt-get install $DE

Try that command on Arch, Fedora or OpenSUSE and let me know how it works. Also, having multiple DEs in parallels rarely plays well with most distros. That's why they usually give you a downloads with one or two options already setup and tested.

They all have wikis you can read. And running DEs in parallel is a different problem from simply switching between two.

Re: Ubuntu stops shipping Flatpak by default

#120

Moved to Fedora for the mess around snaps and I'm not going to look back.

I've been setting up the new Fedora 38 sway spin (Wayland + sway wm out of the box) and am really impressed. I've been an Ubuntu derivative user for a long time but Fedora is great so far.

I've switched to Fedora KDE spin, and I've been loving it. KDE recently got native window tiling support which has been nice. It's not nearly as powerful at tiling as Sway, but it fits the bill for my use.
Post reply on HN