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

271–280 of 624 posts

Re: Ubuntu stops shipping Flatpak by default

#271

Post by simon_o »

bionade24 wrote: post #229
simon_o wrote: post #181

Earlier quoted context omitted.

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

I'm not comparing sandboxing against SELinux/AppArmor. It's a social problem, not a technical one.

I'm comparing "app developers holding themselves accountable" to "package maintainers dish out consequences for misbehavior".

I have absolutely zero trust in the former, and lots of trust in the latter.

Re: Ubuntu stops shipping Flatpak by default

#272

Post by toyg »

necovek wrote: post #77
bantunes wrote: post #70

Earlier quoted context omitted.

I thought flatpak was a response to Ubuntu not open-sourcing the snap store code.

Sure, but I don't think it would have been much effort to build a snap store server with the client and package format open source. IOW, if RH wanted to "join in", there was a cheaper path forward.

You don't want to be a sharecropper; using a format you can't meaningfully influence for something as key as application installation, is an obvious non-starter for any serious distribution.

Re: Ubuntu stops shipping Flatpak by default

#273

Post by account42 »

bionade24 wrote: post #229
simon_o wrote: post #181

Earlier quoted context omitted.

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

You don't need any fancy packaging to restrict ptrace: https://www.kernel.org/doc/Documentation/security/Yama.txt

Re: Ubuntu stops shipping Flatpak by default

#274

Post by mestelan »

vetinari wrote: post #178
lapinot wrote: post #170

Earlier quoted context omitted.

This. Also void and alpine. Which have simple, no-nonsense package formats. We get it that deb and rpm are a hassle to learn and write, but it's completely a false dichotomy to say snap or flatpak are the only alternative. In fact they push a widely different model of software distribution, one that completely destroys "user unions" which is a crucial aspect of what distributions are.

> We get it that deb and rpm are a hassle to learn and write, They solve problems that arch/pacman didn't start even thinking about. Like reliably updating an installation, that wasn't kept in a tight loop with the upstream repo. > false dichotomy to say snap or flatpak are the only alternative we are slowly moving into the world of immutable base systems, like fedora silverblue for example. The last thing you want i…

silverblue ;-)

Re: Ubuntu stops shipping Flatpak by default

#275

Post by PlutoIsAPlanet »

manuelabeledo wrote: post #231
pizza234 wrote: post #137

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…

> These formats might be OK for desktops, but are absolutely awful for servers, containers, etc., which, incidentally, are where Linux dominates.

Containers have already won the war on the Linux server, there's no point Flatpak etc trying to compete here. Additionally, desktop software is a complete design paradigm to server software. I wouldn't even say they make sense to be in the same package manager.

Although they do share tech, ostree, namespacing etc.

Re: Ubuntu stops shipping Flatpak by default

#276

Post by friend_and_foe »

Havoc wrote: post #234

Are Ubuntu devs just not reading the room?

These organizations just demonstrate utter disdain for their users. It's not just Canonical. It's almost every company that's been around for more than a couple of decades. Microsoft, Google and Mozilla are also like this. They just don't care what their users want and they treat them like children who need to be spanked when they don't like it. I personally end all relationships I have with any organization that does this.

Re: Ubuntu stops shipping Flatpak by default

#277

Post by Steltek »

qbasic_forever wrote: post #264
Steltek wrote: post #230

Earlier quoted context omitted.

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

It's best practice not to have any shell tools in your app container, including package managers. It bloats the image and can be a security vulnerability if a zero day exploit hits the app. Ideally a container is something like distroless which just has the libc and dependencies you care about and nothing else, not even bash.

But where do your dependencies come from? Your compiler? Are you building everything from source after libc?

Re: Ubuntu stops shipping Flatpak by default

#278

Post by PlutoIsAPlanet »

pch00 wrote: post #131
viraptor wrote: post #107

Earlier quoted context omitted.

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

Silverblue doesn't get a lot of press but it makes a really solid desktop OS.

Fedora has always been quite bad at branding and making their distro appealing.

It's probably one of the most solid Linux distros at the moment and their website makes it seem.. boring.. No screenshots, features, mentions of whats available (like apps), that Fedora uses newer graphics/drivers kernels, that you can run Steam, that apps are sandboxed etc.

Stark contrast to something like https://vanillaos.org/

Re: Ubuntu stops shipping Flatpak by default

#279

Post by toyg »

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…

> they are rejected just because they are from canonical.

Or rather because they're proprietary, often closed-source, like Snap server.

Post reply on HN