What's a suitable run-time for apps?

[augustl]

We want apps to run in an environment specified by protocols, so that there can be multiple GDS implementations. What should this environment be? Should each app have a *nix container? Should apps live in some kind of VM using a specific language that all GDS apps have to use (JVM? Node?), in order to achieve full cross platform compat for apps?

[augustl]

Should GDS be platform specific and require unix? If so, should it be distro specific? Docker.io could be used to manage dependencies in a distro-unspecific way. In that case, should GDS be a package for multiple distros, or a distro of its own? Do we need sandboxing, and how do we do that in such an environment?

Alternatively, GDS could choose to roll with something like the JVM. The JVM has Java, Clojure, JavaScript, Ruby (JRuby), Python (Jython), Groovy, Scala, and many more languages. It is very good at being cross platform compatible. It has great sandboxing features. And so on and so forth. Some people seem to find the JVM offputting, but I think that's because they assume you have to write Java? Who knows. Perhaps it's a bad idea to depend on Oracle as well, since they're 100 evil. :)

Alternatively, Node can be considered an appropriate run-time. But it's not very low level, you need to write native C++ code if you do heavy computational work in-process, for example. You do have some polyglotism though, with Coffeescript, ClojureScript, and so on.

I think it is important to keep in mind that having multiple implementations of GDS should be possible. Perhaps easy install on windows servers is also a requirement? Or is it enough to support windows via virtualization such as virtualbox or vmware?

[waaaaargh]

I don't know. The vision I had for GDS was to port existing Free/Libre Open Source Software such as roundcube as a webmailer or wordpress as a blog, perhaps fork them to integrate them better with GDS or improve overall user experience. and just let them run in a 'sandbox' that prevents them from accessing data they're not allowed to acess.

I think we shouldn't focus on one runtime but an API that apps can access from any environment.

[sternenseemann]

I agree with @waaaaargh I don't like the Idea of a runtime which every Application needs to run in.

[tobiastom]

I agree with @waaaaargh and @lukasepple :)

Having a safe environment to run current software in should be possible. Maybe not as easy as the optimized apps, but if the system knows how to install them, they should be usable.

[augustl]

The only real downside I can think of with not having a GDS specific run-time, is that an app will be tied to a specific platform. Which isn't a bad thing imo :)

What about things like sandboxing though? I do think that counts as run-time. One of the main points of GDS is to make it easy to install apps, once you got GDS set up. How will we achieve that, when we don't know what to expect of the app? Perhaps the app only runs on windows, when the GDS is installed on a Debian box. How do we detect and handle that?

[lukasbestle]

I guess most apps will be web applications based on scripting languages like PHP, Python, Ruby or Node.js. Of course there are some compiled apps/binary stuff which won’t work everywhere - but this is a minority of all apps. We still have to handle that, you are right…!

[augustl]

I think it's safe to say that this will all be web apps, yeah. There's no reason to limit them to that, though. Perhaps you want an app that is nothing but a backend to your mobile app, and for that you want to use ZeroMQ instead of HTTP :) That should be possible.

I've not yet really understood how docker.io works, but it seems to me that the goal of docker.io is to provide packages of apps that can run and be installed anywhere. Perhaps GDS should require/piggyback on docker.io, and the only real GDS-y thing about them is that the apps inside the docker.io container implements the correct protocols so they can be talked to in a GDS-y fasion.

[lukasbestle]

We already talked about Docker - it’s totally cool but will be a bit of an overhead, though.

But yeah, apps should not be limited in any way. They can request access to specific databases/database versions and to specific runtimes. There would be installation scripts to customize the sandbox of each app however it needs it.

[waaaaargh]

@augustl I don't see why an app should not start a zeroMQ server socket. It gets its own user and is being started/stopped like every other server.

Webapps, especially PHP might require some addition fucking around in order to keep them isolated from each other.

[augustl]

Interesting that you mention PHP. I tried to setup my own trovebox instance, but gave up after about an hour of it not working. All of which was problems with my Apache instance. So I think it's a requirement that if a PHP app depends on Apache, it should spawn its own Apache instance, and provide its own Apache configs. Even better, run the PHP app without apache, if that's possible :)

On 31.10.2013 18:17, Johannes Fürmann wrote:

@augustl https://github.com/augustl I don't see why an app should not start a zeroMQ server socket. It gets its own user and is being started/stopped like every other server.

Webapps, especially PHP might require some addition fucking around in order to keep them isolated from each other.

— Reply to this email directly or view it on GitHub https://github.com/grand-decentral-station/concept/issues/33#issuecomment-27506166.

[keybits]

With relation to Docker and overhead: Docker containers can start up in about one tenth of a second. So for a lightly used personal server, most of the apps could be 'off' until needed. Docker is currently improving it's process manager support and is already quite controllable via systemd. CoreOS might be a good base for GDS. That's where I'm hoping to take my Keybits project (http://keybits.net)

[Edit] more background on CoreOS, etcd and Docker here: http://coreos.com/using-coreos/docker/ This is a dream from a hosting providers perspective - applications can be spun up on demand in milliseconds. It also helps solve the criticism that decentralizing has a 'poor performance per watt' and negates the need for 'selling server power' as mentioned here: https://github.com/grand-decentral-station/concept/blob/master/concept/network.md#selling-server-power