I don't think we should start trimming features just because we think heavy usage might be too much for the hardware. If we make a per-user solution now, it doesn't really add overhead for single user cases that we can use now on dreamplug servers, and it would be really useful to have good multi-user configuration management on non-dreamplug servers or future plug servers.
Michael On Tue, Jul 3, 2012 at 12:51 PM, Brian Drake <br...@drakewolf.net> wrote: > My experience with the dreamplug/ et all devices and having multiple power > users is not great. I really don't believe they are powerful enough to hold > multiple virtual hosts (would love to be proved wrong) > > It was fine for lightweight use but as soon as any kind of heavy IO activity > kicked in there was none of the good shared resource capability of a full > powered desktop/server. One person doing a lot of IO and the thing would > pretty much halt and wait for it be over before moving along. One person, > when you are the one telling it to do X, will be patient with the occasional > slow down. When you don't know that X is happening it gets really > frustrating, really quickly. > > Brian Drake > Austin Texas > 512.850-6326 > http://www.linkedin.com/in/brndrakeecoit > Schedule a Meeting: http://tungle.me/briandrake > > > > On Tue, Jul 3, 2012 at 11:46 AM, <bnewb...@robocracy.org> wrote: >> >> >> On Mon, 2 Jul 2012, Michael Williams wrote: >> >>> To add to what you said, I think we should definitely have fine >>> grained access control to system-wide configuration. The idea of a >>> shared server resource between individuals has been dawning on me, so >>> I really want a way for people to share their FBx with other people, >>> and still let everyone configure their own services. This same concept >>> should expand to any type of server, not just plug servers. >> >> >> Thanks for the reply! >> >> To me the most appealing way to have multiple hosted individuals on a >> single box would be to create lightweight virtual machine containers for >> them so that each user gets a proper login and can fully customize their >> environment. I don't know if this is feasible on the DreamPlug hardware, I >> ran in to trouble getting LXC up and running. >> >> I don't know anything about existing strong access control mechanisms for >> systems configuration (windows registry? d-bus? something gnome? android?), >> and it seems like too much to build in a day or two, so next week i'll >> probably just go ahead with a single user system. >> >> >>> About the current Plinth set-up, I'm interested in making a per-module >>> platform using zeromq (http://zguide.zeromq.org/page:all) and zerorpc >>> (https://github.com/dotcloud/zerorpc-python) instead of python >>> modules. I like the idea of allowing services to be written in any >>> language they want, as long as they abide by a common message-passing >>> protocol. I can imagine the topology being: >>> >>> client -> front-end -> per-user service -> per-user/per-module service >>> >>> OR >>> >>> client -> front-end -> system-wide/per-module service. >> >> >> I don't understand the motivation. I guess I assumed Plinth modules would >> be very small user interface wrappers around existing services or tools >> which are already written in many languages. >> >> -bryan >> >> >> _______________________________________________ >> Freedombox-discuss mailing list >> Freedombox-discuss@lists.alioth.debian.org >> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss > > _______________________________________________ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss