Draconis Software Blog

Uses of GNU Screen

A relatively under-used and unknown tool, GNU Screen has been gathering more interest as of late. Screen is described as a “terminal multiplexer”, a somewhat complicated way of saying that it lets you run multiple Unix-based console applications within a single terminal. In practical use this is done with separate “windows”, which are different views within the same terminal. For example, you could have one window connected to your email client, one monitoring recent syslog events, and one executing a build. Actions like creating, deleting and switching between windows are done through simple key combinations.

In addition to this, you can also keep screen running even after you close your connection, and then restart the session again later. This is a feature that I’ve found to be incredible useful. It allows me to, for example, detach my screen session when I leave work, and then restart it at home continuing right where I left off, with each window intact. You could also use screen to keep multiple connections open to various machines, although there are potential security issues with this.

There are a number of other neat features of screen, some of which are described in this tutorial from Kuro5hin. Another more detailed tutorial can be found here. One feature I especially like is the ability to have split screens, so you could do something like viewing the output of a number of logfiles all at once.

A recent Linux.com article discusses using screen for remote interaction. Screen can allow multiple users to access the same session, at the same time. This provides a simple way of doing “distance education”, as well as remote demos and tutorials.

Although screen isn’t the most widely known GNU program, it’s one of those utilities that once you start using it, you can’t imagine life without it.

The networker’s lifeline: maximizing battery life

Thought I’d take a moment to point out several resources you should checkout if you spend any amount of time traveling with your laptop (or any electronic device, for that matter). Many sysadmins rely on their electronic devices, and losing laptop battery power while far from an electrical plug could mean big trouble for users.

So, if you want to stay connected, follow these tips.

(Read the article)

The tech behind OLPC

You’ve probably heard of the One Laptop Per Child organization first announced in Davos, Switzerland in 2005, and how the project has made some significant progress towards the $100 per laptop goal, first suggested by Oracle’s Larry Elison. Currently, the organization plans to hit about $140 for the first iteration of the laptop, eventually reaching the $100 mark sometime around 2008. There’s a lot of interesting technology behind the OLPC, with much of the concepts readily applicable to other IT-related industries, which I thought I’d explore today.

(Read the article)

Amazon’s Mechanical Turk: Artificial Artificial Intelligence

Clive Thomson has an interesting article on Mechanical Turk, a new Amazon company. Mechanical Turk provides developers with an interface for solving problems that are better solved by humans. As Clive puts it:

Computers suck at many tasks that are super-easy for humans. Any idiot can look at picture and instantly recognize that it’s a picture of a pink shoe. Any idiot can listen to a .wav file and realize it’s the sound of a dog barking. But computer scientists have spent billions trying to train software to do this, and they’ve utterly failed.

Mechanical Turk provides an interface for people to complete simple tasks like these, and get paid for their work (albeit very little).  An example of a successful business that uses Mechanical Turk is CastingWords, a podcast transcription service. Computerized voice recognition is still shaky, especially for something like a podcast, whereas humans can do it quite easily. Other examples of tasks in which Mechanical Turk can assist are image recognition, surveys, or aesthetic evaluations.

Each task usually pays anywhere from a few cents to a few dollars, so it’s unlikely that the humans completing these tasks could make much of a living at it. But a few minutes here and there could bring in a few extra dollars a day. Interestingly, the article also mentions potential labor issues, as Mechanical Turk provides a “virtual day laborer hiring hall” for things that companies might otherwise pay wages for.

I’d be curious to here feedback from users, either from the developer or the worker side.

Cross-platform automated backups

Today marks the last day of our backups week. Hopefully by now you’ve realized how important it is to keep updated backups of your important files, and, as this weeklong feature has hopefully demonstrated, getting a working, efficient backup system into place is anything but difficult.

So far this week we’ve discussed how to setup and use rsync on Linux, Solaris, Windows, and MacOS X to create a useful, automated backups system. We’ve focused on using a single Linux box as the rsync server, but that doesn’t have to be the case: any of these platforms (and others, as rsync has been ported to many different platforms) can be used as an rsync server with nearly identical setup to that which we’ve already explored.

(Read the article)

Automated backups in MacOS X

It’s day four of backups week at the Draconis Blog, and today we’re going to be taking a look at the MacOS. Similar to the Linux setup, getting rsync to work on MacOS X is very easy (it should already be installed with your system).

If you’ve been following along, you’ll notice there are lots of similarities between the different platforms we’ve covered (Linux, Solaris, and Windows) and today’s focus is on the Mac. The main issues we faced are slight platform discrepencies (i.e. using Scheduled Tasks in Windows over cron, directory path names, and using the Cygwin tool in Windows), but using rsync has been universal. And today is no different.

As a quick recap, we have a single Linux rsync server setup to facilitate the transfers between any other computer on the network. This Linux box has plenty of free disk space (mounted at /backups) and has a different rsync profile for each host. Remember also that transferring to the server or from the server makes little difference, as far as rsync is concerned.

(Read the article)

Automated backups in Windows

It’s day three in our week-long exposè on automated backups, and today we’re taking a look at rsync in Windows. If you’ve been following along, you’ll notice setting up rsync in Windows is nearly identical to setting it up under Linux or Solaris (or MacOS, as we’ll look at tomorrow). The trick is to use the great Linux command-line emulator Cygwin, which creates a Linux “environment” on top of Windows. This article will take you through the installation process for Cygwin, and setting up rsync to automatically back up your important documents.

In the first installment of this series, we discussed how rsync communicates – there’s a server and a client, though which is which often doesn’t particularly matter. For our purposes, I’m using a Linux box as the rsync server and transferring all my documents there (and, as we saw yesterday, you can both send and receive documents regardless of which computer is the server).

(Read the article)

Backups in Solaris using rsync

It’s day two in our backups week, and today we’ll be looking at automated backups in Solaris. As I mentioned previously, we’ll be using the rsync tool to regularly send important files over to a Linux server for safekeeping (as well as to keep an additional copy locally).

Setting up rsync in a Solaris environment is very easy (and, naturally, is almost identical to setting it up under Linux). We’ll be sending the important files over to Linux, but there’s actually an additional wrinkle: my Solaris box has a very large RAID storage system (this happens to be a Sun E250 with several SCSI disks builtin – so I have about 50 gigs of space left over that I’m not otherwise using), and I’d like to keep another copy of my Linux backups on my Solaris box – backups of backups. It probably sounds crazy, but there’s actually two reasons for this: (1) the Solaris box isn’t in the same place as the Linux backup server, and (2) I need to backup my Linux files somewhere.

So, we’ll be first sync’ing all of our Solaris files over to the Linux box, and then asking for a copy of all the backups under Linux to also be on my Solaris RAID array. Simple.
(Read the article)