ZenLinux Blog

As mentioned in my previous post, I now have a Sony PRS-T1 ereader – my first e-ink device. Rather than run down the specs of it and cover the same things everyone else mentions in their reviews, here are some links you can follow to other reviews which I found useful:

Engadget Review: Sony Reader Wifi

MobileTechReview’s video review

Gadget Review: Sony Reader Wifi Review

I’ve been reading ebooks on a Samsung Galaxy Tab 7″ Android tablet for a while now, and never realized until now how much nicer an experience it can be to read using an e-ink device.

Here are a few observations I haven’t seen mentioned in other reviews…

A lot of reviewers prominently note that the device uses a full refresh when turning pages. This is true. However, the Sony is capable of doing partial page refreshes, and does so when bringing up menu items or when using the browser. I’ve noticed some mild “ghosting” effects when partial page refreshes occur, and I’ve heard that this is a common problem on other ereaders which do partial page refreshes. The full page refresh when turning pages doesn’t bother me in the least, and I actually prefer it knowing that it prevents the ghosting problem from occurring.

One thing I have been disappointed about is the Google Books “integration”. I originally assumed that the Reader had the actual Google Books Android application. This is not the case. Instead, when you click on the Google Books “app”, it actually loads the Sony Reader application, but brings you to a section of their site where you can search for the free Google Books. You cannot retrieve or purchase ebooks directly from Google Books using the device. I can however download my purchased books from Google Books and then sync them to the Reader using a PC.

I do find it quite handy to have access to a web browser, even though scrolling on it is cumbersome with the e-ink refreshes. Here’s a tip – don’t use your finger to scroll the web page. The prev/next hard buttons will perform a page up/page down action on the web page, minimizing the refreshing latency.

The glossiness of the plastic bezel hasn’t really been an issue. It does attract fingerprints, but I also don’t really notice it that much. These issues could be resolved by getting a thin gel case if they really bother you. My guess is the type of people who get worked up about such things are also the type who can’t stand to break in the binding of an actual paperback book they’re reading. 🙂

Apart from the unwelcome surprise of the Google Books non-integration, I’m quite happy with this device. Also, there is news that the Reader has already been rooted, so in a short time I look forward to having the ability to install arbitrary android apps on the device. Google Books will certainly be one of them, as will ReadItLater.

I recently became the owner of an e-ink ebook reader, the Sony PRS-T1. Inevitably the first question someone asks me when they see me with it is, “why’d you choose the Sony instead of a Kindle or Nook?” So here I’ll share my thoughts on that, and follow-up with another post reviewing the Sony model itself. Forgive me, this is a bit of a rant…

So, why go with this Sony model? To some extent it was a process of elimination. Let me first explain why buying a Kindle is out of the question for me. While it’s true that Amazon’s store offers the largest selection of ebooks, and their ereader hardware is of good quality, what most people don’t realize is that Amazon has made some very strategic choices to try to entrench their own proprietary format at the expense of open standards.

When you buy a Kindle, you’re locked into using a Kindle (or Kindle app) forever if you want to read the ebooks you bought using it. This is because the Kindle supports Amazon’s proprietary ebook format, and nothing else.

There does exist an open file format for ebooks, called ePub. Books in the ePub format are generally much more portable, and can be bought from multiple sources, such as Google Books. These ebooks can be read on pretty much any ebook reader platform (including Android tablets and phones), with one exception. Amazon has to date deliberately left out support for the ePub format in their hardware ereaders.

Amazon’s motivations for doing this are pretty clear – they are the indisputable market leader in selling books and they want to support their own proprietary format, and have no interest in seeing an open ebook format succeed, even if it has been adopted by the rest of the industry. Heaven forbid you buy an ebook from Barnes and Noble to read on their device. Amazon’s omission of ePub support is a blatant middle finger to the concept that a common standard can exist to allow people to buy ebooks from their store of choice and read it on their device of choice.

My friend Jason once said to me something to the effect of: “Amazon settled on MP3 [an open standard without DRM] as their file format for their music store when it was their chance to ‘stick it’ to Apple [which was using a format that locked users into their iTunes player and iPod devices]. But now that they’re the market leader in books, they won’t dare to support an open ebook standard.” I thought this was pretty insightful.

Now whether you care about ePub succeeding as a common format or not, when you buy a Kindle you are placing your book purchases at the mercy of Amazon for the forseeable future. You’ll be dancing to Amazon’s tune for whatever business decisions they make down the road, or risk losing the ability to read your ebook collection. I don’t know about you, but I’m not interested in submitting to this form of vendor lock-in. As such, I have no intention to buy ebooks in a proprietary format, whether it be Amazon’s or anyone else’s.

Unlike the Kindle, the Nook Simple Touch supports ePub ebooks (in addition to Barnes & Noble’s proprietary format, which is being phased out), so the Nook was at least an option for me. A neighbor of mine recently bought one, and I had considered getting it after trying it out. The only feature I found missing was the ability to play music on the device. I often read on public transit, and can be easily distracted if I don’t have something to block out external noise or conversations. So I decided to wait it out a bit longer.

When I recently saw that this Sony model was released, it appeared to offer the right features – everything that the Nook could do and a bit more (like being able to annotate ebooks, and of course an MP3 player). The reviews were quite positive, and even touted integration with Google Books and Overdrive Media Console (for checking out ebooks from the library). Of course the included applications try to steer you to buy ebooks from Sony’s proprietary store, but I could ignore that and stick with my ePub formatted books from other bookstores. The device was priced reasonably (which was not the case with Sony’s previous ereader models), so I decided to pick one up.

I’ll follow up with a short review of the PRS-T1 soon.

The following originally appeared on the Yocto Project’s blog:

The Yocto Project’s developers have been working hard to improve the usability of our software, especially its “out of the box” user experience. One area that has admittedly been a thorn in our side is when users need to access the internet via a network proxy server*. I thought I’d take a few moments to explain the situation, why we don’t have a “silver bullet” solution yet, and how to work around it.

If your personal or corporate network doesn’t require you to use a network proxy to access the Internet, consider yourself lucky. Proxies complicate network communications, requiring special protocols (such as SOCKS) to pass your development computer’s packets out to the Internet and back. And while the “do one thing and do it well” design philosophy of Linux/Unix programs has allowed these utilities to weather the test of time extremely well, there is no universally adopted method of modifying the networking behavior of these programs when it comes to using proxies. Here are but a few methods Linux programs can be made to use a proxy server:

• Some utilities check for a special environment variable (HTTP_PROXY, HTTPS_PROXY, FTP_PROXY, etc)
• Many desktop applications (e.g, GNOME apps) look for a proxy settings key in their global desktop registry
• Others (like Subversion, or Mozilla Firefox) have their own config files or internal configuration dialogs where you have to specify proxy settings
• Finally, some programs don’t contain any code for working with network proxies at all! In this case, you can sometimes get away with running the program under a separate, wrapper program which intercepts its network communications and automatically routes them through your proxy (tsocks is one of these wrapper programs)

I’m reminded of the saying: “Standards are like toothbrushes – everyone has one, but no one wants to use anyone else’s.” Truth be told, there is really no single solution to the proxy problem.

Another issue that poses problems for Yocto Project developers is that many of the proxy configurations for various tools (such as Subversion) are stored in the user’s own home directory. And modifying configuration files in your home directory is not something that will endear us to many users.

So what do you need to do to work with the Yocto Project behind a network proxy? Rather than filling this blog post with configuration tips, I’ll refer you to our wiki page, Working Behind a Network Proxy, where we make every effort to keep up to date with configuration tweaks needed for network proxy users.

If anyone can devise a way of reliably automating this process into a support script we could ship with the Yocto Project, we would be very open to including it. Just keep in mind that the script’s actions cannot clobber other config customizations a user may have, and would need to be fully reversible, to work for users who need to move in and out of proxied network environments.

* Note: a network proxy is different from a “firewall” – Yocto builds should work fine when run from behind a typical firewall router. Sometimes the terms “proxy” and “firewall” are used interchangeably, but they are quite different concepts.

After blogging that I bought the Archos 43 to replace my Archos 5 IT, I promised to write a short review of the A43. Well, here it is.

First of all, I am much, much happier with Android 2.2. I’ve found it to be an order of magnitude more stable and responsive than 1.6 was on the Archos 5. I don’t have to worry about app compatibility, and the wifi and power management are rock-solid. I still use it primarily for recreational browsing, ebook reading, checking transit arrival times, etc.

I never thought I’d make use of the camera – which definitely isn’t of high quality – but I actually find it kind of fun to take spontaneous photos of places I’m at or meals I’m eating. The slim form factor and 4.3″ screen make it very pocketable, and I find I don’t miss the larger screen of the A5 as much as I thought I would. Archos has been releasing firmware updates every month or so, and I’m glad they are actively supporting this device.

My biggest (and just about only) beef with the Archos 43 is the resistive touchscreen, which is many times worse than the one on the A5. It seems that Archos tried to make the touchscreen as sensitive as possible, but this results in “ghost” presses and scrolling unreliability unless you are very careful to always use the edge of your fingernail (or a PDA stylus).

The behavior when you try to use the pad of your finger is so bad, I uploaded a video of it to demonstrate:

Unfortunately the section of the video where I was scrolling a web page did not come out (too much constrast), but the Screen Test Toolkit demo made the same point.

I’m never buying a tablet with a resistive touchscreen again, that’s for certain. This problem makes it so I can’t hold the tablet in one hand and scroll web pages with my thumb – everything is forced to be a two-handed effort.

Overall I am happier with the A43 but I feel it still has a serious flaw that I have to continually work around.

For a while I’ve just ignored my issues with LCD image persistence – essentially the same thing as screen burn-in on CRTs. Fortunately, LCD image persistence is not permanent. I’ve read conflicting accounts of how to get rid of it, but haven’t had any luck with methods I’ve tried.

Until now, that is. This short guide explains that the quickest solution to LCD image persistence is to force your displays to alternate between all-black and all-white images. It mentions doing this with a photo slideshow screensaver. I did it with the GNOME screensaver utility, let it run overnight, and my image persistence problems are gone. Just thought I’d share the solution that worked for me.

I was recently asked to give a short presentation to the Yocto Project team about how to upstream patches most effectively. I thought I’d share it:

I don’t think there’s anything too revealatory here, but it might serve as a good reminder of some best practices for collaborating with open source communities. One thing I will say is that I have been impressed with Intel’s commitment to getting our work integrated upstream when possible. My management really cares about this, not simply because it makes our work easier in the long-run, but because it’s part of being a good open source citizen. And as an additional bonus it keeps us on Greg Kroah-Hartman’s good side. 🙂

chroots provide an extremely useful way of running multiple Linux distros on a single computer without having to run them within a full virtual machine environment. Why would this be an advantage? Well, in my case, I’m performing builds of hundreds of packages for the Yocto Project, and I want to maximize performance by avoiding having to go through a virtualization layer to access my hard disks.

My goal was to create a minimal environment which closely matched what we’re running on some of our autobuilders, which happens to be openSUSE 11.2. It’s easy to set up Debian-based distributions within a chroot by using the debootstrap command, but openSUSE doesn’t have anything analagous to this AFAIK.

It turns out it’s pretty simple to use zypper, openSUSE’s command-line package management utility, to bootstrap an installation into an arbitrary sysroot that you can then use to pull in additional packages over the network. The only caveat is you have to create your initial chroot on an existing openSUSE machine where you have root privileges. Here’s how.

The first thing you’ll need to do is set up the most basic openSUSE package repository config within your sysroot. To create this in the /data/opensuse-11.2 directory, you’d do the following:

mkdir /data/opensuse-11.2
zypper --root /data/opensuse-11.2/ ar http://ftp.osuosl.org/pub/opensuse/distribution/11.2/repo/oss/ repo-oss

Next, you’ll need a /dev/zero device file within your sysroot, since some packages have post-install scripts which make use of it. You can create it manually, but I prefer to simply copy it from /dev:

sudo mkdir /data/opensuse-11.2/dev
sudo cp -a /dev/zero /data/opensuse-11.2/dev/

Presumably you’ll want to move this chroot onto another computer as soon as possible, so here I only install a few needed packages to get started (rpm, zypper, wget, and vim). An editor can be handy in case you need to edit a configuration file (in my case, to configure system-wide proxy settings in /etc/sysconfig/proxy):

sudo zypper --root /data/opensuse-11.2/ install rpm zypper wget vim

At this point you can now tar up the chroot and copy it over to your destination machine of choice. Keep in mind you’ll still need root privileges to tar it up properly:

cd /data
sudo tar cvjf opensuse-11.2.tar.bz2 opensuse-11.2

I use schroot to manage my chroots and highly recommend this little-known utility. It allows you to work within a chroot’ed environment but still have access to your home directory (or any other directory, if you configure it as a bind mount).

After having moved my chroot to its final destination, I added additional zypper repositories and followed the Yocto Project Quick Start Guide to install required build dependencies.

zypper ar http://download.opensuse.org/update/11.2 repo-update
zypper ar http://download.opensuse.org/repositories/security/openSUSE_11.2/ security
zypper ar http://download.opensuse.org/repositories/openSUSE:/Tools:/1.7/openSUSE_11.2/ tools
zypper refresh
zypper install python m4 make ...

From that point on, I could fire up a schroot session anytime I needed to perform builds within a minimal openSUSE 11.2 envrionment with no need to deal with virtualization environments or reboot into another OS.

My interest in internet tablets started when Nokia announced the N770, a really innovative tablet (long before the existence of smartphones) that ran an open source software stack called Maemo. Unfortunately, the N770 was a toy and far too underpowered to be particularly useful. Some time later I upgraded to a Nokia N800, which again was annoyingly slow to use. But it was also just useful enough that I started bringing it with me to read a web article or PDF while taking public transit.

As time went on, a few Android-based web tablets started hitting the market, and I decided to buy an Archos A5IT several months ago. This is a quick review of the device.

The Good:

• It runs Android. Now I could find out what the Android phenomenon was all about (to this day I still don’t own a smartphone)
• The screen quality is outstanding – very bright and crisp
• It has decent battery life, and can stand up to multiple days of heavy use before needing a recharge
• The web browser is decent (the Maemo web browsers were way out of date and incredibly buggy, having something that worked consistently was a big step up for me)
• It’s a great ebook reader. I use the Aldiko ebook reader and have bought a few DRM-free books in ePUB format.
• It’s reasonably fast. The usability in terms of application speed is comfortable.

I use this thing daily as an mp3/ogg player, read ebooks and articles on the web, check the weather forecast, and keep up with twitter. I’ve even occasionally used Instant Messaging with it. And of course I played Angry Birds when it was back-ported to Android 1.6.

The Bad:

• It runs Android 1.6, with no OS updates on the horizon. Archos occasionally releases firmware updates (which are simple to apply over a wifi connection), but Android 1.6 is extremely dated. Bugs I feel are related to Android 1.6 are:
• The wifi frequently does not re-associate when waking from sleep, about 20% of the time. I then have to go into the settings and manually turn off/turn on wifi to work around this.
• Everything slows to a crawl as it runs out of RAM. The use of Advanced Task Killer helps in this regard, but doesn’t clean up apps automatically the way I’d like it to. I have to use it to kill apps manually when I notice the slowdown.
• I can’t run Mobile Firefox, which requires Android 2.x
• It has a resistive touchscreen, which is generally annoying to use. Every smartphone I know of has a capacitive touchscreen, which requires less pressure.
• The screen size is unusual, even today with more tablets on the market. The screen measures 4.8 inches diagonally, and for whatever reason some apps like Aldiko and InstaFetch don’t always apply margins correctly, causing odd layout and overlapping issues.
• The GPS is useless. I’ve tried several times to get it to sync up with the GPS satellites, but even after a half-hour with a good view of the sky it doesn’t even appear to get a full lock on one of them.

I give Archos credit for making an attractive tablet at a reasonable price, and I rely on this thing just about every day. But now that the market is really heating up with non-smartphone tablet options, I can’t recommend it any more. Especially due to the ancient version of Android it still uses.

In fact, I recently decided it’s not worth putting up with these shortcomings any longer, and with a bit of apprehension just ordered an Archos 43 tablet, which is the new generation from Archos, runs Android 2.2, and addresses most (but not all) of the shortcomings I mentioned above. After a few months with the Archos 43 I’ll do a similar review and let you know what I think of it.