Bell charges $51.20 per MB for data usage on cell phone
Today I received my Bell mobility monthly bill. I took note of one line, where it showed Bell charging $51.20 per MB of data usage. I do not have a data package and my phone is an older Samsung. This rate struck me as a bit high, even if I don't have a data package. Incidentally, when I purchased this phone, I had asked for a data package. However, when the phone arrived the contract clearly showed there was no data package. Bell told me afterwards that the phone I had could not have a data package and that I should never have been told I could have one. Nice way to sucker people into buying phones Bell.
Upon calling Bell, I first had to wade through their highly annoying female computer system answering questions and giving my cell phone number. After 1 minute 30 seconds I got annoying and hit zero (0) to get a real person. It then took another two (2) minutes for the person to arrive online. Strangely enough, I then had to answer a bunch of questions and give this girl my cell phone number again. Tiffany--she also gave me her employee number, but so quickly I did not get it--then spent the next four and a quarter (4.25) minutes letting me know that she can reverse the charges.
So, in the end, I spend 7.75 minutes to not pay for this erroneous usage at an amazing rate of $51.20 per MB. Curious, I wanted to find the area on the Bell.ca website where they tell you that you will pay this high rate for data usage, but the only thing I could find was a note saying:
- Additional data: 5¢/MB in Canada, $6/MB in the US
In the package details, they often had little numbers referencing small print. On numerous occasions, I could not find the small print, or, the number was larger than any number in the small print.
Bell, you have officially confused the hell out of me. Tell me why, exactly, I should get another phone from you?
Apache: No space left on device: Cannot create SSLMutex
Today, for the first time on one of our servers, I was unable to restart Apache. Running a configtest showed no errors, so something else was up. Looking in the Apache error logs, there was a line: "No space left on device: Cannot create SSLMutex".
If you ever get this, chances are you are suffering from Apache leaving a bunch of stray semaphore sets lying around after an attempted restart of apache. A semaphore in simple terms, is a lock on an operation. The fix, with many thanks to Carlos Rivero solved my problem instantly. Note that his solution does not fix the root of the problem, rather it simply gets you going again.
In terminal do the following using the ipcs app, which according to the man pages "ipcs - report XSI interprocess communication facilities status" . The -s flag will show a list of semaphores sets:
-
ipcs -s | grep apache
Most likely you will see a fairly large list here. You need too, and it is safe too, have these deleted. The following command will again do the trick:
-
ipcs -s | grep apache | awk ' { print $2 } ' | xargs -n 1 ipcrm -s
Note: If your apache is running as nobody or another user, be sure to substitute that other user in place of apache above.
<h2>Cannot create SSLMutex solution</h2>
At the heart of the problem, is most likely a poorly configured Apache server. By default, SSMutex is configured to the default setting, as it was on this one server of ours. If you read the Apache.org pages for mod_ssl configuration, they have this to say about the default setting:
<pre>
The following Mutex types are available:
none | no
This is the default where no Mutex is used at all. Use it at your own risk. But because currently the Mutex is mainly used for synchronizing write access to the SSL Session Cache you can live without it as long as you accept a sometimes garbled Session Cache. So it's not recommended to leave this the default. Instead configure a real Mutex.
</pre>
There are of course optional configuration settings. At the very least, it is suggested that you set SSLMutex to sem, which will let Apache choose which SSLMutex type to use.
You will most likely find this setting in the ssl.conf file located at /etc/httpd/conf.d.
Learning to use Aperture
Before the holidays I started to use Apple's Aperture photo management software. Mainly because my new camera lets me shoot in Raw, and I also wanted more control over editing and organizing all my photos. The following bugged me for awhile, so I am posting it here as a reminder to myself:
How to bulk remove keywords in Aperture
If you import your library from iPhoto, there is a new keyword on every single photo called 'iPhoto Edited'. Removing this keyword is simple once you know how.
- Click on 'Projects' Tab.
- Click on 'All Photos'
- Under View menu choose 'Browser Only'
- Select All the photos - Command A.
- Press 'Shift D' to show keyword controls
- In the 'Add Keyword' field, enter the keyword you wish to remove
- Then press 'Shift Return'
All of the photos you selected will have that keyword removed automatically.
VMWare Fusion stuck at Shutting Down
This morning when I got to my Apple Mac Pro, I saw that VMWare Fusion, which had been running Window XP, was stuck at Shutting Down Windows. Presumably Windows decided to do an upgrade during the night and got stuck when it tried to reboot.
Going to the menu 'Virtual Machine->Shut Down Guest' didn't do anything. The trick was to hold down the option key, which changes the Shut Down Guest to 'Power Off'. Selecting this worked fine.
Hope this tip helps someone else.
Flash flaw puts most sites and users at risk
Computerworld is running a story on a significant security hole in Flash.
The long and short of it all is that a security hole in Flash is in the wild, and is unpatchable according to Adobe.
Mike Murray, the chief information security officer at Orlando, Fla.-based Foreground Security says "The best mitigation is to not use Flash, but we know that that's impossible for most users, since Flash is so widely used on the Web. Almost everyone using the Internet is vulnerable to a Web site that allows content to be updated inappropriately. That's not hyperbole, it's just fact. This has the potential to affect any social media site, any career site, any dating site, many retail sites and many cloud applications. That's why this attack is so serious. End users would never know they got exploited."
To read all about this, and how it might affect you, please take a moment to get educated and read the story at ComputerWorld.com.
