Posts Tagged ‘Hackery’

Awesome MediaWiki Bug

Thursday, July 23rd, 2009

Poor, lonely <font>. You were irritating to use, and so you were kicked out of the treehouse in favor of stylesheets by HTML 4.01. But cheer up <font>; you can still be extremely annoying! Just try a Wikipedia vanity search, with a few of your pedantic modifiers thrown in for good measure—let’s use <font face=cursive size=50>: wiki_bug_sm

Not only that, <font>, but your old and even more annoying buddy <table> is back in the game, too. And when you two team up,  there’s almost no limit to the amount of carnage you can create:

hi_jeff_sm

This works across browsers, though there are obvious differences in how they render the horribly mangled code these querys will produce. It’s the best lesson in input santization since since Little Bobby Tables.

If you’re good, you can theoretically purpetrate some serious mayhem with this bug—and considering how widely MediaWiki is used around the web, that could be a real problem.

In reality, though, the trickery is probably limited by the abilty of your dirty, dirty inputs to generate search results; without those, it looks like most of your code modifications get cancelled.

That having been said, I endorse using this exploit only for your own personal amusement, not serious destruction. You have been warned.

Cloud du jour

Thursday, June 4th, 2009

Robin Harris made a great post last week over on Storage Mojo outlining 5 zombie storage concepts that should die. His last item on the list really hit home:

Cloud. Yep, the word du jour is, because of its popularity, rapidly being drained of meaning. Public? Private? Compute? Storage? Cheap? Secure? Software? Infrastructure? What??? Sure, talk about cloud, but for goodness sake don’t put the word cloud in a product name. You’ll regret it within 2 years if you do. If you simply must then follow EMC’s oblique approach with Atmos.

I appreciate the need for a simple buzz word with a real-world analog to help people understand and get excited about new technology, but meaning is being drained from “cloud” at a break-neck pace. This blog is a great place monitor the insanity.

Why The TUAW Dell Mini 9 Road Test is a Fail

Tuesday, April 28th, 2009

Normally, I try to keep a strict “do not feed the trolls” policy, but I’m not above a good Internet fight now and again. And let me tell you, TUAW’s “Road Test” of an OS X hacked Dell Mini 9 is certainly bad enough to risk a few punches over.

“My first real work with the mini 9 began in November, when I decided to acclimate myself to its diminutive keyboard by using it during NaNoWriMo (National Novel Writing Month) to work on a novel.”

Fantastic test case for a computer designed for mobility and web access—a monumental, offline task involving hours of ass-in-chair typing. The reason people still fetishize the heavy, zero-connectivity Smith-Corona for this task is because it’s nearly perfect for it.

And yes, I have written a novel, so I would know.

“Sure, it worked for a little bit, and then began to irritate me when the gestures would fail. I decided to use a cheap micro-mouse instead, which meant that two of the USB ports were now filled — one with the cable for the mouse, and the other for the Sprint wireless broadband dongle that I use when I’m on the road.”

So wait—that’s three USB ports, which is one more than any but the most expensive Apple-branded laptop. The laptop I own only Mac laptop I can afford has only two, and since I’m stuck with the early 2006 model, other than two-fingered scroll, none of the mouse gestures work, either.

“My fingers felt like they were tripping over each other when I was typing, to the point that I found that I was actually taking longer to type emails on the mini 9 than it took me to tap them in on an iPhone!”

The choadiness and inaccuracy of my fingers is a matter of record. I’m typing this on a Mini 9, right now. Not suffering. Quotation marks are a pain. They are infinitely worse on the iPhone—the author could at least learn to lie plausibly.

“16GB is not enough capacity to load an OS, a complete office suite, and actually do some work.”

I’m sorry if this guy couldn’t run the Mail Merge Wizard, but no one I know wants a netbook so they can use Office. If you’re seriously writing blog posts in Word or coding pages in Dreamweaver, there are tons of fastlight, and awesome text editors, writing programs, and blogging tools out there for OS X. Can’t store all your music? Put it on a server and mount it with ExpanDrive. Even Photoshop has lighter alternatives.

Once the OS is on (and it fits on 8GB machines), hard drive space should be a non-issue. If not, you’re doing it wrong.

“Next, the limited screen resolution (1024 x 600) of the mini 9 made it virtually impossible to use some Mac apps that have default minimized screen sizes that are larger than that. Those apps simply had to be removed from the device, and I was stuck with a somewhat crippled hackb00k that didn’t have the software tools I normally use.”

What tools? The author is completely non-specific in what he could and couldn’t do, which is infuriating behavior for a reviewer. It’s not like he’s just avoiding brand names—aside from basic text entry, he fails to name even the tasks he attempted to carry out. How is this supposed to be helpful to anyone?

Some solutions do exist to keep peace in the battle between windows and screen space. That having been said, a netbook is “somewhat crippled” by definition. Anyone conisdering a Mini 9 needs to take careful stock of what exactly they intend to do. For broswer, mail, text editing, writing, blogging, and IM, I’ve got no beefs.

I don’t mean to belittle the author of this piece, but even his solutions are ridiculous. The 25,000 iPhone apps he cites are nothing even close to what a netbook brings you. Terminal, real SSH, multitasking, a little thing called root access, and gobs of other critical real-world features are all still only available on jailbroken phones—and I wouldn’t expect Apple to change that anytime soon. Let’s not even mention the AppStore’s strict and largely arbitrary acceptance protocol.

The sort of hybrid touch device he suggests is similarly inapplicable to this situation. It would cost far more than regular laptop, and be at least as large and cumbersome. When low cost and small size are the only reasons anyone would ever buy a netbook, I can’t see how this product would fill a similar niche.

The OS X hackbook appeals to hardscrabble, substance-over-style users who value stripped-down, efficient tools. The author of this post owns a MacBook Air, which, with its ludicrous debut price and limited features, is the epitome of all we hate about Apple. Working with a Mini 9 doesn’t live up the Jobsian Ideal, but for those of us who can manage sleeping on a bed with fewer than four pillows, it’s a Mac by any other name.

OS X is a phenomenal work environment. I’d never chose to use anything else. But for way too long, it’s been chained to machines that are, if not overpriced, certainly a financial hardship. The ability to elude this monetary burden, combined with optimized portability, is a fantastic thing—and you shouldn’t need to be the World’s Toughest Writer to appreciate that.

Moonshine Macs To End the Apple Tax

Thursday, March 12th, 2009

I’ve been paying the Apple tax, in one way or another, since 1984 and I’ve been doing it with a minimal amount of grumbling. But that last batch of MacBooks really irked me, especially the $700+ up-sell if you want FireWire. (Apple’s poverty prize, a three-year-old design with some new parts wedged into it, hardly merits mention here.)

dell-mini-9-mac-os-x.jpg
Consider this your call to rebellion.

But some recent developments may finally crack the whip on Apple’s runaway markups. It’s gotten to the point that, roughly the price of no-frills aluminum MacBook, now you can get an iMac and decently sleek, ultra-portable Dell netbook.

The desktop machine buries the $2000 MacBook Pro in terms of performance, and the netbook does the same in terms of portability. That’s two machines for 30% less than the cost of one. And, in case you’ve been sleeping under a rock for the past month, yes: they both run OS X.

I realize that there are some DIY costs involved with the Hackintosh, and maybe 1% of users really do need the MBP’s combo of power and portability (with another 9% self-absorbed enough to think they do). Heck, I’ll even admit that if I were man of means, the light-up keys might just be worth the two grand.

But much like Sam Adams before it, I think Apple has drastically overestimated its consumer appeal in harsh economic times. As the hackers churn out more Grandma-ready mods, and as the economic grindstone keeps milling idiot consumers into tech-savvy flour, Apple will have to seriously re-evaluate its pricing strategy.

Peaceful coexistence between Rails and PHP

Tuesday, March 3rd, 2009

Have a Rails application you’d like to have coexist with some existing PHP code? Our website is set up as a Rails app, and we’d like to add bbpress, a php forum application, deployed as a directory. Generally speaking, it works fine – but the DirectoryIndex, in this case index.php, doesn’t get picked up and you are returned the 404 page from your Rails application.

To be sure, make sure you have the DirectoryIndex set up with index.php on the end. DirectoryIndex index.html index.php

now set up mod_rewrite to take care of business
RewriteEngine on

RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f 
RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME}/index.php -f 
RewriteRule ^(.*)$ $1/index.php [QSA,L] 

If you’re using Mongrel, make sure you have those rewrite rules in the Apache config file before it the request gets rewritten off to the proxy balancer.

That’s all she wrote.

Mac Retrogaming on your iPhone with minivMac.app

Monday, December 15th, 2008
crystal.png

iPhone developers, it seems, have been coming after Mac users of a certain vintage, retrofitting classic Mac games for the glitzy new portable platform. But after dropping a fat $5 on the iPhone/iPod Touch remake of Crystal Quest, I’ve gotta say I’m disappointed.

Among my beefs were the chincy techno score, the few missing sounds (the ominous “blib”* as Nasties entered the arena; the “gasp” as you cleared a level), and the complete omission of the original manual. “Stay cool at all times. Uncool dudes get stomped on”; those weren’t mere game instructions, they were rules for life.

instruct.png

Fortunately, thanks to the heroic efforts of a few bold hackers, the mini vMac emulator we all know and love has been ported to the iPhone. Now Crystal Quest and host of other Mac Plus classics are just waiting to be installed on your iPhone.

To be fair, Crystal Quest is all but unplayable (you can steer or you can shoot—pick one) but the near-identical aspect ratios of the 512×342 Mac Plus and 480×320 iPhone make for a seriously well-rendered experience in many older games. My personal favorite, The Dungeon Revealed, plays as well as ever.

dungeonr.png

Getting the emulator running does require a bit of work; you’ll need to jailbreak your phone, and to add the namedfork.net repository to Cydia, which will allow you to download the minivmac emulator like any other non-Apple Store app.

Once you’ve installed it, go to your computer and download a Mac Plus ROM, OS 6.0.8, and whatever Mac Plus-compatible classic Mac games you want to play. You’ll need to put the OS and the games on 800k disk images (file extensions should be .img), and then—using Expandrive, of course—add everything to /Applications/minivmac.app/ on your iPhone.

Read through the basic gesture instructions, and fire up the Mini vMac app. If you’ve put everything in the right format and the right place, the app should play the old Mac beep, and ask you to insert a disk. Chose whichever disk image you put OS 6 on, and the emulator should boot from there.

If your disks appear as locked on the emulated desktop (a padlock icon appears in the upper-left corner of their windows), you’ll need to open Mobile Terminal on your iphone and enter the following if you want to save your games:

login root
[Enter your root password at prompt. Default is "alpine".]
chmod 777 /Applications/minivmac.app/[name of game's disk image here]
logout

That should do it. Drop any questions in the comments. I’ll get to them as soon as I can.

*actually, the “blib” is there—just couldn’t hear it over the techno.

Fix Remote Desktop’s “Authentication Failed” error—remotely!

Monday, September 29th, 2008

One of the most frustrating things about Apple Remote Desktop is the “authentication failed” errors that pop up from time to time. You’ve got your user name and password right, but for some reason, the client machine just won’t recognize you.

I got the dreaded “authentication failed” error after upgrading one client machine to version 3.2.2, and so I patched together a solution that allows you to solve the problem remotely, using our good friend SSH. It’s all Terminal window commands, but it’s straightforward enough that most users should be comfortable doing it.

Step 1: SSH to the uncooperative client. You can do this via local IP address:

$ ssh [admin username]@[client machine IP address]

Or over Bonjour if a) you don’t know the IP, or b) your router assigns IPs dynamically.

$ ssh [admin username]@[client machine name].local

If you’ve never connected with SSH before, you’ll have to type “yes” before you enter your admin user password when the “Password” prompt comes up.

My machines are all named after deadly sins, so when I do this, it looks like the screenshot below. “Lust” is the computer I’m using, “Wrath” is the remote machine that’s giving me the “authentication failed” error when I try to connect to it using Remote Desktop.

login.png

Notice how the computer name listed before “cosmo” has now changed from “Lust” to “Wrath”. Be sure that when you enter any Terminal commands described on this page other than ssh, you’re entering them on the remote machine, not the machine you’re running ARD from. If you don’t pay attention, you could end up deleting a bunch of files that are working just fine.

Step 2: Kill ARD on the remote machine. Once you’re connected to the client, type the command top. This opens activity monitor, listing all the processes currently running on the remote machine. Note the process ID numbers of “ARDAgent” and “AppleVNCServer”, along with ‘ARDHelper” if it shows up. login.png

Once you’ve identified those numbers, open a new Terminal window, SSH to the remote machine again, and then force quit these process by typing kill followed by their process ID number (“PID”).

$ kill 234
$ kill 233

Terminal might whine about quitting ARDHelper because it’s being run by root, but use the sudo command or the bang-bang trick to force the process into submission.

$ sudo kill 228

Step 3: Delete the offending files. As far as I can tell, the whole reason the “authentication failed” error comes up is bad data or bad file paths in the Remote Desktop plist files. It might be possible to fix them with a text editor, but I prefer a less fussy solution: delete them.

Double-check to make sure you’re SSHed into your remote machine, and enter the following Terminal commands, one at a time:

$ rm -rf /var/db/RemoteManagement<br>
$ rm /Library/Preferences/com.apple.RemoteDesktop.plist<br>
$ rm ~/Library/Preferences/com.apple.RemoteDesktop.plist<br>
$ rm -r /Library/Application\ Support/Apple/Remote\ Desktop/<br>
$ rm -r ~/Library/Application\ Support/Remote\ Desktop/

Step 4: Fire ARDAgent back up. Now that you’ve quit the processes and deleted the old stuff, change directories to the ARDAgent folder, then turn everything back on and recreate the plist files. You can do this by entering the following two commands:

$ cd /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/
$ sudo ./kickstart -activate -configure -access -on -users username -privs -all -restart -agent -menu

Step 5: Reconnect to the client machine using Remote Desktop. Re-open Remote Desktop on your computer and go to the Scanner. It won’t remember the name of the old machine, but it will still detect it and list its IP address. Double-click that machine, enter your admin name and password, and your dominion over it should now be restored, all without getting out of your chair.

Setting up Hamachi on OS X

Thursday, July 24th, 2008

It’s really too bad LogMeIn had to buy [suck the life out of] Hamachi. Hamachi lets you easily [really easily] setup your own virtual private network. It lets you link together remote computers as if they were on the same local network, no matter where they are, or what router they might be behind. Its one of those rare pieces of technology that magically “just works”

  1. Install Hamachi on any of your machines – it runs on Mac/Windows/Linux.
  2. You are automatically assigned a static virtual IP address in the 5.x.x.x address space
  3. Create or connect to a network – which has a name of your choosing, and is password protected.
  4. Enjoy

On a Mac, that means wonderful things like iTunes music sharing work directly across the internet. No matter where where your computers are – you can see whoever is on the network as long as they have an internet connection. You can also immediately access a screen sharing or file sharing session through finder with a click of a button, whether the machine is next to you – or on the other side of the world.

It’s really great. And it really IS that easy.

Some helpful hints on installation:

The easiest way to get up in running is by using the installer in the [ugly] HamachiX graphical front end. Their documentation walk you through everything. For an even better experience, configure Hamachi to startup at boot with these instructions hosted over at GitHub

Packing It All In: Distributing Python With an App

Tuesday, May 13th, 2008

Python has lovely built-in distribution tools. They’re great to use if you need a nice, repeatable, easy way to distribute your source code and have it install cleanly on a platform that has its $PATH set up correctly. However, if you want to distribute Python as part of a commercial software package, to platforms that may not even have Python installed, the procedure is not as clean or clear-cut. We devised a way to do it that mostly works, though we have to tweak it somewhat for each release. I’ll show you here our method for doing just that, using the Snakefood program for dependency extraction and a custom script to fill in the gaps that Snakefood can’t quite bridge.

Python is an interpreted language, which means, very basically, that it will not compile down to something that will run natively on any platform. The standard way to get Python to operate is to use the CPython interpreter, a program written in C that reads Python code performs the actions it describes (called “interpreting” it). There are other options, too, like Jython and IronPython, which do basically the same thing as CPython except that they translate the Python code to Java and .NET, respectively. We stick with C. After all, the whole reason we’re doing any of this is that we can’t count on Python being installed. We certainly can’t count on Java of .NET being installed.

As a very basic step one, we need to bundle the CPython interpreter with our app. It’s only about 15MB and is highly compressible, so we can easily include the interpreter, but the standard libraries in Python make for a fairly large installation: the estimated size of Python 2.5.2 is about 180MB. Even if we compress that, it’s still a huge download and a not-so-inconsequential amount of hard drive space. The good news is that we don’t use all of the standard libraries. The even better news is that there’s a pretty simple way of extracting only the files you do need and packaging them into a much smaller distribution. The trick up our sleeve is a small program written in Python called Snakefood. It’s not perfect, but I’ll show ways to get the most out of it.

The first step, of course, is getting Snakefood and installing it. If Python is in your $PATH, just extract the source, then run:

% python setup.py install

from the Snakefood directory, which will install Snakefood to wherever your current Python installation is. You can then run it with:

% python sfood <target file>

from any directory. The target file is the main script of your program. With just that command, it will pull the dependencies from the ‘import’ statements in your main script. That’s probably not good enough, so use the option --follow, which follows all the import statements in each of the imported modules to their leaves. That gets most of what you need.

The output of running Snakefood on a target is not entirely intuitive. It is a list of tuples like the following:

((<source_package_root>, <source_file.py>), (<dest_package_root>, <dest_file.py>))

But sometimes the entry looks like this:

((<source_package_root>, <source_file.py>), (None, None))

It may be tempting, but you can’t skip these lines.

The format of the dependencies tells you that <source_file.py> depends on <dest_file.py>, so you need to preserve it in your pared-down distribution. For us, this is as simple as making a new directory called dist/, and copying the file at path os.path.join(<dest_package_root>, <dest_file.py>) into it. You can make a list of these files directly from the Snakefood output (piped from stdin) with the following script:

import sys   
import os   
files = set()
for dep in map(eval, sys.stdin):
    if dep[1][0] is not None:
        path = os.path.join(dep[1][0], dep[1][1])
        files.add(path)
    else:
        path = os.path.join(dep[0][0], dep[0][1])
        files.add(path)

Now take this set of files and copy them into your new directory. Preserving the directory hierarchy is nontrivial, but not that hard. Hopefully, you have already created a custom Python installation so that all of the relevant files are in one place anyway. From there, you must find the root of the dependency tree. My custom Python installation is at /Users/matthewmoskwa/ExpanDrive/python, so on each path in the file set, I split on 'python' and copy the new path into the dist/ directory (making sure to create new directory nodes first):

import shutil
for fi in files:
    distPath = os.path.join('dist', fi.split("python")[1])
    if not os.path.exists(os.path.dirname(distPath)):
        os.makedirs(os.path.dirname(distPath))
    shutil.copy(fi, distPath)

At this point, the writer of Snakefood claims 99% accuracy. I haven’t measured that claim, but I have found a major drawback: Snakefood misses all __init__.py files, and therefore any import statements in those files. Rather than being smart about it, I just use os.walk() to find all the __init__.py files and copy them into dist/. I then ru my code from dist/ and look for ImportErrors. When I see one, I modify my script to manually copy the missing file to dist/. Not perfect, but it works, and it’s still much faster than doing the whole thing by hand.

The final step is to compile all of the files down to .pyo and remove all the .py and .pyc files. We use a Python script called compileall.py, located in the standard library, to compile, and then

% find . -type f -name '*.pyc' -print0 | xargs -0 rm -rdf

to remove the files. Make sure to run compileall.py with the -OO option to get rid of docstrings and other unnecessary stuff.

Until someone writes an OS in Python or all OSes are guaranteed to have Python installed, this is a pretty good way to distribute Python code to the masses. The next step, actually getting it to run like an application, is up to you, though py2app and py2exe can certainly help.

ExpanDrive Version 1.2

Monday, May 12th, 2008

Fresh off the press, out today, come and get it while it’s hot. Since 1.2 seems to be the magic number, that’s what we’re calling ours too.

Big ticket items: free space remaining now displays correctly on servers that support python. A filter field’s been added to the Drive Manager for those of us that have oh-so-many drives. Public key support is far more robust – in addition, encrypted private keys are also now supported.

Also, you might want to try a little Dino Run.

Subscribe:

Add to Google
RSS
Try ExpanDrive

If you’ve heard of SSH then you need ExpanDrive.