Among certain circles, there is a general agreement that university Computer Science courses don't teach practical basics, or equip students to work with actual computers. This begs the question, what would a reasonable course look like?

When I worked at an IT outsourcing company, I would test people's computer skills. Droves of people with fancy qualifications would enter the course, and fail at very basic tasks.

Interacting with highly-qualified people online and in the flesh has left me astounded that they struggle to modify their own operating system, or even to use git.

Of course, when a university teaches computer science, it teaches theory - 'Big O notation', and octets, and such, not high-contingent facts about the latest fashions in coding languages. But we shouldn't let them off with too much responsibility, since almost every student wants to use this information to go into IT later, and learning the basics of git just takes an afternoon.

A Changelog of IT

Things are as they are because of how they were. If you drill down into a problem with a computer, you may - one day - find some 'computer science facts' about octets. But you'll find facts about Unix computers much more often.

Just the other week, I had a nightmare of a problem where I searched for a project's URL to assign it automatically:

1    $ URL="$(grep '^Domain' config.toml  |  cut -d: -f2)"
2    $ echo $URL
3    example.com

The terminal gave me back what I wanted: example.com. So I got the next part: the position in the web address, and put them together.

1    $ suffix=posts
2    $ echo "$URL/$suffix"
3    posts/e.com

This is not what I wanted! Where did posts/e.com come from?

Eventually, I saw the second variable coming first and overwriting the first, and figured it out:

1. 'example.com' was written in a file.
2. That file was written on Windows.
3. Linux ends a line of text with 'new-line': \n,
4. but Windows ends a line of text with 'new-line, return': \n\r.

The 'return' means 'carriage return', which means this:

Hello mister type-writer. I have typed a line of text. Please return your typing-carriage, which holds the paper, to the far-left, so I can start typing another line of text.

The computer had typed:

1e x a m p l e . c o m\r
2p x a m p l e . c o m
3p o a m p l e . c o m
4p o s m p l e . c o m
5p o s t p l e . c o m
6p o s t s l e . c o m
7p o s t s / e . c o m

Without knowing a little of the history of Unix and terminals, I wouldn't have been able to fix this problem.

Never Study

I love git. I use it for everything. But an unfortunate soul, studying IT, told me he hated it.

The problem was not git but 'study'; he had to read about it, memorize commands, and do exams. But I just had problems, and the solution was git.

Virtual History

If the best way to understand how computers work is understanding how they once worked, and what broke, students will understand most easily by using replica 70's computers, and experiencing those problems.

There's little point in replicating those actual machines (that would be expensive!), it'd be enough to limit memory and processing power on a little virtual internet.

1970

• A scanty VM with extremely limited resources is spun up. All students must use it at the same time.
  • File permissions let them assign certain things to groups.
  • Everything is plain-text or binary. No 'python' or whatnot: just shell and C.
  • The users have no $PATH variable - they can only see files by typing /bin/dir.
  • Electronic-mail allows messages to flow between them.
• The computer has myriad problems. Virtual users (set up with bots) send emails back and forth. Each student has to administer them, and ensure all their emails reach each other.
  • Your computer still has not set up NTP. There are no instructions except old manuals, but you can work together with others so everyone gets their NPT programs set up to start when the computer boots.
  • The computer's file system is made of multiple disks, and the disks will randomly break. Students must organize backups between themselves, despite limited disk-space.
  • Time to archive with ar, chat over telnet, and (later) ssh.

We don't need accuracy: we need to know what problems DNS and git solve.

1980

• As the virtual sub-net connects to other universities (by raw IP addresses) the little sub-net grows.
  • They only have a few addresses, so it's time to keep a list of who is at which IP address in the /etc/hosts file.
  • Students will have to swap information about updating hosts files.
• The class has multiple computers. Random students receive emails containing source code for new software: the tarball.
  • This student can distribute it (or package the binary and keep it safe).
  • You can now compress a directory and the files inside, using the 'tape-archiver'.

1990

• Everyone is screaming about licences.
• Git will soon arrive to save the day.
• Emails deride GUI as a passing fad.
• Python means a lot more code is being written, though it runs slower than the simple binaries.

2000

• Flash animations
• Virtual users use payment-systems; the internet now handles money.

Actual Setup

I have no idea how fast this should be, and while a hidden sub-net is easy in practice, making the thing so locked-down that nothing can enter those computers without students typing it in themselves will probably become very difficult. Perhaps the biggest barrier to students just going onto the web and downloading modern software is their computers' small sizes.

Ideally, this course would take place across a series of retreats, without any internet beyond the fake sub-domain.