7 ms·

I recommend just shipping everything you need with your app, either manually or using AppImage. Flatpack is, more or less, just a bad package management.. tech

by gens 5y ago

I recommend just shipping everything you need with your app, either manually or using AppImage. Flatpack is, more or less, just a bad package management.. technology.

kaba0 5y ago
Nah, AppImage still won’t run on all distros. The only thing I think actually solves packaging is nix.
- alvarlagerlof 5y ago
  And AppImage integrates poorly with desktops.
  - southerntofu 5y ago
    How so? Double-clicking an AppImage from a specific folder is not user-hostile (that's a common pattern across desktop systems), and the blogpost specifically points to appimaged and AppImageLauncher as solutions for full desktop integration.
  - gens 5y ago
    Desktops integrate poorly with desktops.
    - ahartmetz 5y ago
      What do you mean? When I think of "...integrate poorly with desktops", I think of Electron apps. These also have a Flatpak-like distribution (but not security) model. And a "best effort" integration model. Basically, whatever is possible without lifting too much of a finger.
      - gens 5y ago
        When i think of "desktop integration", i think about drag and drop not working between `ark` (a QT program) and `thunar` (a GTK program), and i think of folk writing blog posts about window theming. (there's also notifications, icons, etc, blablabla, that keeps getting worse (freedesktop is, that is)) To be honest, i don't care much about how programs look. But i do know many people do care.
- krkoch 5y ago
  Hm, I've some problems with nix and desktop apps that needs opengl or similar machine-specific libraries. There are some hacks, and I also think nix comes very close to a good solution, but it's not 100% yet.
  - kaba0 5y ago
    That’s mostly due to video drivers not being under nix’s control deliberately (if packages would depend on them as well, instead of a stub, there would be exponentially more build for each driver). On nixos this is solved by a specifically-placed stub, while it will be distro specific elsewhere, so it may not work for a random distro (that’s where “hacks” come into the picture, choosing a non-nixos distro specific lib as the stub and it will work just fine)
- deleted 5y ago
  [deleted]
- tomberek 5y ago
  Nix seems to be the only approach that has a chance, but having good fundamentals isn’t enough. The effort to improve the UX and usability is underway. I’m working on it; are there use-cases or “blow your socks off” demos that would be compelling to help convince developers and application writers?
deleted 5y ago
[deleted]
WastingMyTime89 5y ago
You are replying to a comment explaining to you why Flatpak actually works with a dismissive sentence implying it's just a bad technology. Do you have anything substantive justifying your opinion? From what I have seen, most of the opposition to Flatpak comes from the same place that the one to systemd: fear of change. Despite being centered around technology, a very vocal part of the Linux community seems to be extremely conservative.
- kayodelycaon 5y ago
  > Despite being centered around technology, a very vocal part of the Linux community seems to be extremely conservative. A lot of the vocal people who pick linux are people who want complete control over their systems. Things like wayland, systemd, and flatpak take away some of that control.
  - derefr 5y ago
    How so? I feel like this is just unfamiliarity / resistance to learning. It's not like these new tools prevent you from accessing their internals. The internals are all still "right there." They just have internals that have been engineered for efficiency over composability or observability. For example, journald. People know and understand "rotated-gzipped text .log files in a /var/log directory." People don't know, but more importantly, don't want to learn, this: https://systemd.io/JOURNAL_FILE_FORMAT/ https://systemd.io/JOURNAL_FILE_FORMAT/. It's a simple format, that makes perfect engineering sense as a format optimized for the goals it's trying to accomplish. But it's not text — not the thing a greybeard sysadmin has spent the last 40 years working with — so it's "hard." Instead of just learning this format and writing tools to interface with it, people instead think of this data as being impossible to access, somehow "locked away" behind journald / journalctl, as if there were some kind of DRM put into your OS prevent you from accessing your own log data. As it happens, though, journalctl already builds in support for manipulating this data with POSIXy text-based tools — getting your journal as JSON is one `journalctl -o export` away. But nobody knows about these features (I only just learned about it now, from the link above!), because nobody talks about these features, because the tooling already solves 99% of the real-world problems people encounter, and so it's very rare to actually need to script against the journal. And if you are in that 1% use-case, maybe you're e.g. engineering a distributed log-ingest system for efficiency; in which case you wouldn't use `journalctl -o export` anyway, but would rather link to journald's C API to parse the journal directly, because that's what's most efficient, even if it's less convenient/UNIXy. ----- This is similar to e.g. how people pushed back against SPDY/HTTP2.0 for being a "less debuggable" protocol, just because it's binary rather than text-based. Of course, it's extremely rare that anyone needs to actually debug the transport, rather than debugging their own application-layer protocol they've built on the transport. And because every server and client that speaks HTTP2 still also speaks HTTP1, every application-layer protocol flowing over these links can just be debugged using HTTP1 messages. But even if you have that 1% use-case where you need to debug the transport, there are simple POSIX-pipeline-y tools to bijectively map the binary wire representation to a text-based one. But again, when you hit that 1% of use-cases, you're probably a professional doing something weird, such that you probably want to pull out WireShark to analyze the complete nested app-in-HTTP2-in-TLS-in-TCP-in-IP-in-Ethernet packet capture in its original binary form. And so, even though those bijective HTTP2-to-HTTP1 observability tools do exist, nobody thinks they do, because nobody talks about them, because everybody with the 1% use-case is likely solving a large-scope problem for which the simple UNIXy solution is "underpowered."
tapoxi 5y ago
My experience with AppImages is fine, but I prefer Flatpaks because they can be updated with a remote. My installs of Signal and Firefox are with Flatpaks and GNOME Software transparently handles updating both.
- mceachen 5y ago
  FWIW, PhotoStructure has an AppImage edition and it can upgrade automatically in-place. (There's also a docker image, a macOS DMG, a Windows installer, and other editions as well--and yes, you can configure any edition to _not_ upgrade automatically if you prefer).
  - tapoxi 5y ago
    I'm less knowledgeable about AppImages, but your download link implies it's for Ubuntu only? I'm a Fedora user.
    - mceachen 5y ago
      It _should_ work just fine. I have several Fedora users (because they emailed me, not because of any analytics: nothing "phones home" with usage, but I do use Sentry for error reporting, and that can be disabled). If you see any errors, please email me (support@photostructure), post to the forum, or ping me on discord (links to those are in the footer of every page on photostructure.com).
- Scramblejams 5y ago
  I often avoid Flatpaks because the permissions are so frequently wrong or not what I need. For example, you mentioned Signal. I stopped using the Flatpak because of this: https://github.com/flathub/org.signal.Signal/issues/181 https://github.com/flathub/org.signal.Signal/issues/181
  - tapoxi 5y ago
    It looks like that problem is fixed with Flatpak override and not installing the Flatpak with root? This is also probably because the Signal Flatpak is community developed on Flathub from Signal's .deb, they're not building Signal with Flatpak in mind. Mozilla provides an official Flatpak release of Firefox.

by gens 5y ago

I recommend just shipping everything you need with your app, either manually or using AppImage. Flatpack is, more or less, just a bad package management.. technology.

kaba0 5y ago

Nah, AppImage still won’t run on all distros. The only thing I think actually solves packaging is nix.

alvarlagerlof 5y ago
And AppImage integrates poorly with desktops.
- southerntofu 5y ago
  How so? Double-clicking an AppImage from a specific folder is not user-hostile (that's a common pattern across desktop systems), and the blogpost specifically points to appimaged and AppImageLauncher as solutions for full desktop integration.
- gens 5y ago
  Desktops integrate poorly with desktops.
  - ahartmetz 5y ago
    What do you mean? When I think of "...integrate poorly with desktops", I think of Electron apps. These also have a Flatpak-like distribution (but not security) model. And a "best effort" integration model. Basically, whatever is possible without lifting too much of a finger.
    - gens 5y ago
      When i think of "desktop integration", i think about drag and drop not working between `ark` (a QT program) and `thunar` (a GTK program), and i think of folk writing blog posts about window theming. (there's also notifications, icons, etc, blablabla, that keeps getting worse (freedesktop is, that is)) To be honest, i don't care much about how programs look. But i do know many people do care.
krkoch 5y ago
Hm, I've some problems with nix and desktop apps that needs opengl or similar machine-specific libraries. There are some hacks, and I also think nix comes very close to a good solution, but it's not 100% yet.
- kaba0 5y ago
  That’s mostly due to video drivers not being under nix’s control deliberately (if packages would depend on them as well, instead of a stub, there would be exponentially more build for each driver). On nixos this is solved by a specifically-placed stub, while it will be distro specific elsewhere, so it may not work for a random distro (that’s where “hacks” come into the picture, choosing a non-nixos distro specific lib as the stub and it will work just fine)
deleted 5y ago
[deleted]
tomberek 5y ago
Nix seems to be the only approach that has a chance, but having good fundamentals isn’t enough. The effort to improve the UX and usability is underway. I’m working on it; are there use-cases or “blow your socks off” demos that would be compelling to help convince developers and application writers?

deleted 5y ago

[deleted]

WastingMyTime89 5y ago

You are replying to a comment explaining to you why Flatpak actually works with a dismissive sentence implying it's just a bad technology. Do you have anything substantive justifying your opinion? From what I have seen, most of the opposition to Flatpak comes from the same place that the one to systemd: fear of change. Despite being centered around technology, a very vocal part of the Linux community seems to be extremely conservative.

kayodelycaon 5y ago
> Despite being centered around technology, a very vocal part of the Linux community seems to be extremely conservative. A lot of the vocal people who pick linux are people who want complete control over their systems. Things like wayland, systemd, and flatpak take away some of that control.
- derefr 5y ago
  How so? I feel like this is just unfamiliarity / resistance to learning. It's not like these new tools prevent you from accessing their internals. The internals are all still "right there." They just have internals that have been engineered for efficiency over composability or observability. For example, journald. People know and understand "rotated-gzipped text .log files in a /var/log directory." People don't know, but more importantly, don't want to learn, this: https://systemd.io/JOURNAL_FILE_FORMAT/ https://systemd.io/JOURNAL_FILE_FORMAT/. It's a simple format, that makes perfect engineering sense as a format optimized for the goals it's trying to accomplish. But it's not text — not the thing a greybeard sysadmin has spent the last 40 years working with — so it's "hard." Instead of just learning this format and writing tools to interface with it, people instead think of this data as being impossible to access, somehow "locked away" behind journald / journalctl, as if there were some kind of DRM put into your OS prevent you from accessing your own log data. As it happens, though, journalctl already builds in support for manipulating this data with POSIXy text-based tools — getting your journal as JSON is one `journalctl -o export` away. But nobody knows about these features (I only just learned about it now, from the link above!), because nobody talks about these features, because the tooling already solves 99% of the real-world problems people encounter, and so it's very rare to actually need to script against the journal. And if you are in that 1% use-case, maybe you're e.g. engineering a distributed log-ingest system for efficiency; in which case you wouldn't use `journalctl -o export` anyway, but would rather link to journald's C API to parse the journal directly, because that's what's most efficient, even if it's less convenient/UNIXy. ----- This is similar to e.g. how people pushed back against SPDY/HTTP2.0 for being a "less debuggable" protocol, just because it's binary rather than text-based. Of course, it's extremely rare that anyone needs to actually debug the transport, rather than debugging their own application-layer protocol they've built on the transport. And because every server and client that speaks HTTP2 still also speaks HTTP1, every application-layer protocol flowing over these links can just be debugged using HTTP1 messages. But even if you have that 1% use-case where you need to debug the transport, there are simple POSIX-pipeline-y tools to bijectively map the binary wire representation to a text-based one. But again, when you hit that 1% of use-cases, you're probably a professional doing something weird, such that you probably want to pull out WireShark to analyze the complete nested app-in-HTTP2-in-TLS-in-TCP-in-IP-in-Ethernet packet capture in its original binary form. And so, even though those bijective HTTP2-to-HTTP1 observability tools do exist, nobody thinks they do, because nobody talks about them, because everybody with the 1% use-case is likely solving a large-scope problem for which the simple UNIXy solution is "underpowered."

tapoxi 5y ago

My experience with AppImages is fine, but I prefer Flatpaks because they can be updated with a remote. My installs of Signal and Firefox are with Flatpaks and GNOME Software transparently handles updating both.

mceachen 5y ago
FWIW, PhotoStructure has an AppImage edition and it can upgrade automatically in-place. (There's also a docker image, a macOS DMG, a Windows installer, and other editions as well--and yes, you can configure any edition to _not_ upgrade automatically if you prefer).
- tapoxi 5y ago
  I'm less knowledgeable about AppImages, but your download link implies it's for Ubuntu only? I'm a Fedora user.
  - mceachen 5y ago
    It _should_ work just fine. I have several Fedora users (because they emailed me, not because of any analytics: nothing "phones home" with usage, but I do use Sentry for error reporting, and that can be disabled). If you see any errors, please email me (support@photostructure), post to the forum, or ping me on discord (links to those are in the footer of every page on photostructure.com).
Scramblejams 5y ago
I often avoid Flatpaks because the permissions are so frequently wrong or not what I need. For example, you mentioned Signal. I stopped using the Flatpak because of this: https://github.com/flathub/org.signal.Signal/issues/181 https://github.com/flathub/org.signal.Signal/issues/181
- tapoxi 5y ago
  It looks like that problem is fixed with Flatpak override and not installing the Flatpak with root? This is also probably because the Signal Flatpak is community developed on Flathub from Signal's .deb, they're not building Signal with Flatpak in mind. Mozilla provides an official Flatpak release of Firefox.