4 ms·

Interesting! Minus: yet another proprietary package manager, bypassing the operating system's software management subsystem (operational maintainability) Plus

Interesting! Minus: yet another proprietary package manager, bypassing the operating system's software management subsystem (operational maintainability) Plus: finally a language which compiles to binary executable machine code. Plus: transpiles to multiple "backend" languages (but transpilers incur a performance penalty). Plus: can link with shared object libraries, thus having instantaneous integration choices with an enormous corpus of existing software. Plus: can turn off garbage collection, which is ideal for command line programs designed to be chained with the shell pipe mechanism.

enthus1ast 8y ago
i must admit that i'm not a big fan of nimble (nim's package manager; for a few reasons) but on the other site you have apt, pacman, yum, whatelsenot, afaik most of them are not even able to install two versions of the same library side by side. The situation is so bad that most applications these days are packed with `flatpack` or something else, because of the so broken linux package management... In contrast to eg. npm nimble is superfast.
- eeZah7Ux 8y ago
  > most of them are not even able to install two versions of the same library That's entirely by design. Distributions exist to provide a set of packages that are well tested, and work reliably, together. And then guarantee that such set will stay the same and receive timely security updates for 3 or 5 or more years so that people can reliably use it in production.
  - enthus1ast 8y ago
    and in the real world you do configure; make install then ;) edit: or docker every one i've met so far, uses docker as a kind of "package manager". Database? Oh year use this docker image, elastic search & kibana? shure docker. What they actualy want most of the time is: an easy way to install this stacks, in an non ancient version, where i can actually use the stuff i need to use.
    - Annatar 8y ago
      "and in the real world you do configure; make install then" In the real world, one gets an existing RPM .spec file, edits it for the required source one is about to build, and then runs: rpmbuild --clean -ba software.spec once one has RPM's there is no need for Docker, as multiple applications can be cleanly installed, upgraded or removed on the system, and the entire system can be automatically PXE booted and provisioned by Kickstart without a single line of glue code. Say no to hacking with Docker and make install instead of formal system engineering.
- Annatar 8y ago
  A shared object library is supposed to use linker map files during her creation to declare interface versions, so that the run time linker can request and obtain the correct version of the interface. Like all the traditional UNIX operating environments solved it: no need for multiple versions, one library contains all versions and the run time linker maps in the requested code. See how illumos does it. Search for linker map files.
  - enthus1ast 8y ago
    i will thank you
eeZah7Ux 8y ago
> 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

enthus1ast 8y ago

i must admit that i'm not a big fan of nimble (nim's package manager; for a few reasons) but on the other site you have apt, pacman, yum, whatelsenot, afaik most of them are not even able to install two versions of the same library side by side. The situation is so bad that most applications these days are packed with `flatpack` or something else, because of the so broken linux package management... In contrast to eg. npm nimble is superfast.

eeZah7Ux 8y ago
> most of them are not even able to install two versions of the same library That's entirely by design. Distributions exist to provide a set of packages that are well tested, and work reliably, together. And then guarantee that such set will stay the same and receive timely security updates for 3 or 5 or more years so that people can reliably use it in production.
- enthus1ast 8y ago
  and in the real world you do configure; make install then ;) edit: or docker every one i've met so far, uses docker as a kind of "package manager". Database? Oh year use this docker image, elastic search & kibana? shure docker. What they actualy want most of the time is: an easy way to install this stacks, in an non ancient version, where i can actually use the stuff i need to use.
  - Annatar 8y ago
    "and in the real world you do configure; make install then" In the real world, one gets an existing RPM .spec file, edits it for the required source one is about to build, and then runs: rpmbuild --clean -ba software.spec once one has RPM's there is no need for Docker, as multiple applications can be cleanly installed, upgraded or removed on the system, and the entire system can be automatically PXE booted and provisioned by Kickstart without a single line of glue code. Say no to hacking with Docker and make install instead of formal system engineering.
Annatar 8y ago
A shared object library is supposed to use linker map files during her creation to declare interface versions, so that the run time linker can request and obtain the correct version of the interface. Like all the traditional UNIX operating environments solved it: no need for multiple versions, one library contains all versions and the run time linker maps in the requested code. See how illumos does it. Search for linker map files.
- enthus1ast 8y ago
  i will thank you

eeZah7Ux 8y ago

> 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