6 ms·

I agree. Since nowadays the disk space saving argument is almost irrelevant the only thing in favor of shared libraries seems to be the automatic improvement of

I agree. Since nowadays the disk space saving argument is almost irrelevant the only thing in favor of shared libraries seems to be the automatic improvement of all dependents with one update. But I think history has shown that this is a major source of incompatibilities and since Julia software is not really supposed to be running public facing services the security argument is moot anyways.

nsajko 3y ago
> since Julia software is not really supposed to be running public facing services the security argument is moot anyways 1. both Julialang.org and Juliahub.com run Julia as far as I understand 2. even if your premise were true, it wouldn't be acceptable for the Julia project to condone pwning of Julia users
eigenspace 3y ago
> the security argument is moot anyways Sorry, I’m missing something, what security concerns are you referring to?
- chaosite 3y ago
  If each package vendors its own deps, when the dep has a security vulnerability and needs an upgrade you need to hunt down every last location it exists in, instead of updating the single shared system dep and being done with it.
  - somsak2 3y ago
    we just need better tooling for upgrading the individual locations. something like GitHubs dependabot
- nsajko 3y ago
  Apart from what sibling said, another issue is explosion of trust assumptions. On my system, I obviously have to trust the Archlinux project not to serve me malware. When using Julia, I additionally have to trust the Julia project not to serve me malware. (See also: Python, Node, etc.) Obviously: less trust is better for security, ideally almost all installed software would be signed by Archlinux maintainers. For comparison, the situation is kind of similar for Apple users; but on Windows, trust is extremely watered-down anyway (with or without Julia or Python etc.).
Oreb 3y ago
> since Julia software is not really supposed to be running public facing services Who said that? As far as I know, it was always intended as a general purpose language, and in my opinion, it’s already a pretty good one (and rapidly getting better), except for the fact that the library ecosystem is still limited in some areas.

nsajko 3y ago

> since Julia software is not really supposed to be running public facing services the security argument is moot anyways 1. both Julialang.org and Juliahub.com run Julia as far as I understand 2. even if your premise were true, it wouldn't be acceptable for the Julia project to condone pwning of Julia users

eigenspace 3y ago

> the security argument is moot anyways Sorry, I’m missing something, what security concerns are you referring to?

chaosite 3y ago
If each package vendors its own deps, when the dep has a security vulnerability and needs an upgrade you need to hunt down every last location it exists in, instead of updating the single shared system dep and being done with it.
- somsak2 3y ago
  we just need better tooling for upgrading the individual locations. something like GitHubs dependabot
nsajko 3y ago
Apart from what sibling said, another issue is explosion of trust assumptions. On my system, I obviously have to trust the Archlinux project not to serve me malware. When using Julia, I additionally have to trust the Julia project not to serve me malware. (See also: Python, Node, etc.) Obviously: less trust is better for security, ideally almost all installed software would be signed by Archlinux maintainers. For comparison, the situation is kind of similar for Apple users; but on Windows, trust is extremely watered-down anyway (with or without Julia or Python etc.).

Oreb 3y ago

> since Julia software is not really supposed to be running public facing services Who said that? As far as I know, it was always intended as a general purpose language, and in my opinion, it’s already a pretty good one (and rapidly getting better), except for the fact that the library ecosystem is still limited in some areas.