Gregory's Server|
45 comments
 @tripleo @martijnbraam the thing is, we as application devs have had distro maintainers break and limit apps for years. Specifically using the correct/patched ffmpeg version seems challenging. I remember Debian completely breaking it for e.g. which is a bad look for the app on that platform. @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. @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 @martijnbraam @dbrgn or even threatening distributions legally because they packaged the software (including artwork and name)  @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?    @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....
 @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.  @sonny @whynothugo But don't you see that the model breaks there? Portals are not a hard dependency of flatpak. This means portals are either a hard or soft system dependency of individual flatpak packages. Regardless of what's the case, it's handled poorly, because it's possible to install those packages without having portals and if that was intended then they just don't fail very gracefully. Now this is totally fixable. But only if it is acknowledged. @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?) @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. @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) @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 @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 @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 Sounds like what we need is a proper API and user defined per app/device permissions. https://floss.social/@sonny/110483044274568833 Discussion started here https://github.com/flatpak/xdg-desktop-portal/issues/227  @sonny @martijnbraam "sounds like what we need is [new wheel to reinvent but worse]", sounds like flatpak to me. The idea of flatpak is fundamentally broken. In your sentence, replace "Flatpak" with "Wayland" and you get the main argument of anti-wayland people. Let's keep the conversation practical 🙏 What's wrong with platform APIs with better security and user control ? @sonny @martijnbraam platform APIs with better security and control sounds great. What's wrong is the implementation @drewdevault there is no implementation for USB / devices. I assume you mean existing platform APIs. Beside a few bugs and missing features, is there something fundamentally broken about how portals work? @sonny @martijnbraam wow your response addresses none of Martin's points and has nothing to do with flatpak at all @drewdevault that was a response to the blog title. I addressed some of the points in other toots. Check my posts and replies.  @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.
@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... @chainik @martijnbraam There should never be point of not caring about RAM and storage @speaktrap @chainik even statically linked software is not nearly as space inefficient as flatpaks are. @martijnbraam You raise good points about security updates, it didn’t occur to me earlier that it can be a burden on the developers. On the other hand this gives distribution maintainers more time to work on core features. @martijnbraam although I hadn't thought of the point that flatpak is just another distribution with a not very feature rich package manager, and that much is pretty fair. It's just that there currently aren't any better solutions other than nix, which is way complicated for most users. |
@martijnbraam Ah, piece on earth