> On Dec 21, 10:49 pm, "William Stein" <[EMAIL PROTECTED]> wrote: > > Should we view Sage primarily as software in the traditional sense > > of a local binary install with a GUI, or as software in the more > > web-based community sense? I view Sage as being more > > of the latter rather than the former. > > For me, gmail provides a viable alternative to Opera mail, > > kmail or Mail.app -- I used to use those programs, but now I do all > > my email in gmail. Given the impressive success of browser-based > > community software in recent years, it is not a crazy to think > > Sage could provide a useful alternative using a similar approach. > > > > Well, that is how you see Sage, but having a local development > environment is something I would see happening sooner or later. Sage > should work in a way the users wants it to and for many people that > means a local install. I never use the notebook since I don't like to > use web applications for any serious work. Many people disagree with > me on that one, but I don't care ;)
I'm certainly not saying a web interface is the only one for sage; just that it is a very important one. I use the notebook and command line about equally, personally. > > For example, last night I had a long email discussion with the UW sysadmins, > > computing committee, etc., who initially wanted to roll out Sage on all the > > Windows PC's in the department. After a lot of discussion, it became clear > > that it would be better for everybody involved if we setup an > > internal UW math faculty-only Sage notebook server. Then faculty can > > easily share worksheets, they can use all the commercial software on > > the central server from sage (Mathematica license issues aside), upgrades > > are very easy, and -- most importantly -- they can easily use exactly the > > same sage worksheets from at home, when traveling, etc., as they do > > from on campus. > > > > That said, it is clear that a *lot* of people both want and need to download > > Sage and run it on Windows machines -- the sage-vmware download is > > more popular than all the other download types, and there are cases > > like John Voight where running Sage on a bunch of Windows PC's in a lab > > is very useful for distributed computation. I think 99% of these people > > could care less how we package sage -- natively, via cygwin, via > > virtualization, > > etc. -- mainly what they care about is whether or not it Just Works, > > whether or > > not the install process is easy, and disk space issues. Regarding disk > > space, > > keep in mind that a normal install of Mathematica is 1.1GB, so to provide > > a viable alternative, keeping with 1GB of disk space usage is OK. > > Sure, it works today, but I think virtualization on PCs is still an in- > mature technology. It's been heavily developed for over 10 years. I don't think it is any more immature than a lot of other technologies out there. Most things in computing are immature. > It has a pretty big performance impact (a non-issue > for the casual user), but certainly an issue for people like John when > he is using the Lab on the weekend and nights to do computations. Disk performance is slow, but that's not an issue for John's calculation. For CPU bound work, the performance impact is not that large, at least with modern intel processors. In fact, often performance is *better* in vmware than native, since Linux is a better OS performance wise than Linux and OSX. Here's a typical example of what happens in practice: On OS X Xeon 2.6Ghz native: sage: time n=factorial(10^6) CPU times: user 1.87 s, sys: 0.11 s, total: 1.99 s Wall time: 2.01 In a VMware image running on the same machine (64-bit debian): time n=factorisage: time n=factorial(10^6) CPU times: user 1.01 s, sys: 0.10 s, total: 1.10 s Wall time: 1.12 Using 32-bit Debian in VMware on the same machine: sage: time n=factorial(10^6) CPU times: user 1.83 s, sys: 0.18 s, total: 2.01 s Wall time: 2.04 The reason that the second is so fast is that the above benchmark takes advantage of GMP being built 64-bit in that case. There is a 1% performance penalty above with both running 64-bit. I see this sort of thing all the time -- frequently for CPU-bound computations, running Linux in a virtual machine, even 32-bit, is as good or even _better_ than running the same computation natively under OSX, and presumably under Windows. The reasons probably involve developers optimizing every level of the toolchain more for Linux than Windows or OSX. A good example of this sort of thing is MAgma, which is often literally hundreds of thousands of times slower running natively on OSX as on Linux... Anyway, people using Windows as their main computing platform are probably not worrying about small performance penalties. > But a lot of people do not have the expertise to get the VMware image to > run, while they certainly can click on some installer and run it. Anybody who can point and click can install the vmware image. It is not that hard. You install vmware -- which is trivial standard point and click. You extract a zip file. Then you double click on the blue sage icon. That's it. And you get something that won't mess up your computer, that can be paused at any time, copied/moved to another computer, etc. > I see the VMWare image as another delivery vehicle for Sage on Windows, > but I don't think it satisfies the needs of 99% of potential Sage on > Windows users out there. I definitely don't think the current version does either. But I think the main reason has more to do with Sage itself not satisfying the needs of 99% of potential users. > > So in evaluating which approach we take with Sage to MS Windows, > > we should focus mainly on how the end result will work, rather than anything > > about the underlying technology. I.e., if via virtualization one can > > roll something > > out that works better than a native port, then virtualization wins; if not, > > then > > a native port wins. Simple as that. As far as strategy goes, I > > think the best > > plan is: > > > > (1) Create a usable virtualization method to run Sage on Windows (done) > > (2) Create a really good virtualization method to run Sage on Windows > > (3) Earn many Sage under MS windows users. > > (4) Use 3 to fund hiring a couple programmers full time to make a much > > better way to run Sage on Windows (whatever that turns out to be). > > > > If there were a million devoted users of Sage on windows via some sweet > > virtualization approach, I bet we could easily get funding to hire a > > few programmers to > > work on improving usability of Sage in a windows environment. > > Having more open source mathematical code run natively on Windows > would be a side benefit of the port. And as the download number for > maxima clearly show that is where the majority of the users are. If > maxima were to offer a VMWare image only for Windows do you still > think that the Windows download would still be 10 times the number of > the rest of the downloads combined? I don't think so. I don't know. It probably depends on how good the VMware image is. In any case, Maxima is certainly not a model of success to aspire to, at least given what we're trying to accomplish. > > > > Since Sage is almost completely a volunteer project, I hope developers will > > do what excites them most. Just do it very very well. Oh, and make sure > > your > > code is readable since odds are you might be way too busy to work on Sage > > in a few months! > > > > Well, since I have nothing better to do I will certainly spend the > next two weeks on making a first step in the direction of the native > Windows port and might even revive the Cygwin build. So far no linker > has successfully stood in my way forever, and I will break its > resistance to linking a dynamic libSingular! Ah, now my secret plan is exposed! By arguing with you I'll inspire you to do what I really secretly want you to do. :-) William --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~----------~----~----~----~------~----~------~--~---
