In almost every single netiquette guide, people are reminded that a brief signature line is appropriate at the end of an email or newsgroup message. This rule is often abused by spammers, newbies and trolls, but on the whole, it has worked fairly well.

Until recently...

Now, it seems that anyone using their email account at work is unwittingly spamming the rest of the world, useulessly wasting precious bandwidth and valuable electrons. Every email coming out of corporate America or Corporate Australia has to have 20 lines of legalese disclaimers and other useless crap. What's the deal with that?

I analysed a recent post to a mailing list I follow, to make a point. The content was broken down like this:

• Email transport headers: 30 lines, 1656 characters
• Message body: 28 lines, 1367 characters
• Corporate disclaimers: 111 lines, 4205 characters
• Virus checking statements: 12 lines, 339 characters
• MIME regurgitated: 28 lines, 1513 characters

So out of a message of 351 lines or 15233 characters, the actual useful content represented a paltry 9% of the total message, with a transport overhead of another 9%. That means that 82% of the bytes in that message were completely useless!

The message body was a predictably bad joke. I can wear the transport overhead, even though certain email clients (such as those designed in Redmond) put all sorts of extra crap in the real RFC headers. The corporate disclaimers were a waste of time; nobody reads them. They only annoy people and get in the way of the actual message. But in this litigious day and age, where everyone wants to sue everybody else, nobody can take responsability for their own actions, and everyone is trying to cover their arses, just so that if they get sued they can point to their disclaimer and say "bad luck - not my fault".

Anyway, I really wonder if half the legalese verbiage would really stand up in court if put to the test; I suspect much of it is simply hot air, to keep the lawyers happy.

And then of course, there is the "certified virus-free" crap. As far as I'm concerned, this is a blatant advertisement for somebody's virus-scanning product. Sure, they can scan it for known viruses to get that warm fuzzy feeling, but there is always a window of time between when a virus comes into the wild, and when the providers come out with their database update. So there will always be the potential for a virus to slip through and infect some poor sod's skanky MS Outlook system, which will happily go ahead and spam everyone they know into infected bliss.

Attachments are always going to be a potential source of viruses. But if people insist on using products that are more concerned with bells and whistles to keep you on the upgrade treadmill than they are about a secure architecture, people will always suffer. There are two simple solutions: first, use software that has been properly designed with security in mind, and second, train your users to deal with attachments sensibly.

I have a very simple policy that has protected me from viruses for many many years, and I am willing to share it with my gentle readers at no additional charge:

• Don't run executables from anywhere. Period. No matter how funny the animation is supposed to be. No really, don't. If you want to watch animations, view them with Flash or something. Executables only work on the platform and system they were compiled for anyway, immediately limiting their usefulness and lifetime. Why should I trust an entire executable and give it complete privileges to my machine, when all I need to get at is some data?
• Don't enable macros in documents you open from external sources. Honestly, how often are macros really necessary to view some sodding text?
• Secret weapon: use a Free Operating System with a decent email system.

Granted, this email may be unusual in its breakdown, but I know simply from the countless messages that dribble into my inbox that I frequently receive one or two-line messages from people, that have 14 or so lines of corporate disclaimers and crap.

It's a pointless waste. Disclaimers - why are they there? Real recipients just ignore them because they are annoying and get in the way of the real message, and unintended recipients ignore it and just hit the Delete key anyway. So in order to keep the lawyers happy, we are wasting some 50% of our bandwidth?

Pass the clue-stick...

I think I've now got everything up and going with my new OpenBSD install.

There are a few gotchas that I predictably tripped over. Note to self: write up doc patches or FAQ entries and submit to Theo...

So having mostly solved the booting problem, I then needed to sort out the network card problem.

As it happened, my good friend and sometime BSD fiddler Michael had come over for a bbq dinner. Never missing the opportunity to engage in some geek talk, I regailed him with my fascinating stories of installing operating systems, and the ensuing driver problems.

Moved as he was by my tales of woe, he took pity and sat down in front of the newly christened but slightly ill BSD install, and went to town. Before too long, he wandered in to the kitchen shaking his head, mumbling something about me being a moron. Not again, I thought - what had I done?

Apparently a brief review of 'dmesg' revealed that IRQ 5, allegedly allocated to the NE2000 card, was also being surreptitiously acquired by the SoundBlaster card. So the plug-n-pray config had failed to avoid the statically allocated IRQ for the NIC and thus I had a fairly simple case of IRQ conflict. Eureka! Don't you just love the ISA architecture? :-/

So away he toddled, while I quickly got into UKC and did a 'disable isapnp0' faster than you can type the first half of War and Peace, and booted. Lo and behold! - it worked, and my ne0 was humming once more.

The only other thing I had to do (apart from switching to ksh instead of the horrible sh shell) was set /etc/mygate to the IP address of my home gateway, and it was F-A-B Scott!

Now I can start adding some packages, and have a real play. First stop, Emacs...!

So I guess, my thoughts thus far on OpenBSD...

It is very small, very fast, and solid. There are a few issues that make installation a little bumpy, but the documentation is generally pretty good. A default install is a bit bare for my liking; it takes a bit of tweaking and extra packages to get what I would call a comfortable base system. But so far, I quite like it.

And it is always good to learn new tricks...

I love the OpenBSD mascot - the puffer fish. Maybe as cute as a penguin, but definitely not as cuddly!

I'm back to have a play with my new OpenBSD installation. I now have two major problems: a) I can no longer boot into any other OS on the machine, and b) the network card is not being recognised.

Unfortunately, b) makes a) harder to solve...

When I did the install, I accepted defaults whereever possible (and sensible). Part of that must have been to nuke my MBR, so now I can only boot into BSD. I think I'm going to have to install Grub or LILO. If I can boot into the RedHat partition somehow, I can rerun LILO and get that going. Otherwise I need some sort of rescue disk with Grub (or LILO) on it.

Ok, after a bit of fiddling - I used the fantastic Tom's Root/Boot Disk, the rescue floppy with the most - Thanks Tom!! - to mount my old Linux install and rerun LILO. Now NT won't boot (I still have some old files there I haven't backed up) but at least I have some more room to move. I booted back into RedHat, and double-checked that the NE2000 driver loaded correctly. It does; the IRQ and the IO port are the same as in BSD. There's something fishy about the bsd ne driver then... which is surprising, since it is such an old an established card. Hmmm...

Another gripe: when I log in, why on earth should it ask me the termcap type? Surely the enlightened system that it is could at least infer that since I was logging in on the console, that it could make a reasonable assumption as to what would be the most appropriate terminal type?

Well, after a bit more googling, it would appear that I am the victim of a "not quite 100% real" NE2000 card. Apparently not all NE2000 cards are created equal, and while other OSes seem to fudge their way through and work fine, OpenBSD doesn't seem to want to. I know the IO and IRQ are correct from booting into other working systems, and I'm fairly sure I've set the config (and media selection) in the network card SETUP. But apparently it is often a problem where the media selection is not assumed by BSD and if not set explicitly in the card, will not work. Now all I have to do is find that old driver disk... (And if any of you had seen my office, you would feel sorry for me about now...)

More ramblings when I don't have training material to write.

libfg -- Frame Grabber library for Linux

New! - the latest version supports USB cameras, and features a sample app for live video display!

Introduction

The libfg library provides a simple high-level C API for controlling Video4Linux devices, including analog video cameras, TV and webcams.

Overview

Linux has support for TV tuners and frame grabbers. This is provided by the Video4Linux API, which has been around since roughly kernel 2.2. V4L is actually an interface implemented by a number of different drivers or kernel modules that support the different types of hardware. Since it is a kernel level interface, it is driven entirely by ioctl() calls, and is not particularly friendly to use. It is also not particularly well documented.

The purpose of libfg is to provide a simple, high level interface for controlling TV tuners and frame grabbers. This insulates the developer from having to fiddle around with the low-level details. An example below shows how easy it is to use. It is hoped that this will enable developers to write more applications that exploit this hardware, and create some interesting programs.

Features

The current version of libfg supports most of the major features provided by the Video4Linux API (Version 1). This includes:

• Double-buffered capturing (depending on driver)
• Setting a capture window (cropping)
• Set brightness, contrast, etc (in percent)
• Control TV tuner (in MHz)
• Supports multiple norms (PAL, NTSC, Secam, etc)
• Supports different frame formats (eg. RGB32, RGB24, YUV)
• Can save frames to disk (pgm)

Hardware Support

Any V4L device supported by the kernel will work with libfg. This includes capture cards, TV tuners and webcams. The most common type of hardware is probably cards based on the BT848/BT878 chipset, although plenty of others will also work. These days, TV tuner/capture cards are surprisingly affordable too. Get yours today! For more details on particular cards, consult the documentation that comes with your kernel.

We have tested libfg on the following hardware:

• Picolo (BT878)
• FlyVideo 98 / Chronos Video Shuttle II (BT878)
• Logitech Webcam Express

Note on Firewire/1394 devices: it should be possible to use a Firewire camera with the loopback driver; I am currently working on this, and will provide a new version soon.

Kernel Support

You may need to build your own kernel (Shock! Horror!) if your distro doesn't already come with the Video4Linux modules. Debian doesn't by default, while Mandrake does. You will need to enable at least Video4Linux, I2C (for the tuner), and the right module for your card.

License

The libfg code has been released under the Lesser GNU Public License (LGPL). This is to ensure that the code can be used in as many applications as possible (even proprietary or closed-source projects if you really must), while ensuring that improvements to the library itself get sent back to the community. Please read the license in its entirety and understand it before using the software - a copy is included in the source in the file LGPL.

Projects

Currently libfg is used in the following projects:

• The University of Melbourne RoboCup Initiative
• Player/Stage
• Mezzanine

Its main application thus far has been in frame-rate (~40ms) image processing for robotics applications.

If you use libfg in your project, please let me know so I can add you to the list.

Download

For now, you can just download the source tarball (using the link below):

• libfg-0.3.1.tar.gz (Source tarball, 122kB)

Documentation

API reference documentation is provided in the above tarball, in both HTML and PDF formats (thanks to Doxygen). The included samples show how to use it; it is fairly straightforward. The device is always initialised to sensible defaults, so after fg_open() returns, you can start grabbing right away.

Examples

There are two example progams included - test-capture, which exercises a number of different calls in the library, and camview. The camview program uses libsdl to perform live streaming of video images into a window.

Building

Just running make will give you a static library (.a) to link with. For now, that will have to do until I sort out dynamic linking of shared libraries and versioning and all that it entails. The README has info on how to build the Python bindings, which is pretty simple.

Sample User Code

Here is an example of how easy it is to use libfg to control your frame grabber in C:

#define TV_ABC 64.250f


void test()

{

  FRAMEGRABBER* fg = NULL;

  FRAME* fr = NULL;

  // Open the default device

  fg = fg_open( NULL );

  // Capture from our VCR


  fg_set_source( fg, FG_SOURCE_COMPOSITE );

  // Take a snap

  fr = fg_grab( fg );

  frame_save( fr, "vcr.pgm" );

  // Now get ABC TV

  fg_set_source( fg, FG_SOURCE_TV );

  fg_set_tuner( fg, TV_ABC );

  // Take a snap

  fg_grab_frame( fg, frame );

  frame_save( fr, "ABC.pgm" );

  frame_release( fr );

  fg_close( fg );

}

And here is an example of the preliminary Python support. This script
was used to create the image at the top of this page. (Gimp was used
to convert the file from PGM to JPG and scale it down a little.)

#!/usr/bin/env python



import fg


g = fg.Grabber()

g.set_channel(182.250)

g.save_frame('sample.pgm')

del g

Enscript was used to do the colour syntax highlighting of the source code.

Useful Links

Here are some links that may be useful:

• BTTV Mini-HOWTO (LinuxDoc.org)
• Video 4 Linux HQ
• Video 4 Linux Version 2

So I have now installed OpenBSD 3.2. I had a problem post-install, something to do with the tty settings and a pccom driver. This still isn't resolved; it just "came good" after a little while. So...

So all I have is a root user, and I log in as that. Then it admonishes me for logging in as root, and tells me I should 'su' instead. Fair enough - it is supposed to be rather anally-retentive security-wise after all. Anyway, so I decide to add a user. Not knowing how this is done under BSD, I try typing adduser, and get a little usage printout. Right, well lets just type 'adduser fred' and get myself a new regular user. It then warns me that it hasn't created a new home directory. Sheesh! Why wouldn't I want it to do that?! Surely a reasonable default would be to create a new home dir, set a default shell, then copy over some sort of /etc/skeleton type files to get a reasonable default starting install. Now I have to manually do all that crap; and probably miss something in the process. It also didn't even prompt for missing information (such as comment, default shell, or anything useful like that).

Meanwhile, the keyboard is still doing strange things every once in a while, like inserting extra characters. And the default shell obviously isn't bash, as none of the keyboard shortcuts I'm used to work here either. Anything other than alphanumeric keys are greeted with '^[A1' style characters; it's a bit raw. I was going to complain about the lack of virtual terminals, but I just found out (by accident, reading the FAQ of all things) that it is C-A-F1, so I'm happy with that!

Now I've just realised that my network card isn't working - it hasn't found the right IRQ/IObase - it's an older ISA NE2000 clone card, so I will just have to set it up manually. Now where did I write those settings down again...?

(I must say, the documentation is (as I had been told) very nicely done with OpenBSD.)

Er... time for a break (and some chores). The saga will continue...

So I decide to install OpenBSD 3.2, just to have a play. It starts off nice and simple...

Then it comes to fdisk. Now I've installed lots of different operating systems, and I've chopped up disks using lots of different tools. What I found odd was the navigation in the fdisk tool. The usability factor is about minus a thousand; exposing the lowest possible level of partitioning is not necessarily a good match for someone who "just wants a 650Mb primary partition".

I had a number of primary and extended partitions on the big disk where I was installing it. When it first came up, it printed 3 tables of info. I realised this must be first the primary partitions, then the other two tables showed the contents of the extended partitions. Fine... have a quick look at the help to get familiar... Have a read of the manual... Ok, so lets try the select command - that's gotta be safe. Type: select 1. Not an extended partition... Ok. select 2. Cool - get some more guff on MBRs and so on. Do a print, see the contents. Fine, now I want to see the top level. select 0. Nope. It took over 20 minutes of faffing about before I decided to try 'quit', only to discover that this was the way to go "up a level" in the navigation, to get back to looking at the primary partitions. Nothing in the online install guide or the manual or the FAQ were helpful in discovering this. Best I send off a patch for the docs...

Anyway, I changed an old 800Mb FAT partition to type A6 as a new home for OpenBSD. I saved the changes, and continued.

Next comes the slicing and dicing. Well, BSD sure has some different ways about it. But it's always interesting to find new stuff. But it's a bit intimidating when you do a 'print', and discover that for some reason your entire hard drive is listed as 'partition c' and you are politely reminded not to screw with it. What's the deal with that??

Now thus far, I have a single 800Mb partition ready for BSD. It's already created, but both the online install guide and the FAQ show the first thing to do is delete the partition. Presumably this is not really deleting the partition so much as deleting a single slice that is assumed to be taking up the whole partition?

Just to keep things really simple, I decide to have a single root and some swap. I will reinstall later once (a) I have some more space to play with, and (b) I have figured out how to properly allocate slices and so on.

So I get brave and do a 'd a' to delete the 'a' partition. Then I do an 'a a' to add a root partition, and 'a b' to add a small swap partition. During this process, I can't see where it is you are shown the available or unallocated space (which would be rather useful at this point). You really have to know what you are doing, and I imagine planning this on paper would really help.

Next the formatting, which goes fine. I choose another hostname (taken from Blake's 7) and this one is now 'orac'. Choose a few more little things, and then come the packages. I select all but X (the default) and away it goes.

The final stage goes by without a hitch, then I'm prompted to reboot. I reboot and up it comes. Although I notice that, without my go-ahead, it has nuked the MBR boot loader that I had installed, so now I will have to backtrack to boot any of the other systems.

Anyway, just when I think I have a working installation, it gets nearly all the way through the bootup sequence, gets to "setting tty flags" and then just hangs.

A bit of googling turns up some leads, and I discover that this was a known problem with the pccom drivers at around v2.3. Since I am running 3.2 I'm surprised it is still a problem :-(.

Ok, now this is really weird - I spent several hours outside working in the garden. I come back and it is still hung. I hit return a few times, and nothing. Then I turn back to the other machine where I am typing this, do the search, then when I turn back to reset the new BSD install, it is sitting there with a login prompt. Weird... It mostly works, but it feels like the keyboard support is still a bit dodgy.

I have installed it on an oldish Pentium box, with an AMI BIOS. Nothing unusual about it; very plain hardware, no exotic cards or anything. Ah well, I guess now begins the task of actually using the thing.

I guess, my comments on the install process would be: eck. The whole partitioning thing was far more painful than it needs to be. There is just a huge mismatch between the task that the user is wanting to perform (set up partitions of certain sizes) and the interface (which exposes the physical details at the lowest level). Apart from that, it was basic but did the job.

Now on to using it...

Does time really go faster as you get older?

Or is it just that I'm taking on more and more extra projects each year?

Well, I've been doing some more work on the site, and I've written a simple download tracker thing coz the filestore module in Drupal bites rocks right now... Shame coz it could be really good, and it would be really useful. Unfortunately it is rather flaky, and has all sorts of bugs. Maybe I will get around to fixing it one of these days. At least now I've got the hang of PHP etc...