Carlos Fenollosa — Blog

Damn Small Linux on a Libretto 50CT

In about 2004 a friend from college got into his hands a series of Toshiba Libretto 50CT. They all came with Windows 95 pre installed, and we wiped them out and installed Debian with a 2.2 kernel from floppies, with much pain because of the unsupported disk drive. I remember it being so difficult that I don't even want to write about it. But it booted and was able to run Vim, Links, and connect to the internet. Enough for a network-enabled typewriter.

I got Richard Stallman to sign mine while it was running GNU/Linux, but when I bought a regular laptop I stopped using it because, well, it is too old, and its keyboard is too tiny to type comfortably with it.

The Libretto, closed. It is a tiny machine, a wonderful piece of engineering.

Around 2012 I found it inside a box at home, working perfectly, with a battery life of a bit less than an hour—which is incredible for a 12+ year old machine— and DR-DOS installed. I can't remember why I did that, but Golden Axe was also installed, so there's a hint.

I decided to install a modern Linux and, at least, store it on a working condition to give some justice to Stallman's signature.

There are some tutorials available on the net, but none of them covered 100% of the hardware support for my machine. Most of them are also outdated, and refer to distributions that don't exist, don't have any support or are about unusable nowadays. However, I took many hints from those tutorials, and I will reference them accordingly.

Hardware

This laptop has a 75 MHz —actually, mine reports 74 MHz— with 24 MB of RAM, which is an upgrade from the original 16 MB which are usually bundled. The screen is 640x480, and if you choose a higher resolution, instead of scaling the image, it only displays the upper-leftmost 640x480 pixels, leaving the bottom and rightmost part of the area out of sight.

The mouse device is emulated as a PS/2, and physically is a "clitoris"-like pointing device. You know what I mean. Working with the X windows is a pain in the neck because the location of the mouse and buttons isn't very ergonomic, and clicking on a button makes the whole screen move on its hinges.

Next to the mouse there is a speaker which is similar in quality to those of a modern smartphone.

This device doesn't have any extension port other than a dock connector for a dock I don't have, and a 16-bit PCMCIA slot, which you will need for the network card. It doesn't have a COM port or anything like that, which is understandable, given the size of the case.

It does have an Infrared device, which is quite slow and useless, but for its time it was as good as wireless could get. The other holes correspond to the power adapter and the reset button next to the PCMCIA, big enough to be able to reset the laptop with a regular pen.

For the full specifications, please refer to the official leaflet.

The setup I will be using: the Libretto, and a 3Com 16-bit PCMCIA Ethernet card

Choosing a Linux distribution

I wanted to find some modern, low-demanding software, not unsupported versions of Debian or RedHat. As you might have expected by this page's title, I chose Damn Small Linux (DSL).

I was very lucky to find that my machine had been upgraded to 24 MB of RAM. Apparently, even low-end distros have difficulties booting a regular kernel with 16 MB. I didn't want to tune or recompile the kernel on a 75-MHz machine, so I had to do some tricks.

In order to decide on a distro, I tried to set some goals up:

1. Discard modern distributions which require at least 256 MB of RAM. In fact, discard anything that doesn't work with 24 MB of RAM
2. Try to avoid old versions of current distros (i.e. Debian Woody) because the ISOs and the packages might not be mirrored anymore and are difficult to be found.
3. Use a distro which self-configures kernel modules on boot, because I will be installing from a Virtual Machine and the hardware will change between reboots. Recompiling the kernel is totally out of the picture.
4. Kernel 2.4 if possible, to make both the audio and the Ethernet work
5. As easy to configure as possible. I want to finish this in a few hours... [Narrator: he didn't]

I found myself with these contenders, Damn Small Linux, Puppy Linux and Tiny Core Linux.

DSL v4 was the chosen one for many reasons. First, the default software choice is a good compromise and finely tuned for low performing machines. The installation seemed the easiest of the three, and—very important—worked flawlessly inside VirtualBox. The documentation is very extensive and, as a slightly old distro, there are lots of manuals and forum posts with solutions to common problems.

There is also the fact that DSL is based on Knoppix, so it detected my hardware perfectly, didn't have to tweak the PCMCIA, and only had to configure the audio manually because the I/O ports were not the standard ones. This was a huge aid for me. PCMCIA Internet working out of the box is something I hadn't even imagined to have.

However, the decision also came with a few drawbacks. DSL has its own "package manager", which only works from X and can't uninstall packages.

apt-get can be enabled, but it might break packages already installed with MyDSL. Furthermore, those packages tend to disappear on a reboot for some reason. I'm still unsure on whether to use apt-get with MyDSL. We will not be using it.

The ACPI doesn't work, but I don't know whether it's the kernel or the Libretto's fault.

My biggest fear, however, is that most of the packages are old and might have security issues. However, as this will not be my main machine, and it won't run a browser with JavaScript enabled, I'm not very worried.

Why didn't I choose Tiny Core? because it didn't boot on a VirtualBox machine with 24 MB of RAM. It would have been my first choice, because it is better maintained than DSL. A real pity.

And what about Puppy? The LiveCD is great but the installation instructions were too complicated for me. I really didn't want to spend that much time configuring everything. It is maybe too modern (based on Slackware 13.37 with Kernel 3.1.10) and I doubt the Libretto could have handled its kernel.

Installation

Please note: I will assume that you have some experience with Linux, partitioning, and installing stuff from a console.

Strategy

There are two alternatives: use floppy disks or physically remove the drive and set up a VM. Years ago, I went the first path, because I had the floppy disk drive. Since I don't have it anymore, I found an awesome tutorial which suggested to physically remove the drive from the Libretto, attach it to a 2.5" IDE to USB adaptor, and install the system from another computer. Check out his pictures for details on how to remove the drive. My machine is in a bad condition (broken hinges, cracks all over the case, stuck screws) and I had to break some plastics and metal parts to access the drive.

So, we will use another Linux computer, which you probably already have, and set up a virtual machine inside VirtualBox. Then, we will remove the Libretto's physical HDD and attach it via USB to your computer, using an adapter. The DSL CD image and the new /dev/sd will be mapped inside the VM.

This way we can boot and install from a CD, instead of doing netinsts with the Debian Woody diskettes, as you will read on many other websites. It is the fastest and painless way, and if you don't have the floppy drive, it is the only way.

If you have the floppy drive and are wondering if it is worth to buy the adapter, go ahead! Walk the difficult path, install DOS, start a Linux setup from DOS, try to make the floppy disk work, then install from diskettes with a crappy kernel, fight with the PCMCIA driver until you are able to use the network, and install from the net. And, should the installation fail, start OVER AGAIN! When this happens, please send me an email so that I can pretend that I sympathize with you but actually laugh at your misery.

Talking seriously, I am just trying to warn you. I tried that, I failed, then I succeeded, and not even in my success I want even the worst of my enemies going that path. Buy it, then come back and follow these instructions.

Removing the hard drive

You already have the adapter? Great! I bought this one which worked great and allowed me to manipulate the drive from my main computer.

This is the adapter in its box. It comes with an enclosure that I didn't use to avoid overheating, and a handy screwdriver.

A close up of the IDE adapter. Don't buy a SATA one by mistake!

Using the drive in VirtualBox

As stated before, we will use VirtualBox to make DSL think it is running on a real machine, and that the—now USB— hard drive is the main drive of the VM. Turns out that using a physical disk from /dev on VirtualBox isn't easy to find, but the actual command is simmple.

Please make sure that your Linux has detected the USB drive as /dev/sdb before proceeding or you might lose data on the wrong disk! If in case, use Disk Utility or check dmesg.

VBoxManage internalcommands createrawvmdk -filename disk.vmdk -rawdisk /dev/sdb
                                                                       ^^^^^^^^  <-- check this

The command above will create a file named disk.vmdk, which is a short plaintext file which references to /dev/sdb. You can now add it to your VM using the normal VirtualBox Appliance Manager

Partitioning

Use your main Linux box to partition the hard drive. Disk Utility works well, but I used cfdisk.

The tutorial then notes that the last 32MB of the disk space are used for the Libretto's hardware Hibernate feature. I followed his partition table suggestions completely. Just in case his page is down, do this:

• /dev/hda1 738.0 MB, ext2 (ext3 is slower, but more secure), mounted as /
• /dev/hda2 40.3 MB, swap
• A remaining free space of 37.2 MB. Don't worry if the figure is slightly higher or lower due to rounding.

Installing DSL

Now go ahead, and download the ISO image. I used the Release Candidate 4.11.rc1 and it didn't give me any problems

Set up a new VM with 24 MB of RAM, use the ISO as the CD drive, and the disk.vmdk as the hard drive. Then boot.

If everything goes well, you will be shown the desktop. Now, in order to install, I have adapted the official instructions

sudo -s
swapoff -a
mkswap /dev/hda2 ## Considering that you followed the partition scheme in the tutorial
swapon /dev/hda2
dsl-hdinstall

Follow the setup assistant from there. I chose Grub instead of LILO for the bootloader, and it worked. The network also works out of the box, so I didn't need to apply any modifications in /etc/default/pcmcia as stated in David's tutorial.

Now disconnect the USB adapter, remove the disk, put it back in the Libretto, and boot. You should be prompted with either the console login or a X desktop, depending on your setup.

Network

I have a PCMCIA 16-bit 5V 3Com Ethernet adapter and just recently acquired a wireless Orinoco Gold card, 16b 5V too, one of the few known to work with this Libretto model, albeit only in WEP-mode.

This Libretto only accepts Type II PCMCIA, so it is very difficult to find a Linux 2.4 compatible, WPA-capable wifi card. Please let me know if you managed to get WPA wifi working!

Here are some pictures, as a reference.

The 3Com card, front

The 3Com card, back. Note the "PC card" icon with the technical specs.

The Knoppix core of DSL detected my Ethernet card, configured it with DHCP, and it talked instantly to my home router. Woohoo, it's on the Internet! I actually didn't need to do anything, compared to the hell I suffered with the Debian setup some years ago.

Wireless

Again, thanks to the Knoppix core, the Libretto automatically detected the PCMCIA card, loaded the orinoco kernel module, and the card was ready to use.

First, prepare your wireless router to work with WEP. It is highly discouraged to do so, because it is a big security hole. Fortunately I had a spare router that I can use only for the Libretto and will turn it off after playing with it.

My recommended setup for the router is:

• Hide the ESSID
• Filter by MAC address
• Use 802.11b with auto channel
• Use a 128-bit ASCII WEP key

I tuned /opt/eth0.sh to run the iwconfig commands. Add this just below the #!/bin/bash line:

iwconfig eth0 essid ESSID_NAME
iwconfig eth0 key open s:WEPKEY
iwconfig eth0 mode managed
sleep 1

If you WEP key is hex and not ASCII, omit the s: part before it.

Wait for a few seconds, and when iwconfig reports a correct Access Point, you're on the internet. Congratulations!

Since the 50CT has very low specs, Firefox starts swapping like crazy. The best commandline browser is links2 and I recommend dillo if you run X.

Look ma, no cables!

Sound

This other tutorial points out some tricks to use all of the Libretto's capabilities. I didn't try most of them, but since I couldn't play any music, I went ahead and probed the opl3sa2 driver. At first, it didn't work, because the I/O parameters on my card weren't the same than on that page.

This is my main BIOS configuration

A detail of the audio section. From top to bottom, the values correspond to the following module parameters

• mss_io
• not used
• not used
• irq
• dma
• dma2
• io
• mpu_io

This means that we will load the module with the following parameters. Remember to check your BIOS and use the correct ones, or modprobe will fail

modprobe opl3sa2 io=0x370 mss_io=0x530 mpu_io=0x330 irq=7 dma=1 dma2=0

Note: to access the Libretto BIOS, reboot or reset it, and press <ESC> during or just after the memory check

Finally, the Pentium 75 CPU is able to play most mp3 files, but you will need to compile your own mpg123. DSL comes with mpg321, but the audio isn't fluid and for some reason only mpg123 is able to decode mp3 in realtime. Running it from a console instead of an X session also helps, though the main bottleneck is the CPU, not the RAM

ACPI/APM/Battery

I only managed to get APM working. Playing with the Grub boot options there is no way to enable ACPI.

This blog post has some pointers on how to install the Toshiba experimental ACPI driver, but as I didn't want to recompile the kernel, I couldn't use it. If you feel strong enough, use the same Virtual Machine that you used for the DSL install and recompile it there, with the power of a current computer.

The toshiba kernel module loads correctly (/proc/toshiba), but not toshiba_acpi (/dev/toshiba). Not a big deal for me, but if you managed to get it working without recompiling the Knoppix kernel, please let me know.

The Libretto does some power management by hardware (screen blanking, hibernation), and this is enough for me. However, to get the system to actually power off after a shutdown, edit the /boot/grub/menu.lst and change the parameter noapm to apm=on apm=power-off

torsmo, DSL's dashboard, usually manages to get my battery status, but I didn't investigate further.

Performance tricks

Here are some generic tips on how to save some RAM and CPU cycles

• Enable DMA - For some reason, DSL disables DMA by default. To enable it, edit the Grub config file /boot/grub/menu.lst and change the boot parameter nodma for dma. You will then see a boot message saying that DMA has been enabled for /dev/hda
• Disable ttys - Edit /etc/inittab and disable all consoles but one. Instead, run a GNU screen session to get terminal multiplexing.
• No X - Disable the automatic X session that is launched on login. You might need to edit the .bashrc or the .bash_profile files. Comment out the startx command.
• GNU tools - With those bytes we saved, use the DSL menu option "Upgrade to GNU tools" to replace the very basic BusyBox shell with the regular GNU tools.
• Fix the date - Use MyDSL to install ntpdate and run it when coming back from hibernation, since the date will probably be incorrect: ntpdate ntp.apple.com

Currently my setup takes the following resources:

• Used memory with X running: 10 MB
• Used memory without X running: 3 MB
• Used disk space: 290 MB

Not bad, right? 3 MB of RAM on boot and a full functioning X taking only 7 MB more. That leaves a whooping 14 MB for applications!

As the pointing device is not that great, I usually run a single tty with a screen session for terminal multiplexing, and do most of my work on the terminal. X is only needed for viewing PDFs or images, and that's a perfectly suitable task for that computer.

Final words

I find it amazing that a laptop from early 2001 can still hold about an hour of battery, its drive is still spinning, and that it overall works. DSL gave it a new life, and though it is tedious to use a cable or WEP to connect to the internet, it is a functioning UNIX system, with audio and a decent mobile typewriter. Yes, the keyboard is small and uncomfortable, but this thing fits in any bag. Why, by 1990s standards, it would "fit in your pocket"!

There is plenty of information out there on installing Linux on a Libretto, but at the time of writing this article, most of articles are about 7-10 years old. I hope that it can be useful for somebody who, like me, found this machine at the bottom of a drawer and might want to play with it a little, install a current Linux and maybe give it to your kids or use it as a second laptop.

I wouldn't use it as a server, since it has little memory to run a server daemon, the disk and fan are noisy, and keeping it on 24/7 would burn the machine. If you want a cheap server, go for an old Mac Mini and install the latest Debian there. The Libretto is a ultra portable laptop and, if yours still holds some battery charge, is a nice toy to write stuff on or browse the simple internet.

DSL is highly customizable, and there is plenty of documentation out there. The default software is great, and searching the net you will find current software which is suitable for low memory devices. You will find yourself with a machine capable of reading and writing emails, displaying images, playing music, and more.

The only sites it can't browse are those which use Flash or are heavy on JavaScript. Well, the modern web, Gmail, Facebook, Twitter... but if you try to use the mobile versions you might get a nice surprise. You can try to use the Firefox version bundled in DSL but I wouldn't recommend that, it's too slow.

Feel free to contact me if there is any mistake on the tutorial or if you have some contribution, for example, a command to make it run with WPA, or if you managed to make the ACPI work.

The Libretto running an X session

Originally published on Github in 2013

Tags: retro, hardware, unix

Comments? Tweet  

Sourcehut, the free software development cloud

I've been following sourcehut for some time and realized that I hadn't talked about it yet.

Sourcehut, at a first glance, is a service that provides git repos and code/project management tools, but it's much more.

It runs CI through virtualised builds on various Linuxes and BSD, provides code review tools, tasks and third party integrations, and of course, mailing lists and wikis.

I think the landing page does a good job of explaining how it is different from other code hosting services. Especially:

• Composable Unix-style mini-services
• Powerful APIs and webhooks
• Secure, reliable, and safe
• Absolutely no tracking or advertising
• All features work without JavaScript
• 100% free and open source software

These bullet points are quite important: sourcehut is the web equivalent of piping UNIX commands for development and is built entirely on free software. The fact that it works without js is just a great bonus.

Sourcehut is the project of a single developer, Drew DeVault, better known as sir_cmpwn on the internet, and he's quite active on Mastodon in case you want to follow him. Amazing work!

Tags: software, unix

Comments? Tweet  

What are the differences between OpenBSD and Linux?

Maybe you have been reading recently about the release of OpenBSD 6.5 and wonder, "What are the differences between Linux and OpenBSD?"

I've also been there at some point in the past and these are my conclusions.

They also apply, to some extent, to other BSDs. However, an important disclaimer applies to this article.

This list is aimed at people who are used to Linux and are curious about OpenBSD. It is written to highlight the most important changes from their perspective, not the absolute most important changes from a technical standpoint.

Please bear with me.

A terminal is a terminal is a terminal

The first thing to realize is that, on the surface, the changes are minimal. Both are UNIX-like. You get a terminal, X windows, Firefox, Libreoffice...

Most free software can be recompiled, though some proprietary software isn't on OpenBSD. Don't expect any visual changes. Indeed, the difference between KDE and GNOME on Linux is bigger than the difference between KDE on Linux and KDE on OpenBSD.

Under the hood, there are some BIG differences with relatively little practical impact:

• BSD licensing vs GNU licensing
• "Whole OS" model where some base packages are treated as first-class citizens with the kernel, VS bare Kernel + everything is 3rd party
• Documentation is considered as important as code VS good luck with Stack Overflow and reading mailing lists
• Whenever a decision has to be made, security and correctness is prioritized VS general-purpose and popularity and efficiency

Do these make little sense to you? I know, it's difficult to fully understand. Your reference is "Windows VS Linux" which are so different on many aspects, like an elephant with a sparrow. To the untrained eye, distinguishing a pigeon with a turtledove may not be so evident.

They're philosophical distinctions which ramifications are not immediately visible. They can't be explained, you need to understand them by usage. That's why the typical recommendation is "just try OpenBSD and see"

Practical differences

So, what are some of the actual, tangible, practical differences?

Not many, really. Some are "features" and some are "undesired" side effects. With every decision there is a trade-off. Let's see some of them.

First of all, OpenBSD is a simpler system. It's very comfortable for sysadmins. All pieces are glued together following the UNIX philosophy, focusing on simplicity. Not sure what this means? Think rc VS systemd. This cannot be understated: many people are attracted to OpenBSD in the first place because it's much more minimal than Linux and even FreeBSD.

OpenBSD also has excellent man pages with practical examples. Use man. Really.

The base system prefers different default daemons/servers/defaults than Linux.

• apache/nginx: httpd
• postfix/sendmail: opensmtpd
• ntp: openntpd
• bash: ksh

Are these alternatives better or worse? Well, these cover 90% of the use cases, while being robust and simpler to admin. Think: "knowing what we now today about email, how would we write a modern email courier from scratch, without all the old cruft?"

Voilà, OpenSMTPd.

The same goes for the rest, and there are more projects on the way (openssl -> libressl)

Security and system administration

W^X, ipsec, ASLR, kernel relinking, RETGUARD, pledge, unveil, etc.

Do these sound familiar? Most were OpenBSD innovations which trickled down to the rest of the unices

"Does this mean that OpenBSD is more secure than Linux?"

I'd say it's different but equivalent, but OpenBSD's security approach is more robust over time.

System administration and package upgrading is a bit different, but equivalent too, at least on x86. If you use a different arch, you'll need to recompile OpenBSD stuff from time to time.

"But Carlos, you haven't yet told me a single feature which is relevant for my day to day use!"

That's because there is probably none. There are very few things OpenBSD does that Linux does not.

However, what they do, they do better. Is that important for you?

Why philosophical differences matter

Let's jump to some of the not-so-nice ramifications of OpenBSD's philosophy:

Most closed-source Linux software does not work: skype, slack, etc. If that's important for you, use the equivalent web apps, or try FreeBSD, which has a Linux compatibility layer

Some Linux-kernel-specific software does not work either. Namely, docker.

The same for drivers: OpenBSD has excellent drivers, but a smaller number of them. You need to choose your hardware carefully. Hint: choose a Thinkpad

This includes compatibility drivers: modern/3rd party filesystems, for example, are not so well supported.

Because of the focus on security and simplicity, and not on speed or optimizations, software runs a bit slower than on Linux. In my experience (and in some benchmarks) about 10%-20% slower.

Battery life on laptops is also affected. My x230 can run for 5 hours on Linux, 3:30 on OpenBSD. More modern laptops and bigger batteries are a practical solution for most of the people.

So what do I choose?

"Are you telling me that the positives are intangible and the negatives mean a slower system and less software overall?"

At the risk of being technically wrong, but with the goal of empathizing with the Linux user, I'll say yes.

But think about what attracted you to Linux in the first place. It was not a faster computer, more driver availability or more software than Windows. It was probably a sense of freedom, the promise of a more robust, more secure, more private system.

OpenBSD is just the next step on that ladder.

In reality: it means that the intangibles are intangible for you, at this point in time. For other people, these features are what draws them to OpenBSD. For me, the system architecture, philosophy, and administration is 10x better than Linux's.

Let me turn the question around: can you live with these drawbacks if it means you will get a more robust, easier to admin, simpler system?

Now you're thinking: "Maybe Linux is a good tradeoff between freedom, software availability, and newbie friendliness". And, for most people, that can be the case. Hey, I use Linux too. I'm just opening another door for you.

How to try OpenBSD

So what, did I pique your interest? Are you just going to close this browser tab without trying? Go ahead and spin up a VM or install OpenBSD on an old machine and see for yourself.

Life isn't black or white. Maybe OpenBSD can not be your daily OS, but it can be your "travel-laptop OS". Honestly, I know very few people that use OpenBSD as their only system.

That is my case, for example. My daily driver is OSX, not Linux, because I need to use MS Office and other software which is Windows or Mac only for work.

However, when I arrive home, I switch to OpenBSD on my x230 I enjoy using OpenBSD much more than OSX these days.

What are you waiting for? Download OpenBSD and learn what all the fuzz's about!

Tags: openbsd, unix

Comments? Tweet  

mosh, the disconnection-resistant ssh

The second post on this blog was devoted to screen and how to use it to make persistent SSH sessions.

Recently I've started using mosh, the mobile shell. It's targeted to mobile users, for example laptop users who might get short disconnections while working on a train, and it also provides a small keystroke buffer to get rid of network lag.

It really has little drawbacks and if you ever ssh to remote hosts and get annoyed because your vim sessions or tail -F windows get disconnected, give mosh a try. I strongly recommend it.

Tags: software, unix

Comments? Tweet  

The SDF Public Access UNIX System -- Est 1987!

I just recently discovered the SDF Public Access UNIX System, an organization that provides free, functional UNIX shells to users, plus webmail, LAMP and other servers to paid users. Check out their plans, they are very cheap.

If you grew up on the old (not ancient) internet where you read news at the newsgroups, chatted on IRC, played MUDs at college computers and nethack at home since you didn't have internet there, this is your place.

They have a modern service, and provide Minecraft servers too.

If you like their service, don't forget to donate! They accept Paypal and Bitcoin.

Tags: unix, retro

Comments? Tweet  

Unix tricks you should be using

Some time ago I started a compilation of unix tricks regarding bash completion, obscure tools and some ssh magic.

The list grew bit by bit until it was posted to Hacker News and quickly exploded. It got about 200k visits the first day and has been accessed and linked frequently since then.

I still maintain it, and I'd like to share it again, as the first post of this blog's new era. I have been tempted to re-write it as a longer blog post many times, but I believe that many people were attracted to the simplicity of the original text file.

Tags: unix, tricks

Comments? Tweet  

The advantages of using screen

There's a reason I posted a screen cheat sheet on my home page, and it's because I use screen so much that I actually needed one for myself.

screen is a tool which isn't suited for all audiences. Its home page states that it is a "window manager" which multiplexes terminals. That basically means it's a terminal manager, and all graphical environments have terminal managers, right? So why do we need another one which has complicated keybindings and doesn't let us use the mouse?

Well, each one might have their reasons, but for scientists there is one very clear advantage: working on the same shells from different terminals. What? Let's look at an example:

You usually have a computer from which you work every day. From that computer you ssh into different servers, clusters, etc. So, in the end, most of us have a monitor full of xterms—or any other terminal emulator. That's fine. But then we arrive home and want to check if that job we launched has crashed, because we need the results tomorrow morning. So what do we do? We ssh into our machine, or the server, open another session (that's the key here) and run some commands.

The problem is, you already had your sessions configured, maybe even set some environment variables, had the history full of commands and the terminal buffer with some output, and now you can't recover that. How about if you could restore the same sessions and windows we had at our work computer without the need to open a VNC or any other graphical screen-sharing tools? That's what screen does.

To put it plainly, screen is a daemon that handles terminal connections, which means that you can always request the same session that you had open before. Obviously it can't manage sessions unless you open them via screen, so it's a good idea to always run your terminals through it, just in case you might need to access them afterwards.

Besides ubiquitous access to your sessions, screen also provides other interesting features that make it useful even if you don't need terminal multiplexing. The first is notifications for terminals which are in background, for example, a visual message appears in your screen if there is a new output in a hidden window. This is very appropriate to avoid constantly checking minimized windows.

It also provides window managing, i.e. many terminals in a single window, and quick switching. Finally, even on today's GUI world, sometimes you need to copy&paste without a mouse, backwards buffer management, perform text "screenshots", etc.

I'll end up with a quick tutorial by an example that actually happened yesterday.

• carlesfe@work:~$ screen
• [screen opens, and gives me a shell]
• carlesfe@work:~$ ssh server.com
• carlesfe@server:~$ work on some commands... run scripts...
• carlesfe@server:~$ launch_a_job.sh
• [output is being generated]

Then I left work and went home. Notice that the output is still being generated, but only in the window that I had opened at work. Usually there are some other ways to check if the job is still running, but what if it crashes? At home I wouldn't normally be able to recover the error message that was printed on the screen. But with screen session management, I can do this:

• carlesfe@home:~$ ssh work
• carlesfe@work:~$ screen -x

And voilà! I can see the exact same window with the same session I had at work. Now I can monitor what's happening, relaunch the command easily if it crashed, and see any error messages that were output on the screen.

I started by saying that screen isn't a very user-friendly tool, but if you feel comfortable with many of the Unix tools out there, you'll get used to it very quickly. Check out this tutorial for a beginner's introduction and give it a try for some days. Once you get used to the basic C-a keystrokes and terminal management, you'll wonder why didn't you discover it years ago.

Tags: unix

Comments? Tweet