Mastodawn

Danilo Jun 3, 2023

@martijnbraam I see Flatpak as a great way for developers to package desktop software in a way that mostly works on all distros, and also offers some sandboxing.

If distros like the software, they should package it, and its users should install the "native" package. But until then, it's a better solution for most users than compiling from source.

Martijn Braam Jun 3, 2023

@dbrgn well the annoying trend is that developers refuse to acknowledge issues if it's not happening on the flatpak or are straight up telling distributions to not package the software

j.r / Julian Jun 3, 2023

@martijnbraam @dbrgn or even threatening distributions legally because they packaged the software (including artwork and name)

Monster Ⓐ Jun 4, 2023

@martijnbraam
This is a good thing. Applications made as Flatpaks are intended to be used that way. Issues often come from traditional packages not being up to date, or simply packaged with the wrong packages. If a developer has nothing to do with this, why would they want to fix it? Oftenly, how CAN they even fix this? If a developer tells packagers to not package their application, they should listen to this.
@dbrgn

Jules Enriquez Jun 4, 2023

@martijnbraam Bit out of the loop on this one; aside from Bottles devs, what other apps have developers refusing to acknowledge issues from non-Flatpak packages and/or telling distros to stop packaging them?

@win8linux Fractal, Workbench, Authenticator from the top of my head

Hugo 雨果 Jun 3, 2023

@dbrgn There's a new trend coming up of software specifically tailored to run on Flatpak where the authors are quite hostile of anyone trying to run their software elsewhere (and dismissing issues outside of Flatpak).

I feel like this anti-portability stance erodes the ecosystem so much.

Maxi 12x 💉Jun 3, 2023

@martijnbraam I recommend to put the article’s title into your toot here.

Maxi 12x 💉Jun 3, 2023

@martijnbraam Also, "does have it's uses" should be "its" without apostrophe.

Maxi 12x 💉Jun 3, 2023

@boilingsteam ^^

grillchen Jun 3, 2023

@martijnbraam i feel like flatpak is the windowsiation of package management. it has its use cases but it is rare, i only want a flatpak or appimage for old university software i have somehow to use and isnt up to date anyway....

baliceauxPelican Jun 3, 2023

enlightening

Sonny Jun 3, 2023

@martijnbraam

Nobody says distros are evil. Flatpak is beneficial/complementary to distros:

* Less work for distros
* Enables read-only rootfs
* No breakage for apps

The sandbox works. You're complaining about GNOME Software and cherry picked an app which doesn't support isolation (yet?).

> painfully shoehorned into Github workflows

That's Flathub and only a matter of time.

> impossible to run the nice Gnome Builder IDE without having your application in a flatpak.

Not true.

Hugo 雨果 Jun 3, 2023

@sonny There's been plenty of breakage in apps while introducing dependency on some of Flatpaks's daemons. Eg: the first time I try to save a file in Firefox, it fails due to trying to use a FileChooser portal (even if no such thing is locally available).

Sonny Jun 3, 2023

@whynothugo I really cannot care if your system doesn't have portals installed -_-

Hugo 雨果 Jun 3, 2023

@sonny Not caring doesn't make your statement true.

Sonny Jun 3, 2023

@whynothugo you realize that missing dependencies is one of the thing Flatpak protects against?

OFC if you miss a Flatpak component it's not going to work.

It's like complaining you don't have audio because Pipewire isn't installed.

If your distro doesn't support Flatpak properly complain there.

James Westman Jun 3, 2023

@sonny @martijnbraam Also, flatpak-builder isn't the only way to build flatpaks. You could definitely make a tool that builds a flatpak from a list of dependencies (IIRC Fedora's repo does this?)

Xavi Jun 3, 2023

@martijnbraam I tend to think static binaries built with musl (those built so as to have no depencies other than the kernel itself) can still offer a distro-agnostic executable, similarly to Flatpak, AppImage or Snap try to achieve, yet being a lot simpler, faster and smaller. I cannot understand why they seem so underrated, though.

razze Jun 3, 2023

@martijnbraam I agree, that usb stuff should get worked on, but I needed to install udev rules for normal packages too to work. So that part doesn't really make sense to me.

But no usb events is the real deal breaker for me right now (well I still use/maintain those packages)

Martijn Braam Jun 3, 2023

@razze the nice thing with normal distributions is you can just package udev rules and it works automagically for end users. No such option with flatpak

razze Jun 4, 2023

@martijnbraam funny that that never seemed to work for me or packagers didn't do that then. But I only tried on manjaro (aur) and fedora.

I also thought udev rules wouldn't be needed, if you make that device known to systemd in the first place? At least I think that's what georges suggested.

Which means udev shouldn't be needed for flatpak to work.

@razze works fine, i have the openswitcher application that is packaged on Alpine and Debian and it ships some custom udev rules to allow plugdev users to access it. Systemd is not really relevant here unless they invented something new again

razze Jun 4, 2023

@martijnbraam I think the idea is to add the device here https://github.com/systemd/systemd/tree/main/hwdb.d and if that's not possible something like this https://github.com/systemd/systemd/pull/22730

systemd/hwdb.d at main · systemd/systemd

The systemd System and Service Manager . Contribute to systemd/systemd development by creating an account on GitHub.

GitHub

https://floss.social/@sonny/110483044274568833

Sonny Jun 4, 2023

@martijnbraam

Sounds like what we need is a proper API and user defined per app/device permissions.

Discussion started here https://github.com/flatpak/xdg-desktop-portal/issues/227

Sonny (@[email protected])

To people who keep picking a specific app to "demonstrate" that the Flatpak sandbox is broken: This is called cherry picking. Nobody claimed the Flatpak sandbox was a magical solution. For certain things apps need upstream support, but hey everyone benefits from it! • We get proper and secure desktop APIs, yes also non Flatpak • Apps become more secure over time • More control to user over permissions and data • No random files in ~ #Linux #Flatpak

FLOSS.social

Sonny Jun 4, 2023

@martijnbraam

My response https://floss.social/@sonny/110482367773271228

Sonny (@[email protected])

Instead of complaining about app developers and Flatpak, maybe it's time Linux based OS developers focus on moving forward with things they are responsible for: * Home encryption * Authenticated boot * Read-only / * Atomic upgrades It's 2023 and I still can't install and leave Linux unattended to family members and friends. Flatpak solves real problem and it only gets better with time because it is the right infrastructure for apps on Linux. #Flatpak #Linux

FLOSS.social

Haelwenn /элвэн/

Jun 4, 2023

@martijnbraam 100% this with both my developer and packager hats, specially as becoming your own distro just for your software is a pain in the ass while having a proper distro just allows to delegate the work of maintaining the dependencies or even just share it cleanly between your own applications.

418 I'm a Teapot Jun 4, 2023

@martijnbraam one wonders why we bother with shared libraries anymore. since we're obviously well past the point of caring about ram and disk space, most of what flatpak tries to accomplish would be more easily done just building a static binary. then people who run the software can be suspicious of binaries in the traditional way because software does stuff, and not given a false sense of security by a weird packaging and distribution system...

Speaktrap Jun 4, 2023

@chainik @martijnbraam There should never be point of not caring about RAM and storage
Shared libraries and much lower disk usage is what I love about GNU vs. Windows not fitting 50GB and beyond system partition

@speaktrap @chainik even statically linked software is not nearly as space inefficient as flatpaks are.

usia Jun 4, 2023

@martijnbraam @speaktrap @chainik Thats actually the main problem I got with flatpak. I used them the first time I run postmarketos on my 64G Oneplus 6 and had space issues realy quickly because I installed a few flatpaks.

Samæ Jun 4, 2023

@chainik @martijnbraam

> one wonders why we bother with shared libraries anymore.

First thing that comes to mind is that I wouldn't be fond a world where libssl (and friends) exists in 50 versions on my system, because each and every package that need it bundle it. I'm not saying this is an end-all argument for anything, just pointing out that it's not a silver bullet.

Samæ Jun 4, 2023

@chainik @martijnbraam

And second thought, more meta, is that collaboration takes work and effort, but provides long term benefits in my experience.

Shifting to a world where application developers need to care less about collaborating (eyes to Chromium for example) is maybe great for the short term (read this as great for prototyping ideas quickly), but just not that great for the longer term (space efficiency, security issues, bug fixing). Free software at least should be a common ownership to all.

Personally, I look to nix as a good way forward for dealing with this divide between "all for devs", or "all for the community". Dependencies will be shared automatically between packages without any involvement of the packager person.

@martijnbraam why not replace flatpak with nix? :)

@j0 you don't have to replace anything. As long as you don't write software that is hardcoded to one platform it can be packaged anywhere :)

I gladly take bug reports from Nix users, they have made several of my codebases a lot better

@martijnbraam i mean why cant nix replace flatpak as the cross-distro packaging standard :) it has a great community already packaging most software and nix could be a part of a lot of distro's immutability (silverblue, vanillaos, whatever ubuntus doing, etc)

WofFS Jun 4, 2023

@j0 @martijnbraam you have to solve runtime issues (OpenGL)

@[email protected] what about https://github.com/guibou/nixGL ?

GitHub - guibou/nixGL: A wrapper tool for nix OpenGL application

A wrapper tool for nix OpenGL application. Contribute to guibou/nixGL development by creating an account on GitHub.

GitHub

WofFS Jun 4, 2023

@j0 exactly this

@j0 or instead of trying to replace everything with $singlething just let distro maintainers do their job?

@martijnbraam yeah thats fair :p

im coming at it with the angle of "this would be so much better for this purpose!" but im not sure if flatpaks solve a problem that needs solving?

Reto Jun 4, 2023

@martijnbraam @j0 I mean, that'd be nice except that this means you need to limit yourself to stuff from +5 years or so as you'd need to cater to Debian stable or even oldstable.

And that's nuts, considering that I want to use the nice apis in the newer version of libraries

@reto @j0 people aren't on debian oldstable just to get software with the latest APIs...

Reto Jun 4, 2023

@martijnbraam @j0 sure, but then you end up with people opening bugs for very old versions of my stuff, bugs which may already have been fixed in later versions.

And that's not just theory, plenty of cases where this happens so much that the devs told Debian to pull the package from their repo or simply autoclose bugs from Debian users unless it's the latest

glorp Jun 4, 2023

@martijnbraam I really disagree with this post, but it's still a good discussion to be had. While there are some issues with flatpak still, especially concerning unpacked vulnerabilities in statics dependencies, the flatpak developers have shown commitment in addressing the problems in one way or another. The fact of the matter is: there is way too much great software out there for a distro maintainer to reasonably package, and flatpak helps with that problem immensely.

If it means that developers no longer have to care for distro specific bugs in most cases I see it as an absolute win. Sure, straight up asking packagers to not package it is a bit extreme, but I can also understand it if they were getting spammed with issues for packaging methods and distros they explicitly do not support. In the end, most OSS developers do it in their free time and for the community, and anything that makes the tedious packaging part easier for them in a reasonably secure and compatible way is a good thing.

Jiří Eischmann

Jun 5, 2023

@martijnbraam "even if it's audited it's ridiculously easy to push a new more evil version to Flathub since practically only the first version of the app you push is thorougly looked at by the Flathub maintainers"

Well, this is what you can do in most if not all distros. I maintain a couple of desktop apps in Fedora and they receive no feedback and scrutiny when I update them. They could, but in the reality they don't.