krallin

Here's a small, shameless, open source, plug: I work on the "Cactus" static website generator, check out and fork our work here: github.com/koenbok/Cactus (current version), https://github.com/krallin/Cactus (next version)

Actually, this comment is correct.

S3 may indeed serve it using Static Website Hosting (and you need to enable it anyway to use CloudFront with it).

Still, S3 is quite slow, and not globally distributed. It's indeed good advice and practice to use CloudFront in front of it.

CloudFront for a static website not very expensive either.

-----

I run my company's website runs off of S3 + CloudFront, and S3 alone is slow.

Load time is usually 2x to 3x when accessed via the S3 origin

Yup - and Route 53 can now even serve the Zone Apex to an S3 bucket!

Totally agree.

I think the problem is that the definition of what a "Cloud Operating system" is actually is quite loose. Mine would include compute, storage, and networking.

And truly, by this definition, OpenStack did achieve something and filled a gap, as it integrated all these components (and so did CloudStack / Eucalyptus).

I received an email from them - the password was included in the email, in plaintext.

So I don't know exactly what they mean, but it's at best symmetric encryption.

In the past, when an AZ goes down, everyone tries to transfer to another AZ and makes lots of API calls.

Consequently AWS has to rate-limit API requests to avoid taking another AZ down.

Maybe this has changed though, but we'll probably have to wait for another disaster to know!

---

But of course, an AZ shouldn't be your infrastructure's single point of failure!

Switching load or transferring data between a remote DC (your dedicated servers) and AWS is not that easy when you start having large-scale infrastructure though.

This is a great idea on paper - but running your baseline infrastructure at your dedicated provider and the rest on EC2 is definitely a challenging task.

Not that it's impossible, but that's probably going to be extra work at the app level.

---

Running OpenStack / CloudStack, or similar software on dedicated servers is indeed a relevant solution too, but this is an extra maintenance cost to bear in mind.

Programmatic access is a big thing, and is what makes EC2, GCE, Rackspace and friends, different from dedicated hosting. (In the case of AWS / GCE, global availability is something else).

Using the Cloud isn't only about instant scaling and per hour billing. Those are useful features, but mostly for specific use cases.

--

The Cloud it's about the ability to have software that controls the hardware.

It's about being able to orchestrate automated failovers that provision new servers.

It's about being able to have services that grow and shrink depending on usage.

It's about being able to replace your app servers with data crunching servers at night and relaunch new app servers at day - all transparently.

Of course, those are just a few examples, but the general idea is that programmatic access (APIs) is the big thing. The rest is secondary.

---

Is is, however, true that this is not useful to everyone.

On the topic of succeeding using the Cloud, it's indeed difficult. That's why companies are building cloud management tools to help users do this.

Disclaimer: I work for one of these companies.

The title used is extremely misleading: CloudStack [1] actually is software that lets one build their own Cloud, but Parse is not using it, they're using AWS.

Calling it a "Cloud Stack", and not "Cloudstack", would have probably been more appropriate.

Also, the CloudStack name actually is trademarked by the ASF.

  [1]: http://cloudstack.apache.org/

I'm not entirely familiar with how go dependencies work, but does using git submodules for the dependencies with go make sense?

I agree that Nginx would be sufficient.

However, configuring S3 + CloudFront really isn't that much effort (I'd argue it's even simpler than Nginx).

It's not that expensive either! : ) It would probably even be within the free tier if I'm not mistaken.

Regarding the load time, using static HTML with a site generator would yield great results here. There really is not reason to be using PHP here.

A great option is to put it on S3 and distribute it with CloudFront.

Exactly!

There's even a feature where you can post the question and the answer at the same time now I believe!

Even better, using the IP / language settings, they could probably make an educated guess! : )

My thoughts exactly, that would be awesome!

Specifically for Python / Django development, PyCharm is very good: http://www.jetbrains.com/pycharm/

Thanks for the clarification! Might want to add that to the website somewhere, I wasn't able to find it when looking for it there.

Exactly. Any proper implementation of this kind of security should not depend on the username, this would entirely break the purpose.

In this specific case it wouldn't be very practical as changing the password would mean changing the encryption key to all your files. Hence, rendering all files unreadable.

That's why I suggested that a more appropriate application would be to derive a key from the password (using a PBKDF, which PKCS5 is (PBKDF2)) and use that one to encrypt the file encryption key.

This way, you can always change the password (provided you still have it) and encrypt the encryption key again, while not needing to encrypt each file.

The first part of the article is of unusually low quality for Ars Technica. It seems like the author is trying to bash Mega for being reportedly lazy in their implementation. This really is a shame because the parts regarding entropy, deduplication, and the conclusion, are very relevant!

> Files and folders, therefore, are encrypted with symmetric encryption. Symmetric encryption means the same key is used to encrypt and decrypt your data; this is less secure than asymmetric encryption (where one key encrypts and a different key decrypts), but it's faster and easier to implement.

Asymmetric encryption is not appropriate for encryption of large amounts of data (or would require incredibly large keys to work). Symmetric encryption is always used to encrypt large chunks of data, and asymmetric encryption can be used to encrypt a symmetric key. The article seems to hint that Mega was lazy in its implementation, that's not really true.

> For the data stored in Mega, the encryption key used is generated for you at the time of sign-up and is itself hashed—or scrambled—using your account's password.

The key can't be hashed, or it couldn't be recovered. A hash is meant to be un-reversible. Unless the article means that the key itself is a derivation (a hash?) of the password. This would indeed be a major issue! If the key is encrypted using the password (hopefully after running it trough a PBKDF), it is fine.

The absence of a password change option is indeed worrying, but the absence of a password recovery option is reassuring. If you lose your password, then you lose the ability to decrypt your key. If you lose your ability to decrypt your key, you lose your data.

It indeed is problematic that you can't back up the key though!

In that case, you can always opt to return bool(return_value), which lets you return True or False without the ugly if / else : )

Orange does have a strategic position in Africa where Google (for the moment) doesn't. I'm not saying Google needs Orange, but it is indeed a strategic partner.

Orange is also an highly trusted ISP in France, and (unlike Free) counts many corporations among its clients. Google probably would not risk alienating those clients by engaging in an open conflict with Orange.

All in all, I don't think any other French ISP would have been able to wrestle such a deal from Google.

Orange has a very strong presence in Africa. It leveraged this presence to have Google pay for their Internet trafic in France and Europe: Orange is pivotal to Google's success in Africa.

According to Orange's CEO, Google just can't do without Orange in Africa - and that's likely to be true.

Sources (in French, sorry!):

http://frenchweb.fr/trafic-france-telecom-se-fait-remunerer-...

http://pro.clubic.com/entreprises/orange-france-telecom/actu...