White dot for spacing only
The Dice Project


Windows support in the context of DICE

Below is an extract from a couple of emails written by Paul Anderson in May 2001 that summarise many of the Windows support issues.
Email 1:
[snip]
I'll try and do two things: Firstly, I'll explain in more
detail exactly what we have decided and present the reasoning
behind it. Secondly, I'll try to say something about the
implications for Windows support.

I'll try to present the reasoning in simple steps, and it
would be very useful to identify clearly any points that you
think are incorrect, or any questions that you think remain
unanswered ...

Decisions
---------

The initial core of the DICE project will focus on providing
infrastructure to support commodity computing under Linux on
PC hardware. This infrastrutre will also support Solaris
(although *deployment* under Solaris will require additional
effort).  No infrastructure will be developed to explicitly
support Windows, although compatibility with Windows will be
considered wherever possible, and support for commodity
Windows applications will be provided via VMware.

Reasoning
---------

  (1) The remit of the project is to provide an infrastructure
      for cost-effective and efficient "commodity" computing for
      the majority of users in the Division.

  (2) We would expect this infrastructure to support the
      majority of the Division's research and teaching
      requirements, but special requirements which are driven by
      specific research or teaching needs should be justified
      and funded from appropriate sources. We will be happy to
      incorporate special requirements if suitable additional
      funding is available.

  (3) Experience at KB and elsewhere demonstrates that (1) is
      possible using Linux on PC hardware; this has proven to be
      cheaper to buy and considerably cheaper to manage than any
      alternative in a large diverse environment.

  (4) VMware can provide access to the important Windows
      *commodity* applications (eg. MS Office).

  (5) Integration with native Windows machine can be supported
      where technically possible (eg. Samba, Kerberos).

  (6) A formal survey of all Informatics staff has confirmed
      that (3,4,5) meet the commodity requirements of all but a
      few users.

This seems sufficient to justify the chosen direction. However,
there are a also a number of very strong supporting factors:

  (7) Around 85-90% of existing Divisional computing relies on
      Unix and it is unlikely that most users would be happy (or
      able) to convert to Windows. EUCS would be unable to
      provide this Unix support to a level which the Division
      would consider acceptable.

  (8) Very few resources are available. Linux is much easier to
      support in large, diverse configurations than Windows. We
      barely have the resources to support the Linux
      platform. We don't have sufficient resources to support
      Windows and certainly not both platforms.

  (9) Most departments in the University which use Windows for
      commodity computing use EUCS for support. EUCS has
      considerable experience and resources to devote to the
      support of these systems. Using Divisional resources to
      duplicate this seems foolish.

  (10) A significant proportion of the DICE effort looks likely
       to be funded by GRID collaboration which is
       Unix-based. If a similar source of Windows-based
       collaboration could be found, we would be happy to make
       use of this.

Implications for Windows Support
--------------------------------

We are well aware that a small but significant number of users
have a genuine requirement to run native Windows operating
systems. There are several options:

  (1) In many cases, the small numbers and ad-hoc nature of the
      work means that development of large-scale automated
      infrastructre is not necessary or cost-effective. In these
      cases, it is probably best to continue to provide the
      higher level of support staffing which is necessary to
      maintain the systems using largely manual methods.  The
      funding for this additional effort should come from the
      group geerating the requirement. EUCS are well-placed to
      provide backup and support for this type of installation.

  (2) EUCS has developed and deployed various mechanisms for
      configuring and maintaining large numbers of Windows
      machines. Because of the difficulty of this, these
      techinques place considerable restrictions on the
      flexibity of the configurations and require larger amounts
      of effort to incorporate new software. This probably makes
      the technology unsuitable for small research clusters, but
      it may be suitable for example, for a student laboratory.

  (3) If we were to consider investing seriously in
      infrastructure for Microsoft support, the central issues
      would be similar to those already identified for DICE:

      (a) The authentication and directory service issues being
          considered for DICE are supported in the Microsoft
          world by Active Directory.  We don't believe that
          anyone would suggest attempting to replace this with
          anything else in a Microsoft environment, so no
          development effort would be required. However, there
          are very serious deployment and integration issues
          which have been extensively investigated by EUCS and
          documented in a good series of papers. Even EUCS, with
          their Microsoft experience, have reservations about
          deploying this technology.

      (b) Software distribution and configuration (particularly
          of third-party software) is extremely difficult under
          Windows.  The "single-user" mentality and the
          proprietary nature of the software make it very
          difficult to develop automated systems for handling
          diverse, evolving environments such as ours.  However,
          the high-level configuration techniques being
          developed for DICE are certainly applicable in theory
          to the Windows environment and we would be very
          interested in following up this application. We have
          attempted (unsucessfully) to interest EUCS in such a
          collaboration. If other interested parties could be
          found, or if specific Windows-related funding was
          available, we would certainly be open to working in
          this area (note that this is a very difficult problem
          and a reasonable resource would be required to make a
          significant impression).

  A personal gut-feeling for the required effort is that about
  twice the effort (again) would be required to develop and
  maintain a similar level of service using MS Windows, to
  that which we can provide under Linux.

Please do give me some feedback on these issues. They have
been given considerable thought and we are attempting to
provide the very best computing facilities for the Division; I
would also like to think that we are setting an example to
those people outside of our small academic world of how it is
possible to build effective, maintainable computing
environments :-)

	Paul


And below is a response to some of the queries raised about points above

Email 2:

> I have a number of projects where I am required to use Windows
tools,

Yes. I assume that these are a minority requirement for
research-specific reasons, and are hence should not be allowed
to unduly influence the commodity needs of the Divison. Of
course, we will attempt to interoperate as much as possible, but
this is not likely to be easy when propritary, closed protocols
are involved.

(BTW: Have you tried NetMeeting under our latest VMware installation?)

> are Office and VM Ware might be an (expensive) solution to that.

This is an important misconception. VMware costs around $70. A
single manual rebuild of a typical Windows machine is likely to
cost more than that simply in terms of CO time which is our most
valuable resource.

> c) Informatics infrastructure and DICE design should allow
> interworking effectively with Windows (and possibly any other)
> systems for those that need them.

We certainly plan to do that & this has been explicitly stated
in the aims.  I would definitely expect to provide
application-level services such as IMAP, SMTP Samba, etc,
however these are comparatively easy - I'd like to emphasize
that (the initial) DICE core involves the layer below that which
is much harder.

You can't offer *any* service such IMAP etc unless you (a) are
capable of building and maintaining servers effectively, and (b)
have an authentication infrastructure which allows it to be used
safely and conveniently.

Just to emphasize - the availability of these services is not
the question - that it easy. What is important is the
infrastructure that they rely on - Setting up a Windows
authentication service to allow these to interoperate seamlessly
is very hard (maybe impossible?), so it may be, for example,
that you need to type passwords more often under Windows, and/or
you system is less secure.

> d) I agree with you that Windows users working inside our
> environment would be poorly advised to go the whole hog Microsoft
> route.  We deliberately use simple setups that can be easily built,
> restored and maintained.

I think the problem here is that most people don't really
understand what we mean when we talk about a maintainable
system. I doubt whether we would agree that your systems and
easy to build, restore, or maintain by our definition (I'd love
to be proved wrong!). You need very high standards here to make
this pay-off in terms off effort. (I'm happy to talk more about
this offline if you are interested).


 : Development : Doc 

Mini Informatics Logo - Link to Main Informatics Page
Please contact us with any comments or corrections.
Unless explicitly stated otherwise, all material is copyright The University of Edinburgh
Spacing Line