Daily Archives: 4/16/2005

Brainwagon Radio: Opening Day for the Athletics

Opening Day PodcastIt’s been a couple of days since opening night for the Athletics, and it’s taken me a couple of days to stitch together the bits of audio I recorded into an Opening Day Podcast. While the A’s were smacked around, I did have a great time and you might find some of the sounds of the game to be interesting. Enjoy!

I have a bit more audio that I recorded that I’ll link here in a day or so. I decided not to lengthen the podcast for those who don’t find it interesting. Despite the fact that it is recorded with my Dell Axim x50v and its internal microphone, I don’t think it turned out half bad.

My Wife is Quite the Shopper…

I thought I got a good deal on my wireless notebook, but I just found out that she managed to get a wireless notebook for only $1.69. Yeah, $1.69! Isn’t that freakin’ amazing? Check it out, I’m not sure if it is 802.11b compliant, I haven’t gotten it to work with my wireless router yet, but you can’t beat the price.

‘Cool it, Linus’ – Bruce Perens

Over on the Register, there is an article on the ongoing row between Linus Torvalds, Andrew Tridgell, author of the Samba software you’ll find as part of many operating system distributions, and Larry McVoy, CEO of Bitkeeper software, the proprietary revision control software which is used to help maintain order in the Linux kernel source tree.

It’s turning into quite a tiff, and Bruce Perens has weighed in and asking for cooler heads to prevail.

The problem is as far as I can tell, entirely Linus’ fault. He made what must be viewed as an incredibly short sighted decision: to use a propietary product as a key element in open source development. It’s a bad idea, for a number of reasons.

First of all, proprietary software is managed by commercial entities. They are allowed to sign NDAs, they can purchase and sublicense proprietary technology and they go out of business. When such a company goes out of business, there is no guarantee that the software which you are using will continue to be available. Putting the long term viability of your open source project at risk in this way is wreckless.

Secondly, if your goal is to promote open source software promote open source software by sleeping in the bed you’ve made. If the open source alternatives aren’t as good as the proprietary ones, then through your weight behind new or existing projects to improve by using them. Linus wrote:

“So I think open source tends to become technically better over time (but it does take time), but I don’t think it’s a moral imperative.” he writes.

The real issue is of course not whether it is a moral imperative, but rather do most people who would work on such a project view it as better to use and improve open source tools which can be made available to all, or to simply use the best tool available, despite it being against the principles which supposedly you began writing open source software to espouse?

Lastly, Linus simply didn’t take the feelings of a large subset of kernel developers into account. For projects which rely on volunteer labor, that’s just dumb.

I’ve used cvs for years, and spearheaded its use within a couple of different organizations. It’s got its flaws, but it is open, and available, and I’m willing to wait until other open source code revision systems have features which make it profitable for me to change. In my career I’ve used SCCS, RCS, CVS, Perforce and subversion, and will probably use some more before it’s all over. For my own personal work, work that I care about, I’ll choose open alternatives every single time.

Hacking to save lives…

From the MakeZine Blog, a report of an attempt to aid American troops in Iraq. Roadside bombs are jury rigged from FRS radios, and set to explode when particular code sequences are sent over the FRS. A 7 watt amplifier and a little Basic Stamp will send all potential detonating codes, and hopefully trigger the explosive device before troops can get in the way. MAKE: Blog: Hacking for GIs