Invisible wrote:
> Granted I haven't read the detailed documentation. But it looks like you 
> can put together an AMI and list it on Amazon's website with "hey, you 
> can run this thing for $2/hour". 

Yes. Which might be worthwhile if that's how you're selling software you 
can't get anywhere else.

> If you wanted to be able to submit renders from your PC and have them 
> automatically run, you'd have to have an instance constantly running, 
> waiting for work to be submitted. 

Huh? No. You start the AMI when you're ready to render something, and shut 
it down when it's finished. That's the point.

If you're automating it (or, rather, the way *I* automated it), the software 
on your desktop creates an S3 bucket with a name based on your Amazon ID, it 
copies the files up to it, it launches the AMI passing in your credentials, 
the AMI starts up and looks at the credentials and copies down the jobs, 
renders them, and puts the result back on S3 and shuts down.  When all the 
instances have shut down, the software on your desktop copies the results 
from S3 back to your machine.

-- 
Darren New, San Diego CA, USA (PST)
   Human nature dictates that toothpaste tubes spend
   much longer being almost empty than almost full.

Post a reply to this message

>> Granted I haven't read the detailed documentation. But it looks like 
>> you can put together an AMI and list it on Amazon's website with "hey, 
>> you can run this thing for $2/hour". 
> 
> Yes. Which might be worthwhile if that's how you're selling software you 
> can't get anywhere else.

Indeed. It wouldn't surprise me if somebody like AutoCAD lets you run 
their software this way so you can "rent" it rather than "buy" it. 
(Although... why would you only need CAD software for a short while?)

>> If you wanted to be able to submit renders from your PC and have them 
>> automatically run, you'd have to have an instance constantly running, 
>> waiting for work to be submitted. 
> 
> Huh? No. You start the AMI when you're ready to render something, and 
> shut it down when it's finished. That's the point.
> 
> If you're automating it (or, rather, the way *I* automated it), the 
> software on your desktop creates an S3 bucket with a name based on your 
> Amazon ID, it copies the files up to it, it launches the AMI passing in 
> your credentials, the AMI starts up and looks at the credentials and 
> copies down the jobs, renders them, and puts the result back on S3 and 
> shuts down.  When all the instances have shut down, the software on your 
> desktop copies the results from S3 back to your machine.

That sounds like a sensible workflow. And I guess if the AMI gets 
started under the customer's account (which your tool presumably has to 
somehow obtain), they get billed, and you can still take your cut.

...until somebody else realises that all your AMI actually does is untar 
the files and launch POV-Ray, and they build their own AMI that does the 
exact same thing. Now they can do exactly what they did before, but 
without paying a cut to you. ;-)

Post a reply to this message

Invisible wrote:
> That sounds like a sensible workflow. And I guess if the AMI gets 
> started under the customer's account (which your tool presumably has to 
> somehow obtain)

It asks.

> they get billed, and you can still take your cut.

Yes.

> ...until somebody else realises that all your AMI actually does is untar 
> the files and launch POV-Ray, and they build their own AMI that does the 
> exact same thing. Now they can do exactly what they did before, but 
> without paying a cut to you. ;-)

Except my tool does more than that. It pushes a bunch of individual jobs up 
to S3, launches multiple AMIs which coordinate to copy down the sources, run 
the jobs, copy the results back up, and starts on new jobs as each machine 
comes free, shutting each down when no work remains. And they don't all have 
to be POV-Ray.

But yeah, if all you're providing is a machine preconfigured with a free 
program, it's going to be rough to get someone else to pay you to run it.

-- 
Darren New, San Diego CA, USA (PST)
   Human nature dictates that toothpaste tubes spend
   much longer being almost empty than almost full.

Post a reply to this message

Darren New wrote:

> Except my tool does more than that. It pushes a bunch of individual jobs 
> up to S3, launches multiple AMIs which coordinate to copy down the 
> sources, run the jobs, copy the results back up, and starts on new jobs 
> as each machine comes free, shutting each down when no work remains. And 
> they don't all have to be POV-Ray.

...and where can I get this tool? :-}

> But yeah, if all you're providing is a machine preconfigured with a free 
> program, it's going to be rough to get someone else to pay you to run it.

LOL! People have tried dumber things... ;-)

Post a reply to this message

Invisible wrote:
> Darren New wrote:
> 
>> Except my tool does more than that. It pushes a bunch of individual 
>> jobs up to S3, launches multiple AMIs which coordinate to copy down 
>> the sources, run the jobs, copy the results back up, and starts on new 
>> jobs as each machine comes free, shutting each down when no work 
>> remains. And they don't all have to be POV-Ray.
> 
> ...and where can I get this tool? :-}

The part that actually launches the VMs isn't finished yet, because I didn't 
do the API work to interface to ECC as well as S3. But if you want to launch 
your instances manually and fire up the program on launch, it should work.

You get it from me, but it'll have to wait until I have time to package it 
up properly, if you actually want it.

-- 
Darren New, San Diego CA, USA (PST)
   Human nature dictates that toothpaste tubes spend
   much longer being almost empty than almost full.

Post a reply to this message

So, since you seem to know a bit about AWS, here's a few questions...

1. Can you access stuff stored in S3 using normal HTTP requests?

2. How do you upload stuff to S3? I mean, presumably there's a shiny 
webpage for uploading individual files, but what if I wanted to upload 
programmatically?

3. How does AWS authentication work?

Post a reply to this message

Invisible wrote:
> So, since you seem to know a bit about AWS, here's a few questions...
> 
> 1. Can you access stuff stored in S3 using normal HTTP requests?

Yes.

> 2. How do you upload stuff to S3? I mean, presumably there's a shiny 
> webpage for uploading individual files, but what if I wanted to upload 
> programmatically?

You use a library, depending on what language you're using, or you implement 
your own, which I did for Tcl. I use the S3 extension to firefox for 
interactive stuff.

> 3. How does AWS authentication work?

Using HTTP with REST, you sign certain HTTP headers and the content checksum 
(or something like that) with the secret key that Amazon gives you when you 
sign up for an account. Which makes it almost REST.

Using HTTP with SOAP, you use the standard SOAP certificate stuff that's 
built into decent SOAP libraries.


-- 
Darren New, San Diego CA, USA (PST)
   Human nature dictates that toothpaste tubes spend
   much longer being almost empty than almost full.

Post a reply to this message

>> So, since you seem to know a bit about AWS, here's a few questions...
>>
>> 1. Can you access stuff stored in S3 using normal HTTP requests?
> 
> Yes.

OK. The documentation wasn't very clear about this...

>> 2. How do you upload stuff to S3? I mean, presumably there's a shiny 
>> webpage for uploading individual files, but what if I wanted to upload 
>> programmatically?
> 
> You use a library, depending on what language you're using, or you 
> implement your own.

I'd be in the latter group.

(There *is* actually a library already, but there's no documentation for 
it, so...)

>> 3. How does AWS authentication work?
> 
> Using HTTP with REST, you sign certain HTTP headers and the content 
> checksum (or something like that) with the secret key that Amazon gives 
> you when you sign up for an account. Which makes it almost REST.
> 
> Using HTTP with SOAP, you use the standard SOAP certificate stuff that's 
> built into decent SOAP libraries.

...right. So I actually need real crypto libraries to be able to use it? 
Oh well, that's the end of that then.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 wrote:
> OK. The documentation wasn't very clear about this...

Uh, OK.  It seemed really clear to me. :-)  They even give you options for 
giving people time-limited access to otherwise unreadable objects.

>> You use a library, depending on what language you're using, or you 
>> implement your own.
> 
> I'd be in the latter group.

There ya go, then. Read the specs. It's pretty straightforward.

> ...right. So I actually need real crypto libraries to be able to use it? 
> Oh well, that's the end of that then.

I think you need an MD5 implementation, is all.

-- 
Darren New, San Diego CA, USA (PST)
   Human nature dictates that toothpaste tubes spend
   much longer being almost empty than almost full.

Post a reply to this message

>> OK. The documentation wasn't very clear about this...
> 
> Uh, OK.  It seemed really clear to me. :-)  They even give you options 
> for giving people time-limited access to otherwise unreadable objects.

Oh, I haven't read through all the low-level documentation, only the 
summary pages.

>>> You use a library, depending on what language you're using, or you 
>>> implement your own.
>>
>> I'd be in the latter group.
> 
> There ya go, then. Read the specs. It's pretty straightforward.

...for somebody who doesn't yet understand what SOAP or REST are?

>> ...right. So I actually need real crypto libraries to be able to use 
>> it? Oh well, that's the end of that then.
> 
> I think you need an MD5 implementation, is all.

I actually wrote an MD5 implementation in Haskell. (The hardest part is 
the padding. You must get this exactly right, and MD5 allows the 
"message" to be an arbitrary number of bits - not necessarily a multiple 
of eight, not necessarily non-zero!) I eventually got it to produce the 
correct answer in every single case I tested.

You can see where this is going, can't you? Yes, I admit it: It's way, 
way too slow to be remotely useful. Files that md5sum.exe can process in 
a split second take several minutes. I haven't figured out why yet.

(Alternatively, there's a binding to the C implementation - which 
presumably won't work on Windows. Probably not hard to pipe the data to 
md5sum.exe tho... Hell, that is one of the *design goals* of the tool!)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message