The /uns Users' Frequently Unasked Questions List

/uns is a collection of installed software which is maintained and supported by UW CSE grad students, not by the department's system administrators. This document answers questions about /uns.

Author's foreword: As /uns coordinator, I wanted to collect a list of frequently-asked questions about /uns. However, hardly anyone has asked me any questions about /uns. Hence, this document is really a list of frequently-unasked questions - an "unFAQ," if you prefer.

Please send comments, additions, and corrections regarding the unFAQ to the /uns coordinator,

Table of Contents


1. Using /uns

1.1 How do I set up my environment to start using /uns?

Here's how to start using /uns in three easy steps:

  1. Add the directories /uns/bin and /uns/share/bin to your PATH. If you want the /uns version of gcc to override the supported version, add /uns/gcc/bin to your PATH as well.
  2. Add the directory /uns/lib to your LD_LIBRARY_PATH (required for programs which use shared libraries in /uns).
  3. Optionally, add /uns/share/man and /uns/man to your MANPATH, and add /uns/share/info and /uns/info to your INFOPATH.

Examples implementing the above recommendations are available for Bourne Shell or C Shell. Note that, depending on the relative ordering of directories in your path, you can have /uns/bin shadow the supported binary directories or vice versa.

On Solaris, where /uns provides basic GNU tools such as ls, cp, and so forth, you must add /uns/gnu/bin to your path to take advantage of these tools.

If you use a department-supported version of Emacs but would like to take advantage of /uns's site-lisp directory, add the line

(load "/uns/share/emacs/site-lisp/config-and-add-path.el")
to the top of your .emacs file to update your Emacs load path.

Additional incantations may be occasionally required for X programs that cannot find their X app-defaults, and for other strange situations. If in doubt about a particular package, contact its /uns maintainer.

Greg Badros has provided a detailed example with suggested /uns-friendly environment and elisp settings.

1.2 Do I need to join the /uns maintainers' group to use /uns software?

No. You only need to join the group if you want to install or maintain software in /uns.

1.3 Who maintains package xyzzy in /uns?

The maintainer of a particular /uns package owns the files in that package. To find her user name, locate one such file (generally in /uns/bin or /uns/share/bin) and use 'ls -l' to see its owner. To map a user name to an actual person, use the command 'finger -m userid@cs'. Note that our department often maintains user accounts for some time after a user leaves, so the package maintainer may no longer be here. If in doubt, ask an older grad student about the maintainer's status.

If you find that a package is owned by the user unsadmin, that doesn't mean that the /uns coordinator maintains the package! Packages whose maintainers have left have their files transferred to unsadmin after the maintainer's account is deleted.

If you care about a package which has been orphaned because the maintainer has left or has lost interest in it, consider joining the /uns package maintainers' group and taking over maintenance of the package yourself. Remember, /uns only works if we all do our part to keep it working!

1.4 How do I use package xyzzy in /uns?

Questions regarding specific packages in /uns should be directed to the package's maintainer.

1.5 I want to install a new package (or take over maintenance of an old package) in /uns.

Great! You'll need to join the /uns maintainers' group; send a join request to

New maintainers should also read the maintainers' unFAQ to learn about the installation guidelines for /uns software.

2. /uns Logistics

2.1 What is /uns?

/uns is a collection of installed software which is maintained and supported by UW CSE grad students, not by the department's system administrators.

The /uns software repository is shared by most departmental UNIX machines through NFS. It provides a more convenient, more persistent alternative to installing shared packages in individual users' home directories. Anyone can use the software in /uns, and many grad students with UNIX desktops do so on a regular basis. Moreover, anyone who asks may join the group of /uns maintainers, who can install and maintain software in the /uns repository.

2.2 Which packages are in /uns?

/uns has way too many packages to list here; check your local /uns partition to see what's installed.

2.3 Who's in charge of /uns?

/uns is run cooperatively by its users, in particular the 40+ members of the package maintainers' group. The /uns service remains usable primarily through the ongoing efforts of individual package maintainers.

The /uns coordinator ( is responsible for curating the collection of installed packages, adding people to the package maintainers' group, proselytizing new /uns users, and harassing the Lab about issues like disk space for the /uns partitions. The coordinator is nominated and elected to a one-year term by CSE graduate students at the annual elections held during spring quarter.

Aside from keeping an eye out for old or bogus software installations, the /uns coordinator generally stays out of the way of the package maintainers.

2.5 Where do I find out about current happenings and new software in /uns?

/uns-related news is posted to the CSE newsgroup uw-cs.apps.announce.uns, which is gated (in both directions) to the cs-apps-announce-uns@cs mailing list. Ideally, package maintainers are supposed to post/email to this group whenever they install, change, or upgrade software in /uns, but this rule seems to be honored mostly in the breach. Sometimes the maintainers send mail to uns@cs instead, though that list is officially only for maintainers.

Questions and complaints about /uns itself should be sent to the /uns coordinator or, if they are of general interest, posted to the newsgroup. Questions and complaints about a particular package in /uns should be sent to the package's maintainer.

2.6 If this document is a list of Frequently Unasked Questions, why didn't you call it the "/uns FUQ"?

When you're elected /uns coordinator, you can call it whatever you want.

3. Platforms and Machines

3.1 Which UNIX platforms have /uns repositories?

Separate /uns partitions are maintained with binaries compiled for Linux x86 (2.2/glibc 2.1), FreeBSD (3.4), and Solaris (2.2.5/8.0). In addition, there is a single shared repository, mounted as /uns/share, which holds platform-independent files like scripts and Emacs Lisp code as well as transient /uns program state such as lock files.

If you're using a department-supported UNIX desktop on one of the above architectures, you should have an /uns partition mounted on your machine. For user-supported project machines, the machine's administrator chooses whether to mount the appropriate /uns partitions.

If you have a department-supported machine that doesn't run one of the above flavors of UNIX and doesn't have /uns, ask the /uns coordinator about creating an /uns partition for it.

3.2 I use Windows. Is there an /uns for me?

There is a Windows /uns repository which can be mounted as a share. It provides numerous useful tools, mostly command-line oriented, as well as application archives that can be installed on Windows users' local machines.

To access the contents of the Windows repository, go to the share \\rfilesrv1\UNS. To add the /uns tools to your environment, copy (ctrl-drag) the shortcut "Start UNS environment" to your desktop and double-click to get a shell with the /uns environment.

For more information, see the file \\rfilesrv1\UNS\README or email the Windows /uns coordinator.

3.3 I'm using an instructional (IWS) UNIX machine. Is there an /uns for me?

There is a separate /uns partition for the IWS x86 Linux servers (ceylon, fiji, sumatra, and tahiti). This partition is maintained by the IWS /uns coordinator.

3.4 I run an untrusted UNIX machine. How can I mount /uns on my box?

The Lab is responsible for most of the policy on untrusted hosts (machines on which the owner, rather than the Lab, has root), including what mounts are allowed. Here's what you need to do to keep the /uns coordinator happy if you want to mount /uns:

  1. If you're getting NFS write access to /uns, you must join the /uns maintainers' group. The reason: you'll have the ability (as root) to write anything you want to the /uns partitions, so you should assume the responsibility that goes with that privilege. This step is not required if you're mounting /uns read-only.
  2. Group 650 on your machine must be named uns, to be consistent with the group numbering on supported machines. Your mount points for /uns and /uns/share should be owned by this group and (if possible) mounted with the grpid flag, so that any files you write will be automatically chgrp'd to the /uns group.
  3. For your own safety, you should mount the /uns partition with the flags nosuid,nodev to avoid mounting a huge security hole along with your /uns partition.

4. Common Complaints

4.1 Package xyzzy in /uns is broken!

Complaints about broken or incomplete packages in /uns should be directed to the package's maintainer. If the maintainer is gone, or the package is owned by unsadmin (which amounts to the same thing), send mail to the list of all package maintainers at

If you find that a package broke because part or all of it was removed from /uns, bug the /uns coordinator.

4.2 Package xyzzy in /uns is installed on platform foobut not on platform bar!

Package maintainers are encouraged but not required to build binaries for all /uns architectures. Sometimes, it doesn't make sense to install a package on all platforms; other times, a package may not build and/or may not be available in binary form for all platforms.

If you know how to get a package working on an architecture where it is not currently installed, your best bet is to join the maintainers' group and do the installation yourself.

4.3 Package xyzzy in /uns is superseded by a newer Lab-supported version (e.g. in /usr or /usr/local)!

Bug the package maintainer if possible; otherwise, talk to the /uns coordinator.

Note that older or duplicate packages in /uns may have been built with extra features not present in the "official" Lab-supported versions.

4.4 Platform foo has a very poorly maintained /uns partition!

The enthusiasm for maintaining /uns on each platform is proportional to the number of package maintainers using that platform.

That said, if you find that something is broken on any /uns platform, you should still alert the package maintainer and/or the /uns coordinator. And of course, you can always perform necessary maintenance yourself.

/uns coordinator (
Last Update: 6/1/2001