Comment by eigenspace | Hacker News Reader

Comment by eigenspace | Hacker News Reader

Parent Full thread

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-artif...

> 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.

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")"

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.

Actually I would argue the reason that every language is inventing their own poor package manager, is because other OS don't have proper package management.

As I said in the previous post, I hardly ever have issues with my system packages. Helping people set up an environment to develop cython code for windows on the other hand is an absolute nightmare.

Have you used Julia's package manager? Imo, it works better than apt and snap (I don't have enough experience with RPM/flatpack to compare)

I would say most language package managers I have used are easier than than any Linux package manager I have used.

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.

> 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

> the security argument is moot anyways

Sorry, I’m missing something, what security concerns are you referring to?

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.

we just need better tooling for upgrading the individual locations. something like GitHubs dependabot

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.).

> 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.

Reply on news.ycombinator.com