William Stein wrote: > On Jan 31, 2008 11:22 AM, Jason Grout <[EMAIL PROTECTED]> wrote: >> >> William Stein wrote: >>> On Jan 30, 2008 2:19 PM, Jason Grout <[EMAIL PROTECTED]> wrote: >>>> Joel B. Mohler wrote: >>>>> On Wed, Jan 30, 2008 at 10:13:09AM -0600, Jason Grout wrote: >>>>>> Now, for the ncurses part. It seems like it would be very, very nice to >>>>>> have a minimal admin menu using ncurses or newt (with the python snack >>>>>> module) or dialog. Each of these has a python module, so hopefully it >>>>>> should be fairly easy. I've never done any text-based GUI programming, >>>>>> but I'm willing to try to whip up something. Are there any experts here >>>>>> that could give some advice about what to use or how to do it (or whip >>>>>> something up even faster)? It seems that an interface that at least has >>>>>> the options to create a remote ssh account, set up sage to start on >>>>>> bootup, and set the networking information for the box (DHCP or a static >>>>>> address) would answer some of the issues above. In the future, we could >>>>>> add to the menu and keep things simple for non-unix people. >>>>> Wouldn't it be much easier to program and use if the vmware image would >>>>> start a >>>>> web server (presumably something from twisted) and provide control panel >>>>> from >>>>> the default IP address? All of these configuration things (which don't >>>>> involve >>>>> vmware player) are quite doable from a web interface. This is would fit >>>>> in to >>>>> the sage web interface idea and also be quite similar to the things that >>>>> anyone >>>>> needs to know to set up any old router that they buy for their home >>>>> network. >>>>> >>>>> All you have to do then is start the image in vmware player, wait a >>>>> suitable >>>>> period of time, load up your web-browser and go to http://192.168.x.x. >>>> That's a good point; it would be more familiar and possibly easier to >>>> use. Are there security issues with this? Having a default >>>> publicly-accessible configuration panel seems like an exploit waiting to >>>> happen (even if we have a default username/password). That's why I >>>> preferred the image being locked down until someone sitting at the >>>> console opened it up to outside access. >>> We should install a _minimal_ X server and window manager, >>> and completely replace the current text view on bootup with a similar >>> GUI that comes from the X server (but hopefully looks like a native >>> windows app as much as possible). This way the users mouse won't >>> get trapped. Also, maybe cut and paste will work. (This is actually >>> how the sage-vmware image used to be 2 years ago.) A minimal >>> X server takes very little disk space, e.g., Damn Small Linux has >>> one and it takes < 60MB or so for all of Linux. >>> >>> People should not have to worry about username / passwords >>> on windows by default. This isn't a problem at all if the vmware >>> image is using shared networking, which is the *default*, since then >>> only the local computer can connect to the vmware image. The >>> only time the sort of security issues that sparked this discussion come >>> up are when one explicitly changes the notebook to use bridged >>> networking. >> The sage distribution by default is also the development environment for >> sage. Someone (you?) said that this was by design and was a crucial >> decision in the growth of Sage. DSL does not include gcc or make, so >> development would be problematic on such an image. Are you willing to >> sacrifice the development environment on an image for the size? >> > > If I'm still going to be the person building, testing, and distributing > the binaries, then no I am not willing to make that sacrifice, since > it means there will have to be two vmware images. If somebody > else wants to take over, then things might be different. Are you > volunteering? I could certainly use a break from being "the vmware > binary guy".
Well, I'm not volunteering yet; I still have yet to build a good first image. I was just wondering if you were suggesting going with DSL and no development environment over something like Ubuntu JeOS with a full development environment. For now, I'll keep experimenting with the full development environments (e.g., not DSL). I think the capability of *everyone* being able to develop and submit patches (like all those high school students in schools running these virtual servers) will continue to stimulate growth and acceptance of Sage. Not to mention that installing most optional spkgs requires a development environment (i.e., gcc, make, etc.), right? Incidentally, I'm seeing that although OS image is only about 500 MB, the total disk space of the vmware files is around 900MB. I've defragmented the disk. I think it might be the swap space that is taking up the extra 400MB. Does that sound right? Would it be reasonable to run without swap space or is there some way to somehow get the size of the image down? Also, how do you install sage to /usr/local like on the current vmware image? Where do you put the mercurial repository? Jason --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
