GitLab: where is it and how do I sign in?

When talking about GitLab at this course, we will always refer to the faculty instance at https://gitlab.mff.cuni.cz.

For login (username) you will be using your CAS credentials, i.e. the same ones as you use for SIS. Use the username derived from your first and family name (such as doejohn) instead of the numerical one.

If it does not work, please, try changing your CAS password (even if you change it to a temporary password and then back to the original one) to trigger a new password synchronization. Note that this synchronization can take a full day to be visible. If that does not help, contact us at teachers-nswi177@d3s.mff.cuni.cz.

Update: for some new accounts (typically for Erasmus students but can apply to BIOINF students as well in certain situations) it is necessary to wait for an extra synchronization round that is performed at midnight every day. Next morning, please, try to change the password as described above and try logging in to GitLab few hours after that.

Update #2: you need to have an account with so-called verified password (typically, this applies to Erasmus students). You need to visit one of these offices to verify your account.

Your first login will activate your account there. Only after that we are able to assign you to your project where you will submit your solutions.

Note that for some accounts, projects were enabled only after you filled-in your e-mail address in your profile.

Important: without an active account you will not be able to submit the graded tasks and pass this course.

Can I use a different operating system?

Well … yes, but be prepared that some things will not work. For example, WSL might seem to work but you may encounter unexplainable behaviour that is very difficult to reproduce and debug. In other words, you will be on your own. Other Unix flavors also have different behaviour in some cases.

This course is about Linux. Use it for your everyday work (other courses, photo editing or watching a movie) and you may actually find out that it is much easier and comfortable to use than other environments. If you approach it as a must-be evil that you need to live with to pass this course, (a) you might actually have problems passing the course easily and (b) you are deliberately throwing away a chance to broaden your horizons and learn something new.

The truth is that many of the tools we will be using are cross-platform. But Linux (or some of its ancestors) is their native environment where they perform the best.

Is it mandatory to attend the labs?

No. We try to provide all needed information on pages dedicated to labs. We expect (and encourage you to do so) you will attend the labs if you are unsure about some of the tasks, if you get lost or do not understand something.

If everything is clear (or you already passed similar course somewhere else), you do not need to come. But you are welcomed to attend and participate.

Just do not forget to submit solutions to the graded tasks in time.

Can I use other distribution than Fedora?

Sure, there shall not be any problem.

There are differences in package naming across distributions thus the packages names we mention may slightly differ.

The only big issue we still encounter is that some distributions still prefer Python 2 as the default (so that package python-something refers to Python 2 version of something and for Python 3 you need to install python3-something). All our examples will target Python 3 as Python 2 reached EOL two years ago.

There will be of course differences when we talk about installation and package management but the general steps are virtually the same across all major distributions (and if you use some special distribution, you already know what you are doing hence you should be able to translate the commands to your environment).

What are the default passwords?

If you use disk images from us, following are the default usernames and passwords. For USB/Qemu/VirtualBox, user intro, password linux (and root with password toor). For the Live ISO, there is liveuser also with password linux.

Change these passwords as soon as possible. You can use the passwd command for that.

How to interpret automated test results on GitLab?

When you open your course project, you will notice that there is either a green or red icon next to your last commit message representing state of your project.

Clicking on the icon will show detailed record of the actual tests. There will be usually several subgroups (jobs) that refer to before-class quizzes and post-lab assignments.

Opening either of them will show you a transcript of actions that were performed by GitLab for you.

The important part starts with bin/tests.sh followed by text similar to the following.

1..3
ok 1 99/assignment.py - Submitted (0)
ok 2 99/assignment.py - Has correct shebang (-10)
not ok 3 99/assignment.py - For input 12 (20)
# -- output differs --
# expected (3 lines):
#   2
#   2
#   3
# actual (1 line):
#   8
# --

This is a Test Anything Protocol (TAP) output that says that it executed three tests (1..3).

The test line consists of four parts: whether the test passed (ok) or failed (not ok), assignment name (usually refers to actual filename with your solution), test name (what was actually tested) and approximate scoring information (in parenthesis).

When all tests are ok, it means you solution is fine.

For a failing test, we also provide further description of the failure. TAP uses comment-like syntax of prefixing the lines with extra details with the hash sign (#). In the example above, we show expected and actual output.

If the assigned points are negative, it means that this amount of points will be subtracted if the test fails. If the test passes, no points are added (obviously, we will not subtract points for a passing test). In other words: ok test will add points to the total score or not influence it at all (i.e., passing test with negative score is nothing to be worried about).

We use the negative scoring for things that you should already know for some time. For example, first assignments that required an executable bit to be set added extra points for that: it was something new. But further assignments subtract points for not setting the executable bit (by that time it is something well known and running chmod should be a natural step after creating any script).