On 3/10/2011 9:04 PM, Stuart Johnson wrote: > >>> Meaning you think python would be too heavyweight? >> Certainly as one approaches the embedded end of the spectrum, there's >> something to be said for avoiding dependencies on large (compared to >> busybox ash) interpreters. It'd be neat if I could deploy per-service >> containers on, say, a router with an 8MB MTD and 32MB RAM, and using >> python/perl/ruby/whatever would make that harder. Maaaaybe lua would be >> a better fit; I tend to stick to busybox ash, since it's already there. > > Perhaps we should be asking first, should an ncurses control panel be > part of LXC or a separate project? If it's the latter, then its rather > immaterial, although personally I would love it to be part of LXC. I > want to able to install LXC on any Linux box, and start managing > containers with the least amount of effort.
The embedded example just shows how everyones needs are very different. I can see that wanting the lightest of non-interactive shell scripts run as cgi from a web server and all ui done via browser, or possibly run directly by the web server from a built-in mod_php or such with no use for ncurses at all. I say let the main lxc package just continue to make better non-interactive command line tools, and let all higher level front-ends be separate packages written in whatever language(s) the authors like, serving whatever diverse special purposes they may. Ideally of course would be to improve libvirt and/or other virt managers add lxc support to them and modify lxc relatively little just to facilitate that where indicated. -- bkw ------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d _______________________________________________ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
