|
|
|
The remit of this report is to describe what approaches there are to supporting the functionality of Microsoft Applications, principally those from the Office productivity suite (Word, Excel and PowerPoint for example), under our local Linux environment (DICE).
It is not the remit of this report to make any reccommendations, although some natural conclusions will be drawn.
This report takes Microsoft Applications as representing all applications that run natively under a Microsoft Windows operating system, but are not necessarily produced by Microsoft.
While this report will focus on approaches for supporting Microsoft Office Applications, the applicability of the approaches as regards other applications (Outlook and Internet Explorer for example) will also be touched on.
There are four principal approaches that could be taken to supporting Microsoft Applications under Linux. Each represents a different technological solution.
A few other approaches were identified but are not addressed in this report. For example using Windows Servers and VNC or running a Linux environment under Windows.
Each approach is measured by consideration of a number of factors. These factors include: license cost which is the monetary cost of the approach; support cost which is the initial and recurrent time/personnel cost to adopt the approach into our managed infrastructure; training cost which is the time/personnel cost to train users in that approach; usage which is the categories of user the approach would be suitable for; performance which is how fast (or easy to use) the approach is for the user.
The four approaches are Dual-Boot, Emulation, API, and Equivalents. These are listed in decreasing order of functionality, where functionality is a metric based on the perceived size of user-base that could use that particular approach (in the order listed each approach is a super-set of the following approaches, a user that minimally needs the Equivalents approach could also use the Dual-Boot approach but not vice-versa for example).
Within each approach the best (as determined by the above factors) implementation (or product) is highlighted. However, alternatives within each approach are also covered.
This approach simply has the users machine installed with both a Linux and a Microsoft Windows operating system. The user chooses at boot time whether to run Linux or Windows and must stick with that choice until reboot.
Effectively this is the lowest common denominator solution since we are just providing a native Windows operating system. In one sense it is just a space-saving alternative to having two separate machines on a desk, one Linux and one Windows.
Due to the overhead of rebooting to switch between Linux and Windows it is questionable how realistic a solution this approach is. If this approach is used because a real Windows environment is required then the user is likely to be a heavy Windows user anyway and is unlikely to ever switch to Linux if they can achieve all they need to in Windows, so one could argue why not just install Windows. One exception to this would be taught students who may be forced to use the Linux environment to do their practical work.
This approach offers the most functionality. Since we are running a real Windows operating system on real hardware all Windows applications run natively as they would do on a pure Windows non dual-boot machine. There would be no interoperability or compatibility issues with other Windows users. In summary the functionality rates VERY HIGH.
The license cost would need to cover the purchase of the Windows operating system and any applications, for example Office. While covered by University site licences these are still expensive. Technically the Windows operating system is included in the cost of the machine hardware, however since this cost can be offset in other approaches it must be considered part of the license cost of this particular approach. In summary the license cost is HIGH.
The support cost is complicated in this approach. It depends on whether the Windows operating system is managed as any other stand-alone Windows machines would be managed. This is currently in flux but it is likely there will be a managed solution, the cost of which will depend on the particular category of each user. There are also initial support overheads to installing a dual-boot machine and recurrent support overheads where one or other installed operating system is trashed by the user (which is easier to do in a dual-boot scenario, although it could be minimized). In summary the support cost is MODERATE running to HIGH (particularly if there are a lot of these types of machines). If an infrastructure has been put in place to support dual-boot and the user themselves is responsible for building the Windows partition (or a scenario based on the EUCS managed desktop, or hybrid thereof, is adopted) then the support cost ought to be LOW.
Since we are running a real Windows operating system natively and we are running real Microsoft applications the training cost is minimal as we can just use EUCS courses. In summary the training cost is LOW.
Again since we are running a real Windows operating system natively on real hardware the speed of operation is identical to a stand-alone Windows machine. The incovenience of having to reboot to switch between Linux and Windows is a significant ease-of-use barrier however. In summary the performance is VERY HIGH.
There are some technical problems with this approach. For example, managing the security of the Windows operating system sharing the same network as the Linux operating system.
This approach would be used by anyone that really needs a pure native Windows environment. In particular, if special hardware is needed which is not (or not as well) supported under Linux. Primarily this would just be the case for research or project work.
This approach emulates some or all of an x86 architecture so that the Windows operating system can be run as an ordinary application under Linux. In principle any Windows application can then be run on top of this, although there are some limitations.
Products implementing this approach include VMWare, BOCHS and Plex86. VMWare just emulates the PC input/output hardware, the CPU is used directly. This means it is reasonably fast, although struggles with graphically intensive multimedia work. BOCHS emulates the CPU as well and so it is much slower and not a viable option as a result. Plex86 is the OpenSource equivalent to VMWare but it seems relatively underdeveloped as yet. We focus on VMWare.
Even given the speed limitations of the emulation approach VMWare works fine for standard Office applications. Since it provides the whole Windows operating system environment and can use real Microsoft applications then interoperability and compatibility with other Windows users is not an issue. Since VMWare only emulates the basic hardware of an x86 PC, some Windows applications would not work where they are designed to operate with dedicated hardware for example. In summary the functionality rates HIGH.
Starting it up for the first time is slow because the Windows operating system needs to boot up, however once running it can be left as an iconized window ready for immediate use - this is clearly better than the Dual-Boot approach. However, the start-up time is not ideal if you just wanted to quickly read a Word document somebody has been sent as a mail attachment for example. In summary the performance is HIGH.
The license cost of VMWare is expensive at approximately $300 per license although educational discounts could reduce this. It is licensed on a per-user basis. In addition the cost of the Windows operating system license and the Office license must be added on top. So this approach is actually more expensive than the Dual-Boot approach. In summary the license cost is VERY HIGH.
There is an initial support cost to wrap up the VMWare component for our management infrastructure. However, this has already been done. There is also an initial support cost to build ready-made Windows/Office images. There is a recurrent support cost to handle modifications for upgrades. In summary the support cost is MODERATE. If the user is responsible for building their own images then the recurrent support cost only needs to handle upgrades to VMWare. In this scenario the support cost is LOW.
Since we are running a real Windows operating system and real Microsoft applications the training cost is minimal and just covers specific aspects of the VMWare environment itself. In summary the training cost is LOW.
Technical problems with this approach include the speed issue which limit its applicability for some applications and the problems that arise from only emulating the basic PC hardware. There are also security aspects of running a Windows operating system using the full network access of the underlying Linux operating system.
This approach could be taken by anyone that needs real Office applications and a real Windows environment (.NET for example) but doesn't have sufficiently heavy application/hardware use to justify the Dual-Boot approach.
This approach implements the API call layer of the Windows operating system under Linux. If this were done perfectly it would mean that a large number of Microsoft applications could be run directly on Linux (x86) without the Windows operating system. In practice the complexity, size and undocumented features of the Windows API call layer mean that current implementations fall short of this ideal.
The main implementation is WINE which is OpenSource. However, Microsoft Office applications do not run easily under this. Crossover Office is a commercial version of WINE with some bundled extensions that mean Microsoft Applications (Word, Excel, Powerpoint, Outlook and Internet Explorer) will run effectively. It should be highlighted that with this approach the user is running a real Microsoft Office application directly under Linux. The Crossover Plugin allows the Microsoft Office Viewer applications to be used (for Word, Excel and Powerpoint) with hooks into native Linux browsers for automatic mail attachment handling. This is useful if you only need to read Microsoft formatted documents.
To all accounts this approach works extremely well. While not all the functionality of the Microsoft Office applications is perfect the features the majority of people use on a daily basis are. Interoperability and compatibility with others using native Windows and Office is not an issue again because the real Microsoft applications are being used. In summary the functionality is MODERATE.
The license cost for an educational institution of Crossover Office is approximately $44/user or $24000 for 1000 users. The license cost for an educational institution of Crossover Plugin is approximately $20/user or $6000 for 1000 users. It is also possible to purchase both products bundled at approximately $56/user or $28000 for 1000 users. A site licence could also be negotiated. The Microsoft Office Word, Excel and Powerpoint viewers are free so there is no license cost above that mentioned for Crossover Plugin to just view Microsoft Office documents. Hence, if Crossover Plugin is deployed widely it is very cheap. However, to create Microsoft Office documents the license cost would need to include the full cost of the Microsoft Office Application. In summary the license cost is LOW for Crossover Plugin and MODERATE for Crossover Office.
The initial support cost covers packaging for our infrastructure and the provision of ready-made Office images. However, the Crossover Office bundle goes some way to assist in this process, including the ability to build an RPM. The recurrent support cost would need to cover upgrading our local package and images for newer versions of CrossOver Office and Microsoft Office. In summary the initial support cost is MODERATE and the recurrent support cost is LOW. Note that the management of licenses will add an overhead in support cost (as it would for the Dual-Boot and Emulation approaches as well).
The training cost would be HIGH if the user is familiar with a Windows operating system environment but is moving to Linux using this approach. The training cost would be LOW otherwise since this approach runs real Microsoft applications so EUCS courses would still be applicable.
Since only the API layer is being emulated and the raw CPU and hardware of the PC are still available to the application the speed is comparable to running Microsoft applications natively under a Windows operating system. The beauty of being able to type a command at a Linux shell and having a Microsoft Word window fire up in a few seconds is compelling. In summary the performance is HIGH.
There may be a problem with the lifetime of this product given the OfficeXP license clause (which supposedly states that the license is only granted for running the software under a true Windows operating system). This has not been confirmed or fully investigated yet.
This approach could be taken by anyone that really needs genuine Office applications, primarily because of the need for heavy interoperability with people using Microsoft Office under Windows.
Applications written specifically for Linux which provide the functionality of Microsoft Office but are a different package entirely.
There is a lot of choice here: OpenOffice, StarOffice, Corel, KOffice, GNOME Office and AbiWord to name the most recognized ones. OpenOffice is a fully featured alternative productivity suite including Word Processor and Spreadsheet functionally equivalent to the Microsoft applications. It can import and export Microsoft formatted documents. StarOffice is the Sun Microsystems supported version of OpenOffice (both OpenOffice and the current StarOffice are derived from the same source). Licence costs are negligible for education. StarOffice has some advantages over OpenOffice, for example it includes a Spellchecker, Thesaurus, database component, additional import/export filters and clipart. Corel WordPerfect is another commercial alternative but is expensive. KOffice and GNOME Office provide similar functionality to OpenOffice but are considered less feature rich, less developed and interoperability with Microsoft application documents is not as good. AbiWord is only a Word Processor rather than a full Office suite and is designed to have a Microsoft "look and feel". Falls short on Microsoft Office document interoperability. We focus on OpenOffice.
While OpenOffice interoperability with Microsoft products is possible (and best of the available products) it should still only be considered limited. Reading or writing basic Microsoft documents works fine for the most part but active sharing on a document would not. For example, the differences in Macro support between Excel and OpenOffice would make document sharing very difficult. OpenOffice also lacks a powerful equivalent to Microsoft Powerpoint. While it has an adequate presentation tool it is limited by comparison. OpenOffice also lacks an equivalent to Outlook, although there are other OpenSource applications for Linux which provide some of the functionality of Outlook (none yet provide interoperability). In summary the functionality is LOW.
There is no license cost for OpenOffice, it is free of charge.
The initial support cost would entail wrapping up OpenOffice for our Linux environment and providing an easy to use startup script. However, this has already been done. The recurrent support cost needs to cover updating our packaging for new versions. In summary the support cost is VERY LOW.
The University provides training courses for Microsoft Office but nothing for OpenOffice. If a lot of staff were using this seriously then we would need to consider providing our own training courses. In summary the training cost is MODERATE to HIGH.
OpenOffice provides a viable alternative to Microsoft Office for anybody who wants a word processor and spreadsheet with an equivalent level of functionality and who is occasionally needing to look at Microsoft documents. However, for anyone who must work heavily with others using native Microsoft Office the level of interoperability with Microsoft documents is limiting and the user would have a problems under that scenario. Of course if the whole School/College/University used OpenOffice this would be less of an issue - it is considered that users could be equally productive using OpenOffice as they could using Microsoft Office at significantly less cost.
In conclusion there is no ideal solution and it would be wrong to take the attitude that one size fits all. Each of the detailed approaches meets different types of user requirement.
Consequently it is difficult to envisage a scenario where we would not need to support all of the above approaches to at least some degree. One exception might be that VMWare could be dropped in favor of just the dual-boot option. How practical this is depends on the perceived user base for VMWare against dual-boot. For example, if almost everyone is using VMWare for Office applications then Crossover office and/or OpenOffice provide an equally viable solution. Anyone using VMWare for other Windows applications or the Windows development environment for research is likely to be a heavier user of Windows and the inconvenience of a dual-boot approach is mitigated (in fact it could arguably be replaced with a pure Windows machine).
We could support the ability to dual-boot (within the Linux/DICE infrastructure) and support the VMWare application itself. However, the management of the Windows part of a dual-boot environment or the creation of Windows images under VMWare could be supported differently (less or not at all under a scenario where the EUCS managed desktop is used for example).
Given that the recurrent support cost of OpenOffice and Crossover Office is low but the target usage differs it doesn't seem unreasonable to offer both of these approaches. Given that StarOffice is now free it might be worth considering the use of this instead of OpenOffice, although it may be harder to package. In any case it might be worth purchasing a site license for Crossover Plugin to provide free genuine Microsoft Office viewers to all users. Only those who need the ability to create Office documents would then need full licenses for Crossover Office.
The reviewer was impressed by the multitude of approaches and provided packages for each approach to the provision of Office productivity suite under Linux. This amazing array of choice is in rather stark contrast to the sole provision from Microsoft which is important to highlight.
VMWare (http://www.vmware.com/products/desktop/ws_features.html)
BOCHS (http://bochs.sourceforge.net/)
PLEX86 (http://plex86.sourceforge.net/)
Crossover Office and Plugin (http://www.codeweavers.com/products/office/)
Word Viewer (http://office.microsoft.com/downloads/2000/wd97vwr32.aspx)
Excel Viewer (http://office.microsoft.com/downloads/2000/xlviewer.aspx)
PowerPoint Viewer (http://office.microsoft.com/downloads/2000/Ppview97.aspx)
OpenOffice (http://www.openoffice.org/)
StarOffice (http://wwws.sun.com/software/star/staroffice/6.0/)
KOffice (http://www.koffice.org/)
GNOME Office (http://www.gnome.org/gnome-office/)
AbiWord (http://www.abisource.com/)
CrossOver Office: The Killer App for the Linux Desktop? (http://www.linuxplanet.com/linuxplanet/reviews/4126/3/)
MS Office for Linux? Nope, not quite--but close! (http://www.zdnet.com/anchordesk/stories/story/0,10738,2860311,00.html)
An Office Without Windows (http://www.pcworld.com/reviews/article/0,aid,101003,00.asp)
Running MS Office under Linux with CodeWeaver's CrossOver Office (http://www.linuxjournal.com/article.php?sid=6153)
Codeweavers' CrossOver Office (http://www.unixreview.com/documents/s=1353/uni1023214136259/)
Review of Win4Lin 4.0 (http://www.osnews.com/story.php?news_id=1112)
Office on Linux: If you can't beat Microsoft, join it (http://techupdate.zdnet.com/techupdate/stories/main/0,14179,2861621,00.html)
MS Office arrives on the Linux desktop (http://www.desktoplinux.com/articles/AT6509081484.html)
AbiWord: Open Source's Answer to Microsoft Word (http://linux.oreillynet.com/pub/a/linux/2002/03/14/abiword.html)
|
Please contact us with any
comments or corrections.
Unless explicitly stated otherwise, all material is copyright The University of Edinburgh |
|
