Re: [Freedombox-discuss] FBx Configuration Management
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
Re: [Freedombox-discuss] FBx Configuration Management
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:allhttp://zguide.zeromq.org/page:all) and zerorpc (https://github.com/dotcloud/**zerorpc-pythonhttps://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.orgFreedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.**org/cgi-bin/mailman/listinfo/** freedombox-discusshttp://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
Re: [Freedombox-discuss] FBx Configuration Management
On Sat, 23 Jun 2012, Nick M. Daly wrote: Bryan, thanks for sending this along. I don't have any answers, but these are pretty fundamental questions. Thanks for the reply! Does anybody else have any guidance or insight? This is more than I want to bite off on my own. In case this thread fell off the radar, the original message is here: http://www.mail-archive.com/freedombox-discuss@lists.alioth.debian.org/msg03428.html I know there was some talk about using James's withsql [0] package for at least storing custom application-specific settings (for, i.e., Plinth and FreedomBuddy) but that doesn't really solve configuration management problems. I'd like to see something that can be hooked into Plinth and built upon there, but maybe there are other, more important criteria. Does anybody know any details about said system? Searching the wiki and discuss mailing list archive didn't turn up anything helpful. Is there some other medium where development planning is taking place? -bryan ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] FBx Configuration Management
On Wed, 20 Jun 2012 22:16:32 -0400 (EDT), bnewb...@robocracy.org wrote: General purpose Configuration Management seems to be a crucial component of the FreedomBox software stack/distribution. It needs to be secure, accessible (elegant user experience for diverse userbase), reliable, robust, etc. Bryan, thanks for sending this along. I don't have any answers, but these are pretty fundamental questions. I know there was some talk about using James's withsql [0] package for at least storing custom application-specific settings (for, i.e., Plinth and FreedomBuddy) but that doesn't really solve configuration management problems. I'd like to see something that can be hooked into Plinth and built upon there, but maybe there are other, more important criteria. Nick pgpxTJGxgOtMh.pgp Description: PGP signature ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
