andrewgodwin

Not to mention the fact that you have to have a really wide range of knowledge to cover that full stack of management and security - from raw networking to database management and everything in between. We're fortunate that our skillset just about covered it, but throw in support for all the popular web languages and it's unlikely you'll pull it off without 3 or 4 people, minimum.

(I'm one of the two Epio founders)

Obviously, we have an interesting view on this whole problem. I'm personally of the opinion that PaaS is still not quite the right solution - there's certainly some progress, but there's such an murky boundary between what a platform and an app provides that it's hard to make something that doesn't surprise people in some way.

It's interesting to note that as a PaaS platform you do get an advantage over IaaS - you can share resources and box-pack apps a lot more efficiently when you control memory and disk access at that higher level, so it's not like IaaS is certain to win either.

I probably need to compose my thoughts into something more intelligible and write a full blog post about how I think deployment should evolve, but I have a migration to shepherd first.

Not to mention the obvious legal ramifications, even of encrypted data - in the UK, it's a crime not to give up the key to encrypted data, even if you claim to not have it (though I would hope in this case it's provable you really never did, and that would somehow help.)

From what I understand of the technology at play here, it seems like it could be defeated by a pair of earplugs (or, if you're in a conversation rather than a speech, then a microphone/headphone combination with an additional short delay) - though I'm by no means qualified in this area!

Still, even if there is a workaround, it seems impractical to wear all the time.

My main concern with this is discoverability - menus are helpful in that they convey a very precise listing of the app's possible actions (when designed well), something that's hard to otherwise come by.

Blender is perhaps the extreme example of this - it has an incredible amount of features, so they can't be placed into menus, and you spend some time learning where (in the hundreds of panels) or which of the thousands of keyboard shortcuts to use.

That said, I find keyboard-driven user interfaces very powerful, so I'm curious to try this out. Fortunately, there's been a way to turn off Crazy Ubuntu Features in most releases if you know how, at least so far.

I like that once again the approach of "build it and deploy something on it" seems to work more effectively than "specify it over a five-year intensive period".

I imagine that's just my inner lazy engineer talking, though; there are some protocols that would definitely have been better off specified properly from the start (I'm looking at you, SMB)

I find the article a little overzealous; while I'm no staunch capitalist, including sentences like "The web in its current, open state is a threat to capitalist ideals" doesn't help convince me about your goals.

And yes, while this is partially true, a lot of legitimate businesses and people who aren't motivated enough to "go dark" also drive the internet, and they're not going to be so easily forced underground - any such internet would be a shadow of its former self, and an easy thing for governments to demonise with the usual examples (drug trafficking, child pornography, etc.)

Ah, interesting, everyone always seems to forget apache. I imagine it still doesn't support the holding-connections-open-during-bootup bit, though?

Exactly, as at Epio all our backends are identically sized. Obviously this isn't the case for everyone - but it's easy to add that code.

There's no sticky sessions, and the balancing is purely random (so statistically roughly the same as a round-robin) - it was primarily designed for large numbers of small backends, rather than one or two sites with ten backends, though we'll be adding in more balancing types as we go.

In the article I cover why we moved away from HaProxy; someone's also asked me why we didn't choose Nginx. It's because we needed HTTP/1.1 support to the backend (for things like WebSockets), which Nginx doesn't have (yet).

Epio cofounder here - we're not worried by this, and we've known it was coming for ages now.

The hosting market is plenty big enough for more than one player - we're expanding to multiple languages, much like Heroku expanded from Ruby, which provides an ample feeding ground of old-style hosts to slowly steal business from - and there's also still a lot of room for innovation.

Heroku, as much as I like their product - and I do, which is why we started this a year ago - still has its flaws and idiosyncracies, some of which are those low-level-design type of choices where if you go the other route, a different set of people complain. You can't be all things to all people, and I don't think anyone will end up being that.

Ah, now that looks useful - thanks! And it supports AAAA records, thankfully.

We've (Epio) been using Route53 for 6 months or so now, and have had zero problems with it. The main problem is, as others have said, that the only way to interact with it is via the (somewhat cumbersome) API.

We got round this by writing our own Python command-line tool using Boto, which sadly I have yet to release...

I'm not even sure it is legal in the UK - we have laws against "unfair contracts" [1], and there are also some statutory consumer protections that can't be waived. Of course, this is about security breaches, and IANAL, but I'd say this doesn't stop all potential lawsuits.

[1] http://www.oft.gov.uk/about-the-oft/legal-powers/legal/unfai...

Interesting - we run a pretty large entirely eventlet-based system, so I'm excited to try this out on that. That said, our threads often number in the thousands, so I'm unsure how this would cope with that.

Near the end, the article touches on the fact that orientation matters for the phone part, but not the software - part of me wonders if even that is necessary.

Would it be too hard to install two microphones and two earpiece speakers in the thing? I imagine they'd also have to have some kind of weird aerial switching as well, though, as traditionally those are always at the one end; I seem to remember it was to pass regulations.

Not only that, but it's mostly compatable with things like .tmLanguage files, so there's even some cross-portability there.

(I've never used Textmate, being a Linux user, but being able to benefit from the ecosystem to get e.g. .pp file highlighting is great)

This is actually pretty similar to what we've got so far internally at ep.io, albeit without the procfile and with a slightly more complex definition instead.

We're even running things like Redis instances off of a similar codebase, albeit one modified so the >1 server case is different.

Edit: Oh, and of course we're not exactly as open and launched as Heroku are. Just pleased to see that other people think it's a sensible way to build this stuff!

We use powerline networking at home, and it's pretty decent - nowhere near the speed of actual ethernet, but a good 70Mbit or so.

I'm always surprised how few people know it exists (well, at least in the UK). You can even get nice combination hubs-and-powerstrips - getting six power sockets and three ethernet sockets off of one main plug is quite handy.

I'm not sure that GAE is the ideal environment to run Django in - the whole reason it scales is because it enforces a certain way of doing things (nonrelational datastore, no long-running processes, no local storage).

General Django PaaS will probably be 'nicer' with the various less-restricted options that are springing up (be that mine, ep.io, or others, like djangy, gondor.io, apphosted, or the several others I forget), since those tend to lessen up on the "it must scale" aspect and focus more on making the 99% majority of sites (i.e. medium sized or smaller) work well.

It's pretty rare a NIC allows two letter domains so it might be a general limitation, but they are possible. Either that, or our domain (ep) is just a very persistent hallucination.

Two-letter ones are 'cooler' - we grabbed ep.io a few months back - but the NIC don't allow language or country codes as two letter domains, IIRC. Still, there's plenty left, as petercooper's comment says.

The main problem with the fragment change solution is that it _doesn't work without JavaScript_. And we're not talking for the one user browsing the site - any links people post (on forums, mailing lists, etc.) that have fragments in them are simply unusable for people without JavaScript, as the server does not get sent the fragment - the best it can do is send a generic "oh, sorry, no JS" page back.

This would be a problem for search engines as well, if it wasn't for the awful translation Google said they'd do. It's just breaking the meaning of fragment identifiers completely, and that really makes me worried.

My favourite part of the program archaeology is when he digs right down to the core and discovers the computers are still keeping time in seconds since the time when man landed on the moon (and then discovers it's really a time a bit more than five months afterwards).

I never did think of UNIX time as tied to the moon landings that closely, but it's a nice fact. It was still odd seeing small negative timestamps when we were working on spacelog.org, though...

As one of the two people working on something similar to Heroku or GAE (we're called ep.io), Beanstalk is simultaneously worrying and quite interesting - while it is an interesting player into the market, it's not _that_ hands-off, from what I can see, especially when it comes to databases, or things like Redis, which it's nice to have managed for you as well.

It's possible we'll see people springing up on EC2 offering those as separate services, however.

The other interesting part is that, since they don't do shared hosting but make you use a whole EC2 instance, there's potential for it to cost considerably more for smaller sites, but only once you get past that free plan of theirs (then again, the disk I/O on the Micro instances is truly awful)

Not only that, a DDoS can cost quite a bit in extra bandwidth costs (I've had a couple of small ones chew through a suprising amount). It's a bit more of a substantial repercussion in addition to hitting "brand", and often affects smaller companies proportionally more.

A point that might be interesting for HN people: the source code is freely available on GitHub at https://github.com/Spacelog/Spacelog

We also made sure the missions were in a VCS-friendly text format, so people can fork and merge in changes (everything, down to all the images, ships in a single mission folder, so it's pretty reuseable for different missions)

The part I find worst is the comment saying that it's still alright because, statistically, "more sex offenders are male".

If that's a valid judgement call, surely the fact that most child sex offenders are relatives/acquaintances of the victim rather than strangers means it's safer to sit the child away from their family and friends? I get slightly annoyed by these misuses of statistics.

I'm not sure I'd say it has "won" - such a phrase implies a long-term positioning at the front of the pack, and those that came before it for code hosting (SourceForge, Google Code) enjoyed their time in the spotlight before having something new come along.

BitBucket in particular have made a good attempt after the Atlassian takeover, with the infinite free private repos being the most interesting part - I use it a lot, but mostly because I do a lot of small personal projects, and so the "social" features of GitHub - those which benefit most from its prominence - are mostly meaningless to me.