ZenLinux Blog

If you’re in the Portland area and are curious to learn a few things about the Autotools, please feel free to attend the December meeting of the Portland Linux User Group at PSU. I’ll be giving a novice-friendly introduction to the Autotools.

Autoconf. Automake. Libtool. This trio of build configuration utilities (known as the Autotools) are used in a large majority of compiled software applications for Linux, but they remain a mystery to many of us.

Finally, Scott will offer some practical tips for understanding and fixing errors you may see when building an Autotools-based package. It’s sure to be a fun romp for the whole family.

When: 7-9pm Thursday, December 1, 2011
Where: Portland State University Engineering Building, room FAB 86-01 (this is in the basement). The building is on SW 4th Ave across from SW College Street.

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.