# Julia in Linux distributions

**URL:** <https://discourse.julialang.org/t/julia-in-linux-distributions/16120>\
**Category:** Community\
**Created:** [October 10, 2018, 2:23pm UTC](https://discourse.julialang.org/t/julia-in-linux-distributions/16120 "2018-10-10T14:23:12Z")\
**Posts on this page:** 20\
**Page:** 2

<div class="post-metadata">

**Author:** ![johnh](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/johnh/32/3615_2.png) [@johnh](https://discourse.julialang.org/u/johnh)\
**Post date:** [October 16, 2018, 4:24pm UTC](https://discourse.julialang.org/t/julia-in-linux-distributions/16120/21 "2018-10-16T16:24:45Z")

</div>

@iwelch @nalimilan on this thread does marvellous work with CentOS/Fedora doing just that via ‘COPR’ repositories.

However I agree with @Tamas_Papp - there should be distro packaged versions of Julia.  
However that is only a starting point - ie it sets a low bar for entry to Julia.  
You need then to go on with downloaded versions.

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [October 16, 2018, 4:26pm UTC](https://discourse.julialang.org/t/julia-in-linux-distributions/16120/22 "2018-10-16T16:26:30Z")

</div>

> [@johnh](#):
>
> However I agree with @Tamas_Papp - there should be distro packaged versions of Julia.

Perhaps I wasn’t clear then — I was arguing that they are not worth it.

---

<div class="post-metadata">

**Author:** ![johnh](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/johnh/32/3615_2.png) [@johnh](https://discourse.julialang.org/u/johnh)\
**Post date:** [October 17, 2018, 3:46am UTC](https://discourse.julialang.org/t/julia-in-linux-distributions/16120/23 "2018-10-17T03:46:51Z")

</div>

@Tamas_Papp I did understand your reply, and it was me who was not being clear. Sorry.

---

<div class="post-metadata">

**Author:** ![johnh](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/johnh/32/3615_2.png) [@johnh](https://discourse.julialang.org/u/johnh)\
**Post date:** [October 17, 2018, 3:58am UTC](https://discourse.julialang.org/t/julia-in-linux-distributions/16120/24 "2018-10-17T03:58:13Z")

</div>

Perhaps appropriate here for me to give some experience from building HPC clusters.  
In that field the cluster admins have to build a complete software stack, from the Infiniband/Omnipath drivers, through various MPI flavours through to the applications software.Here ‘build’ covers commercial applications which would eb installed rather than built from source.

This is managed using packages such as Easybuild [Introductory topics — EasyBuild v4.6.0 documentation (release 20220708.0)](https://easybuild.readthedocs.io/en/latest/)  
and Spack [https://spack.io/](https://spack.io/)  
One of the difficulties in HPC is that a particular application may be built several times - with different compilers and different MPI flavours. So on one cluster you can choose which implementation you use, by adjusting your PATHS using Modules [http://modules.sourceforge.net/](http://modules.sourceforge.net/)

The distributions package MPI flavours, but these tend to be out of date and you continually see this on the OpenMPI mailing list - “I am working with version 1.xxx” the reply being “well use the latest version please”  
Also another example is a recent kernel update which was made available by Redhat. RDMA was disabled in this kernel by a small bug. Which affected many HPC sites. No-one particularly blamed Redhat there - the developers dont have access to Infiniband hardware so could not test.

---

<div class="post-metadata">

**Author:** ![johnh](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/johnh/32/3615_2.png) [@johnh](https://discourse.julialang.org/u/johnh)\
**Post date:** [October 17, 2018, 4:05am UTC](https://discourse.julialang.org/t/julia-in-linux-distributions/16120/25 "2018-10-17T04:05:29Z")

</div>

Now that I am on my high horse… The attitude that Ï will only work with the packages shipped with Ubuntu, and I will only consider Ubuntu" drives me mental. I of course can accept counter arguments here.  
Remember that Ubuntu made a very conscious decision and put a lot of effort into capturing the mindset of the web scale generation - the developers there did not stumble upon Ubuntu as being a good solution. Neither did your friend pass it on to you in a viral fashion. Ubuntu marketed themselves as the distro of choice.

I will give one small specific - discussing choice of Ubuntu with someone and he said “We use it cos they ship Tensorflow in their repositories”  
WTF??? That’s all well and good if you are wanting to try something out, and I an all for it.  
But if you are doing something business critical, and you need the latest version or a bugfix, then you need a highly competent sysadmin (for example me). Someone who can build Tensorflow using a knife and fork in a Force 10 gale on any Linux OS. Someone who has the tools to determine where the problem is when your model won’t run.

---

<div class="post-metadata">

**Author:** ![nalimilan](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nalimilan/32/147_2.png) [@nalimilan](https://discourse.julialang.org/u/nalimilan)\
**Post date:** [October 21, 2018, 4:49pm UTC](https://discourse.julialang.org/t/julia-in-linux-distributions/16120/26 "2018-10-21T16:49:33Z")

</div>

I’ve just pushed a new version of the official Fedora package using an ILP64 OpenBLAS.

---

<div class="post-metadata">

**Author:** ![fusion809](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/fusion809/32/6080_2.png) [@fusion809](https://discourse.julialang.org/u/fusion809)\
**Post date:** [November 15, 2018, 12:41pm UTC](https://discourse.julialang.org/t/julia-in-linux-distributions/16120/27 "2018-11-15T12:41:58Z")

</div>

Julia can be obtained via the cross-distribution package manager, Nix, which presently provides Julia 1.0.1. To install Nix itself run:

```bash
curl https://nixos.org/nix/install | sh

```

then install Nix with:

```bash
nix-env -i julia

```

then you can launch Julia, after Nix is added to your PATH (with `export PATH=$HOME/.nix-profile/bin:$PATH`) with `julia`. Nix is very handy for getting packages not provided by our distro, or provided by your distro but with bugs.

---

<div class="post-metadata">

**Author:** ![non-Jedi](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/non-jedi/32/3645_2.png) [@non-Jedi](https://discourse.julialang.org/u/non-Jedi)\
**Post date:** [November 15, 2018, 10:10pm UTC](https://discourse.julialang.org/t/julia-in-linux-distributions/16120/28 "2018-11-15T22:10:34Z")

</div>

Please don’t recommend people to install things by piping curl outputs directly to sh. There’s many valid ways of installing nix; that isn’t a good one. Especially since this is a public forum meaning there are certainly people here who don’t understand the full security implications of that bit of scripting.

EDIT: Please don’t tell people to ever pipe things from the network directly to sh.

---

<div class="post-metadata">

**Author:** ![fusion809](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/fusion809/32/6080_2.png) [@fusion809](https://discourse.julialang.org/u/fusion809)\
**Post date:** [November 15, 2018, 10:43pm UTC](https://discourse.julialang.org/t/julia-in-linux-distributions/16120/29 "2018-11-15T22:43:49Z")

</div>

OK, which method of installing Nix would you recommend that should work on all modern Linux distros? I chose that method because it’s the most distribution-agnostic method of installing it, many distros don’t have it in their official repos.

---

<div class="post-metadata">

**Author:** ![jpsamaroo](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jpsamaroo/32/46804_2.png) [@jpsamaroo](https://discourse.julialang.org/u/jpsamaroo)\
**Post date:** [November 16, 2018, 1:47am UTC](https://discourse.julialang.org/t/julia-in-linux-distributions/16120/30 "2018-11-16T01:47:52Z")

</div>

I think the important part is having the ability to review the script before you run it. Therefore, first download with curl, do whatever auditing of the script you care to do, and then run it.

---

<div class="post-metadata">

**Author:** ![Yifan\_Liu](https://avatars.discourse-cdn.com/v4/letter/y/4da419/32.png) [@Yifan\_Liu](https://discourse.julialang.org/u/Yifan_Liu)\
**Post date:** [November 16, 2018, 1:50am UTC](https://discourse.julialang.org/t/julia-in-linux-distributions/16120/31 "2018-11-16T01:50:45Z")

</div>

Has anyone used the MKL linked Julia in arch linux?  
[https://aur.archlinux.org/packages/julia-mkl/](https://aur.archlinux.org/packages/julia-mkl/)

---

<div class="post-metadata">

**Author:** ![fusion809](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/fusion809/32/6080_2.png) [@fusion809](https://discourse.julialang.org/u/fusion809)\
**Post date:** [November 16, 2018, 6:02am UTC](https://discourse.julialang.org/t/julia-in-linux-distributions/16120/32 "2018-11-16T06:02:22Z")

</div>

> [@jpsamaroo](#):
>
> I think the important part is having the ability to review the script before you run it. Therefore, first download with curl, do whatever auditing of the script you care to do, and then run it.

If they’re the cautious type there’d be nothing stopping them from viewing [https://nixos.org/nix/install](https://nixos.org/nix/install) in a browser first.

---

<div class="post-metadata">

**Author:** ![non-Jedi](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/non-jedi/32/3645_2.png) [@non-Jedi](https://discourse.julialang.org/u/non-Jedi)\
**Post date:** [November 16, 2018, 4:45pm UTC](https://discourse.julialang.org/t/julia-in-linux-distributions/16120/33 "2018-11-16T16:45:20Z")

</div>

Doesn’t eliminate the concern; fairly easy for an attacker to show something different in the browser than when it sees a curl user-agent. Never run untrusted code in a non-sandboxed context without first checking that it’s what it says on the tin. This is why distro package managers check signatures on packages.

EDIT: even that script verifies the checksum after downloading a tarball. Same (or higher) level of thoroughness needs to be applied to distribution of the install script itself.

---

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [November 16, 2018, 5:03pm UTC](https://discourse.julialang.org/t/julia-in-linux-distributions/16120/34 "2018-11-16T17:03:21Z")

</div>

> [@non-Jedi](#):
>
> fairly easy for an attacker […] Never run untrusted code in a non-sandboxed context without

Interesting (paranoia, not saying unjustified).

You justify why each distro’s update method is better (is there none that is foolproof across distros? I’ve not looked much into Snap and Flatpack; I assume they work). Compared to Windows at least with [self-extracting] .exe that curl-method isn’t any worse… I’ve not looked into if Windows users have anything better. I know of .msi files, just not if they have the same issues.

Back on topic to Julia, the Windows users are only offered nothing better than such an .exe file… (yes, ok, compile from source). And I notice they don’t even have a GPG file unlike for other platforms, at the download page. I’m guess many (most?) [Windows] users don’t care or wouldn’t know what to do with it.

Users should be able to trust “us”, but we shouldn’t be telling them (implicitly) that they should, or that it’s a good idea to trust us.

To be really paranoid would be to not trust the actual Julia binary for either Linux or Windows or any platform. An attacker could check the .sh file, but it wouldn’t guard against a virus/malware in the Julia binary itself. So are we just talking about degrees of trust (or guarding us against other distributors); just guarding against the easiest ways to get hacked?

---

<div class="post-metadata">

**Author:** ![Ronis\_BR](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ronis_br/32/50999_2.png) [@Ronis\_BR](https://discourse.julialang.org/u/Ronis_BR)\
**Post date:** [November 16, 2018, 8:06pm UTC](https://discourse.julialang.org/t/julia-in-linux-distributions/16120/35 "2018-11-16T20:06:30Z")

</div>

I try to keep Julia in openSUSE Tumbleweed as closest as possible to the latest version. In Leap, it is not possible due to some old libraries. Right now, we have 1.0.1 and probably 1.0.2 by the end of next week. So, if you are using Tumbleweed, you just need:

```julia
zypper in julia julia-devel julia-doc

```

---

<div class="post-metadata">

**Author:** ![chakravala](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chakravala/32/6832_2.png) [@chakravala](https://discourse.julialang.org/u/chakravala)\
**Post date:** [November 16, 2018, 8:28pm UTC](https://discourse.julialang.org/t/julia-in-linux-distributions/16120/36 "2018-11-16T20:28:52Z")

</div>

Arch linux uses `pacman` which uses `gpg` keys to verify the trust of the binary downloads

[https://wiki.archlinux.org/index.php/Pacman/Package\_signing](https://wiki.archlinux.org/index.php/Pacman/Package_signing)

```julia
sudo pacman -S julia

```

---

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [November 16, 2018, 9:45pm UTC](https://discourse.julialang.org/t/julia-in-linux-distributions/16120/37 "2018-11-16T21:45:46Z")

</div>

> [@Ronis\_BR](#):
>
> In Leap, it is not possible due to some old libraries

Leap is brand new (and the other developer/rolling).

I’m just curious (I have no need for OpenSuSE), why are the old libraries a trouble? I assume it’s the old [distro/Linux] problem of using dynamic linking to repositories. Is it by choice? I actually thought Julia wanted to statically link a lot if not all, at least for now.

I think that’s the problem solved with containers: e.g. Flatpak and Snap.

[https://software.opensuse.org/package/flatpak](https://software.opensuse.org/package/flatpak)

is available for OpenSuSE (and other major Linux distros), while Snap not yet (while supported by other major), it seems.

As always, there seems to be two or more solutions in Linux. Not sure if Flatpak is better, while for OpenSuSE currently.

Needs Julia support it and/or snap, for the way forward?

Linux

---

<div class="post-metadata">

**Author:** ![Ronis\_BR](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ronis_br/32/50999_2.png) [@Ronis\_BR](https://discourse.julialang.org/u/Ronis_BR)\
**Post date:** [November 16, 2018, 11:22pm UTC](https://discourse.julialang.org/t/julia-in-linux-distributions/16120/38 "2018-11-16T23:22:27Z")

</div>

The problem is that we should not bundle libraries into packages as per openSUSE guidelines. In Julia, somethings cannot be avoided, such as LLVM. Leap 15.0 is new, but uses some old, stable libraries that cannot build newer Julia versions. When 15.1 is out, then it will have Julia 1.0, but it is very difficult to keep Julia updated in Leap. Leap 15.0 has Julia 0.6.2.

---

<div class="post-metadata">

**Author:** ![alec-hoyland](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/alec-hoyland/32/6001_2.png) [@alec-hoyland](https://discourse.julialang.org/u/alec-hoyland)\
**Post date:** [November 16, 2018, 11:29pm UTC](https://discourse.julialang.org/t/julia-in-linux-distributions/16120/39 "2018-11-16T23:29:01Z")

</div>

Can confirm. Arch Linux has a package for [Julia](https://www.archlinux.org/packages/?name=julia) that is kept up-to-date with the latest version. I’ve experienced no problems with it so far. Works as I’d hope it would.

---

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [November 17, 2018, 4:55pm UTC](https://discourse.julialang.org/t/julia-in-linux-distributions/16120/40 "2018-11-17T16:55:39Z")

</div>

> [@Ronis\_BR](#):
>
> The problem is that we should not bundle libraries into packages as per openSUSE guidelines. In Julia, somethings cannot be avoided, such as LLVM.

As you say, they are just a guidelines that you break anyway for LLVM, so why not just do that too for the other problematic libraries/dependencies? You can always relax this later, and it’s the only option to support Julia 1.x.x in current Leap? Or as I said, use Flatpak (where as with Snap, I think the point is to avoid the depositories and dynamic linking).

I see no difference with LLVM vs other libraries in theory; there’s even USE\_SYSTEM\_LLVM in the Makefile. Isn’t there such for all the other problematic libraries too?

It’s just that LLVM is heavily patched. When LLVM catches up, I expect you want to use the system LLVM.

[Previous page](https://discourse.julialang.org/t/julia-in-linux-distributions/16120.md?page=1)

[Next page](https://discourse.julialang.org/t/julia-in-linux-distributions/16120.md?page=3)