<?xml version='1.0' encoding='UTF-8'?><rss xmlns:atom='http://www.w3.org/2005/Atom' xmlns:openSearch='http://a9.com/-/spec/opensearchrss/1.0/' version='2.0'><channel><atom:id>tag:blogger.com,1999:blog-4152097373641005138</atom:id><lastBuildDate>Fri, 16 Jan 2009 16:14:48 +0000</lastBuildDate><title>Cloud Scale</title><description>The rarified atmosphere of cloud design.</description><link>http://jamiesonbecker.com/blog.html</link><managingEditor>noreply@blogger.com (Jamieson)</managingEditor><generator>Blogger</generator><openSearch:totalResults>8</openSearch:totalResults><openSearch:startIndex>1</openSearch:startIndex><openSearch:itemsPerPage>25</openSearch:itemsPerPage><item><guid isPermaLink='false'>tag:blogger.com,1999:blog-4152097373641005138.post-1213252415576332546</guid><pubDate>Thu, 01 Jan 2009 00:23:00 +0000</pubDate><atom:updated>2009-01-10T14:32:35.032-08:00</atom:updated><category domain='http://www.blogger.com/atom/ns#'>memcache caching</category><title>Memcache may not be as fast as you think</title><atom:summary type='text'>I became a big fan of memcache a few years ago and used it for several projects, where it was extremely useful. A recent project involved distributed caching on front-end web servers that each had multiple GB's of RAM and about 1TB of local disk each.  As I was designing the application, I did some simple testing to learn whether the advantage of hitting a network-based memory cache could really </atom:summary><link>http://jamiesonbecker.com/2008/12/memcache-may-not-be-as-fast-as-you.html</link><author>noreply@blogger.com (Jamieson)</author><thr:total xmlns:thr='http://purl.org/syndication/thread/1.0'>6</thr:total></item><item><guid isPermaLink='false'>tag:blogger.com,1999:blog-4152097373641005138.post-8971922243585613584</guid><pubDate>Sun, 19 Oct 2008 21:40:00 +0000</pubDate><atom:updated>2009-01-08T00:42:52.659-08:00</atom:updated><category domain='http://www.blogger.com/atom/ns#'>python</category><title>Finding actual path of a python script</title><atom:summary type='text'>Python guru ironfroggy pointed out a quick way to pull the path of the module you are located in (aside from sys.modules['__main__'], which doesn't always work) is os.path.abspath(os.path.dirname(__file__)).</atom:summary><link>http://jamiesonbecker.com/2008/10/finding-actual-path-of-python-script.html</link><author>noreply@blogger.com (Jamieson)</author><thr:total xmlns:thr='http://purl.org/syndication/thread/1.0'>2</thr:total></item><item><guid isPermaLink='false'>tag:blogger.com,1999:blog-4152097373641005138.post-1202495457910662954</guid><pubDate>Sun, 03 Aug 2008 18:21:00 +0000</pubDate><atom:updated>2009-01-08T00:42:42.027-08:00</atom:updated><category domain='http://www.blogger.com/atom/ns#'>debian xmms</category><title>How to install XMMS in Debian Lenny</title><atom:summary type='text'>As with most of my posts, this one is also a quickie problem solution, so ignore it if it doesn't apply to you. Why XMMS when it's been dropped by Debian and Ubuntu? Simply because it handles problematic playlists (i.e., playlists with ../ in them, which I use a lot and audicious doesn't handle), it handles all files without crashing (i.e., Amarok and Audacious both hang with many of my tunes), </atom:summary><link>http://jamiesonbecker.com/2008/08/xmms-in-lenny.html</link><author>noreply@blogger.com (Jamieson)</author><thr:total xmlns:thr='http://purl.org/syndication/thread/1.0'>4</thr:total></item><item><guid isPermaLink='false'>tag:blogger.com,1999:blog-4152097373641005138.post-1285080192316143784</guid><pubDate>Wed, 23 Jul 2008 16:44:00 +0000</pubDate><atom:updated>2009-01-08T00:42:30.879-08:00</atom:updated><category domain='http://www.blogger.com/atom/ns#'>dns security vulnerability</category><title></title><atom:summary type='text'>"Patch.  Today.  Now. Yes, stay late.  Yes, forward to OpenDNS if you have to.  (They’re ready for your traffic.)  Thank you to the many of you who already have."

The largest vulnerability since about 1999 is here!

THIS IS HUGE. THIS IS HUGE. THIS IS HUGE. (AND APPARENTLY  QUITE REPETITIVE.)

EVERY WEBSITE THAT YOU LOG INTO MIGHT NOT ACTUALLY BE THE WEBSITE THAT YOU THINK IT IS.

If you've ever</atom:summary><link>http://jamiesonbecker.com/2008/07/patch.html</link><author>noreply@blogger.com (Jamieson)</author><thr:total xmlns:thr='http://purl.org/syndication/thread/1.0'>0</thr:total></item><item><guid isPermaLink='false'>tag:blogger.com,1999:blog-4152097373641005138.post-4179520801329817717</guid><pubDate>Thu, 26 Jun 2008 02:43:00 +0000</pubDate><atom:updated>2009-01-08T00:41:47.951-08:00</atom:updated><category domain='http://www.blogger.com/atom/ns#'>debian ubuntu</category><title>Dynamic MMAP ran out of room</title><atom:summary type='text'>I always forget this, and wanted to post it here: if you ever get "Dynamic MMAP ran out of room" when apt-get updating, it's probably because you're pinning or getting ready to dist-upgrade. To fix it, just add this line to /etc/apt/apt.conf to increase the apt cache limit to 8MB:

APT::Cache-Limit "8388608";</atom:summary><link>http://jamiesonbecker.com/2008/06/dynamic-mmap-ran-out-of-room.html</link><author>noreply@blogger.com (Jamieson)</author><thr:total xmlns:thr='http://purl.org/syndication/thread/1.0'>0</thr:total></item><item><guid isPermaLink='false'>tag:blogger.com,1999:blog-4152097373641005138.post-996777759783924830</guid><pubDate>Fri, 06 Jun 2008 05:47:00 +0000</pubDate><atom:updated>2009-01-08T00:41:42.683-08:00</atom:updated><category domain='http://www.blogger.com/atom/ns#'>json http iso countries codes zip IP states area codes</category><title>Quickie databases (in JSON, of course)</title><atom:summary type='text'>(Note: all of the JSON files below I created/converted by hand using regular expressions, and I'm placing them into the public domain. The larger ones are compressed with gzip, which is a fast but efficient standardized compression system. (It's part of HTTP -- yes, even Internet Explorer has been able to decompress it for years.)  If you need a program to decompress it, it's probably already </atom:summary><link>http://jamiesonbecker.com/2008/06/quickie-databases-in-json-of-course.html</link><author>noreply@blogger.com (Jamieson)</author><thr:total xmlns:thr='http://purl.org/syndication/thread/1.0'>1</thr:total></item><item><guid isPermaLink='false'>tag:blogger.com,1999:blog-4152097373641005138.post-1536050669783997552</guid><pubDate>Thu, 05 Jun 2008 01:30:00 +0000</pubDate><atom:updated>2008-06-04T19:11:46.927-07:00</atom:updated><category domain='http://www.blogger.com/atom/ns#'>http status error json xml w3c python</category><title>HTTP Status Codes (Errors) in JSON and XML Format</title><atom:summary type='text'>Here's a handy conversion of the W3C HTTP Status codes from w3.org and descriptions into both XML and JSON format.

Here's a sample in JSON:
"302": {
  "name": "Found",
  "description": [
      "The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response </atom:summary><link>http://jamiesonbecker.com/2008/06/http-error-descriptions-in-json-and-xml.html</link><author>noreply@blogger.com (Jamieson)</author><thr:total xmlns:thr='http://purl.org/syndication/thread/1.0'>3</thr:total></item><item><guid isPermaLink='false'>tag:blogger.com,1999:blog-4152097373641005138.post-7417704264290026828</guid><pubDate>Wed, 04 Jun 2008 19:35:00 +0000</pubDate><atom:updated>2008-06-08T20:05:43.768-07:00</atom:updated><category domain='http://www.blogger.com/atom/ns#'>sparse virtual servers filesystem linux-vserver xen lvm2</category><title>Overselling your disks without LVM</title><atom:summary type='text'>It's easy to "oversell" (i.e., pretend that you have more disk available) your disks by simply using sparse files. This is particularly useful with Linux-Vserver, Xen, UML, VMware, etc. Just use these sparse files (already mounted) as the "backing store" for your virtual machines.

For instance, let's say that you only have a 1TB filesystem in RAID1 available on your server, but you want to </atom:summary><link>http://jamiesonbecker.com/2008/06/overselling-your-disks-without-lvm.html</link><author>noreply@blogger.com (Jamieson)</author><thr:total xmlns:thr='http://purl.org/syndication/thread/1.0'>0</thr:total></item></channel></rss>