4 ms·

I pretty strongly disagree here. The fact of the matter is just that tonnes of bugs, incompatibilities, permission problems, and bad installation experiences e

I pretty strongly disagree here. The fact of the matter is just that tonnes of bugs, incompatibilities, permission problems, and bad installation experiences every Linux user is intimately familiar with, often occur because package code has no control over which versions or whatever of system-level dependencies like Xorg, Fontconfi, Cairo, etc. are already installed. This also makes it much much easier for package authors to write code which works on multiple OSs without being experts on the details of all those OSs. Now, if there was no way around this, then you might have a point, but users always can opt-out of binary artifacts like that and point julia to their system libraries instead of the default vendoring of binary artifacts[1]. I think this is the right way to do it. Experts who want to get involved in the nitty gritty details of this stuff and who are also equipped to debug and deal with failures, can opt into using their system libraries, and the rest of us can pay some hard drive space and get a better out-of-the-box experience. ______________________________ [1]: https://pkgdocs.julialang.org/v1/artifacts/#Overriding-artifact-locations https://pkgdocs.julialang.org/v1/artifacts/#Overriding-artif...

WanderPanda 3y ago
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.
cycomanic 3y ago
> I pretty strongly disagree here. > The fact of the matter is just that tonnes of bugs, incompatibilities, permission problems, and bad installation experiences every Linux user is intimately familiar with, often occur because package code has no control over which versions or whatever of system-level dependencies like Xorg, Fontconfi, Cairo, etc. are already installed. I can tell you I had orders of magnitude more issues with inferior (and I have yet to encounter one which is anywhere close to a system package manager) language package managers. The main issue that one might encounter (especially with super stable packages like Cairo or fontconfig), is that the package one wants to install uses some feature of the most cutting edge release and the system has an older release. The consideration of not always using the latest and greatest and considering only stable releases seems to have completely gone missing and people just argue to install everything via virtual environments or docker containers. So we end up with tons of different versions of the same library all over the place. Regarding Julia being not public facing and security being not an issue, that someone else mentioned somewhere else down the thread, this package builds interactive dashboards. That's pretty public facing to me.
- patagurbon 3y ago
  It's fairly easy, if not super user friendly, to opt out of the Julia-vendored binaries though. If you've ever tried to install CUDA related packages from a poorly configured Python environment you'll have encountered this issue. On the vast majority of machines if you want to use CUDA.jl you just add it as a dependency. There's a reason much of Julia's audience uses things like Spack or even static dependencies in their non-Julia code. If you just want to get work done fussing with PATH issues or the right version of CMake/gcc/LLVM-OMP etc etc can take hours. Once you've gotten the work done, and you know it will load on most users computers, you're ready to deploy. Then just add an Overrides.toml to your environment. From the other side, just like websites there is a barrier caused by "please install W, X, Y, Z dependencies" vs "Pkg.add("GLMakie")"
- bmitc 3y ago
  This seems much more like a critique of Linux than any language or package development. And Linux is particularly a nightmare when it comes to graphical things.

WanderPanda 3y ago

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.

cycomanic 3y ago

> I pretty strongly disagree here. > The fact of the matter is just that tonnes of bugs, incompatibilities, permission problems, and bad installation experiences every Linux user is intimately familiar with, often occur because package code has no control over which versions or whatever of system-level dependencies like Xorg, Fontconfi, Cairo, etc. are already installed. I can tell you I had orders of magnitude more issues with inferior (and I have yet to encounter one which is anywhere close to a system package manager) language package managers. The main issue that one might encounter (especially with super stable packages like Cairo or fontconfig), is that the package one wants to install uses some feature of the most cutting edge release and the system has an older release. The consideration of not always using the latest and greatest and considering only stable releases seems to have completely gone missing and people just argue to install everything via virtual environments or docker containers. So we end up with tons of different versions of the same library all over the place. Regarding Julia being not public facing and security being not an issue, that someone else mentioned somewhere else down the thread, this package builds interactive dashboards. That's pretty public facing to me.

patagurbon 3y ago
It's fairly easy, if not super user friendly, to opt out of the Julia-vendored binaries though. If you've ever tried to install CUDA related packages from a poorly configured Python environment you'll have encountered this issue. On the vast majority of machines if you want to use CUDA.jl you just add it as a dependency. There's a reason much of Julia's audience uses things like Spack or even static dependencies in their non-Julia code. If you just want to get work done fussing with PATH issues or the right version of CMake/gcc/LLVM-OMP etc etc can take hours. Once you've gotten the work done, and you know it will load on most users computers, you're ready to deploy. Then just add an Overrides.toml to your environment. From the other side, just like websites there is a barrier caused by "please install W, X, Y, Z dependencies" vs "Pkg.add("GLMakie")"
bmitc 3y ago
This seems much more like a critique of Linux than any language or package development. And Linux is particularly a nightmare when it comes to graphical things.