The Good Practice Guide (or, How To Be a Considerate User)

This page contains some comments on good and bad practice when using computers within the School of Informatics. Following these guidelines should allow you to make the best use of the School's computing resources whilst minimising the impact on other users.

The Computing Environment within Informatics is, hopefully, set up for ease of use and flexibility. This means that some of the responsibility for making sure the facilities are not abused falls on you, the user. The following guidelines should be used to tailor your own working methods.

General

• Remember, you are expected to have read and agreed to the University Computing Regulations (it is a requirement of matriculation that you do so, and is similarly applicable to staff contracts). These deal with all issues of acceptable use, and do allow for "other small-scale use" (personal use) provided that this privilege is not abused.
• For desktop (non-public) machines, using a screen-saver may help maintain/renew your Kerberos (services authorisation) ticket - which would expire after 18 hours if not renewed (note that this does not apply to all screen-savers, but "xscreensaver" currently has this functionality).
• Don't slow other users down by running jobs on multiple machines. If you are working on a lab machine that is, or becomes, sluggish or unresponsive and you suspect that someone else is running compute-intensive jobs on that machine, it is perfectly acceptable to reboot (but not power-cycle) it, if:
  • it is, or is becoming, unusable
  • there are no other machines free

  This only applies if you are directly logged-in on the console, and not if you have connected from another machine. Pressing the Ctrl-Alt-Delete keys should reboot the machine cleanly (power-cycling a machine does not!).

• Crypto-mining is not allowed on Informatics computers. It's a breach of the University Computing Regulations — which will result in disciplinary action — and it's also very selfish (it slows them down for everyone else) and bad for the environment (electricity use can go way up).
• It is not acceptable to put signs on lab machines saying something along the lines of "Do not use, experiment running ...". Lab machines are shared resources. You can run long jobs on the lab machines but you must run these in the background (using longjob) to allow other users to log in at the console. If you find a machine in such a state and you wish to use it, you can press Ctrl-Alt-Backspace to log the person off.
• If a machine hangs, or fails to reboot properly, then inform a Lab Supervisor/Demonstrator or your nearest Computing Support person (either by using the support form, phone, or calling in to one of the support offices - details of which can be found on the Computing Support web page).
• Be aware that rebooting the machine will also destroy any processes that you might have had running on that machine.
  Note that it is not acceptable to connect remotely to desktop (non-lab) machines and run compute-intensive jobs without consulting the main user of that machine first!
• To save energy, feel free to switch off the monitor of a machine you have finished using. However, do not switch off the computer itself, as upgrades happen automatically overnight, and other processes besides yours may be running on the machine.

Security

There are various aspects of computer-related security that will affect the way you work:

• Choose a memorable yet obscure, non-dictionary password (any password that appears in any on-line dictionary or word-list can be discovered by a brute-force automated attack). See also DICE password policy.
• Do not share your username, or tell anyone your password.
  (So don't let a visiting friend borrow your account to check his or her e-mail - it's against the Computing Regulations anyway.)
• Regularly review the login activity for your account.
• Do not leave your laptop lying around (it may get stolen, or - which is arguably worse - tampered with).
• Pay attention to all security/virus/worm notices (and install any relevant patches or fixes on personal machines that may be used to connect to the University network).
• If using a publically-accessible machine, don't leave it un-attended while you are logged-on (if you do, it is possible that your data may be tampered with, or potentially damaging e-mail may be sent from your account).
• Don't leave a publically-accessible machine screen-locked for long periods of time - this is anti-social, and may prevent other users gaining access to computing facilities.

Browsing

• Remember that your account here is for educational, not personal, use (the above "other small-scale use" notwithstanding) - so don't download huge music, image, or other files.
• Be aware of any copyright limitations when taking copies of material from the web or other locations.

Printing

• Try not to waste resources by printing documents that could as easily be read on screen.
• If you must print something out, consider printing it with two or four document pages per sheet of printout (rather like the layout of a book or magazine). You can use "lpr -o number-up=2 <filename>" or "lpr -o number-up=4 <filename>" to do this - see the DICE - Printing Information page for more information.

Mail

There are several issues relating to good practice when reading or sending email - see the separate How to be a Considerate Mail User web page.

Disk Usage and Software Installation

• If you are installing software that will only be used on one machine (your own desktop machine, for example), consider using local disk space instead of your home directory (or other networked filespace). This gives you a quota-free area, and locally stored files (be they data or executables) are accessed much faster than over the network. The local disk space should be available as /disk/scratch or /disk/hostname (or some variant thereof). Use "df -hl" to see what's available locally. If you don't have permission to write to this space, ask Computing Support to create a directory for you.
• Software installed using the package mechanism (deb packages on Ubuntu, RPM on SL7) may be subject to automatic removal, since each machine keeps a list of "approved" packages that it checks installed packages against - any missing packages are installed, and any extra packages are removed. This does not apply to software installed by hand or using other package installation software. If you have problems with this, your package can be added to the "approved list" that the machine checks against - ask Computing Support to add your package to this list (assuming there is no conflict with other packages or any other reason not to add it).
• If you are compiling a package from source, you might consider storing the source and temporary compilation files on the local disk too, moving binaries and any run-time libraries or other run-time files to your home directory after successful compilation (if you are going to use any such package only on your desktop machine, you don't even need to do that). If you are going to do this, make sure that any compiled code is relocateable, and if you intend to delete the sources, check the compiled software beforehand (you could move or rename the directory containing source and temporary compilation files, and see if the executable complains - deleting unwanted files if not).
• Note, however, that it is not wise to store anything on local disk that cannot be easily recreated or rebuilt. Local disks are not backed up, and - should the local disk become damaged or corrupt - no recovery of the data is possible.