4 ms·

There have been several approaches to distributing applications with their dependencies such as AppImage or most recently Snap (or Application Bundles on the Ma

There have been several approaches to distributing applications with their dependencies such as AppImage or most recently Snap (or Application Bundles on the Mac). For some reason none of them really took of. Ironically the official way of installing LXC and LXD is now through Snap packages.

AnIdiotOnTheNet 8y ago
Indeed there have, and they haven't taken off... in Linux. Which is one of the reasons I think the Linux Desktop is unsalvagable. If the community would rather keep recreating the package manager and never fixing any of its problems as a distribution mechanism than go with the obvious and simple solution, then it is no surprise they have such a small share of the Desktop. Just use folders guys. Mac classic used to essentially do that (it was technically a single file with a resource fork), DOS did that, RiscOS did that, NeXTStep did that and modern MacOS inherited from it and still does that, A lot of Windows applications still work like that even if they don't advertise it, and I'm sure there's a bunch I'm forgetting. Linux Desktop seems like the outlier here, insisting on spreading everything over the file hierarchy and interlocking it all like it's still a server from the 70s.
- yjftsjthsd-h 8y ago
  And then every package comes with its own libraries, which don't get updated and end up with duplicates everywhere. It's the same reason that Linux (the kernel) emphatically refuses to support out of tree drivers. It means that you have to make the effort to package it, yes, but once you've done that you get dependencies essentially for free. And as the end-user, I can update EVERYTHING on my system with one command, rather than the Windows hell of a dozen updaters running in the background constantly.
  - AnIdiotOnTheNet 8y ago
    > And then every package comes with its own libraries Only if they aren't part of the base OS set. This is how basically every operating system except BSD and Linux do things, and they have an order of magnitude more adoption than the Linux Desktop. Hell Android even uses the Linux kernel and has an appstore and still does that. > It's the same reason that Linux (the kernel) emphatically refuses to support out of tree drivers. Well no, that's because they insist that drivers can be better maintained (because it forces them to be open) and don't have to tie their hands supporting an ABI. As an example of the downside of this policy, see nVidia drivers on Linux. Yes, it's a tradeoff, but there are a lot of downsides to package management that its proponents completely ignore. Case in point: the prevalence of using containers to run software without having to deal with conflicts created by trying to intermingle everyone's dependencies, or install up to date software without having to go through some repo, or distributing for multiple distros without having to maintain packages in two dozen repositories. Even Linus distributes with AppImage. Probably just a stupid Windows user.
    - Annatar 8y ago
      "Case in point: the prevalence of using containers to run software without having to deal with conflicts created by trying to intermingle everyone's dependencies," That's a problem on GNU/Linux; it's not a problem on illumos or BSD based operating systems. Don't use GNU/Linux or package 3rd party and unbundled software in /opt, configuration in /etc/opt and configure the software to use /var/opt (as per the FHS specification) and the problem goes away. It's the clueless developer problem, not an OS packaging problem.
      - AnIdiotOnTheNet 8y ago
        Maybe for that particular problem, it still doesn't do anything for many others. For instance, what if I want to install an application on a different disk? In grand UNIX tradition, the scheme you outlined still spreads an application's files all over the tree. I suppose you'll call that a packaging problem too, and I agree: you should package applications as relocatable directories that contain all their non-OS-provided dependencies.
        Annatar 8y ago
        "still spreads an application's files all over the tree" No, only three directories: /opt for application, /etc/opt for configuration, and /var/opt for applications' data. Please read the specification, either FHS[1] or AT&T original[2] from whence FHS came. Good engineers seek out and read specifications before they start any planning and work. When you package applications in this way, only /var/opt needs to be backed up. [1] http://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html http://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html [2] https://smartos.org/man/5/filesystem https://smartos.org/man/5/filesystem
        AnIdiotOnTheNet 8y ago
        Right, so instead of your entire application being in one directory, it is in fact spread across 3 disparate ones. Why not /opt/<APP>/(var|etc)? Would make too much sense I guess. I've read the spec, it's crap. There is no value to following a crap spec.

AnIdiotOnTheNet 8y ago

Indeed there have, and they haven't taken off... in Linux. Which is one of the reasons I think the Linux Desktop is unsalvagable. If the community would rather keep recreating the package manager and never fixing any of its problems as a distribution mechanism than go with the obvious and simple solution, then it is no surprise they have such a small share of the Desktop. Just use folders guys. Mac classic used to essentially do that (it was technically a single file with a resource fork), DOS did that, RiscOS did that, NeXTStep did that and modern MacOS inherited from it and still does that, A lot of Windows applications still work like that even if they don't advertise it, and I'm sure there's a bunch I'm forgetting. Linux Desktop seems like the outlier here, insisting on spreading everything over the file hierarchy and interlocking it all like it's still a server from the 70s.

yjftsjthsd-h 8y ago
And then every package comes with its own libraries, which don't get updated and end up with duplicates everywhere. It's the same reason that Linux (the kernel) emphatically refuses to support out of tree drivers. It means that you have to make the effort to package it, yes, but once you've done that you get dependencies essentially for free. And as the end-user, I can update EVERYTHING on my system with one command, rather than the Windows hell of a dozen updaters running in the background constantly.
- AnIdiotOnTheNet 8y ago
  > And then every package comes with its own libraries Only if they aren't part of the base OS set. This is how basically every operating system except BSD and Linux do things, and they have an order of magnitude more adoption than the Linux Desktop. Hell Android even uses the Linux kernel and has an appstore and still does that. > It's the same reason that Linux (the kernel) emphatically refuses to support out of tree drivers. Well no, that's because they insist that drivers can be better maintained (because it forces them to be open) and don't have to tie their hands supporting an ABI. As an example of the downside of this policy, see nVidia drivers on Linux. Yes, it's a tradeoff, but there are a lot of downsides to package management that its proponents completely ignore. Case in point: the prevalence of using containers to run software without having to deal with conflicts created by trying to intermingle everyone's dependencies, or install up to date software without having to go through some repo, or distributing for multiple distros without having to maintain packages in two dozen repositories. Even Linus distributes with AppImage. Probably just a stupid Windows user.
  - Annatar 8y ago
    "Case in point: the prevalence of using containers to run software without having to deal with conflicts created by trying to intermingle everyone's dependencies," That's a problem on GNU/Linux; it's not a problem on illumos or BSD based operating systems. Don't use GNU/Linux or package 3rd party and unbundled software in /opt, configuration in /etc/opt and configure the software to use /var/opt (as per the FHS specification) and the problem goes away. It's the clueless developer problem, not an OS packaging problem.
    - AnIdiotOnTheNet 8y ago
      Maybe for that particular problem, it still doesn't do anything for many others. For instance, what if I want to install an application on a different disk? In grand UNIX tradition, the scheme you outlined still spreads an application's files all over the tree. I suppose you'll call that a packaging problem too, and I agree: you should package applications as relocatable directories that contain all their non-OS-provided dependencies.
      - Annatar 8y ago
        "still spreads an application's files all over the tree" No, only three directories: /opt for application, /etc/opt for configuration, and /var/opt for applications' data. Please read the specification, either FHS[1] or AT&T original[2] from whence FHS came. Good engineers seek out and read specifications before they start any planning and work. When you package applications in this way, only /var/opt needs to be backed up. [1] http://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html http://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html [2] https://smartos.org/man/5/filesystem https://smartos.org/man/5/filesystem
        AnIdiotOnTheNet 8y ago
        Right, so instead of your entire application being in one directory, it is in fact spread across 3 disparate ones. Why not /opt/<APP>/(var|etc)? Would make too much sense I guess. I've read the spec, it's crap. There is no value to following a crap spec.