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.

Last year marked a new first for Portland, OR – the birth of the Open Source Bridge technical conference. In a previous post I expressed a great deal of enthusiasm about how awesome last year’s event was. Those weren’t just kind words – I found myself moved enough by the incredible activism and community in the Portland tech scene to get involved for this year’s conference as a volunteer. That’s right, Open Source Bridge is back in 2010! June 1-4, to be exact.

This year’s event has an outstanding presentation lineup and will be held at the Mark Building of the Portland Art Museum. I had a chance to tour the venue with the OSB organizing crew and must say that the location is really unique, inspiring, and truly fitting for a conference of people who are working to improve the world through quality open source software projects. There will once again be a 24-hour hacker lounge (a major highlight from last year), this time on-site at the Mark Building.

One of the great things about OSB is that it’s a very diverse gathering of open source citizens, and offers a great opportunity to expand your horizons to learn about tools and platforms you may not have encountered before. I will also be giving a variation of my PLUG Advanced Topics talk on OpenEmbedded if embedded Linux systems pique your interest.

Check out the Open Source Bridge website to learn more and register. Trust me – it’s gonna rock your socks.

I am happy to report that our Rails Rumble application was indeed completed within the 48-hour time limit! We named the app A Well-Oiled Machine and you can try it here (Update: The Linode server made available to us during the contest is no longer active. I will need to re-deploy the app elsewhere in the near future). The app does require an OpenID account to log in – if you don’t have one I would recommend using myopenid.com.

I had a great time working with Jason and Jesse on this app, though I must give them credit for doing a lot of the heavy-lifting when it came to coding. My rusty Rails skills became evident pretty quickly, and I had to curtail the scope of what I worked on to make sure I didn’t turn into a bottleneck. That said, it was still a true team effort, and it felt good to immerse myself in the Rails world again.

2009 Rails Rumble Hackfest

The contest required the use of git for version control, and I am sold on this tool. It is fast and the workflow it promotes is much more sensible and flexible than subversion. Deployment remains a breeze with Passenger (mod_rails for apache) and vlad (a simpler deployment tool alternative to capistrano).

Friday night and Saturday we worked from my dining room, and on Sunday we made the trek out to Backspace for the final effort.

2009 Rails Rumble Hackfest at Backspace

It was an intense effort and the resulting app has a couple of rough edges, but we did accomplish what we set out to do, and I consider that a great achievement. Many of the Rumble contestants didn’t even end up with a working app. It was an honor to be able to work with Jason and Jesse on a project together, and I would jump at an opportunity to do this kind of thing again. Thanks guys for your outstanding effort and attitude!

This year I put a team together to participate in the Rails Rumble, a programming competition to create a web app using Ruby on Rails within a 48-hour time limit. In past years I’ve followed the event, but for various reasons not had the time to participate. This year I decided to jump right in, despite the fact that I’m nearly becoming rusty with my Ruby on Rails skills (my last app was written with Rails v1.2.6).

The Rails Rumble is a wonderful opportunity to embrace constraints, get together with some talented people to learn from each other and have a good time. We’re not aiming to win any of the competition categories, but simply to have an application that has some semblance of completeness by the end of the contest. No all-nighters for us this time.

Our web app will be a tool to help you track your vehicle’s maintenance schedule, and send you notifications by email when you’re due for service. While planning how the application would work, it’s been interesting to think of all the possibilities of what it could do, but then having to let go of most of them in the interests of having something simple enough to bang out in a weekend.

When we’re finished I’ll write up a summary post about the experience. But I already know this is the kind of thing I will never have regrets about doing.

From June 17 – 19 I attended the Open Source Bridge Conference in Portland. This was a relatively small, all-volunteer run event that really impressed me. The event was created in response to O’Reilly moving a couple of high-profile conferences out of Portland this year, including OSCon and RailsConf.

Open Source Bridge (OSB) focused on the use and development of open source software in many contexts. I really liked that several of the talks were on the theme of using open source in government and business, including making a living from working with open source software. Portland Mayor Sam Adams gave a one of the keynote talks, and I sincerely believe he “gets it” or at the very least wants to get it, and recognizes Portland’s unique positioning as a center for open source software developers to live and work.

I’ve been to a number of conferences before, from tiny ad-hoc “unconferences” such as BarCamp to huge O’Reilly ones such as RailsConf. I have to say OSB was one of the best events I’ve ever been to, and definitely trumps all of the other ones in terms of value. They focused on hosting the conference at a quality venue (the Oregon Convention Center) and had an outstanding 24-hour hacker lounge on the 23rd floor of the downtown Hilton. But to lower costs, they didn’t spend oodles on things that don’t really matter at events, such as catered lunches.

I am deeply grateful for the work of OSB’s organizers and am absolutely certain I’ll be back next year. I attended interesting and relevant sessions, got to meet some great people, and did so without having to spend several hundred dollars.

Here’s a video from the hacker lounge taken on the first night of the conference:

I’ve spent the better part of this week doing battle with a pesky problem in Firefox v3. The bug report on Mozilla’s bug tracking system (along with a patch to fix it) can be found here if you’d like to read all the gory details.

The product I’m putting the finishing touches on at work is a touchscreen-based appliance that can, among other things, display video streams from IP cameras. The lowest common denominator for IP cameras it supports is the motion JPEG protocol, so early on in the project (many months ago) we did some testing and found that Firefox readily supports displaying these streams, and that we could also use a video player plugin for better system performance. Sounds like an easy feature to add, yes?

Nope! It turns out that the bug I referenced above means that once you display an MJPEG stream, it never stops running. If you browse away from the stream you still take a performance hit, and Firefox eats up the CPU and network bandwidth resources as if the stream was still being displayed. This became a critical problem on an embedded platform that needed to display up to four IP camera streams at the same time. Additionally, the camera streams are not the focus of the product (its primary purpose is to control multiroom audio systems).

So onto “Plan B” – the mplayer video plugin for Firefox. As a bonus, this plugin makes use of hardware video acceleration to display streams, resulting in significantly lower CPU utilization. Have we found a winner? No, again. The plugin did its job well, until you went to unload it from the page. This process turns out to take an indeterminate amount of time due to various complex interactions between the plugin and the independent mplayer process that also needs to be shut down. The delay would amount to several seconds regularly – unacceptable for the product’s requirements. Various aggressive methods of killing the plugin to avoid the delay only resulted in killing Firefox along with it. And through communication with one of the open source developers of the mplayer plugin, we confirmed that this was a inherent design problem that could not be overcome.

So what now? All I can say is we are very, very lucky that the Mozilla team fixed this bug. Although it is not yet released into the mainline Firefox, I was able to apply the patch cleanly to the sources and compile a custom Firefox that meets our needs.

It’s been a long week, but in the end I am still grateful that we’re using open source software as our technology foundation. It may have its problems, but if you put some effort into searching through the infrastructure that’s publicly available on the web (i.e, bug tracking sites and mailing lists) you can usually understand and find the solutions to your problems.

NetBeans 6.0 final (my Ruby/Rails/C/C++ IDE of choice) was released a couple of days ago. Pat Eyler posted on his blog an interview with Tor Norbye, which outlines many of the spiffy features of NetBeans 6 and some of the challenges in writing IDE tools for a dynamic language such as Ruby.

Because it’s an enjoyable language to program in. Thank you, Giles, for reminding us about the importance of this factor.