5 ms·

Yet I still can't compile an app on some arbitrary release of some arbitrary distro and just run the darn exe on another and be 100% sure it will work.

smoldesu 3y ago
On a large enough timescale I don't think you can reasonably expect this on any of this big 3 OSes. From a less macro perspective, I think tools like Appimage and Flatpak will fill that role.
- zer0zzz 3y ago
  On a long enough time scale we are all dead, and Linux doesn't exist. That doesn't mean that in the decades that computer software has to be useful to actual people that things have to suck this badly right now.
  - smoldesu 3y ago
    The "actual people" using Linux on the desktop are not running .so files off the internet. I get what you're saying, but you know it's facetious to pretend that packaging is simple on Mac and Windows too.
    - api 3y ago
      Packaging is fairly simple on Mac and Windows if you use the dev tools for the platform and are not doing things like installing services or drivers or changing OS configuration. Your packaged app will almost always work too. There are not 50 distributions of these OSes.
      - zer0zzz 3y ago
        exactly
    - zer0zzz 3y ago
      > The "actual people" using Linux on the desktop are not running .so files off the internet. They do this all day every day when they use a little something called Steam or when they install Google Chrome. > I get what you're saying, but you know it's facetious to pretend that packaging is simple on Mac and Windows too. It is...
      - account42 3y ago
        > They do this all day every day when they use a little something called Steam Which while (initially) officially only released for a specific Ubuntu version ran on pretty much any up to date distro from day zero.
AnthonyMouse 3y ago
The trouble is you're trying to distribute it as a binary yourself. The there are two traditional ways for distributing software for Linux: 1) The system package manager. It will download a binary from the repository which is the right one for that system. 2) make && make install. This is mostly for software in development that hasn't made it into the package manager yet. It will compile from source and produce a binary for the target system. All the problems are from people trying to do something other than this.
- zer0zzz 3y ago
  That's the problem. The Linux way of distributing apps is wrong for trying to compete with the other consumer platforms. The ChromeOS or electron style of doing things is another story though.
  - AnthonyMouse 3y ago
    What exactly is wrong with it? If you have a stable widely used application suitable for being installed by unsophisticated consumers, have the distributions put it in their package managers. This is hardly any different than consumer mobile platforms that require you to use an app store, except that it isn't actually required, just the thing you ought to do absent a good reason to do otherwise. If you're distributing something sufficiently esoteric or experimental that the package managers won't touch it, your correspondingly sophisticated or adventurous users can compile it from source. We don't need some malware-facilitating norm that encourages users to install opaque binaries from random websites.
  - tripleo1 3y ago
    Alot of you may be looking at it wrong. Each distribution is a different operating system. You cannot package the "same" app for Windows and mac, so why should you be able to package the same application for Debian and Arch, which, even though they run a lot of the same code, have different underlying layers and assumptions?
eternityforest 3y ago
On other platforms people don't even try to support anything but one "distro". You could make an AppImage or snap that would work across pretty much any mainstream non-hobbist-oriented distro, and Snap/AppImages is pretty much the Linux equivalent of EXE. Raspberry Pi OS just moved to NetworkManager and they have PipeWire, which was the last reason I had to deal with less common software stacks, so it seems like stuff is getting more standardized.
- night-rider 3y ago
  +1 AppImages. And the beauty is you can make them portable by creating a folder with the same name as the AppImage and append .home to the end, and boom: portable software. For example image-editor.AppImage image-editor.AppImage.home (folder, all settings are stored there)
  - zer0zzz 3y ago
    Actually, I don't think I've tried AppImage. Does it do static linking or does it do something more similar to flatpak?
    - account42 3y ago
      It's a self-mounting image so closer to flatpak than static linking but without the strict isolation.
- account42 3y ago
  Snaps will not work on anything but Ubuntu. AppImages are just a fancy self-mounting disk image. If you do it right and include all required contents then it will work ~anywhere but you can just as well do that in a .tar.{gz,xz,zstd}/whatever archive.
  - hollerith 3y ago
    >Snaps will not work on anything but Ubuntu. I installed VSCode as a snap on my Fedora install and it worked fine as far as I could tell. This was in Mar 2021, and I chose the snap because code.visualstudio.com/docs/setup/linux said that "Due to the manual signing process and the system we use to publish, the yum repo may lag behind and not get the latest version of VS Code immediately. . . . Updates are automatic and run in the background for the Snap package." (I don't have an opinion on Snap as compared to Flatpak or AppImage or none of the 3.)

smoldesu 3y ago

On a large enough timescale I don't think you can reasonably expect this on any of this big 3 OSes. From a less macro perspective, I think tools like Appimage and Flatpak will fill that role.

zer0zzz 3y ago
On a long enough time scale we are all dead, and Linux doesn't exist. That doesn't mean that in the decades that computer software has to be useful to actual people that things have to suck this badly right now.
- smoldesu 3y ago
  The "actual people" using Linux on the desktop are not running .so files off the internet. I get what you're saying, but you know it's facetious to pretend that packaging is simple on Mac and Windows too.
  - api 3y ago
    Packaging is fairly simple on Mac and Windows if you use the dev tools for the platform and are not doing things like installing services or drivers or changing OS configuration. Your packaged app will almost always work too. There are not 50 distributions of these OSes.
    - zer0zzz 3y ago
      exactly
  - zer0zzz 3y ago
    > The "actual people" using Linux on the desktop are not running .so files off the internet. They do this all day every day when they use a little something called Steam or when they install Google Chrome. > I get what you're saying, but you know it's facetious to pretend that packaging is simple on Mac and Windows too. It is...
    - account42 3y ago
      > They do this all day every day when they use a little something called Steam Which while (initially) officially only released for a specific Ubuntu version ran on pretty much any up to date distro from day zero.

AnthonyMouse 3y ago

The trouble is you're trying to distribute it as a binary yourself. The there are two traditional ways for distributing software for Linux: 1) The system package manager. It will download a binary from the repository which is the right one for that system. 2) make && make install. This is mostly for software in development that hasn't made it into the package manager yet. It will compile from source and produce a binary for the target system. All the problems are from people trying to do something other than this.

zer0zzz 3y ago
That's the problem. The Linux way of distributing apps is wrong for trying to compete with the other consumer platforms. The ChromeOS or electron style of doing things is another story though.
- AnthonyMouse 3y ago
  What exactly is wrong with it? If you have a stable widely used application suitable for being installed by unsophisticated consumers, have the distributions put it in their package managers. This is hardly any different than consumer mobile platforms that require you to use an app store, except that it isn't actually required, just the thing you ought to do absent a good reason to do otherwise. If you're distributing something sufficiently esoteric or experimental that the package managers won't touch it, your correspondingly sophisticated or adventurous users can compile it from source. We don't need some malware-facilitating norm that encourages users to install opaque binaries from random websites.
- tripleo1 3y ago
  Alot of you may be looking at it wrong. Each distribution is a different operating system. You cannot package the "same" app for Windows and mac, so why should you be able to package the same application for Debian and Arch, which, even though they run a lot of the same code, have different underlying layers and assumptions?

eternityforest 3y ago

On other platforms people don't even try to support anything but one "distro". You could make an AppImage or snap that would work across pretty much any mainstream non-hobbist-oriented distro, and Snap/AppImages is pretty much the Linux equivalent of EXE. Raspberry Pi OS just moved to NetworkManager and they have PipeWire, which was the last reason I had to deal with less common software stacks, so it seems like stuff is getting more standardized.

night-rider 3y ago
+1 AppImages. And the beauty is you can make them portable by creating a folder with the same name as the AppImage and append .home to the end, and boom: portable software. For example image-editor.AppImage image-editor.AppImage.home (folder, all settings are stored there)
- zer0zzz 3y ago
  Actually, I don't think I've tried AppImage. Does it do static linking or does it do something more similar to flatpak?
  - account42 3y ago
    It's a self-mounting image so closer to flatpak than static linking but without the strict isolation.
account42 3y ago
Snaps will not work on anything but Ubuntu. AppImages are just a fancy self-mounting disk image. If you do it right and include all required contents then it will work ~anywhere but you can just as well do that in a .tar.{gz,xz,zstd}/whatever archive.
- hollerith 3y ago
  >Snaps will not work on anything but Ubuntu. I installed VSCode as a snap on my Fedora install and it worked fine as far as I could tell. This was in Mar 2021, and I chose the snap because code.visualstudio.com/docs/setup/linux said that "Due to the manual signing process and the system we use to publish, the yum repo may lag behind and not get the latest version of VS Code immediately. . . . Updates are automatic and run in the background for the Snap package." (I don't have an opinion on Snap as compared to Flatpak or AppImage or none of the 3.)