Results tagged “open-source” from karlo.org

Last night I was able to get a newly purchased Buffalo WHR-G300N wifi router ($35 from Newegg.com) to accept a firmware install DD-WRT, the Linux-based open source firmware package for wireless routers.

Why even attempt this perversity? It gives you a very cheap wifi router with the kinds of interface features you might only see built into either commercial or premium units.

Quick notes:

• This wasn’t really what I’d consider a straightforward or user-friendly process. I definitely thought at one point that I’d bricked the unit. Eventually I got it working, but I’m not sure I could say with 100% certainty I could do it again without bricking a unit.
• Before you start, read the DD-WRT wiki page for this router, and the threads linked to it. (I did not.) It will save you some tears, although it won’t make it completely easy.
• All I can say about setup is, keep trying. I finally succeeded by pushing the firmware from my Mac using tftp during the router’s boot sequence, which takes advantage of the device’s built-in recovery method. Once the “put” had finished, it took a while, but the wifi light went on and things were good from there.
• The WHR-G300N only does 2.4Ghz, not 5Ghz. Given that it costs about $35, half the price of a retail 802.11g router, it’s not a huge disappointment.
• The DD-WRT interface is leaps and bounds better than Buffalo’s original software. They should just bite the bullet and sell these routers with DD-WRT pre-installed.
• I’ve had the best results by setting wireless security to WPA2 and TKIP+AES
• Despite some early problems, my iPhone now connects to the router just fine

To give a few examples, the DD-WRT software has built-in support for about a half-dozen dynamic DNS services, QoS management, and you can SSH directly into it if you want a command line. The interface is much more useful and informative than Buffalo’s own firmware, or most routers.

Network performance has generally been great. My MacBook backs up every hour to a USB drive connected to my Mac Mini Media Center, and ever since I upgraded from my old G router to this one, that process is fast and reliable.

It certainly doesn’t give my favorite router - the Apple Airport with its great management interface, Time Machine support and gigabit ethernet - a run for the money. But it’s also about 1/4th the price.

So, it’s a little hairy - but if you can get past the setup trials, it’s a good deal.

"We all realized that working together for a common good would be much more productive than duplicating things on each side of the fence. Merb and Rails already share so much in terms of design and sensibility that joining forces seemed like the obvious way to go. All we needed was to sit down for a chat and hash it out, so we did just that."

David Heinemeier Hansson has this evening posted a remarkable missive about the merging of Rails and Merb, two independent but parallel frameworks within the Ruby community.

While the merger itself is huge news for anyone who works with Ruby, Rails or Merb, the letter and the merger are also of broader interest to anyone who follows online communities. In the face of a broad trend of fragmentation, division, and overall entropy within special-interest online communities, the friendly (and, potentially, massively productive) merger of two relatively healthy collaborative programs is worthy of note.

When corporations merge, one of the reasons they always cite is the cost savings from eliminating redundant infrastructure and employees ("synergies") despite the fact that they are seldom realized. Conversely, for volunteer or open-source efforts, this effect is too often overlooked entirely - creating situations like what used to exist between Rails and Merb, where two essentially similar communities were building very similar products in parallel, for a similar user base, and in the process duplicating a lot of effort that in reality was of little consequence to their respective constituencies. By agreeing to "unbranch" these two technology platforms (I use quotes because they did not, in fact, arise from the same original code base), these teams have the opportunity to spend a greater portion of their time on work that really matters rather to their user base. And that is a good think (TM) for everyone.

There's another parallel this brings to mind: real world churches have traditionally fractured, split, grown or withered, but almost never merged. It's not easy, but there are good reasons to do it if you're able to be flexible. (Unfortunately, churches don't generally have "flexibilty" high on their list of traits.) In the process, a lot of good community work and effort goes to waste, because either a church keeps growing, or it gradually withers away and disappears. Open-source projects have traditionally suffered similar fates. Hopefully, intelligent, thoughtful mergings of communities, not just technologies, like the Rails/Merb merge, will be the future trend.

Updated: David has written more about the situation, talking about it at a more conceptual level.