DrTebi's Blog

Converting Brainstorms to Blogs

Monday, March 23, 2015

Yahoo Search for Audacity links directly to Spamware

I was shocked today when I wanted to download Audacity for Windows and ended up with some "COMODO GeekBuddy" spamware. I admit I acted a bit to fast, and didn't realize that the first search result on Yahoo Search was actually not the official website of the Audacity Audio Editor.

However, Yahoo did not only list the wrong page as the first result, it also marked it as the "Official Site":

Screenshot of Yahoo Search result for "Audacity"

Audacity.com is not the official site of the Audacity Audio Editor.

Here is the correct URL for the official, and I mean the real official home page of the Audacity Audio Editor:


This is just outrageous. How can this slip through "Quality Control" of the Yahoo ad department?

Removing the unwanted spamware turned out to be a nightmare as well, as it apparently installs all kinds of add-ons for Internet Explorer, Firefox etc., and refuses to properly uninstall.

No thank you, I don't let anyone trash my system like that, not even my Windows install which I hardly ever use.

I reformatted and removed the windows drive, and went back to my Linux System on the primary disk.

I removed Yahoo Search from my search engines in Firefox. Goodbye Yahoo!

This was a good reminder why switching to Linux many years ago was the right decision.

Monday, December 10, 2012

Changing DPI setting on Gnome 3.4

The following post outlines the steps I took to change the hard-coded DPI of 96 on Gnome 3.4 to my desired DPI.

The problem and why one would want to go through the trouble

My monitor (an IBM T221) has an extreme resolution... 3840x2400 pixels on 22 inches. This means that by default all text is extremely small, and so are icons, buttons, scroll-bars etc. In Gnome 3 and also in Unity text can be "scaled" to be larger, either through the accessibility options or through other configuration settings. However, that does not always help when it comes to buttons, titlebars etc. It also often messes up the entire layout of applications, and will require the user to constantly resize windows.

In Gnome 2 the DPI value could be changed, through the dconf editor if I remember correctly, and everything looked great; but in Gnome 3 this is not possible anymore. The DPI value is hard-coded and I do not know of any plugins that could fix this.

Therefore I spend a couple of days looking for a solution which would involve hacking the source code. Read on if you are having similar issues and want to change your DPI setting as well.

System Setup

The following instructions were performed on a fresh live-cd of Ubuntu 12.04. I am not a big fan of the Unity desktop, and thus installed Gnome-Shell, logged out, changed my session to Gnome and logged back in (on the live-cd the username is "ubuntu" and the password is blank).

I am not sure if the instructions would work for the Unity desktop as well without installing Gnome-Shell first; to be on the safe side, just install Gnome-Shell, it's a pretty neat desktop anyway.

Let's start hacking

The gnome-settings-daemon will have to be compiled from source code. This requires a few things to be setup.

Most of the tips for setting this up were taken from this page:

Get your environment ready

Open Terminal (on Gnome 3, press the super-key or point to the top left of the screen and type Terminal).

Once Terminal is open, use the command-line to install build-essential and checkinstall. Not sure if this is absolutely necessary, buy can't hurt either:
sudo apt-get install build-essential checkinstall

Also install apt-file, which will make it easier to find dependencies that we may need when the configure command complains:
sudo apt-get install apt-file

Use the folder /usr/local/src for all your work, but set up the right permissions to avoid any problems (replace <user> with your username):
cd /usr/local/src
sudo chown <user> .
chmod 755 .

Install all the dependencies for the gnome-settings-daemon that we will install. Just copy and paste this line into the Terminal, it should just work. The list was taken from the "gnome-settings-daemon_3.4.1-0ubuntu1.dsc" file on https://launchpad.net/ubuntu/+source/gnome-settings-daemon/3.4.1-0ubuntu1:
sudo apt-get install cdbs debhelper gnome-pkg-tools dh-autoreconf autotools-dev intltool libdbus-glib-1-dev libglib2.0-dev libgtk-3-dev libgconf2-dev libnotify-dev libxt-dev libxi-dev libfontconfig1-dev libxext-dev libx11-dev libxtst-dev libgnomekbd-dev libxklavier-dev libgstreamer0.10-dev libgstreamer-plugins-base0.10-dev gsettings-desktop-schemas-dev libgnome-desktop-3-dev libpulse-dev libcanberra-gtk3-dev libpolkit-gobject-1-dev libappindicator3-dev hwdata libupower-glib-dev libcolord-dev liblcms2-dev libnss3-dev libgudev-1.0-dev libwacom-dev xserver-xorg-input-wacom

Get the gnome-settings-deamon source code and extract it:
wget https://launchpad.net/ubuntu/+archive/primary/+files/gnome-settings-daemon_3.4.1.orig.tar.xz
tar xvf gnome-settings-daemon_3.4.1.orig.tar.xz

Hack the DPI Setting

Now it's time to edit the DPI setting. To do so, cd into the directory where gsd-xsettings-manager.c is and search for the DPI value (which is 96 originally). On my screen with a 3840x2400 resolution a DPI value of 160 looks good, but on smaller resolutions you should definitely use a smaller value. 120 might be a good start.
cd gnome-settings-daemon-3.4.1/plugins/xsettings
nano gsd-xsettings-manager.c

Once you have the file open in nano, look for #define DPI_FALLBACK 96, which is right after a long long comment. Here change the value from 96 to the one you desire, press Ctrl+O to save and then Ctrl+X to exit nano.

Now go back into the extracted directory and run the configure command:
cd /usr/local/src/gnome-settings-daemon-3.4.1

At this point the configure script may complain about missing libraries. In my case it was cups-config. In order to find the package name and install it, I used apt-file:
apt-file search cups-config

The result from apt-file gives a list of possible packages that might correspond to the missing one, in my case it was libcups2-dev, so I installed it:
sudo apt-get install libcups2-dev

Once all dependencies are installed, we can run the configure command again:

Compile the Code

Once all dependencies are installed, it's time to compile gnome-settings-daemon:

Now my approach differs from the post on the Ubuntu site--instead of installing the entire package, I only replaced the new libxsettings.so file with the existing one on my system. I tried to install the complete package at some point, but it caused problems afterwards. Anyway, to do this, I made a backup of the old libxsettings.so file, and then copied the new one into the directory where it belongs:
cd /usr/lib/gnome-settings-daemon-3.0/
sudo mv libxsettings.so libxsettings.so~
sudo cp /usr/local/src/gnome-settings-daemon-3.4.1/plugins/xsettings/.libs/libxsettings.so .

And finally...

After this I closed all programs, held my breath, and logged out and back in. In my case, it worked... I hope it will work for you as well.

Reverting this Hack

If things went wrong, one simply has to replace the new libxsettings.so with the old one. This can be done from the terminal, either in Gnome or from a TTY which can be reached by holding down Ctrl and Alt and pressing F1:
cd /usr/lib/gnome-settings-daemon-3.0
sudo mv libxsettings.so~ libxsettings.so

Final Words

Please notice that not every application obeys to the DPI setting. Google Chrome as well as Chromium will for example still have tiny text for their tabs. As far as I know, this is due to the fact that these applications also hard-coded the font sizes somehow.
Also icons will not necessarily scale; there are other how-tos and tutorials online that explain how to make these larger.

I hope this was helpful for anybody out there looking for a higher DPI setting,


Saturday, September 22, 2007

A smart __autoload() function for PHP 5 with minimum overhead

Yet another __autoload() function

It took me a while to figure out how I wanted to organize my classes, and how to use __autoload() to load them automatically, instead of having to use require_once() in every script.

My goal was a fast implementation of the __autoload() function, which would not have to do any unnecassary I/O.

I came up with a very small and simple function, which creates the path to the class from the name of the class itself. The only caveat is that classes names and the directory structure must adopt to a very strict naming scheme, which is also case sensitive. But I believe that it doesn't take much time to get used to this scheme, and many people may be using a similar, if not the same, scheme already.

Naming Scheme

  • Base Classes
    • the class name must start with a capital letter
    • the class name can only contain letters
    • the class name can only have one capital letter
    • the class file must resides in a directory with the same name as the class
    • the class file must have the same name as the class followed by the extension .php
  • Extended Classes
    • the extended class name must start with the base class name
    • the extended class name can only contain letters
    • the name after the base class name must start with a capital letter
    • the name after the base class name can only have one capital letter
    • the extended class file must reside in a sub directory of the base class with the same name as the extended class
    • the extended class file must have the same name as the extended class followed by the extension .php

Directory Structure and Class Names

/path/to/classes - BASE_PATH (must be defined in autoload.php script) /path/to/classes/autoload.php - the file containing the __autoload() function /path/to/classes/Shape/Shape.php - class Shape /path/to/classes/Shape/ShapeCircle/ShapeCircle.php - class ShapeCircle extends Shape /path/to/classes/Shape/ShapeRectangle/ShapeRectangle.php - class ShapeRectangle extends Shape /path/to/classes/Shape/ShapeRectangle/ShapeRectangleSquare/ShapeRectangleSquare.php - class ShapeRectangleSquare extends ShapeRectangle

One nice feature of this naming scheme is that your directory tree will look exactly like your classes, your base directories would have your base classes, and each sub directory would have an extended class of it's parent. Classes can be extended multiple times.

To setup this scheme, first the BASE_PATH directory has to be created, and the path has to be defined in the autoload.php script. The __autoload() function should reside in a file by itself in that directory, like in the example above.


Assuming the previous classes and directory structure, a Shape class could be used like this:

$shape = new Shape();

A ShapeCircle class could be used like this:

$shape = new ShapeCircle();

Several classes can be used as well, like so:

$shape = new Shape();
$circle = new ShapeCircle();
$square = new ShapeRectangleSquare();

The __autoload() Function

And finally, here is the simple but powerful __autoload() function:

<?php // Function to autoload classes // // This function tries to automatically locate a class and do a require_once() // on it if it is found. // // @author DrTebi[at]yahoo[dot]com // @version 0.1 // @date 2007-09-22 // // @public // @param class_name @c string the name of the class, automatically provided by PHP // @return @a void calls require_once() if the class file is found, // triggers an E_USER_WARNING otherwise

__autoload($class_name) {
$class_base "";
  for (
$i 1$i strlen($class_name); $i++) {
    if (
ord($class_name[$i]) < 97) {
$class_base .= substr($class_name0$i) . DIRECTORY_SEPARATOR;
$path BASE_PATH DIRECTORY_SEPARATOR $class_base $class_name DIRECTORY_SEPARATOR $class_name ".php";
  if (
is_readable($path)) {
  } else {
trigger_error("Could not load class: " $pathE_USER_WARNING);

Tuesday, December 05, 2006

Error 1305. Cannot read from openofficeorg20.msi

A mysterious error occurs when trying to install OpenOffice.org

Note: this article describes an error message that occurred on windows installs only

After I downloaded OpenOffice.org version 2.04 and tried to install it today, I encountered an error that didn't seem to be solvable. The error message was something like

Error 1305. Cannot read from file openofficeorg20.msi. The source file may be damaged.

I assumed that my download went wrong, so I went back to openoffice.org and tried again. I noticed that every time I clicked on the "continue to download" button, I was sent a download from a different mirror. However, the second, and even the third download showed the same problem.

I even went ahead and downloaded the uTorrent program in order to download it via BitTorrent. Besides the fact that I got an amazing speed in downloading the OpenOffice.org installation file, it still failed to install.

What caused the problem

Searches on the Internet revealed problems with "Error 1305," but none of them specific to OpenOffice.org. It became a bit of a frustrating issue, since I had to finish an important paper the same night.

But I didn't give up and finally found out what went wrong: As my C:\ partition on my hard disk is really full, I downloaded the installation file to another disk. This itself is not a problem, but when unpacking, the files must be extracted to the C:\ partition. Only when the OpenOffice.org package was unpacked to the C:\ partition, and installed from there, I was finally able to install the program without the mysterious "Error 1305."

I hope this helps anybody that encountered the same problem.

Tuesday, November 28, 2006

Logging PHP errors with metalog

On production servers, PHP errors should not be displayed. Just logging errors to a file will be problematic once that file grows big.

Note: This article implies that you are running LAMP, and are using metalog as your system logger.

A huge update was due for my TattooJoy website, which automatically meant things could go wrong. Of course, as recommended in the php.ini file, I do have display_errors set to off. But if something went wrong after the update, how would I know?

PHP allows you to log errors to a file. Setting this up is fairly simple, all you have to do is decide where to save the file, set it's owner and permission correctly, tell PHP about this in the php.ini settings, and restart apache. These settings in php.ini will suffice:

error_reporting = E_ALL log_errors = On log_errors_max_len = 1024 ignore_repeated_errors = On ignore_repeated_source = Off report_memleaks = On track_errors = Off error_log = /var/log/php/errors.log

Most of these are default settings. The last line, error_log, defines the location of your error log file. In order to be able to write to this file, PHP must have permissions to do so. And since PHP is run by the apache web server, you must make sure that the user running apache (usually "apache" or "nobody") has write permissions to the file defined by errors_log file.

Once this is setup, just restart apache and produce an error (that should be easy!) in any PHP script. You will find all your errors logged into /var/log/php/errors.log

PHP's error log file can grow extremely large

Soon enough I found out that over time this file was just growing bigger and bigger. The directive log_errors_max_len made it appear as if PHP would do some kind of rotating once the log file reaches this size--but that was quite wrong.

log_errors_max_len only defines the length per line PHP writes into your error log file, don't be fooled.

Thankfully, I was sceptical, and regulary checked the log file. Once I learned that I had no control over it's growth, I started to think about other possibilities.

Logging PHP errors to the syslog facility

Another option PHP offers is to log to syslog. If you are on a Gentoo system, you probably know that any errors are logged into /var/log/everything/current. To get PHP to log it's errors to that file, you only have to change a tiny bit of code in your error handling section of the php.ini file:

error_reporting = E_ALL log_errors = On log_errors_max_len = 1024 ignore_repeated_errors = On ignore_repeated_source = Off report_memleaks = On track_errors = Off error_log = syslog

So, instead of specifying a path to an error log file, you simply specify syslog as your way of error logging. Restart apache, and reload your PHP script that contains an error.

Note that messages aren't immediately recorded into log files; that is actually a feature of metalog, it avoids disk I/O and improves performance. If you are too impatient to see your errors, you can temporarily disable caching:

kill -USR1 `ps -C metalog -o pid=`

And to turn it back on again:

kill -USR2 `ps -C metalog -o pid=`

Using metalog to log PHP errors into it's own error log

While it is useful to have PHP errors in the "everything" log, it would make more sense to designate a directory for PHP errors alone, just as other programs like ftpd or samba.

This is a lot simpler that it sounds. All there is to do is create a directory in e.g. /var/log, edit metalog's config file (which resides in /etc/metalog/metalog.conf), and restart metalog. Here is a sample PHP section for the metalog config file, in it's simplest way:

# DrTebi's PHP syslog logging PHP error message (sent by httpd): program = "httpd" logdir = "/var/log/php"

By default, if you are on a Gentoo system, all log files are rotated daily, or if they exceed 100KB, and a maximum of 5 log files is kept. These settings can be adjusted for every section individually, so you may want to play around with it, if you aren't happy with the defaults.

You can find more information about metalog at metalog's website, and read more about PHP's error directives on PHP's manual.

Blog Archive