Tweaking Vim For Fun and Profit

Vim, to certain extent, amazes me. It can be tweaked in any number of ways. To start with, set your xterm or whatever terminal you use to 256 color palette, as long as it supports 256 color palette. You can check this in your terminfo installation--never thought of what the h*** terminfo and ncurses are for until this point--which for xterm, placed in /usr/share/terminfo/x/*. The file named xterm-256color in that path represents 256-color-xterm. Use the tput command to check if your terminal in X supports 256 color palette, as follows:

tput colors

The output will be similar to:

darmawan@opunaga:~/_Projects/******/svn_checkout/trunk$ tput colors               
256

notice the 256 which means it supports 256 colors. If you're using Xfterm4 in XFCE you can easily convert its setting to 256 colors by entering "xterm-256color" to the "$TERM setting" in its Edit|Preferences, akin to this:


Once you get the 256-color terminal, it's the time to tinker with Vim. First, download a good colorscheme for Vim. I recommend zenburn. Then place it in the system-wide vim color setting, which in my case placed in /usr/share/vim/vim71/colors directory. Then do some editing to your ~/.vimrc. Add the following lines:

set nobackup          " This line is not related to vim visual tuning, it can be omitted
set writebackup       " This line is not related to vim visual tuning, it can be omitted
set number            " Show numbers on the left of each line
:colorscheme zenburn  " Set the colorscheme to zenburn

Now, with some vim command combination, e.g. '0 (recall last buffer), '1 (recall next to last buffer), split (^Ws), vsplit (^Wv), exchange window (^Wx). You will get something like this:




And by using DejaVu Sans Mono (7 pitch) in Gvim, this is what you'll get:



All in all, Read The Friendly Manual with ":help history" or other topics. It helps a lot to get you up to speed.

Get Ready for World Domination

Starting to make junk post =))

ATI Propietary Linux Driver - Xine - Video Overlay

With the Slamd64 up and running, I noticed a problem when using Xine to play Videos. I cannot zoom the video scene correctly and the video control panel is not shown in fullscreen mode. I have to force Xine to close in fullscreen mode with Alt+F4.
I found that this is something to do with a "miscommunication" between the ATI Propietary Linux Driver a.k.a ATI Catalyst for Linux and the X server that handles image buffering. I'm using ATI Catalyst for Linux X86_64 version 8.50.3 (filename: ati-driver-installer-8-6-x86.x86_64.run) and the default X server that comes with Slamd64 12.1. It turns out the the video overlay mechanism is not set correctly. So, I have to set it manually with aticonfig. This is the snippet of aticonfig options for video overlay:

darmawan@opunaga:~/test $ aticonfig --help | less

Screen-Related Options:
 --ovt, --overlay-type=STRING
       Change the overlay for the X server.  STRING can be one of:
           opengl
           Xv
           disable

I set the driver setting (as root) with aticonfig:

aticonfig --ovt=Xv

This is because OpenGL is not working nicely with Xine yet in my machine. Note that I'm using Xinelib 1.11 and Xine UI 0.99.5 on system with Turion64 1.8GHz, 1GB RAM and ATI X200M (RS480 northbridge and SB400 southbridge chipset). After trying to force video overlay with opengl and do some tests, I confirm that none of the ATI Catalyst for Linux works. Neither Catalyst version 8.50.3 nor 8.51.3 can work correctly when I used Xine with video overlay set to opengl. Only Xvideo a.k.a Xv extension can work correctly with Xine in my RS480-based system.



Helpful links:
http://ati.amd.com/support/drivers/linux64/linux64-radeon.html
http://wiki.cchtml.com/index.php/Main_Page

Xfterm4 Problem (Solved)

I got this warning in Xfterm4 due to unknown reason:

WARNING: terminal is not fully functional (press RETURN)

when I run more, less or CTRL-L and some other commands in Xfterm4. With some googling effort, I don't seem to find the solution. All I know that this must be terminal setting problem. I went to check every terminal related setting and I found that by replacing
~/.config/Terminal/terminalrc
with one from the other login, everything back to normal again.

Slackbuild Scripts

This a gstreamer slackware build script ported to Slamd64. It's only a quick-hack. But it's working as expected. There is a downside though. I should've been setting the target MANPATH to /usr/man, but I set to /usr/share/man instead. Which is wrong.

#!/bin/bash
#
# gstreamer.SlackBuild
# code: Vicious (michal@scxd.info); improvements: Zielony (e-pl@o2.pl)
# adapted for x86_64 and local source Pinczakko (darmawan_salihun@yahoo.com)
# Pinczakko Note: Use at your own risk!
#
set -e
# PACKAGE GENERAL INFO [EDIT]
PKGNAME=gstreamer
VERSION=0.10.20
BUILD=1X
ARCH=x86_64
SRC_PATH=gstreamer-$VERSION.tar.bz2

CWD=`pwd`
TMP=/tmp/$PKGNAME
PKG=$TMP/package

if [ ! -d $TMP/$PKGNAME-$VERSION ]; then
rm -rf $PKG
mkdir -p $PKG/install

# PACKAGE DESCRIPTION  [EDIT]
cat << 'SLACKDESC' | fmt -w $(( 80 - `echo $PKGNAME | wc -c` - 3 )) | perl -pe "s/^/$PKGNAME: /" > $PKG/install/slack-desc
GStreamer (multimedia framework)

GStreamer is a library that allows the construction of graphs of media-handling components,
ranging from simple Ogg/Vorbis playback to complex audio (mixing) and video (non-linear editing) processing.
Applications can take advantage of advances in codec and filter technology transparently.
Developers can add new codecs and filters by writing a simple plugin with a clean, generic interface.

       Package prepared by Zielony (e-pl@o2.pl)
       Adapted for Slamd64 by Pinczakko (darmawan_salihun@yahoo.com)
SLACKDESC


# step 1: COPY SOURCE
case "${SRC_PATH//*\/}" in
       *.tar.bz2) EXTENSION="tar.bz2"; DECOMPRESS="tar jxvf" ;;
       *.tar.gz)  EXTENSION="tar.gz";  DECOMPRESS="tar zxvf" ;;
       *.tgz)     EXTENSION="tgz";     DECOMPRESS="tar zxvf" ;;
       *.zip)     EXTENSION="zip";     DECOMPRESS="unzip" ;;
esac
PKGFNAME="$PKGNAME-$VERSION.$EXTENSION"
cp -v $SRC_PATH $TMP

# Go to build directory
cd $TMP

# step 2: UNPACK SOURCE AND PREPARE PACKAGE
$DECOMPRESS $PKGFNAME

DIRNAME=`ls -c | head -1 | cut -d / -f 1`
if [ "$DIRNAME" != "$PKGNAME-$VERSION" ]; then mv $DIRNAME $PKGNAME-$VERSION; fi

chown root:root $TMP -R
fi

cd $TMP/$PKGNAME-$VERSION

case "$ARCH" in
       "i686")   SLKCFLAGS="-O2 -march=i686 -mtune=i686" ;;
       "i486")   SLKCFLAGS="-O2 -march=i486 -mtune=i686" ;;
       "i386")   SLKCFLAGS="-O2 -march=i386 -mcpu=i686" ;;
       "s390")   SLKCFLAGS="-O2" ;;
       "x86_64") SLKCFLAGS="-O2 -fPIC" ;;
       *)        SLKCFLAGS="-O2" ;;
esac

if [ ! -e 'Makefile' ]; then
CFLAGS="$SLKCFLAGS" CXXFLAGS="$SLKCFLAGS" ./configure \
       --prefix=/usr \
       --disable-debug \
       --disable-static \
       --libdir=/usr/lib64 \
       --mandir=/usr/share/man \
       --sysconfdir=/etc
#       --sysconfdir=/etc \
#       --program-prefix="" \
#       --program-suffix="" \
#       $ARCH-slamd64-linux
fi
make
make install DESTDIR=$PKG
rm $PKG/usr/bin/*-`echo $VERSION | perl -pe 's/^([0-9]+\.[0-9]+)\.?.*/$1/'`
for i in $PKG/usr/share/man/*/*-`echo $VERSION | perl -pe 's/^([0-9]+\.[0-9]+)\.?.*/$1/'`.1; do
       mv -f $i ${i%-*}
done
rm -rf $PKG/usr/share/gtk-doc

# step 3: STRIP BINARIES & GZIP MANUALS
cd $PKG
( find . | xargs file | grep "executable" | grep ELF | cut -f 1 -d : \
       | xargs strip --strip-unneeded 2> /dev/null
 find . | xargs file | grep "shared object" | grep ELF | cut -f 1 -d : \
       | xargs strip --strip-unneeded 2> /dev/null
 find . | xargs file | grep "current ar archive" | grep ELF | cut -f 1 -d : \
       | xargs strip --strip-debug 2> /dev/null )

find $PKG/usr -regex '.+/man/\(.+?/\)?man./.+' -exec gzip -9 \{} \;

# step 4: CREATE PACKAGE & CLEAN TMP
if [ `find . | wc -l` -le 1 ]; then
       echo "Brak plików pakietu!"
else
       ( requiredbuilder -y -s $PKG/install $PKG )
       makepkg -l y -c n $CWD/$PKGNAME-$VERSION-$ARCH-$BUILD.tgz
       if [ "$1" != "-nc" ]; then rm -rf $TMP; fi
fi

XFCE 4.4 "Special Key" Bindings

The concept of key binding in XWindow has always been vague to me until I fix the key binding in my window manager. I'll explain how it works with an example. So, I have this problem of using the "windows" key to open the main menu in XFCE 4.4 in my Slamd64 12.1. This key is called Xfce-popup-menu in Xfce keyboard setting. The key is not detected by Xfce, the Window Manager. Here's how I got it working.

1. Find the keycode of the problematic key. I use xev to find the keycode. Run xev from an X terminal and set the focus to xev window and watch for the keycode in the terminal from which you launch xev. I found that the "windows" keykode is 115



2. Edit/create .Xmodmap file in your home directory and "bind" the keycode 115 into one of the key symbol recognized by the window manager. /usr/share/X11/XKeysymDB contains the list of key symbols for X11. My .Xmodmap reads like this:
   

   
   keycode 115 = XF86MenuKB
   keycode 162 = XF86AudioPlay
   keycode 164 = XF86AudioStop
   keycode 160 = XF86AudioMute
   keycode 174 = XF86AudioLowerVolume
   keycode 176 = XF86AudioRaiseVolume
   keycode 178 = XF86WWW
   

   
   



3. Run xmodmap .Xmodmap to activate the keycode-to-key-symbol binding.


4. Then map the key symbol to the window manager keyboard setting. In XFCE 4.4 open Settings|Keyboard Settings menu then select the shortcut tab and then create new theme then select add. In the dialog that's shown, enter the command that you would like to execute when the key is pressed. In my case I enter: Xfce-popup-menu and in the subsequent dialog I press the "windows" key to assign the binding in XFCE. This will bind the X86MenuKB key symbol to Xfce-popup-menu command.
   

Links:

http://wiki.xfce.org/faq
http://gentoo-wiki.com/HOWTO_Use_Multimedia_Keys#Setting_up_xmodmap

Slamd64 OpenOffice Installation Fix

I've just migrated to Slamd64 12.1 and found out that the default OpenOffice 2.4.0 installation source from SUN cannot be installed correctly. I wander around and I found these clues:

• Open Office colors
  
• A working x86_64 openoffice
  
• http://slackbuilds.org/repository/12.1/office/openoffice.org/

So, the solution is to download the x86_64 version of OpenOffice 2.4.1 from:
ftp://ftp.linux.cz/pub/localization/OpenOffice.org/2.4.1/

Then prepare the required slackbuild scripts.

Nonetheless, there are still few things need to be fixed in the slackbuild package above. These are the steps that I did to make it work:

• Place the openoffice 2.4.1 x86_64 file in the same directory as the unpacked slackbuild files.
  
• Edit the openoffice.org.Slackbuild file in order to make it to point to the right "target" files. It looks like the following when you're done:
  

  
  #!/bin/bash
  
  # Slackware build script for OpenOffice.org (binary repackaging)
  
  # Copyright 2006-2008  Robby Workman, Northport, Alabama, ASA
  # All rights reserved.
  #
  # Redistribution and use of this script, with or without modification, is
  # permitted provided that the following conditions are met:
  #
  # 1. Redistributions of this script must retain the above copyright
  #    notice, this list of conditions and the following disclaimer.
  #
  #  THIS SOFTWARE IS PROVIDED BY THE AUTHOR "AS IS" AND ANY EXPRESS OR IMPLIED
  #  WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
  #  MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.  IN NO
  #  EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
  #  SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
  #  PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
  #  OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
  #  WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
  #  OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
  #  ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  
  # Thanks to Sandman1, Larhzu, and MacIver for early assistance.
  # Thanks to Fred Emmott (http://slamd64.com) for some better code in a few
  #  places and ideas to include the Optimization Solver and disable javaldx.
  # Thanks to eroc for the idea to include support for other languages.
  #
  # Modified for SLAMD64 and 64 bit build kingbeowulf@gmail.com
  
  PRGNAM=openoffice.org
  VERSION=2.4.1
  ARCH=${ARCH:-x86_64}   # The binaries are built for i586 - leave this alone for Slackware
  BUILD=${BUILD:-1}
  TAG=${TAG:-ewk}
  
  CWD=$(pwd)
  TMP=${TMP:-/tmp/ewk}
  PKG=$TMP/package-$PRGNAM
  OUTPUT=${OUTPUT:-/tmp}
  
  if [ "$ARCH" = "x86_64" ]; then
   TARGET=${TARGET:-X86-64}
  else
   TARGET=${TARGET:-Intel}
  fi
  
  # This should allow you to either pass a different value of OOLANG when you
  # run the script (OOLANG=pt-BR ./openoffice.org.SlackBuild for example) or
  # change it in this script.  Note that you will need to have the correct
  # tarball in the build directory for this to work...
  # You can get localized tarballs from the following location:
  # ftp://ftp.free.fr/mirrors/ftp.openoffice.org/localized/$OOLANG/$VERSION/
  # Thanks to Niki Kovacs for finding this :-)
  OOLANG=${OOLANG:-en-US}
  PKG_LANG=$(echo $OOLANG | sed s/-/_/)   # Leave this alone
  
  # If you want to disable java support by removing executable permissions
  # form OOo's java loader (this will not affect other apps), set this
  # variable to "YES"   Default is "NO"
  # According to Fred Emmott, this is *highly* desirable on 64 bit systems
  DISABLE_JAVA=${DISABLE_JAVA:-YES}
  
  # If you want to include the new experimental Optimization Solver,
  # download "scsolver.uno.zip" from the following location:
  # http://wiki.services.openoffice.org/wiki/Optimization_Solver
  # and place it in the same directory as the SlackBuild script ($CWD)
  # Set the following variable to "YES"   Default is "NO"
  ADD_SOLVER=${ADD_SOLVER:-NO}
  
  # Yes, I know there is a Slackware integration file in the desktop-integration
  # directory, but it's worthless to us.  I mailed the maintainer of this
  # module with suggestions on how to make it more compliant with standard
  # Slackware packaging, but I received no response.  Anyway, to sum up, we're
  # not using that file...
  
  set -e # Require the script to exit if any command fails
  
  rm -rf $PKG
  mkdir -p $TMP $PKG $OUTPUT
  cd $TMP
  
  # Ignore this - it's just to get the toplevel directory name of the
  # extracted tarball archive
  # Top level DIR is RPMS in this particular x86_64 build so add another level...
  if [ "$ARCH" = "x86_64" ]; then
   SOURCEDIR=${PRGNAM}
   rm -rf $SOURCEDIR
   mkdir $SOURCEDIR
   cd $SOURCEDIR
   tar xvzf $CWD/OOo_${VERSION}_Linux${TARGET}_install_${OOLANG}.tar.gz
   cd $TMP
  else
   SOURCEDIR=$(tar -tzf $CWD/OOo_${VERSION}_Linux${TARGET}_install_${OOLANG}.tar.gz | head -1 | tr -d \/)
   rm -rf $SOURCEDIR
   tar xvzf $CWD/OOo_${VERSION}_Linux${TARGET}_install_${OOLANG}.tar.gz
  fi
  
  cd $SOURCEDIR/RPMS/
  mv desktop-integration/openoffice.org-freedesktop-menus-*.noarch.rpm .
  for FILE in *.rpm ; do rpm2cpio < $FILE | cpio -imdv ; done 
  rm -rf desktop-integration *.rpm 
  mv opt usr $PKG 
  cd $PKG  
  
  # Create symlinks in /usr/bin to actual binaries and edit the 
  # included wrapper scripts in /usr/bin to correct the paths 
  ( cd $PKG/usr/bin   
  for FILE in sbase scalc sdraw simpress smath soffice spadmin swriter unopkg ; 
  do     
    rm -f $FILE     
    ln -sf ../../opt/openoffice.org2.4/program/$FILE . ;   
  done   
  
  for i in $(find . -type f) ; do sed -i 's/etc/opt/g' $i ; done 
  )  
  
  # Correct symlinks in /usr/share/applications 
  ( cd $PKG/usr/share/applications   
  for APP in base calc draw extension impress math printeradmin writer qstart ; 
  do     
    rm -f openoffice.org2.4-$APP.desktop     
    ln -sf ../../../opt/openoffice.org2.4/share/xdg/$APP.desktop \         
      openoffice.org2.4-$APP.desktop ;   done 
  )  
  
  # Fix Exec commands in the desktop files 
  # See http://bugzilla.xfce.org/show_bug.cgi?id=2430 
  # --not going to worry about this right now since using KDE and 2.4.1 (kingbeowulf) 
  patch -p1 < $CWD/desktop-file-fix-2.4.1.diff  
  
  # Move docs to their correct locations 
  mkdir -p $PKG/usr/doc/$PRGNAM-$VERSION 
  for i in README README.html LICENSE LICENSE.html THIRDPARTYLICENSEREADME.html ; 
  do   
    mv $PKG/opt/openoffice.org2.4/$i $PKG/usr/doc/$PRGNAM-$VERSION/$i ; 
  done 
  cat $CWD/$PRGNAM.SlackBuild > $PKG/usr/doc/$PRGNAM-$VERSION/$PRGNAM.SlackBuild
  
  # Disable Java support if desired (see above)
  if [ "$DISABLE_JAVA" = "YES" ]; then
  chmod -x $PKG/opt/openoffice.org2.4/program/javaldx
  fi
  
  # Add optimization solver if desired (see above)
  if [ "$ADD_SOLVER" = "YES" -a -f "$CWD/scsolver.uno.zip" ]; then
  ( cd $PKG/opt/openoffice.org2.4
    program/unopkg add --shared $CWD/scsolver.uno.zip
  )
  fi
  
  mkdir -p $PKG/install
  cat $CWD/slack-desc > $PKG/install/slack-desc
  cat $CWD/doinst.sh > $PKG/install/doinst.sh
  
  # Fix ownership and permissions and make the package
  chown -R root:root .
  find . -type d -exec chmod 755 {} \;
  chmod -R u+rw,go+r-w,a-s .
  /sbin/makepkg -c n -l y $OUTPUT/$PRGNAM-${VERSION}_${PKG_LANG}-$ARCH-$BUILD$TAG.tgz
  
  

  
  Note that the original script in this post points to a different version of the desktop related file that need to be fixed in XFCE (I'm using XFCE as my window manager) and also it points to a different filename for the original openoffice installation source from the link above. Therefore, you have to rename the file from File: OOo_2.4.1_LinuxX86-64_install_en-US_rpm.tar.gz to OOo_2.4.1_LinuxX86-64_install_en-US.tar.gz or edit the slackbuild script to refer to it correctly. I opted for the former.
  
• Run the slackbuild script (openoffice.org.Slackbuild) to create an installable package. The result will be placed in /tmp. Its name will be "openoffice_something.tgz". Note that it's quite weird because I have to do this build process as root to complete it correctly.
  
• As root, run installpkg to install the result from /tmp into the real installation directory
• Now, you should have the correct link in your XFCE main menu (in the panel)

Anyway, after this I think I need to learn about the mechanics of the Slackbuild scripts.

Something to Remember..

Have nothing to say. Maybe one day I will remember this setup and laughing all the way home :))

Since 12XX

Probably you've seen it in advertising or something similar, the word "since 19xx" or "since 18xx", or "since 17xx". These words are meant to imply how long has a product being made and the craft-man-ship of the corresponding company who makes the product. There's also a very high possibility a University or a College being labeled as such. But, have you ever seen something like, "since 1240"? I'm quite sure it's a very rare case. Let's see an example then, this University:



The University of Siena, founded in the 13th century (explanation on wikipedia). A very old university. Probably only university in Florence or Padua that are older in the world. Other universities of its age have long been gone. In my opinion, this is impressive. It has been there for 8 centuries, well preserved over the course of history. It's very unfortunate that I have yet to locate the original campus because the one in the photo above is a former Psychiatric Hospital building, that was converted to be used for University of Siena. Even then, it's still an impressive mileage to preserve the institution for such a long time.

There also this joke from one of the university professor that the boys are kept separated from the more "sane" girls in the second floor of the building. This implies that the boys are "less-civilized" than the girls ;-). I think so, he..he..he..

One of The Oldest Banking Institution in The World

The photo below is taken in front of a Bank that started as early as 1492. Yes, exactly the same year as Christopher Columbus landed in America, what a coincidence!



It is located in the city of Siena, Tuscany.

The Forward+Reverse Engineering Approach

In some certain cases it's not possible to finish an engineering task just by doing a forward engineering approach (doing a design, prototyping and so on until you get the product to market) or vice versa, i.e. the task cannot be finished just by doing a reverse engineering approach (a.k.a tear-down and document everything). In these very peculiar case a combined approach of forward and reverse engineering is required.

I've never been into such a complicated problems like this before but in these last few weeks, the combined approach is clearly the only way to solve the problem. I noticed from books that I read a few years ago that usually a reverse-engineering task involved a legacy software where you couldn't find the documentation anywhere anymore. I can say that this is the "hell's pit" for a software developer, but I finally got into the same case.

The story starts with an Software Development Kit (SDK) that suppose to work on our target hardware in the office. Nonetheless, after 2 months tinkering with it I finally figure out that none of the documentation is exactly inline with the code in the SDK. Therefore, I have to create patches and patches and patches every day to make everything works as intended. OK, I thought everything was finished by then, but reality hits me. The previous version of the SDK produced an almost entirely different format for the output binary and moreover the tools to create this binary is also coming only in executable form in the SDK. I'll say this is take one of the "hell's pit" for me. Because I have to reverse engineer the file format from an SDK that supposed to be backward compatible with the previous version. You might ask why don't I request the previous version of the SDK? Well, it's impossible because apparently it's not there in the hardware vendor's FTP server. I try to ask them politely but they don't know either. I suppose, the development of the SDK is outsourced to some third party guys somewhere in Taiwan and this guy cannot be contacted anymore a.k.a disappear after he shows a working demo of the SDK and he didn't even take into account backward compatibility into account. Yeah, this is still take one boys and girls.

Now, take two. So, we have this driver for the hardware coming only in binary form, yeah binary form! We bought 1K units and we still got the binary form of the driver? This is insane! But taking into account the population of China, 1K units is nothing for them. Lets say, this Taiwanese hardware vendor sold most of their units in China then they won't provide support or a complete source code for those who buys only 1K units. I heard form the one who purchase our units in the office that unless you're buying 10K units you won't even be in their radar, sic.

Now, take three. Finally I decided that these things must be regarded as legacy software and a forward+reverse engineering approach would be very important to finish my task as I described above. Welcome to the "hell's pit" ladies and gentlemen.

Overall, this is an entirely new ground for me. But, I'm quite happy and challenged to see how far I can get with it. I'll give them a lesson. A very hard lesson. But, I hope and I think this won't shake up the industry ;-).

CD/DVD Burning and Gnome's Nautilus

It's been ages since the last time I burn a CD in Linux. Back then I would use X-CD-Roast. Today, I found that it's much easier to do that with the built in CD/DVD writer front-end in Nautilus. The only drawback is I have to log in as root when invoking the CD/DVD writer front-end. In order not to run at full root privilege, I spawn a new shell and invoke the Nautilus CD/DVD writer front-end with:

nautilus --no-desktop --browser burn:///

This way, I was greeted with the following window (or widget if you prefer the *NIX nomenclature)



The rest is just a drag and drop operation.

Anyway, if I've given the permission for reading and writing to the associated CD/DVD device to normal user previously, I shouldn't be bothered to log in as root in the first place.

The Fifo and WLAN Ndiswrapper driver bug in kernel 2.6.24.3

Yesterday, I have to adapt my kernel module because of a new device that I have to connect to my linux laptop. This device is actually a serial-to-usb device. It is based on Future Technologies FTDI fifo chip. Because my optimized 2.6.24.3 kernel didn't include the support for this chip, I have to compile the module and create a new kernel image with proper linkage with the new driver. The kernel compilation went OK.

Unfortunately, problems begin to show up with my WLAN ndiswrapper-based driver. The WLAN driver which is somehow linked to the ssb kernel module cannot work when the FTDI serial-to-USB FIFO driver is also loaded. The Ndiswrapper that I'm using is Ndiswrapper version 1.52. After trying to add list of suspected drivers into the blacklist driver list (/etc/modprobe.d/blacklist) in order to prevent the offending driver from loading, I found out that ssb module would always be loaded because it's linked very closely with the FTDI fifo driver. Finally, I decided to try to upgrade my kernel in the hope that the new native linux driver for Broadcom BCM4318 will work, to overcome my inability to use my WLAN in Linux. Upgrading to the latest kernel, i.e. version 2.6.25.9 proves to be a well-working solution. So, now I have all my hardware working as expected. The only draw back with the current driver is I have to disable my Ethernet network adapter prior to activating the WLAN interface. Otherwise, the WLAN interface cannot be activated.

Moreover, when I decided to upgrade my ATI video card Linux driver to it's latest version, I found out that this kernel version (2.6.25.9) plays well with the new ATI driver (Catalyst v8.50.3, i.e. filename: ati-driver-installer-8-6-x86.x86_64.run). I finally able to set the video resolution in Linux into the LCD's wide screen maximum resolution, i.e. 1280x768, which previously would always stuck at 1024x768, even if I set the ModeLine parameter to 1280x768 in /etc/X11/xorg.conf.