dragffy.com

Came accross the following post at:
http://www.pluralsight.com/community/blogs/fritz/archive/2007/06/19/47771.aspx

“I spent more time than I care to admit tracking down this one, perhaps this post will save someone else the trouble…

When defining a number of functions in a prototype in JavaScript, do not include a trailing comma after the last function:

MyType.prototype = {
    foo : function() {
          // ...
    },

    bar : function() {
        //...
    }, //< - fails in IE!
 }

What was especially tricky about tracking this problem down was that FireFox works with or without the trailing comma, so it only fails in IE!”

I’ve recently started experimenting with Git, previously being totally committed(!) to Bazaar. Git is difficult in comparison but I intend to stick with it. I have been using Git under Cygwin on Windows XP, it seemed to work fairly well except that often when I added a large batch of source code files they wouldn’t get committed.

Eventually I found out it is because Git is choking on one the line endings in some files. When trying a commit of these files I would see a whole load of errors fly by such as ‘trailing whitespace’ and “you have some suspicious patch lines”. Googling around I found three answers, but I could only fully understand two of them.

Firstly, the approach I took, was to run the command chmod a-x .git/hooks/pre-commit in the git repository.

The other approach, which I found here says to edit the pre-commit file above and comment out the lines:
if (/\s$/) {
bad_line("trailing whitespace", $_);
}

Which would mean changing it to:
#if (/\s$/) {
#bad_line("trailing whitespace", $_);
#}

Hope that can help someone!

A good article has been written on PC Mech about Firefox 3 being a memory hog. The author got slated by some, but I support the author. From my first hand experience FF3 on OS X Leopard has managed to eat up 650MB RAM with just a few tabs open.

Full article can be found here: http://www.pcmech.com/article/firefox-3-hogs-memory-like-crazy/

I have a first generation macbook coreduo.

The latest version of Ubuntu (Hardy Heron 8.04 LTS) works very well on it with minimal configuration. However, several issues remain. One of which is the poor sound quality. Initially, installing linux-backports-modules did the trick, however after several reboots it became clear that it didn’t always work. I came across this post, which I followed and the results were outstanding. I have completely copied it here, only to make sure there is another copy of this important document. Full credit for this one goes to the original author. Anyway, here’s what you need to do:

Edit the file /etc/modprobe.d/options
$ sudo vim /etc/modprobe.d/options

And add the following to the end of the file:
options snd-hda-intel model=[MODEL_BELOW] position_fix=2 probe_mask=1

Run the following command:
$ sudo update-initramfs -u

Then reboot.

You must select the Intel HDA model that corresponds to your computer:

These are the codes you can use in the above instructions:
intel-mac-v1 : Intel Mac Type 1
intel-mac-v2 : Intel Mac Type 2
intel-mac-v3 : Intel Mac Type 3
intel-mac-v4 : Intel Mac Type 4
intel-mac-v5 : Intel Mac Type 5
macmini : Intel Mac Mini (equivalent with type 3)
macbook : Intel Mac Book (eq. type 5)
macbook-pro-v1 : Intel Mac Book Pro 1st generation (eq. type 3)
macbook-pro : Intel Mac Book Pro 2nd generation (eq. type 3)
imac-intel : Intel iMac (eq. type 2)
imac-intel-20 : Intel iMac (newer version) (eq. type 3)

For example, I have a Macbook 1st generation, and the only setting that worked was
model=intel-mac-v1. All others just gave me no sound at all, including the apparently
obvious macbook and the documented-as-equivalent macmini ones.

If nothing works, you can revert this by deleting the line and performing the rest of the steps.

For BEST sound, if the above works, open a terminal and type:
$ alsamixer

And set the front and surround sliders to their maximum.
It might be necessary to unmute them with the ‘M’ key.
Press ESC twice to leave the program.

I recently set up a new file server. It contains three 1 terabyte drives configured in a RAID 5 array but with RAID 1 for the boot partitions so in the event of drive failure the system could still boot.

Essentially you need to go through a normal installation process and make sure you choose a couple of things during parition setup. I split each of the 3 drives in to two partitions, one 200MB, and the other partition the remaining disc space. This is what I had:
sda1 = 200MB
sda2 = 9800MB
and the same for the other drives.

Set all sda1 partition to be ext3 and bootable and mounted as /boot, set sdb1 and sdc1 partitions to be Linux Software Raid, bootable, but not mounted. Configure the RAID and create a new RAID device, tell it to use three devices and add to it sda2, sdb2, and sdc2.

When I returned to the partition menu I configured md0 as a partition for a logical volume group. I then configured LVM and created logical volumes for /root, swap, and /home. Returning to the partitioning menu I formatted these and selected their mount points and installed the system.

Following system installation I went about creating a RAID 1 array for sda1, sdb1, and sdc1. First thing was to create a new array using mdadm and the two paritions we haven’t yet assigned:
# mdadm --create /dev/md1 --level=1 --raid-disks=3 missing /dev/sdb1 /dev/sdc1

Make a filesystem on our new RAID device:
# mkfs.ext3 -m 0 /dev/md1

Save the new configuration in to mdadm’s config file:
# mdadm --examine --scan >> /etc/mdadm/mdadm.conf

Edit mdadm.conf and remove the duplicate entry at the bottom:
# vim /etc/mdadm.conf

Mount the new RAID device so we can copy data to it:
# mkdir /media/md1
# mount /dev/md1 /media/md1

Copy over the boot partition to the RAID device:
# cd /boot
# cp -dpRx . /media/md1

Edit fstab and replace /dev/sda1 with /dev/md1:
# vim /etc/fstab

Edit mtab and do the same:
# vim /etc/mtab

Unmount /boot, change it’s system type and add it to the RAID array:
# umount /boot
# fdisk /dev/sda
Command (m for help): t
Partition number (1-4): 1
Hex code (type L to list codes): f
Changed system type of partition 1 to fd (Linux raid autodetect)
Command (m for help): w

# mdadm --add /dev/md1 /dev/sda1

Configure GRUB so that it can boot from any hard drive:
# grub
grub> device (hd0) /dev/sda
grub> root (hd0,0)
grub> setup (hd0)
grub> device (hd0) /dev/sdb
grub> root (hd0,0)
grub> setup (hd0)
grub> device (hd0) /dev/sdc
grub> root (hd0,0)
grub> setup (hd0)
grub> quit

# update-initramfs -u

Change all occurance of (hd*) to (hd0) in the file /boot/grub/devices.map.

That should be all - good luck with the reboot!
# reboot

Installing Netatalk from the repositories means that when you connect using a Mac client you will be warned that you are going to send your password in the clear. Obviously this isn’t great for security, and being prompted every time you want to connect is annoying. This occurs because Netatalk in the Ubuntu repositories is compiled without SSL support (SSL is what handles the encryption).

The key to getting this to work is to get the Netatalk source code and compile it yourself. Don’t worry, it’s been done hundreds of times before and if you follow this tutorial closely you should be fine.

The commands written always start with a dollar sign ($), you should not type this, it just indicates the commands should be typed at a standard user prompt in the terminal.

First off it’s a good idea to switch to your home directory:
$ cd ~

Make a new directory to hold the hundreds of small Netatalk files:
$ mkdir netatalk

Ensure you have essential development libraries and tools installed:
$ sudo aptitude install libdb4.2-dev libslp-dev autotools-dev devscripts cracklib2-dev dpkg-dev libssl-dev

Change in to the newly created directory:
$ cd netatalk

Install the netatalk source code:
$ sudo apt-get source netatalk

Install all required dependencies for netatalk:
$ sudo apt-get build-dep netatalk

A new directory called netatalk-2.0.3 should have been created, change in to that directory:
$ cd netatalk-2.0.3

Compile Netatalk with the SSL option:
$ DEB_BUILD_OPTIONS=ssl sudo dpkg-buildpackage -us -uc

Install the finished product!:
$ sudo debi

Initially I had set a mail account with a quota of 200000, or roughly 200MB. The user complained of a full mailbox, despite using Plesk to up the limit to 2GB, and then unlimited the account continued to bounce emails saying:
"Recipient's mailbox is full"

I found people complaining of a bug in version 7.5 of Plesk, but it seems this is also present in 8.3. The problem, I discovered after nosing around the config files of the server, was that any changes I made in Plesk weren’t saved. Ultimately I found the limit in the config file remained at 200MB, despite numerous changes. The quota config file is located at:
/var/qmail/mailnames/example.com/username/@mbox.quota

Manually edit that file so it has the quota you want. I like to use vim:
vim /var/qmail/mailnames/example.com/username/\@mbox.quota
(run this as root)

After editing, save the changes, and you won’t need to restart any services or the server. Changes should take effect.

Note, that this was performed on a CentOS 5 installation, so paths and instructions may vary slightly on other systems.

Today I upgraded a server that was running Gutsy AMD64 arch. I wanted to note in this blog that the update went well, and the result is what seems to be a perfectly good Hardy Heron system. This is what I did from the command line:
sudo aptitude install update-manager-core

followed by:
sudo do-release-upgrade

Went through it all. Sometimes got prompted about config files - whether to keep my version or install package maintainers version. I chose to install the maintainers in case there were some important new config options (I had backups of my config files). These were mostly related to Apache and PHP. Having gone through the config files I can say that it is safe to choose to keep your config files (if upgrading from Gutsy). If you’re going from Dapper you probably should check.

I recently found that sending emails via my server was painfully slow. After further invesitigation in to this issue I discovered that the server was performing reverse-DNS checks on client IPs. These were slow because they often didn’t work and had to wait for a timeout. The solution is to turn of reverse-DNS checking on the server by editing a config file as follows…

The modification must be made to the /etc/inetd.conf file:

smtp stream tcp nowait root /path/to/qmail/bin/tcp-env tcp-env -Rt0 ...

smtps stream tcp nowait root /path/to/qmail/bin/tcp-env tcp-env -Rt0 ...

It is necessary to restart inetd in order for the changes to take effect:

# kill -HUP `cat /var/run/inetd.pid`

Note, /etc/inetd.conf may be overwritten and the options you added will be removed if you make certain changes through Plesk CP, for example add MAPS server.

There was a time when I would recursively grep the contents of literally thousands of files at a time to search for particular occurances of characters. The usual starting place was something using grep, which we can time for crude benchmarking:

user@localhost$ time grep -rn 'hello' *
templates/temp.tpl:1:hello

real 1m56.190s
user 0m1.400s
sys 0m0.940s


Using Ruby to write a script, which I named Grope, I made the search process 450 times faster, reducing an operation that took more than a minute to taking a blink of an eye…

user@localhost$ time grope 'hello'
templates/festival/06/temp.tpl: 1
hello...

real 0m0.181s
user 0m0.100s
sys 0m0.070s