These instructions are mainly inspired by the how-to “Ubuntu 9.10 64bit and custom 32bit JDK and Eclipse 3.5 pwned” on blog.javaee.cz/2009/11/ubuntu-910-64bit-and-custom-32bit-jdk.html. />
These instructions were developed originally for Ubuntu Linux 9.10 Karmic Koala.
Download the latest JDK 6 (currently JDK 6 update 18) for Linux 32bit platform from java.sun.com/javase/downloads/widget/jdk6.jsp. You need to pick the file without the “-rpm” suffix as we want to put all files in one directory instead of spread this 32bit stuff all around in our 64bit system. Also, installing RPMs in distributions that use the Debian package format does not work that well in most times …

(1) Create the directory /usr/local/lib/jvm/ and unpack your Java 6 SDK in this directory:
   cd /usr/local/lib/jvm/;
   sh /some/dir/java-jdk-6u18-linux-i586.bin;
This will create a sub-directory jdk1.6.0_18.

(2) Create a symlink named “java” to the SDK’s directory, as this is “good style”:
  ln -s /usr/local/lib/jvm/jdk1.6.0_16 /usr/local/lib/jvm/java/;

(3) Create a file /etc/profile.d/setup-dev-env.sh that sets up environment variables for the Java development environment we set up here, for every user. Content for this file:
   export JAVA_HOME=/usr/local/lib/jvm/java
   export JDK_HOME=$JAVA_HOME

(4) Install Eclipse 3.5. 32bit into /usr/local/share/applications/eclipse-3.5.1-32bit/:
   cd /usr/local/share/applications/;
   tar -xzf /some/dir/eclipse-java-3.5.1-linux-32bit-gtk.tar.gz;
   mv eclipse eclipse-3.5.1-32bit;
   cd /usr/local/bin/;
   ln -s ../share/applications/eclipse-3.5.1-32bit/eclipse eclipse-32bit;

(5) We will not use the update-java-alternatives command to select this Java SDK installation for running Eclipse, instead adapt eclipse.ini ton include a modified -vm argument like this, in two lines directly before the “-vmargs” line:
   -vm
   /usr/local/lib/jvm/java/bin/java

(6) Eclipse 32bit and a 32bit JDK for it is now installed. You can test it by running the eclipse-32bit executable.

(7) There is a bug in Eclipse 3.5 (except when it comes with the distro, where the bug is already corrected), due to a change in GTK, that prevents clicking most buttons. You have to highlight them with the mouse and then press enter to trigger them. To fix this, replace the symbolic link /usr/local/bin/eclipse-32bit with an executable file of the following content:
   #!/bin/sh
   # Custom startup script for Eclipse 4.5 to correct the “non-clickable buttons” found there.
   export GDK_NATIVE_WINDOWS=1;
   /usr/local/share/applications/eclipse-3.5.1-32bit/eclipse;

(8) To prevent linkage error when linking to the SWT platform plugins from this Eclipse 32bit platform (or for other kinds of reasons, as you chose to set up a 32bit Eclipse), you will want to let all the Eclipse RCP applications you develop also run with a 32bit JDK. You cannot use the “-vm /usr/local/lib/jvm/java/bin/java” argument in the “Arguments” tab of the Eclipse run configuration here; it is ignored because you the Execution Environment / JRE setting on the “Main” tab is used instead. So configure this to use your 32bit VM in /usr/local/lib/jvm/java/bin/java.

(9) If you see an error “org.eclipse.swt.SWTError: No more handles” when running Eclipse, there is a fix for that in our source blog.javaee.cz/2009/11/ubuntu-910-64bit-and-custom-32bit-jdk.html. />

Eclipse 3.4 is not in the Ubuntu repositories of Ubuntu 9.10 Karmic Koala. So if you need it for any reason, you need to download the tarball from eclipse.org and install it yourself. If you follow the normal procedures for that, you might receive the following error message in {$ECLIPSE_WORKSPACE}/.metadata/.log

!ENTRY org.eclipse.osgi 4 0 2010-01-26 18:28:31.518
!MESSAGE Application error
!STACK 1
org.eclipse.swt.SWTError: XPCOM error -2147467262
        at org.eclipse.swt.browser.Mozilla.error(Mozilla.java:1638)
        at org.eclipse.swt.browser.Mozilla.setText(Mozilla.java:1861)
        at org.eclipse.swt.browser.Browser.setText(Browser.java:737)

Above that last error, there can be many “java.lang.RuntimeException: Widget disposed too early!” messages.

The solution I found was in the Ubuntu Bug #237081 log where somebody tried to install Eclipse 3.4 RC1 and RC2 on Ubuntu 8.04 Hardy Heron back in 2008, for 32 bit Linux. It works also for me (64 bit Ubuntu 9.04), so the problem and solution seem to be both quite general.

Now, the steps how to do the installation:

1. Download Eclipse Classic 3.4.2 (eclipse-SDK-3.4.2-linux-gtk-x86_64.tar.gz) from here.
2. Unpack the tarball into /usr/local/share/applications/.
3. Rename the resulting eclipse/ directory to eclipse-3.4.2-64bit/ if you like (for example, to separate it from other Eclipse installations in that directory).
4. Install the Ubuntu package named xulrunner. It does not help here if you have the xulrunner-1.9.1 package installed, as Eclipse seemingly cannot find this one. The version that I installed was 1.8.1.16+nobinonly-0ubuntu1.
5. Add the following line to the eclipse.ini file of the Eclipse 3.4.2 installation, at a place somewhere below the -vmargs line:
   -Dorg.eclipse.swt.browser.XULRunnerPath=/usr/lib/xulrunner/xulrunner
6. Start Eclipse (maybe you need the -clean option).
7. Now you can remove the line from eclipse.ini again (I do not know exactly why this is the case; it seems that Eclipse now is able to find XULRunnner 1.9.x, which it could not before because the path was different from its expectations).

However, the sad news is that this does not cure all problems in Eclipse. Eclipse might show many NullPointerExceptions, some XPCOM errors, and the like. Additionally there is a bug related to GTK 2.18 (making it impossible to press buttons normally) which is cured only in Eclipse 3.5.2 (and in some Linux distros before that release). There is this alternative howto that you might try out (I did not).

But in all, it seems you are better off by going with Eclipse 3.5.x and solving the problems you encounter there.

The viewer should be cost-free and support at least Mac OS X and Linux, and if possible also Windows.

The best solution seems to be currently the program “GLC Viewer”. It is very easy to use, works really good and seems a good, clean software. The best thing is, it is open source. Its website: http://www.glc-player.net/.

Installation for Ubuntu 9.10 (Karmic):

1. Make sure you have QT 4.5 installed.
2. Go to http://ftp2.srv.endpoint.nu/pub/software/getdeb/ubuntu/pool/apps/g/glclib/ and download the glclib Debian package for your architecture.
3. Install glclib. For example: dpkg -i glclib1_1.2.0-1~getdeb1_amd64.deb
4. Go to http://ftp2.srv.endpoint.nu/pub/software/getdeb/ubuntu/pool/apps/g/glc-player/ and download the glc-player Debian package for your architecture.
5. Install glclib. For example: dpkg -i glc-player_2.1.0-1~getdeb1_amd64.deb

Evaluated alternatives include:

1. TNG viewer. A free viewer that can open OBJ files but is only available for Windows and Mac OS X.
2. Deep Exploration. A very good viewer, but not cost-free and also not available for Mac OS X and Linux.
3. Blender. Not just a viewer but a cross-platform 3D authoring tool. And therefore it is too complex to use as a viewer, also since it uses strange (umh … innovative) GUI concepts.

This goes alongside some sources (linked in the post) and adds some notes that I found necessary. It just relates to installing Flex Builder on a 64bit operating system; for 32bit Linux, there is another article on this site. Especially, one source was Adobe’s instruction set for installing on 64bit Linux.

1. We need to create a clean environment. Only if you never had Eclipse 3.5 installed on your system, you can jump over this.
   • rm -R ~/.eclipse/org.eclipse.platform_3.5.0_*/ (Omitting this can cause all Flex perspectives, editors and views to be “hidden” even though Flex Builder 3 alpha 5 for Linux is correctly installed. This happens if a previous failed / wrong installation caused this stuff to be hidden, as the directory deleted above then stores that configuration, seemingly.)
   • Delete your Eclipse 3.5 installation folder and your Flex Builder for Linux installation folder, if you have previous, failed installation attempts.
2. Install Eclipse 3.5 Galileo 32bit. You will want to use a tarball for installing locally, to not mess up with a 64bit version that you might already have installed via your package manager. So you need the “Eclipse IDE for Java Developers (92 MB)”, version 3.5.1, for Linux, 32bit. To install it, unpack it e.g. to /usr/local/share/applications/eclipse-3.5.1-32bit/.
3. Install the 32bit version of the Sun Java JRE 1.5.x or newer. For that, on Ubuntu, simply install ia32-sun-java6-bin and all its dependencies.
   (Generic solution for other distros: I downloaded the file jre-6u17-linux-i586.bin from here. Found on the index of all Java downloads. And installed it to the directory /usr/local/lib/sun-java-jre-1.6.0.17-32bit/.)
4. To run the Flex Builder installer, we need to temporarily make the “java” command point to the 32 bit version. So set the environment variable PATH such that the 32-bit version of Java (installed above) is run by default. For me it was export PATH=/usr/lib/jvm/ia32-java-6-sun/bin:$PATH). Verify that you set the PATH right by running “java -version”. The output must be the same as that of “/usr/local/lib/sun-java-jre-1.6.0_17-32bit/bin/java -version”.
5. In the configuration file eclipse.ini add the line -vm so that the 32-bit JVM is definitely picked up when Eclipse is launched. In my case here it is editing /usr/local/share/applications/eclipse-3.5.1-32bit/eclipse.ini and adding the following before the -vmargs line [reason]:
   -vm
   /usr/lib/jvm/ia32-java-6-sun/bin/java
6. Install Flex Builder for Linux alpha 5: download the file flexbuilder_linux_install_a5_112409.bin, make it executable and run it.
7. Create a small wrapper shell script in your PATH to start Flex Builder. In my case, I created /usr/local/bin/flexbuilder, made it executable and added the following content:
   #!/bin/bash
   cd /usr/local/share/applications/flexbuilder_3alpha5/;
   ./Adobe_Flex_builder.sh;

In the official instructions from Adobe and also in the Flex builder installation process they say that you need to install Firefox 32bit to get it running. This seems to be not true, as it would just be to install the Flash Player 9 32bit Debug that comes with Flex Builder. Instead, you can simply use your 64bit Firefox and install the new Flash Player 10 64bit Debug in it.

So from now on, you can run Flex Builder by running the command “flexbuilder” as any user. The remaining steps are to deal with some pesky problems that pop up because we are running in Eclipse 3.5 (while only Eclipse 3.3 is officially supported by Flex Builder for Linux 3 Alpha 5).

1. Update your Flex SDK to Flex 4 beta 2 SDK, and update AIR. Use the stage 3 instructions here and follow the “To use Flex 4 SDK” steps here.
2. Apply James Ward’s ProblemManager patch (steps 2,3,4,5). A preliminary solution is to switch off warnings in the “project properties -> Flex compiler” settings. I have a more detailed description of the problem to solve here.
3. Apply Danyuls patch:

• Download Danyul’s patch from here and unpack it with.
• Delete the directory /usr/local/share/applications/flexbuilder_3alpha5/eclipse/plugins/com.adobe.flexbuilder.debug.e33_3.0.204732.
• Delete the file /usr/local/share/applications/flexbuilder_3alpha5/eclipse/plugins/com.adobe.flexbuilder.editors.derived_3.0.204732.jar.
• Unpack the replacements from Danyul’s patch: cd /usr/local/share/applications/flexbuilder_3alpha5/eclipse/plugins/; tar -zxf eclipse-galileo-fbl-patch.tar.gz; mv eclipse-galileo-fbl-patch/eclipse/plugins/com.adobe.flexbuilder.* .; rm -R eclipse-galileo-fbl-patch*;

1. Optionally: There is an issue that can prohibit opening the ActionScript editors, written about in more detail here. Interesting enough, while I had it in my 32bit install, it did not appear in the 64bit install here. But prophylaxis does not hurt: open the file ${ECLIPSE_3.5_32BIT_DIR}/links /com.adobe.flexbuilder.feature.core.linux.link and prepend the content with “path=” (omitting the quotation marks).

Remaining problems:

• It seems that you cannot install any new software into this Eclipse installation. That is, you can install it and it will show up in the “What is installed?” software list, but you will not find any part of the new software elsewhere in the Eclipse UI. Cleaning the workspace (eclipse -clean) and creating a new workspace (and importing the old projects there) does not help. Deleting the settings directory for this Eclipse instance in ~/.eclipse/ did not help (there is one subdir per instance in that). There is an error “ProvisioningEventBus could not be obtained. Metadata caches may not be cleaned up properly.” however in the Error Log view.

These instructions relate to KMail 1.12.4 (that is KDE 4.3.4).

When choosing “Forward: As Attachment …” KMail will create a new message with the message to forward attached, and also attachments of that message included. But you cannot chose to use a template from your template folder then (with preconfigured text and recipioents).

1. Save the e-mail to forward as a local file with the .mbox extension. This is just a text file with the mail’s source text.
2. Create a new mail from the template in your KMail templates folder.
3. Choose “Attach: Attach File …” and attach the .mbox file you just saved.
4. Remove the .mbox extension from the attachment.
5. Set the MIME type of the attachment to “message/rfc822″, which is what KMail
   uses when you choose “Forward: As Attachment …” to forward a message. Else, KMail will not honor the “suggest automatic display” setting for this attachment.

At least KMail can open such an attachment as an e-mail, also including
attachments to that attachment (like image files). It is unclear
currently how this displays in other e-mail programs.

Use the AMD64 variant of Ubuntu 9.10 and install that. After that, here are steps to take to cure various problems that are present after a “vanilla” Ubuntu 9.10 amd64 installation:

Black screen after resume

This problem with the computer’s NVidia Quadro NVS 140m graphics card is reported to be due to using the open source “nv” graphics driver kernel module, and to be cured by installing the proprietary “nvidia” graphics driver kernel module. See for example: “On an R61 running Fedora Core 9, the nv driver fails to turn the backlight on after resuming from a suspend to RAM. I fixed this by using the proprietary NVIDIA Linux drivers (v177.82)” [source].

So the solution would simply be to install the newest nvidia driver, that would mean nvidia-kernel-source-185 as of this writing. However there is an additional issue: it seems that when installing nvidia-185-kernel-source, the post-install script misses to create an /etc/X11/xorg.conf file. Then, the X server will startup with an internal default configuration that will apparently not use the nvidia proprietary driver even if the corresponding kernel module is installed. Even worse, after installing the nvidia-173-kernel-source package there is an issue that the LCD stays blank (though backlight is on) in every second system startup. And even worse, installing the version 173 package changes the font dpi settings so that fonts get really huge and render most applications unusable. Note that this problem is also cured with the below method.

Therefore the full solution is this:

user@computer:# sudo apt-get install nvidia-185-kernel-source
user@computer:# nvidia-xconfig # (Will create a fitting /etc/X11/xorg.conf which uses also correct font settings.)

Then start X. You will note, in comparison with the default built-in X server configuration: more color depth on the display (though even before it seemed that external monitors already had that deep color depth), sound is working now incl. volume changing keys, suspend-to-RAM and resume works without the “black screen” issue, and accelerated graphics works (like transparency and other effects in KDE). Note that Fn+F4 for suspend-to-RAM does not yet work, instead call it from the menu.

You can further tune settings if you want by starting “gksudo nvidia-settings” within X.

No sound

After the initial installation, the equilizer of audacious2 indicates that it plays, but there is no sound output, neither at the speakers nor the headphones. However when starting “xmms2 play” and then doing a suspend-to-RAM / resume cycle, sound starts to play audibly on resume (but then the display stays black currently; also, the volume control buttons would not work). All these issues went away automatically after following the above instructions for the “black screen after resume” issue.

This goes alongside some sources (linked in the post) and adds some notes that I found necessary. It just relates to installing Flex Builder on a 32bit operating system; for 64bit Linux, there is another article on this site.

1. We need to create a clean environment. Only if you never had Eclipse 3.5 installed on your system, you can jump over this.
   • rm -R ~/.eclipse/org.eclipse.platform_3.5.0_*/
     (Omitting this can cause all Flex perspectives, editors and views to be “hidden” even though Flex Builder 3 alpha 5 for Linux is correctly installed. This happens if a previous failed / wrong installation caused this stuff to be hidden, as the directory deleted above then stores that configuration, seemingly.)
   • Delete your Eclipse 3.5 installation folder and your Flex Builder for Linux installation folder, if you have previous, failed installation attempts.
2. Install Eclipse 3.5 Galileo and Flex Builder for Linux alpha 5.
3. Cure the “path=” issue: open the file {$ECLIPSE_3.5_DIR}/links/com.adobe.flexbuilder.feature.core.linux.link and prepend the content with “path=”. Read more about that issue here.
4. Apply James Ward’s ProblemManager patch (steps 2,3,4,5). A preliminary solution is to switch off warnings in the “project properties -> Flex compiler” settings. I have a more detailed description of the problem to solve here.
5. Apply another patch (Stage 2: steps 5,6,7). The instructions there are for teh Flex Builder 3 alpha 4 build, so the stuff to remove is named differently. But you need NOT to rename the patch files with the new build ID.
6. Update your Flex SDK to Flex 4 beta 2 SDK, and update AIR. Use the stage 3 instructions here and follow the “To use Flex 4 SDK” steps here.

The error is this typical, pesky “an internal build error has occurred. right-click for more information.” error. For “normal” causes of this error see:

• 9mmedia blog post 165
• Juda Frangipane blog post 212
• Michael Imhoff “Internal build error” blog post
• more searching through the Internet

Now all this did not work in this case. The {$WORKSPACE_LOC}/.metadata/.log said:

!ENTRY com.adobe.flexbuilder.project 4 43 2009-12-30 22:49:43.166
!MESSAGE ConfigurationProblem logging info
!STACK 0
java.lang.IllegalArgumentException: "The attribute value type is com.adobe.flexbuilder.project.compiler.internal.ProblemManager and expected is one of java.lang.String, Boolean, Integer"
        at org.eclipse.core.internal.resources.MarkerInfo.checkValidAttribute(MarkerInfo.java:84)

In Danyul’s post 68 I found the solution: when trying to combine Flex Builder for Linux 3 Alpha 5 with Eclipse 3.5 (which is officially not possible), the compiler will halt on all warnings! So cure the warnings in the project that throws the above error, and it will compile.

The cleaner solution is, of course, a patch that sorts out the ProblemManager problem. Installing this is discussed in above-mentioned Danyul’s post 68. There is even an unofficial port of Flash Builder 4 beta to Linux (referred to here and in various other blogs), but I could not get hold of the files.

The problem: you can have file names with special characters in them on your Sansa Clip player, and also play them if they are MP3 files etc.. But you can play them only directly with the player’s functionality, while referencing them in playlists does not work.

First of all, get and install the latest firmware for the Sansa Clip MP3 player. You can find installation instructions and the firmware itself here. These instructions apply to Firmware 02.01.32. You can find that out in “Settings -> System information”. By the way, the exat type number of the player is “BI0810BIIK-8GB” (printed to its bottom).

First problem: Getting the filenames right

The Sansa Clip seems to interpret filenames within the charset that belongs to the language you use. For example, it uses the ISO 8859-1 charset when you use German as the language. This is visible in the playlist names when scrolling through the list of playlists. German umlauts appear there correctly if the filename contains them.

Now it is a first problem (at least when using Linux and having bash use UTF-8 filenames by default) to get the filenames right. If you have Linux, and your bash creates UTF-8 filenames by default, you can use this approach to convert the UTF-8 filenames to ISO 8859-1 ones (or whatever encoding you need):

for file in *; do \
  mv "$file" "$(echo $file | recode "UTF-8..ISO-8859-1")";
done;

Note that, what also works for creating new files is creating them with an ISO 8859-1 encoded bash script file. Note also: when writing files to the file system in UTF-8, the files can be played, but the file names are not shown correctly.

Second problem: Getting the playlists right

Now, interesting enough, the Sansa Clip does not interpret M3U playlists with the same charset as it does interpret the file names. This is simplest to be demonstrated by creating a demo playlist (referring to an existing file with just ASCII characters in path and filename) and using special characters in the “display name” in the #EXTINF lines of the playlist (see here). Oh and yes, here is how to create M3U playlists if you are on Linux. The effect is, Chinese characters were displayed instead of German umlauts, using a M3U playlist in ISO 8859-1 encoding.

That’s because the Sansa Clip expects M3U playlists to be UTF-8 encoded. Provide this, and everything works fine.

Note: To be able to create playlists with easytag and create files as a user, mount it in a way that normal users can write to it. For example by using this instruction: sudo mount -o uid=myusername /dev/sdb /media/misc/.

Note: Take care; if your playlist contains entries to non-existing files, they will not be displayed when browsing the playlist on the player, but when scrolling down further through the entries folloing the first non-found entry, scrolling is incredibly slow (about 1 song per second). Also, when you have really much playlist entries that refer to missing files, opening the playlist will take really long. If for example a playlist of 1000 entries is opened, and all entries refer to non-existing files, the Sansa Clip seems to be “crashed” as it does not react to anything then except forcing switch-off by holding up the switch-off switch for 4 seconds. The normal case is that a 1000 entry playlist opens in 1 second.

What did not help with this problem:

• Calling this command: CHARSET="ISO-8859-1" bash; After that, file names are still shown with UTF-8 characters correctly displayed, and with non-ASCII characters in ISO-8859-1 encoded filenames replaced by “?”. Also, newly created filenames are still created in UTF-8.
• Calling sudo mount -o uid=matthias -o iocharset=iso8859-1 /dev/sdb /media/misc/ or the same with iso8859-15. This only tells the system how to interpret non-ASCII characters in 8.3 filenames, while today, always the FAT long filenames are displayed. Which are always created with UTF-8 encoding, regardless of the iocharset setting. See “man mount” for that. It
  seems that file names are created in UTF-8 anyway, regardless of the iocharset setting. But they are marked as being encoded in the iocharset setting, so when mounting next time with another such setting, each appears as “??” (for a UTF-8 character, being tw bytes). This applies to filenames within and without the 8.3 naming schema.
• Playing around with “export LANG=[...]“.
• “dpkg-reconfigure locale” might work, but affects the whole system.

A large audio book is here defined as one that needs chapters and sub-chapters to navigate meaningfully. For example, an audio Bible. It would have 1189 chapters when using one navigation level alone, which is clearly unnavigable.

There are two alternatives in principle. The first is to store each chapter as a separate audio book, so that each subchapter becomes a chapter of such a separate audio book. This is simple to achieve: just create one folder for each chapter in the AUDIOBOOKS/ folder of the Sansa Clip. This gives you one audiobook per chapter, where you can then place the files (one per subchapter). The problem with this approach is that the player will repeat a chapter (as it thinks it is a full audiobook) instead of going to the next one.

The second approach is to store the audiobook in the MUSIC/ folder, one folder per chapter, one MP3 file per subchapter. And then to create playlists, one per chapter, named by chapter, starting with the first subchapter of that chapter, and going through all the subchapters sequentially, ending with the one immediately before the first one in the playlist. That way there is one playlist per chapter (allowing to jump quickly into each chapter), and then one can navigate within the playlist form file to file between the subchapters. In addition to the first approach, the playback does not stop and restart at the chapter boundaries, but moves on to the next chapter, repeating the whole playlist (that is, the whole audiobook).

In the playlists, you can use the #EXTINF section of the M3U playlists to give the real
name of the chapter instead of the filename. [source]

You can also combine both approaches: since firmware 01.01.32 resp. 02.01.32, the bug “Playlist referencing content in Audiobook folder does not work” is removed, so you can have playlists referencing audio books. [source]