Linux Desktops at the University of Oxford

by Barry Cornelius on 19 May 2006 , last updated

Archived This page has been archived. Its content will not be updated. Further details of our archive policy.


In 2003, OSS Watch undertook a scoping study which attempted to establish the state of use of open source software in higher and further education institutions in the UK. It had the added benefit of also helping to clarify where OSS Watch should be placing its effort in its initial phase. Although the survey asked a question about the deployment of Linux, it did not specifically focus on the use of Linux on the desktop. Since 2003, of course, Linux has increasingly been adopted as the desktop of choice in some businesses, local government environments and, not surprisingly, also at research universities.

In order to get an up-to-date picture of the use of open source software in UK higher and further education institutions, OSS Watch will be performing another national survey early in 2006. To understand some of the issues that might be met in the national survey, we decided that it would be useful to perform a survey locally. So, in June 2005, I conducted an informal survey to obtain a picture of how widely Linux has been deployed on the desktop at the University of Oxford. The results are reported below. Some results were predictable; others were surprising. They will certainly impact the 2006 OSS Watch national survey.

An informal survey

In June 2005, OSS Watch conducted an informal survey of Linux desktops in use by _units _ (departments, colleges, research groups) at the University of Oxford. Oxford is perhaps unusual in that units are effectively autonomous on most Information and Communication Technology (ICT) matters. Thus an informal survey of these units may give an indication of the results that would be obtained from diverse institutions across the UK. Or the findings might just be peculiar to Oxford.

The survey involved a list of 30 questions. The questions were trialled by interviewing the sysadmin of one of the units. This initial feedback led to a slight revision in the questions. Then the sysadmins of nine other units were interviewed. Their enthusiam made it difficult to keep to the script. But the digressions also aided in rounding out the picture of Linux deployment across the units. Additionally, some questions were circulated by email to all IT Officers in each of the units. The resulting data forms a reasonable informal snapshot of Linux deployment on desktops at the University in June of 2005.

As a result of the survey, approximately 965 Linux desktops were located. The approximation is due to the variable counting of desktops. Clearly a PC with a single operating system used by a student, researcher or lecturer should count as a desktop. How then should one count dual-boot machines (PCs with two or more operating systems, one of which is Linux)? Does desktop refer to the physical machine or does each operating system count as a desktop? And if the latter, do virtual machines also count as desktops? Does a machine need to be used on a regular basis to count as a desktop? And how do you count the machines of researchers who have two or more physical machines but only use one on a daily basis? None of these issues were addressed in advance, though clearly they would need to be sorted out in any formal survey.

It was also noted that a wide number of Linux distributions are in use: Debian (woody, sarge), Gentoo, Mandrake [now called Mandriva] (9.2, 10, 10.1, 10.2), Red Hat (7, 8, 9, FC1, FC2, FC3, FC4 beta), Slackware (10), SuSE (8.1, 8.2, 9.0, 9.1, 9.2), Ubuntu (and Kubuntu).

An analysis of the replies


I was interested to know how a unit chose which Linux distribution to use. I found that, across the units, there were widely different reasons for arriving at the decision.

Often, an evaluation of the various distributions was not done in advance of selection. Time and limited access to up-to-date comparative information were the usual reasons given. Usually, the decision had been made before the sysadmin had joined the unit. In many cases, however, familiarity with a particular distribution aided the selection of a new sysadmin for a post.

Sometimes a distribution was chosen because another unit was using that distribution. Clearly, there is some cross-unit sharing of knowledge and experience at the University, which is a good sign. However, in other units there was little knowledge of what other units were doing.

Some units moved from Red Hat when the licensing changed. Although some did move to Fedora Core, some jumped ship entirely, mainly to SuSE. When Novell purchased SuSE, this popular Linux distribution began to fall under campus agreements that many units participate in.

I found that the most used distribution is some variant of Debian. The second most used is Redhat/Fedora Core.

Observation: for various reasons, it would be useful if the University adopted a particular distribution. However, as units often make different choices when choosing applications software, it is unlikely that they would agree to a particular distribution of Linux.


I found that there were two common approaches to updating a machine to a new release of a distribution. One is to upgrade when the machine is recycled to a new user. This means that sysadmins end up supporting different releases of the distribution across different machines. The other approach is to make a massive change occasionally: this means that all the machines of the unit are running the same release.

I found the first approach is usually adopted: so most units have a mix of releases. For example, one unit uses RH7, RH9, FC1, FC2, FC3 and FC4 beta.

Observation: although it needs more initial investment, it would be better for each machine of a unit to be running the same release of the distribution.


I found that different units have different policies as to who can use a Linux desktop. In some units, a desktop is just used by one person: it is his/her desktop. In other units, there is principally one user, but others in the same group also use the desktop. In a few units, anyone can log in to a desktop, either physically or remotely.

The sysadmin of one unit argued that often machines just sit there doing nothing, and that spare CPU time should be used. So they have a policy: people can use other machines. The sysadmin recently performed a survey: 10 people said that they sometimes used 10 to 20 machines concurrently. One person even said he had used 60 machines concurrently.

The decision on who uses a desktop affects where home directories are located. In some units, home directories are stored on the local disc. In other units, a home directory is mounted from a file server.

Observation: it is more flexible to allow people to access any of the machines and to have home directories mounted from a server.

Root access

Units have different attitudes as to who can have root (administrator) access. In some units, it is argued that when the user of the machine has bought the machine, it is difficult to deny root access to that person. In other units, a small number of people in each research group have root access to the machines in that group. In a few units, only the sysadmin has root password because he/she takes the responsibility that the machines are secure and up-to-date.

Observation: it should be the policy of a unit that sysadmins take responsibility for all the machines and that they should be the only people that have the root password.

Patching machines

As far as patching machines is concerned, again there are many different policies. In a few units, the sysadmin tests out the patch on a master machine and then, when he/she is happy, each machine is told to update. In many units, every night on each machine a cron job is run that does the patching, and if a reboot is required (e.g., if a patch is to the kernel) the sysadmin negotiates with the user as to when this would be convenient. However, in one unit, the sysadmin leaves it to each user to update their machine.

Observation: problems will eventually arise if a sysadmin leaves it to users to update their machines: sysadmins need to take on this responsibility.

The software that is installed

Most sysadmins do a full install of the distribution. This provides people with choice. Here are some examples. On the desktop, they might have a choice of Gnome/KDE; for a web browser, they might choose between Firefox and Konqueror; and for a mail agent, they might choose between Evolution, pine and Thunderbird. Although choice is provided, usually more support is given to one of the pieces of software.

I also asked about what discipline-oriented software is made available. Many units use the GNU compilers, Java and TeX/LaTeX. A lot of units install MATLAB and quite a few install Mathematica. Other software includes bioinformatics tools, FDR, FMRIB, FSL, Haskell, IDL, IRAF, Maple, R, S-PLUS and SPM.

If the user or the group has root access, they can install anything. Otherwise, the sysadmin installs the software. In some units, software is installed locally, whereas in other units it is installed on a file server.

Observation: the installation of software is more manageable if the sysadmin is the only person that can perform this task, and mounting software from a file server makes it easier to ensure that all machines get new releases of software.

Providing a webserver

With more people using companies to host their personal websites, I was interested in whether Linux desktops were acting as webservers. The University’s firewall permits access from outside the University to port 80 of a University IP address only for those addresses that are registered with the firewall. In some units, there are other port 80 restrictions. And in most units, webserver software is not installed. So, only a handful of desktops run a webserver.

Observation: it is better for a unit to have one webserver and for the different groups in a unit to be provided with space on this webserver.

Accessing Microsoft Windows

Often a user wishes to access Microsoft Windows. Units adopt one of four approaches to achieving this: provide the user with two machines; provide a Windows Terminal Server; install VMWare on the desktop; or allow machines to dual-boot. One sysadmin reported that he does not allow VMWare as he is unhappy about its security. Another said that it requires too much resource and often crashes. One sysadmin reported that, were he to allow dual-boot, he would not be guaranteed access to a machine to perform Linux updates. Another pointed out that if the machine were in Linux for a long time, it would become very out-of-date with its security patches for Microsoft Windows. Another sysadmin reported that dual-boot annoys other users because they are unable to remote login when it is in Microsoft Windows.

I also asked why access to Microsoft Windows was needed. Often the answer was the need to access Microsoft Office. But Linux provides Office clones, such as OpenOffice. In some units, OpenOffice is only started when the user is using a mail client and receives an attachment: the user switches to Microsoft Windows when they want to produce a document. But, in some places, people extensively use OpenOffice.

Observation: with increasing support in Linux for applications that were previously associated with Microsoft Windows, it is becoming less necessary to provide access to Microsoft Windows. In the meantime, dual-boot is the easiest option to provide.

Linux desktops elsewhere

I also looked at what other UK HE institutions were doing in this area. This was done by a quick search of web pages.

The Computing Service at the University of Cambridge provides a public workstation facility (PWF). These are managed collections of machines. 1200 of them are PCs. There are also some Macs. Between 500 and 600 of the PCs dual-boot between Microsoft Windows and Linux; the other PCs are Windows only. Some machines are restricted by membership of a group, and some by physical access to the machine.

At the University of Durham, there is a room that has 18 desktops that dual-boot between Linux (FC3) and Microsoft Windows. They use cfengine to make changes, so all the desktops should be the same and a desktop should revert back to a known state if it is reinstalled.

The University of Edinburgh’s academic structure has three Colleges. One of these is the College of Science and Engineering. Its Computing Committee has produced a report entitled Planning with Linux in Mind. In 2003-04, about 1800 of the College’s 5000 desktops (38%) had Linux installed. The University has also developed a Knowledge Management Strategic Plan. Section 6.1.34 of this draft includes the sentence The managed desktop concept will extend to Linux and Macintosh systems using technologies appropriate to those environments, and one of the Milestones for 2005-06 is IT-51: Linux managed desktop available.

The University of Warwick has four faculties. The Centre for Scientific Computing is a research centre in the Faculty of Science. The CSC has 300 registered Linux users (who are a mix of staff and students); there is a Linux cluster with 62 processors; and there are about 100 Linux desktops. Each user can log in to any of the systems, and they will always get the same environment. The desktops are treated like cluster nodes. So cluster management software is used to deploy and maintain them. The desktops are organised into a taskfarm allowing users to exploit unused CPU cycles. Desktop users get the best of both worlds: a consistent environment and the processing speed of a local CPU. The CSC and IT Services are about to roll out this Managed GNU/Linux desktop to other departments.


In the informal survey of units at the University of Oxford, a significant number of Linux desktops were found. The desktops were mainly found in scientific departments. There were widely different practices in the units for managing these desktops, some being more successful than others.

In a brief look at the information available on the web, there was evidence that other UK HE institutions are looking at how they can manage Linux desktops.

Observation: As ICT at the University of Oxford is so devolved, it is not surprising that each unit makes its own decisions about how to manage its Linux desktops. However, there ought to be guidelines giving some ideas about best practice, recommending a particular distribution and describing how desktops are best managed. I also feel there is a need for a managed Linux desktop service to be provided centrally. This would be for those units who would like to move to Linux on the desktop but who would like to shift the risk of its maintenance and management to others. It would also be for those units who feel that their current provision of Linux desktops could be improved.


I would like to thank those that were interviewed and those that replied to questions. I would also like to thank Julian King (University of Cambridge), Michael Young (University of Durham) and Jaroslaw Zachwieja (University of Warwick).

Further reading


Related information from OSS Watch: