Recognizing that not everyone has immediate access to a Unix system to do work and submit assignments, the following resources are available for your academic use:


The Internet Teaching Laboratory
A computer lab (frequently just called the ITL) in Science Center 334. All of the machines usually run Linux by default, but can be booted into Windows if need be; if you'd like to switch, just reboot the machine, and follow the instructions on the menu. The ITL is formally maintained by the volunteers in COSI, so if you're experiencing any problems (or just need help), feel free to cross the divider into Science Center 336 and ask anyone there. The ITL is open for as long as someone is in SC336, which is often very late into the night. Note that the ITL machines, while accessible from the public Internet, serve ssh on non-standard ports (to prevent automated scanning attacks), and it is generally discouraged to ssh into them to work on them (but you may ask if you'd like).
This is a Linux host (actually, a virtual machine) also maintained by COSI and administrated by Jeanna Matthews and the CS141 TAs. All students enrolled in the class should have an account on this; if it is not working for some reason, please contact one of the administrators, or anyone in SC336--who will probably know how to find an administrator. Odin's passwords must be changed manually; it is not part of Clarkson's domain (please ask if you'd like to know how to do this). Odin is accessible by its full name from anywhere on the public Internet (modulo restrictive firewalls), so you need not be on campus to take advantage of it.
This is a rather-outdated Linux host maintained by OIT. Being a university resource with access to far more than just CS141 material, OIT sets very restrictive permissions, and we have a very limited ability to administer it. In general, if you are having trouble with an account, you may contact Jeanna, who can get in contact with OIT on your behalf. Polaris always uses the same password as your student email, moodle login, PeopleSoft login, etc.; changing your password will have an almost immediate effect on your Polaris login. Polaris is also accessible from the Internet (again, ignoring firewalls).
Another Linux host server which runs a git and HTTP server. Its main purpose is hosting code for collaboration and revisioning. All students enrolled in this course should have an account, and the passwords between this, Clarkson's domain, and Odin are not shared (sorry!). It should, like the other servers, be accessible outside of campus; however, note that its website uses a self-signed certificate, and your browser will probably complain about that (it doesn't compromise security—it's just not "trusted [by someone else you 'trust']"). In general, to authenticate against your account correctly, it is highly recommended you set up an SSH key for this server through its web interface—see Using Git, below.


These are people and organizations that you may ask for some help with the course:

Yaoqing Liu
The instructor of the course this semester; consult him during office hours for questions about the course, grading, etc. (his Clarkson username is "liu"). He does not directly coordinate the labs for the most part (the TAs do).
Teaching Assistants
These are subjugate instructors of Liu, and usually also matriculated students. They will be directly overseeing the labs; feel free to ask them for help regarding them. Our current roster is myself (Clarkson username "northug") and Corey Richardson (Clarkson username "richarcm").
Clarkson Open Source Institute
The result of a large merge, COSI is a volunteer student organization found in Science Center 336 that is not affiliated with CUSA, but nonetheless recognized by the Computer Science department. Their members maintain a number of public services without pecuniary interest, including the ITL, Odin, and other non-course related services such as a software mirror, a backup (under username "newmanre") of the Internet Archive, the networking in both SC334 and SC336, and a number of graduate student projects. A few students have completed the course; feel free to ask around for their assistance, as they are more than likely able to help.
Office of Information Technology
OIT is the IT department of the university. Their responsibilities are far more vast than anyone single class, so they tend to be somewhat busy; nonetheless, they have relatively impressive turn-around times for technical issues, on the order of a few hours to a day or two. They are the sole maintainers of Polaris, so you should contact them regarding issues with signing in (not regarding course material, and in some cases, Liu's permission may be required anyway, so you might as well just ask him). In general, they are also a fair resource for any technical problems or issues stemming from the use of most other computers on campus, and are frequently kind enough to also look into issues with or recommendations for personal computers, in my experience.

Windows Programs

Windows is the only popular operating system which does not have a solid heritage in Unix; it derives a number of its behaviors from DOS (itself from CP/M, which competed with Unix back in the day). Most importantly, most of the Linux commands won't work in any of Windows' "command prompts", including PowerShell. Volunteer programmers have, nonetheless, developed some applications which will allow you to use the remote hosts anyway, essentially superseding the use of ssh and scp:

A software client for ssh, with a GUI, for Windows. The GUI is rather imposing and shows many esoteric features (most all of which can also be used from the command line), but you generally only need to worry about entering a domain name or IP address and clicking "Connect", after which it will prompt you for a username and a password. It will then open a terminal emulator that will allow you to work on the remote host.
WinSCP -
A software client superficially similar to scp, but with a GUI and far more flexibility at easily selecting files and directories, and keeps a connection open so as to avoid having to authenticate multiple times. (scp has long been known to be deficient in this endeavor; the program more correctly resembles sftp).

Using Odin

Odin is:

The latter is, significantly, why it it so important to know how to use Odin.

For a more in-depth explanation, please consult ssh and man ssh. For the impatient:

  1. ssh, where username should be replaced with your Clarkson username, or assigned credential (consult Jeanna or the TAs).
  2. If the host asks Are you sure you want to continue connecting?, type out yes in full and tap Enter. Depending on your known_hosts file, it may ask you this more than once.
  3. When it asks you for password, if you have not set a password yet, use cspassword. (Otherwise, skip to step 7.) You will not see the characters you are typing, but you are typing them; this is a security feature.
  4. Assuming cspassword worked, it will probably ask you to change your password. When it says (current) UNIX password:, type cspassword and tap Enter.
  5. It will ask you for (new) UNIX password: and to repeat it. Type the password you want (twice), pressing Enter after each.
  6. Assuming all went well, it will say something to the effect of password change successful. It will then kick you out. You'll need to start from step 1, but follow the instructions for having a set password.
  7. If you have a set password, type it in when it asks you for's password:. As in step 3, it will not display to you, but you are still typing it. Tap Enter when you're done.
  8. If all goes well, you should be at a shell prompt, nicely colored in green to distinguish it from other systems you might be on. To be sure, you should see @odin somewhere in your prompt. You may now start using the host as usual.
If you have any problems whatsoever with the above, please contact Liu or the TAs (and not OIT).

To copy files to Odin, as will often happen if you work on a machine other than Odin (such as your personal computer), you have a couple options:

The syntax for scp is not significantly different from ssh, and I recommend going to the command reference (or referring to the man pages for more information, but, again, for the impatient: specify a remote source or destination by appending a colon (:) and path to your pair.

Using Git

Git is a version control system. If you haven't used git before, here are some resources that you can refer to.

In any case, here's a rather brief synopsis of the commands you should know:

git status
Tells you as much as possible about the state of the repository--what files have been modified, what files are new, which of those are ready to commit later with git commit, and how many commits you have yet to git push to your various "remotes". If you're ever unsure about any of those details (e.g., if your work is saved to, if you've committed all your work so far, etc.). This command never changes any status, which means it's safe to use multiple times.
git add path [path …]
Stages changed files, which gets them ready to commit with git commit. For each path, if it refers to a file, and that file is changed or new, it will be staged; if it refers to a directory, every changed and new file under that directory (including in subdirectories) is staged. git add . from the repository root is a common way to add all changed and new files.
git commit [-a] [-m message]
Commits staged files—which you can review with git status—writing them into the history of your repository. Each commit represents a recorded state of your work (and some data about it, like who the author was and a brief message of your choosing). Note that commits are only stored locally until pushed elsewhere; use git push for that. Specifying -a will automatically add all changed files, but not new files. If you don't specify -m message, a text editor will open to allow you to type a commit message.
git push [-f] [-u] [remote [branch]]
Pushes (uploads) new commits to the specified remote and branch (defaulting to the current branch and the default remote for that branch). If -u, also sets the local repository to know where to git pull from—you usually only need to do this once. If -f, force the push to occur—this can destroy work!
git pull [remote [branch]]
Pulls a branch, and all of its commits (including new commits) from a remote branch (by default, the current branch, and the default remote for that branch—as set using -u to git push).