CS 202 - Working On Your Own Computer
So you don't want to use the lab machines... Unlike the work you may have done in other CS classes, some of the things we do in this class will be quite OS or tool version specific. You are welcome to work in whatever manner you like (gcc can certainly be installed on OSX and windows machines), but be aware that your work will be graded on a Linux machine and "but it worked on my machine" will not be an acceptable excuse. Thus, at the very least, you should test any code on the lab machines before handing it in.
The best approach, however, is to find ways to do your work on Linux from your own computer. There are a couple of ways you can do this.
Install Linux on your computer
If you really want the full geeked out experience, go ahead and install Linux on your machine. You can dual boot, or commit fully and leave behind those pretty closed source operating systems. I don't necessarily think this is the best option, but I would be remiss if I didn't mention it.
Install Linux on a virtual machine
A much better solution is to run a virtual machine. Running Linux virtually gives you most of the advantages (and experience) of installing Linux on your computer without requiring you to risk your existing setup. This is a great option if you want to know more about operating systems and Linux in particular. You will have a Linux box that you can beat on and experiment with without any real risk (though I don't recommend experimenting too wildly the night before an assignment is due when you are relying on the image to do your work). The only downsides to the virtual machine approach is that it will take a big chunk of harddrive space and there will be a performance hit from the virtualization layer.
Professor Johnson has put together a set of instructions for getting up and running with Arch Linux, which is not what we run in the lab, but should be close enough for everything we care about.
If you follow his instructions, you will need to install gcc and whatever your favorite text editor is in order to do the assignments.
Note: This option will take some time to set up, don't start this in the hours leading up to a homework deadline assuming you can do this and then bang out the assignment.
Connect remotely
A lighter weight approach is to just go ahead and connect to the lab machines from your computer and work remotely. You can connect to any of the lab machines using ssh (secure shell). On OS X, ssh is built in and is available from Terminal. On Windows 10, I believe that ssh is available in the PowerShell. For older versions of Windows, or if my information is wrong, PuTTY has long been a reliable ssh client.
From a local command line (OSX Terminal or Windows PowerShell), you can type ssh snake.cs.middlebury.edu, and you will connect to snake (provided the machine is switched on). All of the lab machines are available this way (don't know the names of the lab machines? Try some Vt mountain names...). In addition to the machines in the lab, you can log into basin.cs.middlebury.edu, which has the advantage of being available from off campus.
If you go this route, your life will be more pleasant if you set yourself up with ssh keys so you don't need your password to log in.
Of course, all this gets you is shell access to the machine, not a full Linux graphical environment. So, you can compile, debug, etc, but unless you use a console based text editor, you won't be able to edit your files in the way you can in the lab. There are a couple of ways to deal with this.
Use a console based text editor
The simplest solution is to just learn how to use a console based text editor like emacs or vi. This is light weight and will always work. Every Linux machine you encounter will have vi installed and the vast majority will have emacs, and knowing how to use at least one of this is a good skill to have. In combination with a tool like tmux, you can create a respectable development environment over a single ssh connection.
Work local, compile remote
There are a number of ways to do this, but the basic idea is that you use a local text editor and then move the file over to the remote machine for compiling and debugging.
One way to do this is using the scp command line tool which works just like cp, it just can connect to remote machines over ssh. This works, and if you are doing fully local development and just are making the final test before handing in your work, this is fine. This would be really annoying for normal development cycles and inevitably you will forget the push the changes across and start banging your head against the wall when your changes don't seem to be having any effect.
Another approach is to mount basin as a remote drive. This allows you to edit the file locally, letting NFS handle the transfer when the file changes. This is a little more fluid than copying the file manually, but sometimes NFS doesn't propagate changes as quickly as you can move from your editor to the terminal window.
A compromise for the enterprising types is to write your own script that detects changes and syncs the file to the remote machine (you could also use existing tools like unison or possibly even Dropbox to do this for you as well).
A final approach is to use an editor that does remote editing or syncing. A quick search reveals three packages for Atom that claim to handle this with various levels of transparency: remote-atom,remote-edit,and remote-sync (I can't vouch for any of them as I've not tried them yet). The idea is to let the editor handle the file updates over ssh for you. I've not yet tried the Atom package, so your milage may vary. Other editors will have similar capabilities. There are also some SFTP clients, like Cyberduck, that will handle the file synchronization between a local editor and remote file system.
Export X windows
Yet another approach is to forward the Linux windows over your ssh connection. To do this, you will need a local version of X Windows (XQuartz on OSX or X Windows from Cygwin on Windows). Start the appropriate local window server. Connect to one of the lab machines over ssh using the -X or -Y flag (-X is the normal one, but OS X usually prefers Y which bypasses some of the security extensions). This does not work when connecting to basin, because basin runs headless and there is nothing to export. You can then open your favorite GUI editors remotely (where your files are) and they will display locally on your machine (where your fingers and eyes are). The downside of this is that is that it can be somewhat slow.
If you come up with some other technique that works well for you that I've missed, let me know and I will add it to the list.