Programming

Just the other day, I was contacted by Mohammad Ebrahim Mohammadi Panah who setup a wiki and has been attempting to document the Paltalk protocol. Upon his request, I contributed the gaim-pt source code for use in his documentation efforts.

You can find the gaim-pt related info (including the source code): here.

I saw a card trick on YouTube amongst my late night YouTube surfing, and thought to take a moment to give an explanation as to how it works. It's not an illusion of any sort, no slight of hand is involved. It's simple mathematics.

The trick relies on one thing: The cards for each suit are ordered, thus the n+13 th card in the deck is the card n of the next suit.

Cutting the deck doesn't change the order of the cards. If I have an array of ( 1,2,3,4,5,6,7,8 ) and I 'cut' the array at 4, my array is ( 5,6,7,8,1,2,3,4 ) thus the elements are still ordered. Flipping the deck over only affects the order in which the suits present. It also does not matter that the cards are ordered king-to-ace, ace-to-king, or 10-to-ace-jack-to-king, etc. as long as they are in the same order for each suit.

I wrote a perl script to illustrate this, exactly as the feller does it in the video. I posted a video response on YouTube.

Today, I was looking at a couple of PHP benchmarks (the one here for example), and they compared OOP benchmarks to Procedural benchmarks for the most part. I decided to write my own set of benchmarks using four of the most well-known web development languages that were ready-at-hand: PHP, Python, Perl, and Ruby. My benchmark also tests OOP vs. Procedural on a few terms: Execution speed and Raw lines of code written. I compare a visual estimate of memory usage between all four languages as well.

Now, one cannot draw very many conclusions from my benchmarks here, because the programs used don't really do anything useful, nor do they simulate "real-world" conditions, or practical use-cases. Remember, we learn multiple programming languages, not because of fads, but because it expands our own knowledge, and because some languages are better than others for some things; and it's helpful to be able to choose the right tool for the job.

Keep in mind the golden rule of benchmarking: All benchmarks are flawed benchmarks.

Today, I'm releasing PSX-GS -- a plugin for epsxe and other PSEmu-compatible emulators on Linux to allow the use of Game Shark / Pro Action Replay codes. Winblows users have had this functionality long enough!

PSX-GS is licensed under the GNU General Public License (version 2) (or later), and has been tested with epsxe 1.6.0. You'll need a fairly recent GTK 2 build in order for the UI portion to work properly. Note that codes with correct formatting and improper addresses may crash the emulator. Be sure to read the README.

You can download it here: Source Code, 32-bit x86 Binary

Here's a brief walk-through of how to use it. You can watch the YouTube video I made about this plugin here.

Recently I wrote a syntax file for TI-Basic and Extended Basic for Vim. It can be downloaded here. Click on the thumbnail above to see a screenshot of the syntax highlighting in action.

The Problem

As we all know, the HTTP standard defines a multipart/x-mixed-replace MIME type, which is supported in all Mozilla-based browsers, but not in IE.

This mime-type allows a content generator to dynamically replace the current content with different content. Each part of the stream can have its own MIME type, so you could use this feature to stream images, HTML pages, or anything else supported by the browser. With the need to generate such content, I set about to solve this task, for which there seems to be no solution.

My requirements to fix this are as follows:

1. Has to be simple yet elegant
2. Has to support both Mozilla-based browsers and IE
3. Has to practically duplicate the effect of using x-mixed-replace.

The Solution

First, we have to flush the content regularly. In PHP, we use flush(), and in perl setting the auto-flush flag is sufficient ($| = 1;).

Second, we need to instruct the browser not to cache content on the page, as it would be pointless, and could possibly interfere. We do that by setting the Cache-Control HTTP header to no-cache.

Third, your script should do whatever it needs to do, but send updates back to the client within the Keep-Alive interval, even if it just sends a carriage return.

Fourth, Your script completes, and sends one final update to the client to change the content.

The fourth step really is the key to it all, so I'll elaborate in detail:

Mozilla-based browsers (e.g. Firefox, Safari) and IE allow for the document.body.innerHTML property to be changed (naturally). Both also will allow you to send more than one body element, and will execute the onload handler upon parsing that element. Note, however, that it will not allow you to do:



So naturally, you can get around this by:



In most cases, this will work just fine. If you want to say, change the title, or modify the head, you won't be able to do anything like:



OR



Niether update as expected in Firefox, and neither will work in IE (because the first two nodes(html and head) are read-only.)

You can see an working example of this here. With the source here.

Tonight, I completed testing of my latest patch for Dinovo support in bluez-utils.

For:
3.18
3.19

Changes:
1. Moved the dinovo_mediapad() call to make connecting the media pad essentially hassle-free.
2. Added an implicit --search to hidd's --server handling.
3. The patch no-longer necessitates calling automake after patching (however it is good practice.)

Notes:
1. Be sure to configure with --enable-hidd!
2. Be sure to restart dbus after installing.
3. Be sure to either compile in uinput support within the kernel, or 'modprobe uinput' before using.
4. You may need to tune your system's init scripts to call hidd. I noticed that the gentoo init scripts do not call or reference hidd at all.
5. I added an implicit --search when the --server switch to hidd is specified. Note that there is a search timeout - so unless the mediapad is connected before the timeout you'll have to manually run either hidd --search, or hidd --connect.
6. Make sure you have your Keyboard Shortcuts setup as in the screenshot!


Edit 9/26: Updated patch for 3.19.

This new patch moves the mediapad code from the old hidd to the bluetooth-input-service daemon.

If you're viewing this site in Internet Exploiter, good for you. You're one of Microsoft's horde of sheep. Blind to everything else around you, let alone the fact that IE isn't standards compliant (no matter how bad one may want to believe it.) You've been duped my friends.

Whilst at work, I made a layout for a client, using fixed-positioned divs. While it works flawlessly in Firefox- it's obviously broken in IE. And why is that? Because IE dosen't comply with CSS standards. Although it's rumored that IE 7 beta 2 and up are compliant, I can't help but doubt it, given the obvious laziness of Microsoft's IE developers, and their unwillingness to comply with standards that have been established for more than 5 years.

Granted I've spent something around 4 hours trying to find a workaround, scouring the net like a hawk in a forest, I've been unsuccessful thus far. Even if all the divs have a static width, height, and position (fixed or absolute) - IE still tacks on extra vertical space, and even with overflow-y: hidden; the page still dosen't render correctly (though overflow-y gets rid of the extra space.)

The real problem isn't that IE isn't compliant, but that roughly 90% of the computer users in the world use Microsoft's Windows OS, and most of that 90% use IE simply because it's bundled with the OS. Granted that a lot of Winblows users don't know about the existence of free, standards-compliant browsers such as Mozilla Firefox, ignorance is no excuse. As long as such a trend remains in affect, we web developers will continue to be slapped in the face by IE's mishandling of even the most basic things.

Granted that it's a known fact that over 60% of all Windows remote exploits are exploited through security holes in IE - most users of the Windows OS aren't security savvy, thus they don't read up on these things. That's the whole damn reason we have so many spam-sending zombies out on the net.

A good number of spyware, malware, and trojans install themselves via security holes in IE. Can you guess why?

The same reason as they do from Winblows filesharing programs, or watching Windows Media Video: It's a common, routine task; and because IE makes it a laughably easy vector of attack.

Above all, I abhor having to keep two separate codebases, one for IE, and one for the rest of the world. It's the explicit catering to IE that really infuriates me. Why the hell should I have to rewrite my work just for the Microsoft sheep out there? Seems kind of pointless to have standards when most of the world ignores them...

Fellow web developers, I urge you to cease support for the quirks in IE. Hopefully if enough people write purely standards-compliant work, Microsoft will be forced to finally bring IE into compliance - though I doubt we'll see that happen any time soon.

Web users - I urge you to download Firefox. It's 100% free, 100% standards compliant, and 100% free of IE's security holes.


I've been free of the chains of Microsoft bondage for nearly 10 years - and damn proud!



Edit: I fixed the problem today at work. A combination of z-ordering, absolute positioning vs. fixed, overflow: hidden, and a containing div fixed the problem.

I was recently involved (and disinvolved) with the online community of Second Life. As I started pouring over the code, I became disenchanted with the idea of Winblows and Mac users being the only ones who could watch in-game videos. So I dusted off my bottle of ass-whoop, and went to work at the code. The result can be seen in the two screenshots above.

See the code section for a source code patch against 1.14.0.0 / 1.14.0.1 (should also work with the latest versions - just need to be careful with modifying the SConstruct file. The only drawback is that it's not as fast as one would like. This can be worked around. FFMPEG is also under constant development, so with these promising results, it's only a matter of time, right? If I don't ever finish this, hopefully someone else will pick up the torch. Remember, It's up to you now, to ensure that we Linux users aren't simply ignored! As always, the download is in the Code section.

For christmas, I got a Logitech DiNovo Media Desktop Keyboard/Mouse/MediaPad set (~$200 USD) and promptly installed the Bluez tools and updated kernel drivers. The keyboard, mouse, and media pad, all work fine as standard HID devices (in USB mode), with the exception of the mediapad's LCD.

Whilst googling around, I came across Patrick's diNovo Media Desktop page. He's got a ton of useful info about the key mappings, and various configuration details that make things much more livable. I nearly tore my hair out with the initial setup and the transition into bluetooth mode. I wish I'd found his page right off.

One thing to note, is that he was told by Logitech:


I understand from your email that you want to know the specifications for managing the LCD display on the Medipad.
Unfortunately, the information you are requesting is proprietary in nature and therefore not publicly available.
I am sorry for the inconvenience caused...

Unfortunately, Logitech does have any plans on developing a closed-source library for Mediapad LCD/Bluetooth/Logitech
diNovo Desktop. I am sorry for the inconvenience caused.


So enraged was I, to see that they hadn't even the notion of Linux support, that I went into my dark chambers, and began to figure out what was really going on. After a few hours of clean-room reversing, I wrote a few test programs, and hacked away at the HID daemon in Bluez. Following the lead of the bluez developers, I implemented a driver for the mediapad in "fakehid" mode.

After all, someone had to Git-R-Done!

I invite anyone who may benefit from it to download my patch for bluez-utils 3.8 to implement the driver. One interesting thing about my implementation, is that the driver uses DBUS so that other programs can interact with the mediapad as well. There's also a small python script included with the patch that shows how to use it via DBUS.

Update: 2007-01-08 23:39:15 EST: Glen Rolle sent me some suggestions which I have implemented in this update. Thanks Glen! Note: This patch must be applied after the previous patch has been applied.

I've been Gitting-R-Done quite a bit lately. I've resumed working on K'Tan for some time now (using a new code base, completely from scratch.

In other news, I fixed a gaping security hole in a certain web forum software that even the manufacturer has yet to rectify. Specifically, it's called MiniHTTP Web Forum & Filesharing Server (4.x).

"Have I gone mad", you ask? "What am I doing fixing Winblows programs, etc.?"; Well, call it a musing to keep me occupied all night, or perhaps it's just simply me being benevolent to people who might use that software, however unfortunate that may be... Either way, I'd say it's a nice gesture on my part.

What's worse is that the vendor dosen't really seem to care about the vulnerability. No wonder Google dosen't turn up too many. Get the patch!