skippy dot net

Ubuntu Buckeyes

The Ubuntu Ohio Team was recognized as an official Local Community team this evening! LoCos (Local Communities) "work together in regional teams to help advocate, promote, translate, develop and otherwise improve Ubuntu"

The Ubuntu Ohio team has been extremely active, and there are a lot of great plans being developed. Of particular interest to me is the New User Team, and the Face2Face support initiative. I don't know that I'll have the free time to participate as much as I want, but it's definitely something on which I'll be keeping an eye.

Many thanks to all the members of the Ubuntu Ohio team for their energy and commitment to the group. Special kudos to vorian for his passion and dedication.

MVix GPL

I really like my MVix MX-760HD. It's been a great little media device for me, even if it does take me a really long time to rip our Monty Python collection to MP4 format! Next up, our Mystery Science Theater 3000 DVDs.

One of the reasons I was initially attracted to the MX-760HD was its use of GNU/Linux inside. It uses the uClinux kernel, which is designed specifically for embedded systems. I want to support companies that make use of GNU/Linux. I'm also interested in seeing what third-party developers can do with the hardware through use of the GNU/Linux operating system.

I'm not much of a hardware hacker, and I'm certainly not an embedded developer, but I admit to being intrigued by the notion of third-party firmware for the MX-760HD. The LinkSys WRT54G is a terrific example of the value of an open, hackable system: the third party firmware offerings turn this $70 device into something vastly more functional than what's provided by the default firmware. Most consumers won't need anything other than the default, but for those customers who are interested in more, it's available to them. This, to me, is the real value of Linux in appliance hardware: your customers can use your product for what they want.

I sent an enquiry to MVix USA's contact page asking for the source code the uClinux kernel they use. I'm interested in learning more about the hardware inside -- specifically the CPU and the network adapters. There's little I can do with this stuff myself, but a fellow COLUG member is an embedded developer, and I'd like to pick his brain about some of this.

I received a rather unhelpful reply from MVix USA's marketing department:

As per our contract with the development and manufacturing partners we do not have an authorization to release the firmware sourcecode under GPL. As you know, we are primarily the marketers and distributors of Mvix brand products and hence have to abide by the policies and contractual obligations of our manufacturing partners and developers.

Unfortunate, but I can't be too upset with the marketing staff not being familiar with the intricacies of the GNU GPL. I replied, expressing my disappointment, but heard nothing back.

A few days ago a gentleman named Rich K. from MVix USA sent me an email, hoping to capitalize on my zeal for the MX-760HD, asking how they might help me continue to advocate and evangalize their product. Normally, I'd be quite happy to do this. I took the opportunity to ask Rich for the GPL sources used in the MX-760HD:

I was _very_ excited to read about your use of Linux inside the MX-760HD, though I've been disappointed with my lack of success obtaining the source code to your kernel, as required by the GNU GPL license under which Linux is
distributed. I am sure _a lot_ of people would love to be able to hack on an MX-760HD in the same ways that they hack on Linksys WRT-54G routers. Small, functional Linux systems are very interesting to all sorts of users, and the more you enable us to use them in unique ways, the more units you're likely to sell.

Rich's reply was less than helpful:

We are the marketing, distribution and customer-support arm of our brand. As per our contract with our partners, we do not have adequate access to the source code, neither does our contractual obligations allow us for release of any codes. While we respect your suggestion, we regret that we cannot help. Our sincere apologies.

I replied, asking Rich for contact information for the development branch of MVix, or indeed of anyone who would be in a position to facilitate my request. I made it clear that I wasn't interested in any proprietary software or codecs -- I was only seeking that code that is governed by the terms of the GPL:

Can you please provide me with an email address or telephone number for your development folks? I'm not interested in any proprietary bits inside the MX-760HD: I'm solely interested in getting the kernel config files you've used, so that I can evaluate it.

I have not yet received a reply; and since it's been about 10 days since I sent it, I'm no longer expecting a reply.

I was willing to chalk up the initial refusal to provide source code as mostly ignorance of the issue. But Rich's reply suggests to me a slightly more intentional failure to comply with the license terms. Now, the MX-760HD is not manufacturer by MVix USA. Rather, it is manufactured by Unicorn Information Systems Co. Ltd. (Korea). I have just sent an email to Unicorn, asking them for the GPL licensed source to the Linux kernel used in the device. However, I am still of the opinion that MVix USA has an obligation to make the source code available to its customers. This is remarkably similar to the recent situation with MEPIS Linux's GPL non-compliance.

I'll be sure to post more details as they develop. If you're an MX-760HD owner, do please send a polite request to both MVix USA and Unicorn asking for the Linux source code. Feel free to share your results in the comments below.

Spread the news

So it's official: I'm leaving WordPress behind. I'm involved with the development of Habari, the next-generation blogging solution. One might wonder why we're re-inventing the wheel. Someone recently quipped that we're past the wheel, and are now working on the hovercar! Nonetheless, an explanation of what Habari offers should help explain why I'm involved.

Community

Community is the cornerstone of Habari development. It was community that brought the four of us together, and we're keeping community squarely in mind as we approach decisions and plan features. We recognize that only through collaboration will Habari succeed: each participant brings with him or her their own unique skills and passions. This diversity of talent and ability is an important aspect of Habari's community.

Another important aspect is that Habari is owned by the community. No one person has full authority over it. The people who use it and work on it are the ones who should -- and will -- make decisions about Habari development. Additionally, community members should be given the power to take charge of their areas of expertise. If someone is passionate about documentation, they ought not have to work through someone else's restrictions in order to make the docs successful.

Innovation

Habari is about innovation. There's a lot of great things being done with internet technologies, and we are very interested in integrating them into the way we blog. Things like OpenID, CoComment, and the Atom Publishing Protocol are all very useful innovations. We've been frustrated by the difficulty in integrating these -- and more -- into WordPress. Some of the roadblocks to integration into WordPress were technical, while others were clearly non-technical. We hope to remove both kinds of roadblocks and make Habari the most cutting-edge blogging system available.

One of the very first decisions when planning Habari was to make it a fully object oriented system, and leverage the powerful features of PHP objects. This has resulted in some wonderfully efficient code, and so far the system is remarkably fast. Object oriented programming allows us to streamline the development of user-created plugins; allows us to integrate a unified error handling system; and vastly simplifies the construction of our Application Programming Interface.

Another early goal of Habari was database independence. There exist enough database abstraction libraries that locking oneself into a single database really does seem a poor design decision these days. By using PHP version 5, we gain access to the PHP Data Objects (PDO), which is the PHP-native database independence solution. We currently have MySQL and SQLite working, and are eager to find contributors with PostgreSQL experience. Preliminary conversations suggest that Oracle support wouldn't be too hard, either, surprisingly enough. Another very real benefit to using PHP5 + PDO is that we gain the use of prepared statements for all database interactions. This drastically reduces the likelihood of a SQL injection attack against your blog. We're considering using stored procedures, too, as both a means to improve performance as well as to improve database independence.

Documentation

As much as we're striving to make a system that's friendly and intuitive, we recognize that not all people have the same background as we do; and as such what's intuitive to us might not be intuitive to a first-time blogger. Documentation is of paramount importance to the Habari project. End-user documentation and developer documentation will both be included in the download.

We plan to integrate links to the manual into the Habari administrative interface, so that you may get help about specific parts of each screen with a single click. The manual will be part of your Habari installation, so if you can get to your site you can read the manual. Users should be able to access the documentation without relying on our possibly flaky servers to store the manual they need.

Developers -- and would-be developers -- should also be provided with meaningful documentation. We're fully documenting (via PHPdoc) the source code to Habari, and plan to include thorough instructions as to how the system operates: initialization, request processing, theme and plugin dispatching, and more. This is a fundamental part of the Habari distribution, and not left to the kindness of volunteers after the fact. New methods will be documented when they're included in a new release, not after someone figures it out on behalf of everyone else.

Another important aspect of documentation is meaningful changelogs, listing real changes to the product since the last release. Distributors and integrators rely on changelogs to see what's happened. Developers rely on changelogs to be made aware of fundamental changes to systems they might be using or extending.

Experimentation

Habari is not afraid to experiment with new ideas. The Subversion repository ensures that nothing is ever truly deleted. If someone eagerly checks in a new idea that proves to be either poorly implemented, or maybe just not such a great idea after all, the revision control system makes it easy to correct the situation and move on. We hope to support developer branches for their own work outside of the core trunk.

With all these people having access to check in new code, it's a very real possibility that someone might try to intentionally foul things up. If someone were to flake out and try to actively harm the project by deleting files or polluting contents, the other project members could simply roll back to a previous version before the attack and keep going. If someone checks in something by mistake, or implements something broken outside of their area of expertise, it can be dealt with relatively easily.

Development Model

I met DrBacchus several years ago, and it's been fascinating to listen to him speak about the Apache development process. The meritocracy of the Apache Software Foundation is such that regular participation results in increased permission within the project. This is the model we've decided to adopt for Habari: frequent contributors are given access to submit new stuff directly, because they've proven themselves capable.

This is important for several reasons. First, we each have our own areas of interest and expertise, so by getting more people involved directly we speed up the development of all areas of the code. Second, more people are available to deal with problem situations. Third, the project as a whole doesn't slow down if a few of the developers are offline for extended periods of time. Finally, more developers improves our "bus factor": it takes more people getting hit by more buses to interrupt the project.

Spread the news

We've been working on Habari since October, 2006. I'm tickled that many of the suggestions on "What the new kid on the block needs to get right" had been discussed long before we ever announced the project. With the influx of interest and enthusiasm, there's been a lot of attention on the installation process. Hopefully we can dedicate as much energy to the upgrade process as well.

I'm thrilled with the response to Habari so far. Owen's posted some more info about Habari, as well as a collection of links to some other posts about it. The IRC channel is becoming surprisingly busy. I know eventually all the enthusiasm will taper off, and tough decisions will need to be made; but for right now the sky's the limit!

Needless to say, I'm very excited about Habari!

Over Engineering

I'm considering getting new computers for the twins. Tayler has my old Shuttle PC, a 2.4 GHz Pentium 4 with 1GB RAM. Tyler has Carina's old 1.8 GHz Pentium 4, also with (I think) a gig of RAM. With the price of PCs these days, it seems almost silly not to buy new ones, and enjoy dual core processing.

I grudgingly permit the twins to use Windows XP on their desktops. They like to play the occassional game of Sims 2, or some other PC game, as well as a variety of web-based games. All of these web-based games use Flash, and most of them now use the new Flash 9. Alas, Flash 9 is only available in beta format for GNU/Linux, and my limited experience with it was less than stellar.

The kids' machines are currently dual-boot, with GNU/Linux installed on the off-chance I need to do some hefty computing on these boxes. The girls almost never boot into GNU/Linux, so the dual-boot is more a distraction for them than anything else. Any new machine(s) I purchase will be required to run GNU/Linux, though I'm willing to continue to permit Windows for the kids as needed.

I've been fiddling with VMware at work, and I've been eyeing Parallels (due largely to Bob's continuing advocacy of their product), which got me thinking about how I might use a virtual machine for the kids' computing environment. I could construct the kids' profiles such that when they log in, it immediately launches the VMware instance of their Windows image. I could give the kids administrator privileges inside their VMs, if I felt like it, without worrying about them trashing the system as a whole. The only (immediate) challenge is how to shut the computer off when the kids log out of the virtual machine (they're notorious for leaving their computers on unattended). Owen suggested I configure the hardware to hibernate when the power button is pressed. I wonder if that would work...

Tayler received a Palm handheld for Christmas from her biological father, and some of the support utilities require administrative privileges for full functionality (SplashPhoto being the worst offender, requiring admin rights for any functionality!) The SanDisk MP3 players I purchased for the twins for Christmas also seem to require admin privileges in order to load music onto them.

The virtual machine solution has a lot of appeal. It allows me to continue to use GNU/Linux on their computers, should I need it (Kino to crunch video of Christmas morning, for example). I can grant administrative privileges to the kids' virtual accounts, and it gives me some control over how to recover from any malware that might infest their computers. It allows me to provision specific amounts of resources to their use, leaving the computer(s) still usable to me via remote access.

I can't help but feel, though, that just maybe I'm over-engineering the solution.

Codec Compatibility Chart

The MVix MX-760HD is a neat little device, and I've had fun fiddling with it. In order to help others who might be interested in it, I've documented some of the media formats it supports.

Introduction

Video encoding seems to be a pretty complex thing, with a lot of variables involved. I'm not interested in learning the deep magic (or the mathematics) of video and audio compression; but on the other hand I'd like to know that I'm getting better-than-decent results from the tools I use. I don't (yet) have a high definition television set; I don't have a top-of-the-line home theater system; I'm not an audiophile; and I'm not obsessed about getting perfect quality in the smallest file size. I'd like to find some process that converts my DVDs to files I can store somewhere. I'd like these files to preserve multi-channel audio, when present in the original; and I'd like the quality of these files to be at least a little better than "decent". In my opinion, hard drive space is cheap, so I'd prefer quality over compression when it comes to ripping the DVDs. I don't think hard drive space is so cheap as to store raw DVD images, though, so I do want some compression to occur.

I use GNU/Linux as my operating system, and when possible I prefer to use Free Software and open codecs. The latter is currently impossible when it comes to multi-channel audio, at least as far as I've found so far. Various external factors do influence my decisions with respect to codecs, as well. For example, my wife has an ipod, which doesn't natively support Ogg Vorbis audio; so all of our CDs will be ripped to MP3 format.

Tools

The software I've used so far includes Handbrake and avidemux2. I found the Post Your "Best" Settings Here, and WHY thread on the Handbrake forums to be very helpful. Not knowing entirely what I was doing, I posted a question on the avidemux2 support forum, asking for guidance. The responses to my question pretty well match with my experiences documented below.

Methodology

I started by encoding the same scene from Lord of the Rings: The Fellowship of the Ring using all the combinations of container format, video codec and audio codec provided by Handbrake (here's the script I used, and here are the files I created -- the files are no longer online). I then played each file in Totem (using Xine as the actual backend, rather than the default GStreamer):

for i in `ls`; do totem $i; done;

For comparison, I also played each of the files in MPlayer:

for i in `ls`; do mplayer $i; done;

Finally, I tried to play each file on my media player. I had to rename the OGM files to .mpeg before the MX-760HD would recognize them as movies it could (try to) play. It's a bit disappointing to note that the Ogg container format isn't supported at all by the MX-760HD; though the Vorbis audio codec is supported. As such, I've excluded it from the tables below, and instead listed only those container formats that actually produce some playable output on the MX-760HD.

Results

Here's a PDF of all the codec combinations and how they fared in the players I tried.

Summary

It's pretty clear that AVI is the best container for the MVix. It's also worth noting that the x264 codecs are completely unplayable on the MVix.

Xvid is an open implementation of the MP4 standard, so I've chosen it as the video codec to use when ripping movies. I'm still fiddling with options that affect quality and file size. So far, I've been doing two-pass encodings with large target sizes (2 - 3 GB), rather than constant bitrates.

Since most DVDs have multi-channel audio, a feature I wish to preserve, I will use AC3 as the audio codec when ripping DVDs. For source media that lacks multi-channel audio, I'll likely continue to use AC3, for convenience sake (since I'm scripting many of these operations), but I may elect to use Vorbis, since it's an open codec.

Feel free to post suggestions in the comments, if there's anything I've overlooked!