Welcome to Kirsle.net!

Ubuntu by default follows some good security practices such as locking out the root password so that you can't log in directly as root (short of using sudo -i), but in Fedora systems if you lock out the root password, you can't use any of the graphical admin apps anymore since they ask for the root password.

So, here's how to set up Fedora to ask for the user password for graphical admin apps:

There are scripts in /etc/security/console.apps/ for most of the graphical admin apps, for example /etc/security/console.apps/system-config-users for the user & groups app. The general syntax for these files is like this:

USER=root
PROGRAM=/usr/share/system-config-users/system-config-users
SESSION=true

On my Fedora 12 system though, all these scripts include /etc/security/console.apps/config-util first. So, my system-config-users script just said this:

. config-util
PROGRAM=/usr/share/system-config-users/system-config-users
SESSION=true

After my first blog post about it, I've already made a lot of progress. Here's a (very alpha) screenshot I took today:

What you're seeing here is a debug mode "actor selector" window. This is a screenshot on Linux so the actor window looks ugly as sin (it'd look nicer on Windows) -- but this is only available when the game's run in debug mode so you'll never see it as an end user. The game window itself looks the same on every platform.

The interactive bits of the game revolve around actors (things that do stuff, including the hero character and in-game NPC's). There are singleton actors that exist exactly once in the entire game world (this includes the hero(s) of the game), and the other actors may exist multiple times.

In the screenshot there is one singleton actor named "hero", and two dummy hero actors who aren't singletons but use the same sprites as the hero (simply because I didn't feel like making additional sprites yet).

The debug window there just lets you choose which actor you want to control, out of the list which shows every actor on every loaded map. And it works, and you can walk around as any of the three clones there.

I'm a day or two's work away from programming an event scripting system, which will make the game become more interactive than just walking around, and then I'll start trying to make an actual game with this engine. The rest of the details (weather effects and other nifty features like that) will come later, since I want to create a game and not just make an engine.

BTW, the graphics aren't going to suck as badly as in that screenshot. I'm using stock RPG Maker graphics just for development and will be replacing those, and programming an auto-tiling system so that the tiles will blend better and not be so square.

I needed to do this because I was testing something at work that involved an Asterisk server calling a softphone running on my Linux box, and it wanted me to record a voice prompt and then hang up. This computer didn't have a microphone installed, so I started looking for a way to fake the mic input and make it record an MP3 or something instead.

If your system is using PulseAudio (every recent Fedora and Ubuntu distribution does), the steps to follow are:

1) Open PulseAudio Volume Control

This is pavucontrol on the command line, and in Fedora is provided by the package pavucontrol.

Go to the "Input Devices" tab, and select "Show: Monitors" from the bottom of the window. If your computer is currently playing audio, you should see a bar showing the volume of the output:

The "Input Devices" tab showing monitors.

2) Start running an app that is recording audio, and go to the "Recording" tab and see if your app is listed.

In this screenshot I'm running Audacity and recording audio.

3) Click the input device button ("ALSA Capture from") and pick "Monitor of Internal Audio Analog Stereo")

The "Input Devices" tab showing monitors.

And that's pretty much it. If you see volume bars on the Recording tab now then it's probably working, and the recording app is now recording your audio output.

Here's a full desktop screenshot of me running `play audiodump.wav` (a WMA-to-WAV conversion of the Windows XP Welcome Music) in a terminal, the PulseAudio Volume Control running, and Audacity recording from the mic.

Click for bigger screenshot.

Why? To see if anybody else uses my computer when I'm not there, and to see what they were doing with it.

screenspy - Linux desktop monitoring daemon

Basically, you run this script as root, and it monitors your major hardware input devices for any activity. By default it watches /dev/console (which, on Fedora systems, seems to output data whenever there's keyboard activity), and /dev/input/mice (which is a common node for the collective input of any and all mice attached to a computer).

When it sees any activity at all on either of these devices (it doesn't care what the devices are doing, it just cares that they're active), it begins taking screenshots. If you use the keyboard or mouse for a little bit, and then stop for 2 seconds, it takes a screenshot. If you use the keyboard or mouse constantly and don't stop, it will take a screenshot every 5 seconds.

So it essentially creates a visual log of everything you were doing on the computer; every time you type, stop typing, type like crazy, move the mouse, stop moving the mouse... anything that happens, a screenshot is taken.

It uses scrot to take the screenshot, since this is the lightest-weight screen capturing program I could find. Using ImageMagick's import command is slow, and makes the computer beep, and GNOME's screensaver application can't run without showing a GUI window.

You can check it out here. You'll be required to edit the script in the "configuration" section though, at least to change the directory where it saves the screenshots to.

Since the script runs as root, the images it creates are naturally owned by root as well, and can't be deleted by the nonprivileged user, even if the user does manage to find the screenshots. Better yet, you can have the screenshots saved under root's home directory, keeping them completely out-of-sight for the user. And, to kill the script, you have to be root since it will be a root-owned process. +1 if your unauthorized users don't know your root password!

keylog - A Simple Keylogger

Actually, it doesn't store all keystrokes; instead, it stores what the user "intended" to type. That is, if a user begins typing a sentence and makes a typo and hits backspace a few times and then continues typing, what gets logged is what they actually ended up typing... you don't see their typo; when they hit backspace, the log buffer also deleted the last character it logged, before saving it to disk.

It separates what they type based on certain "divider characters," which includes Tab, Return and Enter. So as they fill out a web form, the script would log one line of text for each field they filled out as they tab through the form. Also, if they delay their typing for a few seconds it will dump the current buffer to the log file as well, so if they're a particularly slow typer, one "sentence" may span multiple lines in the log file.

I can't recommend using this keylogger for malicious purposes, it's just being uploaded for educational purposes only and should only be used as a personal desktop monitoring solution, if it should be used at all.

Source code: keylog.

The type of game I'll be making with it will be a 2D RPG type game, with a top-down perspective (think: Zelda, SNES-era Star Ocean, etc.). I feel that this type of game offers the most flexibility, having a wide-open game world where you can move your character in two dimensions.

I'm programming it in Perl, because I know Perl better than any other language (with Java coming in second place, but I'll avoid getting Java involved if I can help it). ;) However, it's highly possible that I'll need to switch languages down the line, so I'm future-proofing what code I am writing just in case any major changes need to happen.

For example, I like the model employed by Sierra and LucasArts when they made their games based on AGI (Adventure Game Interpreter) and SCUMM (Script Creation Utility for Maniac Mansion), respectively. Their game engines were programmed in who-knows-what language (likely C), but the games themselves--the scripts for dialog and interactions within the game--used a new, home-made programming language. This way, the game engine can be reprogrammed in a different language, and the existing games can "just run" on the new engine without any modification.

This is how ScummVM is able to run old SCUMM games; they've just re-implemented the SCUMM engine, and the existing games can "just run" on ScummVM without requiring them to be modified at all.

So, my game engine will be similar, using a new scripting language, so that if I have to scrap Perl in the future and go to Java, all I need to do is re-implement the engine in Java, and what game code I have written will "just work" on the new engine.

Now, as for the Perl stuff... I'm future-proofing my code against other Perl modules, too.

The engine runs out of a core Perl module, and it uses multiple "front-end plug-ins" to actually interact with the user. They're divided into three categories: Graphics Front-end, Sound Front-end, and Filesystem Front-end.

Graphics Front-end

Perl/Tk may be dated, and look ugly as hell on Unix, but if the Tk window only consists of a Canvas widget (which is what I'm planning for), you won't be able to tell. Compose a nice picture in a Canvas and it looks the same on all platforms.

Tk Canvas treats everything you draw in them as "objects", or sprites as far as my game will be concerned. It means that once you put an image in the canvas, you can move that image around later by its ID. SDL, on the other hand, is not sprite-based, but pixel-based, so to move a sprite you've already placed, you have to erase it and redraw it. Plus one for Tk.

Tk Canvas doesn't support layers, but it does support "implied layering"... that is, each object you place on the canvas gets an implicit Z-index that's one higher than the object you placed before it. This is the same as the default behavior in HTML. When you move sprites around after placing them, they'll either stay above or below other sprites, depending on the order the sprites were drawn. Therefore, by drawing sprites in the right order, layers can be simulated. SDL doesn't support layers either, so +1 for Tk here again.

At any rate, the graphics front-end won't be too integrated with the core game engine. Instead, it will register callbacks to the engine, so Tk will say "when you want me to draw a sprite, call this function of mine and I'll take care of it."

This way, the core engine just tells the graphics front-end what to do: what sprites to draw, where to move them to, etc. and the front-end just does as it's told. This way, the internals of Perl/Tk don't get caught up in the core engine; if I need to ditch Tk and use SDL instead, I just need to make SDL respond to the same commands from the core as Tk does and all is well.

Sound Front-end

Tk doesn't have any audio support of any kind. But fortunately, there are other Perl modules that can handle audio. For Windows computers, there is Win32::MediaPlayer, and for Linux there is GStreamer.

Win32::MediaPlayer and GStreamer both can play whatever codecs the user has installed. On Windows this means it can play mp3, wav, even midi music out-of-box. On Linux it means it can play wav, ogg, and other formats that aren't patented. If the Linux user installs MP3 support, though, GStreamer can play mp3 files too!

Similar to the graphics front-end, the sound front-end registers callbacks. When the core wants to play a sound effect, it calls a method in the sound front-end to do so, and the sound front-end does it.

If I stick with open audio formats, I can have an SDL audio front-end to get sound for Mac OS X too, since there isn't yet a Perl module to play sound natively on OS X.

Filesystem Front-end

With such an archiving algorithm, the game could store all its data files (images and scripts) into a read-only archive, which only the game knows the password to. This stops the players from getting in there and seeing sprites for characters in the game they haven't seen yet themselves, and especially to prevent them from modifying the game's script if they do manage to get into the archive.

(By the way, my game engine will probably be released as open source software, so you'll be able to make your own games with it; just stay out of my games' files!)

Until Archive::Tyd is completed though, the game will just read files off the filesystem directly. But the filesystem front-end is there so that in the future, I can replace it with one that reads files out of Tyd archives instead.

Anyway, I've already gotten a few hundred lines of code written, and the general framework for the engine is already working (abstracting away the graphics front-end from the core, for example). I've recently completed a tileset handling Perl module which I intend to use for it.

When I get more work done, and especially when there's a playable demo of the game engine, I'll probably make a small website for it as a subdomain of kirsle.net.

This blog post is primarily for my own reference, to avoid having to dig through the manual to look up the occasional edge case.

How to use SSH to do port forwarding. These assume you're on a Unix-like system (Linux or OS X) and not using some lame Windows client like PuTTy.

Forwarding Remote Ports to You

ssh -R 9022:localhost:22 remotehost.com

By default the remote host only would make port 9022 available on the loopback address, so from your home PC you can do ssh -p 9022 localhost and connect to it, but you can't do e.g. ssh -p 9022 remotehost.com and connect to it from somewhere else on the Internet.

To open the port on all interfaces (thus making it available on the internet too):

ssh -R *:9022:localhost:22 remotehost.com

Forwarding Local Ports to Remote

ssh -L 8080:localhost:80 remotehost.com

Then you open Firefox and go to http://localhost:8080/ and yer in.

Another example: you have a VNC (remote desktop) server running on remotehost.com, but the VNC protocol itself is insecure, and you don't want your password being sent across the network in clear text to log in. So, you need your VNC traffic to be encrypted via SSH.

Here, remotehost.com is listening on port 5900 (the VNC port). You want to open a port on your local computer to the same number, so that you connect a VNC client to "localhost:5900" and it really connects you to "remotehost.com:5900" over a secure SSH tunnel:

ssh -L 5900:localhost:5900 remotehost.com

"Penetrating" the Remote Network

ssh -L 5900:10.10.1.101:5900 remotehost.com

This opens up a listening port 5900 on my local (office PC) -- the first 5900 in the command -- and if I connect to it, it will use remotehost.com as a jumping off point to connect onward to 10.10.1.101:5900 (the laptop with a private LAN IP address on the remote network).

Then I point my VNC client at "localhost" and I end up with remote desktop on the laptop.

Using SSH as a Secure SOCKS 5 Proxy

ssh -D 8080 remotehost.com

Additionally, this can be used to reach other devices on the remote server's LAN that you otherwise couldn't get to. For example, turn on your proxy settings in Firefox and you can navigate to http://192.168.1.1/ to log into the router from the remote LAN (as opposed to a router on your local LAN). The SOCKS 5 proxy would cause Firefox (or any other app configured to use it) to use "remotehost.com" as a jumping off point into the internet, so it can connect to other local network devices on its end just the same.

First, this is what I mean about serial numbers. Suppose you're using a Windows system, have a floppy disk at drive A:/ and a regular USB flash drive at E:/, and you run these commands in the command prompt:

C:\>vol E:
Volume in drive E is CRUZER
Volume Serial Number is 955C-59BF

C:\>vol A:
Volume in drive A has no label.
Volume Serial Number is EC2B-36AF

According to The Wikipedia, the serial number (ID) is kept in two different places on the partition depending on the version of FAT being used.

In FAT12 and FAT16 (used with floppy disks), the ID begins at byte offset 0x27 (39 in decimal); in FAT32 (used with flash drives and external hard drives), the ID begins at 0x43 (67 in decimal).

So, with the handy dd utility that comes standard on pretty much any Unix-like system, you can extract this information and display it. Here are a couple of one-liners you can run in a Unix terminal. I'll explain how they work afterward.

# For FAT32 filesystems (modern flash drives)
dd if=/dev/sdb1 skip=67 bs=1 count=4 | hexdump -v -e '1/1 "%02X" " "' | xargs perl -e '@_=@ARGV; print "Serial Number: $_[3]$_[2]-$_[1]$_[0]\n"'

# For FAT12/16 filesystems (old floppy drives)
dd if=testfloppy.img skip=39 bs=1 count=4 | hexdump -v -e '1/1 "%02X" " "' | xargs perl -e '@_=@ARGV; print "Serial Number: $_[3]$_[2]-$_[1]$_[0]\n"'

If you're going to be using a physical device like in my first command, you need to run the command with root privileges (regular users can't read directly from the device node). My second example (using an image file) can be run as a regular user, however.

These commands printed in the terminal for me:

(for the flash drive)
4+0 records in
4+0 records out
4 bytes (4 B) copied, 3.3445e-05 s, 120 kB/s
Serial Number: 955C-59BF

(for the floppy image)
4+0 records in
4+0 records out
4 bytes (4 B) copied, 3.1551e-05 s, 127 kB/s
Serial Number: EC2B-36AF

dd if=/dev/sdb1 skip=67 bs=1 count=4
hexdump -v -e '1/1 "%02X" " "'
xargs perl -e '@_=@ARGV; print "Serial Number: $_[3]$_[2]-$_[1]$_[0]\n"'

The hexdump command takes the 4 binary bytes and displays them in hexadecimal. On my flash drive, it looks like this: BF 59 5C 95. Note that the hex codes are out of order; Windows shows them as 955C-59BF - basically, the reverse of what hexdump shows. Hexdump is showing the correct order; Windows and DOS reverse them when they show you the serial number.

So, we run it through xargs (which turns the four hex numbers into four separate parameters) and sends them to a quick Perl script, which prints out "Serial Number:" and puts the hex codes in the correct order, to give the same result as Windows and DOS.

One could use this information to make a vol command for Unix. If the command checks other places in the filesystem headers to determine the version of FAT, it could automatically use the correct byte offset and get the serial number from both floppy disks and flash drives.

This is a re-do of my previous blog post about Perl upload progress bars - my previous approach was completely wrong. By the time $q->upload(); is used, the file has already been received and stored in a temporary location, and so the "progress bar" in this case is really just gauging how fast the server can copy the file from one place to another on its hard drive.

So this post is how to really do a real working file uploader progress bar in Perl.

The basic steps required to do this include:

• Set an onSubmit handler on your form that will set some ajax requests running in the background. The ajax will continuously poll your CGI script to see how the upload is going.
• The upload CGI script needs to set an "upload hook" that CGI.pm calls repeatedly as the file is being received by the server. This hook can store the current progress of the upload somewhere, so that when the ajax pings it for the status, it can report the status.
• Besides that everything else works the same as for a non-progress-bar upload. You can still do $q->upload(); and everything like before.

The source code needed for this is still amazingly short and concise, compared to the source codes you'll get when you download solutions from elsewhere.

Implementing this doesn't require any special Apache handlers or mod_perl or anything fancy like that.

Sources:

• upload.html

<!DOCTYPE html>
<html>
<head>
<title>Upload Test</title>
<style type="text/css">
body {
 background-color: #FFFFFF;
 font-family: Verdana,Arial,sans-serif;
 font-size: small;
 color: #000000
}
#trough {
 border: 1px solid #000000;
 height: 16px;
 display: block;
 background-color: #DDDDDD
}
#bar {
 background-color: #0000FF;
 background-image: url("blue-clearlooks.png");
 border-right: 1px solid #000000;
 height: 16px
}
</style>
</head>
<body>

<h1>File Upload Test</h1>

<div id="progress-div" style="display: none; width: 400px; margin: auto">
        <fieldset>
                <legend>Upload Progress</legend>
                <div id="trough">
                        <div id="bar" style="width: 0%"></div>
                </div>
                Received <span id="received">0</span>/<span id="total">0</span> (<span id="percent">0</span>%)
        </fieldset>
</div>

<div id="upload-form" style="display: block; width: 600px; margin: auto">
        <fieldset>
                <legend>Upload a File</legend>
                <form name="upload" method="post" action="upload.cgi" enctype="multipart/form-data" onSubmit="return startUpload()" id="theform">
                <input type="hidden" name="do" value="upload">

                <table border="0" cellspacing="0" cellpadding="2">
                        <tr>
                                <td align="left" valign="middle">
                                        Session ID<span style="color: #FF0000">*</span>:
                                </td>
                                <td align="left" valign="middle">
                                        <input type="text" size="40" name="sessid" id="sessid" readonly="readonly">
                                </td>
                        </tr>
                        <tr>
                                <td align="left" valign="middle">
                                        File:
                                </td>
                                <td align="left" valign="middle">
                                        <input type="file" name="incoming" size="40">
                                </td>
                        </tr>
                </table><p>

                <input type="submit" value="Upload It!"><p>

                <small>
                <span style="color: #FF0000">*</span> Randomly generated by JavaScript. In practice this would be
                randomly generated by server-side script and "hard-coded" into the HTML you see on this page.
                </small>
        </fieldset>
</div>

<div id="debug"></div>

<script type="text/javascript">
// a jquery-like function, a shortcut to document.getElementById
function $(o) {
        return document.getElementById(o);
}

// called on page load to make up a session ID (in real life the session ID
// would be made up via server-side script and "hard-coded" in the HTML received
// by the server, thus it wouldn't require javascript at all)
function init() {
        // Make up a session ID.
        var hex = [ "0", "1", "2", "3", "4", "5", "6", "7", "8", "9",
        "A", "B", "C", "D", "E", "F" ];
        var ses = "";

        for (var i = 0; i < 8; i++) {
                var rnd = Math.floor(Math.random()*16);
                ses += hex[rnd];
        }

        $("sessid").value = ses;

        // we set the form action to send the sessid in the query string, too.
        // this way it's available inside the CGI hook function in a very easy
        // way. In real life this would probably be done better.
        $("theform").action += "?" + ses;
}
window.onload = init;

// This function is called when submitting the form.
function startUpload() {
        // Hide the form.
        $("upload-form").style.display = "none";

        // Show the progress div.
        $("progress-div").style.display = "block";

        // Begin making ajax requests.
        setTimeout("ping()", 1000);

        // Allow the form to continue submitting.
        return true;
}

// Make an ajax request to check up on the status of the upload
function ping() {
        var ajax = new XMLHttpRequest();

        ajax.onreadystatechange = function () {
                if (ajax.readyState == 4) {
                        parse(ajax.responseText);
                }
        };

        ajax.open("GET", "upload.cgi?do=ping&sessid=" + $("sessid").value + "&rand=" + Math.floor(Math.random()*99999), true);
        ajax.send(null);
}

// React to the returned value of our ping test
function parse(txt) {
        $("debug").innerHTML = "received from server: " + txt;

        var parts = txt.split(":");
        if (parts.length == 3) {
                $("received").innerHTML = parts[0];
                $("total").innerHTML = parts[1];
                $("percent").innerHTML = parts[2];
                $("bar").style.width = parts[2] + "%";
        }

        // Ping again!
        setTimeout("ping()", 1000);
}
</script>

</body>
</html>

• upload.cgi

#!/usr/bin/perl -w

use strict;
use warnings;
use CGI;
use CGI::Carp "fatalsToBrowser";

# Make a file upload hook.
my $q = new CGI (\&hook);

# This is the file upload hook, where we can update our session
# file with the dirty details of how the upload is going.
sub hook {
        my ($filename,$buffer,$bytes_read,$file) = @_;

        # Get our sessid from the form submission.
        my ($sessid) = $ENV{QUERY_STRING};
        $sessid =~ s/[^A-F0-9]//g;

        # Calculate the (rough estimation) of the file size. This isn't
        # accurate because the CONTENT_LENGTH includes not only the file's
        # contents, but also the length of all the other form fields as well,
        # so it's bound to be at least a few bytes larger than the file size.
        # This obviously doesn't work out well if you want progress bars on
        # a per-file basis, if uploading many files. This proof-of-concept only
        # supports a single file anyway.
        my $length = $ENV{'CONTENT_LENGTH'};
        my $percent = 0;
        if ($length > 0) { # Don't divide by zero.
                $percent = sprintf("%.1f",
                        (( $bytes_read / $length ) * 100)
                );
        }

        # Write this data to the session file.
        open (SES, ">$sessid.session");
        print SES "$bytes_read:$length:$percent";
        close (SES);
}

# Now the meat of the CGI script.
print "Content-Type: text/html\n\n";

my $action = $q->param("do") || "unknown";
if ($action eq "upload") {
        # They are first submitting the file. This code doesn't really run much
        # until AFTER the file is completely uploaded.
        my $filename = $q->param("incoming");
        my $handle   = $q->upload("incoming");
        my $sessid   = $q->param("sessid");
        $sessid     =~ s/[^A-F0-9]//g;
        $filename =~ s/(?:\\|\/)([^\\\/]+)$/$1/g;

        # Copy the file to its final location.
        open (FILE, ">./files/$filename") or die "Can't create file: $!";
        my $buffer;
        while (read($handle,$buffer,2048)) {
                print FILE $buffer;
        }
        close (FILE);

        # Delete the session file.
        unlink("./$sessid.session");

        # Done.
        print "Thank you for your file. <a href=\"files/$filename\">Here it is again.</a>";
}
elsif ($action eq "ping") {
        # Checking up on the status of the upload.
        my $sessid = $q->param("sessid");
        $sessid =~ s/[^A-F0-9]//g;

        # Exists?
        if (-f "./$sessid.session") {
                # Read it.
                open (READ, "./$sessid.session");
                my $data = <READ>;
                close (READ);
                print $data;
        }
        else {
                print "0:0:0:error session $sessid doesn't exist";
        }
}
else {
        print "0:0:0:error invalid action $action";
}

You can download my full proof-of-concept test below:

• upload.tar.gz (6.6K)

Notice: this code is called "proof of concept"; it is NOT production-ready code. You should NOT download this if all you want is a complete plug-and-play solution you can quickly upload to your web server to get file uploading to work. I wrote this code only to show how to make a file uploader in the simplest way possible; this is useful for developers who only needed to know how this is done and who will write the code themselves to develop their production-ready file uploader.

If you want to treat this as a plug-and-play solution, I'm not your tech support about it. The code was never meant to be secure or useful to allow the general public to upload files through it. Session IDs are made up client side for example which is a bad idea in real use case scenarios, etc.

Sometimes I start a graphical app from within a terminal, for instance because opening the app via a double-click doesn't do anything (for instance, if a Wine app won't start because of a missing DLL file - I can only see this error message if I try to start the app from within a terminal).

But then I want to close the terminal but still keep the graphical app running. Closing the terminal would kill the graphical app too, unless you can somehow detach it completely from the terminal.

For the example I'll run gedit, GNOME's default text editing program, from a gnome-terminal terminal window.

1) Start the graphical app from the terminal

$ gedit

2) Temporarily suspend the process with Ctrl-Z

^Z

The terminal will tell you which "job number" it has given to the suspended process. This will usually be 1 unless you have other jobs running:

[1]+ Stopped gedit

$ bg 1

4) Disown all jobs from this terminal

$ disown -h

This can also be used to detach command-line applications, too - especially if it will be a long-running process (for example, to back up a large folder over the network) and when you don't really care about its output; you just want it to continue running until it's done, but you need to close your terminal.

With no 3D acceleration, the results are the same as before: a mostly black screen, can't really do very much with it. With VirtualBox's 3D acceleration enabled, it's similar to the result I had before... very frequently the majority of the desktop (besides a box around my desktop icons) and the whole shapes of windows have that "striped" blue texture all across them.

I say most of the time because it's sometimes possible to get a window to show its true contents and become usable by dragging it around and playing with it for a bit, but the effects usually don't last very long before the window loses its textures again. The scale effect of bringing up the main menu in GNOME Shell usually fscks up all windows you have open again.

But the reason for this particular blog entry is that I also decided to test Compiz Fusion inside VirtualBox, on Fedora 12, under the same conditions as the GNOME Shell. I couldn't do this before because the beta version of Fedora 12 had some dependency issues, and Compiz conflicted with GNOME Shell; they couldn't co-exist together.

In Fedora 12 they can co-exist, and the Desktop Effects GUI window gives options to select either Compiz or GNOME Shell. Anyway, here's a screenshot. This is a real screenshot of Fedora 12 running in VirtualBox with full desktop effects active, including the 3D Cube effect.

Click for a full-size version of this screenshot