Frequently asked questions (FAQ):

  
What's a host?
A host is a very kind grad student willing to give up a portion of their home directory for the benefit of others. 		Being a host makes you an honorary member of the ring. Leeches will love you, fellow hosts will respect you, but bothes will confound their love and respect with a secret contempt, "yeah, whatever, that host couldn't write a GAP program to save a whale".
What's a leech?
Neither a lattice nor a blood-sucking animal, a leech is a grad student who uses the software hosted by another grad student. 		Being a leech does not make you a member of the ring. Even if you accost hosts over tea with, "Oh most honored host, you are so cool, may you enjoy that lovely cup of tea", although you might get a friendly smirk, ultimately you will still not be a member of the ring.
What's a both?
A both is a grad student who both hosts software and uses software hosted in the ring. (You might only use the software hosted by yourself. That's okay.) 		Being a both makes you an official member of the ring with full duties and priviledges, including all feelings of superiority that go along with that. For example, over tea you are allowed to accost a suspected non-host leech and say, with a friendly-yet-menacing smirk, "Yo leech, what's going on?"
What's a browser?
A browser is a grad student interested in high-performance computing or other computing issues who finds these pages useful but has no interest in free math-related software and is not willing to give up space for hosting. 		Browsers are like leeches minus the sucking but with bigger eyes. We don't mind them in the slightest.
What's the basic setup for hosts?
Each host has a world-readable public_packages directory (similar to the existing public_html directory). Inside are subdirectories for each package hosted by that host. All the files (binaries, man pages, library files) related to a package sit in a tree inside that subdirectory. (In particular, the host may have to avoid the usual RPM or make install approach and resort to careful hand-installation, depending on the flexibility/design of that particular package.) Thus the package can easily be re-hosted by someone else or deleted, since all of its files sit in one place. 		 
What's the basic setup for leeches?
Each leech has a $HOME/bin directory (added to their PATH) in which are placed symbolic links to the host's binaries. The leech can opt-in on individual packages, and can opt-out simply by deleting the symbolic links. 		 
Why not just ask the sysadmin to install the software?
Most of these packages have been requested in the past. Occasionally a package gets installed. The time period between request and installation can exceed a semester. Some requests get ignored. In the future, depending on the nature of the request, it may have to be a written proposal approved by the faculty computer committee. Even if the request (in whatever form) is honored, the system-wide installed version may be an older (perhaps more stable) version but may not have all the features some of us need. 		 
Should the sysadmin no longer install packages system-wide?
Not at all. We will continue to request system-wide installation. But we will continue to install bleeding-edge stuff inside our ring. As we gain experience with a particular version, we may report back to the sysadmin, who might be willing to go system-wide with a particular version based on our experience. In general, the system-wide versions (there could be multiple ones under different names) will be older and/or more stable ones. Our versions (there could again be multiple ones) are there to meet our own particular needs. Users can opt-in/opt-out on an individual package/version basis. The point is that we can meet our own needs immediately, and the sysadmin can selectively catch up on a system-wide basis. 		 
This is stupid. If one of the hosts leaves the UofA or simply deletes a package for need of space, then part of the ring is destroyed. Isn't there a better way?
Yes, this may be stupid. Perhaps it would make more sense if our ring owned a separate grad account with a large quota, and all the installations happened there. Or perhaps we should have access to a special system-wide directory. Unfortunately, these other ways require the support of the sysadmin and the computer committee. Perhaps such support will be forthcoming in the future, especially if we continue to press them for acknowledgment that what we're doing is relevant. Meanwhile, we're taking the present approach. 		In fact the situation is not too desperate. In the present setup, if one of us graduates, or if one of us needs room for something else, then at worst a few hosted packages disappear, so only part of our ring breaks down. Fortunately, since each package is installed inside a single directory, it is easy to transfer a package to a new host, and presumably existing hosts are sufficiently responsible to see to that before deleting a package. Ultimately, we must pressure the leeches to become hosts, and we must recruit new hosts by getting young grad students interested in computing, for example by individually taking them under our wing and showing them how to use a particular software package (or smiling humbly as they show us...).
Why exclusive to grad students? Why can't faculty participate?
We would love faculty to participate, but logistics prevent it. At one time faculty and grad students all had accounts on the same system (the old Sun-based Solaris environment, usually referred to as ame2 because that's the name of the main server). Unfortunately, some faculty members considered their needs to be superior to those of grad students, and various battles ensued, and the sysadmin and department head took pity on the grad students, and a separate cluster for grad students was created. Furthermore, most machines in faculty offices do not mount network directories. (In other words, none of us can login in a faculty office, and each faculty member can login only in their own office.) Presumably a future design could achieve a middle ground whereby grad accounts are served globally to all machines, and faculty accounts are served to all faculty machines. Then faculty could participate in this ring as leeches, but not as hosts. 		For grad students, there are advantages to having a separate cluster to which faculty can't log in. For example, the high-performance machines chivo and chivo2 are available only to grad students, and if one of us needs to run a job yet another one of us is hogging the machine, we might just go talk to them. But if a faculty member was hogging the machine, which of us would have the guts to go say, "Yo, you need to renice your task you mean bad inconsiderate faculty member, so lowly poor me can also get some work done." It only takes a couple bad apples among the faculty to make a shared environment difficult for grad students.