Linux command: Screen

screen is one of those commands that you just fall in love with immediately and once you start using it, you will start to find a many ways to use it to increase productivity.

When you type, screen, it does this:

It opens up a new screen(logical) in the shell, which can be “attached” to or “detached from” at any point in time without affecting the process running with in it.

Use case 1: This is obviously useful when you are working on SSH. For example, if you have to start a long running build process from a remote SSH, then you would need to be worried about the SSH connection breaking off, because if you loose that session the processes that were started within that are also killed.

screen will help you here, you can start your process from screen and then detach from it, it would be then running on in the background and you can get back to it whenever you want, even if you loose your SSH session.

Use case 2: You want to start build and then be able to connect to same session from other machines/location.

screen will let you take(connect, interact, view) your sessions where your go. Its like portable little shell 🙂

Small tutorial:

$> screen

This will open up a new screen.

Play around a bit, it is just like a bash shell. One difference : press “Ctrl+A”   and then “?” This will show your screen commands.

[screen] $> <start your longrunning process>

[screen] $> “Ctrl+A” and “d”

this will detach from the shell and return to the original prompt.

$> screen -ls

this will list the screens you currently have going on.

$> screen -r <screenid[listed above]

This will “reattach” you to the screen, and you will be happy to see your process still running 🙂 Note: even if you loose the connection of the SSH.

This is probably the start, lot of other things that you could do with screen.

You could create new multiple windows, with in one screen.

Also, you might want to log the output of a screen, you can do that with “ctrl+a” + “H” (upper case) and that will create a .log file on the home directory.

That’s it I guess, to get started !

Proof-Of-Work : CAPTCHA for Machines.

While CAPTCHA works great for testing if the actor is indeed a human being and not a robot or a machine, there are time when you want to test if the actor is valid machine. In some cases machines would be accepted actors but we still want to filter out spammers to safegaurd against, say denial-of-service.

Proof-Of-Work is protocol that would help you just do that, it would let you know that the responding/requesting machine is genuine and not an automated spammer.

Use Case

You have a Server which provides free Forex Rates. This accepts connections from various clients which could be both machines and humans. Here we want to protect ourselves from denial-of-service from automated robots. Proof-of-work can be used here, conceptually it states that the client would need to perform some “significant” work and supply the proof of the same to prove it is indeed not an automated spammer. This relies on the economics that for an automated spammer, the sum of each of those significant work for each of the spam would significantly increase the cost for him.

This “significant work” generally your CPU power. You could imagine a complex calculation that would need to be done and then the result of that to be supplied as a “proof”. For a genuine user this is just once and it could cost him 1 second of his CPU power but for a spammer to send out 10,000 requests this would mean 10,000 seconds to  just prove his genuineness  and this would prove it economically meaningless for him.

Some implementations of the same:

Hashcash

Client Puzzle Protocol

Guided Tour Puzzle Protocol

WTF !

WTF !