As one of the commenters there points out, you can just do this with ssh. Which means you're ssh'ing to a machine you probably control, which means you would have had to install the stuff you want at some point on that machine anyway. Why not just do all your development from that machine (or, if you don't want to, why not just install the package on your local machine?).
I think the authors idea is that you would ssh to a machine that someone else controls and is providing access to. E.G. For a dollar a month I'll give you shell access to a machine where I've set up ImageMagick, and I'll give you a set of scripts that make running ImageMagic commands on your machine transparently run them on mine instead.
Yes, the value here is in 'where I've set up ImageMagick'.
If I have a task that could be made easier by having ImageMagick, but I don't have it on any machine I have easy access to, then I have to deal with the overhead of getting the package, installing the package, configuring the package, and possibly removing the package when I'm done.
Even though I know how to do all things, it would take me some time to get it all done, and then I'd have to waste brainpower in those things, and not the real problem I'm trying to solve.
A lot of that is solved by the "better" distributions, e.g. Debian has nearly everything under the sun.
But not everything. That's where the opportunity might be.
I probably wouldn't pay a dollar a month just for ImageMagick, but I might pay a few for shell access to a machine that has all of the new and shiny things available, things too new to get into the main repositories, and keeps them up-to-date and keeps adding new stuff, so I don't have to handle the sysadmin tasks for yet-another-box.
Sounds like a webservice with a REST API. Every non-Windows computer comes with a client out of the box.
In fact, for some of these things, I think I've seen REST APIs in existence, for the text and image conversion ones. The imagined "ru" command could just be a function or alias to curl/wget.
The thread where mkjones is parent explains why mostly.
The issue is that you use remote utilities hosted by other resources but as people already pointed out there are utilities provided already that essentially allow this. What "ru" would potentially be is more of a wrapper or alias to existing commands.
I feel that the quote he references in general would simply state that if users are seeking the ability to execute commands on a remote host then there are security implications. We have secure tools for accessing remote hosts and working but generating a catch-all utility would be an act of "reinventing the wheel"
Disagree, there are plenty of problems this solves. For example, this service could allow users of certain platforms to utilize tools that don't compile or are difficult to compile on certain platforms.
Why would you want to use a remote service instead of just installing the software on your local machine? Most software is quite small and it would be much more reliable this way as it wouldn't rely on a network connection to a second machine.
Seriously why would you not want to install pygmentize? It's Python, so it runs everywhere. The Debian package is 332 kB, so it's not wasting disk space. What possible motivation do you have to pay someone a fee to run it on their computer instead?
You cannot, in general, easily install software on your machine.
That is, I can find quite a few examples for which a particular version or some particular software won't install on your particular machine/OS combination.
Remember we're talking about CLI software. While I don't doubt you can find some examples of CLI programs that are hard to install on Debian, I doubt they're nearly enough to justify something like this.
Even if it's not packaged, 'tar xf file.tar && ./configure && make && checkinstall' doesn't require any particular effort to someone used to the shell, and you only have to do it once for each program.
As one of the commenters there points out, you can just do this with ssh. Which means you're ssh'ing to a machine you probably control, which means you would have had to install the stuff you want at some point on that machine anyway. Why not just do all your development from that machine (or, if you don't want to, why not just install the package on your local machine?).