Live data from Hacker News

Ubuntu stops shipping Flatpak by default

lwn.net

561–570 of 624 posts

Re: Ubuntu stops shipping Flatpak by default

#561

Earlier quoted context omitted.

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.

Can you share bit more details? I have no issues with that setup or at least I cannot notice the issues.

There were a few things wrt to clustering (which I don't need) and storage pool management that tripped me up at first, but not too bad. However, it made me worry about the fact that I might not be the target audience for the LXD project (I just need simple lightweight machines with snapshots, nothing more).

When they decided to stop officially distributing debs, and promote Snap as distribution channel, that was the final straw. I don't understand what's their target audience anymore. Desktop users? My machines are sensitive about reboots, but pretty much sealed off the internet. Upgrades are tested, and happen in scheduled windows. Yet Snap auto-update insists on restarts, whenever it sees fit.

Sure, I can find workarounds [0], but the complete disregard on this issue and the reason that they probably forced the LXD project to promote the dumpster fire that is Snap just didn't sit well with me. I'm gone for good.

[0] https://forum.snapcraft.io/t/disabling-automatic-refresh-for...

Re: Ubuntu stops shipping Flatpak by default

#562
post #173
post #157

Earlier quoted context omitted.

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.

> You can't take a .deb from Debian 11 and install it on Debian 10. I mean, you can, if you also install its dependencies. And you may end up with a weird franken-system, but you can. You can even automate it and set preferred distros with pinning, it's how people run things like hybrid testing-unstable distros.

If you automate it and work out the kinks, you basically get flatpak.

Re: Ubuntu stops shipping Flatpak by default

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

Competition of implementations is good but competition of standards less so. My biggest problems with Ubuntuland-alternatives is that they expect the world to pay the maintenance cost for their NIH syndrome. Mir as a Wayland compositor is fine. Mir as something that every toolkit needs to implement is a giant waste of everyone's time. The same is true for Snap - if you could make one package that works with flatpak and Canonical's implementation then I would be a lot less opposed. But you can't. Because Canonical doesn't care how much extra work everyone else has to do as long as they get their way. Thankfully, so far they don't in the end - I expect Snap to follow.

Re: Ubuntu stops shipping Flatpak by default

#564
post #50
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…

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…

> they do have a problem getting the community involved, but part of that is the size and limited time their developers have.

A tiny inconsequential part. The bigger one is their refusal to give a shit about usage outside of Ubuntu with Canonical-controlled servers and their insistence on CLAs. Canonical has noone but themselves to blame for Red Hat to continously win the community for their solutions even when they were late to the party.

Re: Ubuntu stops shipping Flatpak by default

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

Flatpak development actually started much earlier than that. The first version happened in 2007 when it was known as "Glick". https://github.com/flatpak/flatpak/wiki/Flatpak's-History

And AppImage was already a thing in 2004. To bad that everyone has to reinvent the wheel when it comes to packaging instead of building on the existing solutions.

Re: Ubuntu stops shipping Flatpak by default

#566
post #54
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…

Bzr is a great counter example. Bzr "lost" because git had GitHub, whereas Launchpad was one too many things and slow to optimize for modern sensibilities. (And Linux used a different VCS before git, so that didn't matter in adoption) Imagine a world without GitHub, and I don't think git would be our go-to VCS. Though maybe not even Baazaar, but there are things like Mercurial too.

Git already had momentum before GitHub became popular. And yes, it is absolutely Linux and other high-profile projects that ensured its success in the OSS world. Claiming that Linux having used a different VCS before git means that Linux's use of git doesn't matter is really odd when git was developed for the Linux project.

Re: Ubuntu stops shipping Flatpak by default

#567
post #279

Earlier quoted context omitted.

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…

> they are rejected just because they are from canonical. Or rather because they're proprietary, often closed-source, like Snap server.

And even if they are open source, the development is not (initial development often closed completely, later development requiring CLAs) and the projects only care about Canonical's use of them to the point where even building them on other distros is often far from trivial.

Re: Ubuntu stops shipping Flatpak by default

#568
post #366

Earlier quoted context omitted.

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?

I wasn't talking about audit but dependency lifecycle.

Re: Ubuntu stops shipping Flatpak by default

#569

Earlier quoted context omitted.

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

I found a better example. Only solution aptitude ever gives is not to install paprefs. Please solve that. $ sudo aptitude install paprefs Keep the following packages at their current version: ... 11) paprefs [Not Installed] ... Accept this solution? [Y/n/q/?]

Don't know your install, but Debian by default uses Pipewire, not Pulseaudio. If you are using Pipewire, indeed you can't install a Pulseaudio application. That's expected.

You can replace pipewire with pulseaudio. It's doable, just not trivial enough for an HN comment. In general, you'd have to force removal of pipewire without removing all dependent packages, install pulseaudio and then have apt check that all dependencies are ok. Then, having Pulseaudio in the system, you can install paprefs, a Pulseaudio application.

As I said, it's a solid system, rather impossible to break into an unrecoverable state.

Re: Ubuntu stops shipping Flatpak by default

#570

Earlier quoted context omitted.

Slackware, perhaps? Honestly, if you just want the naked OS, you don't need a distro at all. Or just don't use the package manager.

I'm curious what a Linux would look like that behaved more like windows or android in the sense that there isn't such a blurry line between the OS and its applications. For example, installing a C# or Go compiler on Linux is great with a package manager. But doing the same with a C or Python is different? This is basically the Unix "I'm not just an OS, I'm a platform for building and running C programs" heritage that…

We've reached the point where the C ecosystem has so given up on having a package manager that isn't Linux distributions that Microsoft added WSL and Docker(-compatible) Linux images are the most widespread distribution format. I don't think we can still figure out a way to decouple the two again, and without that, we can't really create a Linux environment that isn't a package manager with an email client.

And to a degree, the line is blurry with Windows as well, what with how deep MSVC/win32 is integrated into the system. .NET took decades to dis-entangle itself from Windows and become a proper standalone platform, and Microsoft's attempts at getting people to use UWP instead of win32 is ongoing and not very successful so far.

Post reply on HN