Load Average: those funny little numbers

I was going to write a little article on interpreting the load average in UNIX and Linux machines, but I ran across this blog post and don’t think I could have said it better. Really, check it out.

When I’m logged into a graphical session on my FreeBSD system I use conky to monitor hardware utilization and performance (and the local weather and unread messages in my GMail inbox, etc.) But normally I work from the command line with ssh and tmux, so I have created an alias that I load in my login profile to let me get at the load average in a quick-and-easy fashion:

alias loadavg='sysctl vm.loadavg | cut -d" " -f3,4,5'

Now I just run loadavg any time I want to see how my cpu cores are doing.

Be seeing you.

​

More on Editing Multiple Documents in vim

Using vim Windows

We’ve talked about using buffers to edit multiple documents in vim. Each file lives in a buffer which, in turn, lives in it’s own tab page, rather like a tab in a web browser. But sometimes I want to view one file while editing another, and it would be handy to have both files in the same screen at once. To support that, vim gives us windows.

To split the screen into multiple windows in vim, switch to command mode and run :split or control-w followed by s. This will split the screen into two windows, each containing a copy of the file that was in the original screen. Running :split again will create a third pane, and so on.

If you want to open the new pane with a different file, run :split myfile. This will open a new window with the other file loaded inside. To open a window with a new, blank file, run :new or control-w n.

The active window can be resized with with the command :resize # or z#, where the # sign is the number of lines high that the window should be.

To move up and down among the visible windows use control-w k and control-w j respectively. To close the selected window, run :close or press control-w c.

There are actually many commands to manipulate buffers and windows in vim. These are the basics and will get you through most common tasks. To learn more, go to vim’s command mode and run :help window.

Be seeing you.

​

I'm an Alias, I'm a Legal Alias

Useful Command Aliases

When working from the command line I like to cut down on the amount of typing that I do because a) I get in a hurry, and b) I fat-finger the things I’m trying to type, so c) I end up doing things over to get them right. I use aliases to take some common tasks and shorten them up so that I can save time and face.

If you look at my *nix systems you’ll find several aliases for various incarnations of ls:

alias l='ls -F'
alias la='ls -a'
alias ll='ls -lh'

The first of these, -F, appends a character to the end of the file name to identify the file type: * for executable files; @ for symbolic links; and / for directories. Regular files don’t have any special character following their names. While most Linuxes and BSDs use a colorized ls command these days, this is useful if you need to work from a terminal or remote session that doesn’t support color.

The second alias lists all files, including hidden ones, and the third displays a detailed listing with file sizes in “human readable” format: gigabytes or megabytes instead of bytes.

Aliases can be more sophisticated, standing for piped output. When I use the df command to check free disk space, usually I just want to see mounted logical volumes and not pseudo-filesystems and LVM disks. I pipe the output of df to grep to get what I want:

alias dfh='df -h | grep -v "^[[:alpha:]]"'

And to see a sorted list of details about my own processes:

alias myps='ps aux | grep ^$(whoami) | sort -k 2b'

An alias can also contain several commands—a mini-script, if you will:

alias sched='echo ""; cal; echo ""; calendar -w 3; echo ""'

Perhaps I have inspired you to experiment with aliases and discover some of the cool things you can do with them.

Be seeing you.

​

Editing Multiple Documents in vim

Using vim Buffers

When editing a file in vim it is stored and displayed in a buffer, something like a tab in a web browser window. You can open multiple files at once and easily move back and forth among the buffers to work with each file.

Opening Multiple Files in vim

To open multiple files in vim when you start your session, simply list them on the command line:

$> vim myfile1 myfile2 myfile3 myfile4

This will start vim with four buffers pre-loaded with your four files. You can use wildcards:

$> vim documents/myfile*

If you already have vim running and want to open another file, go to command mode and type:

:e documents/myfile5

You’ll be happy to know that you can use tab completion with the :e command. If you want to create a new file within vim, from command mode run :enew which will open an empty buffer. Just remember to save the file with a name anytime before you exit:

:sav documents/myfile6

Navigating Among Files

To see the buffers open in your current session, from command mode run :buffers. Note that each buffer lists the file that it contains, and each has a unique number. To move to a different buffer, run :b# where the # sign represents the number you want to move to. For example, to begin editing the file in buffer number 3, run:

:b3

Keep in mind that before you can switch to a new buffer you must save or discard all the changes made to the current one. Use the :w command to save your file before changing buffers.

You can cut, copy and paste among buffers just as you would within a single file. Just remember that if you make a cut you will need to save the changes in the current file before switching to the target buffer.

When you no longer want to work on a file you can close its buffer with the “buffer delete” command, :bd. This command closes the file in the current buffer and deletes the buffer; the file is not removed. By adding a number you can delete a specific buffer. For example:

:bd3

This will close the file in buffer 3 and delete the buffer. And quitting vim will close all files and delete all buffers.

Be seeing you.

​

xargs: Praise the Lord and Pass the Argument!

One interesting command in UNIX is the little xargs command. It takes something from standard input and passes it as an argument to another command. For example, if a command expects a user name, you can get that name from somewhere and feed it to the command through xargs:

whoami | xargs passwd

The silly example above is also superfluous—passwd can accept a user name through standard input directly, so xargs isn’t needed here. And of course, passwd with no arguments would change the current user’s password anyway. But it is a simple way to illustrate what xargs does. Some commands don’t look for a required argument in the standard input stream, so they won’t read directly from the pipe. xargs takes whatever is in the pipe and sends it as an argument to the command that follows; in this case, passwd.

I personally use xargs in my .xinitrc file to set a random background wallpaper on my desktop when I start X:

find ~/pictures/wallpapers -type f | sort -R | tail -1 | xargs feh --bg-fill

The find command locates all the files in my wallpapers directory. The sort command puts the file names in random order and the tail command grabs only the last one in the list. xargs then passes that to feh, an image display utility, which sets the randomly selected file as my wallpaper. And so X greets me with a surprise every time I go GUI.

Be seeing you.

​

Those Were (Not) the Days...

In my Linux and UNIX classes I introduce the students to a nifty little CLI tool called cal. Run from the command line, it displays a calendar of the current month with today highlighted. If you have a *nix terminal handy, fire it up and let’s take this little baby for a test drive.

Run cal and you get the calendar for the current month. To see the calendar for the entire year, run cal 2015.

You can also ask cal for a specific month and year. To find the date for Thanksgiving in the year 2020, run cal 11 2020. Pass cal the month and year of your birth and you’ll see what day of the week was graced by that momentous occasion.

But do you want to see something cool? Run cal 9 1752. You might notice something wrong here—September of 1752 is missing eleven days! Is cal broken? Hardly. In September of 1752 the British Empire (finally) adopted the Gregorian calendar to correct an error that was, by that time, eleven days long. What’s cool is that a little UNIX program already knew all that, so you don’t have to worry about accidentally scheduling a Tardis trip for London, September 8, 1752. That is, assuming the Tardis runs a version of UNIX…

So, there’s some trivia for the local pub. Perhaps you can use it to win a few drinks. And watch out for blue police call boxes.

Be seeing you.

​

love my chromebook, but...

it was 2002 when i installed thinkfree office as a cross-platform alternative to a popular proprietary office suite. that is when i began moving my life to the cloud. i realized that having to manage data on several computers running different operating systems was silly. i needed access to much of the same stuff on my mac, sparcstation, linux and windows pcs, and i didn't want to have to maintain multiple copies. the cloud made sense to me, though it wasn't then quite the buzzword that it has since become.

back then i predicted that we would one day run most of our software over the internet on a subscription basis. while we haven't arrived there yet, we're certainly going that way. i can now edit documents, touch up photos, record music and video, take notes, send email and text messages, make phone calls, listen to music, read books, watch movies and television shows, and write code all online. since that pretty well sums up most everything i do on a computer today i decided to take the plunge and pick up a chromebook, the samsung series 5 with 3g (in a lovely arctic white.) i have to say, i'm loving it, and i will keep you posted here about my adventures in google's vision of the cloud.

before i wrap up this post, i'll share my impressions after my first week with chromebook. i have to say, there are so many things i love about this device that i can't list them all. speed and convenience are at the top, though. but i have two needs that the chromebook doesn't address. one, i must have a local rdp client. i need to communicate with my company's terminal server from the public internet, but i also need to talk to virtualbox machines that are running on private networks. web-based rdp-to-html5 services can't access my private ip addresses, so a local client is a must. word is, google is working on this, so i'll wait. the second is java. now, if the chromebook had a jre then my first concern might disappear—i've found a very fine java rdp client. but there are many web sites that use java, not the least of which are those that host games like minecraft and runescape. after all, all work and no play...

assembler tutorial: intro 1 of 2

assembled 'neath a dark, foreboding sky

as promised, a little dos and linux assembly language tutorial in several verses for your consideration. mostly dos though, for that is where my dark past lies, but a little linux is good for the soul (and the understanding.) before we begin in earnest, two things:

---

first, assemble (huh) your 'a' team, the tools you will need to code along with me. since i work on mac, linux and vista platforms i find great comfort in the familiarity of a singular environment across all machines that i (might) happen to be writing code on at the moment. for this, i use dosbox, a great little dos + x86 emulator. it may have been primarily designed for running classic games like wolfenstein or ega trek, but it makes for a pretty decent development platform, too.

to write your code you'll need a text editor. alas, a good dos text editor for writing assembler is only a pipe dream (this used to not be the case, but i can't find my old tools anymore.) editv, however, does provide must-have line numbering and is one of the easiest editors to use. i still prefer vim, but the dos version of it is really lame and i don't intend to teach vi editing in this blog.

we'll be writing code specifically to be assembled by nasm, the netwide assembler. there is no such thing as "standard assembler syntax," so every assembler has its own idiosyncrasies. one of the reasons i'm writing these tutorials is to teach myself nasm: i actually learned on tasm and worked on masm in the bronze age of computing. the concepts are the same and linguistic differences are often minor, so it's nothing to break a sweat over.

some of the programs we write will require a linker. i'm using the public domain warplink for this. and finally, since most of these utilities are packaged as .zip files, we'll snag the darling of dos bbses the world over, pkzip (the second-finest piece of dos shareware ever written.)

install dosbox and create a folder in your home directory to keep your work in. i called mine dos. edit the dosbox configuration file by adding a few lines after the [autoexec] section at the very end. mine automatically mounts my dos directory as drive c and adds several directories to my path variable, like this:

[autoexec]
# Lines in this section will be run at startup.
@echo off
mount c ~/dos
c:
set PATH=%PATH%;C:\NASM;C:\WARPLINK;C:\EDITV;C:\PKZIP;C:\BIN

once you've done this you can start dosbox (which should drop you into your c drive) and use the dos command md to create the directories nasm, warplink, editv, pkzip, bin, and mycode. run the command dir and ensure that eight directories exist (this number includes the . and the .. directories.)

copy pk250dos.exe to the dos/PKZIP directory and run the executable inside dosbox. you will find that when you modify the dos filesystem from your host operating system outside dosbox, those changes don't appear when you list the directory inside dosbox. dos likes to cache the directory lists to speed things along, so if it is unaware of changes you made from outside the environment it pretends that they aren't there (they really are.) to force the changes to appear you can clear the directory cache with the rescan command.

copy the rest of the programs listed above to their respective directories and, in dos, run rescan and unzip each of them like this example:

C:\EDITV>pkunzip editv41u.zip

when all this is done, close and reopen dosbox (you can type 'exit' at the dos prompt to close) and verify that you can run all these programs from the root directory of drive c by just typing their names: editv, nasm, and warplink. if you run into any dosbox trouble, refer to this little article. if everything works as expected, your path is set up correctly, your team is assembled (huh) and you're… almost… ready to begin…

um, you rub it and make a wish...

today i needed a lamp. that's an acronym that refers to a special kind of server, one that contains a server operating system, a database server, a web server, and a web development framework. most of the web servers you interact with on the internet today use a suite, or "stack" of tools like this. and i needed one.

now, i can build a lamp server from scratch: configure a base os; install a web service and database; install the web modules to access the database; install the web application framework; install the web modules to interface with the framework; and configure all the pieces to play well together. frankly, i can think of better things to do with my time, so i headed over to turnkeylinux.org and downloaded their prebuilt lamp installer. boy, was i impressed! the installation was fast, painless, and almost hands-free. in less than twenty minutes i had a working server, ready to hand out interactive web pages.

the webmin administrative interface is really slick: a far cry from where it was when i last used it at the turn of the century (i like saying that.) it took me a couple of minutes of poking around to figure out how to add packages through webmin, which appears to be a necessity since the system didn't seem to recognize the things i installed "manually" using apt-get.

this product really exceeded my expectations. i could install and configure lamp servers all day like this. and considering that this is open source software that's easy on hardware resources, it would be a great virtual server solution and provide an impressive roi. maybe not as cool as rubbing it and having a genie pop out, but almost.