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

151–160 of 624 posts

Re: Ubuntu stops shipping Flatpak by default

#151

Post by schmorptron »

SSLy wrote: post #71
necovek wrote: 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…

snap's original sin was the moat of server being closed source and client /really/ wanting to talk only to the Canonical's instance. The latter is shared by Docker, in a way.

It's so upsetting that canonical will continually come up with cool tech, try to keep complete control over it and ideally make it so it long term becomes the only option, which people understandably don't jive with. Had they learned that in the space theyre in an open approach works better, we could still be using mir, upstart and most importantly unity now. God I miss unity.

Re: Ubuntu stops shipping Flatpak by default

#152

Post by noirscape »

qbasic_forever wrote: post #91
bombolo wrote: post #84

Earlier quoted context omitted.

I don't want debian to be like the android app store, where there are thousands apps that work badly and overflow me with ads. I much prefer the f-droid model, of having curated repositories to keep crap outside. Also, I can't understand why people on the internet think that upstream developers are omniscient. They make lots of mistakes and errors. Distribute maintainers fix a lot of things, and send the fixes to the…

There's nothing stopping someone from making a flatpak or other similar tech feed or 'store' that's only the curated apps they deem appropriate for users. Bugs should be fixed upstream, not kept in distro specific silos. There's no reason why only a packager can fix some upstream issues or become a contributor. On the contrary shipping your app as a universal tech like flatpak means Redhat, Debian, Arch or any other…

> Bugs should be fixed upstream, not kept in distro specific silos.

This is mostly a Debian issue fwiw. Debian is literally notable because they're obsessed with making sure that any package in their repositories is kept with the same "API"[0], no matter how old the software is. The result is that Debian packages can end up hugely derivative compared to the equivalent of upstream and other distros, but it's usually also because the software in question is half a decade old.

With other distros, packaging changes to upstream usually just reflect the preference to match a certain style of configuration (to pull another example from Debian: nginx ships with sites-{enabled,available} folders and is configured to load from sites-enabled by default. This is to match the same configuration style that's used for apache2 and that it's associated tools assume you configure apache2 with, even though nginx just uses a conf.d folder and has no extra tools to facilitate anything fancy with sites-{enabled,available}).

The extreme end is nix, which actively requires you to have the upstream written with nix in mind because nix will basically demand you configure the source code in ways to accommodate for it.

[0]: This includes actual software-intended interfaces and the ones hacked together by users by ie. reading out logfiles.

Re: Ubuntu stops shipping Flatpak by default

#153

Post by attractivechaos »

dTal wrote: post #65
Klonoar wrote: post #51

Earlier quoted context omitted.

This model doesn't necessarily work for software that developers don't want others shipping for them .

Setting aside that those developers are not good team players / open source citizens, they always have the option to ship a regular tarball with everything inside, a la Blender / Firefox / VSCode / Arduino etc... I resent having to install and maintain another package manager, and another set of base runtime libraries. I won't do it. Give me standalone binaries, give me source that compiles, but don't give me a link…

I wish all software could provide portable binaries. However, compiling portable binaries is hard. Not many developers have the skill.

Re: Ubuntu stops shipping Flatpak by default

#154

Post by Izkata »

api wrote: post #133
bayesian_horse wrote: post #13

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

As someone who does this for a lot of distros (ZeroTier), I can say that it is hell and I understand why devs don't want to do it. Two specific examples: (1) For some reason a lot of Debian distros decided to rename and/or re-version-number OpenSSL for no good reason (pedantry is not a good reason), meaning if you depend on OpenSSL/libcrypto your packages will mysteriously break all over the place because you're not…

> Snap, FlatPak, and Docker are all variations on the same basic conclusion that many developers reached long ago: "fuck it, just distribute software in the form of tarballs of entire Linux installs."

..wait a minute

> (2) We use a UPnP library called miniupnp in the current version. We have to statically link it because of issues like (1) and also because some distros were for a time stuck on a version that had security bugs that they would not upgrade because it would break other packages.

Wouldn't this solve the same problem without adding snap/etc?

Re: Ubuntu stops shipping Flatpak by default

#155

Post by vinyl7 »

phkahler wrote: post #132
zorr wrote: post #56

Earlier 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. And application developers have to essentially wait for each distro to repackage their app before it becomes available on that distro. Or start messing with alternate repositories for each distro they want to support. The old model works for established software, but breaks down a l…

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

Arch Linux would like to have a word

Re: Ubuntu stops shipping Flatpak by default

#156

Post by chr15p »

rickydroll wrote: post #117
chr15p wrote: post #44

Earlier quoted context omitted.

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

I don't think it is a pissing context between them, they can both happily exist in the same world, it just interesting to see the difference in approach and try and figure out why one seems more successful than the other.

I think you're right that Canonical creates and releases projects and assumes they are in charge of them, but I disagree about Red Hat (honestly not sure what you mean by "rough ideas and code"), I think they tend to see whats already out there and then throw their weight behind that, then only if there isn't do they create their own and even then they are more open about how the project runs. That difference means Red Hat gets more momentum behind its projects, and that is what counts. (of course RH can throw more engineers at stuff as well, and that also helps a lot)

Its not some sort of conspiracy, nothing Canonical has ever done has had the same amount of hate as systemd has, its just a difference in approach.

Re: Ubuntu stops shipping Flatpak by default

#157

Post by veeti »

phkahler wrote: post #132
zorr wrote: post #56

Earlier 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. And application developers have to essentially wait for each distro to repackage their app before it becomes available on that distro. Or start messing with alternate repositories for each distro they want to support. The old model works for established software, but breaks down a l…

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

Have you ever actually worked on distribution packaging? There is no such thing as a "standard" .deb or .rpm. Unless you're statically linking against distro policy they have dependencies on the particular version of the distribution they are built for.

You can't take a "standard" .rpm from the Fedora repositories and install it on CentOS. You can't take a .deb from Debian 11 and install it on Debian 10.

Re: Ubuntu stops shipping Flatpak by default

#158

Post by cardanome »

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.

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.

Re: Ubuntu stops shipping Flatpak by default

#160

Post by preisschild »

mg wrote: post #108

I wish there was a solution like flatpak or snap that does make things simpler, not more complex. To begin with: It would be nice if the data of the containerized applications were stored in one place and one place only. Each application should simply be a single directory in /snaps/ or something. At first I thought snap would be like that. But no. When I did some tests, the data of a snap seems to be splattered acro…

Flatpak does this. It stores it in `~/.var/app/`
Post reply on HN