This page provides answers to some commonly asked questions. Feel free to use the GitLab issues if you cannot find an answer here.
I just enrolled in the course, what should I do?
Welcome! Take a look around the website, especially the links in the side bar which lead to additional pages with information about lectures and labs (along with links to resources).
These are the essential points for getting started:
-
Most information in this course is disseminated through Git repositories in MFF GitLab. It is therefore imperative that you have a working account. You should be able to log in using your SIS user identifier and password — the account will be automatically created on your first login.
-
Visit the course project group and open your repository in the
student
sub-group. The repository name corresponds to your SIS identifier. The repository title page contains links to information about course organization (the rules document), self study instructions for each lecture, quizzes, and project implementation specifications.If you cannot find your repository even though you have been enrolled in the course for longer than one day, please let us know.
-
Read the rules document.
-
Keep in mind that self study is a mandatory prerequisite to lecture participation and the lecture will not substitute for self study. Similarly, labs are meant for discussion about project implementation and we assume that you will have read the specifications.
-
Check for quizzes and milestones that you can still submit within the deadline, and start working on them as soon as possible.
If you have any other questions, please post an issue in the forum GitLab project. If you are unsure whether the question is not revealing too much (e.g. answer to a quiz question), make the issue Confidential so that only teachers can see it.
GitLab: where is it and how do I sign in?
When we refer to GitLab in this course, we always mean the faculty instance available at https://gitlab.mff.cuni.cz.
Use your CAS credentials to log in, i.e., the
same credentials you use to access SIS. Use the username derived from
your first and family name (such as doejohn
) instead of the numerical
identifier.
Your first login will activate your GitLab account. Without that, it is impossible to provide you with access to project repositories required for participation in this course and you will not be able to submit the assignments and quizzes required to pass this course.
Troubleshooting
If you cannot log in, try changing your CAS password (even to a temporary one — you can change it back to your original password later) to trigger password synchronization. Note that you may need to wait up to one full day before the effect of the synchronization becomes visible.
For some new accounts (typically Erasmus students and, in certain situations, also BIOINF students) it is necessary to wait for an extra synchronization round that is performed at midnight every day. Try to change the password the next morning and try logging in to GitLab few hours after that.
Note also that you need to have an account with so-called verified password (this typically applies to Erasmus students). You need to visit one of these offices to verify your account.
Also note that for some accounts, projects were enabled only after you filled-in your e-mail address in your profile.
If nothing helps, contact us as soon as possible via e-mail.
Logging to the lab
machine
Connect to port 22004 (standard SSH port + old course code) of the machine
lab.d3s.mff.cuni.cz
using your SIS credentials.
Consider adding the following fragment to your ~/.ssh/config
to simplify
the login to bare ssh nswi200
.
Host nswi200
HostName lab.d3s.mff.cuni.cz
User YOUR_SIS_LOGIN
Port 22004
Note that this machine contains all that is needed to compile and run the assignments.
Please, do not use any remote development features of modern IDEs on this machine as they tend to eat all the available disk space by downloading various helper binaries over and over again (or clean those binaries manually after every use). Thank you.
Logging to GNU/Linux machines in Rotunda lab
You will need a Secure Shell (SSH) client. On GNU/Linux machines, the
SSH client is typically part of a base installation, so you should be
able to simply run the ssh
command. Windows 10 (21H2 and possibly
earlier versions) provide an OpenSSH client as an optional component.
If the OpenSSH client is not available, you will need to install an
external SSH client. We recommend using PuTTY,
but feel free to use any other client.
Connect to u-plN.ms.mff.cuni.cz
(where N
is a number between 1 and 23)
using your SIS credentials (i.e. the same username and password).
Note that machines in Rotunda use AFS and Kerberos and thus it is not possible to setup a login via a public SSH key.
Keeping your fork up-to-date
Most of the (later) milestones and the self-study material will be published in form of changes committed to the respective upstream repository. You are expected to merge these updates into your private repositories. When you view your private repository in GitLab, the corresponding upstream repository will be shown as the repository you Forked from.
For example, when we add a new quiz, we will commit the changes to the upstream repository.
To merge these changes into your private repository for the first time, you need to perform the following steps (for subsequent updates, you will only need to perform the last 3 steps):
-
Clone your private repository and/or change to the directory with the clone.
git clone git@gitlab.mff.cuni.cz:teaching/nswi200/2023/student/LOGIN.git
cd LOGIN
You need to be inside the clone directory for the subsequent steps.
-
Add a remote pointing to the upstream repository.
git remote add upstream git@gitlab.mff.cuni.cz:teaching/nswi200/2023/upstream/student.git
This only needs to be done once per clone.
-
Fetch changes from the upstream repository.
git fetch upstream
-
Merge the changes.
git merge -m "Merge upstream changes" upstream/master
Git will respond with an
"Already up to date."
message and do nothing if there is nothing to merge. -
Push the merged changes from your (local) clone back to your private repository on faculty GitLab.
git push
A more detailed explanation is also available in the labs for Introduction to Linux course (NSWI177).
Merging partial changes from upstream
Sometimes we may publish minor updates to the assignment (e.g. when we find a bug in the tests). And thus sometimes you may need to merge only certain upstream changes.
To merge only certain commits (note that it is possible to select any commit via cherry-picking, the following focuses on the simpler case when we want to merge up to some commit) following commands will do the trick.
Assuming we are inside the directory with your team repository and that your team is using the RISC-V variant of the operating system skeleton:
-
Ensure we have upstream up-to-date.
git remote add upstream git@gitlab.mff.cuni.cz:teaching/nswi200/2023/upstream/team-riscv.git git fetch upstream
-
Merge changes up to a certain commit first.
git checkout master git merge abcdef0123456789-commit-hash-goes-here -m "Merge upstream changes"
-
Optionally, we may create a new branch where we would merge rest of upstream changes.
git branch m03-import git checkout m03-import git merge upstream/master -m "Merge M03"
Introductory materials
The materials from the Computer Systems (NSWI170) course can help in refreshing your knowledge of the C language and basic principles of program execution.
- C language basics
- Instructions and compilation of basic programming language constructs (also contains an introduction to the MIPS instruction set)
The materials from the Introduction to Linux (NSWI177) course can help in refreshing your knowledge in the following areas: