The first thing you need to know before using sudo is that you should use the visudo command to edit the sudo config file. This script does a number of useful things, like creating a lock to prevent mulitple editing, and doing some sanity check. But if you have the problem that setting $EDITOR and $VISUAL is ignored when running something with sudo (like sudo visudo or sudo crontab -e), that's a sudo config issue. Add the following in your /etc/sudoers file:

Defaults env_keep += "EDITOR VISUAL"

And you can use sudo from within your normal Emacs window by using the Emacs' Tramp Mode, which allows all kinds of editing, even remote editing. Just use the sudo "protocol" when editing a system file, like /etc/fstab:

Find file: /sudo::/etc/fstab

This will prompt you for your password (not the root password - remember, we're doing this via sudo, which wants your password, not root's). Type it in and you can edit the file in place, rather than running a special Emacs process as root. Very nice!

Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.

My latest Emacs discovery was on an Arch Linux forum thread on note taking software. I use Remember The Milk for plenty of lists, but the web based nature of it makes it hard to be quick about doing a quick note. I started keeping a simple text file with notes on what I was doing, as I was finding whole hours at the keyboard disappearing into a black hole. I whipped up a quick Emacs macro that I bound to F7, which opened a file to prepend a new quick entry:

(setq logfile-name "/home/jdarnold/Dropbox/dailylog.txt")
(defun insert-new-log ()
  "Start a new log entry"
  (interactive)
  (find-file logfile-name)
  (beginning-of-buffer)
  (insert "==== ")
  (insert-now)
  (insert "\n\n")
  (previous-line)
  )

As you can see, I put the file in my Dropbox folder (use this link to sign up and we both get an extra 250gb of storage space), so no matter which computer I'm working on, I can jot a quick note that looks something like this:

==== Monday, January 25 2010 10:43 AM (1264434222)
after a couple of hours puttering around, including writing a review
for Goodreads, I'm back at work. Trying to figure out what I did to
break the video plugin
#insors

I have a few adhoc tags, stamp it with time date and Unix time, and tried to see what I was working. It's okay, but if I forgot to jot something down when I left the keyboard (which I often did), it lost a lot of its effectiveness.

Then I found out about org-mode in Emacs. It's been in the standard Emacs distribution for a couple of releases, but I'd never heard of it before. And wow, is it amazing! The PDF of the User Manual is nearly 200 pages! And it really does everything you could want in an organizer/todo manager/note taker. It even has a clock in/clock out/idle timeout paradigm, so it can notice when I've walked away from my computer. Unfortuantely, "real" idle only works on Mac OSX and Linux (after compiling x11dle.c). On Windows, it just notices when you are idle in Emacs, which, despite the fact I use Emacs alot on Windows, isn't quite the same thing.

So now I've changed my Emacs checkin macro to be:

(defun start-new-task ()
  "Start new journal task"
  (interactive)
  (find-file (concat dropbox-folder "org/" journalname))
  (end-of-buffer)
  (org-insert-heading)
  (org-clock-in)
  )

so it adds a new heading and starts the clock. And on my work machine, I set journalname to be a work journal and on my personal machine, I give it a different name. Still working out the kinks in the process, but it's closer to tracking what I've been doing.

I also intend on using org-mode to jot down my myriad project ideas. I'm always coming across interesting web sites, esp. for web APIs, that make me want to dabble in some projects, but I've never had anywhere to jot them down. I was using MindMeister.com, an online mind-mapping tool for it, but found it too structured. Given org-mode's flexibility, I should be able to find some easy way to just add my "brilliant" brainstorms to a file!

• Wicked Cheap Hosting - some great web hosting deals, courtesy of All About Linux
• TermBuilder - a simple web app to build a commandline command

I didn't really have as complete a checklist of features as I have had in the past. Of course, it had to install on my beast of a machine, with its myriad hard drives, cd drives, dual monitors, and the like. I wanted an easy to use package manager, with plenty of packages available. I was't quite as sold on a "one size fits all" admin panel like openSUSE's Yast2. I'm feeling a little more adventurous, and hate to see my configs get changed without my knowledge. I wanted a KDE distro, as I find GNOME to be bizarre. I didn't want to get too far off the beaten path, as I like a popular, well documented distro.

First up was Sabayon, which has been getting lots of good press. I wasn't crazy about their home page - it was too hard to find even the download link. And there were a few kinks in the install process. It was a few months ago, so I don't remember exactly the problems, but they were enough to sour me on it a bit. It did have exactly the same problem I was going to find in all the rest of my installs, which is that the setup hard drive numbering for GRUB was always different than the final installation drive numbering, requiring me to reboot using the live disc and edit the /boot/grub/menu.lst file and change the hd0 to hd1. Not sure why that is, but I guess the mix of IDE & SATA hard drives makes it crazy.

So after dabbling a bit with Sabayon, I moved over to try Sidux, which really intrigued me with its cutting edge release and huge package library. It also had an incredibly clean install process and the desktop is stunning. Really a very polished and good looking release. It has a very nice community with lots of good info on the web site. I was a little turned off by its insistence that you drop down into single user mode to install any updates, which isn't something I like doing.

But I played with Sidux for a couple of days. It was nice, but I decided to give Arch Linux a try. It had been written up very nicely in the previous issue of Linux Format, in the "Remix Your Own Linux" article. It's overriding philosophy of "Keep It Simple" was really attractive, as was the very large package library. I found it amusing that the Live CD boots into a commandline, the installer is the old fashioned text-mode graphics and, even after installing, you end up with commandline! It doesn't even install X for you.

I found this a refreshing change and decided to jump right in. I even decided against installing KDE and just run openbox with a stripped down config. It's really been working nicely for me and I haven't looked back. Arch makes a great server install, as there is very little cruft installed by default. When I built my media server machine, with its 1tb software RAID, I only added Emacs & Samba and I know it is a lean, mean, serving machine.

The Arch wiki is incredibly informative and comes up early in many Google searches. The forums are active with intelligent discussions and it is a very nice, experienced, community. While I wouldn't use it for my Grandma's Linux, Arch is a great distro once you get some Linux experience and want to tailor a distro to your ideas, and not the other way around. Arch is also why the calls for fewer distros is misguided. It isn't for everyone but as long as each distro has a certain focus, and hues to it closely like Arch does, there's plenty of room out there. Next up - theme color changes!

• 7 Best Linux Apps for Ripping CDs and DVDs | Maximum PC
• 50+ Ultimate Collections of Planet Wallpapers
• TermBuilder: a graphical Linux command line generator

Actually, it's a pretty easy fix. Instead of using /dev/sd? in places like grub's menu.lst file and the all important /etc/fstab, use a special label that doesn't change. I find using UUID's to be the best solution.

There are a couple of ways to get the UUID of a hard drive. The easiest is to use the blkid command from the commandline. It lists all the hard drives, along with their UUID and TYPE:

$ blkid
/dev/sdb1: LABEL="ReiserData" UUID="0e9c1455-4993-4ddf-a86a-a3dac116a5cc" TYPE="reiserfs" 
/dev/sda1: UUID="a846c306-3114-403d-b893-a3e27704755a" TYPE="ext3" SEC_TYPE="ext2" 
/dev/sda3: UUID="c03ce6c7-32ab-41e9-b603-da09acc0fbab" TYPE="ext4" 
/dev/sda4: UUID="303889b7-ae78-436f-85ac-da95b2280596" TYPE="ext3" 
/dev/sda5: LABEL="/home" UUID="d6db1ae8-30d6-48ee-8a66-90912480e8be" TYPE="ext3" SEC_TYPE="ext2" 
/dev/sda6: UUID="71712106-eef9-48c3-840f-20fb77173a9d" TYPE="swap" 
/dev/sdb2: LABEL="GAMEY2" UUID="4B89-0200" TYPE="vfat" 
/dev/sdc1: UUID="59ac55ab-93f8-4466-804d-57d1148b76e5" TYPE="ext3" 
/dev/sdc2: UUID="260834A7083477BF" LABEL="Media" TYPE="ntfs" 

You can also get the UUID of paritions by using ls :

$ ls -l /dev/disk/by-uuid/
total 0
lrwxrwxrwx 1 root root 10 Feb  1 00:00 0e9c1455-4993-4ddf-a86a-a3dac116a5cc -> ../../sdc1
lrwxrwxrwx 1 root root 10 Feb  1 00:00 260834A7083477BF -> ../../sdb2
lrwxrwxrwx 1 root root 10 Feb  1 00:00 303889b7-ae78-436f-85ac-da95b2280596 -> ../../sda4
lrwxrwxrwx 1 root root 10 Feb  1 00:00 4B89-0200 -> ../../sdc2
lrwxrwxrwx 1 root root 10 Feb  1 00:00 59ac55ab-93f8-4466-804d-57d1148b76e5 -> ../../sdb1
lrwxrwxrwx 1 root root 10 Feb  1 00:00 71712106-eef9-48c3-840f-20fb77173a9d -> ../../sda6
lrwxrwxrwx 1 root root 10 Feb  1 00:00 a846c306-3114-403d-b893-a3e27704755a -> ../../sda1
lrwxrwxrwx 1 root root 10 Feb  1 00:00 c03ce6c7-32ab-41e9-b603-da09acc0fbab -> ../../sda3
lrwxrwxrwx 1 root root 10 Feb  1 00:00 d6db1ae8-30d6-48ee-8a66-90912480e8be -> ../../sda5

You can see that FAT32 and NTFS partitions have different kinds of UUIDs, but it should work for our purposes. Now you just need to replace all references to the various /dev/sd? names with the correct UUID. This will remove all "randomness" from the boot order. Even if you currently have only one hard drive, you really should go to this "persistent" method of naming partitions, as you never know when you might add another.

In the /etc/fstab, replace /dev/sd? with UUID="uuid", like this:

#/dev/sda4
UUID="303889b7-ae78-436f-85ac-da95b2280596" / ext3 defaults 0 1

and in the /boot/grub/menu.lst file, replace it with the /dev/disk/by-uuid path, like this:

kernel /boot/vmlinuz26 root=/dev/disk/by-uuid/303889b7-ae78-436f-85ac-da95b2280596 ro vga=773

The Arch Linux Wiki has a very nice page on Persistent block device naming here: http://goo.gl/GTWT.

• Ultimate eye candy

  - a pretty interesting article on how to get the most dazzling display, whether you use Compiz, KDE, or GNOME. Despite my general disdain for eye candy, I would try the Compiz/Emerald 3d window manager if it worked on dual monitors, but last I looked it didn't support them.

• KDE distributions

  - coincidentally enough, just as I'm looking to move on up from my OpenSUSE 11.0 install, along comes LXF with their KDE distro Roundup. I wouldn't have to go too far afield if I stayed with their winner, which is OpenSUSE 11.2, but I'm trying out a couple of other ones they regard highly, like Sabayon and Sidux. I'm a KDE man, so it works out well.

• Get to grips with /proc and /sysfs

  - this is an excellent overview of the virtual filesystems /proc and /sysfs.

• DVD Coverdisc

  - the DVD coverdisc includes live previews of the latest versions of KDE and GNOME, which is pretty cool. It also includes Ubuntu Netbook Remix (which I think I'll try on my Dell Mini), Moblin 2.0 and Puppy Linux 4.3.

To enter my little contest, where I will mail you a pristine copy of LXF #126, along with the DVD coverdisc, just drop me an email at jdarnold@buddydog.org. On Monday, Dec. 7th, probably in the evening, I will randomly select one entry and email you back asking for your mailing address and soon it will show up on your doorstep. Open to both of my international readers too :)

Oh, and I also heartily endorse subscribing to the magazine. Yeah, it's pretty expensive, but if you do it via the TuxRadar web page, you can cut it down to US$99 for 13 issues. And, as a subscriber, you get access to all the back issues in PDF format and they really have gotten their act together with it. The PDFs look great and they have a nice HTML page linking it all together. You won't be disappointed.

So I get a 1.5 out of 4 for my holiday projects. I did get the girls' computer up and running. The new power supply took a bit of forcing to get it to fit into the old case, but then it was up and running just fine. I was bit stumped as to what to install for an OS on it. For obvious reasons, the old Windows XP installed on the hard drive failed to boot. Really, all they do is play flash games on it at this point, save for R10.4 playing some Day of Defeat with me and my clan buddies. So I moved her onto the Windows machine and had to pick a Linux for the new box. I went with OpenSUSE 11.2, as I'm most familiar with that and so it would require the least amount of thought. So far, so good.

I get a half a project because I did try to install a new Linux on my own box, but wasn't really happy with it. I installed the latest Sabayon (v5.0), after being pretty impressed with how well the Live CD ran. But I immediately ran into a problem after the installation - GRUB refused to boot it up.

Because I run my own boot manager (TerraByte's BootIt NG), I always install the GRUB boot loader onto the first block of the OS's boot partition. One test of an installer is just how hard this is to do, and I'm happy to report it wasn't too hard for the Sabayon installer - just select the Advanced Options and it was one of the choices. But on boot, I just saw "GRUB " and I knew immediately what the problem was. My machine is a homebrew one, with both old fashioned IDE drives and newfangled SATA drives and this isn't the first time an installer or LiveCD called the drives something different than what a full boot calls them.

Unfortunately, I had formatted the partition as an 'ext4' drive, so I couldn't get at it with my OpenSUSE 11.0 boot. And it may also have had something to do with why GRUB didn't work either. So I redid the install using 'ext3' and still had the problem. After rebooting the Sabayon Live CD, the usual GRUB steps to fix a broken GRUB install didn't quite work:

# grub
grub> find /boot/grub/stage1
 (hd0,0)
 (hd0,3)
grub> root (hd0)
grub> setup (hd0,3)
....
grub> quit

I do the ",3" part to (hd0,3) so that it installs in the root block of partition 3 and not the root block of that whole hard drive, to not overwrite my own boot manager. But I knew this was still wrong, because after a "normal" boot, the boot drive is hd1, not hd0. I think there is a way to tell grub this using another parameter to the setup command, but I had a better idea - I just booted into my OpenSUSE boot and changed all 'hd0's to be 'hd1'. After booting, things got a little further, until I realized that the setup command doesn't seem to fix the /boot/grub/menu.lst file, so I had the make the same s/hd0/hd1/g change there too.

Now I was able to boot into Sabayon. And because they aren't afraid to install binary drivers, I got the nVidia drivers and was quickly able to turn on my second display, which was nice. But the update process left me a little mystified. I couldn't really figure out how to get it to select packages and install the updates. And even when it was downloading, it was incredibly slow and, in the end, didn't seem to do anything.

So in this age of instant gratification, I sort of gave up. I think I'll try the Sidux distro next, although I should just stop wasting time and install OpenSUSE 11.2, as that is the one I like and use.

Fix Girls' Computer

Their computer finally gave up the ghost a few weeks ago and they've been using one of my work computers while I figured out what to do. I picked up an AMD motherboard for cheap (US$120) from AscendTech.us, that included an AMD 6000+ cpu and 1gb of RAM. What it did not include was any kind of manual, which kind of upset me. I think it is an ECS MCP61SM-AM motherboard, which isn't even listed on the ECS web site. But I did figure it out enough to get it put into the case, only to find out the power supply only has a 20 pin plug, and the new ones require a 24 pin plug. So I ordered a new power supply and now it awaits final assembly. Not sure what OS I'l put on it. Maybe I'll go back to Qimo For Kids again.

Install New Linux

My current openSUSE installation is pretty old at this point. I did upgrade from 10.3 to 11.0 about a year ago, but since then I've managed to break it. An update was going too slow and eventually had to be abandoned, leaving it in a state where even the updater won't run. But it was time to start fresh anyway. Good timing, as Linux Format #126 reviewed the "best" KDE4 distros. Not surprisingly to me, their #1 pick was OpenSUSE 11.2. But I also thought the Sidux and Sabayon distros sounded interesting, so I wanted to spend some time with those before picking one.

Continue Linux From Scratch

I also need to get back on the Linux From Scratch project. I have the toolchain all built and backed up, and am ready to begin Chapter Six and actually build the real copy. I have gotten a little sidetracked in the whole package manager discussion, but I think I'll just ignore it for now and try an install. If I want to go further, then I'll think more on a package manager. But I have really been enjoying the heck out of getting into the real guts of a Linux install.

Work On Android

One new toy I haven't talked about is my G1 (Google) phone from T-Mobile. I have actually had it about 8 months now. I really like it and one reason I bought it was for its open source development model. I have a couple of interesting little projects for it ready to go, but just haven't found the time to pursue. I'm not a huge fan of Java programming, but I think I know enough to get something running.

So who knows how many, if any of the above projects I'll get to. Well, I have to do the first one so I can get my test computer back, and it promises to be a cold rainy day here in the US Northeast, so I think I can definitely get that done. As for the rest....?

$ cd $LFS/sources
lfs:/mnt/lfs/sources$ tar xjvf binutils-2.20.tar.bz2
lfs:/mnt/lfs/sources$ cd binutils-2.20

If the downloaded package is a .gz file, then instead of 'xjvf', you do use 'xzvf' to untar it. 'j' uncompresses bz2 files while 'z' uncompresses .gz files. The untarring command is implied before you start each sub-chapter. I also finally figured out how to time multiple commands using the GNU time command (which has a nicer, seconds-only format) rather than the builtin bash 'time' command:

$ \time -f "\\n================\\nTotal time: %e seconds\\n================" bash -c "../binutils-2.20/configure \
    --target=$LFS_TGT --prefix=/tools \
    --disable-nls --disable-werror && make && make install"
[.... many many commands later ....]

================
Total time: 146.24 seconds
================
$ \time -f "\\n================\\nTotal time: %e seconds\\n================" bash -c " ../gcc-4.4.2/configure \
    --target=$LFS_TGT --prefix=/tools \
    --disable-nls --disable-shared --disable-multilib \
    --disable-decimal-float --disable-threads \
    --disable-libmudflap --disable-libssp \
    --disable-libgomp --enable-languages=c && make && make install"
[....]
================
Total time: 678.12 seconds
================

I use \time to make sure I'm not using any builtin or alias command - this picks up GNUs /usr/bin/time (read more about finding the correct time in an earlier post). The -f option lets you specify a printf-like statement for formatting the output, so in this case I want it to just show seconds (%e). The real tricky part was how to get the multiple commands to run as one command, as time just times one single command. By invoking bash with its -c option, and quoting the entire rest of the line, we get it all together as one.

Oh, I also forgot to remove the source and build directories as specified in the book, so I needed to go back and do that for gcc and the binutils. And for the API headers, I understood it to mean that I needed to untar the linux-2.6.31.5.tar.bz2 file. And actually, that's one of the gotchas mentioned in the Linux Format's article:

Kernel API headers

A common mistake is to expect the kernel API headers to be in their own package. This is not the case - you will need to extract the kernel source package (usually of the form linux-2.6.x.tar.bz2) and then move into the extracted directory to follow the steps in the ebook.

For the binutils Pass 2 build, I needed to tweak the line a bit because of quoting problems:

 $ \time -f "\\n================\\nTotal time: %e seconds\\n================" bash -c "CC=\"$LFS_TGT-gcc -B/tools/lib/\" \
   AR=$LFS_TGT-ar RANLIB=$LFS_TGT-ranlib \
   ../binutils-2.20/configure --prefix=/tools \
   --disable-nls --with-lib-path=/tools/lib && make && make install"
[.....]
================
Total time: 135.00 seconds
================

Note the \" ...\" for the CC= line. This is so that it gets passed along correctly to the bash shell that gets run. I do wonder if the SBU time used should include the last 2 make commands specified on the binutils, Pass 2 page though. To get the current status of the SBUs for my system, you can see it here.

And I do know what LXF means when one of their caveats says to be careful with getting lulled into feeling it is always ./configure --prefix=/tools! I have changed my sample timing command to be:

\time -f "\\n================\\nTotal time: %e seconds\\n================" bash -c "./configure --prefix=/tools && make && make install"

I have this in a file and I just copy / paste while running it in an Emacs shell. But every now and then, a configure slips in that wants just a little more...

I finished up with Chapter 5: Constructing a Temporary System without too many problems. I've really been enjoying the in depth exploration of exactly what gets built and why. I do wonder about some of the unapplied patches though. Perhaps because it is just the "bootstrap" system, they aren't important at this point. I also thought it very quaint that the book worries about disk space and gives advice on how to save a whole 95mb by stripping the apps and removing some doc files:)

Edit: turns out the manual, not surprisingly, does talk about the unapplied patches here::

Several of the packages are patched before compilation, but only when the patch is needed to circumvent a problem. A patch is often needed in both this and the next chapter, but sometimes in only one or the other. Therefore, do not be concerned if instructions for a downloaded patch seem to be missing

The series so far:

1. Scratching the Linux Itch, pt. I
2. Scratching the Linux Itch, pt. II

Here is the result of my version-check.sh script on my openSUSE 11.0 system:

bash, version 3.2.39(1)-release
/bin/sh -> /bin/bash
Binutils: (GNU Binutils; openSUSE 11.0) 2.18.50.20080409-11.1
bison (GNU Bison) 2.3
/usr/bin/yacc -> /usr/bin/yacc
bzip2,  Version 1.0.5, 10-Dec-2007.
Coreutils:  6.11
diff (GNU diffutils) 2.8.7-cvs
find (GNU findutils) 4.4.0
GNU Awk 3.1.5h
/usr/bin/awk -> /bin/gawk
gcc (SUSE Linux) 4.3.1 20080507 (prerelease) [gcc-4_3-branch revision 135036]
GNU C Library stable release version 2.8
GNU grep 2.5.2
gzip 1.3.12
Linux version 2.6.25.20-0.5-pae (geeko@buildhost) (gcc version 4.3.1 20080507 (prerelease) [gcc-4_3-branch revision
    135036] (SUSE Linux) ) #1 SMP 2009-08-14 01:48:11 +0200
m4 (GNU M4) 1.4.11
GNU Make 3.81
patch 2.5.9
Perl version='5.10.0';
GNU sed version 4.1.5
tar (GNU tar) 1.19
makeinfo (GNU texinfo) 4.11
Compilation OK

So it looks pretty good so far. It's always scary when reformatting an existing partition. I have 3 primary 50gb partitions on a 250gb hard drive used to play with Linux distros. The fourth partition is an extended one with 2 logical partitions, a 90gb /home partition and a 2gb Swap. One of the primary partitions houses my regular distro, openSUSE 11.0, while the other 2 currently have an openSUSE 11.1 and an Ubuntu 9.04, neither of which I've used recently. So I'll just use the Ubuntu one, which is /dev/sdb3, and already created, so I just need to reformat it:

# mke2fs -jv /dev/sdb3
mke2fs 1.40.8 (13-Mar-2008)
Warning: 256-byte inodes not usable on older systems
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
2883584 inodes, 11520613 blocks
576030 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=0
352 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
        4096000, 7962624, 11239424

Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 28 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.

So far so good. Mount it on /mnt/lfs and we're good to go. On to chapter 3.

One small confusion about getting the matching packages is that while the manual says that an easy way to download all the packages is "by using wget-list as an input to wget", only they don't explain what that means. So here's what I did:

# cd $LFS/sources
# wget -i wget-list

[... 77 downloads later ...]

FINISHED --2009-11-12 09:22:42--
Downloaded: 77 files, 257M in 39m 57s (110 KB/s)

Actually, it turns out there is a slight clarification in the FAQ here, although they still don't clearly mention that you should cd into the $LFS/sources folder before doing the wget command. Maybe getting a little too anal but I think every little bit helps. So it took about 40 minutes to download all 77 packages. Now, onto Chapter 4, Final Preparations.

My next bit of anal retentiveness comes in the section 4.4, Setting Up the Environment. The book suggests a way to create a .bash_profile that restarts the bash shell in a "good" (ie, clean) working environment. But it doesn't really help in my openSUSE distro, because there is a system wide /etc/bash.bashrc that gets executed, "cluttering" up the environment even when the system wide /etc/profile isn't executed. So I modified the .bash_profile to be:

exec env -i HOME=$HOME TERM=$TERM PS1='\u:\w\$ ' /bin/bash --norc ./bash-startup

The --norc prevents both the system and the user .bashrc file from executing. And I copied the .bashrc file they say to create to bash-startup, and appended a couple of lines, leaving me with:

set +h
umask 022
LFS=/mnt/lfs
LC_ALL=POSIX
LFS_TGT=$(uname -m)-lfs-linux-gnu
PATH=/tools/bin:/bin:/usr/bin
export LFS LC_ALL LFS_TGT PATH

# my added lines to create a brand new, empty shell:
export PS1='\u:\w\$ '
exec bash --norc --noprofile

So I added the PS1 export and then re-exec bash, this time with neither the rc files or the profile files getting executed, just to be safe. Even then, there are a bunch of environment variables, but I think they are just ones that bash sets up for itself:

$ su - lfs
Password: 
lfs:~$ set
BASH=/bin/bash
BASH_ARGC=()
BASH_ARGV=()
BASH_LINENO=()
BASH_SOURCE=()
BASH_VERSINFO=([0]="3" [1]="2" [2]="39" [3]="1" [4]="release" [5]="i586-suse-linux-gnu")
BASH_VERSION='3.2.39(1)-release'
COLUMNS=80
DIRSTACK=()
EUID=1003
GROUPS=()
HISTFILE=/home/lfs/.bash_history
HISTFILESIZE=500
HISTSIZE=500
HOME=/home/lfs
HOSTNAME=touch
HOSTTYPE=i586
IFS=$' \t\n'
LC_ALL=POSIX
LFS=/mnt/lfs
LFS_TGT=i686-lfs-linux-gnu
LINES=24
MACHTYPE=i586-suse-linux-gnu
MAILCHECK=60
OPTERR=1
OPTIND=1
OSTYPE=linux-gnu
PATH=/tools/bin:/bin:/usr/bin
PPID=16656
PS1='\u:\w\$ '
PS2='> '
PS4='+ '
PWD=/home/lfs
SHELL=/bin/bash
SHELLOPTS=braceexpand:emacs:hashall:histexpand:history:interactive-comments:monitor
SHLVL=1
TERM=vt100
UID=1003
_=bash
lfs:~$ 

Now that the environment is set, time to move on to Chapter 5.

The series so far:

1. Scratching the Linux Itch, pt. I
2. Scratching the Linux Itch, pt. II

My favorite Linux magazine, by far, is Linux Format, a UK based magazine that is just chock-a-block full of great Linux info. They also run the informative Tux Radar blog. So I thought I would just give a rundown each month of the highlights from the most recent issue.

In issue 125, dated December 2009, the cover story is Remix Linux and there's some great stuff in there about creating your own personal distro. They start with apps that let you create your own mix, working from the Ubuntu Customization Kit (or UCK for short), thru SUSE Studio, and include quick shoutouts for Revisor (the Fedora UCK equivalent) and InstalLinux.com, a cool web site for building a distro.

The next step is to build your own Arch Linux version. Looks involved but you get pretty much complete control. And speaking of hard core, the final step is a project I've always had on my back burner - Linux From Scratch. Here you build it all from sources, beginning with GCC. Follow along with the ebook and see what happens! Better than a video game, even.

My favorite sections, being the "app-aholic" I am, are the Reviews and the Hotpicks, along with the Roundup, where they examine a bunch of apps dedicated to one purpose. This month, they looked at collection managers, and, being the packrat I am, I'm hoping to give this month's winner, GCStar a whirl, esp. after finding it in the openSUSE 11.0 KDE4 repository. I also tried to compile Choqok, a Twitter client, directly from the development snapshot, but my current installation as KDE3 just doesn't seem to like compiling this KDE4 app. Other interesting apps this month include Bilbo (a blogging client now called Blogilo), Booh (generate static web albums ready to upload straight to your website), Jampa (Yet Another music player), Rednotebook (a diary, journal and notebook), and KMyMoney (a personal finance package). I played a bit with KMyMoney (again) but got stumped when I couldn't figure out how to import .OXF files. Also disappointing there's no kind of web connect, but maybe I'll get back to it.

There's also several great tutorials, including writing a Python script to get Google data and getting your backups straightened out using Backup PC (although I've always leaned towards Bacula myself).

All in all, a great deal, even for US$99 (go here for that deal). You get 13 issues a year, plus a jam packed DVD in each issue, plus access to all the back issues in PDF form. The best deal in Linux!

Anyway, we finished Neverwinter Nights (we don't mind playing lagging edge games) and went on to play Sacred, which we picked up for cheap at the wonderful GoG (Grand Old Games) site. It was fun for the first few weeks, but then there started to be problems with the lobby server, as it isn't a direct connect game. It had become a bit of a grind, anyway, so we started looking about for a new game to play.

Unfortunately, classic, hard-core, cooperative RPG games are few and far between these days. The definitive site for all thing co-op, Co-optimus has almost no entries at all for even an action RPG to play co-op. Not sure why the well has dried up. So we decided to go really olde school and try the classic Baldur's Gate. Many years ago, in a galaxy far far away, I actually played this a bit across the 'net, but I've never really played it all that much. As I had two copies of it, I gave one to my buddy and we sat down to play it.

But we played the "Figure Out The Router/Firewall" game instead. For the next 2 hours, we tried to figure out why I couldn't connect to his server. This worked fine for both NWN and Sacred, but whenever I would type in his IP address, BG would just pause for a long time, and the come back with "Cannot Connect To Game Session". As my router is a virtually impossible to configure Juniper Netscreen router, he was hosting the games on his side. He made sure all the ports mentioned were opened, all to no avail. As well as the "official" ports (2300-2400 & 6073), someone also mentioned ports 1470, 15000, and, most importantly, ports 47624-49672. Not sure about those, but port 47624 is the DirectPlay port, so I'm not sure why this doesn't show up in the official docs.

But despite all these efforts, we just couldn't get our Baldur's Gate games to connect. So last night, we tried Icewind Dale. Still a wonderful RPG (in fact, I like it more than Baldur's Gate, despite, or perhaps because of, its more linear and hack-n-slash nature), but a slightly newer engine, esp. when updated with the Heart of Winter expansion and its Trials of Luremaster patch/expansion. So we were hoping the updated engine would be more cooperative.

But, alas, we were wrong. I still got the dreaded "Cannot Connect" error. So we then tried Hamachi, a free VPN software. Still no go. As he's a network wonk, I was sure the firewall and router was correct on his end. And I don't run a firewall at all (don't really need one if you are behind a NAT router), so it had to be my "user unfriendly pain in the butt to configure" Juniper Netgear NS5GT router. I fired up Wireshark (nee Ethereal) and began sniffing packets.

I hosted the game on another internal computer and sniffed the traffic, comparing it to the packets I was sending and receiving to my friend's machine. It was then I noticed something odd - my machine would send out a DirectPlay packet on port 47624, but it would get back the response on port 2300 on my internal connection but, of course, it wouldn't get it back from my friend's computer, because routers will allow a response on the same port but not a different one.

So I rolled up my sleeves, used some Black Belt Google Fu and found this page that describes the dozen or so steps(!) you need to go through to get it to work. I added 2300 & 47624 to my "Infinity Engine" Custom Service Object, and set the policy to forward it to my game playing machine. This got me connected but not for long. Turns out, I needed to add 2350 as well. I tried to add 2300-2400, as recommended somewhere, but the Juniper Netgear complained about not enough ports in the pool, whatever the hell that means.

And now it works. So, the basic fix is to make sure that both players port forward UDP and TCP traffic for the ports mentioned here (2300-2400, 6073) and 47624 (the DirectPlay port). I'm not sure what 6073 is for, as I don't think either of us have it set up - maybe that's an old DirectPlay service port? Yup, it is according to this (DirectPlay 8), while it say 47624 is "directplaysrvr". Not sure what the difference is, unless one is a fallback for the other. At the very least, forward ports 2300 & 2350 - I think it uses the second one by default and will only use a different one if it finds that port is busy.

emacsclient -n +%l:%c %f

The -n tells it to not wait for the server to relinquish control of the file - I just want to edit it. +%l:%c says set the cursor at the line,column specified. The Info and Man pages for emacsclient don't specify this correctly, as they are both missing the colon.

Now I'm trying to figure out how to bring it to the front. Burying Emacs behind a bunch of windows isn't much help. I did come across a pretty cool KDE keyboard shortcut - Ctrl-Alt-A - which brings to the front the window "demanding attention", but that's not all that much help. Unfortunately, it doesn't look like a problem that has been solved for these window managers that don't allow "focus stealing".

The most basic status tool is, of course, ps. In number of options, it competes with ls for most in the Linux manual! This is because it has 3 different command "modes" - UNIX, BSD and GNU versions, and all are usually mutually incompatible. ps gives you a basic snapshot of what programs are being run.

While ps is always around, the rest of these usually need special installation, although the next one, top, is almost always around. top adds more information but, most importantly, runs in a curses display, so it stays around and updates itself, giving you a constant view of what your CPU is up to. You can see it change dynamically as programs work your CPU harder. Use the 'h' key to display a help screen, giving you more sorting and display options.

The most flexible version of ps is htop. This gives you even more information, more sorting options and an even better curses display. Again, use the 'h' command to get a full help display. I especially like htop for how it displays the complete command line.

iftop uses a top-like display to show you what is going on in your network (your interface). It displays the various network requests, who is making them and how much is coming and going on each. This is an especially useful command on a server, as you can see what your web server is working on, and keep useful totals.

iotop again uses a top-like display to give you a real time, in-depth view of disk I/O. This is an especially useful diagnostic tool if you notice your hard disk is "thrashing" - ie, the red access light is doing a disco-like strobe effect and you're wondering who is doing all that hard drive dancing.

saidar is another monitoring tool that shows a nice overview of everything going on in your computer. Useful information like CPU load, swap usage, disk space, and network traffic. Good quick clean overview.

Next time, perhaps I'll take a look at some of the graphical system monitoring tools available for KDE and GNOME. If you have any other favorite terminal-based monitors, please mention them in the comments.