Part II of the Gervais Principle

I discussed the first part of Venkatesh Rao's essay on the Gervais Principle here. He has since released part II, entitled "Posturetalk, Powertalk, Babytalk and Gametalk." Just as insightful as his first part, I highly recommend reading it over.

FOSS drivers for Broadcom Crystal HD creates a lot of potential for low-cost HTPCs

Broadcom's Crystal HD is a new technology that for most of us AV nerds that is as revolutionary as is evolutionary. Usually those are mutually exclusive, but bear with me. Anand argues that the available platforms don't make sense for what most people are trying to do. Intel's graphics platforms, while reasonable for the real-time decoding of most content, are simply too underpowered to handle 1080p. NVIDIA's ION platform, on the other hand, is just too expensive; I believe the phrase he used was "not retrofittable." This allows you to take an existing system that may just not have to juice to stream 1080p content and imbue it with that magical power, in the form of a mini-PCIE card. In the future, it should also be available in ExpressCard and 1x PCI-E form factors.

What makes this release revolutionary is a result of both Broadcom's strategy and the software ecosystem into which it will inevitably end up. First, Broadcom has released the driver under the (L)GPL for both Linux and OS X, and if you know me at all you should know how warm that makes me feel inside. This obviously has its own inherent benefits, such as a rapid update cycle, quick bugfixing, greater compatibility, etc. In combination with existing software for Mac/Linux, though, this is a no brainer. He uses XBMC as an example of one such media center because it has already incorporated the userspace support for the Crystal HD libraries, but I can easily see this being taken up by other projects such as ffmpeg, vlc, mplayer, and MythTV -- just look at how quick those projects were to adopt NVIDIA's VDPAU library!

I don't have any 1080p content currently, but that was based on my hardware limitations. Once I was able to move up from SD to 720p streaming my video library quickly upgraded. I don't think this is something I'll tinker with in the coming months, but certainly something I will follow as it combines three of my favorite things: media streaming, open source, and HD!

[via AnandTech]

Full text search indexing in sqlite3

I guess I'm a little behind the curve, but I just discovered that sqlite3 has full text search capabilities (appropriately dubbed "FTS3") a la Google. FTS3-enabled tables are actually built atop virtual tables, about which I also just found out.

Anyway, there's a great write-up about it and how to use it here.

Using ext4 when compiling your own kernel

My parents finally upgraded to a new computer this past weekend so I took their old one (PIII, 384MB SDRAM) and turned it into a file server. I used gentoo to build it and was surprised how little time it took to actually configure (compiling was a different story...). I had an old 120 GB PATA hard drive lying around so I partitioned it as follows:

• /dev/sda1 | ext2 | 100MB (/boot)
• /dev/sda2 | ext4 | 15GB (root)
• /dev/sda3 | swap | 1GB
  
• /dev/sda4 | ext4 | 104GB (/mnt/whatever)

It was all pretty standard: upgrade to sys-devel/gcc-4.4.2 and sys-libs/glibc-2.11-r1, `make menuconfig`'d sys-kernel/hardened-sources-2.6.28-r9, made sure I included baked-in support for ext4, and compiled. After waiting half an hour (literally -- `time make` took ~32 mins!), I rebooted and was welcomed by an unfamiliar message in my system log:

EXT4-fs: dm-5: Filesystem with huge files cannot be mounted read-write without CONFIG_LSF.

Fortunately, my root partition mounted cleanly and the error only applied to /dev/sda4. Googling around*, I discovered that the "huge_file" feature is implicit when running mkfs.ext4. I saw 'CONFIG_LSF' in the kernel config and the documentation said it was only necessary for files 2TB or larger -- clearly nothing I'd need to worry about -- so I didn't include it in the kernel.

Instead of recompiling my kernel, I figured I'd just reformat the partition without huge_file support. Yes, recompiling the kernel would've been a pain, but reformatting seemed like the more ideal/elegant solution -- especially considering this partition was barely 100GB. The default behavior for mke2fs.ext* can be found in /etc/mke2fs.conf (on gentoo, at least), and the culprit looks like this under the ext4 block:

features = has_journal,extents,huge_file,flex_bg,uninit_bg,dir_nlink,extra_isize

* http://old.nabble.com/Bug-509893:-e2fsprogs:-mkfs.ext4-produces-unusable-filesystem-td21193293.html

Secretly updated version of MidpSSH for BlackBerry

If you've used MidpSSH for Blackberry, you'll find that the most recent version available from the website it hopelessly out of date (last updated March 2008). If you've never heard of it, shame on you! Its the only BlackBerry SSH client of which I'm aware, and if you have a BlackBerry and use *nix, then you'll most certainly find it useful.

Anyway, while I was researching which of the myriad versions of the application to install on my new Curve 8900, I stumbled upon an old BerryReview article that links to an updated version not listed on xk72.com! It's listed at version "1.7.4 beta 2" and has a timestamp of Oct 2008 -- so its now just plain out-of-date (not hopelessly).

The big features added to this release (according to the article) include:

• BIS-B support (depends on carrier on which ports you might be able to work, IE on mine they block port 22, but I just changed my sshd port of linux box to a higher port,). When configuring the host, just add :PORT (so it would be IP.OF.SERVER:PORT)
• WIFI support
• Application is signed in order to gain access to some RIM protected APIs

I was appropriately skeptical but I figured I'd give it a shot and the changelog given is very accurate! I was able to connect to my home linux server over both WiFi and BIS (T-Mobile EDGE) whereas previously I had to be connected to a WiFi network; said server's SSH server is also open to a port other than 22, and specifying that in the connection preferences allowed me to connect; and I wasn't presented with the "untrusted application rah rah" warning when I downloaded and installed it. It also seems noticeably faster, but then that's probably just because I'm coming from an old Pearl 8120.

Unfortunately, I doubt we'll be seeing many updates to this application anymore, but this should certainly hold me over until someone else decides to pick up the ball. Besides, its not like SSH standards change very often. The source code is available to anyone enterprising enough to tackle such a huge project for the BlackBerry community.

Site hosting the application for OTA install:
http://www.deltatech.com.mx/midpssh/beta2/midpssh-bb-ota.jad