If you want to get myth2ipod working on Ubuntu (assuming you have both MythTV and Ubuntu installed) there aren’t any instructions to my knowledge. I found the currently posted set of instructions to be outdated (last update 3/5/06). The following, updated instructions are actually much simpler (everything is in apt).

I did as follows (Myth .20, Ubuntu 7.04):

1. Get the appropriate version of ffmpeg (with xvid support). To do that, add this line to your /etc/apt/sources.list file:
   deb http://packages.medibuntu.org/ feisty free non-free
   and then run
   wget -q http://packages.medibuntu.org/medibuntu-key.gpg -O- | sudo apt-key add - && sudo apt-get update
   Then install your brand new version of ffmpeg:
   sudo apt-get install ffmpeg
   (found that tip linked from here)
2. To test what you did in step 1, run ffmpeg -version and make sure you see ‘enable-xvid’ and ‘enable-faac’ in the output.
3. Install the codec library, which is required to make sure you can encode aac audio.
   sudo apt-get install libavcodec0d
   To test that you can, run ffmpeg -formats and make sure you see DEA aac listed under “Codecs”.
4. Install mp4box, which is available in apt under ‘gpac’ sudo apt-get install gpac
5. Grab nuvexport:
   cd /tmp
   wget http://forevermore.net/files/nuvexport-latest.tar.bz2
   tar -xjvf nuvexport-latest.tar.bz2
   sudo mv nuvexport-0.4 /usr/local/share/nuvexport

6. Copy down the scripts and put them in the right places:
cd /tmp
wget http://myth2ipod.com/myth2ipod.txt
wget http://myth2ipod.com/iPod.pm
sudo mv myth2ipod.txt /usr/local/bin/myth2ipod
sudo chmod +x /usr/local/bin/myth2ipod
sudo mv iPod.pm /usr/local/share/nuvexport/export/ffmpeg/iPod.pm
sudo ln -s /usr/local/share/nuvexport/nuvexport /usr/local/bin/nuvexport

7. At this point you can follow the rest of the instructions at the site for editing /usr/local/bin/myth2ipod , etc. The rest of it is not distribution-specific. The slight change I had to make was the path to MP4Box which is hard-coded in the script to point to /usr/local/bin but on Ubuntu it gets put into /usr/bin.

A few of us at work were trying to figure out why Apple released Safari for Windows yesterday. We came up with a number of reasons against it:

• It doesn’t (directly) make them any money.
• It does cost them money. Aside from the up front costs of producing it, they’ll now enter the (endless) cycle of patching holes that allow people to exploit Windows.
• Firefox is the most popular competitor to Internet Explorer, and it seems to have been stuck at the 15% penetration mark for some time now.
• If you think there’s room for a browser that touts itself as being “really fast” but has lackluster support for 3rd party extensions, maybe you should have taken a look at Opera‘s success on the desktop. (below 1%)

But, of course, Apple also announced the the “API” for building iPhone applications will be Safari. So, that changed the game a little bit. Some reasons for putting Safari on Windows:

• Legitimize the iPhone’s development platform. If it works in Safari, it doesn’t just work on the Mac, it also works on Windows, and on the iPhone.
• Allow iPhone developers to develop on Windows. It’s a theory, although if that’s all they wanted, they wouldn’t need to bundle Safari with iTunes – they could just offer it as a download from their developer site.
• Foster “the switch.” If I’m on a Windows PC and I use iTunes for my music, and Safari to surf the web and use a variety of web apps, maybe next time I buy a computer I’ll just get a Mac which has those familiar things on it.
• Give them an avenue for pushing web standards. If they’re looking to extend web standards to provide for things like, perhaps, special mobile-based extensions, this again gives them a more legitimate/widespread platform for doing so.

I’m not thrilled, being a web developer, at having yet another browser-OS combination to have to test on. I also don’t think that it will be a successful/popular browser on Windows. I hardly even use it on my Mac (I prefer Firefox, in large part due to extensions). But, I’m interested to see what happens with it. Anyone else have some good theories?

I’m a bit concerned at the fact that the Rails community is relying more heavily on plugins to deliver functionality than building that functionality into Rails. It’s a good idea on paper, but in practice you’ll find that it’s not uncommon for two plugins to stomp on each other. The asset_packager and distributed_assets plugins both override the compute_public_path method in Rails, and step on each other. There’s a similar story with the conditional_cache plugin and the caching-plugin.

Fortunately for me, in all of these cases, Rails core decided the features that these plugins provide are worth including in core and some form of them will be in Rails 2.0. I can only imagine that the proliferation of plugins is going to bring up this problem again and again, however. Because Ruby is a dynamic language, you practically get a plugin architecture for free. The problem is that it’s totally unstructured, and people can clobber one another’s methods at will.