Software

Interesting finds

by

%Windir%system32 (typically C:WINDOWSsystem32)

clipbrd.exe — ClipBook Viewer

Big question, can I actually use it for anything? (Grrr, vim is better); windows clipboard management out of box seems to suck, or require finding a program almost no ones ever heard of :

ftype — manages file associates

very bloody useful – no more need to invoke explorer.exe to play with them.

systeminfo — quick print useful data

Gotta remember this next time I’m working on a system; msinfo32 provides more info, but for some dang reason always seems to need start.exe or rhe run dialog to launch it. systeminfo gives a good first look, and is easier to grep.

Windows XP does have some useful changes from DOS 5/6 based releases, but I’ve never actually found a lot that isn’t in my MS-DOS reference >_>.

by

Hmm, arguably I have my bad days, and then I have my worse days…

Tomorrow can’t get much worse in terms of work, I hope : Nearly 0500R, so no time for a proper days log; I really need to stop staying up so late.

At the moment, I’ve nearly got nail configured to my needs. The addition of macros and IMAP support is a real improvement over the old Berkeley Mail program. With a little more adjusting, I just might be able to dig into my back-log of mail sometime lol. So far, I only have one major complaint – no line editing at the prompt beyond the most basic level (provided by the terminal). That’ not really a problem though, it allows that old ed like terseness, it’s easy to keep the commands short.

Software, like physical tools should empower users to get work done efficiently, A little bit of learning how to use the program, is worth it when the reward is productive.

One thing I’ve also come to enjoy, is a useful trick for generating HTML manual pages. The mail/heirloom-mailx port installs as /usr/local/bin/mailx on FreeBSD, corresponding manual page being /usr/local/man/man1/mailx.1.gz. Because nail has a big manual page, it’s worth while to use a web browser or a text editor with tabs, in place of the usual $PAGER used by man.

$ zcat /usr/local/man/man1/mailx.1.gz | groff -Thtml -man > ~/mail.1.html
$ firefox3 ~/mail.1.html &

which is much more fun then my shell alias:

alias   man-nail="man -M /usr/local/man mailx"

Miscellaneous ponderings

by

/bin/ed isn’t so bad after all, but hey… knowing how to use ex, vi, and vim helps lol.

The old Berkeley mail interface is very interesting, but seems to lack mutts infinite configuration. Most of the time, I just use webmail. Google Chrome (Windows) or some thing from $BROWSER (*nix) is always open, so typically use that; but some times I do like to work from my terminal hehe. It even looks like the nail/heirlom-mailx program might add the stuff I desire.

TODO: inhale /usr/share/doc/usd/07.Mail (the reference manual), inhale nail documentation.

Reboxing the box

by

To go with the changes in my working environment, a new style for blackbox 😉

Image Hosted by ImageShack.us

Since I left KDE in favor of more compact systems, I’ve found that I tend to change my layout of things less often. Most of the arrangements are calculated for muscle memory, and my visual patterns, and have become a set of very quick reflexes.

I don’t miss a taskbar at all, and have still yet to find an excuse to use the slit or dock in Blackbox lol.

running off the deepend

by

Well, finished one portion of my docs (Grrr… wasting time in #kde-chat and #vim lol); even got one of the manual pages written out.

Ya know, with the mdoc.samples(7) and mdoc(7) manual pages + a few simple manual pages for reference (head, cat, pkg_add) the process of writing a manual page is actually much less painful then I remember it being. I’ve only got one small problem so far, thin I’ll post on daemonforums later and see if anyone has an idea; if not I’ll probably have to adjust the man pages wording a lit’ bit.

nroff/troff is also strangely addicting once you start playing with macro packages…

The problem with typing to quickly

by

Check if the program ‘named’ is running and listening. I don’t know off the top of my head if /etc/rc.d/named supports the status command or not (rc), but finding out if it is running the hardway is still easy.

I’m not familiar with any of the dns/ apps in ports, so I can’t say what name they would run under; but I’m sure someone here would point it out.

—

$ ps xa | grep named
   ... is named running?
$ cat /var/run/named/pid
   ... does the pid file exist?
$ netstat -n -p tcp | grep 53   -- s/tcp/udp/
   ... is anything listening on the usual port?

-> Assuming that the standard issue name server was used, you may want to check named.conf first, in case the settings were changed. On FreeBSD I believe this is etc/namedb/named.conf.

I really should check my posts for typo’s more completely, before I make an ass of myself so easily…. at least J65nko spotted it. Most times I try and check what I write, but after work, it’s not exactly a high priority – compared with finishing the sentence before I get AFK’d for the umpteenth time lol.

Installing SWAT 4 TSS on GNU/Linux

by

Disclaimer

The game is not supported by code weavers, and I don’t support users of this posting ether. However, comments and corrections are always welcome – spam will be killed. Also note well, I prefer the command line interface, so I do not use file mangers such as Explorer, Nautilus, or Filer often.

Prerequsists:

  • Basic understanding of GNU/Linux user accounts and permissions
  • Having a working GNU/Linux distribution installed (Ubuntu or Debian recommended)
  • The ability to understand file paths and simple file operations (e.g. copy) without a photograph or explanation of how to copy/move/delete files.
  • Legal copies of both SWAT 4 and SWAT 4: TSS, total of 3 CD-ROM

Step one: Purchase a copy of “CrossOver Games for Linux” from CodeWeavers, or download the free 7 day trial.

Step two: install Cross Over Games for Linux, hence forth called simply cxgames — for brevities sake!

The installation process is simple, the format I suggest is to install it as root for all users. This basically amounts to executing the install shell script as root, either with su or sudo

$ su - root
# ./install-crossover-games-demo-7.1.0.sh

$ sudo -H ././install-crossover-games-demo-7.1.0.sh

Either way, root will need access to you’re display. Via the su method, on a secure system to will have to grant root this access. The proscribed method is you’ll need to run 

xhost +local:root

, and set your $DISPLAY value accordingly once you’ve su’d to root. N.B. a lot of documents say 

xhost +localhost

, which will grant everyone on your machine access to the display; instead of adding root.

Once you’ve launched the install script, it will walk you through it — mostly by a graphical installation wizard.

Step Three: Install SWAT 4

Insert your SWAT 4 disk #1 into the drive, and make sure it is mounted. Some Linux distributions are set to automount it like Windows (Ubuntu), others require you to manually mount it. N.B. that secure systems will only allow root to mount file systems by default.

Launch the cxgames windows program installer; this may be in your applications menu (gnome/kde users) or have to be run manually from a prompt. If you have to run it manually, the program you want to execute is /where/you/installed/cxgames/bin/cxinstall, for example: /opt/cxgames/bin/cxinstall.

Since SWAT 4 is not one of the supported games, you’ll want to go with the “install other games” option, and pass by the disclaimer. You’ll thne need to tell it where to find the disk, usually this is just clicking a checkbox but it is quite flexible. You should install SWAT 4 into it’s own “bottle”, because Linux doesn’t care much for spaces (and command lines are fun), a good bottle name is “SWAT4”.

A bottle is just a simulated windows installation, so if desired – every game can be installed into it’s own separate place. This really makes back ups a snap, limits one program screwing with another, and improves situations if you need to make ‘tweaks’ to the bottle. The installer will then create the bottle in your personal space, e.g. /home/terry/.cxgames/SWAT4. N.B. that .files-and-dirs in Linux are considered ‘hidden’ files, in a GUI file manager, you’ll need to b/p to deal with that.

When the installer starts, run it, there is no need to change the default install paths, unless you are installing into a very customized bottle. Since SWAT 4 uses two CD-ROMs, you will have to umount your first disk, and mount your second before pressing “retry” on the change disks dialog. Same thing happens again at the end of the install, to put the play disk back into circulation. When you’re done, you can close the install program and tell the cxgames installer that it has completed, it will warn you for paranoias sake — close it.

Step Four: Launch SWAT 4

SWAT 4 uses a SecuROM based copy protection system, when I set this up – it thought cxgames version of wine was a cd-rom emulator! And refused to run, a quick fix is to google for the ‘swat 4 no cd’. You will need to backup the old Swat4.exe, and then replace it with the no cd fix in order to launch the game.

Since I prefer the command line, I use cp and mv to copy and move files around; rather then copy/pasting icons in a file manager.

$ cd ~/.cxgames/SWAT4/drive-c/Program Files/SierraSWAT 4/Content/System
$ mv Swat4.exe Swat4.exe.orig-1.0
$ cp /path/to/fixed/1.0/Swat4.exe ./Swat4.exe.nocd-1.0
$ cp Swat4.exe.nocd-1.0 Swat4.exe

Now launch the game, either via your applications menu (gnome/kde users), or manually with the wine subsystem of cxgames, e.g.

$ /opt/cxgames/bin/wine --bottle ~/.cxgames/SWAT4 ~/.cxgames/SWAT4/drive-c/Program Files/SierraSWAT 4/Content/System/Swat4.exe

Then go ahead and test the training level or something like that. SWAT 4 must take care of first run chores before you install the path. When you’re done, just exit the game like normal. In the vent of catrostrophic disaster, you should be able to ctl+alt+function key to vtty, login to a command prompt, and us the ps and kill commands to terminate the process, cxgames also has it’s own way of nuking bad windows processes hehe.

Step Five: Patch SWAT 4

Because the patch checks for a legit copy of SWAT4, we have to replace Swat4.exe with Swat4.exe.orig-1.0, otherwise the patch will fail and scramble a few game files.

$ rm Swat4.exe
$ cp Swat4.exe.orig-1.0 Swat4.exe

Now insert you SWAT 4: TSS disk and run the installer, just like when you installed SWAT 4. Except use the same bottle, by selecting it from a list of existing bottles when prompted for a bottle to use. Once the TSS installer pops up, click the button to install the SWAT 4 1.1 patch.

Step Six: Test run SWAT 4 1.1

Now you need to use a no cd fix for SWAT 4 1.1 in order to continue, download it and do like in Step Four.

$ mv Swat4.exe Swat4.exe.orig-1.1
$ cp /path/to/fixed/1.1/Swat4.exe ./Swat4.exe.nocd-1.1
$ cp Swat4.exe.nocd-1.1 Swat4.exe

and launch the game as in Step Five.

Step Seven: Installing TSS

If you left the TSS installer open from Step Six, fine, if not, open it again — same exact way.

You will have to replace the no cd fixed Swat4.exe with the original one from the path, else the TSS installer will bomb out on you.

$ rm Swat4.exe
$ cp Swat4.exe.orig-1.1 Swat4.exe

Now get the TSS installer up and click the install swat 4 tss expansion pack button. Then proceed through the installation process; you shouldn’t have any major problem, as long as you remembered switch executables first.

Step Eight: Run SWAT 4: TSS

Now you should be able to launch SWAT 4: TSS, when I did it… there was no problem with the Swat4x.exe file in the expansion pack, but the game soon refused to run, having verification problems, despite being a legally paid for copy, with the legally paid for copy in the drive. So one will need to employ another no cd fix to be able to use this legally paid for copy of the game.

$ cd ~/.cxgames/SWAT4/drive-c/Program Files/SierraSWAT 4/ContentExpansion/System
$ mv Swat4X.exe Swat4X.exe.orig
$ cp /path/to/fixed/Swat4X.exe ./Swat4X.exe.nocd
$ cp Swat4X.exe.nocd Swat4X.exe

You can launch it the same way as SWAT 4, but in the case of the command line, the path changes. Just like on Windows, from ContentSystemSwat4.exe to ContentExpansionSystemSwat4.exe.

Known Issues

If the game and your display are not running at the same resolution, moving your mouse pointer to the ‘edge’ will make it scroll outside the window, effectively creating a pan and scan across your display. I have a 1600x1200px primary screen and a 1280×1024 secondary screen. Having SWAT in 1024x768px mode, was horrible… edit: this happens even when the game and X screen are at the same resolution.

I have yet to determine under what conditions dual heads will work, but luckyally most X Window Managers handle dual heads better then Microsoft Windows (in my indignant opinion), at least that has been my experience under FreeBSD 7 and Ubuntu GNU/Linux 8.04 with X.Org 7.2,a nd Windows XP Media Center Edition. So the main problem is a question of mouse handling.

Because of the way things work, people who use mods (e.g. SSF) may have problems launching them, without a corresponding no cd exe. Other wise the game seems to be useable, I’ve only to acertain whether or not graphical performance can be maintained.


Free Image Hosting at www.ImageShack.us

My word, wouldn’t it be heaven to only need windows to play Raven Shield once in a blue moon?

getting bored

by 
#!/bin/sh
#
# usage: vimbuild [tag]
#
# fetch indicated release tag of vim, compile, and test it.
# Requires the Concurrent Versions System (cvs) or  Subversion (svn) client,
# and a suitable make tool.
#
# environment:
#
# $TMPDIR will be used as a staging area if defined, else /tmp is used.
#
# exit status: non zero on failure, zero on success.
#

PATH="/bin:/usr/bin:$PATH"

WORKDIR=${TMPDIR:-/tmp}
VTAG=${1:-vim}
CONFIGURE_ARGS="--enable-perlinterp --enable-pythoninterp --enable-tclinterp --enable-rubyinterp --enable-cscope --enable-fontset --enable-gui=gtk2 --disable-gtktest"

mkdir -p $WORKDIR || exit 1 
cd $WORKDIR

# fetch latest vim
if [ -x "`which cvs`" ]; then
    echo using cvs
    cvs -z3 -d:pserver:anonymous@vim.cvs.sf.net:/cvsroot/vim checkout $VTAG
elif [ -x "`which svn`" ]; then
    echo using svn
    svn checkout https://vim.svn.sourceforge.net/svnroot/vim/branches/${VTAG}
else
    echo 'error, could not find a cvs or svn binary in $PATH!'
    exit 1
fi

cd $VTAG
 ./configure $CONFIGURE_ARGS

#
# set the make command
#
uname | grep -i linux > /dev/null
if [ $? -eq 0 ]; then
    NCPU=$(expr `cat /proc/cpuinfo | grep processor | wc -l` * 4)
    MAKE="make -j${NCPU}"
else
    # assume GNU make is gmake, like on *BSD
    if [ ! -x "`which gmake`" ]; then
        echo "Warning, GNU make not found!"
        echo "This will probably make a GTK gui build fail..."
        MAKE=make
    else
        uname | grep -i bsd > /dev/null
        if [ $? ]; then
            # check number of cpu via BSD sysctl
            NCPU=$(expr `sysctl hw.ncpu | awk '{ print $2 }'` * 4)
            MAKE="gmake -j${NCPU}"
        else
            MAKE=gmake
        fi
    fi
fi

# now build and test it
$MAKE
if [ -x ./src/vim ]; then
    ./src/vim --version > /dev/null
    if [ $? -eq 0 ]; then
        echo "I think the Vi IMproved build was a success"
    else
        echo "I think the Vi IMproved build was a failure"
        echo "Do you wish to test it manually?"
        read REP
        echo $REP | grep -i y && exec ./src/vim
            # NO RETURN on yes
    fi
fi

cat << EOF
    run: `echo $MAKE | awk '{ print $1 }'` install
    as root to finish installing vim
EOF

exit 0

I wonder, if I’ll ever bother to use it lol

Hey, it actually worked lol.

Uploaded it to my server, tweaked the configure args and bingo — freshly updated via

$ vimbuild vim7
…
$ su – root
# cd /tmp/vim7 && make install

Just for the heck of it, I’ve made the script adapt $CONFIGURE_ARGS based on what it finds installed, hehe.

Muahuaha !!! I love this thing.

by 
$ vim pf.conf.new
 ... write new packet filter configuration file
$ pfctl -nf pf.conf.new
  ... silent output if no errors
$ su - root
Password:
# cd /etc
# mv pf.conf pf.conf.old
# cp /home/Terry/pf.conf.new /etc/pf.conf && rm /home/Terry/pf.conf.new
# chmod 644 pf.conf && chown root:wheel pf.conf
# echo 'pfctl -F all -d' | at hhmm
  ... unlock the door if we screw up
# pfctl -e

enabling or disabling the packet filter (-e, -d) kills the SSH connection, but in the event of any embarrassing “oh crap, I’ve locked myself out” accidents, the at job will flush the firewalls settings and disable it. Believe me, if you’ve got a system running with no head or physical inputs (e.g. no monitor, no keyboard), ya really want to use such a thing… I still remember coming home from a *very* bad day at work, working on my rule sets, and locking myself out 5 times, and having to hook up a monitor and keyboard to the server each time >_>.

What wonders you can learn from one bad day, huh?

At least tonight, I’ve not locked myself out once… despite the days troubles, hehe. One of the reasons I like OpenBSDs packet filter, it’s simple, it’s powerful, just read the fine manual, use your gray matter, and it works! The rule sets are fairly easy to read, and OpenBSD documentation is second to none. Heck the manual page even gives the pf.conf syntax in Backus-Naur Form. The only complex part of pf, is the networking stuff – not the configuration. And of course, I love anything that is configured through a sane text file, rather then having to fire up some cornball program lol. Really, I wish I had the resources to replace my router with an OpenBSD machine, that way I wouldn’t have to learn my way around a new web-interface whenever one pops its final cork.

Ahh… At least one good thing happened this weekend!!!