Live data from Hacker News

Ubuntu stops shipping Flatpak by default

lwn.net

361–370 of 624 posts

Re: Ubuntu stops shipping Flatpak by default

#361

Earlier quoted context omitted.

The last app image I've installed took 800 MB. It was approximately 720 MB of libraries, and just 80 MB of core program. Using self-contained images is simply not scalable. I have some experience with packaging, and if we talk about standalone applications, dependencies aren't a big deal; producing deb packages for different targets is not difficult. The last (only) breaking change across different targets I can reme…

> The last app image I've installed took 800 MB. It was approximately 720 MB of libraries, and just 80 MB of core program. Using self-contained images is simply not scalable. This is one of the points they are missing with snaps and flatpaks. These formats might be OK for desktops, but are absolutely awful for servers, containers, etc., which, incidentally, are where Linux dominates. Do I want to spend my time worryi…

Not sure about snap, but at least for Flatpak, it has runtimes and runtime extensions that Flatpaks can share, which already reduces the individual Flatpak size. But further more, all runtime, extensions and Flatpaks live in a single OSTree repository on the system, which does automatic de-duplication on the file level.

While probably still less efficient than a properly maintained and integrated distro, where all software uses a single set of shared core libraries, its actually (in the Flatpak case) quite optimized & has additional benefits, such as installing a set of apps that don't share a common set of required library versions, which would normally be impossible.

Re: Ubuntu stops shipping Flatpak by default

#362
post #106

Earlier quoted context omitted.

There are plenty of projects to semi-automatically produce packages for a large number of distributions starting from just a git repo of the software to package. Sure, packaging software is a bit of a thankless task, but with enough automation, packaging thousands of bits of software on every git commit should be doable by just a few volunteers.

What I would like to see is: 1) a unified database for package names (it's all unnecessarily ad-hoc right now, with different distros having different policies for capital letters, whether libraries are prefixed with "lib", whether python packages have "py" or "python" or "py3" etc... 2) a standard format for declaratively describing how to build a package. Basically, we have FreeBSD ports, Arch PKGBUILDs, Void templ…

There are already many standard build specification formats: CMake, autotools, Meson. For each, most distro's package managers can build the software with very little configuration, e.g. Debian's debhelper will cover most standard build systems and Gentoo has eclasses that you just need to inherit in a package. I'm not sure that adding another makes things easier.

Configuration options will need to be specified manually if you want any but I don't see a way around that as they are both package-specific and also something where distros want to differ.

For dependencies there are usually language-specific registries and pkg-config for C/C++-land. Some distros (e.g. RPM-based-ones) already support specifying dependencies by the pkg-config names or library SONAMEs. There is no distro-agnostic way to specfy your dependencies except for a README as far as I know - this would be something worth specifying.

Re: Ubuntu stops shipping Flatpak by default

#363
post #296

Earlier quoted context omitted.

I also switched to arch for a bit, but then I was left with an unbootable system after the arch devs shipped grub's master branch as stable. The arch devs were completely unapologetic and told me 'well maybe you shouldn't use arch if you can't recover a system who won't boot' Immediately formatted and switched to pop OS and I've never been happier.

Yeah, Arch is definitely geared toward a more technically proficient user base. Their users, myself included, are typically willing to wrestle with changes like that. Recovering a system that won’t boot is almost a rite of passage in the community, since there’s an expectation that you probably built up the entire boot process by yourself, so you ought to know what it’s doing. For some users, that’s simply not true.…

Yeah I was using endeavoros which was basically vanilla arch with an installer at the time.

https://old.reddit.com/r/EndeavourOS/comments/wygfds/full_tr...

Re: Ubuntu stops shipping Flatpak by default

#364
post #166
post #145

Earlier quoted context omitted.

But if hundreds of distro maintainers don’t do it then millions of users have to do it.

No, users don't do it. The application developers do it in their CI pipelines. Application developers should be the ones building and testing the app, not distro maintainers responsible for a dozen other applications.

You can't have distro specific policies using this methodology.

Re: Ubuntu stops shipping Flatpak by default

#365

Earlier quoted context omitted.

This also happened to me. So I decided to uninstall the snap and “apt install firefox” Guess what I got? A freaking snap. Yes, try it. I’m done with Ubuntu

It is possible to get an apt package, you have to jump through a few hoops but it can be done; I do it every time I install Ubuntu (frequently) because I won't touch that snap shite again. I can't move work off of Ubuntu; it's too embedded now, but I'm looking for something else for home. Switching distro-base isn't so easy when you've been using it for decades though; I tried NixOS but it wasn't comfortable (Nix is…

I moved from Ubuntu to Fedora when Canonical started pushing snaps 4 years after the auto update debacle that's also mentioned elsewhere here. Couldn't be happier.

Key differences I noticed:

- apt vs dnf

- Intalling on a new computer.

Would totally recommend.

Re: Ubuntu stops shipping Flatpak by default

#366
post #166

Earlier quoted context omitted.

No, users don't do it. The application developers do it in their CI pipelines. Application developers should be the ones building and testing the app, not distro maintainers responsible for a dozen other applications.

History has shown that application developers are very bad at releasing good deliverable without too much security holes in the packaged libraries or bad practices. And the sandboxing in flatpak is actually meant to protect users from harm done by clueless devs but it fails because devs can actually build non sandboxed flatpaks and they will do it because they don't care

How often do distribution maintainers actually audit the package source code?

Re: Ubuntu stops shipping Flatpak by default

#367

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…

Ehem: https://old.reddit.com/r/EndeavourOS/comments/wygfds/full_tr... EndeavorOS is basically vanilla arch with an installer, I just posted their thread because they were open and transparent about the issue while the arch sub did very little. When I raised this with an arch dev, I was told they purposely shipped grub's master branch (not release) because they didn't feel like backporting a security fix, and if I cou…

I may be misreading this comment, but it feels a little stuck up. Arch is created for Arch developers. This is well-known and they have never hidden that. The wiki states as much somewhere in the installation guide. That the distribution turned out to be useful to many others is purely coincidental. If you tried it and decided you're not one of them, no need to pour shit on devs as if they owed you something and didn't fill their part of the bargain.

Re: Ubuntu stops shipping Flatpak by default

#368
post #350

Earlier quoted context omitted.

I can't recommend EndeavourOS enough. You get all the good parts of Arch with an easy to use graphical installer, XFCE or another DE + great Nvidia support out of the box.

And if you are down to install and configure your distro from the CLI, NixOS is amazing.

It's not really what I would want on the desktop, but I did mess around with it a little and it's pretty interesting. Next time I need to set up a server for something I think I'll probably use it.

Re: Ubuntu stops shipping Flatpak by default

#369
post #238

Earlier quoted context omitted.

My favorite experience with snaps is Firefox just closing in the middle of doing something because it wanted to update, and it didn't even bother to check if I was using it first.

This also happened to me. So I decided to uninstall the snap and “apt install firefox” Guess what I got? A freaking snap. Yes, try it. I’m done with Ubuntu

Not userfriendly at all, but there is a solution:

  sudo tee /dev/null
  Package: firefox*
  Pin: release o=Ubuntu*
  Pin-Priority: -1
  EOF

  sudo add-apt-repository ppa:mozillateam/ppa
  sudo apt update
  sudo apt install firefox
I'm getting old for this; Canonical is getting Microsoft's manners.

Re: Ubuntu stops shipping Flatpak by default

#370

Earlier quoted context omitted.

Yeah, if you don't mind hugely increased start-up times, RAM usage and less curation and more crap, sure no need for package distribution. I personally do mind very much. Just the differences in startup times between apt and snap applications are huge and I would absolutely despise working with such a sluggish system. I would rather build everything myself from source if forced to.

The mass proliferation of electron and other such webpages-as-desktop-applications would seem to indicate that the average user doesn't care for any of those things.

So much weird assumptions.

First of all, there is no such thing as an average user. Also, it is not relevant to the discussion. I care about what I want in a system, not what some imaginary users want.

Now, we could stop there but I will play: Electron solves a real problem for developers. Writing cross-platform GUI apps is a real pain. Yes, there are native solution but ensuring the user has the exact same experience on every platform tends to be orders of magnitude more costly compare to web based solutions. (That or they are exotic options like Lazarus with Free Pascal that have a much lower Developer pool.) Many apps wouldn't even have Linux ports if they were not written on Electron.

Now, why do users accept them? Why are they not out-competed by native solution? Oh, honey. Why do I have Microsoft Teams installed? Because I like it? Hell, no! Because I need it for work. Why do I have the Discord Client? Because it is great? Nah, I long for good old IRC but Discord it there the people currently are. Did I think the Epic Games launcher is such an great app? Nah, they bought me with offering free games.

Users tolerate shitty software for many reasons, mostly because they have to. It does not follow from that, that they don't mind software being shitty.

Post reply on HN