Coming very soon: vi(1) Tips: Essential vi & vim Skills, 1st ed.

Author: Jacek Artymiak

Price: coming soon

There is no way to predict how long it will take to run a particular command under UNIX. But you can measure the time it takes to run it with time(1) and use the result as a yardstick.

The article is attached below. You can download it in PDF.

Most of the time, the scheduler will do a pretty decent job of making sure that each process gets a decent share of the CPU time. This technology has been in development for a few decades and is pretty stable, as it should be. Not that improvements aren’t possible, but they should be done in the code itself, not by way of human intervention. Alas, there are times when we really need to intervene, either to make some processes have more CPU time then others, or to slow other processes down so that the system does not slow down too much. There are two commands that can help you lower or raise the priority of the process whose CPU time share is out of line: nice(1) and renice(8).

The article is attached below. You can download it in PDF.

The OpenBSD project publishes all of it's source code on the Web.

• The OpenBSD CVS Repository (external link)

uptime(1) is handy to get a quick snapshot of some basic system information and often that’s all you need to decide what to do next, but if you want to get a better view of the load average patterns on your system, you will need to run uptime(1) at regular intervals over a period of a day, or week. Here’s a script that runs uptime(1) at 15-minute intervals for 24 hours. We'll call it uptime-mon.sh.

loopon=1;

loopdelay=900;

loopend=96;

n=0;

while [[ $loopon -eq 1 ]]; do

        if [[ $n -eq $loopend ]]; then

                exit

        fi

        sleep $loopdelay

        uptime

        n=$n+1

done

If you wonder where I got those numbers from, you should know that the ksh(1) sleep command expects that we express the delay in seconds therefore 15 minues translates into 15*60 = 900. And since each hour is made of four 15-minute segments, we have to run uptime(1) 4*24 = 96 times.

Remember that the script shown above will stop as soon as you close the terminal window or log out of the system, so make sure it runs in the background and does not stop after you log out of the system:

$ nohup uptime-mon.sh > 24-hr-uptime &

When you log in the next day, you will be able to monitor the results as the are being written with this command:

$ cat 24-hr-uptime | less

If you have better things to do than babysit uptime(1), you can make your script deliver the results straight to your mailbox when it's done:

$ nohup uptime-mon.sh | mail joe &

The above is a fragment of a longer article to be published next Monday. Subscribe to our Articles list to get the whole thing.

A refresher on w(1) and who(1). The URL goes out on Monday, Aug 4, 2008. Join the Articles mailing list to get the URL delivered to your mailbox. (The sign-up form is in the column on the left.)

There are two useful commands that can tell you who’s doing what on your system: who(1) and w(1). While both give you a list of users logged on the system there are some differences that you might know about.

The article is attached below. You can download it in two formats, PDF and Amazon.com Kindle (html).

As you have no doubt noticed, the quality of our videos on YouTube leaves a lot to be desired. Here's a blip.tv version. Much better, imho.

devGuide.net Training News Mailing List

We're going to put a lot of our training materials on YouTube and other video sharing sites. This is a test of our OpenBSD YouTube channel.

devGuide.net Training News Mailing List