3 ms·

> Minus: yet another proprietary package manager, bypassing the operating system's software management subsystem (operational maintainability) False. Nimble in

> Minus: yet another proprietary package manager, bypassing the operating system's software management subsystem (operational maintainability) False. Nimble installs packages only in the current user's home. It's one of the few package managers that does not encourage the dreadful "sudo pip/npm/... install"

dom96 8y ago
oh, guess I shouldn't implement that[1] then :) To be honest, now that I'm thinking about it again, I think you're totally right. 1 - https://github.com/nim-lang/nimble/issues/80 https://github.com/nim-lang/nimble/issues/80
- Annatar 8y ago
  If you implement that, you instantaneously take away the ability to deploy applications through OS's automated deployment (like Kickstart, Jumpstart, or AutoYaST) and you create more work for every system engineer in existence because they have to finish your work for you, namely integration of your software (nim language) into the OS. For every platform nim supports, native operating system package(s), delivering into /opt/nim (and system-wide configuration into /etc/opt/nim) should be provided. This is not some whim, it's a formal system engineering specification. See LSB FHS, /opt, /etc/opt and /var/opt sections, or the illumos filesystem(5) manual page for the same. (Why aren't you as a third party supposed to deliver software into /usr as you intend in that Github issue?) If you do not do it this way, it will impede adoption because it's one thing for a developer to play around in a language and another for a system engineer to make it operational: system engineers' time is usually in extremely short supply, and if they have to package your language for you, they could easily just move on to writing software in a different language that they can mass-provision natively, and nim will stay an underdog. Operational maintainability is the end goal, means mass deployment without extra code or software like Docker, only using native subsystems. Sooner or later things must go into production. Never bypass OS packaging. Unless you are an OS vendor, never deliver anywhere into /usr, not even /usr/local.
  - debiandev 8y ago
    You seem to be confusing /opt and /usr. > native operating system package(s), delivering into /opt/nim (and system-wide configuration into /etc/opt/nim) should be provided No, native package managers should install binaries in /usr/[s]bin and libraries under /usr > Never bypass OS packaging. Unless you are an OS vendor, never deliver anywhere into /usr, not even /usr/local. +1
    - Annatar 8y ago
      "You seem to be confusing /opt and /usr." It is very unfortunate for me that it seems this way to you, but as someone doing precisely this kind of engineering for almost three decades, I can assure you that this is not the case. "native package managers should install binaries in /usr/[s]bin and libraries under /usr" Unless one is an operating system vendor (like Joyent, redhat, SuSE, Debian, Canonical, CentOS, ...) third party and unbundled applications must never be installed into /usr: by doing so, one risks destroying or damaging systems in production in the case where the vendor decides to deliver their own version of the same software, and the vendor's upgrade overwrites one's own software and configuration. Long story short: don't deliver your unbundled software into someone else's space. /usr belongs to an OS vendor and to that vendor alone (vendor in this context also includes volunteer operating system projects one is not a part of). /opt, /etc/opt and /var/opt exist for a reason. Refer to the filesystem(5) manual page on illumos and the LSB FHS specification, sections 3.13., 3.7.4. and 5.12.: http://illumos.org/man/5/filesystem http://illumos.org/man/5/filesystem http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#optAddonApplicationSoftwarePackages http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#opt... http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#etcoptConfigurationFilesForOpt http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#etc... http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#varoptVariableDataForOpt http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#var... section 3.13.2., Requirements, explicitly states: No other package files may exist outside the /opt, /var/opt, and /etc/opt hierarchies except for those package files that must reside in specific locations within the filesystem tree in order to function properly. For example, device lock files must be placed in /var/lock and devices must be located in /dev. http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#requirements7 http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#req...
Annatar 8y ago
It's not false: installing any kind of software without using OS packaging, even in one's home directory makes it a hack. It's working for you in your home directory; what if it now needs to work for everyone, or if it needs to be deployed without any human interaction whatsoever?
- debiandev 8y ago
  Nimble is used only at build time for libraries and few tools. Packaging binaries for production is not its use-case.
  - Annatar 8y ago
    Ever worked at a financial, military or an intelligence institution? For example, what if the system where the software must be built has no connection to the internet? Resisting creation of operating system packages, even for dependencies is silly, because doing so is not hard at all: all it requires is reading some documentation, but the knowledge gained can be reused over and over and over again for the rest of one's career. Learning different OS packaging systems is an investment which pays hefty dividends.
    - debiandev 8y ago
      I fully agree. I worked on systems that are not connected to the Internet for security reasons and receive "offline" security updates using distribution packages. It's also very common in security-sensitive environments to give blanket approvals to specific distributions and prohibit cowboy deployments. (I'm not sure why you are replying to my post)

dom96 8y ago

oh, guess I shouldn't implement that[1] then :) To be honest, now that I'm thinking about it again, I think you're totally right. 1 - https://github.com/nim-lang/nimble/issues/80 https://github.com/nim-lang/nimble/issues/80

Annatar 8y ago
If you implement that, you instantaneously take away the ability to deploy applications through OS's automated deployment (like Kickstart, Jumpstart, or AutoYaST) and you create more work for every system engineer in existence because they have to finish your work for you, namely integration of your software (nim language) into the OS. For every platform nim supports, native operating system package(s), delivering into /opt/nim (and system-wide configuration into /etc/opt/nim) should be provided. This is not some whim, it's a formal system engineering specification. See LSB FHS, /opt, /etc/opt and /var/opt sections, or the illumos filesystem(5) manual page for the same. (Why aren't you as a third party supposed to deliver software into /usr as you intend in that Github issue?) If you do not do it this way, it will impede adoption because it's one thing for a developer to play around in a language and another for a system engineer to make it operational: system engineers' time is usually in extremely short supply, and if they have to package your language for you, they could easily just move on to writing software in a different language that they can mass-provision natively, and nim will stay an underdog. Operational maintainability is the end goal, means mass deployment without extra code or software like Docker, only using native subsystems. Sooner or later things must go into production. Never bypass OS packaging. Unless you are an OS vendor, never deliver anywhere into /usr, not even /usr/local.
- debiandev 8y ago
  You seem to be confusing /opt and /usr. > native operating system package(s), delivering into /opt/nim (and system-wide configuration into /etc/opt/nim) should be provided No, native package managers should install binaries in /usr/[s]bin and libraries under /usr > Never bypass OS packaging. Unless you are an OS vendor, never deliver anywhere into /usr, not even /usr/local. +1
  - Annatar 8y ago
    "You seem to be confusing /opt and /usr." It is very unfortunate for me that it seems this way to you, but as someone doing precisely this kind of engineering for almost three decades, I can assure you that this is not the case. "native package managers should install binaries in /usr/[s]bin and libraries under /usr" Unless one is an operating system vendor (like Joyent, redhat, SuSE, Debian, Canonical, CentOS, ...) third party and unbundled applications must never be installed into /usr: by doing so, one risks destroying or damaging systems in production in the case where the vendor decides to deliver their own version of the same software, and the vendor's upgrade overwrites one's own software and configuration. Long story short: don't deliver your unbundled software into someone else's space. /usr belongs to an OS vendor and to that vendor alone (vendor in this context also includes volunteer operating system projects one is not a part of). /opt, /etc/opt and /var/opt exist for a reason. Refer to the filesystem(5) manual page on illumos and the LSB FHS specification, sections 3.13., 3.7.4. and 5.12.: http://illumos.org/man/5/filesystem http://illumos.org/man/5/filesystem http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#optAddonApplicationSoftwarePackages http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#opt... http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#etcoptConfigurationFilesForOpt http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#etc... http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#varoptVariableDataForOpt http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#var... section 3.13.2., Requirements, explicitly states: No other package files may exist outside the /opt, /var/opt, and /etc/opt hierarchies except for those package files that must reside in specific locations within the filesystem tree in order to function properly. For example, device lock files must be placed in /var/lock and devices must be located in /dev. http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#requirements7 http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#req...

Annatar 8y ago

It's not false: installing any kind of software without using OS packaging, even in one's home directory makes it a hack. It's working for you in your home directory; what if it now needs to work for everyone, or if it needs to be deployed without any human interaction whatsoever?

debiandev 8y ago
Nimble is used only at build time for libraries and few tools. Packaging binaries for production is not its use-case.
- Annatar 8y ago
  Ever worked at a financial, military or an intelligence institution? For example, what if the system where the software must be built has no connection to the internet? Resisting creation of operating system packages, even for dependencies is silly, because doing so is not hard at all: all it requires is reading some documentation, but the knowledge gained can be reused over and over and over again for the rest of one's career. Learning different OS packaging systems is an investment which pays hefty dividends.
  - debiandev 8y ago
    I fully agree. I worked on systems that are not connected to the Internet for security reasons and receive "offline" security updates using distribution packages. It's also very common in security-sensitive environments to give blanket approvals to specific distributions and prohibit cowboy deployments. (I'm not sure why you are replying to my post)