Hacker Newsnew | comments | show | ask | jobs | submit | carson's comments login

From hearing the details it seems that there is no real limitation to what you can execute as long as it runs on the instance. I get the feeling that if you zipped up all of the parts of python or ruby you need to ru you could execute a script using either of them as long as you initiated it from your node script. The key word here is probably "support" and that may be more of an issue if you want to edit your scripts with their web IDE.

-----


Someone pull a CSI and enhance the reflection in the glasses at about 43 seconds in!

-----


It would be awesome to see the 1st and 3rd tools open sourced.

-----


Hello Carson, Pierpaolo from Dropbox here.

we are considering open sourcing the segmenter tool (3rd). As you can imagine it's very much tailored for our pipeline and as the internal tool built in ffmpeg matures, we think our solution will become of marginal value. I keep debating myself if/when to bite the bullet and try out the ffmpeg one.

The first tool is quite similar to the one that mau posted (https://github.com/danielgtaylor/qtfaststart). Given that we forked quite some time back, I'd suggest to start from that one since it has probably bug fixes on top of our version.

-----


you can find something that do the 1st job here: https://github.com/danielgtaylor/qtfaststart

-----


Anyone know how "thousands of packages" cited in the original article turned into "millions of customers" in the gigaom piece?

-----


From the #code2012 poll on twitter C# is 8th where it was last year: http://www.ioncannon.net/projects/code2012/ Not that it is any better a stat than Google searches but the number one language from the poll was Javascript and I tend to think that from a use standpoint that is probably "the language of the year" if there is one.

-----


It is also worth pointing out that you can fly to DC and NYC in under 2 hours from Louisville. You can fly to Chicago and get there before you took off thanks to the time change. So you have access to pretty much any of the "best" of those things listed here in about 3 hours including the time it takes you to drive to the airport, get through security and board.

-----


#2 is possible but #3 isn't unless you have a completely open bucket and that wouldn't be good.

-----


I hate to be so self-promoting, but http://jsfiddle.net/GTYX5/2/ should do everything you're asking for

-----


filepicker.io is cool. But your backend service wouldn't be needed if the image uploading & resizing straight to s3 could be done in the browser. Your product would simply be a javascript lib.

-----


how do you do #2?

-----


I will second this. At the bottom of this article there is a reference the article I wrote a while ago when Amazon released this feature. I was planing on doing multipart uploading at that time using the FileReader but there was a bug in the way S3 did CORS so I didn't want to continue until that was fixed. They fixed it and I never came back to it. Maybe be a good time to try it again. Resuming a partial upload seemed like a good win to me.

-----


I wrote the example referenced at the bottom of the article and it has an example of indicating progress to the user. You can see it in app.js here: https://github.com/carsonmcdonald/direct-browser-s3-upload-e...

-----


Anyone remember Joyent's Strongspace service? http://www.datacenterknowledge.com/archives/2008/01/21/joyen...

-----


They got a free thumper from Sun through the "try and buy" program, loaded it up with customers, and ... failed to operate it properly. IIRC, it wasn't just a service outage - some data was irrevocably lost.

ZFS on Solaris was a non-beta, prime time product at that time, so it's not fair to blame it on "a ZFS thing". Deploying customers on loaner hardware is scrappy and admirable, in a way, but Sun wasn't giving those away two by two - there was no redundancy.

The joyent blog, in those days, alternated between enterprise cloud bullshit-bingo posts and facebook game development. I thought it was a clown operation back then and I suspect it still is.

-----


ZFS was officially a non-beta, prime time product. In practice, apparently anyone who tested its robustness thoroughly before deploying it found that it tended to crash and burn at the first hint of trouble exactly like it did for them.

-----


That's pretty much what happened if you were foolish enough to try and run a production system on ZFS back then, I think.

-----

More

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: