Xfce

Subdomains
 

Xfce 4.8 with Conky

  • August 21, 2011
  • Mike Massonnet
I have been following a short discussion on the IRC channel #xfce regarding an issue with the use of Conky and transparency. I didn't use Conky for a very long time, but since I knew it was possible to have Conky perfectly running, I gave it a shot again and since I did a fresh reinitialization of Xfce on my workstation, I tweaked the configuration file to my need. Now I have it running in the background and I'll most probably keep it.

The configuration I was able to get for a good working Conky window with transparency is bellow. Of course I could tell you which combination doesn't work, with the why, but since there are so many of them I simply put a working one.
own_window yes # create a separate XWindow over the one from Xfdesktop
own_window_type desktop # the window cannot be moved or resized
own_window_hints undecorated,below,sticky,skip_taskbar,skip_pager # make it behave like it belongs to the desktop
own_window_argb_visual yes # true transparency, a compositor has to be active
own_window_argb_value 100 # make the background semi-transparent
double_buffer yes # avoid flickering

Here is a screenshot of the desktop with Conky in the bottom right corner, I made sure there is some I/O activity going on :-)

Xfce with Conky
Now if you want you can steal my .conkyrc file.

Xfce 4.8 with Conky

  • August 21, 2011
  • Mike Massonnet
I have been following a short discussion on the IRC channel #xfce regarding an issue with the use of Conky and transparency. I didn't use Conky for a very long time, but since I knew it was possible to have Conky perfectly running, I gave it a shot again and since I did a fresh reinitialization of Xfce on my workstation, I tweaked the configuration file to my need. Now I have it running in the background and I'll most probably keep it.

The configuration I was able to get for a good working Conky window with transparency is bellow. Of course I could tell you which combination doesn't work, with the why, but since there are so many of them I simply put a working one.
own_window yes # create a separate XWindow over the one from Xfdesktop
own_window_type desktop # the window cannot be moved or resized
own_window_hints undecorated,below,sticky,skip_taskbar,skip_pager # make it behave like it belongs to the desktop
own_window_argb_visual yes # true transparency, a compositor has to be active
own_window_argb_value 100 # make the background semi-transparent
double_buffer yes # avoid flickering

Here is a screenshot of the desktop with Conky in the bottom right corner, I made sure there is some I/O activity going on :-)

Xfce with Conky
Now if you want you can steal my .conkyrc file.

Analysing a phishing email

  • July 16, 2011
  • Mike Massonnet
I've been hit by several phishing emails in a short time the last week. Having time this morning I took the initiative to look at the headers from one email and the phishing location.

The hosting server
The domains DNS zone is hosted on a particular network just like its website. Two different servers actually, but behind it seems to be a lucrative webhosting service where you can get your domain registered although it's not a registrar. All of this is hosted in Texas.

The email server
The email is originating from Italy. The FROM address is set up to show a truthful email (usually where you put the surname) with an inexistant email address behind that. The email address' domain name exists however and is hosted in France, but has no relation to the scam, at least the owner of this domain can't do anything about it.

The Return-Path shows a real email address with a different domain name but same network anyway. The domain name shows a dummy webpage "Under construction".

Who to contact?
All of them if you care, otherwise just let it go, because phishing pages are set up and down daily...

To contact the webhosting or email server, request the Whois information of the IP address and contact the abuse department, there is always an abuse section in the Whois of an IP address. You can also contact the domain name holder and/or look if the registrar or webhosting sevice has a dedicated abuse website page.

Of course it happens that an abuse email address forwards everything to the trash can. In order to have a chance to stop the scam, it is good to contact as many services as possible.

Analysing a phishing email

  • July 16, 2011
  • Mike Massonnet
I've been hit by several phishing emails in a short time the last week. Having time this morning I took the initiative to look at the headers from one email and the phishing location.

The hosting server
The domains DNS zone is hosted on a particular network just like its website. Two different servers actually, but behind it seems to be a lucrative webhosting service where you can get your domain registered although it's not a registrar. All of this is hosted in Texas.

The email server
The email is originating from Italy. The FROM address is set up to show a truthful email (usually where you put the surname) with an inexistant email address behind that. The email address' domain name exists however and is hosted in France, but has no relation to the scam, at least the owner of this domain can't do anything about it.

The Return-Path shows a real email address with a different domain name but same network anyway. The domain name shows a dummy webpage "Under construction".

Who to contact?
All of them if you care, otherwise just let it go, because phishing pages are set up and down daily...

To contact the webhosting or email server, request the Whois information of the IP address and contact the abuse department, there is always an abuse section in the Whois of an IP address. You can also contact the domain name holder and/or look if the registrar or webhosting sevice has a dedicated abuse website page.

Of course it happens that an abuse email address forwards everything to the trash can. In order to have a chance to stop the scam, it is good to contact as many services as possible.

XTerm as root-tail

  • October 23, 2010
  • Mike Massonnet
The idea behind this title is to use XTerm as a log viewer over the desktop, just like root-tail works. The tool root-tail paints text on the root window by default or any other XWindow when used with the -id parameter.

Using XTerm comes with little advantage, it is possible to scroll into the “backlog” and make text selections. On a downside, it won't let you click through into the desktop, therefore it is rather useful for people without desktop icons for example.

We will proceed with a first simple example, by writing a Shell script that will use the combo DevilsPie and XTerm. The terminals will all be kept in the background below other windows and never take the focus thanks to DevilsPie. DevilsPie is a tool watching the creation of new windows and applies special rules over them.

Obviously, you need to install the command line tool devilspie. It's a command to run in the background as a daemon. Configuration files with a .ds extensions contain matches for windows and rules that are put within the ~/.devilspie directory.

First example

The first example shows how to match only one specific XTerm window.

The DevilsPie configuration:
DesktopLog.ds
(if
(is (window_class) "DesktopLog")
(begin
(wintype "dock")
(geometry "+20+45")
(below)
(undecorate)
(skip_pager)
(opacity 80)
)
)
The Shell script making sure devilspie is running, and spawning a single xterm process:
desktop-log.sh
#!/bin/sh
test `pidof devilspie` || devilspie &
xterm -geometry 164x73 -uc -class DesktopLog -T daemon.log -e sudo tail -f /var/log/daemon.log &
NB: You can notice the size of the XTerm window is set through the Shell script while the position is set through the DevilsPie rules file, and there is a simple reason for this. By default XTerm has a size of 80 columns and 24 lines and text with too long lines will be wrapped on the next line. If afterwards you resize the window the wrapped text won't move up and the result will be ugly. Therefore it's better to set the initial size of the terminal correctly.

To try the example, save the DevilsPie snippet inside the directory ~/.devilspie, and download and execute the Shell script. Make sure to quit any previous DevilsPie process whenever you modify or install a new .ds file.


Second example

The second example is a little more complete, it starts three terminals of which one is coloured in black.
DesktopLog.ds
(if
(matches (window_class) "DesktopLog[0-9]+")
(begin
(wintype "dock")
(below)
(undecorate)
(skip_pager)
(opacity 80)
)
)
 
(if
(is (window_class) "DesktopLog1")
(geometry "+480+20")
)
 
(if
(is (window_class) "DesktopLog2")
(geometry "+20+20")
)
 
(if
(is (window_class) "DesktopLog3")
(geometry "+20+330")
)
desktop-log.sh
#!/bin/sh
test `pidof devilspie` || devilspie &
xterm -geometry 88x40 -uc -class DesktopLog1 -T daemon.log -e sudo -s tail -f /var/log/daemon.log &
xterm -geometry 70x20 -uc -class DesktopLog2 -T auth.log -e sudo -s tail -f /var/log/auth.log &
xterm -fg grey -bg black -geometry 70x16 -uc -class DesktopLog3 -T pacman.log -e sudo -s tail -f /var/log/pacman.log &


NB: You will probably notice that setting the geometry is awkward, specially since position and size are in two different files, getting it right needs several tweakings.

This blog post was cross-posted to the Xfce Wiki.

Benchmarking Compression Tools

  • September 6, 2010
  • Mike Massonnet
Comparison of several compression tools: lzop, gzip, bzip2, 7zip, and xz.
  • Lzop: small and very fast yet good compression.
  • Gzip: fast and good compression.
  • Bzip2: slow for both compression and decompression although very good compression.
  • 7-Zip: LZMA algorithm, slower than Bzip2 for compression but very good compression.
  • Xz: LZMA2, evolution of LZMA algorithm.

Preparation

  • Be skeptic about compression tools and wanna promote the compression tool
  • Compare quickly old and new compression tools and find interesting results
So much for the spirit, what you really need is to write a script (Bash, Ruby, Perl, anything will do) because you will want to generate the benchmark data automatically. I picked up Ruby as it's nowadays the language of my choice when it comes to any kind of Shell-like scripts. By choosing Ruby I have a large panel of classes to process benchmarking data, for instance I have a Benchmark class (wonderful), I have a CSV class (awfully documented, redundant), and I have a zillion of Gems for any kind of tasks I would need to do (although I always avoid them).

I first focused on retrieving the data I was interested into (memory, cpu time and file size) and saving it in the CSV format. By doing so I am able to produce charts easily with existing applications, and I was thinking maybe it was possible to use GoogleCL to generate charts from the command line with Google Docs but it isn't supported (maybe it will maybe it won't, it's up to gdata-python-client). However there is an actual Google tool to generate charts, it is the Google Chart API that works by providing a URI to get an image. The Google Image Chart Editor website helps you to generate the chart you want in a friendly WYSIWYG mode, after that it is just a matter of computing the data into shape for the URI. But well while focusing on the charts I found the Ruby Gem googlecharts that makes it friendly to pass the data and save the image.

Ruby Script

The Ruby script needs the following:
  • It was written with Ruby 1.9
  • Linux/Procfs for reading the status of processes
  • Googlecharts: gem install googlecharts
  • ImageMagick for the command line tool convert (optional)
The Ruby script takes a path as argument, with which it creates a tarball inside a tmpfs directory in order to avoid I/O latencies from a hard-drive. Next it runs a number of commands over the tarball from which it collects benchmark data. The benchmark data is then saved inside CSV files that are reusable within spreadsheet applications. The data is also reused to retrieve charts from the Google Chart API and finally it calls the ImageMagick tool ''convert'' to collect the charts inside a single image. The summary displayed on the standard output is also saved inside a text file.

The script is a bit long for being pasted here (more or less 300 lines) so you can download it from my workstation. If the link doesn't work make sure the web browser doesn't encode ~ (f.e. to "%257E"), I've seen this happening with Safari (inside my logs)! If really you are out of luck, it is available on Pastebin.

Benchmarks

The benchmarks are available for three kinds of data. Compressed media files, raw media files (image and sound, remember that the compression is lossless), and text files from an open source project.
Media Files
Does it make sense at all to compress already compressed data. Obviously not! Let's take a look at what happens anyway.


As you see, compression tools with focus on speed don't fail, they still do the job quick while gaining a few hundred kilo bytes. However the other tools simply waste a lot of time for no gain at all.

So always make sure to use a backup application without compression over media files or the CPU will be heating up for nothing.
Raw Media Files
Will it make sense to compress raw data? Not really. Here are the results:


There is some gain in the order of mega bytes now, but the process is still the same and for that reason it is simply unadapted. For media files there are existing formats that will compress the data lossless with a higher ratio and a lot faster.

Let's compare lossless compression of a sound file. The initial WAV source file has a size of 44MB and lasts 4m20s. Compressing this file with xz takes about 90s, this is very long while it reduced the size to 36MB. Now if you choose the format FLAC, which is doing lossless compression for audio, you will have a record. The file is compressed in about 5s to a size of 24MB! The good thing about FLAC is that media players will decode it without any CPU cost.

The same happens with images, but I lack knowledge about photo formats so your mileage may vary. Anyway, except the Windows bitmap format, I'm not able to say that you will find images uncompressed just like you won't find videos uncompressed... TIFF or RAW is the format provided by many reflex cameras, it has lossless compression capabilities and contains many information about image colors and so on, this makes it the perfect format for photographers as the photo itself doesn't contain any modifications. You can also choose the PNG format but only for simple images.
Text Files
We get to the point where we can compare interesting results. Here we are compressing data that is the most commonly distributed over the Internet.


Lzop and Gzip perform fast and have a good ratio. Bzip2 has a better ratio, and both LZMA and LZMA2 algorithms even better. We can use an initial archive of 10MB, 100MB, or 400MB, the charts will always look alike the one above. When choosing a compression format it will either be good compression or speed, but it will definitely never ever be both, you must choose between this two constraints.

Conclusion

I never heard about the LZO format until I wanted to write this blog post. It looks like a good choice for end-devices where CPU cost is crucial. The compression will always be extremely fast, even for giga bytes of data, with a fairly good ratio. While Gzip is the most distributed compression format, it works just like Lzop, by focusing by default on speed with good compression. But it can't beat Lzop in speed, even when compressing in level 1 it will be fairly slower in matter of seconds, although it still beats it in the final size. When compressing with Lzop in level 9, the speed is getting ridiculously slow and the final size doesn't beat Gzip with its default level where Gzip is doing the job faster anyway.

Bzip2 is noise between LZMA and Gzip. It is very distributed as default format nowadays because it beats Gzip in term of compression ratio. It is of course slower for compression, but easily spottable is the decompression time, it is the worst amongst all in all cases.

Both LZMA and LZMA2 perform almost with an identical behavior. They are using dynamic memory allocation, unlike the other formats, where the higher the input data the more the memory is allocated. We can see the evolution of LZMA is using less memory but has on the other hand a higher cost on CPU time. And we can see they have excellent decompression time, although Lzop and Gzip have the best scores but then again there can't be excellent compression ratio and compression time. The difference between the compression ratio of the two formats is in the order of hundred of kilo bytes, well after all it is an evolution and not a revolution.

On a last note, I ran the benchmarks on an Intel Atom N270 that has two cores at 1.6GHz but I made sure to run the compression tools with only one core.

A few interesting links:

Benchmarking Compression Tools

  • September 6, 2010
  • Mike Massonnet
Comparison of several compression tools: lzop, gzip, bzip2, 7zip, and xz.
  • Lzop: small and very fast yet good compression.
  • Gzip: fast and good compression.
  • Bzip2: slow for both compression and decompression although very good compression.
  • 7-Zip: LZMA algorithm, slower than Bzip2 for compression but very good compression.
  • Xz: LZMA2, evolution of LZMA algorithm.

Preparation

  • Be skeptic about compression tools and wanna promote the compression tool
  • Compare quickly old and new compression tools and find interesting results
So much for the spirit, what you really need is to write a script (Bash, Ruby, Perl, anything will do) because you will want to generate the benchmark data automatically. I picked up Ruby as it's nowadays the language of my choice when it comes to any kind of Shell-like scripts. By choosing Ruby I have a large panel of classes to process benchmarking data, for instance I have a Benchmark class (wonderful), I have a CSV class (awfully documented, redundant), and I have a zillion of Gems for any kind of tasks I would need to do (although I always avoid them).

I first focused on retrieving the data I was interested into (memory, cpu time and file size) and saving it in the CSV format. By doing so I am able to produce charts easily with existing applications, and I was thinking maybe it was possible to use GoogleCL to generate charts from the command line with Google Docs but it isn't supported (maybe it will maybe it won't, it's up to gdata-python-client). However there is an actual Google tool to generate charts, it is the Google Chart API that works by providing a URI to get an image. The Google Image Chart Editor website helps you to generate the chart you want in a friendly WYSIWYG mode, after that it is just a matter of computing the data into shape for the URI. But well while focusing on the charts I found the Ruby Gem googlecharts that makes it friendly to pass the data and save the image.

Ruby Script

The Ruby script needs the following:
  • It was written with Ruby 1.9
  • Linux/Procfs for reading the status of processes
  • Googlecharts: gem install googlecharts
  • ImageMagick for the command line tool convert (optional)
The Ruby script takes a path as argument, with which it creates a tarball inside a tmpfs directory in order to avoid I/O latencies from a hard-drive. Next it runs a number of commands over the tarball from which it collects benchmark data. The benchmark data is then saved inside CSV files that are reusable within spreadsheet applications. The data is also reused to retrieve charts from the Google Chart API and finally it calls the ImageMagick tool ''convert'' to collect the charts inside a single image. The summary displayed on the standard output is also saved inside a text file.

The script is a bit long for being pasted here (more or less 300 lines) so you can download it from my workstation. If the link doesn't work make sure the web browser doesn't encode ~ (f.e. to "%257E"), I've seen this happening with Safari (inside my logs)! If really you are out of luck, it is available on Pastebin.

Benchmarks

The benchmarks are available for three kinds of data. Compressed media files, raw media files (image and sound, remember that the compression is lossless), and text files from an open source project.
Media Files
Does it make sense at all to compress already compressed data. Obviously not! Let's take a look at what happens anyway.


As you see, compression tools with focus on speed don't fail, they still do the job quick while gaining a few hundred kilo bytes. However the other tools simply waste a lot of time for no gain at all.

So always make sure to use a backup application without compression over media files or the CPU will be heating up for nothing.
Raw Media Files
Will it make sense to compress raw data? Not really. Here are the results:


There is some gain in the order of mega bytes now, but the process is still the same and for that reason it is simply unadapted. For media files there are existing formats that will compress the data lossless with a higher ratio and a lot faster.

Let's compare lossless compression of a sound file. The initial WAV source file has a size of 44MB and lasts 4m20s. Compressing this file with xz takes about 90s, this is very long while it reduced the size to 36MB. Now if you choose the format FLAC, which is doing lossless compression for audio, you will have a record. The file is compressed in about 5s to a size of 24MB! The good thing about FLAC is that media players will decode it without any CPU cost.

The same happens with images, but I lack knowledge about photo formats so your mileage may vary. Anyway, except the Windows bitmap format, I'm not able to say that you will find images uncompressed just like you won't find videos uncompressed... TIFF or RAW is the format provided by many reflex cameras, it has lossless compression capabilities and contains many information about image colors and so on, this makes it the perfect format for photographers as the photo itself doesn't contain any modifications. You can also choose the PNG format but only for simple images.
Text Files
We get to the point where we can compare interesting results. Here we are compressing data that is the most commonly distributed over the Internet.


Lzop and Gzip perform fast and have a good ratio. Bzip2 has a better ratio, and both LZMA and LZMA2 algorithms even better. We can use an initial archive of 10MB, 100MB, or 400MB, the charts will always look alike the one above. When choosing a compression format it will either be good compression or speed, but it will definitely never ever be both, you must choose between this two constraints.

Conclusion

I never heard about the LZO format until I wanted to write this blog post. It looks like a good choice for end-devices where CPU cost is crucial. The compression will always be extremely fast, even for giga bytes of data, with a fairly good ratio. While Gzip is the most distributed compression format, it works just like Lzop, by focusing by default on speed with good compression. But it can't beat Lzop in speed, even when compressing in level 1 it will be fairly slower in matter of seconds, although it still beats it in the final size. When compressing with Lzop in level 9, the speed is getting ridiculously slow and the final size doesn't beat Gzip with its default level where Gzip is doing the job faster anyway.

Bzip2 is noise between LZMA and Gzip. It is very distributed as default format nowadays because it beats Gzip in term of compression ratio. It is of course slower for compression, but easily spottable is the decompression time, it is the worst amongst all in all cases.

Both LZMA and LZMA2 perform almost with an identical behavior. They are using dynamic memory allocation, unlike the other formats, where the higher the input data the more the memory is allocated. We can see the evolution of LZMA is using less memory but has on the other hand a higher cost on CPU time. And we can see they have excellent decompression time, although Lzop and Gzip have the best scores but then again there can't be excellent compression ratio and compression time. The difference between the compression ratio of the two formats is in the order of hundred of kilo bytes, well after all it is an evolution and not a revolution.

On a last note, I ran the benchmarks on an Intel Atom N270 that has two cores at 1.6GHz but I made sure to run the compression tools with only one core.

A few interesting links:

Moblin blazing fast

  • April 30, 2010
  • Mike Massonnet
I updated my netbook to give it a new look. I switched the Xfce Panel against bmpanel2 and changed the background (the previous definitelly lasted very long.) Not much changes, but I topped a cold boot of about six seconds, always faster baby :-P And the window manager is OpenBox by the way.


The only real useful entry missing in this panel is a battery monitor. At least I have an indicator over the keyboard that starts blinking when there is about three percents left. What I like about this panel is the cool themes that it is provided with, however the configuration is set through a hand-written configuration file which sucks but what do you want, it is extremely lightweight on the other hand.

Update: Should I mention I totally forgot about the Xfce power manager? Well I did, and it is provided with a notification icon displaying the battery status :-) However I had to fix the default ACPI script related to the lid, since HAL doesn't list it, in order to get the netbook to go into sleep.

Moblin blazing fast

  • April 30, 2010
  • Mike Massonnet
I updated my netbook to give it a new look. I switched the Xfce Panel against bmpanel2 and changed the background (the previous definitelly lasted very long.) Not much changes, but I topped a cold boot of about six seconds, always faster baby :-P And the window manager is OpenBox by the way.


The only real useful entry missing in this panel is a battery monitor. At least I have an indicator over the keyboard that starts blinking when there is about three percents left. What I like about this panel is the cool themes that it is provided with, however the configuration is set through a hand-written configuration file which sucks but what do you want, it is extremely lightweight on the other hand.

Update: Should I mention I totally forgot about the Xfce power manager? Well I did, and it is provided with a notification icon displaying the battery status :-) However I had to fix the default ACPI script related to the lid, since HAL doesn't list it, in order to get the netbook to go into sleep.

Vala Notes Plugin

  • March 11, 2009
  • Mike Massonnet
Or better, there is Vala in the Notes plugin. It's been a long time I thought about a hypertext view widget for the notes plugin, so it can highlight links and open them on click, and doing this in pure C/GObject is quite a PITA because there is a lot to take care about (more lines of code), and then you didn't start thinking about the whole functions of the object. Now this is retro with the presence of Vala. I played with Vala some time ago, doing some very rudimentary hello worlds, and I never had a chance to really write something in Vala, untill two days ago. I started to write a very dummy object on top of GtkTextView that implements the simple undo/redo feature I wrote inside notes.c and it was very fast and easy to backport from the C code to Vala, and this gave me a very good start with Vala (now that was one Vala too much, wasn't it? anyway...). Yesterday I added skel functions to support hyperlinks which I finished today. Finally I integrated the Vala object inside the notes plugin in a way that it compiles to C code when you are in MAINTAINER_MODE, which means for end-users they won't need Vala but only gcc.

Now for those interested into Vala, here is the file I played with: hypertext.vala. This source contains at the end of the HypertextView class, another class that contains a main function so it can be compiled to a binary. This proves how easy it is to test a class, and all you need to do is to run the following command: valac --pkg=gtk+-2.0 hypertextview.vala && ./hypertextview.
There are many samples available with the source of Vala and on Gnome Live. The tutorial covers important points, the FAQ too, but the documentation is a little less interesting if you already know GObject IMHO.
One important thing I learned about Vala was the difference between the out and ref arguments.

If you have a hard time at finding the right method definitions, look into /usr/share/vala/vapi/gtk+-2.0.vapi for instance for GTK+. There you can quickly find any function name you now from the C API, for instance if you want to have a look at gtk_text_view_get_iter_at_location search for get_iter_at_location. By scrolling up you will see that you are in the class Gtk.TextView. Vapis are very easy to read.

I am very interested into porting the objects of the Xfmpc project to Vala, and then start trying out the plugin sample (loading modules during runtime)... I hope my fellow will like that idea :-)

Now for the people interested to develop Vala classes with VIM I have some tips. First follow these instructions in order to get Vala syntax. Then I suggest you install the Tag List plugin, and to get it working with Vala you will need to add the following lines to your vimrc configuration:
" Work-around Tag List
let tlist_vala_settings='c#;d:macro;t:typedef;n:namespace;c:class;'.
\ 'E:event;g:enum;s:struct;i:interface;'.
\ 'p:properties;m:method'
If you don't know about folding then you miss a lot of VIM culture, in fact you can fold/unfold brackets by going over a bracket and typing zf% in command mode. And that's all folk, thanks for reading til here.