We are collaborating on an open-source free-software project called ucanvcam to help build virtual webcams or add special effects to a webcam stream. A tool based on this should be showing up on makesweet eventually. The basic idea is to make an API for doing webcam video stream manipulation in an OS-neutral way. Support is just Windows and Linux so far though, there’s nothing there for Macs yet. Anyway, ucanvcam should take care of all the messy OS details and leave users of the project free to create fun effects. We’ll be doing our bit to make this happen.

Related projects out there:

• EffecTV
• CamTwist
• Splitcam, SuperWebcam, WebcamMax, ManyCam, …
• Video jockey software such as Gephex

Update:
You can now download a binary release of ucanvcam. The release is a GUI for windows, and command-line for Linux. You can download and compile the source to get a GUI for Linux, but we don’t have a portable build for it yet.

Update (2):
Now the GUI is ready and downloadable for both Linux and Windows.

Are you interested in an open-source virtual webcam? If so, why? Leave us a note - the more information we have about interest in this the more we can justify contributing to the development on it.

We were having a problem with google webmaster verification of a website; it constantly said:

“Our system has experienced a temporary problem”

It turned out that a misconfiguration of wordpress on that site in the main .htaccess file was producing error 500 codes instead of error 404 codes for http requests for non-existent pages.  You can see if you have this problem just by trying to load “/nonexistent.html” for your website.  If that reports error 500, that is the problem you need to fix in order to make google happy, and the place to look is the top level .htaccess page.  In our case, a fantastico installation of wordpress had added the following:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

which wasn’t very helpful given that the wordpress installation was not in that directory at all…

What stops a program compiled on one linux machine from running on another? Libraries, mostly. The libraries available on one machine may not be on the other, or may have different versions.

It is generally quite easy to get something you compile on one linux machine to run on another. Here’s how.

Suppose I’ve just compiled a program called “killerapp” on machine A, and now want it to run on machine B. But if I just copy it across, here’s what happens when I try to run it on B:

./killerapp: error while loading shared libraries: libcgicc.so.5: cannot open shared object file: No such file or directory

This means I’m using a library that isn’t on the other machine. Of course, I could try installing all the same libraries on B as there are on A. Suppose we can’t or don’t want to do that. Then our alternative is to statically link libraries with our program.

On B, run the command “ldd killerapp”. This will give something like:

linux-gate.so.1 => (0xffffe000)
libpthread.so.0 => /lib/tls/libpthread.so.0 (0xf7f77000)
libdl.so.2 => /lib/libdl.so.2 (0xf7f73000)
libgd.so.2 => /usr/lib/libgd.so.2 (0xf7f26000)
libcgicc.so.5 => not found
libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0xf7f08000)
libpng12.so.0 => /usr/lib/libpng12.so.0 (0xf7ee4000)
libz.so.1 => /usr/lib/libz.so.1 (0xf7ed3000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xf7e0b000)
libm.so.6 => /lib/tls/libm.so.6 (0xf7de8000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xf7dde000)
libc.so.6 => /lib/tls/libc.so.6 (0×45b43000)
/lib/ld-linux.so.2 (0×45b29000)
libXpm.so.4 => /usr/X11R6/lib/libXpm.so.4 (0xf7dcf000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0xf7cef000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xf7c84000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0xf7c76000)

The list on the left is the libraries our program is looking for, and then on the right are the local versions it finds. We’ve got a “not found” in there for a library called “libcgicc”. This is a library present on A, the machine we are compiling on, but absent on B, the machine we want to run on.

The extension “.so” means “dynamic library” - a library that doesn’t get included in your program, but instead will be hooked up to it when your program is run.

Libraries can also come with the “.a” extension, which means “static library” - a library that is inserted in your program and so gets copied along with it.

Let’s go back to our compiling machine, machine A, and see what “ldd killerapp” says there for libcgicc:

libcgicc.so.5 => /usr/lib/libcgicc.so.5 (0xb7f18000)

So on machine A, the library we want is in /usr/lib. If we do “ls /usr/lib/libcgicc*” we can see what versions of this library are available. On my machine that is:

/usr/lib/libcgicc.a
/usr/lib/libcgicc.la
/usr/lib/libcgicc.so
/usr/lib/libcgicc.so.5
/usr/lib/libcgicc.so.5.0.1

So there is a static version available, “libcgicc.a”. If there were not a “.a” version, we would need to get one - on debian/ubuntu, we could track it down by doing (as superuser):

apt-file search libcgicc.a

(If you haven’t used apt-file before, do “apt-get install apt-file” and “apt-file update” first).

Now, all we need to do is relink our program, replacing “-lcgicc” with “/usr/lib/libcgicc.a”. Now when we do “ldd killerapp” on either machine, we have no more missing libraries.

However, that doesn’t guarantee all libraries are exactly the same version. A frequent problem is libstdc++ for C++ code. If you see a message like this when trying to run your code:

./killerapp: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.9′ not found (required by ./killerapp)

Then you’ve got a version mismatch. This may be fixable by statically linking the libstdc++ library. Check what version of g++ you are using with “g++ –version”, and then check for libstdc++.a in:

/usr/lib/gcc/[platform-name]/[version]

(location may be different on your computer). Once you track this file down you can link it statically as before.

We may also see later runtime problems, if our library versions are a bit out of whack. For example:

./killerapp: symbol lookup error: /home/foo/killerapp: undefined symbol: gdImageGifAnimBeginPtr

This is a missing method from the “gd” library on machine B. We can fix this by static linking of libgd.a following the same method. Note that when you switch from linking with -lgd to /usr/lib/libgd.a, you may have to manually link against libraries that gd depends on in turn (e.g. -ljpeg, -lpng12, etc).

And so on.

Note that if you plan on distributing a program widely, you need to think carefully about library dependencies, but for just moving from one machine to another this kind of step-by-step fixing is often good enough.

I’ve a tendency to use wget for everything. Here is one of many ways to check if a page contains dead links:

wget -k http://your.site/page.html
wget –spider –force-html -i page.html

(of course there are plenty of online services for this too).

For some reason, a virtual linux machine running on vmware that I occasionally check in on tends to drop into read-only on its root filesystem from time to time. I assume some corruption is going on somewhere, but the machine isn’t important enough to spend time figuring this out. Recovering is usually super easy:

fsck
mount -o remount,rw /

If you have to ask what “fsck” means, I suggest you don’t do this…

Update: looks like there is a patch for this problem (thanks Dan).

Very occasionally, the KDE menu bar disappears on me. I don’t like restarting just because of this. The following seems sufficient to get things going again:

killall -9 kicker
kdeinit kicker

Just in case you are caught without a terminal, it is also useful to know that ALT-F2 gives you a command line in KDE.

There are probably better ways, but this works…