In the beginning of November, my wife and I decided to buy a digital camera as the LCD display on our old one was broken. After much research, we settled on the Sony HX9V, and I found it on an online site called AjRichies.com (not linking for obvious reasons) for $30 cheaper than Best Buy. I went ahead and placed an order. And that’s when the fun began.

It started with a phone call from a guy with a distinctive New York accent the next day to “clarify” my billing information. At the end of the conversation, Mr. New York tells me that I’ve gotten a great camera, but the stock battery that comes with it is only good for 30 minutes. He suggests that I get a long-life battery that will last for 3 hours – only $39.95. A 6X increase in capacity for $39.95 sounds pretty good, so we go for it. The guy then tries to talk me into getting a high-speed SD card, but we decide to pass on it as we already have a perfectly good 4GB SD card.

Almost two weeks later, I receive notice that they’ve shipped the package, and they also ask me to review them at ResellerRatings.com. A further two weeks later, my order arrives. When I open up the box, there’s the camera and there’s the spare battery. I looked at the battery and it’s some no-name brand rated at 1350mAh. I then open the camera box and look at the stock battery. It is rated at 900mAh. 1350. 900. The 1350mAh battery has only 50% more capacity than the stock battery. So either the stock battery will last for 2 hours of continuous shooting or the “long-life” battery will only last 45 minutes. Either way, the guy on the phone lied to me.

I decide to return the battery, and that’s when I realize what I’ve gotten myself into. I come across this site that has a lot of comments detailing how AjRichies.com (before a name change) works. It seems that their normal modus operandi is to list an item really cheap and then phone you with an upsell when you buy their item. It appears that if you decide against the upsell, there’s a good chance they’ll cancel your order, and, if you do order an extra item or two and then want to return them, they charge you a 15% restocking fee.

Bearing this in mind, I call up customer service and tell them that I want to return the long-life battery. They tell me that I’ve called sales and they’ll transfer me to customer service. I wait on hold for a good ten minutes, and, next thing I know, I’m talking to Mr. New York again.

First he tells me that he is sales and I should have called customer service. I explain that sales had transferred me to him, and beg him to help me. So he asks what the problem is and I explain that I want to return the long-life battery. He then tries to tell me that a 1350mAh battery can last six times longer than a 900mAh battery (something akin to a used-car salesman telling you that a car that gets 45 mpg gets six times better mileage than a car that gets 30mpg). When I insist on returning the battery, he tells me that I need to talk to customer service and transfers me. After waiting on hold for 25 minutes, I finally hang up. Round one goes to AjRichies.com.

I call up customer service again, and it’s Mr. New York again. When I ask if I’m talking to customer service, he says yes, and then (I assume as he recognizes my voice) quickly backpedals and tells me that he’ll transfer me to customer service. The next guy I speak to goes through the same process of trying to convince me to stick with the battery, and, only after much arguing, finally agrees to give me an RMA number so I can return the battery. I ask him how much I’ll get back, and he tells me something like $33.96. After pointing out that they had lied to me, he finally agrees to waive the 15% restocking fee, but it’s still my responsibility to pay shipping. Round two goes to me (mostly).

So I ship the battery back to them, and then wait until they’ve transferred the money back into my credit card account. I then go to ResellerRatings.com and leave this review. Within minutes, I receive an email requesting that I call them. By next morning, they obviously decide that they’ve waited for my call long enough. I receive a phone call from “Adam” in customer service.

He starts by asking why I’m unhappy. I summarize my point of view of the whole situation and tell him that I’m not happy being lied to, being put on hold indefinitely and feeling like I’m being taken advantage of. He argues that I’ve gotten the camera “$100 cheaper than anywhere else”, suggesting that I’ve gotten off lightly because they have given me the full refund for the battery, and basically says that a couple of phone calls is a cheap price to pay for the camera.

When I point out that I did have to pay shipping to return the battery to them, he immediately jumps on my statement and offers to pay me $10 to cover shipping and the time I’d wasted. But this is contingent on me changing my review at ResellerRatings.com. He then tries to cajole me into changing my review while I’m on the phone with him. When I politely decline he says, “We try and sell a nice product cheap, but I guess we can’t please everyone,” and ends the call.

So why did I refuse to change my review? In the end it comes down to this. I expect the companies I deal with to have integrity. If your sales strategy involves deceiving your customers, you do not have integrity. If the only time you’ll do right by your customers is when they’re twisting your arm, you do not have integrity. If you offer to pay customers to change their reviews, you do not have integrity. And I will not sacrifice my integrity to bolster yours, whether you pay me $10, $100 or $1 million.

On ResellerRatings.com, AjRichies.com currently has 80% positive reviews. I’ll leave the reason for this to your conjecture.

Bibletime hasn’t worked in Fedora 16 since CLucene was updated to version 2.3 because of some changes to CLucene’s API. I’ve patched BibleTime so it builds against the newer CLucene. An updated source rpm is available, and the patch is here.

The phone is dead
I bought my first smartphone, a Nokia N900, just before Christmas, 2009. Chosen because its OS was the closest thing to a stock Linux distro I could find, the N900 has stood me in good stead for the last almost two years. I’ve used it to ssh into servers and restart failed services, stream video from a LEGO robot to my laptop, and Skype my family in the States while I was in Lebanon (if I remember correctly, it was the first smartphone to include Skype, though I may be wrong).

So fast-forward to a few weeks ago, with me sitting at my home in southwest Washington, enjoying my sabbatical. I glanced down at my phone and noticed something strange: The phone signal bar was gone, and in its place was a funky symbol that I finally realized was a SIM card with a red line through it. Restarting the phone fixed the problem. But over the next few days, the red SIM of death (RSOD) appeared more and more often and I finally reached the end of my rope.

Some research on the web, and a dmesg or two later revealed that the phone’s modem was constantly resetting, and, given the reset rate, was probably going bad. As I bought the phone in the US, it only had a one year warranty… and I was screwed. Bummer. Less than two years after buying it, my $550 phone had become an expensive unimpressive tablet. Thanks, Nokia. And now I had to replace it.

Long live the phone
During the HP Touchpad firesale, I managed to get ahold of one, and was really impressed by its ease of use, especially when it comes to multitasking. So I went to see what kind of WebOS phone I could get for cheap, and came up with the HP Veer. I managed to get it and a touchstone for just over $100, including shipping.

So far, I’ve been fairly impressed with it. Like Android, WebOS uses the Linux kernel, but not much of the higher stack. It doesn’t use X or any of the other standard applications that make up a normal Linux distro. Having said that, WebOS has strengths of its own. The N900 was great at multitasking, but the Veer takes it to a new level. WebOS’s card interface is not only easy to use, but also quite fun. There’s community-created software available from preware.org, and I’ve managed to overclock both the Touchpad and the Veer.

My main annoyance with the Veer is that it can sometimes be a bit unresponsive; I’ll tap the hang up button and it will flash, I’ll tap it again and it will flash again, but it won’t hang up until the third or fourth tap. I can understand that it may be thinking, but I find it a bit annoying to have the phone act like it received the event and then ignore it.

The most common complaint you’ll hear about the Veer is that it’s too small. And it is small, very small. But I’ve got small hands, so I don’t find the keyboard hard to use, and they do make good use of the space they’ve got on the display. And, after carrying around the brick that is the N900, it’s nice to have something so light that I can barely feel it in my pocket.

All in all, I find the Veer to be more fun and more intuitive than my wife’s new Android phone (which she is rapidly falling in love with).

Conclusion
So now I get to work out whether to try to get a few bucks by putting my N900 on ebay (but who would buy what’s essentially a two-year-old 5 inch tablet when there’s far better available), or keep it as a remote control for my media center in Lebanon.

And I get to see whether I can do the same kind of cool things with the Veer that I could do with the N900. Unfortunately the Veer doesn’t seem to come with gstreamer, so the LEGO robot idea might be out. But, I have hopes that the Veer will be at least somewhat as hackable as the N900 was.

Offtopic
For those who have been following along, Naomi (my wife) and I are currently on sabbatical in the States, following a month in Ireland. I was hoping for more time to work on Fedora stuff, but the last couple of months have been a bit crazy and I can’t realisticly expect the next few to be much different. I should be able to continue fixing the bugs that have popped up in yum-presto, but not much more than that.

I would love to meet any Fedora people in the area (I’m about an hour north of Portland on I-5), but haven’t had the time to track down if anyone’s actually in the area. I’d also love to do a conference, but, again, don’t know what’s in the area.

For those in Lebanon, we will be back at the end of this year, and I’m already looking forward to seeing you again.

Over the last year or so, I’ve done very little with the yum plugin Presto. It’s done its job and done it reasonably well, but, like water wearing down an ancient monument, there have been a few little complaints that have built up, and it’s long past time to fix them. I’ve pushed yum-presto-0.7.0 to Rawhide, which deals with most of the problems.

The first complaint was that Presto would download the deltarpm metadata even when you were just doing an install. Obviously, deltarpms can’t accomplish a whole lot when you’re only doing an install, so downloading the metadata is waste of bandwidth, which, ironically, is what Presto is supposed to prevent. So, now Presto has been fixed so that it only downloads the deltarpm metadata when at least one package is being updated.

This brings us to the second complaint, which is that there’s not much point in downloading a 800kb deltarpm metadata file when you’re only updating a 50kb package. Even if the deltarpm is 0 bytes, you’ve still managed to waste 750kb of bandwidth. The problem is that there’s no way to see how much the deltarpms will save until Presto has downloaded the deltarpm metadata file, which is what we’re trying avoid.

So, now Presto checks whether or not the combined size of updated packages in the repository is smaller than the deltarpm metadata. If it is, there is definitely no advantage to using deltarpms, so Presto doesn’t bother downloading the deltarpm metadata.

There were a number of other small bugs fixed in 0.7.0. Unfortunately, because all of the fixes would be considered enhancements, and given Fedora’s update policy, I will not be pushing the updated yum-presto to Fedora 14 or 15.

The game Naev is now in Fedora’s repositories for 14+. Install using ‘yum install naev’.

Thanks, Spot, for the review.

We had a blast at the InstallQuest last Friday! I’d say that roughly 20 people showed up, and most of them were students from LES Loueizeh and LES Tyre.

We started at 4:00PM with a short introduction to Linux in general, and then Fedora and Ubuntu. David Correia (the Elementary Coordinator in Tyre), Paul-Marc Bougharios (a local Fedora Ambassador), and I presented Unity, KDE and GNOME Shell respectively. We then took a quick break, and started both the installs and the sessions.

The Sessions
My wife, Naomi, gave a talk on creating documents using OpenOffice.org/LibreOffice, and then exporting them as PDFs so anyone with a computer can read them. She was only supposed to go for fifteen minutes, but there was so much interest that she ended up going over thirty minutes.

Desaturated lizard

Hisham Hamdan, the Assistant System Administrator here in Loueizeh, then did a session on package management and system updates. We broke for pizza (generously provided by the school), and returned to a session on photo editing using the GIMP by David. He showed how to desaturate a photograph except for one small element.

Finally, I finished off the sessions with a short demo on how to use photorec (part of testdisk) to recover photos deleted off of an SD card.

The Installs
While the sessions were happening in the main computer room, where people could either use the school computers or their own, the installs were happening in the small computer room next door. We had cleared the computers from the room, leaving a few monitors, keyboards and mice just in case anyone brought desktops without the peripherals (which ended up being pointless; all of the installs were done on laptops). We left the network cables in the room and did PXE installs where possible.

Installs

Both Tyre and Loueizeh use Fedora with GNOME Shell as our default desktop, so I wasn’t too surprised that a majority of the guests chose to install Fedora. What did surprise me was the number that chose KDE. Paul-Marc did an excellent job of demonstrating just how functional (and pretty) KDE has become. For someone who hasn’t used KDE since my Mandrake days, and who hasn’t looked at KDE since 4.0 came out, it was quite the eye-opener! KDE has become very impressive, and, while I prefer the simplicity of the Shell, I can see why many are so passionate about it.

We probably ended up doing about fifteen installs, with the final one ending just before 11:00PM. We only had one failure, a laptop with a BIOS password that the owner didn’t know.

Lessons learned
While I thought the InstallQuest went well for the first time around, there are a few things I’d love to see done differently the next time around. The sessions were a big hit, but there was some disruption as people would have to leave their installs to attend a session, and then try to pick up from where they stopped. We may try to split the sessions from the installs next time around.

I would also like to see more people from the other Linux communities in Lebanon involved. We had good representation for Fedora, but only one person came to represent Ubuntu, and there was nobody from the other communities.

Related to this, we need to do a lot more advertising the next time around. While we did advertise on the Fedora and Ubuntu Lebanon mailing lists, and on a few other Lebanon-specific open source sites, I’m convinced we didn’t do as well as we could at reaching out to the schools and universities here in Lebanon.

We will be doing another InstallQuest, probably in January or February. By making some simple changes, we hope to make it an even bigger success.

A huge thank you to those involved in making the InstallQuest a success: Hisham, Paul-Marc, David, Naomi, Steve White, the principal of LES Loueizeh, and all those those who participated.

InstallQuest logo – Released under a CC-BY license. Modified from USB Flash Drive by Ambuj Saxena

InstallQuest 2011 is only four days away! The idea of the InstallQuest is to mix installing Linux on participant’s computers with short lessons on how to use their new desktops.

We have three members of the local Fedora community involved, along with a few members from other local Linux communities. A number of my students have been asking for Fedora, so hopefully this will be an opportunity for them to get it.

InstallQuest logo – Released under a CC-BY license. Modified from USB Flash Drive by Ambuj Saxena

We will be in Ireland for most of July, and then in the States (southwest Washington State) from early August until the end of December. We will be back in Beirut on New Year’s Eve and ready for a new term in school when Christmas break finishes.

I have no idea how this sabbatical will affect the time I spend on Fedora. I suspect that I will have more time available, but it’s entirely possible that the opposite may occur. Either way, I’m looking forward to seeing family and friends, and I can’t wait to watch my daughters play with their cousins for the first time.

On a Sunday a few weeks ago, I finally decided to take the plunge and install the Fedora 15 Alpha on my primary workstation. I’ve been using GNOME Shell pretty much exclusively since Fedora 13, and I was looking forward to an even cleaner setup as it got closer to its first official release. The installation went smoothly, and, soon enough, I had the new interface up and running, and, I have to say, it’s looking great!

Just a quick aside to say that I really appreciate where GNOME Shell is going. I love the favorite apps/running apps on the left, desktops on the right concept. I do miss having persistent desktops (Firefox is always alone in the first desktop, and it’s a bit of a pain to get it back there when I restart Firefox). It’s also much harder to get to my files since the recent documents list on the left has gone. But though it’s taken some getting used to, the notifications menu on the bottom has ended up being really nice.

Anyhow, on Monday after the installation, I brought my laptop to my office in the morning, booted it up, and then went off to teach my first two classes. When I returned to my office, my screen had a nice kernel panic on it saying something about sda write errors, unable to write to disk, the end of the world, etc.

Being the incredibly sophisticated hacker (read “complete idiot”) that I am, I proceeded to do a hard reboot of the laptop without taking a picture of the screen. Oops. Then, on the reboot, the system ran into a small problem. It wasn’t able to mount any of my filesystems. A quick reboot into my livecd and one e2fsck later, and my system partition was back up again (apparently with no major errors). Unfortunately, that wasn’t the end of the story.

I should probably take this opportunity to explain my incredibly cunning partition setup here. You see, I have a boot partition, two 20GB system partitions that I switch between every time I update my system, and a swap partition. I then have a 400+GB encrypted home partition, a btrfs encrypted home partition, created back in the F13 days. This home partition contains all of my data. In the world. Everything.

So I booted from my now repaired system partition and… my home partition refused to mount. It said the filesystem was unrecognizable. Oookay. How about a btrfsck /dev/sda5. “No valid Btrfs on /dev/sda5.” That can’t be good. Ok, I’m a system administrator, I should have a good backup somewhere. Check around, and there it is, dated… May 8, 2010. Well, that sucks.

This was the point where I started to get slightly worried. I hopped onto the #btrfs IRC channel on freenode and that’s where my bacon was saved. Apparently whatever caused the kernel panic also caused some major problems when btrfs was writing its metadata. Unfortunately, since I had no record of the panic except my spotty memory, we weren’t able to track down the cause. All we knew was that the primary superblock had been corrupted, and that was why none of the tools could read it.

At this point, Chris Mason (the creator of btrfs) walked me through compiling btrfs-progs from the “next” branch in git, and then compiling btrfs-select-super (which isn’t built using the normal Makefile). I used btrfs-select-super to switch to the second superblock, and voilà, I was able to mount the filesystem (read-only, of course)! Some of the metadata was pointing to junk, and I ended up losing all my files that had been changed in the last few days, but most of them were emails, which I did have backed up elsewhere.

I still don’t know what caused the problem. There were some SMART errors on the drive, but repeated extended offline scans found no errors, and manually overwriting the entire partition using dd and then reading it found nothing amiss. There was some talk of it possibly being related to luks, but no evidence pointing in that direction.

So, now I’m running Fedora 15 Alpha, with a newly created encrypted btrfs filesystem as my home partition… and daily backups. A huge thank you to Chris and the others on #btrfs on freenode who gave me such great help!

Steep cliff credit: Steep cliff by Rob Lee. Used under CC BY-ND

Deltarpm is brittle. When it works correctly, it’s brilliant. But, like a tightrope walker crossing the Niagara falls while balancing an egg on his head, all it takes is one slip and…*splat*.

At the beginning of the Fedora 15 release cycle, a new version of xz was pushed in which the defaults for compression level 3 were changed (as far as I can tell, to what used to be level 4). This doesn’t cause any problems for newly compressed data, but if you decompress an rpm whose payload was compressed using old level 3 (like makedeltarpm does) and then recompress it with new level 3 (like applydeltarpm does), the compressed files no longer match. *Splat*.

I wrote about the root problem here over a year ago, but to summarize: almost no compression algorithms ever guarantee that, over all releases, they will create the same compressed output given the same uncompressed input.

Our fix for Fedora 15 was pretty simple. Delete all of the old deltarpms in Rawhide. As long as the users have the new xz before doing a yum update, all new deltarpms will work correctly. Yay.

The problem is that this is all still extremely fragile. Take Fedora bugs #524720, #548523, and #677578 for example. All three bugs have cropped up because of mistakes in handling changes in the compression format, and it’s all a bit ridiculous. Would anyone use gzip if an old version couldn’t decompress data compressed with a newer version?

A possible solution?
There is no simple solution. So what if we change the rules? Instead of trying to keep the compression algorithms static, what if we stored just enough information in the deltas to recompress using the exact same settings, whatever they are.

For gzip, this would mean recording things like each block size, dictionary, etc. For xz, it would mean recording the LZMA2 settings. The problem is that this information is different for each compression type and the functions to extract the needed information haven’t been included in any compression libraries (to my knowledge).

However, if we could write these functions and get them into the upstream libraries, it would benefit all programs that try to generate deltas. Deltarpm would continue to work when compression algorithms change. Rsync could actually delta gzipped files, even if the “–rsyncable” switch hasn’t been used in gzip.

There are a couple of possible problems with this solution. First, I’m not sure how big the extra needed information is. Obviously, for each compression format, it’s different, but, unless it’s at most 1/100th the size of the uncompressed file, storing the extra data in the deltarpm will probably not be worth the effort.

Second, no code has actually been written. In an open source world of “Show me the code”, this is obviously a major issue. I’d love to do a reference for one of the simpler compression formats (like zlib), but just haven’t had the time yet.

Obviously, the best solution would be for the various upstreams to provide the necessary functions, as they understand both their algorithms and what information should be stored. However, most upstreams have enough on their plates without needing extra stuff thrown in from random blogs.

Another good solution would be for someone who is interested in deltas and compression to take on this project themselves. Any volunteers?

Broken eggs credit: Broken Eggs by kyle tsui. Used under CC BY-NC-ND