It’s unfortunate that you feel the need to adopt the nasty tone that’s characteristic of others at PK, Robb. These issues of network management and Innovative New Applications are often difficult, and there’s no need to attack people for giving technical solutions that can’t be packaged as easily-digestible sound bites. Just because you’re on the PK payroll doesn’t mean you have to lose your pleasant, aw-shucks-I’m-just-a-barbershop-singer demeanor. You could teach Art and Gigi quite a bit about public image. This would be especially useful for them the next time they want to complain about text message blocking on the Internet, for example. Or about something that actually exists. But I digress.

George Ou, like you, doesn’t have a deep background in protocol design or network architecture. But he does have a great deal of hands-on, practical experience and the ability to learn new concepts very quickly. I rate him very highly in native intelligence and diligence, and find no fault with him asking people with more experience to explain things to him. That’s what smart people do.

The problem the ISPs are dealing with today was caused by the acceptance and popularity of an Innovative New Application, peer-to-peer file sharing. It creates a different mix of traffic than previous applications, and managing this traffic on top of the existing traffic created by more traditional apps, such as VoIP and the Web, has given rise to a number of experimental approaches.

The IETF recognizes that the Internet toolkit is inadequate for managing this Innovative New Application, and has created a study group to explore a standard approach. So it’s a fallacy to assert that existing, standard mechanisms are sufficient. The IETF doesn’t see it that way, and they’re the ones who should know.

While we wait for the IETF to develop its standard solution, we’re in a gray area where the ISPs aren’t precisely sure what they can and can’t do, and what will and won’t work, and what’s cost-effective and what isn’t. Consumers who don’t use Innovative New Applications don’t necessarily want to be stuck with the bill for network upgrades they don’t need, and who can blame them? Granny Sue and Uncle Earl never signed up to pay for you to publish the movies you share with the World Wide Internet, and we have to respect their rights.

I personally believe we’re going to solve the P2P traffic problem (much more upload than we’ve ever seen before, by a factor of thousands) through the IETF’s efforts. But in the meantime, it’s reasonable for an ISP to solve the problem by employing a two-stage system:

1. Allocate bandwidth equally across user accounts, according to instantaneous load; and then:
2. Prioritize traffic within each account by native requirements, using DPI or any other classification scheme that’s efficient.

Now that’s just my personal theory, and it’s not necessarily the best way for every ISP to approach the problem, but I offer it here as an example of a provisional system that can be put in place while we’re waiting for the good folks at the IETF to recommend a standard solution.

The scenario reminds me of the transition from WEP to AES in wireless LANs. It took the IEEE 802.11 a long time to figure out the ins and outs of AES encryption, the Wi-Fi Alliance jumped into the breach and gave us the provisional TKIP solution. We used that as WPA until AES was standardized, and then we moved to WPA2.

These things happen, and it would be unfortunate for the FCC to jump up and down and get its face all red because the Innovative New Application went on-line before the Innovative New Application’s Management Solution.

So be patient, and don’t advise the regulator to do anything stupid, as they’re likely to take you up on it, and then your barbershop singing will suffer.

And nobody wants that.

His response is simply more vitriol. This is all very sad.

This Monty Python sketch was the inspiration for the Hipster Olympics.

The Hipster Olympics are quite ironic.

H/T the New Megan McArdle blog.

Fedora 7 is the latest release of Linux in the Red Hat line. It includes the 2.6.21 kernel, which has kernel-resident KVM virtual machine support, Firefox 2, and the latest versions of the Gnu toolchain and all that. It’s the first Linux that’s seemed to me like a credible alternative to Windows for general-purpose desktop use, but it’s got some problems. My first shot at installation was on an Asrock ConRoe1333-DVI/H R2.0 motherboard, which uses an Intel chipset and has on-board video with DVI, in the form of the Intel Graphics Media Accelerator 950. Intel is alleged to be super-supportive of open source, so I expected this configuration to work even though it breaks the one-year rule (never install Linux on hardware less than one year old.) Installation was smooth, but when the system booted I got a black screen.

So no problem, I put Windows on that machine and moved on to an MSI K9AGM2-FIH motherboard. Like the Asrock, it has on-board video and support for a dual-core CPU, but it uses the AMD/ATI Radeon X1250 graphics controller. Both motherboards support HDCP so they’ll be usable with the new Blu-Ray drive from Pioneer that’s supposed to be here any day now. Installation on the MSI was easy, and unlike the Intel motherboard, it actually ran. The system doesn’t know what to do with the Radeon yet, but that’s another story.

As soon as you have an operating system, the next thing you want to do is get to the web, and that’s where things get interesting. Like most people, I use Adobe Acrobat and the Adobe Flash player, but neither of them is up to snuff for Linux.

Acrobat has a bug that makes it go hard loop on any computer with the latest version of GTK, one of the graphics libraries it uses. It’s a simple bug to fix, requiring a one-character change in the /usr/bin/acroread script, but Adobe hasn’t figured out how to do it and in fact has re-released the same bug several times. It’s simply a matter of changing this line:

echo $mfile| sed 's/libgtk-x11-\([0-9]*\).0.so.0.\([0-9]\)00.
\([0-9]*\)\|\(.*\)/\1\2\3/g'

to this line:

echo $mfile| sed 's/libgtk-x11-\([0-9]*\).0.so.0.\([0-9]*\)00.
\([0-9]*\)\|\(.*\)/\1\2\3/g'

Can you see the difference? right after the middle of the line there’s an extra ‘*’ after one of the [0-9]‘s. That’s not too hard, is it? Of course not, any moron can fix that.

Now the situation with the Flash player is a little more interesting. These new AMD and Intel processors have 64-bit instructions, so Linux has both 32-bit versions and 64-bit versions. For most applications, supporting 64-bit Linux is simply a re-compile with the 64-bit flag turned on. This is too much for Adobe to handle, so they only offer Flash in a 32-bit version. Since this is the tool that plays YouTube, it seems like a nice thing to have. But what happens if you install the Flash plugin for Firefox on 64-bit Linux is interesting: Firefox doesn’t see it, and you’re nagged to install it again, and again, until your patience runs out.

It turns out the issue here is that Fedora 7 includes both the 32-bit and the 64-bit versions of Firefox, in different locations. The basic /usr/bin/firefox is a script, and it runs code out of /usr/lib or /usr/lib64 as appropriate. The Flash plugin goes into the 32-bit code library, but as you’re running the 64-bit code you never see it. So the solution is to erase Firefox from your system:

Then your Flash install will work (after you repeat it), but now you’ve got yet another problem, as all the plugins that have real 64-bit versions aren’t going to run, so you have to play more games to get things like Java running under a 32-bit plugin. …install a nice little wrapper that allows you to run 32-bit plugins under 64-bit binaries.

More on that later, but for now Adobe is officially inept at Linux.