Thanks y'all for input. I've updated the draft in the first post with more OSes / distros / package managers, and will continue to update it as I come across more info. There's no point yet in listing every distro for which Nim is _not_ available, but let me know what package managers that contain Nim (even if old version) I've missed.
**This is just the first step toward making Nim as easy, quick, and convenient to install and update** **_on any OS / distro_** **as any other programming language!** It seems that a latest precompiled Nim package isn't available on many [popular](http://distrowatch.com/) Linux distros, but what's most important is that we get the big two Linux package managers (deb and rpm) covered. I was able to "dpkg -i [nim_0.16.0-1_amd64.deb](https://packages.debian.org/sid/amd64/nim/download)" the Debian package on my Ubuntu 16.10 laptop. It did complain about libssl version, but I fixed that by installing the Debian [deb](https://packages.debian.org/stretch/amd64/libssl1.0.2/download). The Debian package included nimble, nimgrep, and nimsuggest in addition to nim; and Debian's [nim-doc](https://packages.debian.org/stretch/all/nim-doc/download) deb also installed OK. The [RHEL package](https://www.joyent.com/blog/pkgsrc-2014q4-lts-signed-packages-and-more) (which has to be extracted with ar x command before tar xvf) didn't contain any other bin utilities, bin the nim binary seemed fine. So the question is - do we want to tell Linux users that it's OK to use non-distro-specific Nim binaries, and to further test and document the process? Or should we continue to encourage them to build from source?
