Saturday, December 22, 2007

A native Sage on Windows?

Since the 2.9 release I spend most of my time fixing various bugs and memory leaks in preparation for the 2.9.1 release, but more about that later. This post is about what initially started out as some observations by Ondrej Certik [sorry, I am lazy here, no fancy accents :)] about the use of Mathematica in a Lie group lecture he was attending. It quickly turned into a somewhat heated discussion about the merits of a native Windows port, certainly to some extend due to a lengthy rant I posted early on in the discussion. Most of the thoughts and arguments I put down in writing in that thread have been on my mind for quite a while, so I finally took the time to put them all into one more or less coherent argument. I will not rehash the complete argument here, but feel free to follow the above link and read the whole discussion at the Google group.

The desire for a native Windows port of Sage has been discussed on and off by various people at Sage Days 5 & 6 face to face and in IRC over the last couple months. While we support Windows via a VMWare image many people (including myself) think that a truly native port could bring Sage and its components to a lot more people. We used to have a Cygwin port, but that was dropped during the 2.5.x development cycle since we didn't manage to make libSingular work despite us trying for several weeks.

During the discussions various point of views came up why we shouldn't do a native Windows port:
  • A native Windows port would take away time from people that might be better spend on fixing bugs on OSX, Linux and Solaris.
  • It just isn't worth it to port Open Source applications to Windows. If people were really interested in Open Source they would switch to some free operating system.
  • We should spend time on improving the VMWare image instead.
I pretty much think that all of the above aren't valid or miss the point:
  • Bugs that are fixed on on platform are often present on the others, they just haven't caused any trouble yet.
  • For the foreseeable future Windows will remain the dominant desktop operating system. While that may be different in certain areas of academia we have to consider targets like high school students and so on. I do not buy the argument that by offering people Open Source applications on Windows those people no longer have an incentive to switch to a free platform. It is quite the opposite: Firefox has brought the idea of Open Source to many more people than the Linux kernel ever will. Take into consideration that I have been running Linux since the time you had to install it from sets of floppy discs that I downloaded at night over 14.4KB modem lines. And I have run it as my primary desktop OS ever since. But for many people switching away from Windows isn't desirable, because Windows is good enough for them. Another quite common scenario is that various lock in factors prevent people from moving away. So in the end we [as in Sage developers] just have to accept reality and do the best we can to bring Open Source math software to the masses, even if they "haven't seen the light yet" and are still using Windows.
  • Improving the VMWare image is orthogonal to the port issue. The VMWare image has its places and in many cases will be better suited, but it cannot replace a native port.
But there are also certainly problems with the port:
  • We will need to rely on non-free compilers, mainly MSVC [the express edition is free as in beer, but certainly not free as in freedom] and Intel Fortran [not free as in beer & freedom].
  • It will be a huge amount of work and all that needs to be integrated upstream. So far no entity has been willing to support the developers to do so.
  • We stand to gain few developers from the effort since most Open Source developers tend to work on anything but Windows and do not have the desire to go back. But the native Windows port will certainly require a lot of attention, maybe even more than the other ports combined.
There are also advantages:
  • We will potentially gain 64 bit support on Windows. A lot of the components of Sage are only available via Cygwin or MinGW which are currently limited to 32 bits, discounting the fact that Cygwin runs in 64 bit mode on Windows/Itanium.
  • The install will be smaller and it offers the possibility to do upgrades via binary packages. While we certainly plan to do something similar via the Debian packaging effort, it seems to be more or less the only way to do efficient upgrades on Windows since few people will have the tool chain to build Sage.
  • The potential user base for Sage will increase by a magnitude or more. And we are not elitist snobs that want to exclude people based on their choice of operating system :)
So what needs to happen to make this a reality? Mostly [more] developers willing to commit. We are still in the planning stage, but have a wiki page about the port. So if you are interested let us know if you want to help out or just give your perspective on the issue.

Cheers,

Michael

4 comments:

Nate said...

You should take a quick look at why Aurdor project has a Windows port, but has never released it.

It comes down to the cost of supporting Windows. Despite hordes of people telling you continously about how hard Linux is and drivers are difficult and all that, Windows is more of a PITA.

So unless you recruite talent from the actual Windows development community.. people not only willing to help out on the port, but are also willing to take Windows-specific emails and deal with the public then it's likely that it'll be more problems then it's worth.

But if you can get developers now that are willing to devote the time and effort to support the Windows version, without taking away from actual application development, then it's probably worth it.


Ardour may be in a different boat from you because their application seems to be much more closely tied to hardware and driver issues, which is a hard thing to deal with, but it's worth considering.

Tom said...

I'm looking forward to a Windows Sage. I'm a Windows user and my company uses Windows. Keep on porting ...

Tom

SmithB said...

If you want to port Sage to Windows without having to rely and depend on Microsoft's bugs, holes and daily update-patch-service pack paranoia, just AVOID as more as possible MS's dependent technologies like ".NET" and do it the old fashioned Win32 way, in native C (NOT C#) by using only the most basic API and libraries. That will save You and your Users 99% of MS issues and update time -if it works on the beginning it will never brake from Windows bugs and dependencies or because the user didn't install today "Microsoft .NET Framework 3.0 Sp2".

I too would like to use a native port of Sage on Windows.
I cannot use Linux as my main OS not because "I haven't see the light" yet, but because I have to work with some specific Windows applications that do not (yet) have a Linux alternative of similar value. Also, I'm planning to develop apps for profit, so I have to use the OS that paying users (customers) use!

Jeff said...

I am a community college mathematics instructor and have to use Windows for most things on my job. I am not a technophile. I use Sage in VirtualBox, but for me this is a kludgy solution at best. It is frustrating that Sage and LaTeX integrate so well together, but I can't use sage.tex with my Windows installation of MikTeX (I've tried to follow instructions I've found online, but so far haven't been able to make them work. Also, Sage is virtually inaccessible to my less technically minded students.