I have encountered this with apt as well.
Yup, there’s all sorts of stuff within Ubuntu that I could never figure out until I discovered the Arch wiki. With the amount of users debian has I don’t understand how they never wound up with anything even close to the Arch wiki.
One other thing i’d like to mention is, a few weeks ago my portable laptop died and stopped booting. Luckily, i was able to get an M.2 SSD card reader and used dd to transfer my arch linux install to the SSD of the replacement laptop, which is ASUS (while original was Lenovo).
Despite the hardware differences, i was able to successfully boot into my arch install and got fully up and running within a day. All i had to do was reconfigure the fstab and some bootloader configs, and some keyboard shortcuts.
So if I ever need to switch to a new computer again, now I know I dont even need to start from scratch on every machine. Kinda awesome.
Therefore, i dont need Manjaro to get me up and running quicker, since I can just copy my custom install of arch.
Since Arch/pacman is mentioned a few times here: I had segfaults in julia installed with pacman sometime ago (with 0.6.x, I think). Like always, Arch tries as much as possible to use system libraries Groups · Explore · GitLab and I think it’s different from the vanilla build you would get with simple make. I find using generic Linux binary from Download Julia is much safer (or just build from git master).
If I am not mistaken, Ubuntu 18.04 runs 4.15
As of today, the manjaro repository has what is tagged as 1.0.0.2, not sure what that is.
On 0.6, I believe arch used the system llvm which is almost certainly where the segfaults were coming from. When I peeked a couple weeks ago, it looked like arch was letting Julia build its own llvm for 1.0, so those segfaults may be a thing of the past.
Ah, yes it looks like it’s fixed FS#57387 : [julia] Requires a patched version of LLVM. Thanks for the info!
Most of the distros are identical in terms of performance. Solus uses more optimization, and is faster.
If performance is the main priority when choosing a Linux distribution, then Intel’s Clear Linux is the way to go, as various benchmarks by Phoronix show. Well, at least if you have an Intel CPU.
I guess, it should be “1.0.0-2”. The number behind the dash is the package release version. It is increased when the package content changes, but the packaged software version is not changing e.g.
The comments on this post have gone wildly off topic…
I shouldn’t encourage off-topic comments, but it has become the thread I was looking for (and anyway the best distribution for building Julia is probably the best distro for a server if you want Julia on a server; the best distro for a desktop, if you want Julia on a desktop, etc.).
I was searching the web for comparisons of Arch vs. Debian “testing”, vs, etc. The discussions are of various quality. I thought I’d look on Julia discourse, because compared to the average forum, threads here are usually more informed, or intelligent, or hip and with-it.
This is the best thread on the subject that I’ve found 
I wonder if this applies to Julia code though, which uses its own compiler (LLVM). Of course for external libraries (BLAS/LAPACK/…) this may be relevant.
Common wisdom says that older hardware (not too old) is better supported by the kernel and the distributions. Why is this different with Arch ?
no optimized Julia bundle yet: Feature/bundle request: Julia · Issue #126 · clearlinux/distribution · GitHub
Nvidia is messy in Arch. On a previous system, I wasn’t able to use X with Nvidia unless I created some empty config file.
And when you look in the Arch Wiki you can see that NVidia has a lot of different driver packages that one has to look through and carefully pick the right one. I guess this might be a problem of having such a freely configurable system. Distros like Ubuntu and Debian are probably preconfigured whereas you have to do at least some lifting in Arch yourself.
Another problem I had (or have) is that if I use the standard Linux kernel my system doesn’t boot anymore (it enters some infinite loop during boot). My momentary solution is to use the linux-lts kernel. But since then everything has been going smoothly.
I guess the bottom line is that when you use vanilla Arch Linux you should be open to investing more time into configuration and setup. If that is not for you, there is still Antergos and Manjaro.
I believe my hardware was old to the point that it was also faulty. This also laptop had troubles with overheating (causing the CPU to lock up, especially when using the graphics card).
So it might not be specific to arch, but I recall that it worked better on xubuntu for that laptop, for whatever reason that I cant explain. Maybe because the drivers were not the very latest, so more stable with the faulty card? Last time I compared it was about 2 years ago.
On my new laptop, it was more stable though, maybe because the hardware isnt damaged.
Sounds intriguing. Can you elaborate on this? The most I reviews I found focused on usability and installation.
I actually by myself have not tried it yet, while some of my friends are quite into it. I have seen a reddit post made by the Solus team members, and they mentioned that they learned a lot from the aggressive optimizations made by clear Linux. Since clear Linux may not be a great choice for desktop use, I guess Solus, which focuses on desktop users, could be a great choice.
I personally use Fedora, which is stable and bleeding edge at the same time. It may not be the fastest, but the ecosystem is huge. RHEL is used by many corporations, and Centos is used as servers OS in many places.
This Solus forum post from Aug 31 suggests that Julia 1.0 currently fails on Solus:
Not going into the repo yet, consistently fails to build on the build server. I’m going to re-open this and evaluate it when we go to LLVM 7.
Solus 3.9999 ( Solus 3 ISO Refresh) was released on September 20, 2018 which begs the question: Does Julia 1.0 work on Solus 3.9999? I don’t have a spare PC to test …
I’m sure the binaries or building from source yourself would work on Solus.
That they’re simply having trouble building with system llvm, etc.
Similarly, I strongly suspect that Clear Linux’s advantages primarily boil down to function multi-versioning and the clear Linux bundles shipping well optimized versions of their libraries.
Official Julia binaries already have function multi-versioning, so it’d only be faster if it ships linked to MKL instead of OpenBLAS. You can build from source yourself, but the lack of Arpack (requires OpenBLAS), and libraries that depends on it, eg Distributions and Lightgraphs, mean you’re likely to be happier with OpenBLAS.