[Please respond on sage-windows...] On Tue, Apr 19, 2011 at 9:50 PM, Volker Braun <vbraun.n...@gmail.com> wrote: > If you are fine with using a virtual machine then just punch the notebook > port through. The only thing running native would be the browser rendering > the worksheet. Of course you need admin rights to install a virtual machine, > and there can be only one hypervisor on the system. So you'll never have a > one-click app. > With Cygwin, a one-click Sage installer could just drop a sufficient minimal > install and then add Sage on top. The official python docs specifically > mention cygwin so it can't be that hard to build nowadays. > I don't see the point of going beyond this stage. Yes, with huge effort one > could port everything to Win32 instead of posix. For what, to run 10% faster > on somebody's gaming system? While running slower everywhere else because we > have to remove fork()? Windows has essentially no market share in high > performance computing. Or, for that matter, anywhere outside of the desktop. > Having students work on a Win32 port is not in the interest of their > education unless they have their mind already set on a job in Redmond.
These are some of the many reasons I stopped working on a native Win32 port. > If the "moving target" became a problem, we could always create a Cygwin > installer which went to sage.math to download the files. I'm sure it can't > be hard to add another mirror and remove the other mirrors. This could be a lot of work to maintain, but it is an interesting idea, and I'm surprised we didn't consider doing it before. Thanks for suggesting it. RegB: > The path to getting Cygwin/X up and running "usefully" on > a MS_Windows platform > is long and arduous for the naive user, e.g. it was so for me. Just to confirm what kcrisman said, from 2005-2007 when we distributed a Cygwin version of Sage this wasn't the case. It really was a 1-click install. We used a standard .msi installer and just distributed the libraries (etc.) in Cygwin that were needed, and it worked. Bradshaw: > Interestingly, some libraries and computations actually run faster in > a virtualized linux environment than natively on Windows. For example, the assembly language optimizations in GMP and/or MPIR are different for MSVC + Windows than for GCC + Linux, even on the same hardware. This can have a significant impact on performance, since the virtual machine will be building MPIR for GCC + Linux on that hardware. Dima: > the VM performance hit might be relatively minor, but the amount of > resources a VM > takes is quite big, compared to Cygwin. There are a lot of performance related issues people haven't mentioned yet, as far as I can tell: * fork on cygwin works, but it is still dog slow -- vastly slower than on Linux + VM * VM's generally suck at shared file support "just working", whereas in Cygwin it always just works * VM's sometimes/often have issues with networking, whereas in Cygwin it just works or isn't necessary * Cygwin is 32-bit only. It is easy to make a 64-VM running Linux (maybe even if Windows is a 32-bit install), as long as the hardware is 64-bit. William -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
