Ported this over the weekend, I think it’s in a state now where some people will be able to use it. Initial reports are that it has issues running on CF-based carts, I only have a SuperCard SD to test with so I haven’t been able to debug it on CF to see what’s going on.
Built against SaTa’s modified FAT libraries from REIN (SD users probably want this):
Built against chishm’s FAT libraries with just CF enabled:
Copy it to your media, then copy over the Genesis ROMs you want to play (it should be able to play ROMs with .BIN, .GEN, and .SMD extensions). There’s no sound, but since it uses the Cyclone 68k core which is optimized for ARM it runs well for the most part. Scaling is done in-software right now so the downscale isn’t as fast or good as it could be. There’s no double buffering yet so you might see tearing on some games. Y/B/A are A/B/C.
Screenshots:
Video:
There’s been some commotion about the KittenAuth CAPTCHA and how effective it is or isn’t. Last weekend, I decided to give the PCA-SIFT algorithm a whirl against it and see how it went. After having wget grab a sufficient number of images, I deleted all duplicates and put the manually verified cats in a folder and got keypoints for them. Now finding out what is and isn’t a cat is as simple as a Perl script:
$ time find . -iname '0.*' -exec ./findkitty.pl {} \;
Finding keypoints...
64 keypoints found.
Finding keypoints...
105 keypoints found.
./www.thepcspy.com/images/dynamic/kitty/2/0.390180844063955 is a cat
Finding keypoints...
124 keypoints found.
./www.thepcspy.com/images/dynamic/kitty/3/0.390180844063955 is a cat
Finding keypoints...
96 keypoints found.
./www.thepcspy.com/images/dynamic/kitty/4/0.390180844063955 is a cat
Finding keypoints...
209 keypoints found.
Finding keypoints...
118 keypoints found.
Finding keypoints...
209 keypoints found.
Finding keypoints...
173 keypoints found.
Finding keypoints...
122 keypoints found.
real 0m6.045s
user 0m5.173s
sys 0m0.319s`
I used PCA-SIFT because, while it’s slower than a simple file hash (which would defeat this in its current form), it can still accurately match images which have been through a variety of modifications (i.e. pretty much all of the modifications I have seen suggested elsewhere).
It would be pretty hard to use the idea for this captcha and have a sufficiently large enough database that it could defeat the method I’m using to get around it. An attacker could just have it cache all the unique images it sees and only have to have a human look at any given picture once to classify it, and if you use a large source of known images that you wouldn’t have to classify (such as GIS or kittenwar), it’s reasonable to believe that an attacker could use it as well.
I’ve whipped up a short Perl script, available here, that converts a Netscape-style cookies file into the ELinks cookies format. This is useful for sites which have an image-based login captcha, so you can use Firefox to log in and then copy your cookies and have them in ELinks. Example usage:
./ns2elcookies.pl > ~/.elinks/cookies
By default, it does a find on ~/.mozilla/ for the first cookies.txt file it sees. You can also specify a cookies file as the first argument if that isn’t what you want. It should be fairly easy to modify the script so that it instead outputs in another browser’s cookie format, w3m for example.
Due to some changes in libavformat, the sample code at
http://www.inb.uni-luebeck.de/~boehme/libavcodec_update.html no longer
compiles correctly.
avcodec_sample.0.4.9.cpp: In function ‘int main(int, char**)’:
avcodec_sample.0.4.9.cpp:83: error: request for member ‘codec_type’ in
‘pFormatCtx->AVFormatContext::streams[i]->AVStream::codec’,
which is of non-class type ‘AVCodecContext*’
avcodec_sample.0.4.9.cpp:92: error: cannot convert ‘AVCodecContext**’
to ‘AVCodecContext*’ in assignment
avcodec_sample.0.4.9.cpp:105: error: ‘struct AVCodecContext’ has
no member named ‘frame_rate’
avcodec_sample.0.4.9.cpp:105: error: ‘struct AVCodecContext’ has
no member named ‘frame_rate_base’
avcodec_sample.0.4.9.cpp:106: error: ‘struct AVCodecContext’ has
no member named ‘frame_rate_base’
I’ve created a patch as well as a fixed example for the code. I’m not entirely sure about commenting out the frame rate correction hack, but those frame rate variables are no longer members of the AVCodecContext struct.
Also, for compiling under Debian, the recommended usage is not to change the include directives, but to use:
g++ `ffmpeg-config --cflags` -o filename filename.cpp
`ffmpeg-config --libs avformat --libs avcodec`
I have updated and modified Nikita Smirnov’s jabberd2 LDAP rosters/vCards patch for my own use, and thought some other people might be interested in it as well. This patch only includes the sm rosters and vCards modifications, and not the c2s ldapfull authentication method. It has been updated to patch cleanly with jabberd2-2.0s3. I have modified the roster publication for people using normal LDAP authentication, so the “@servername” text is appended automatically to the supplied LDAP uid before storing it in the roster (so you don’t have to maintain seperate uid’s and jid’s). I have also modified the sm.xml.dist.in example to be a little more clear. If you use a Debian-style distribution, you should be able to “apt-get source jabberd2″, put this in debian/patches, and run “debian/rules binary” to get a modified package.
All of this information is now being pulled from our LDAP server, which is pretty snazzy. You can get the patch here. So now, I have LDAP working for:
- user logins to Linux
- Samba PDC functionality (shares the same home directory etc. as their Linux account)
- company-wide addressbook (works in mail clients, as well as the copier/scanner machines)
- logins to intranet web apps (including the very cool Trac)
- Jabber authentication, rosters, and vCards
- postfix and Courier IMAP for mail handling
- pureftpd authentication
All in all, kind of a hassle to get going, but definitely worth it. There should be a free Linux distro that assumes you want to do this kind of stuff by default. Novell OES may come close, but it’s non-free in both the monetary sense and in that it relies on the closed-source eDirectory.
So there’s this really annoying bug that a lot of GNOME users have been experiencing, including myself. The first issue is that the default GNOME layout binds the “Windows” key to Super_L/Super_R, which prevents you from using it as a modifier key. This is a relatively easy fix; run gnome-keyboard-properties and change “Layout Options->Alt\Win Behavior” to “Meta is mapped to the Win-keys” (or just about anything other than “Default”, apparently). Now, you can open up gnome-keybinding-properties and use away. But wait! It mysteriously only works for some of the actions. This is because essentially two keybinding backends are used, gnome-settings-daemon and metacity. Turns out, gnome-settings-daemon ignores Mod4 (which is what the Windows key gets mapped to as a Meta). Thankfully, it’s an easy fix! Grab my patch or if you’re running Ubuntu/Debian, you can install these deb’s which already have the patch applied and restart GNOME (these have only been tested on Ubuntu Hoary). Now, rejoice that you can finally have Windows+L mapped to “lock screen”!
After struggling with this lovely error (”XML Parsing Error: not well-formed” while pointing to a nonexistant location in my code) for a while hacking around on Wereboy, I became a little frustrated. So I created a clean profile and added the extension, where it worked fine. Turns out that profiledir/XUL.mfasl will apparently keep around uninstalled plugin chrome then later confuse itself, resulting in this sort of breakage. You have to delete/move it then relaunch Firefox to force a rebuild.
This plugin lets you post Tomboy notes to a weblog through the magic of XML-RPC. Attached is the source (goes in tomboy-[ver]/Tomboy/Plugins/) and a diff/patch against the cvs tomboy-[ver]/Tomboy/Plugins/Makefile.am.
Notes:
- needs XmlRpcCS. Mono 1.1.x users, check my guide for installing it.
- there’s no pref’s dialog, you need gnome-blog, it currently reads your gnome-blog settings from GConf
- currently only supports the MetaWeblog API (MovableType, etc.)
- does not support post editing
- currently just uploads whatever the text value of the note is. If your blog supports setting a default formatting style (like Markdown), just use that in your note and it should show up properly.
Some ideas for enhancement:
- keep track of postID’s in an extra XML field (like width and height are now). This would allow you to upload a post, then edit/update it within Tomboy.
- move pref’s to Tomboy’s preferences dialog and GConf settings?
- let you sync your notes with your weblog. This would update your blog with local Tomboy changes, as well as pull down other posts not made from Tomboy into Tomboy.
- maybe a different icon?
Enjoy, feel free to enhance/update/improve/etc.
And yes, this post was made with it. 
I was trying to work on some XML-RPC craziness under Mono, and came across XmlRpcCS and a nice tutorial. Problem is, since I’m running Mono 1.1.4, I could reference the built XmlRpcCS.dll assembly at compile-time with no problems, but the resulting program would die with:
WARNING **: Could not find assembly XmlRpcCS, references from
~/source/monoblog/monoblog.exe (assemblyref_index=3)
This is because with Mono 1.1.x, it seems you must register signed assemblies with gacutil. In order to do this with XmlRpcCS, you need to do the following:
- Download the XmlRpcCS source file and unzip it.
cd to the XmlRpcCS directory and run “sn -k XmlRpcCS.snk” to generate your keyfile.- Edit the
makefile and change the CSFLAGS line to “CSFLAGS=-define:__MONO__ -delaysign-“
Edit src/nwc/xmlrpc/AssemblyInfo.cs and add the following lines:
[assembly: AssemblyDelaySign(false)]
[assembly: AssemblyKeyFile("XmlRpcCS.snk")]
Run make
- Run “
sudo gacutil -i XmlRpcCS.dll -package XmlRpcCS“
Now when you need to compile against XmlRpcCS, just add “-r /usr/lib/mono/XmlRpcCS/XmlRpcCS.dll“, and it should work fine.
Britt ran into me today while I was hacking around on a toy program of mine. Basically, I’d gotten fed up with having 5000 Firefox tabs open at once, with no proper way to search through my history or bookmarks, so I decided there needed to be a better way. I started playing with Gecko# and got a bit caught up in getting something half-usable out. Since the last thing the world needs is another web browser, I’ll probably just polish it off some more and put up the source to help out (or possibly confuse!) anyone else who wants to do some Gecko# hacking beyond a 5 minute browser. I did finally discover the old Mac app I was doubtlessly inspired by, TrailBlazer.
Anyway, onto the main reason for abandoning it, my conversation with Britt made me realize that even beyond the silliness of trying to create another browser, I was also reinventing the wheel in numerous other ways. It would probably be much easier to hack the functionality I’m looking for onto Beagle. Guess I’ll need to set up an inotify-enabled kernel.
Speaking of which, I need to do quite a bit of kernel hacking in less than a month anyway, with 3-4 large kernel modification projects ahead of me. Thankfully, due to my inability to read a syllabus, I finished all my projects for another course two weeks ahead of time, so I won’t have that looming over my head.
