One of the big disadvantages to using web frameworks like Rails or Django for open web applications is that the deployment is very tedious, at least compared with something like PHP. Something that requires having root access to a *nix server and takes 25 steps to install is never going to be mainstream - you need something that a 13-year-old could put up on a shared hosting account (i.e. phpBB) to really get traction.

Yup. Appleseed is LAMP and built to work on shared hosts, and it installs in a few minutes.

That was by design from the beginning. I considered using Python or Ruby at points, but PHP was the easiest way to satisfy those requirements

I deploy django+myapp+modules in to a virtualenv[1] without any permissions other than default user perms in a Unix box. The only 'tricky' bit is setting up the database, that requires more permissions (and for good reasons).

It's completely possible to make to make it simple in any language. I agree with the point that currently the Diaspora installion instructions are a bit excessive though.

[1]- http://pypi.python.org/pypi/virtualenv

But then you still leave the user responsible for getting the site up and running under mod_wsgi, etc., correct?

yep, they can deploy via any modern web server but you're right I don't really have any control over that. I don't see the difference to PHP though, you still need to install PHP modules, additional php libraries (via PEAR maybe), set permissions etc.

Have you heard of Heroku? They were YC's largest exit to date largely due to solving exactly that problem! It doesn't get any easier than Heroku.

Heroku's great, but the cheapest plan they have is $36 a month. There are shared hosts out there that cost $1.99.

Actually, their cheapest plan is $0 and it works great.

Isn't that just for prototyping/development?

That depends on your traffic. It includes one worker.

You should be thankful the tutorial used pre-built Ubuntu packages and didn't include manual compiling.

There should be simpler installation instructions with rvm. Or using Heroku. Or someone may provide pre-built EC2 images. I'm sure you could reduce those 25 steps to one-liner (although it would be cryptic).

There are endless possibilities to automate the process, it's just that this exact article does everything by hand.

A lot of that is packaging issues. While they might never be able to get it down to a one click install, one installer script could probably take care of most of those steps at some point.

I haven't looked at diaspora in 3-4 months, but based on where it was then I find it hard to believe that anyone should be downloading and running it right now that isn't a developer/SA type and expecting a fair degree of pain. In that way the install process is a bit of a gatekeeper. If they made it super ultra easy to install and run but code quality / feature completion was still in the toilet what would they have gained? No reason for them to work on the installer right now.

I'm not too sure diaspora is going to end up all wine and roses, but they only claim to be in "alpha" release for now, give the kids a break.

THIS IS PRE-ALPHA SOFTWARE AND SHOULD BE TREATED ACCORDINGLY. PLEASE, DO NOT RUN IN PRODUCTION. IT IS FUN TO GET RUNNING, BUT EXPECT THINGS TO BE BROKEN.

While the idea of Diaspora is nice and all, I'm not going to start using it until someone convinces me that I don't need to audit every code change. Removing commit access for all of the core developers would be a fantastic start.

For those who aren't aware of the issues[0] that were revealed several months ago, Diaspora's devs made some rudimentary security mistakes. Yes, it's an alpha, but as pointed out in the HN thread (which I did not save, and am too lazy to search for), this was basic security - the stuff you have to keep in mind from the start, not stick on later.

[0]: http://www.kalzumeus.com/2010/09/22/security-lessons-learned...

In practice it's meant to run like email--most people don't register a domain, provision a server and install a mail server / webmail app / spam blocker. They just use an existing server, be it their ISP, Gmail, Yahoo, an employer, or whoever. It's nice that I can set up my own, but it's also not the path that 99.999% of people take.

Someone stick it on the EC2 public instances list... There's your 3-step setup...

Most people won't have to do this. Most people will just join an existing site. Diaspora is much more significant in that it solves the gay bar problem of social networking (http://www.slideshare.net/padday/the-real-life-social-networ...) and that it lets you export your data. It remains to be seen if they make the system of "aspects" simple enough.

That said, it's a little annoying that a supposedly open product can't be installed in one command.

> Diaspora is much more significant in that it solves the gay bar problem of social networking

I had to go through the slides to understand this: basically, it said in the case of a woman they did research on, she commented and liked photos of her friends at the gay bar, but her ten-year-old students could see those comments too. The thesis was that a bunch of her social groups that shouldn't interact were forced to interact on Facebook.

Now that that's overwith (if you were as confused as I was), how does Diaspora solve this? I'm honestly asking. Do you not see updates on another service, or something?

It created "Aspects", or groups of friends, and you post things to specific aspects or to all aspects. Only the people in that aspect will see updates.

So, posting is limited to friends? Friends of friends? Friends of friends of friends? Search? Public?

So, Facebook groups?

They've tried to solve the blurring social contexts problem of facebook with something called 'aspects.' Aspects are user defined sets based on social context, eg 'work', 'school'. You can choose to make any activity on diaspora visible to certain aspects, and defining aspects is supposed to be pretty central to the diaspora interface—although I haven't ever used it so I can't really say for sure.

Facebook kind of solved this problem in the meantime by making facebook groups more intuitive. When diaspora was first announced, this social context issue was perceived as a bigger problem with facebook than it is now.

It sounds like it will get simpler. From the site:

"We deploy and run Diaspora with a deployment tool called sod, which currently only supports CentOS. We use Rackspace Cloud, but you can point sod at any CentOS machine. Sod is unfinished and probably has hardcoded configuration for our servers. It is not ready for use."

I imagine that once it has been around for a while, you'll find Diaspora packaged in all the major distro repositories.

What surprises me is the number of different servers that need to be run, tho I figure that's more my lack of experience with commercial grade social networking software.

The problem is that if there's a high barrier to entry there might be a "Google Wave" effect - people joining, finding out they have no friends on the service, and never using it. What the distributed social network market needs is a network that has an actual launch with a product, and get as much press as Diaspora did when they announced, but have an actual product.

I think there's a typo in the submission--this looks like installation instructions, as opposed to just "join & use" instructions.

What an improvement over the tedious Java version which would run with "java -jar diaspora.jar" (or a double click on Mac/Windows)!

I didn't realize that Java now comes with MySQL and a Redis server bundled.

So DON'T USE THEM. Srsly, are we professionals or script kiddies here?

If you're going to provide an alternative to Facebook, you can damn well make something from appropriate technologies. pg doesn't even use a database for Hacker News, and while it has it's problems, it does quite well. That fact that 5 people agreed with you disappoints me.

hsqldb is more than adequate for a diaspora node. diaspora in a jar is completely doable and outperforms any rails/django setup.

At least the instructions are thorough. Someone with a small amount of system admin knowledge could probably get it up and running. They could have just gave a short explanation that only anyone who does develops web apps or system admins all the time would understand.

I got a pod up and running a day or so after the initial code drop, as a test to see where things were at (which I toyed with briefly, then removed; I haven't poked at it much since then).

Please trust me when I say, the instructions available today are vastly better then the state of play when they initially released; if you didn't have some Rails experience going into it at the time, you were probably not the target audience. ;)

I plan on deploying this over the next few days to a fresh server for the 'lulz' factor.

As mentioned already, I really did expect something a little more simplified for an open-source application. That guide is most likely going to take a couple of hours to work through.

Sure, it'll be worth it, but should it be that complicated. Someone should try and script this using Fabric! :P

I was starting to lose my faith in diaspora as months went by and there was no progress to be seen but I love the concept of a service with distributed infrastructure. If diaspora proves it to be a working and applicable model I think a lot of other services will emerge using similar models. especially music stuff, think new napster.

What a joke. Doesn't work on Windows. Fine, I'll buy that. Doesn't support IE. How hard is it to just use a good CSS Reset these days? We knew this wasn't going to kill Facebook, but it's not even going to get laughed at if only 2 people can use it.

Facebook's server-side code wouldn't work on Windows, either. IE support is coming according to the page, but it makes sense to develop initially for the more standards-compliant browsers.

25 steps? The conversion on this funnel must be < 0.00000001%

I tried these instructions and got bupkis.

TWENTY-FIVE steps is not "simple". =)