Random May 20th, 2009
After a while I had the chance to get back to MooseX::Log::Log4perl, which is Role (based on Moose) that can be easily reused in classes requiring logging functionality.
While it is really simple to use, I still found myself often directly using the default logger approach by creating a class variable and using that. So instead of:
use Moose;
with MooseX::Log::Log4perl;
sub whatever {
my $self = shift;
$self->log->debug("Here I am") if $self->log->is_debug;
}
mostly the direct logger was used in the classes.
use Log::Log4perl;
use vars qw($log);
$log = Log::Log4perl->get_logger(__PACKAGE__);
sub whatever {
my $self = shift;
$log->debug("Here I am") if $log->is_debug;
}
One reason was that during that time I optimized for speed and found a hotspot to be the additional method call for the “log” method. As perl has some overhead in calling functions, this still holds true to some extend, so that’s why I added a benchmarking test to the testsuite of MooseX::Log::Log4perl.
So if you have the chance, I’d like to see if in your test environment still the performance limits (keep overhead lower than 5% compared to using Log::Log4perl directly). To run the test simply get the sources and run the test.
cpan> look MooseX::Log::Log4perl
shell# TEST_MAINT=1 prove -l -v t/99_bench.t
t/99bench.t ..
1..6
ok 1 - Bench instance for MooseX::Log::Log4perl isa BenchMooseXLogLog4perl
ok 2 - Bench instance for Log::Log4perl isa BenchLogLog4perl
Rate MooseX-L4p log MooseX-L4p logger Log4perl method Log4perl direct
MooseX-L4p log 21235/s -- -0% -4% -6%
MooseX-L4p logger 21273/s 0% -- -4% -6%
Log4perl method 22102/s 4% 4% -- -2%
Log4perl direct 22535/s 6% 6% 2% --
...
If all tests pass you stayed within the limits (around 95% compared to using Log4perl directly). I’d like to see your results. So please comment on it and add the comparison table to it.
Random May 13th, 2009
The system itself is a Dell D830 laptop with a nvidia NV135 chip and an Intel Core2 Duo T7500 CPU with 2GB RAM. For actual benchmarking the new futuremark paecekeeper browser benchmark has been put to use.
The compared browsers are:
- Midori 0.1.4 (lightweight GTK browser using webkit)
- Iceweasel 3.0.9 (the debian rebranded Firefox 3.0.9)
- FIrefox 3.5b4 (latest beta of firefox 3.5)
Sunspider results are:
RESULTS (means and 95% confidence intervals) for SunSpider 0.9
--------------------------------------------
Firefox 3.5b4: 2405.6ms +/- 4.0%
Midori 0.1.4: 3917.2ms +/- 2.6%
Iceweasel 3.0.9: 4465.6ms +/- 1.6%
Here are the results for the Futuremark Peacekeeper browser benchmark:
The results are quite unexpected, as working with the browser show a different perceived quality. Although midori scores highest in the peacekeeper benchmark, the rendering on some sites is sometimes flaky and seem to take longer as with both firefox version. On the other hand the sunspider benchmark shows midori far behind firefox, which also is strange as SunSpider is from the webkit project and should therefor be quite fast on a browser using webkit.
Random April 27th, 2009
In the process of getting a debian repostiry ready to allow easy installtion with debian’s apt, a small series of posts are going to be created here. So here is the initial post describing a very simple debian repository layout.
All that’s required to setup your own debian repository is the dpkg-dev package and a web or ftp server for serving the files. For a local deployement (e.g. within a company) also a file-system based approch is possible through a NFS mounted directory.
Make sure the dpkg-dev package is installed:
sh# aptitude install dpkg-dev
Copy all files into a directory binary on the server. So the layout will look something like this:
(webserver-root)
+-- debian
+-- binary
|Â Â Â +-- myweb-2.0-1_i386.deb
|Â Â Â +-- myweb-utils-2.0-1_i386.deb
+-- source
Here the packages in the binary directory can new be used to create the repository index and serve this then as a debian repository. To scan the packages and create the index use:
$ cd webserver-root
$ dpkg-scanpackages binary /dev/null | gzip -9c > binary/Packages.gz
$ dpkg-scansources source /dev/null | gzip -9c > source/Sources.gz
Now the repository can be used by adding the following to /etc/apt/sources.list:
deb http://my.server.com/debian/binary ./
deb-src http://my.server.com/debian/source ./
See http://www.debian.org/doc/manuals/repository-howto/repository-howto for more details.
Random February 22nd, 2009
After seeing that ATI has released again drivers for Linux with a new major version number (and not the scarry .0 behind it) I thought it was time to battle the ATI dragons again. As Debian usually lags behind on the proprietary ATI stuff (who wonders…) I’m using aain the binary packages provided by ATI.
The system is Debian testing, which is now codenamed “Squeeze” as Lenny finally stablized.
As the build required libstdc++5 I had to reinstall this package:
sh# aptitude install libstdc++5
Downloaded the latest ati-driver-installer-9.2-x86.x86_64.run and ran the usual:
sh# sudo sh ati-driver-installer-9.2-x86.x86_64.run --buildpkg Debian/testing
which results in the following packages being built:
- fglrx-amdcccle_8.582-1_amd64.deb
- fglrx-driver_8.582-1_amd64.deb
- fglrx-driver-dev_8.582-1_amd64.deb
- fglrx-kernel-src_8.582-1_amd64.deb
Install those and if RandR 1.2 is compiled into Xorg (which it is usually) your dual-screen setup probably switches back to a cloned view. In case you never had a working dual-screen (called big desktop by ATI) setup, run the following (and be sure to backup your /etc/X11/xorg.conf in case you have anything special in there), otherwise skip this section:
sh# sudo dpkg-reconfigure -phigh xserver-xorg
sh# aticonfig --initial --desktop-setup=horizontal --overlay-on=1
Then be sure to have added a “Virtual” desktop size to your “Display” subsection like so (for two 1680×1050 screens thats 3360×1050):
Section "Screen"
Identifier "aticonfig-Screen[0]-0"
Device "aticonfig-Device[0]-0"
Monitor "aticonfig-Monitor[0]-0"
DefaultDepth 24
SubSection "Display"
Viewport 0 0
Depth 24
Virtual 3360 1050
EndSubSection
EndSection
After restarting X11 (Ctrl-Alt-Backspace) login and open a terminal and run:
sh# xrandr --output DFP2 --right-of DFP1
This will setup display DFP2 to be right of DFP2, please check the correct display names to use with
xrandr -q
.
Of course you can also use the graphical tools arandr or grandr to accomplish this.
Random January 13th, 2009
Die Playstation 3 erobert jetzt (dank günstiger Preise in UK) einige Wohnzimmer, so auch unseres.
Um der sozialen Komponente genüge zu tragen hier einige Playstation Network User:
- Peter & Elke: donpedro80 & elkemaus
- Martin & Nathalie: basketfighter & spacegirl666
- Roland & Sonja: Random-Logic & Schnautzal
- Ferenc: ?
- Chris: tintifax4711
- Oliver: okabae
Random November 8th, 2008
Resizing of the file-based qcow2 format for handling disk images is possible by performing the resize on a different format and use the conversion capabilities of qemu-img.
Having created a 1GB disk image in qcow2 format like this:
quikit:/var/kvm# qemu-img create -f qcow2 mydisk.qcow2 1G
Formatting 'mydisk.qcow2', fmt=qcow2, size=1048576 kB
quikit:/var/kvm# qemu-img info mydisk.qcow2
image: mydisk.qcow2
file format: qcow2
virtual size: 1.0G (1073741824 bytes)
disk size: 16K
cluster_size: 4096
The resize existing images the following steps are required:
- Convert the qcow2 disk image to raw format
qemu-img convert -f qcow2 mydisk.qcow2 -O raw mydisk.raw
- Resize the raw image using dd (the file contents is not touched)
dd if=/dev/zero of=mydisk.raw bs=1M count=0 seek=4096
- Convert back to the qcow2 format (only used blocks will take up diskspace)
qemu-img convert -f raw mydisk.raw -O qcow2 newmydisk.qcow2
After conversion the qcow2 info now shows:
quikit:/var/kvm# qemu-img info newmydisk.qcow2
image: newmydisk.qcow2
file format: qcow2
virtual size: 4.0G (4294967296 bytes)
disk size: 28K
cluster_size: 4096
So resizing a partition can be as simple as that. Now try to boot the resized image, if it is not working you may have to reinstall the bootloader.
If you are using a NTFS partition you have to take special care. See the qemu forum for details.
