A quick fix would be just to increase the title bar font size in the appearance settings, but this would result in larger-than-normal title bar text if you were to disable the Compiz effects. This smaller text is actually a slight bug, and can be fixed by entering the command compiz --version in the terminal. After doing this, you’ll see the title bar text increase back to the normal size - invoking compiz seems to cause the manager to reset the size back. However, the changes do not persist after a reboot or after logging back in and it’s impractical to have to do this every time.

As with all tedious tasks, the best way to accomplish them is with a script. Here’s a nice workaround.

It turns out other people were having the same problem as I. Searching lead to a thread which suggested the compiz --version command and another which suggested using a bash script.

Combining the two, I came up with this. Simply follow these steps and the fix should automatically be enabled after every time you login.

1. Make the script file

   Create a file and name it something like “compiz-fix”. Open it in your favourite text editor (nano is my current favourite, after dealing with systems at work that only have vi).

   Enter the following lines:

   sleep 10
   compiz --version

   These two commands enable the fix to work. Here, we’re waiting/sleeping for 10 seconds after login to make sure that Compiz has time to start up - or else the compiz --version command will have no effect. You may have to change the sleep period on your system depending on how long it takes to login, but 10 seconds should be enough.

2. Make the script executable

   This is straightforward, simply open a terminal window and chmod +x {script-file-name}.

3. Make the script run at startup

   In Linux Mint this is done by going to Preferences -> Sessions and then adding an entry to the “Startup Programs” tab.

   The command should be something like this:

   bash /home/<user_name>/compiz-fix

   This is assuming you’ve saved the “compiz-fix” script under your home directory.

And then you’re done! You should now notice the proper title bar text size every time you login, as seen below:

This fix was used in Linux Mint 4.0 (Darya) but should also apply to Ubuntu 7.10 (Gutsy Gibbon), upon which it is based and possibly also Ubuntu 8.04 (Hardy Heron) and Linux Mint 5.0, assuming the problem hasn’t already been fixed.

Nothing appeared wrong with the mouse and plugging in the receiver did cause Windows to automatically detect it as a mouse. I was about ready to contact the seller and request a refund but some searching turned up a helpful forum thread with users describing the exact same problem as me. Thankfully, the fix is very simple: Use the Logitech SetPoint Connect Utility to re-synchronize/reconnect your mouse with the receiver.

Mismatch

Usually, if a Logitech mouse cannot connect with the receiver automatically, it is a case of mismatch between the mouse and the receiver. Usually, this is solved by pressing the “Connect” or “Reset” button on the bottom of the mouse, which causes the mouse/receiver to synchronize back together on the same channel. Most of the time, the mouse and receiver are already paired together at the factory so there’s no need for this process.

However, with the VX Revolution, there is no reset button on the mouse. (The power or on/off button doesn’t seem to have a “reset” effect) Thus, to “reset” the VX Revolution to get it to connect to a receiver you have to press a predefined and cryptic sequence of buttons on the mouse. This information is conveyed to you when you use the Logitech SetPoint Connect Utility:

After carrying out that complicated sequence of steps, the VX Revolution worked! I should note that I’m not sure if you even need to install SetPoint in order to carry out the reset/reconnection procedure. Though, it may be worthwhile thanks to some nice additions available for SetPoint that really unleash all of your mouse’s potential.

After seeing glowing recommendations for the heuristic-based ThreatFire anti-malware app from PC Tools, I decided to install it to complement my antivirus scanner and other anti-spyware tools such as Spybot-S&D and Ad-Aware.

Initially, it worked fine. While I don’t know how much protection it really added, it was intuitive, easy to configure and didn’t slow down my system like many other real-time scanners might have. However, I ran into some trouble with my web development environment, consisting of Apache, MySQL and PHP (in the form of XAMPP) that I could only attribute to ThreatFire’s presence.

The symptoms

With ThreatFire installed and enabled, requesting any pages from Apache that would result in MySQL access took painfully long. Accessing static pages or scripts that did not use the MySQL database did not hang. At first, I thought it was a problem with the application/scripts I was working on, but other popular third-party scripts, such as phpMyAdmin, were also slow or unresponsive. The server appeared to “hang” for about 10-15 seconds before producing any response. This was on a local server.

I tried several different courses of action, such as:

• Enabling logging of slow queries with the --log-slow-queries option.
• Adding the MySQL binaries (mysqld.exe and mysqld-nt.exe) to the ThreatFire exclusion/ignore list
• Reinstalling XAMPP

None of these worked. In particular, logging slow queries did not produce any logs, which seemed to indicate that MySQL was hanging even before the queries were executed. Surprisingly, logging the execution time of PHP scripts did not seem to indicate any problems either. The queries I was executing and that datasets I was working on were also small and unlikely to be a contributing factor - any query, no matter how simple, seemed to hang.

When I suspended or removed ThreatFire, the problems immediately went away. Strangely, as I noted above, adding the MySQL binaries to the exclusion list did not help. What was more interesting is that ThreatFire did not popup any warnings. Usually, when “suspicious behaviour” is detected, ThreatFire will prompt you for a decision. I did not notice any of this.

ThreatFire is not bad

The purpose of this is not to bash ThreatFire; it’s clearly a good tool and has definitive advantages, but just may not be well-suited to development environments where multiple servers are running. I also wanted to provide this information to anyone else who may have been struggling with a slow/unresponsive server because of the same situation as mine.

I was working on some PHP development recently with my editor of choice, UltraEdit. In my view, UltraEdit is the text editor to use. (Assuming you’re in a Windows environment) It basically has everything I need, and is especially well-suited for web development. Where it may fall short is for developing desktop applications, as then a specific IDE may offer more features, though UltraEdit can be configured to work with compilers and so forth. (UEStudio is probably a better choice in this case)

While I don’t want to argue about the merits of UltraEdit, as people’s passion for their text-editors seem to border on the religious, I wanted to point out a potential solution to a code highlighting problem some of you may have encountered when developing with PHP 5.

Missing functions in the function list

UltraEdit supports code highlighting through its wordfile.txt file, which stores the configuration information for highlighting different languages based on their file extension(s). This file can be found in the directory you installed UltraEdit to, or it can be accessed via the configuration menu. This file determines what language highlighting options show up in the “View As” list. It also allows the function list to display a list of functions/methods in the current file by defining what strings are function declarations.

PHP 5 supports classes and objects better than previous versions. In particular, setting the visibility of members is now supported. So, you can define, for example, methods to be public, protected or private. (The default is public)
However, when using one of these keywords to define a method, the method seemed to disappear from the function list. This was with using UltraEdit 12.10.

Modifying the UltraEdit wordfile file

You need to get the PHP 5 word file and then add it to your word file. Open up wordfile.txt (in UltraEdit, of course!), and delete the entire definition block previously used for PHP. It’ll start at a line of text that begins with:

Lx"PHP"

Where ‘x’ is a number. The end will be just before the next language definition, which will be something like:

L(x+1)"LanguageName"

You need to delete everything starting from the the first line to just before that last line. Then, you can copy and paste in the contents of the PHP 5 word file, changing the first line’s L20 to Lx, where ‘x’ was the number as before. Public, protected and private-declared methods should now show up in the function list.

UltraEdit and Regular Expressions

The UltraEdit word file is actually a bunch of regular expressions that tell UltraEdit which lines are function declarations (among other things) so that it can populate the function list with them. In the past, it would appear that the wordfile doesn’t use Unix-style RegExps but instead uses some sort of UltraEdit format. I don’t know if this behaviour has been changed since then, but looking at the word file, it appears that this is still the case.

You see, UltraEdit has its own style of regular expressions. While you have the option of searching within text files using either UltraEdit’s style, Unix, or Perl-compatible regular expressions, it seems as though the word file language definitions must use UltraEdit-style regular expressions.

The solution is nicely outlined in the [H]ard|OCP Forums, where it’s aptly known as the “Benny Hill Effect”. Turns out that the problem has to do with power state management issues and how they affect the read time stamp counter instruction (RDTSC), which is used for timing. I followed the guide, and it fixed my problems.

The games that I noticed the timing issues in were NFS:MW, Rome Total War and GTA San Andreas. This is by no means a complete list of games that are affected by this issue. Some of my own observations and suggestions for fixing the problem:

• I installed the “AMD Dual-Core Optimizer”, but found that while it fixed some of the jerky games, it caused problems such as video distortion in other games
• So, I uninstalled the fix, and strangely, the jerkiness in games remained gone and all previously caused problems were removed as well
• This may have been the result of the “/usepmtimer” switch being added to the “boot.ini” file (This may have been all that was needed)

Regardless, the guide in the [H]ard|OCP Forums is quite extensive, and you should be able to solve any of your dual-core related gameplay issues by reading it.

The cause

The cause of this interference is from the PC speaker, or rather, how the pass-through of the PC speaker to the onboard audio, was implemented. The onboard audio is automatically setup to receive PC speaker signals from your motherboard and route them to the outputs. This path was not very well isolated and as a result interference (EMI) from other system components can creep in, resulting in the noisy output from your speakers.

Solution: Mute it

The solution is to mute the PC speaker output on the onboard Realtek audio. This can be accomplished in two ways, depending on your situation and needs.

The first is in software, and requires that you have the Realtek audio drivers installed, not the default nForce audio drivers, despite the fact that they work well with the A8N32-SLI Deluxe, an nForce 4 board. You can grab the Realtek drivers from Asus’ site or a later version from Download.com.

1. Open volume properties (either by clicking the systray icon or through Control Panel)
2. Click on Options > Properties and make sure that “PC Speaker” is checked, then click “OK”
3. Now, mute the PC Speaker input

This should have removed or reduced most of the sound interference - this worked well for me. If not, try muting other inputs, such as AUX or Line In, that you may not be using.

Getting rid of interference while using NVidia’s drivers

The second method, if you choose to stick with NVidia’s nForce audio drivers, is a bit more complicated. For some reason, the nForce audio drivers do not give an option to mute the PC speaker. I am guessing this was because the nForce audio drivers need to work with a variety of nForce motherboards, so they have to stick with something that’ll work with a reference design. Since not all nForce motherboards might use the Realtek audio and may not use the PC speaker input functionality, it could be problematic to code the drivers for this.

Thus, you’ll have to disable the PC speaker in hardware. This is done by opening your case and disconnecting the PC speaker connector from the motherboard. This seems to break the connection to the PC speaker input to the onboard audio, removing most of the interference. This also worked for me. While you’re inside of your case, you may want to clean out some of the dust like I did.

Which method is better?

At the surface, it may seem like the software solution, using Realtek’s drivers just to disable the PC speaker input, is better and easier. While it is easier, I didn’t really like the audio control panel provided by Realtek. While it had plenty of features, I just didn’t like the look & feel, nor did I appreciate the lack of an equalizer.

The NVidia control panel, by contrast, looks more polished and offers a fully-featured graphic equalizer, that not only shows the different frequency ranges but also each channel. It also has a convenient “Night Mode” that automatically reduces bass and dynamic range for a quieter listening experience.

I was living with this problem for over eight months, and just assumed it was because of the low-cost onboard audio. I was at the point of buying a separate soundcard just to alleviate the problem, before I stumbled across the solution in several forums. It seems like quite a lot of other people have experienced this trouble. Hopefully Asus won’t let this happen in any more of their motherboard designs. However, Asus motherboards have always been rock-solid in terms of stability for me, so I don’t think I’ll switch anytime soon.

Since the major use of Internet is for accessing websites, the “www” prefix shouldn’t be needed anymore. It is an archaic holdover from a previous era, one where browser wars meant IE vs. Netscape and where Geocities was the place to be. Thankfully, the folks over at no-www have been aiming to improve this for some time.

So what’s the big deal?

Well, it’s not such a big deal, more just a pet peeve of mine. Most sites out there are thankfully configured well enough so that navigating to “domain.com” just redirects you to “www.domain.com” with no damage done. However, some servers are setup so that navigating to “domain.com” doesn’t work, and this forces you to type in the “www” subdomain before. This really doesn’t make sense in today’s world.

In my opinion, all websites should be set up with the no-www version as the default. Using the “www” subdomain should redirect you to the no-www version, with no harm done. This is known as Class-B compliance, according to the no-www folks, and it’s probably going to be the best way to go for some time, since many people still use the “www”, after having the phrase drilled into their heads during the late 90’s.

So, how to fix it?

If you’ve signed up for hosting from a provider, chances are they’ve already implemented some sort of compliance, but not the optimal type. For example, most hosting providers will automatically redirect the no-www request to the www one. So, under this configuration, someone entering “domain.com” would be redirected to “www.domain.com”. No big deal, but things could be better. After all, the no-www version is shorter and thus requires less typing and less space. Good if you want to save a few cents on your business cards.

Fixing it is a simple effort that takes a minute or so. All you have to do is edit the .htaccess file in the root of your website, if you’re using Apache. Here’s the following directive I’m using.

# BEGIN no-www
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.unitstep\.net$ [NC]
RewriteRule ^(.*)$ http://unitstep.net/$1 [R=301,L]
</IfModule>
# END no-www

The RewriteRule uses a 301 - this is a special HTTP code used to tell of a permanent redirection. Browsers and search engines crawling your site will interpret this as an instruction that your website has permanently moved to the non-www address. This is most important for search engines, so that they know that the no-www version is not just a duplicate or different website than the previous www version. The 301 instruction tells them that the old www version doesn’t exist anymore, and it has been moved to the no-www address.

Taking it a step further, you could also redirect any subdomain to just the root. For example, I also own the domain “peterchng.com”, and wanted to redirect any request to that address, subdomains included, to my main site. Here’s the directives I used.

# BEGIN peterchng.com FORWARD
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_HOST} ^(([a-zA-Z0-9]+)\.)*peterchng\.com$ [NC]
RewriteRule ^(.*)$ http://unitstep.net/$1 [R=301,L]
</IfModule>
# END peterchng.com FORWARD

Go ahead, try typing in “who.the.heck.is.peterchng.com” into your browser, and you’ll see it redirects right back to this site.

You’ll want to be careful when using these directives - if you actually do have separate websites on different subdomains, they’ll be inaccessible if you do this! I’ve been using it until I find a use for peterchng.com - or a different use for unitstep.net.

Why all the trouble then?

With all the trouble of going of removing the “www” you may wonder why it was ever used in the first place. Well, IIRC, in the early years of the Internet, websites or HTTP wasn’t the main use. Other services/protocols such as gopher, FTP and telnet were probably a lot more dominant. So, it made sense to set up a separate subdomain that would be used to accept HTTP connections. This would make it easier for users to distinguish between the services offered from a particular domain. However, since HTTP has grown to eclipse those traditional services, the use of www is almost superfluous nowadays.

I finally decided to take a look at the heatsink/fan area - it didn’t look like it had a lot of dust in it, but then again, I had been lazy. Not any more - I took a can of compressed air and aimed straight at it. Immediately, a huge puff of extremely fine dust spurted out and I had to cover my face. I then proceeded to spray out the rest of the dust until no more was seen. Now, the laptop runs like it was brand new. If you have a laptop that’s getting very hot, invest in a can of compressed air, but make sure you’re in an area that you feel comfortable scattering with very fine dust particles.

The issue (Matlab closing right after start-up) stems from Matlab (at least this version, the newer versions might not be affected) not “recognizing” the processor string for newer AMD Athlon 64-based processors; in my case, I had an Athlon 64 X2 3800+. Matlab relies on different Basic Linear Algebra Subprograms (or BLAS) routines for different types of CPUs, and these are stored in different DLL files.

The BLAS file responsible for telling Matlab which DLL file to use for what type of CPU is located at:

%MATLAB7%\bin\win32\blas.spec
(where %MATLAB7% is the path to your Matlab installation)

To fix the problem, open up the file in a text-editor, and add the following two lines to the bottom:

AuthenticAMD Family 15 Model 12 atlas_Athlon.dll # Athlon 64 (Newcastle)
AuthenticAMD Family 15 Model * atlas_Athlon.dll # AMD64

This will tell Matlab to use the proper DLL file with your newer AMD-64-based CPU, instead of apparently defaulting to using a Pentium DLL file when an unrecognized CPU is detected.

More on the problem

As mentioned, the problem stems from the CPU being unrecognized by Matlab’s configuration file. All CPUs have some sort of identifier string, and Matlab uses this to determine what DLL file to use. When an unrecognized CPU string is detected, it apparently defaults to using a Pentium DLL file; this results in Matlab crashing when it’s run on an AMD-64-based CPU, and results in the crash-on-start behaviour.

Why the different DLL files for different CPUs? My guess is that the BLAS, upon which Matlab is based, are optimized or made to work better with select CPUs. It should be noted that these problems may not be experienced if you’re running a more current version of Matlab.

I did a little more searching and found this forum thread over at the Matlab website, where a different fix for the same problem is presented. It involves setting a Windows environment variable instead of editing the blas.spec file, but should do the same thing; I haven’t tried it. This other forum thread also details a similar procedure.

Hope this helps in fixing any Matlab ailments you might have had, because running into a problem like this can be frustrating as heck when you need to have an assignment done for tomorrow!

Update

I’d just like to say that a dual-core setup totally rocks. It’s awesome to be able to still play CS:S while running a Matlab simulation.

However, this can create problems if you want to create password-protected directories. Accessing them sometimes doesn’t work because of WordPress’s .htaccess file, however this isn’t a WordPress problem per se, but rather a problem with how Apache has been set up. I ran into this problem - I tried accessing a password-protected directory that I knew had been set up properly, but I kept getting a 404 error and was redirected to my WordPress theme’s 404 page. After a little bit of searching over at the WordPress support boards, I found some solutions that were sort of messy, involving editing WordPress files or adding a lot to the .htaccess file.

However, after looking for a bit more, I found this page, where the author outlines his fix; but later on a comment posted to his site provided me with the fix I wanted - something simple. Though that site deals with TextPattern, another blogging platform, apparently it handles requests in a similar manner to WordPress.

The problem lies with improperly set (usually non-specified) ErrorDocument directives. In this case, the responsible error codes are 401 (Unauthorized) and 403 (Forbidden). These directives are used to tell Apache what document to send or display to the user when each of these error codes are encountered. If these are set to point to a non-existant file, WordPress ends up handling the request - which in these cases, it treats just like a 404. When you try to access a password-protected resource, Apache first sends a 401 (Unauthorized), as a challenge to provide the proper credentials (login/password); if the error directive for this points to non-existant file, then the request is improperly passed on to WordPress and then treated like a 404 here.

To fix it, you need to specify the error directives in your root .htaccess file, which if you have WordPress in the root, is the same file that WordPress uses. If you open it up, you should find WordPress’ rules in there, which will look something like this

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

Add the following lines to the .htaccess file.

ErrorDocument 401 /<PATH_TO_ERROR_DOCS>/401.html
ErrorDocument 403 /<PATH_TO_ERROR_DOCS>/403.html

Where 401.html and 403.html are the pages you want shown when each of those respective errors are encountered. These should be static pages. (eg. not server-side scripts) This fix worked like a charm for me.