CSE 481D: Capstone Software Design - Autumn 2008
|
|
CSE 481D: Capstone Software Design - Autumn 2008 |
 About Us |
Search |
Contact Info |
We have (exclusive) use of Sieg 324. This is an incredibly great situation:Entry is by card key. If you have problems getting in, send mail to cardkey@cs, or let me or the TA know. or .
- It's above ground.
- It's all ours (so occasional noise is no problem).
- It's a single place, so will encourage you to work in physical proximity to each other. (It turns out that is really important -- it's surprisingly hard to make progress if working in separate locations, even using technology like IM. This is especially true at the beginning, end, and middle of the course.)
- It's right down the hall from the animation class lab and classroom (and the entire animation scene is way cool).
We have about a dozen quad-core machines, donated by Intel, supplemented by a few dual-core machines. The machines are currently configured with Windows. One or more can be reimaged to run lab standard Fedora. (There are plenty of "game engines" that are portable across those platforms, so that probably isn't a major factor in this decision. Of course, there are some things that demand one or other other.)Machine local storage (it's own hard drive) is not backed up. Backed up storage is available from a file server; details depend on whether the machine you're using runs Windows or Linux.
As a matter of policy, the CSE 481 lab is run differently than all other labs. The boxes are never re-imaged, so you can install things and they stay installed. This also means that if a machine becomes corrupted it stays corrupted until someone tells support about it -- tell support about it.
The machines aren't reimaged because you have full freedom to install whatever (right down to what to boot), something you (or someone) will definitely have to do - we use easily available but non-standard software in this course, and part of your team's job is to pick that software.
This has some implications for how CSE 481D lab machines interface to the rest of the department resources and the world. For Windows boxes, they look basically exactly like standard lab Windows machines. For Linux, we install a firewall, standard file system mounts are not available (the files/storage are, just not by mounting), and we run a dedicated (and backed up) file server. On Linux, you have root (or at least sudo) access, which is the crux of the problem. (A lab Linux box is treated about the same as a personal Mac, to give you an idea of what it's like.)
There is a considerable amount of setup required to be ready to get your implementation work done - mainly installing the set of packages you need and checking out a working copy of the code from your team's source repository. For that reason, it isn't fun to sit down at just any old machine and try to do your work; you'd rather sit down at one that is already set up. As a result, lab usage usually evolves to a 1-1 mapping between machines and people.
/projects/instr/cse481d/08au/c481d-Xhas "unlimited" space for use by your team, where 'X' is your team letter. Unless there's some very compelling reason to do otherwise, your source repository, at least, should live in this space.Files created here are not deleted at the end of the quarter, like most other project space. In fact, there is no deletion deadline for them.
(You will lose access to these files some time after the end of the quarter, because you will lose membership in the required group. Get in touch with me if you need to see them after that, and I can provide either a copy or access.)