Skip navigation

Tag Archives: linux

Following up from my previous post, I have decided to use Java for Museic since, ironically, it looks easier to write platform-portable code that plays MP3 files in Java than in Python. And well it is but that is not to say that the road to my goal was bump-free.

First off, the “default” way to play MP3 files in Java would be to use the JavaFX library. However, JavaFX is not at all available in Java 6 (you need to include specific JARs in your class path to use it), only half-included in Java 7 (you still need to be specific with your class path), and fully-included only in Java 8.

The obvious way to stop worrying at all about the version of Java installed in your system is to use a dependency manager, my choice being Maven. Maven has a JavaFX plugin. All you need to do is (1) fix your class path by issuing the command mvn com.zenjava:javafx-maven-plugin:2.0:fix-classpath and (2) add the following in your pom.xml

        <mainClass>[put your application main class here]</mainClass>

Alas, I wish it was that easy. In my system, it was complaining about some missing JARs. It seemed to me that I was encountering the very problems I hoped to avoid by using Maven.

Then I realized that I was using OpenJDK 7 instead of Oracle JDK 7. Now, I’m aware of the distinction between OpenJDK and Oracle JDK; at Chikka, we’ve made it a point to use Oracle JDK in production. Nonetheless, for my personal projects, I’ve never experienced any significant difference of OpenJDK so I kept using it as it took less effort to install in Ubuntu. Until now.

The moral of the story is: if you are going to use JavaFX, make sure you are using Oracle JDK.

(And yes, Museic is now playing MP3 files with my desired delay, thank you very much. It’s now my practice/jam buddy!)

I just got locked out of my Linux machine (details here) for reasons I am still trying to determine (see the link). I tried to recover my password but, unfortunately, all my most recent Live CDs I’ve left at work. All I have with me is an old Karmic installer, incidentally, the first Ubuntu I ever tried to install (and failed miserably more due to hubris and absence of mind—but that’s another story).

So from the Live CD, I was able to mount my Linux partition fine. Note that, I guess due to EFI and/or the tutorial I was following is just outdated, a mere sudo fdisk -l did not show me all my partitions; I had to use gparted (thankfully available with Karmic). But when I try to chroot, into my mounted partition, I get an exec format error which is apparently because my Karmic LiveCD is just 32-bit while the installation I am trying to salvage is 64-bit.

Thankfully, tinkering around with how Linux stores passwords, I got to reset my main account to have no password.

  1. Edit /etc/passwd. Look for your username in the first of the colon-delimited fields. A typical line in the this file looks like bin:x:2:2:bin:/bin:/bin/sh. The ‘x’ in the second field means that the password for this account is encrypted. Remove the x so the line corresponding to your user becomes similar to bin::2:2:bin:/bin:/bin/sh.
  2. Your actual password is stored in the /etc/shadow file. Open this file and, again, edit the line corresponding to your user to just have four colons after it like so: user::::.
  3. Reboot. You should now be able to log-in passwordless. Remember to reset your password at once.

Note that to get my system to boot from LiveCD I had to tweak my BIOS yet again. I had to set my boot mode to Legacy and, after doing the steps outlined above, had to switch back to UEFI and disable Secure Boot. Man is BIOS dealing becoming traditional for me!

Ever since I got my new laptop and upgraded to Ubuntu 12.04, I noticed that my WiFi has been very unsteady to the point that for anything greater than 100MB, my most reliable download method would be via torrent, unless the server I’m downloading from supports resuming downloads, which is never. That’s a shame since not everything > 100MB can be found in P2P networks. I also noticed that Ubuntu 12.04 oftentimes took ages to connect to our WiFi network upon start-up. This isn’t the case with 10.04 and Windows 8. Unfortunately, the last time I felt this frustrated with WiFi connection upon start-up was with Windows Vista.

At first I thought it is an issue with our router which is around 3-4 years old—a suspicion I got pretty confident with upon checking my ping and traceroute logs. My pings averaged at around hundreds of milliseconds, sometimes even up to 800ms, while the normal was only at around 50ms to 60ms. Traceroute, on the other hand, times out intermittently and, noticeably, on the first hop towards our router (

I got a replacement for our router around a month ago and, to my disappointment, the problem persisted. My ping and traceroute returned to normal but the WiFi remained choppy while connected and initial connection upon start-up still took ages. I’ve been searching for a solution for this problem but every solution I come across seem to be very hardware specific (check those network cards, geeks) and involved building some low-level modules. For what it’s worth, it seems that this problem boils down to a conflict among the wireless drivers that come with 12.04.

Then somewhere, in my searches, I encountered a post in Ubuntu Forums which looked like a general solution to the problem I am having. This, as the command suggests, installs a backport of wireless drivers into your machine:

sudo apt-get install linux-backports-modules-cw-3.3-precise-generic

Now, my Ubuntu 12.04 instantly connects to our WiFi upon start-up, just like my old 10.04 installation.

The WiFi still cuts though, something which I’ve pinpointed to be a fault of the router (or, maybe, how I’m positioned with respect to the router): I noticed that my XPeria Z, stationed on the same desk, also gets disconnected. For what it’s worth, reestablishing connection is now faster since I backported my drivers.