If we are sharing anecdotes: both my condo building and office building have reserved spots for charging electric cars. However, I'm not a fan because they were both installe by government subsidy and currently offer free power. Just why we need: to subsidize the drivin habits of people rich enough to afford an electric car (as they currently command a price premium).
A believe many people enjoy movies and don't want to pirate them (I am one of them). They won't pirate and don't want to abstain from movies, so the only option is to provide a credible alternative entertainment that doesn't involve sending money to those who lobby against us.
Exactly, compare this to SimpleDB. SimpleDB started out with an advanced query language that let query and filter your results in all sorts of ways. And guess what? SimpleDB is still limited to 10 GB per domain (aka, database). Want to horizontally scale? The official suggestion is to shard your data across domains. This is a really messy solution because you have to preshard based on estimated database size and resharding is nearly impossible (you'd have to rewrite your entire DB).
AppEngine went the other route and provided a very simple database API at first and all queries had to be range scans over an index. Any query you wanted to perform had to be precalculated by defining a composite index and some things (like inequalities on multiple fields) weren't supported. Over time they've built upon their basic database and added features such as a zigzag merge join algorithm which lets you perform queries that were otherwise impossible with a given set of indexes.[1]
I bet DynamoDB will be going the AppEngine route by starting with a simple, scalable base which can be used to build more advanced query engines and features.
I'm running a bunch of t1.micros for different websites, now I have to pay twice as much to get an ELB for each to use v6? And I still can't SSH over v6. Amazon needs to stop pretending that ELB is the final solution for v6 and give each instance their own v6 address.
It's disingenuous to believe Amazon is pretending anything or won't eventually offer IPv6 IPs. They have a massive, global, proprietary internal routing infrastructure -- it takes time, resources and lots of testing before rolling out new services on that infrastructure.
The problem is having no roadmap. We know they're working to make AWS better... somehow. And you can't assume anything; there are EC2 feature requests that have been open for five years.
Try searching for [poison control] or [suicide]. Both of those bring up one boxes with phone numbers to call. Those probably help save a couple lives per day. Sure, you could call 911 and have them give you the poison control number, but now you've tied up 911 resources.
Speaking as a former 911 operator, I can say fairly certainly that a 911 operator won't object to you calling to try and access the poison control center. They'll probably just transfer you, OR (more likely, depending on the policies of the jurisdiction in question) go ahead and dispatch an EMS crew to your location.
The server is written in node.js and it uses socket.io to do the transfers. I think it only works in Chrome because I didn't bother getting the drag-and-drop working with anything else. Actually, it seems to be broken in the current dev channel of Chrome. I announced it back in September:
Heh. Well, mine wasn't completely arbitrary. If I remember correctly I was trying to trade off server CPU usage with memory usage. One chunk at a time is buffered on the server, so I wanted to keep it small enough that I could have a bunch of ongoing transfers on my puny t1.micro. However, too small of a chunk size resulted in too many roundtrips and lots of CPU load on the server. I settled on this value because I was able to pump a couple megabytes per second through it using one stream, which seemed reasonable.
Also: in further testing, it looks like Safari works with the drag and drop, but not the uploading. I purposely disabled all socket.io transfer types except web sockets in order to encourage adoption of modern browsers. Unfortunately, since I used such bleeding edge, unstandardized technology (drag and drop, file API, and web sockets), the browsers have changed and broken my implementation, each in a slightly different way, such that none of them work end to end anymore.
If anyone cares, I found out what the problem was. Chrome updated to a new version of the web socket standard back in version 15 or so. I wasn't aware of the change and so didn't update my version of socket.io which supports the new standard, thus an incompatibility. It should work now.
This just goes to show that you have to be vigilant if you are building sites with the latest and greatest, as they are still under development and likely to change out from under you.
This seems to be more of a streaming upload/download. Node just basically pipes along the chunks from the serving peer through the websockets.
I'm pretty sure that if you just "connect the uploader's POST to the downloader's GET" then the Node server would have to buffer the entire file from the submitter before sending it to the clients.
> I'm pretty sure that if you just "connect the uploader's POST to the downloader's GET" then the Node server would have to buffer the entire file from the submitter before sending it to the clients.
Not at all. Use stream.pipe(). I've done it countless times and it works really well.
My major take away from the MG Sieler post was that Rubin deleted a tweeted, which makes it look like he's trying to hide something, regardless of the true reason for deleting it. Why does he need to delete a tweet that whose commands no longer work? A tweet is a point in time snapshot that represents a thought or opinion at a certain point in time. They aren't wikis that need to be constantly updated and maintained. If someone tried the command and it didn't work, they could always search for the up to date instructions. I'm not sure how this became a platform flame war.
Still, MG clearly overreacted, which makes him look rather foolish right now. It just shows how biased he is against Android and Google, that he will make a big problem out of nothing, which is actually very much like he's doing his reviews. Downplays Android advantages, and makes a big deal of some of the disadvantages.
