Protecting Your Privacy on Linux

Some times you need to protect your documents containing sensitive information from prying eyes. Simply enforcing access-control on a document (e.g. "chmod 600 foobar") is not enough in such cases as it can still be read by those with super-user access or with physical access to your storage media (e.g. when your laptop gets stolen or you misplace your backup media). It is also ineffective when you use on-line back-up solutions like SkyDrive, Google Docs or Dropbox. Fortunately Linux provides several tools to help you here depending on your needs.

Read More...

Google Chrome on Slackware

Google Chrome has been out for a while now, but only on Windows. There are pre-release Linux builds of Chrome, but they work out-of-the-box only on Ubuntu or Debian. As a Slackware 12.1 user, I couldn't therefore check out this browser and I was too lazy to build it myself. Fortunately for me, it turns out that the available builds can be made to work on Slackware with a little effort. Chrome turns out to be surprisingly usable and fast on Linux. That said, I'm not shifting from Firefox to Chrome yet, at least not right away.

Read More...

Firefox 3

I have been using the release candidates of Firefox 3 on Linux for some time now. The experience has been quite good so far. I would encourage you to try it out for yourself - in fact, download it on the 17^th of June and help Mozilla set a world record.

Firefox 3 comes with quite a lot of fixes and improvements. The "Field Guide to Firefox 3" is a nice page summarising the more important improvements. It seems to have improved a lot in terms of memory usage and speed. You just have to use Gmail to see the difference in speed for yourself. Since I never open too many tabs, use too many extensions or keep the browser open for too long, I have never personally run into memory-usage issues with previous releases of Firefox and I can't really say if the improvements in this area are that drastic.

One of the more important fixes for Indian users of Firefox on Linux is its improved support for complex text layout, which is used in quite a few Indic scripts. I have complained about it before and I am happy to report that it now seems to work fairly well:

Devanagari Text Rendering on Linux: Firefox 2 (left) v/s Firefox 3 (right)

The composite screen-shot above shows the difference between Firefox 2 and Firefox 3 when rendering Devanagari text (from Josh18) under Linux. I have circled some of the words that were rendered incorrectly by Firefox 2 and correctly by Firefox 3. (Click on the image above to see a larger version.)

It has not been all wonderful though. There are still some issues that make my experience with Firefox 3 less than ideal. The most egregious of these is how some web pages using Flash either cause Firefox 3 to freeze up or just crash with a segmentation fault (of course, this could be due to a badly-written Flash Player plug-in). The other issue that has persisted from Firefox 2 but now seems to have become worse for me is how Firefox would just freeze for a second or so every now and then, especially noticeable while scrolling up and down large web pages. This might be related to garbage-collection cycles, but I am not sure about it.

Incidentally while Firefox 3 itself mercifully does not require GNOME (I am a happy KDE-only user), its new crash-reporting tool does need a few of the GNOME libraries. This tool is now based on Google Breakpad. I found that the crash reporting tool itself would crash while trying to send a crash report to Mozilla. That was fixed only after I installed GConf, ORBit, libIDL, D-Bus and dbus-glib. It still failed to send the crash reports and it turned out that I must also install and configure Curl. Of course, ordinary Linux users with a typically-bloated Linux distribution would not run into such issues.

By the way, there is now a new pseudo-URL named "about:crashes" that would let you to lovingly admire the crash reports that your instance of Firefox has generated and submitted to Mozilla.

Disabling atime Updates

A recent article on KernelTrap highlights the high cost of supporting atime ("last-accessed time") updates on Linux file-systems. It has been suggested that desktop machines should just mount their file-systems using the "noatime" option to avoid this overhead.

Each time you read a file, its atime has to be updated. This can quickly become costly if you have applications that access a lot of small files. Most modern desktop environments, office suites, compilers (think of C/C++ headers), browsers, etc. fall into this category, so Linux takes a lot of unnecessary performance hit for data that is of interest only to a very small set of applications like tmpwatch. (Apparently even Windows has the same issue with NTFS.)

I have now changed the "/etc/fstab" on my PC to mount its file-systems using the "noatime" option. It does seem to have slightly improved the responsiveness of the desktop, though this could just be a placebo effect. On the other hand, in the KernelTrap article people have presented measurements that demonstrate the actual performance improvements brought about by using this option.

Indic Scripts and Linux

If you have the fonts for Indic scripts (for example, the Lohit fonts), Firefox on Linux is able to display the Devanagari text on sites like BBC Hindi and Google News in Hindi. (Devanagari is the primary writing system for languages like Hindi, Sanskrit, etc.) However, if you are using the builds released by mozilla.com, you would notice that the matras (diacritics) are not applied properly to form the correct ligatures. For example, the word "हिन्दी" ("Hindi") itself is not rendered properly. Konqueror does not suffer from such problems.

It turns out that Firefox does not support complex text layout because it doesn't use Pango in the officially-released builds (Firefox 3 will support it by default). You have to either compile it yourself from the source and enable the support for Pango by using --enable-pango, or use a build that has Pango enabled - for example, the builds provided by the Fedora Project. (Setting the environment variable MOZ_ENABLE_PANGO to "1" had no effect for me with Firefox 2.0.0.3.)

On Fedora Core 6 (FC6), it is very simple to get this working:

1. Install the fonts for the Indic scripts you are interested in. For example, "sudo yum install fonts-hindi" , "sudo yum install fonts-malayalam", "sudo yum install fonts-kannada", etc.
2. Install a Firefox build for Fedora using "sudo yum install firefox". Note that FC6 installs Firefox 1.5 by default - if you prefer Firefox 2.0 instead, you can install it using "sudo yum --enablerepo=development install firefox".

By the way, I recently came across Omniglot, a site about the writing systems of almost all known human languages, existing or extinct, naturally-evolved or artificially-created. I found it extremely fascinating and insightful. For example, I did not know that Devanagari was not considered to be an "alphabet" but an "abiguda". Check out the International Phonetic Alphabet (IPA) that can represent almost all spoken languages. How about Loglan (and its freer derivative, Lojban) that claims to be a "logical" language? (I first came across the IPA on Wikipedia, where it is used to provide the pronunciation for some terms. xkcd is where I first read about Lojban.)

Firefox 3 and Linux

Mike Connor blogs about the proposed requirements for Firefox 3 to run on Linux. A nasty surprise for me was the inclusion of GNOME as a dependency. While the GTK/Pango/Cairo/etc. requirements are quite understandable, I don't understand why it should need GNOME. Many of us are happy with KDE or Xfce and would like to avoid the bloat and the dependency hell of GNOME for the sake of running a browser.

As an aside, Firefox on Linux also seems to behave quite differently from Firefox on Windows. For example, on Linux Firefox seems to consistently consume more CPU time and memory than on Windows. Some pages are rendered differently on Windows and Linux (perhaps due to the availability, or otherwise, of the fonts requested by the page designer and the rendering infrastructure). I have personally also noticed bug-337093 on Windows but not on Linux.

Running Java Applets in Internet Explorer on Linux

One of the unfortunate things about the current state of the internet is that some web sites refuse to work with anything other than Internet Explorer (IE). Some of these also require you to run Adobe Flash Player and/or Sun's JVM within IE. Most of these sites can be happily avoided, but some of them just can't, especially when they run important applications within a corporate intranet. This can seriously dampen the enthusiasm of people willing to try out Linux as their primary desktop.

WINE allows you to run many a Windows application natively on Linux, including IE (albeit with a few tweaks). IEs4Linux makes it really simple to install one or more versions of IE on your Linux system, something that is very difficult on Windows itself, if not impossible! You can also view Flash content and run Java applets within such an IE. The latter requires a bit of tweaking with the current release of WINE (0.9.34), if you want to use Sun's JVM instead of that provided by Microsoft, as explained below.

Install a version of IE using IEs4Linux into, say, $HOME/.ies4linux (the default). Assuming that you choose to install only IE 6.0 SP1, IEs4Linux will create a WINE "bottle" named "ie6" within "$HOME/.ies4linux", separate from your regular WINE bottle (which is present by default in "$HOME/.wine"). IEs4Linux can also automatically install Adobe Flash Player along with IE. Run IE at least once to verify that it is working.

Now install the Java Runtime Environment (JRE) making sure that you correctly specify the WINEPREFIX environment variable by pointing it to the IE WINE bottle. For example:

export WINEPREFIX=$HOME/.ies4linux/ie6
wine jre-1_5_0_11-windows-i586-p.exe

For some reason, RegUtils.dll is not correctly copied during the installation of the JRE and therefore you must copy this file from a Windows machine that has exactly the same version of the JRE. This file is usually found in the "bin" sub-folder of the JRE installation folder. Without this file, the Java Control Panel applet will not be able to register Sun's JRE with IE.

Now run the "javacpl" programme found in the "bin" sub-folder of the JRE installation folder. With the current WINE release, this would cause your display to flicker or black out since it does not yet fully support DirectX-based acceleration (but where the maximum development effort currently seems to be directed). To avoid this, you can also invoke the Java Control Panel applet alternatively like this in the "lib" sub-folder of the JRE installation folder:

java -classpath deploy.jar \
  -Dsun.java2d.noddraw com.sun.deploy.panel.ControlPanel

Go to the "Advanced" tab and uncheck the check-box for "<APPLET> tag support" for "Internet Explorer", apply your changes and close the applet. Restart the applet once again and this time check the check-box, apply your changes and close the applet. You should now be able to see Java applets within IE using Sun's JRE.

If you wish to avoid the flicker/blacking-out of the display whenever you run Java GUI applications, you can either pass the JVM option -Dsun.java2d.noddraw to Java applications and applets or disable DirectX-based acceleration for Java 2D completely by looking for a registry key like:

HKEY_CURRENT_USER\Software\JavaSoft\Java2D\1.5.0_11

and setting the value of "DXAcceleration" to "0". (WINE includes a "regedit" programme just like its Windows counterpart.)

With IE, Flash and Java Applets with you, you are now ready to savour the worst of the internet first-hand on your Linux desktop instead of hearing about it from your friends who use Windows.

(The method outlined here seems to work with WINE 0.9.34 on Fedora Core 6, IE 6.0 SP1 as installed by IEs4Linux 2.0.5 and Sun's JRE 1.5.0_11 - your mileage might vary.)

Update (2007-07-03): With WINE 0.9.40 on Fedora 7 and Sun's JRE 1.5.0_12, I don't see the problem with "RegUtils.dll" and the JRE installs just fine. Another way of avoiding the blackening of the entire desktop while using Java Swing applications (and for getting a much more accurate display) is to enable a "virtual desktop" that will hold your Windows applications. To do this, invoke "winecfg", select "Enable a virtual desktop" under the "Graphics" tab and provide a size for the virtual desktop (say, 800 by 600 or 1024 by 768).

Update (2007-10-31): The default location used by IEs4Linux is $HOME/.ies4linux (notice the period in front of the directory name). Changed the post to use this location instead as people were getting confused by the location used earlier.

NX

NX allows you to remotely access a Linux or Solaris machine and makes applications using X Windows appear quite responsive even over slow links. It even supports resuming, from anywhere, a session with the server suspended for any reason (for example, a broken network connection). The "Free Edition" of NX is free for personal use. The core NX libraries are Free Software. There is also FreeNX that provides a Free implementation of the NX server licenced under the GPL.

NX performs incredibly well, especially when you compare it to VNC, ssh with compression and X forwarding, etc. The desktop client, especially on Windows, still has a few bugs that are mildly irritating but nothing catastrophic. The sheer improvement in the response of your remote applications more than makes up for these minor shortcomings.

Xfce and KDE

I have started using Xfce instead of KDE as the desktop environment on my Linux PC.

It is easy to compile Xfce 4.4.0. It even has a self-extracting installer that first compiles a GUI installer, which interviews you and then proceeds to automatically configure, compile and install the Xfce modules. The environment is quite configurable, the file manager and the terminal emulator quite usable and it integrates well with an existing KDE installation.

My PC now boots into a usable desktop environment after a cold start far faster than before and there is considerably more free memory and CPU cycles for use by applications. (For some reason, artsd from KDE used to eat up a lot of CPU cycles on my PC.) Everything feels so much snappier now.

KDE has become increasingly bloated over the years. Unlike the Linux kernel, which has also become more bloated over the years but at least makes it easy to leave out unwanted features using "make menuconfig" before compilation, there is no simple way to avoid the increasing bloat in KDE other than to hack the Makefile templates. With each release, each of the KDE core packages seems to pick up more utterly useless, functionally-overlapping and half-developed applications.

KDE has also remained rather buggy throughout the years. Applications crash every now and then for no apparent reason. Watching the numerous panicking messages from applications fly by on the console makes one constantly wonder how the desktop still manages to hold up and fills one up with an urgency to just get the work done as soon as possible and close the panicking application before it eventually crashes. About the only "improvement" in newer releases seems to be a dialogue-box asking the user to submit a bug report to the developers when an application crashes. The applications still crash about as often as they used to.

About every two years, I check out the latest release in the last stable KDE branch. I do this with the hope that the bugs affecting me would have been fixed by then. They usually are, but their place is then taken up by newer bugs. Compiling a KDE release is not a pleasant exercise and not just for the fact that each release takes longer and longer to compile than the previous release on the same hardware (understandable, since there is more code from more applications and GCC also generally keeps getting slower and slower at compiling C++ with successive releases). Each KDE release seems to require more and more dependent libraries (or updated versions of existing dependencies), which in turn require yet more dependent libraries - this is the kind of dependency hell that put me off GNOME in the first place. Each KDE release seems to fail compilation for me in the most basic of ways (for example, ksysguard in 3.5.6 has an unguarded call to strlcpy( )). Some times there are issues with the tarballs themselves. For example, the 3.5.6 tarball for kdelibs that I downloaded off a mirror had the timestamps for the files set to 31 October 2007 for some reason, with the result that when it finally finished compilation after several hours on my PC, I executed a "make install" only to discover that it proceeded to compile everything from the beginning all over again! Needless to say, this is very frustrating.

I know that Konstruct is supposed to ease the pain of downloading and compiling a KDE release, including automatically applying fixes for problems discovered only after the release, but I never found its insistence on downloading and compiling dependent libraries, even though I already have the necessary versions, particularly appealing.

Even after switching to Xfce, I still haven't removed KDE from my PC. After all, it does have some nifty applications, not least of which are two of my favourite games Kmahjongg and Ksirtet (a Tetris clone). I also like its well-integrated look and feel and its almost infinite configurability. Some day perhaps KDE will be able to iron over its current problems and I would again be tempted to go back to KDE. For the moment however, I'm happily sticking with Xfce.

On a side note, has anyone tried to compile the ultra-modular 7.1 release of the X.org server? Every little thing has now been broken into its own little module with the result that there are just too many modules without an easy way of choosing the ones you want (again, like "make menuconfig" for the Linux kernel). There are scripts to automate the download and build, of course, but they still don't seem to make it easy to choose among the modules.

Tar Formats

GNU tar creates archives in various formats and recent versions create archives in the POSIX-2001 format. Unfortunately, while this format is the most flexible and is standardised, it is not yet supported by most of the installations out there. When you distribute archives in this format, users using older versions of tar (even GNU tar before version 1.14), will see "weird" folders like PaxHeaders.1640 extracted along with the ordinary contents of the archive as well as get error messages like "unknown file type `x'".

I was bitten by this problem when I tried to extract an archive created on my home PC using GNU tar 1.15.1 on Linux on different systems elsewhere. It seems that the "v7" format is the most portable at the moment, though it has severe problems with long file names and large files. My project does not have long file names or huge files, so I can use this format for the time being to avoid these problems. The long-term solution however is to encourage everyone to use a tar programme that can handle the far better POSIX-2001 format.


(Originally posted on Advogato.)

"A look at GCJ 4.1"

Mark Wielaard has written another article for LWN.net titled "A look at GCJ 4.1" (where he also looks at GCJ 4.2 and beyond). It is subscribers-only for the moment (for a week), but if you are interested in Linux in any way, you should seriously consider subscribing to LWN. It's quite good.

(Originally posted on Advogato.)

OpenOffice.org v2.0

I have been waiting for this release for quite some time now, so as soon as it came out, I downloaded the Linux tarball. To my horror, I find that unlike previous releases it does not contain a simple installer but many RPMs! Why did they have to do this? It is so silly. An alternative for me is to build it from sources, but I do not have the energy or the enthusiasm to do it. Sheesh!


(Originally posted on Advogato.)

Prelinking

I have now become yet another fan of pre-linking. It works wonders on the startup times of most applications. Many thanks to Jakub Jelinek for creating prelink for Linux.

(Originally posted on Advogato.)

GCC v/s glibc

I had configured and built GCC 3.4.4 with "--with-arch=pentium3" and was happily using it for everything till I decided to compile glibc 2.3.5 with it. The build failed with a weird assembler error message as noted in glibc bug-701. That bug however, had been been closed unceremoniously and marked a duplicate of bug-333, which itself looks unnecessarily obnoxious.

After a bit of poking around, I found out that GCC pre-defines "__i686" if "-march=pentium3" is used (see $GCC_SRC_DIR/gcc/config/i386/i386.h) and this was causing the problem with glibc (see $GLIBC_SRC_DIR/sysdeps/i386/elf/setjmp.S). So I had to explicitly use "-march=i386" with GCC to be able to compile glibc. However, "make check" still fails. I will now build and install a vanilla GCC 3.4.4 and see if that is able to properly build glibc.


By the way, glibc 2.3.5 can not be built with GCC 4.0.1, though Dan Kegel seems to have patches to enable you to do it. It can not be built with anything lower than GCC 3.2 either.


(Originally posted on Advogato.)

Java Web Start (JDK 1.4.2_07) on Linux (Again)

I found a neater way of working around the bug in Sun's javaws
in JDK 1.4.2_07 on a Linux system running kernel 2.6.x and
glibc 2.3.3+ that I referred to in my previous blog entry - I
wrote a wrapper for waitid() that tolerates the
bogus options passed by javawsbin and calls the
real waitid() with saner options. With this code,
I am finally able to run javaws without problems. Note that
this bug seems to have been fixed by Sun in JDK 1.5.0_02.

/* Quick and dirty pre-loaded DSO to make buggy javawsbin
   in JDK 1.4.2_07 work on Linux with kernel 2.6.x and
   glibc 2.3.4.

    Compilation:
     gcc -O2 -fPIC -g0 -shared -o mywait.so mywait.c

    Usage (Bash):
     LD_PRELOAD=/path/to/mywait.so /path/to/javaws <Launcher URL>
   */
#include <dlfcn.h>
#include <sys/wait.h>

 int (*real_waitid)( idtype_t, id_t, siginfo_t *, int);

 int
waitid( idtype_t idtype, id_t id, siginfo_t *infop, int options)
{
  int retVal = -1;

   void *handle = dlopen( "/lib/libc.so.6", RTLD_LAZY);
  real_waitid = dlsym( handle, "waitid");

   options = (options == 0) ? WEXITED : options;
  retVal = (*real_waitid)( idtype, id, infop, options);

   dlclose( handle);

   return retVal;
} /* End pseudo-waitid() */

(Originally posted on Advogato.)

Java Web Start on Linux

Due to a bug in Sun's Java Web Start executable in JDK 1.4.2_07 for Linux, I am not able to use it as-is on a system with glibc 2.3.4 and kernel 2.6.11. As should be obvious, if they had made it truly Free, I could have easily fixed the problem and moved on with my life. Since it is not, I have to either use an alternative like OpenJNLP or somehow work around this bug.

On a system where this bug does not manifest itself, I used "ps --columns 2000 -e -o "%a" | grep javaws" to grab the command line that is used by this executable to spawn the Java VM. I tried modifying this command line for my system (adjusting paths) and running it but it failed trying to download the JVM from Sun's site. After a bit of snooping around, I found out that it was looking for a file named "deployment.properties" in "$HOME/.java/.deployment" that is populated by the wrapper executable with the information on the JRE being used. So I just copied this file over from the system where stuff works and adjusted the paths. It finally worked as expected, albeit without the splash screen (which I do not regret losing at all).

(Originally posted on Advogato.)

PDF Viewer Under Linux

Mark: Honeymoon? Congratulations!

As for Evince, my PC only has KDE and therefore I don't think I can use it. In any case, I like the way Adobe Acrobat Reader cleanly renders PDFs and I especially like the navigation and zoom controls. The last I checked, both XPDF and KPDF were rather lacking in this area.

(Originally posted on Advogato.)

Adobe Acrobat Reader 7.0 for Linux

Acrobat Reader 7.0 isavailable for Linux, but for some reason the main download page still shows 5.0 as the last supported version for Linux. This version takes up around 93MB (!) of disc space, but feels and shows documents much better than any of the other PDF viewers for Linux that I have had a look at.

(Originally posted on Advogato.)

"The Five Boxing Wizards Jump Quickly"

This is much better than "the quick brown fox jumps over a lazy dog", which was the only other pangram I had known before seeing this blog entry by X guru Keith Packard. Talking of X, XFree86 released their server version 4.5.0 almost a week ago and I haven't seen references to it on any of the main nerds news sites yet. From the same blog entry by Keith, I came to know that a font designed 530 years ago still looks quite decent.

(Originally posted on Advogato.)

GCC v/s ext3fs

I build and test the ever bloating mainline GCC at home on a 2GB ext3 partition (that used to contain the whole of my Linux installation in days gone by). It contains GCC CVS sources, a stripped snapshot of the sources to play with and the GCC build folder. Today the bootstrap of GCC failed complaining that there was no space left on the device for the final libgcj.so - a "df -k" showed that 93% of the space was being used. A dumpe2fs showed me that 5% of the filesystem was reserved for the super-user and the block size was 4K - I moved the data out, reformatted the partition to use 1K blocks and 0% reserved for the super-user and moved the data back in. Now the GCC bootstrap has succeeded and df -k still only shows 70% usage. Pick your lesson to learn from this incident.

By the way, the nVidia 6629 drivers installed and worked perfectly with kernel 2.6.10 and X.org server 6.8.2 - the mistake I made the last time was to not have /usr/include/linux/autoconf.h when I had copied over the kernel headers after building glibc. This gets built when you do a make menuconfig and configure the kernel.

(Originally posted on Advogato.)