Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[JimH]

" ... Now, leaders from the GNOME Foundation and KDE Foundation are ... building an app store on top of Flatpak, a universal Linux software deployment and package management program. "

https://www.zdnet.com/article/linux-desktop-leaders-unite-behind-flathub-app-store-heres-why/

[BryanC]

Meanwhile Canonical is abandoning Flatpak in favor of snaps . Looks like the One App Store to Rule Them All will be the next Linux fracture point. Hopefully our NixOS overlords can save us.

[JimH]

We'll step in and fix that.

[Hendrik]

Meanwhile Canonical is abandoning Flatpak in favor of snaps .

No surprise there, because Snap is owned by Canonical, and they have a vested interest into their solution being used. Its a corporate project, rather then a community one like Flatpak.

[mwillems]

Just anecdotally, I think flatpak uptake on the dev side is much more significant than snap uptake (i.e. flatpak seems to be "winning"). 

I've seen a lot of FOSS software that offers official flatpaks, and many programs are suggesting a flatpak install as the recommended or default method of installation.  Flatpaks are also integrated into, for example, the GUI "software store" that ships by default with large distros like Debian and Fedora.  I generally prefer distro packages, but I've installed a few flatpaks where there was no package for my distro, because the devs made a flatpak available, and it worked fine.

Snap adoption seems much lower, and I've never seen software that actually recommended installing it via snap (although I'm sure there's some out there somewhere). It seems like an "only on Ubuntu" type solution, which makes sense for the reasons Hendrik mentioned, but is bad news for a supposedly universal packaging format. 

[Awesome Donkey]

I personally try to avoid using Snap or Flatpak (or AppImage) because of the potential security issues with sandboxing, e.g. with Flatpak https://madaidans-insecurities.github.io/linux.html#flatpak

If I was going to choose one, it'd probably be AppImage. But even then if given the choice, I'd avoid all of them.

[Hendrik]

A native package would have zero sandboxing and generally always full access to your system.

[danrien]

I personally try to avoid using Snap or Flatpak (or AppImage) because of the potential security issues with sandboxing, e.g. with Flatpak https://madaidans-insecurities.github.io/linux.html#flatpak

If I was going to choose one, it'd probably be AppImage. But even then if given the choice, I'd avoid all of them.

That's a good read, thanks for sharing it . I personally like Flatpaks quite a bit, and I use Flatseal to manage permissions: https://flathub.org/apps/details/com.github.tchx84.Flatseal. It would be nice if the permissions that are requested would be asked for ahead of time when installing, but in my opinion, it's better to know what permissions are used rather than having no idea what the application has access to at all, which is the state of affairs if you're installing arbitrary binaries (or AppImages), correct?

[cheaha]

This REALLY needs to happen.  Flatpak or appimage are capable of extending all necessary permissions for end users to be able to use MediaCenter in linux with a turnkey install.  Your current solution is going to become MORE and MORE problematic as Linux is shifting to an immutable / atomic landscape.  JRiver will finally be able to be listed in the Linux application stores and I'm sure more and more people will install it.  I have been a paid user for years and have just completed a migration from Windows to Bazzite/Bluefin fedora myself.  I was able to make MC work, but it was a gigantic pain.  PLEASE take the time to at least reach out to the linux community and see if you can get some help to 'fix' MC distribution for Linux.  It will mean MORE sales for you and a win for everyone else.

[Awesome Donkey]

Bob has looked into it a few times, and if I recall correctly none of them are adequate enough for Media Center due to its requirement for access to hardware and whatnot.

[cheaha]

https://docs.flatpak.org/en/latest/sandbox-permissions.html#

--share=network - Access the network
--socket=pulseaudio - Access to PulseAudio, includes sound input (mic), sound output/playback, MIDI and ALSA sound devices in /dev/snd

https://docs.flatpak.org/en/latest/sandbox-permissions.html#usb-portal

Since 1.5.11.

Sandboxed access to individual USB devices can be controlled by portals. Flatpak allows specifying enumerable USB devices to allow access.

Like --device=usb, this is just about accessing the raw USB device, that needs libusb (or equivalent). By using the portal, you can restrict which device can be requested (enumerable) and then request an explicit permission to access. For example, if you run a scanner driver, there is no reason for USB security devices to be accessible.

[bob]

Bob has looked into it a few times, and if I recall correctly none of them are adequate enough for Media Center due to its requirement for access to hardware and whatnot.

Off the top of my head, things that need to work before it's even worth more time looking into this again.

Direct access to ALSA devices not just via Pulseaudio.
Access to video hardware via OpenGL.
Direct filesystem access for iNotify handles.
Direct access to CD devices via /dev/sr0

I'm sure there are some I'm missing...

[Awesome Donkey]

If this was ever going to happen, I'd prefer having an AppImage over a Flatpak or Snap - I'm personally not a fan of the latter two and prefer AppImages when possible.