I did this partly to test the speed, and partly to reduce the bandwidth costs that I was seeing through MaxCDN.
A little background – CloudFlare works by taking over as the primary DNS provider for your domain- In order to use their service, you need to set CloudFlare as your domain’s primary name servers.
This makes some sense, since they can route to various servers on their site as necessary, but creates a bit of a headache-
I offer Robohash in both HTTP and HTTPS versions. In order to serve HTTPS through CloudFlare, you need to be a premium/paid member. That’s fine, and I don’t mind the fee, but you can’t upgrade your account until your DNS already is moved over.
This creates a bit of a headache in that you to commit to fully using CloudFlare before you get a chance to really test it. With most CDNs I’ve used, I can setup an Origin-Pull, and run both concurrently.
Subjectively, the site did feel faster. I also noticed the number of hits that were hitting my nginx instance were cut down dramatically. Within 2 days, the number of hits reaching my server were cut to 1/7th of what they had been prior.
That makes sense, since the RoboHash.org content is HIGHLY cacheable. In the typical usage, such as a forum or blog, the Robot will be generated for the first user, and then every subsequent load will be from cache.
Pingdom didn’t report any clear change in the load times.
If anything, the page load times seem far more variable after moving over.
Enabling SSL support through Cloudflare was spookily simple.
CloudFlare accepts the SSL request to their site, and proxies it back to my origin over normal HTTP.
I didn’t need to give them a copy of my certificate, or give them any additional information.
CloudFlare has a built-in feature which helps to protect your sites against attack- When users who are suspected being a threat (such as infected PCs, Spammers, or would-be hackers), CloudFlare blocks their access to your site.
Optionally, you can allow these users access, if they pass a CAPTCHA.
RoboHash is a pretty simple service, and I want to make it available to as many people as possible.
Since it loads as part of OTHER people’s sites, I don’t want it blocked. I don’t care if they’re actively trying to hack ME, don’t block it. I don’t want users of Robohash to have a degraded experience.
I emailed CloudFlare, and asked that we disable the blocks entirely. They admitted that there are false positives, and there’s no way to fully disable the feature. They suggested the ‘Essentially Off’ functionality, which is supposed to only challenge the worst of the worst.
Running the service for 2 weeks gave me over 30 blocked IPs, most for being part of a botnet.
I’m not at all comfortable with the number of blocks they were performing.
Further, CloudFlare sets a cookie on every request.
I don’t want this, and it’s not fair to downstream users of RH.org
threepwood:~ e1ven$ curl -I http://robohash.org/ABCD.png HTTP/1.1 200 OK Server: cloudflare-nginx Date: Mon, 27 Feb 2012 20:15:10 GMT Content-Type: image/png Connection: keep-alive Expires: Tue, 26 Feb 2013 20:15:10 GMT Cache-Control: public, max-age=31536000 CF-Cache-Status: HIT Set-Cookie: __cfduid=d9c25dc8324ac644c1ae0f980ae487c311330373710; expires=Mon, 23-Dec-2019 23:50:00 GMT; path=/; domain=.robohash.org
versus the native request
threepwood:~ e1ven$ curl -I https://robohash.org/ABCD.png HTTP/1.1 200 OK Server: nginx/1.0.2 Date: Mon, 27 Feb 2012 20:16:43 GMT Content-Type: image/png Connection: keep-alive Expires: Wed, 29 Feb 2012 20:16:43 GMT Cache-Control: max-age=172800
As an additional point of comparison, here is the result from MaxCDN, another CDN who I’ve had good luck with.
threepwood:~ e1ven$ curl -I http://static1.robohash.org/ABCD.png HTTP/1.1 200 OK Server: nginx/0.8.36 Date: Mon, 27 Feb 2012 20:34:32 GMT Content-Type: image/png Connection: keep-alive Expires: Wed, 29 Feb 2012 20:21:28 GMT Cache-Control: public, max-age=172800 CF-Cache-Status: HIT X-Cache: HIT
Finally, however, I started seeing an increasing number of missing images.
Every so often, maybe one in 20 page loads, I’d see a Robot not just appear at all.
That’s simply unacceptable.
Ultimately, I’ve removed CloudFlare from the DNS for Robohash.
I apologize for any inconvenience caused while I was using it.
I like the idea behind their service, and I can see how it might be useful for a large number of sites, but their offerings are tremendously invasive, give you limited control over disabling their ‘features’.
It’s a good deal if you’re looking to help protect your blog from the slashdot-effect, particularly as a solution that semi-technical users can implement. If you have the patience to learn, it seems like in most cases you’d be better off with a caching Nginx server, potentially combined with a cheap standalone CDN.
You’ll get better performance, more control, and fewer surprises.
My experience playing Grim Fandango, a game from 1998
I’m somewhat ashamed to admit this, especially as someone who purports to be a fan of Adventure Games, but here it goes.. I’ve never played Grim Fandango.
Obviously, this is a very serious situation, which required immediate rectification.
Particularly with the news that the lead developer from Grim Fandango, Tim Schafer, is at work on a new multi-million dollar adventure game.
I had some time off of work, so I decided to take the plunge. I installed and played through the game this week..
The Puzzles were generally paced well, the story was engaging, and the characters were charming.
My biggest challenge with the entire game, it turns out, was getting the game to run properly long enough to finish it
Running on my Macbook
Lately, I’m doing most of my computing on a 17″ Macbook Pro – I’ve pimped the RAM up to 16G, it’s got a speedy processor, the OS is fun to use.
Since there’s no Mac-native version, I took a look at ScummVM, which I had used for other LucasArts games in the past, such as Monkey Island, and Day of the Tentacle.
It turns out that ScummVM only supports the 2d games, but a sister-project exists, ResidualVM which supports Grim.
Their website recently shows the game as 100% completable, so I downloaded the VM, copied the files from the CDs and fired it up.
It took a tiny bit of fidgeting- I needed to manually edit
to allow the game to play fullscreen, but Google was helpful enough in advising me.
The game was glorious! The game’s graphics were a little dated, but were given such a stylized look that it rarely mattered.
I was able to get a few hours into the game, before I ran into a bug in Residual- I walked into an area I wasn’t supposed to get to yet.
Never having played the game before, I had thought that I was playing normally. The tone of the game changed fairly dramatically, but I wrote it off as a mystery I was supposed to discover.
As I kept playing, however, the game was referencing things that took place earlier, which I had no recollection of!
I kept playing the game for a while, until I realized that I had found myself in an unwinnable position.
I had somehow jumped further ahead in the story than I was supposed to be, and had missed some crucial events.
(For anyone who’s played the game, the specific bug I hit was clipping into Domino’s office, immediately after first meeting Meche)
Eventually, I realized that this couldn’t possibly be expected behavior- I checked a walkthrough, and found where the VM had glitched.
Since this was my first play though, I realized that perhaps ScummVM wasn’t quite ready for me yet.
If I had known what lay ahead in trying to play other versions, I probably would have kept playing, bugs be damned. Alas, Hindsight can be cruel.
Try 2, My Trusty old PC
Grim is a PC game, after all, so I figured I’d avoid these bugs if I played it in the original engine.
Simple enough.. I had an old P4 desktop PC I built a few years back.. I just needed to install a hard drive, replace the power supply, install Windows 7, find drivers for all the various components, and I’d be off the races.
Eventually, I got the machine up and running- I reinstalled Grim, set the game to run in compatibility mode, and again, I was playing.
The saves weren’t compatible, so I had to start from Scratch, but that was a small price to pay for knowing that I’d not run into any VM-specific bugs.
The more I played, the more I was having difficulty controlling the game- Grim Fandango is one of those games that feels like a bad console port, even thought it was only ever released on PC.
After a few hours of playing, I realized I really ought to be playing it with a controller.
I trip to Microcenter later, and I was back, a new Xbox360 controller in my bag, and ready to start making serious progress.
The only problem was, the game crashed. Frequently.
Sometimes, the game would crash mid-save, corrupting the save file.
Othertimes, it would just grind to a halt, and become unplayable.
OK, I thought to myself- Compatibility mode doesn’t work. Let’s go back to the source.
Grim was originally released in 1998, so it seemed natural to try running the game under Windows 98.
I still had my original Win98 CDs in the closet, so once more, I formatted my PC, this time installing the classic OS.
The first problem I ran into was that my HD was too large- Each time I asked the Win98 setup utility to partition and format the 500G HD resulted in the machine hanging.
Despite enabling LBA mode, formatting it with a Linux boot CD, and leaving it for hours on the formatting screen, no progress was made.
I dug around, until I was able to find an older 80GB harddrive deep in a closet full of things I ought to have thrown out years ago.
Now, I was able to format successfully. The install was able to get through the text-based part of the installation.. And then crashed.
Googling a bit more, it turns out that Windows 98 won’t run with >512 of RAM.
OK..Luckily, there was a workaround. A few tweaks to system files later, and I’m up and running in glorious 16-color windows.
My Video card was released just a few year too late, it seems, to have had any Windows 98 drivers created. The oldest version of the drivers for my card run on Windows 2000.
I wasn’t stopping here, though-
After some digging, I found a generic SVGA driver that was built for Windows 98.. It wasn’t fast, but it worked.
Next up, Audio- Creative’s site doesn’t list the Win98 drivers anymore, but some clever folks at the MSFN Forum had found a working link to a similar card, built on the same chipset.
Finally, I could fire up the game!
And… It crashed. Every time. On launch.
It didn’t write a log.. Win98 doesn’t have an Event Viewer, so I didn’t have many options.
I realized that I might need some critical Win98 patch in order to play, so I fired up Windows Update.. And was greeted with a redirect loop on Microsoft’s site.
It seems that they don’t even offer the Win98 update service anymore.
Luckily, another Win98 Aficionado put together an Unofficial Win98 Service Pack 2.1, which includes all the updates ever released.
Installed, and the game started…. And the game ran!
The problem was, I was in seconds-per-frame territory.
The Generic SVGA driver does work, but it looks like it can’t take advantage of ANY 2d acceleration.. So the game was entirely unplayable.
Win98 in a VM
OK, I thought! This is solvable. VMware has tested, working drivers for Win98, so I’ll use them.
It might be a bit of CPU overhead, but the video performance should be much faster.
I dutifully reinstalled Windows7, and installed a 30-day demo of Vmware.
It turns out that I needed to use Vmware 7, since the newest Vmware 8 wouldn’t run on my P4 CPU.
I installed Win98, patched it, then loaded the Vmware drivers.
By this point, I was starting to get pretty quick at the whole process- I had all of the drivers I needed for Windows7 copied to my Dropbox, so it was rather straightforward to get running again.
VMware installed cleanly, and Win98 ran mostly without issue. The biggest problem was the Audio drivers that ship with Win98 aren’t always compatible with VMware’s virtual machine hardware – There are replacements however.
Once things were finally back up and running, I re-installed and restarted Grim. This time, I was greated with a beautiful 4-panel screen, in inverted colors, before the game crashed.
I found that the the game would run in Windowed mode, however!
The speed better than native Windows 98, but not yet playable.
Watching the system to see where the load might be, I saw that the CD was being accessed heavily.
Since the game was designed in 1998, the designers tried to minimize the amount of disk space used, preferring to seek the needed content from the CDROM wherever possible.
Luckily, there was an updated launcher for the game, which a fan had released- This program copies all the content from the game’s CDs to the local hard drive, then instructs Grim to use the local version.
The only problem was that this app was that it needed GDI+, a library Microsoft released around the time of Windows XP.
Microsoft had released a version of this library for Windows 98, but they don’t distribute it anymore.
Luckily for me, other sites still have mirrored copies.
After installing, I needed to install DirectX. Microsoft released DirectX 9.0c for Windows 98, so it should be an easy task.. But it turns out that Microsoft released 18 different versions of DirectX with the same version number!.
Once more, I was able to find them Mirrored on a third party page.
Finally, I was able to run the game, and despite it running in a Window, it ran reasonably well.
It was certainly playable, but it stuttered heavily. A bit more research showed that while Win98 would run the WDM drivers for the sound card, it suffered performance problems when using them, compared to the older VXD drivers.
Further, running in Windowed mode heavily cut into performance.
Once more, into the breach
I had read a number of reports of the game running properly in Windows XP’s compatibility mode, so this was my next step.
I created a new VM, installed XP, drivers, updates.
Now that I was on a more modern OS, I was able to use the official Xbox 360 drivers.
After patching Grim, and installing the modified launcher, I was able to run in full screen, and had the best performance of any system yet!
The only problem at this point was the 3d models were flickering in and out of existence while I played. Using DX Diag and disabling DirectDraw finally fixed this problem, allowing me to finally, after days of prep work, play the game reliably.
While it’s clear, in retrospect, that playing the game in Windows XP compatibility mode is the safest balance of driver-availibity to game-compatibility, that was far from obvious initially.
One might reasonably suspect (as I did) that using either the Latest OS, or the one from the time, might be the best choices.
What seems so infuriating is just how difficult it is to play a game from the not-so-distant past!
Grim Fandango was released in 1998.
For reference, That was the same year than the movie Office Space was released.
With Office Space, I can still play a DVD I bought in 1999, or buy a Blu-Ray today.
I can stream the movie from Netflix, iTunes, or Amazon.
I can watch the movie in any number of formats, quickly, easily on any number of devices.
I can still buy and watch movies from nearly 100 years ago, without much effort!
|I can watch these movies more easily than I can play a game that’s younger than either of them.|
But with a Video Game of the same Era, I have to clear obstacle after obstacle.
Now as I mentioned in the introduction, I really enjoy Adventure Games- I’m willing to jump through hoops to play what is considered a Great Game.. But this is far beyond what could be expected of anyone who was simply curious what this great game was about.
Further, to get the game running in each of these scenarios, I relied on a Myriad of third party sites mirroring older utilities, many which technially violate copyright laws.
For older games, DosBox provides a solution to this problem, by allowing Publishers to distribute the game running in a Virtual Machine, very similarly to my eventual solution in VMware.
This isn’t a legal option for newer games, however- If Lucasarts wanted to sell a copy of Grim Fandango this way, they’d need to include a copy of Windows with each game!
This is an instance of Copyright creating unintended consequences.
Outside of moving entirely to FOSS, I would propose that best solution to this puzzle might lie with Microsoft. If they were to release an embeddable version of Windows, that could be used as a wrapper for applications, they could largely solve their compatibility problem.
We already see Microsoft adopting a similar strategy to allow users to test on various versions of IE. Expanding this program to the general public would allow Microsoft to gain the benefits of having programs written to an open standard (indefinite durability), while still tightly controlling the publishing platform.