4 ms·

"Case in point: the prevalence of using containers to run software without having to deal with conflicts created by trying to intermingle everyone's dependencie

"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.
    - Annatar 8y ago
      You might have read it, but you didn’t understand it, and the reason you didn’t understand it is because you don’t understand the concepts behind UNIX. No matter; here is your next stop: “The art of UNIX programming” ...punch that into a search engine, read the book. Then we shall continue.
      - AnIdiotOnTheNet 8y ago
        I understand the concepts just fine. They're from the 1970s, and probably made more sense then, but it isn't the 70s anymore. Hell, the people who made it moved on and improved it with Plan9 and even that was decades ago. Stop treating UNIX and posix like they're some kind of religion.
        Annatar 8y ago
        If you had understood them, you wouldn’t have made the statements you made. The delineation between /opt, /var/opt and /etc/opt is intentional: when the content in /opt and /etc/opt is packaged, only /var/opt/application needs to be backed up because that is the variable portion, the data. There are other factors like the linker mapping and ABI versioning consumed by the runtime linker as well as a separate stack of shared object libraries that play into this scheme, since except for libc and libstdc++ the libraries used with the OS aren’t supposed to be linked with. That’s how I can see you haven’t grasped the enirety of the subject matter at hand, which is why you were told to go read some more. Packing each application in her own directory with her own libraries might be convenient, but it’s dumb because of all the library code duplication, storage consumption and the nightmare which will ensue come time to patch the software. These kinds of stupidities are reserved for Microsoft®️ Windows®️ but have no place on UNIX®️ where operational maintainability and stability are the highest of priorities. I’m running infrastructure across datacenters here, not putzing around with a lone application. My worries are ever so slightly broader than concerns of individual lone desktop PC developers with only convenience in mind.

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.
  - Annatar 8y ago
    You might have read it, but you didn’t understand it, and the reason you didn’t understand it is because you don’t understand the concepts behind UNIX. No matter; here is your next stop: “The art of UNIX programming” ...punch that into a search engine, read the book. Then we shall continue.
    - AnIdiotOnTheNet 8y ago
      I understand the concepts just fine. They're from the 1970s, and probably made more sense then, but it isn't the 70s anymore. Hell, the people who made it moved on and improved it with Plan9 and even that was decades ago. Stop treating UNIX and posix like they're some kind of religion.
      - Annatar 8y ago
        If you had understood them, you wouldn’t have made the statements you made. The delineation between /opt, /var/opt and /etc/opt is intentional: when the content in /opt and /etc/opt is packaged, only /var/opt/application needs to be backed up because that is the variable portion, the data. There are other factors like the linker mapping and ABI versioning consumed by the runtime linker as well as a separate stack of shared object libraries that play into this scheme, since except for libc and libstdc++ the libraries used with the OS aren’t supposed to be linked with. That’s how I can see you haven’t grasped the enirety of the subject matter at hand, which is why you were told to go read some more. Packing each application in her own directory with her own libraries might be convenient, but it’s dumb because of all the library code duplication, storage consumption and the nightmare which will ensue come time to patch the software. These kinds of stupidities are reserved for Microsoft®️ Windows®️ but have no place on UNIX®️ where operational maintainability and stability are the highest of priorities. I’m running infrastructure across datacenters here, not putzing around with a lone application. My worries are ever so slightly broader than concerns of individual lone desktop PC developers with only convenience in mind.