CSCI 2330
Foundations of Computer Systems
Spring 2024
Instructor: Sean Barker
| Release Date: | Monday, January 22. |
| Acceptance Deadline: | Tuesday, January 30, 11:59 pm (same as due date for Lab 0 only). |
| Due Date: | Tuesday, January 30, 11:59 pm. |
| Collaboration Policy: | Level 1 |
| Group Policy: | Individual |
This introductory lab is designed to introduce and familiarize you with many of the tools that we will be using throughout the semester. Most significantly, this lab will teach you the basics of working in a Unix/Linux environment, using the command line, writing and running programs on remote servers, and version control. Getting a handle on your working environment early on will save you lots of time in the long run and let you focus on the actual course material of the later labs.
First, read the class syllabus so that you are aware of important course policies. If you have questions or need clarifications on anything in the syllabus, please let me know! Going forward, I will assume that everyone has read and is familiar with all policies and procedures detailed in the syllabus.
Somewhere within the syllabus is a code (unique to you) that you'll need to submit in the next part of the lab. Make a note of this code!
Questions, discussions, and announcements in this class will all make use of Slack, which is a channel-based messaging platform. Slack will provide a convenient, efficient way to communicate with me, the LAs, your classmates, and your team (for group assignments).
Slack will be used in preference to all other written forms of communication outside of class, including (and especially) email. Once you have Slack set up, do not send me email; send me a direct message (DM) on Slack instead! Similarly, I will post important announcements and information to Slack instead of sending email. Therefore, it is critical that you are configured to receive Slack notifications so you do not miss important information from me. Follow these steps to get set up:
The Slack contains five public channels (visible to everyone): assignments (for discussion of lab assignments), general (for announcements and general discussion), inclass (for discussion of in-class material), random (for anything off-topic), and scheduling (for the regular LA and office hours schedules and any temporary schedule changes). You can also create (private) DM threads with multiple participants. To post anonymously in a channel, just type your message like so: /anonymous This is an anonymous message (but note that you cannot reply anonymously inside a message thread). Messages can also be edited or deleted after posting.
Now that you are set up in Slack, you should rarely, if ever, need to send me email! Just DM me instead.
One Slack caveat to be aware of: due to how Slack operates free workspaces, messages are automatically archived (and not easily retrieved) 90 days after being sent. As a result, the class Slack should not be used for any long-term storage (and note that 90 days is a bit less than the length of the semester, so messages sent during the first few weeks of the semester will no longer be accessible prior to the end of the semester).
Go through the Command-Line Unix Crash Course (except for the version control section at the very end). If you have never worked in a command-line environment before, this tutorial may take you some time. If you have some Unix background, you may already have seen most of this material (but you should still at least skim the tutorial to make sure).
A few parts of the tutorial involve short snippets of C code. Don't worry if you've never written any C code before; focus on the conceptual ideas being illustrated (e.g., the process of compilation and the use of command line arguments) and don't get bogged down by the details of C at this point. We'll dive into the details of C later in the semester!
There is nothing to submit for this part.
The Unix tutorial above had you working on dover.bowdoin.edu, which is one of Bowdoin's campus-wide Linux machines. However, for the rest of the course, you must use the designated CSCI 2330 server for all lab work, which is hopper.bowdoin.edu (or just hopper for short if you're on campus). Even if the lab files appear to compile and run on your local machine or one of the other Bowdoin servers (like dover), there are subtle differences between operating systems that may cause hard-to-debug problems. Avoid these problems by always working on the class server (which is also the server that will be used to evaluate your programs)!
You have been provided with an account on hopper that will allow you to log in and work on your labs. Access to your server account is by SSH key only (no password access). You should have received your keyfiles from me via email (if not, let me know immediately). For instructions on using your key, refer to the relevant section of the Unix tutorial. Make sure that you are able to login to your account on the class server using your key. If you have trouble, your first stop should be the Unix tutorial. After that, you should ask for help via Slack (or office hours).
From this point on, all lab work in this course should be done on hopper unless otherwise noted. The class server provides a full-fledged Linux environment with all the standard development tools preinstalled (editors, compilers, version control, etc). If there is any software that you would like to use that is not already installed on the server, please let me know and I can probably install it.
Go through the Git Essential Training Companion Guide, which will guide you through a video series in order to learn how (and why) to use the git version control system. This guide is divided into three parts: (1) the core video series on git, (2) a section on working with GitHub, and (3) a section on using git and GitHub for team collaboration. Skip the collaboration section for now (part 3), since the first few labs will be done individually. We will return to this guide before the first group-optional project.
You should go through this guide even if you already have basic experience with git or GitHub, as you will undoubtedly learn some new things and also make sure that your environment is set up correctly.
Remember to use hopper (as opposed to dover) while you are going through this guide. When you are setting up your GitHub account, you should configure your GitHub account to use the SSH key that you were provided to access hopper. Your key is already installed in the right place on hopper, so all you need to do is add the public key to your GitHub account (as detailed in the git guide).
Each lab assignment in this course (including this one) will have a personal git repository accessible only by you and myself in which you will complete and submit your work. At the start of each lab, an invitation link will be posted to Slack that will initialize your personal lab repository on GitHub and add any starter files. Once your lab repository is initialized, you can clone it to hopper and then begin to work.
Finally, you will complete a few simple tasks on the class server to check your understanding and account configuration. The main objective here is to make sure that all systems-related issues are dealt with now, as opposed to right before the first 'real' lab is due.
Your task is to write a very simple C program and a Makefile for the program, then commit your files to your private lab repository and push them to GitHub.
git should not ask you for a username and password during the clone. Once you have cloned the repository, cd into the new lab directory.
The only starter file in this directory will be a README.md file.
like.c that simply prints the message "I like [xyz]!" where [xyz] is the first command line argument. If the program is not given any command line arguments, or is given more than one, it should instead print "What do I like?". Here are a few examples, assuming the executable compiled from like.c is named like:
$ ./like pizza I like pizza! $ ./like Linux I like Linux! $ ./like What do I like? $ ./like Linux pizza What do I like? $If you've never written a C program before, just use the example in the Unix tutorial as a starting template and modify that; you don't need any further knowledge of C to complete this part.
//).Makefile for your C program. Your Makefile should have two targets: the default target (which should be named like) which compiles the program into an executable named like, and a clean target that deletes the compiled files (which in this case is just the like executable). Follow the Makefile example given in the Unix tutorial. Put your name in a comment at the top of your Makefile (comments in a Makefile start with #).make again before you could run the program again):
$ make like $ ./like systems I like systems! $ make clean $ ./like systems -bash: ./like: No such file or directory $ make $ ./like make I like make!
git repository using git add, then commit them using git commit. You will need to specify a commit message describing the changes that you made; at this stage, that message might be something like "added program files". In keeping with best practices, don't add any generated files to the repository (e.g., the like executable). If you want to get fancy, you can add this filename to your .gitignore file so that it won't clutter up your git status output.git push. This step constitutes submitting your lab. You can push your commits to GitHub as often as you want (and doing so regularly is a good idea), but only your final submission prior to the deadline will be considered.This lab will be marked pass/fail only based on the following criteria:
like.c program follow the specification above?Makefile with both the default like target and a clean target?The most common mistake students make is forgetting to commit and push to GitHub (or doing so improperly). Be sure to verify that you did so correctly via the GitHub website as described above.