Defaultism

Three decades ago, a software company named Microsoft successfully started to use a new marketing device: the OEM license. With a pre-installed OS on you new-bought PC, users didn't think anymore about which OS to use - the default, pre-installed OS did indeed meet much requirements, so why should you ever take the effort of looking further?

Much has changed since then, but one thing has not: users are still using mainly the software bundled with the computer or OS, until it lacks important possibilities or they already have experience with a piece of software not present by default. Of course, I am guilty of this behavior as well: back in the days I was still using Windows, I started using a Linux distro because I was very sure it was better. But I became disappointed: as an unexperienced user, not all peripherals did work right out of the box, and messing with configuration files in Vi is quite difficult if all you ever worked with was Dreamweaver. I didn't start using Linux until I got a smooth working distribution out of the box by default settings (or by few and very easy configuration). This behavior I call defaultism.

Most of the Linux users don't act that way. At least, they think they don't. Because they install an OS that's not bundled with the computer by default. After some playing around with desktop enivronments they start looking around and they start discovering the shell. And more and more they become aware of the powerful possibilities. But this is where it ends for the most people.
For most Linux distributions, BASH (the GNU Bourne Again Shell) is default. And it's a pretty good one. It's powerful, relatively easy to use, there is a lot of documentation about it on the internet and - hey, it's default! Sometimes users try other shells like the C shell, the Korn shell, TCSH or ZSH. However, by default, the shells aren't configured the way Bash is. So they experience the shell as "difficult", say it has a "lack of possibilities" or isn't "accessible" enough. All because a decent configuration file is absent.

Last months I've become enthusiast about a particular shell - ZSH. But not before I got a useful .zshrc file - the ZSH config file you have to store in your home directory to make it useful. ZSH is much faster than Bash, extremely configurable and available on nearly every Unix-box. Including Mac. Including BSD. Including every Linux distro I've known so far.

Right now I discover I'm falling back into defaultism again - all I do is making some minor tweaks to existing zsh config files to get it working my way. I don't dive deep into the zshrc file structure to fine-tune it to my wishes. Again, I'm sticking with default settings.

Same story with Vim: I discovered Vim, got used to the basics and became very excited about the ease and efficiency of use. Still I didn't dive into the configuration to make it even more useful. I didn't explore all possibilities but a few - although they're very useful and even now Vim outperforms any other editor I've ever used. But still I stick to defaults.

"Never change a winning team" is well-known, but applied somewhat too easy. I think as computer users, sometimes we don't know whether we're winning or not.

Definitely, in many cases we know. As a beginning C programmer, I knew I wasn't winning when I din't use Makefiles. As a decent company, you know you're not winning when you don't have a website (Besides, are you decent at all without a website?). But in that case, as soon as you will get the opportunity, you will leap up and make sure the winning gear will be in house - before losing even more.
However, sometimes we don't know whether we're winning or not. I never knew I was not winning when I used Linux without using the shell. Until I experienced the advantages. I never knew I was not winning while sticking to Eclipse or gedit. Until I discovered the advantages of Vim. And I'm aware I will be winning when I set applications to my preferences.

Undoubtedly there are improvements out there still unknown to me. Everytime I choose the non-defaultist's way there are. So I got to keep my eyes open for the non-default way to keep winning.

(P.S. wanna get excited too about ZSH?
ZSH: the last shell you'll ever need (Fried CPU)
ZSH for productivity (Prashblog)
Phil!'s ZSH prompt
ZSH description from ArchLinux wiki)

VIM tutorial

We hebben gezien dat veel van jullie nog werken met de editor Kate / Kwrite. Weliswaar zijn deze editors toegankelijk en snel te begrijpen, ze werken voor een programmeur behoorlijk inefficient (bedenk alleen al eens hoe vaak je op de spatiebalk moet rammen tijdens een sessie programmeren of wat een moeite het kost om een loop in z'n geheel te indenten).

We zouden jullie willen aanraden om VIM te gaan gebruiken. Uiteraard kunnen we jullie niets verplichten, maar VIM heeft voordelen als:
- alles te bedienen met het toetsenbord ZONDER ingewikkelde toetscombinaties (Ctrl-Shift-Alt Z e.d. zul je niet tegenkomen)
- de aanwezigheid van verschrikkelijk geavanceerde functies (waar veel IDEs niet aan kunnen tippen), maar tegelijkertijd het binnen een seconde opgestart zijn en draaiend op de traagste systemen (of over je SSH-verbinding)

We kunnen hier nog wel even doorgaan met een lofzang op VIM, maar dat doen we niet. We zouden jullie willen aanmoedigen om VIM uit te proberen.
Omdat VIM een kleine drempel heeft om ermee te beginnen, heeft Tim een tutorial geschreven. Deze staat hier.

SCP (follow-up to SSH)

(If you don't know how to use SSH, first read the previous post)

Another post for the first year students of UvA..

SSH starts a remote shell, enabling you to work on a computer and have full control while you're on the other side of the world (but also if you're sitting next to it, of course). A little downside is, that you - when you're physically on another pc - cannot access your local pc from within the same shell. To move files to and from remote pc's over a SSH connection, there's another tool in Linux, called SCP.

(Before copying anything using scp, you don't have to log in to a ssh server. Of course it is possible to copy anything after logging in, but in that case the "local" file is in reality the "remote" file, and the "remote" file is a file on another "remote" server.

Syntax is quite simple if you're used to ssh:
scp user@host:/path/to/sourcefile /path/to/destinationfile
of course it will work in two directions:
scp /path/to/sourcefile user@host:/path/to/destinationfile
and, instead of destinationfile you'll also be able to specify a directory:
scp user@host:/path/to/sourcefile /path/to/destinationfolder/
use of wildcards is also permitted.
scp user@host:/path/to/sourcefolder/* /path/to/destinationfolder/

So, let's copy a all .txt-files from our UvA-home directory to the directory at the pc I'm now working on:
scp scienceaccount@sremote.science.uva.nl:~/*.txt .
(the last "." stands for "current directory")

Or, copy everything in my UvA-home directory to the directory called "uva_homedir" on the PC I'm right now working on:
scp -r scienceaccount@sremote.science.uva.nl:~/* ~/uva_homedir

SSH

A special post just for our beloved first-year students at UvA :).

It might well happen that you're at home and while having a beer with your dad (or anyone else) you remember you forgot to e-mail your assignment you was working on to yourself. Trouble. You just planned to finish your assignment tonight, but now you left everything you did at the university!

Well, I got some good news for ya: SSH.

On any Linux-pc with a working internet connection, just open a shell and type:

ssh user@host

to open a secured remote shell (where user has to be the user to log in on the remote pc, and host has to be the address of the remote pc).

In case of the University of Amsterdam, user will be your science-account, and host will be sremote.science.uva.nl, so:

ssh scienceaccount@sremote.science.uva.nl

After connecting (this will take about half a minute) you'll be welcomed by the FNWI welcome screen, and asked for your password. While you type in your password, the cursor will NOT move - this is default on UNIX shells.

After logging in, you'll get your bash shell and can access all your files directly. However, the policy of the sremote server requires us to ssh from there to a physical pc - no calculations are allowed at the sremote server (some people have been banned for that).

So, after logging in, choose a pc (ow124, ow125, .. ow141 and so on) and type:

ssh ow124

(because you are already logged in, your current username will be used, and because you're on an internal network you don't have to specify a domain name or something).

From that on, you can perform everything you can on a UvA-PC. Even running graphical programs (nautilus, firefox, try it!).

If the graphical part doesn't work, give SSH the parameter -X (capital x). This will enable X forwarding.

If you're in a Gnome Desktop Environment, you can also select "Connect to Server.." from the "Places" menu. Login credentials:
Service type: SSH
Server: sremote.science.uva.nl
Port: (default, leave empty)
Folder: (default, leave empty)
User name: Your science account user name
Name to use for connection: Be creative :).

After clicking "connect" you will be asked for your password. Now you have your SSH connection integrated in Nautilus!