I’ve snowboarded for about 8 hours so far (well, 8 hours in the past 7 years). I would like to share some thoughts I’ve had.

Tying a person’s feet to a board and throwing them down a hill would be a good form a torture.

You can practice getting on a chairlift by having someone tie your feet together and push a chair behind you.

You can practice getting off a lift by having someone tie your feet together throw you off a roof.

Snowboarders’ paradox: you cannot slow down unless you are in control, but you cannot be in control unless you slow down.

Corollary to the snowboarders’ paradox: Sure, you can slow down by falling, but once you get up, you will be out of control.

You will probably look like a dick as you run into people and cut people off due to your lack of experience.

Get off the practice hill and move to the easy hills as soon as you can.

Good luck turning to your toe side.

A few days ago, I wrote my third ebuild for Gentoo. Actually, wrote isn’t the right word. In two cases, I revised older ebuilds and submitted them. I wrote the other ebuild myself.

The thing that upsets me about the whole process (from raising a bug to having the ebuild in the Portage tree) is how slow it is. I submitted my first ebuild in mid-November and it’s still waiting for a maintainer.

Here’s a summary in table form:

LinCity was just submitted, so I can understand why nothing has happened with it yet. But, Midori is one of the few webkit browsers (if not the only) on Gentoo.

Nevertheless, I’m glad it’s very easy to write ebuilds. Now, if I see a program that I want to use that’s not in Portage, I’m not afraid to attempt my own ebuild.

Do you see that?

It’s something I haven’t seen since I switched from Ubuntu to Gentoo about a year ago. It’s a working wi-fi LED.

I was greeted with this pleasant little surprise after upgrading to the 2.6.26-r4 Gentoo kernel last night. Unfortunately, the excitement was mitigated about an hour later when I knocked over (and broke) my new external hard drive.

And today I got a weird error when trying to build the 2.6.27-r7 kernel. UPDATE: problem solved … check out the awesome solution.

I have this long−standing battle with content types of XHTML files.

You see, the correct content type for an XHTML page is application/xhtml+xml, meaning the page at hand will be rendered according the the stricter (than SGML) rules of XML. Ok, so just set the content type to application/xhtml+xml, right?

WRONG!

Internet Explorer users won’t be able to view your website. Instead, they will be prompted to download your home page. This is the future (it should be the present) of the internet and IE 7 (and IE 8 Beta 2) doesn’t even support it. The only type IE supports is text/html, which leaves web pages as tag soup. IE offers nothing that let’s your website be its XML self.

So the solution is to use something like the code below that changes the content type of your page dynamically (depending on the browser reading the page) so that compliant browsers like Firefox and Opera get the XML version of your site while IE busts out the rock and chisel.

<?php
$type = "text/html";
if (isset($_SERVER["HTTP_ACCEPT"])) {
	if (stristr($_SERVER["HTTP_ACCEPT"], "application/xhtml+xml"))
		$type = "application/xhtml+xml";
	else if (stristr($_SERVER["HTTP_ACCEPT"], "application/xml"))
		$type = "application/xml";
	else if (stristr($_SERVER["HTTP_ACCEPT"], "text/xml"))
		$type = "text/xml"; 
}
?>
…
<meta http-equiv="Content-Type" content="<?php echo $type; ?>; charset=UTF-8"/>

But the story doesn’t end here.

Good luck using the Google AJAX API or reCAPTCHA on your website. Many developers of web apps don’t worry about being compliant with the web standards that Internet Explorer does not support. The Javascript code in their apps contains things like document.write(), which, for reasons I don’t understand, kills scripts when used on application/xhtml+xml pages (and apparently the createElement function et al don’t solve anything, although there is a createElementNS function that offers some hope).

In conclusion, the internet is doomed.

Less than a month ago, Adobe finally released a 64-bit flash player for Linux.

On Gentoo, uninstall the 32-bit plugin—see nspluginwrapper -h—and optionally unmerge nspluginwrapper, add the ~amd64 keyword for net-www/netscape-flash, and emerge netscape-flash. On other distros, unpack the file, which yields only a shared object file. Just move it to the folder for browser plugins. Mozilla recommends /usr/lib64/browser-plugins, but Gentoo users should stick the file in /usr/lib64/nsbrowser/plugins (after uninstalling the 32-bit plugin—see nspluginwrapper -h—and optionally unmerging nspluginwrapper and netscape-flash).

Firefox and Epiphany will find the plugin automatically (see about:plugins). Opera users need to remember to select the plugin by editing the file assocations in Tools > Preferences > Advanced > Downloads.

One user on the Gentoo forums mentioned needing to emerge libflashsupport for sound, but I haven’t needed it. You should also keep in mind that this is alpha software.