Bash as a Service(devthought.com)
devthought.com
Bash as a Service
http://www.devthought.com/2012/03/13/bash-as-a-service/
8 comments
Some people, when confronted with a simple problem, think "I know, I'll add a cloud". Now they have two problems.
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.
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.
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.
I understood it as "run a this command in an implementation that is parallelized and runs in 1000's of machines but has the same interface.
parallel --onall my-command
For example, to use them to convert a bunch of images from PNG to JPG:
find . --name '*.png' | parallel --onall --trc {.}.jpg "convert {} {.}.jpg"
Thank you!
What @sciurus says. And virtualization for security.
"Those who do not understand Unix are condemned to reinvent it, poorly."
-- Henry Spencer
How is this reinventing unix, at all?
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"
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"
I'm impressed that he's managed to come up with a brand new solution to a problem that doesn't actually exist.
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?
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.
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.
Actually, you can do a lot of this using "heroku run bash". And it's pretty awesome.
My understanding is that their vulcan build system [1] is a similar thing optimized for compiling things.
[1] https://github.com/heroku/vulcan
My understanding is that their vulcan build system [1] is a similar thing optimized for compiling things.
[1] https://github.com/heroku/vulcan
[deleted]
Before he got too far into it, I think he might be talking about 0install: http://0install.net/
Close, but 0install runs the apps on your local machine.
Close, but 0install runs the apps on your local machine.
That website without Javascript http://i.imgur.com/iMnNI.jpg
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?).