Day: July 28, 2013

Let me preface this post by saying that satellite radio is a great service.  You get access to a whole lot of content that you might not otherwise be able to access.  When I got my new 2012 Ford F150 XLT SuperCrew, I got a trial subscription for the first six (6) months to a subset of the SiriusXM stations.  I thoroughly enjoyed listening to the selections on the Electronic and Dance stations, the BBC content, stations from Canada, and a wide variety of news outlets, not too mention the comedy channels.

On September 3rd, my trial subscription expired.  I knew that it was going to expire.  In fact, I put a reminder in my personal calendar to warn me that the trial expiration date was arriving.  I liked the service enough that I was going to subscribe so that I could continue enjoying the service.

However when the renewal date approached, I determined that it was not financially smart to sign myself up for yet one more monthly payment at this time.  No big deal, I would just use Pandora, Spotify, Google Music and standard terrestrial radio until I was where I could pay for the subscription.

That’s where it all gets painful.  When the SiriusXM customer service representative called me to make sure that I knew my trial expiration was coming up I explained that I was not currently interested in signing up to pay for it.  When he helpfully (at least in his mind it was helpful) informed me that the monthly payment was only $16 a month, I ensured him that I had actually read the mailing they sent out and knew what the prices were and I just didn’t want to continue.

Now despite the belligerent tone of voice he continued to use to try and bully me into a subscription, I finally managed to get off the call without losing my temper (which was a major feat, let me tell you).  In a logical universe, they would mark my account as having declined service and to try again in a few months (but hopefully never since I did mention that I didn’t want them to call me again) and that would end the matter.

This is where SiriusXM has failed to gain a customer.  Almost every day so far this month I have received at least one call from the SiriusXM folks (866-903-7474) trying to suck me back into the fold.  This constant bombardment is a real pain in the rear.  I can understand one or two attempts, but at some point you have to realize that continued calls are not going to get the customer.

So here’s the email I sent to the SiriusXM Customer Service folks today after yet one more call:

I realize that my trial subscription has expired. In fact I even talked to your customer representatives at least once concerning this prior to the expiration.

I happily informed the customer service representative that I knew my subscription was going to expire and that I was not interested in converting my trial at that time due to the cost, and yes that I knew it wasn’t a lot each month if I subscribed for a year. After he kept trying to get me to convert, rather insistently to the point of belligerence, I finally was able to get him to hang up.

Recently I have been receiving calls from your company (866-903-7474) at least once a day (sometimes twice).

I realize that you would like to retain customers and to gain new ones, however when a current/former customer informs you that they no longer wish to continue the subscription, it doesn’t engender good customer relations to bombard them on a daily basis with calls.

For this reason it is unlikely that I or anyone in my household will ever subscribe to your services at any point in the future. I appreciate that you have made it even easier for me to embrace the free and/or ad-supported streaming services like Pandora Radio, Spotify, Live365, Google Music, and Amazon Music.

Thanks,
Andy Fore

So instead of caring about subscribing to SiriusXM, I will just use my mobile data plan to get the most out of Internet-based streaming services that I can.  I would rather give my money to my mobile provider for data usage than to SiriusXM, since Verizon doesn’t deem it necessary to spam me with phone calls about their services.

Today while working on the AASU Blackboard VISTA custom login page, I ran into an issue loading Java applets.

Apparently, Google Chrome checks your browser plug-ins to determine if they are out of date when you attempt to load content requiring them.  Here’s a snippet from the Google Support Site about the bug feature:

To make sure you’re protected, whenever Google Chrome detects that a common plug-in on a page is out of date with a security vulnerability, a message will appear beneath the address bar notifying you that the plug-in has been blocked.

While this is a great feature, since it is an attempt to protect your computer from nefarious code, there are times that it just doesn’t work properly.

The situation I ran into is described on a chromium issue report.  Basically, the Linux version of Oracle Java 7 is being seen as out-of-date, even though it is the most recent version available.  When going into the Google Chrome plug-in preferences you may see the Java plug-in marked as disabled and showing the version number in red as well as a link to java.com to download a security update.

While Chrome does give you ability to run the plug-in each time it is used, this can rapidly become a pain in the rear.  The checkbox labeled Always Allow also doesn’t seem to work.

So what to do?  Well, you can either painstakingly click the Run this time button or you can run Google Chrome with a command line switch that turns off the plugin checking mechanism.

Being an intrepid sort that likes to live on the edge and dance where angels fear to tread, I chose to run with the checking mechanism turned off.  To update the Ubuntu application launcher to make this easier, I edited the following file:

/usr/share/applications/google-chrome.desktop

sudo vi /usr/share/applications/google-chrome.desktop

Look for the first instance of a line starting with Exec and alter it to read as follows:

Exec=/opt/google/chrome/google-chrome --allow-outdated-plugins %U

After saving the file and restarting Google Chrome you will no longer be bothered by the annoying Java plug-in error warning.  To verify this is working, you can enter the following on the command line:

ps ux | grep -v grep | grep allow-outdated-plugins

You should get back at least one result.

As a bonus, you can ensure that you are running the most recent version of Java (1.7.0_05 as of this writing) by doing the following on a command line:

java -version
javac -version

You should see something like the following:

foreandy@foreandy-iMac:~$ java -version
java version "1.7.0_05"
Java(TM) SE Runtime Environment (build 1.7.0_05-b05)
Java HotSpot(TM) 64-Bit Server VM (build 23.1-b03, mixed mode)
foreandy@foreandy-iMac:~$ javac -version
javac 1.7.0_05

At work we run the WebCT Vista course management system by Blackboard.

Recently I was requested to figure out how to import the security certificate from the command line so that we could add this to the login script used for our campus computers. The main reason behind this was to eliminate the need for the user to have to manually agree to the security certificate when browsing to the CMS.

Normally when you want to create a Java keystore, you would use the keytool program located in

. If you run this program to import a certificate without specifying a location for the keystore it tries to create one named

in the user profile home directory.

However, when the JRE actually imports a certificate it doesn’t put it in this file. After some investigation, it turns out that the JRE imports certificates into a file named

which is located in the following directory

C:\Documents and Settings\USERNAME\Application Data\Sun\Java\Deployment\security\

In order to import a certificate into a keystore you need to vital pieces of information:

1. the keystore name
2. the keystore password

The problem here is that this keystore is being automatically created by the JRE. It turns out that this keystore has a password that is an empty string. What this means is that when you import a certificate you have to specify the password by using the storepass parameter with a value “”.

For example if the certificate that you want to import has a name and path of

the command to import the certificate for the user jdoe would be

keytool.exe -import -noprompt -keystore C:\Documents and Settings\jdoe\Application Data\Sun\Java\Deployment\security\trusted.certs -storepass “” -file c:\Blackboard.cer

Update 2008-04-09:

I have also found how to do this on Mac OS X. According to the developer documents, the JVM on Mac OS X uses the user’s default keychain to store this type of certificate instead of using a file-based keystore like the other OS.

In order to store the certificate in the user’s login keychain you can import it via the command line tool

that is installed on the OS.

The command to import this certificate from the command line is

certtool i path/to/cert/file k=~/Library/Keychains/login.keychain

If you want to have this happen at login for each user who might login, then you could implement this via a login hook. For more on this, take a gander at the article 301446 in the Apple knowledgebase.

Let me preface this post by saying that satellite radio is a great service.  You get access to a whole lot of content that you might not otherwise be able to access.  When I got my new 2012 Ford F150 XLT SuperCrew, I got a trial subscription for the first six (6) months to a subset of the SiriusXM stations.  I thoroughly enjoyed listening to the selections on the Electronic and Dance stations, the BBC content, stations from Canada, and a wide variety of news outlets, not too mention the comedy channels.

On September 3rd, my trial subscription expired.  I knew that it was going to expire.  In fact, I put a reminder in my personal calendar to warn me that the trial expiration date was arriving.  I liked the service enough that I was going to subscribe so that I could continue enjoying the service.

However when the renewal date approached, I determined that it was not financially smart to sign myself up for yet one more monthly payment at this time.  No big deal, I would just use Pandora, Spotify, Google Music and standard terrestrial radio until I was where I could pay for the subscription.

That’s where it all gets painful.  When the SiriusXM customer service representative called me to make sure that I knew my trial expiration was coming up I explained that I was not currently interested in signing up to pay for it.  When he helpfully (at least in his mind it was helpful) informed me that the monthly payment was only $16 a month, I ensured him that I had actually read the mailing they sent out and knew what the prices were and I just didn’t want to continue.

Now despite the belligerent tone of voice he continued to use to try and bully me into a subscription, I finally managed to get off the call without losing my temper (which was a major feat, let me tell you).  In a logical universe, they would mark my account as having declined service and to try again in a few months (but hopefully never since I did mention that I didn’t want them to call me again) and that would end the matter.

This is where SiriusXM has failed to gain a customer.  Almost every day so far this month I have received at least one call from the SiriusXM folks (866-903-7474) trying to suck me back into the fold.  This constant bombardment is a real pain in the rear.  I can understand one or two attempts, but at some point you have to realize that continued calls are not going to get the customer.

So here’s the email I sent to the SiriusXM Customer Service folks today after yet one more call:

I realize that my trial subscription has expired. In fact I even talked to your customer representatives at least once concerning this prior to the expiration.

I happily informed the customer service representative that I knew my subscription was going to expire and that I was not interested in converting my trial at that time due to the cost, and yes that I knew it wasn’t a lot each month if I subscribed for a year. After he kept trying to get me to convert, rather insistently to the point of belligerence, I finally was able to get him to hang up.

Recently I have been receiving calls from your company (866-903-7474) at least once a day (sometimes twice).

I realize that you would like to retain customers and to gain new ones, however when a current/former customer informs you that they no longer wish to continue the subscription, it doesn’t engender good customer relations to bombard them on a daily basis with calls.

For this reason it is unlikely that I or anyone in my household will ever subscribe to your services at any point in the future. I appreciate that you have made it even easier for me to embrace the free and/or ad-supported streaming services like Pandora Radio, Spotify, Live365, Google Music, and Amazon Music.

Thanks,
Andy Fore

So instead of caring about subscribing to SiriusXM, I will just use my mobile data plan to get the most out of Internet-based streaming services that I can.  I would rather give my money to my mobile provider for data usage than to SiriusXM, since Verizon doesn’t deem it necessary to spam me with phone calls about their services.

Today while working on the AASU Blackboard VISTA custom login page, I ran into an issue loading Java applets.

Apparently, Google Chrome checks your browser plug-ins to determine if they are out of date when you attempt to load content requiring them.  Here’s a snippet from the Google Support Site about the bug feature:

To make sure you’re protected, whenever Google Chrome detects that a common plug-in on a page is out of date with a security vulnerability, a message will appear beneath the address bar notifying you that the plug-in has been blocked.

While this is a great feature, since it is an attempt to protect your computer from nefarious code, there are times that it just doesn’t work properly.

The situation I ran into is described on a chromium issue report.  Basically, the Linux version of Oracle Java 7 is being seen as out-of-date, even though it is the most recent version available.  When going into the Google Chrome plug-in preferences you may see the Java plug-in marked as disabled and showing the version number in red as well as a link to java.com to download a security update.

While Chrome does give you ability to run the plug-in each time it is used, this can rapidly become a pain in the rear.  The checkbox labeled Always Allow also doesn’t seem to work.

So what to do?  Well, you can either painstakingly click the Run this time button or you can run Google Chrome with a command line switch that turns off the plugin checking mechanism.

Being an intrepid sort that likes to live on the edge and dance where angels fear to tread, I chose to run with the checking mechanism turned off.  To update the Ubuntu application launcher to make this easier, I edited the following file:

/usr/share/applications/google-chrome.desktop

sudo vi /usr/share/applications/google-chrome.desktop

Look for the first instance of a line starting with Exec and alter it to read as follows:

Exec=/opt/google/chrome/google-chrome --allow-outdated-plugins %U

After saving the file and restarting Google Chrome you will no longer be bothered by the annoying Java plug-in error warning.  To verify this is working, you can enter the following on the command line:

ps ux | grep -v grep | grep allow-outdated-plugins

You should get back at least one result.

As a bonus, you can ensure that you are running the most recent version of Java (1.7.0_05 as of this writing) by doing the following on a command line:

java -version
javac -version

You should see something like the following:

foreandy@foreandy-iMac:~$ java -version
java version "1.7.0_05"
Java(TM) SE Runtime Environment (build 1.7.0_05-b05)
Java HotSpot(TM) 64-Bit Server VM (build 23.1-b03, mixed mode)
foreandy@foreandy-iMac:~$ javac -version
javac 1.7.0_05