make pp.md a bit more portable (to non RedHat *nix systems)

[hoijui]

I am using a bash script here, thoug hit might make more sense to use Haskell for this, if it has a nice portable way to get this kind of info.

with this change, make doc seems to work fine on my systme too (it only fails because I don't have lua nor Rscript installed; if I remove tose two sections, it works)

[CDSoft]

I don't understand the actual need hidden behind this commit. The binary I deliver on cdsoft.fr is compiled on Fedora and their is no guarantee it will work on other systems. The documentation tells exactly on which platform this binary will work. For other platforms the only recommended way is to compile pp from the sources.
To avoid complex scripts, I think that uname should give enough information.

[hoijui]

true! (I changed the commit to use uname)

The need is only that, that it works on other peoples machines.
We want to use pp in a workflow that would be used by a lot of people and projects, and thus it matters to us to have a sense that the project would be fully available (including the ability to develop/fix them) even if the maintainer(s) would abandon them.

... which of couse I hope, does not happen. ;-)

I have no interest to fork/take-over the project by any means!

[CDSoft]

If §sh[(uname -s -r -m) || true] fails, its result will be empty.
Finally I think that we can remove such architecture details and be more generic. e.g.:

    Latest Linux and Windows binaries:
        Linux: https://cdsoft.fr/pp/pp-linux-x86_64.txz
        Windows: https://cdsoft.fr/pp/pp-win.7z

    Older version archive:
        Linux & Windows: https://cdsoft.fr/pp/download.html

    User contributed Mac OS binaries (outdated):
        Mac OS (64 bit binaries): https://github.com/dlardi/pp/releases/download/v1.0/pp-darwin-x86_64.txz

I will update my web site and add more information about the platform used to compile these binaries.

[hoijui]

makes sense, thank you! :-)

I think it would also be good to have a (Travis-)CI build of everything setup, or at least the set of required packages on debian based syustems or something like that. whaat od you think? I might get around somewhen to do that (not this week though).
if we have that list, then you can probabyl derive the set of Fedora packages from it aswell, and we can test that with docker too.