Platforms

[waaaaargh]

We somehow should decide on which platforms we want our software to run. In my opinion, we should include:

• "low end boxes", i.e. small VPSes with only a small amount of RAM.
• Raspberry Pi's
• Just about anything capable of running a current Linux Kernel and a bit of Hard Drive Space.

IMO we should focus on VPSes running on OpenVZ and KVM/Xen, because they are by far the cheapest to rent (The reasoning behind this is: "Hey, I just want mails and a blog, but I don't want to pay EUR 50.00 per month!").

[hnrch02]

So here are my two cents on this topic:

VPSs have the huge advantage of a pretty high uptime and a powerful internet connection while Raspberry Pis depend on your home DSL connection and your home power network but they kind of give you the ultimate control over your data. Theoretically you could unplug the Pi at any time without somebody else being involved in it and your data would no longer be accessible (leaving the backup on diffrent GDSs out of mind for now). That is more consistent with the general idea behind Grand Decentral, IMHO.

So I think we should focus on Raspberry Pis but keep VPSs in mind at any time, so that users who need a faster station can always opt for a VPS but people who like to be in charge of their data can have a Pi at home.

[waaaaargh]

I think we're not writing any platform-dependent code anytime soon, so supporting multiple hardware platforms shouldn't be too much effort.

Ideally we would offer installation images including:

• .iso for x86/amd64
• .img for arm/raspi.
• whatever it is that OpenVZ wants as template.

If we work from a base that covers all the platforms we need (e.g. Debian), this probably is not much of a problem.

[lx4r]

@waaaaargh Sounds very reasonable, we shouldn't worry about the compatiblity too much as long as we're using some kind of common base as you said.

[hnrch02]

I definitely agree, I was just suggesting that we focus on the lowest common factor and not assume that the system is installed on a VPS. Also a VPS is most likely to cost a monthly fee while a Pi is acquired once and after that has no continuous cost (except for your internet connection but without that it wouldn't even make sense to have a GDS).

[tobiastom]

I've already talked with @bastianallgeier about it. IMHO we should define a protocol – not a concrete implementation. Some specification that tells implementors (us) how to do it. Maybe we then would have a Linux implementation, a FreeBSD one, one for Mac OS X desktop or even one for Windows.

[bastianallgeier]

I love how discussions are already pretty technical, but at the same time I agree with Tobias that we should keep it more abstract at first.

In my talk in Nürnberg I spoke about how the guys from hood.ie do something they call dreamcode. Instead of starting with the technical implementation for their frontend library, they design the APIs first and once they come up with the perfect solution, they reverse engineer it. That way we won't get stuck in technical discussions right in the beginning but everyone could just come up with their dream of how this system should work from a developer or user stand point.

Let us do something similar. Let us think about the various aspects such a system would need to provide for developers and designers in order to make it really enjoyable. I think it's especially important to make it enjoyable for developers as this would help with the adoption of the system and also it would assist developers to come up with very polished apps for it.

Let us move on defining certain parts such as how the perfect mail server implementation would work and how it would integrate with applications, how a global asset server could help developers to handle/compress/combine/minify assets for their applications and tasks like that. Let's just write all that down in a way how it would work best and not how it would be the most easiest for us to implement.

We can still get out the scissors in our head later and start thinking about technical possibilities.