<?xml version="1.0" encoding="UTF-8"?><!-- generator="FugitiveCMS/1.0" --><rss version="2.0" 
        xmlns:content="http://purl.org/rss/1.0/modules/content/"
        xmlns:wfw="http://wellformedweb.org/CommentAPI/"
        xmlns:dc="http://purl.org/dc/elements/1.1/"
        ><channel>
        <title>FugitiveThought.com</title>
        <link>http://fugitivethought.com/</link>
        <description>FugitiveThought.com</description>
        <pubDate>0</pubDate>
        <generator>http://fugitivethought.com/cms</generator>
        <language>en-us</language><item><title>Xen HVM + obtaining platform data&#8230;</title><link>http://fugitivethought.com/viewthoughts.php?refer=rss&amp;index=95</link><comments>http://fugitivethought.com/viewthoughts.php?refer=rss&amp;index=95</comments><pubDate>2009/09/02</pubDate><dc:creator>Steve Maresca</dc:creator><image>     <url>http://fugitivethought.com/images/Steve.jpg</url>          <title>Steve Maresca</title>          <link>http://fugitivethought.com/</link></image><category></category><guid isPermaLink="false">http://fugitivethought.com/viewthoughts.php?refer=rss&amp;index=95</guid><description><![CDATA[<p><em>The following provides an overview for a quick little project I threw together motivated by some inquiries in the ##xen IRC channel on Freenode.org. It involves a kernel module; full source is included.<br /></em></p><p><em>Audience: Xen users/admins running linux in HVM context (without the pv-on-hvm kernel module in use) who have avoided ...]]></description>       <content:encoded><![CDATA[<p><em>The following provides an overview for a quick little project I threw together motivated by some inquiries in the ##xen IRC channel on Freenode.org. It involves a kernel module; full source is included.<br /></em></p><p><em>Audience: Xen users/admins running linux in HVM context (without the pv-on-hvm kernel module in use) who have avoided paravirtualization for various reasons, yet require information about the underlying virtualization platform. </em></p><p><em>The following is directly excerpted from the README file. <br /></em></p><p>This is a kernel module for use with linux virtual machines, running in HVM mode atop the Xen hypervisor.<br /><br />In essence, it functions as a Xen hypercall skeleton for HVM guests, querying the hypervisor for information. Linux is rarely run in this mode unless there is some operational requirement imposing full hardware virtualization instead of paravirtualization. That said, it is occasionally useful for management purposes to obtain a VM UUID from within the guest rather than via the control plane.<br /><br />Offers information via /proc/zentific including the uuid of the VM and major/minor version information from the underlying hypervisor.<br /><br />Yes, /proc is 'deprecated.' It was convenient. :)&nbsp; I'll update this if anyone ever actually cares.<br />&nbsp;<br />&nbsp;<br />Instructions<br />---------------------------------------------------------------------------<br />1) Build the module<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a) make sure kernel headers are installed<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; b) make sure a full development toolchain is installed<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; c) run 'make'<br />2) /sbin/insmod zentific.ko<br />2a)&nbsp;&nbsp;&nbsp;&nbsp; alternatively use modprobe if preference/requirement dictates.<br />3) run dmesg to see some status and initialization output<br />3) cat /proc/zentific/{uuid,xen_ver}<br />4) /sbin/rmmod zentific</p><p>&nbsp;</p><p><strong>Download: </strong>http://www.zentific.com/files/zentific-kernel.tar.gz </p>]]></content:encoded>        <wfw:commentRSS>http://fugitivethought.com/viewthoughts.php?refer=rss&amp;index=95</wfw:commentRSS></item><item><title>RPC Call Cacher&#8230;</title><link>http://fugitivethought.com/viewthoughts.php?refer=rss&amp;index=94</link><comments>http://fugitivethought.com/viewthoughts.php?refer=rss&amp;index=94</comments><pubDate>July 11, 2009</pubDate><dc:creator>Justin DeMaris</dc:creator><image>     <url>http://fugitivethought.com/images/Justin.jpg</url>          <title>Justin DeMaris</title>          <link>http://fugitivethought.com//justin/index.php</link></image><category></category><guid isPermaLink="false">http://fugitivethought.com/viewthoughts.php?refer=rss&amp;index=94</guid><description><![CDATA[<p>I've been working a lot with RPC-centric web application development lately, mostly centered around XML-RPC, but in general, the encoding method is fairly irrelevant. In all of my systems, I wrap the RPC call into a single function named "call" that I can use to pass parameters, name the function to call, and include handlers for results and ...]]></description>       <content:encoded><![CDATA[<p>I've been working a lot with RPC-centric web application development lately, mostly centered around XML-RPC, but in general, the encoding method is fairly irrelevant. In all of my systems, I wrap the RPC call into a single function named "call" that I can use to pass parameters, name the function to call, and include handlers for results and for errors:</p>
<p><pre>function call(name, params, handler, error_handler)</pre></p>
<p>A lot of times, I end up making the same call on multiple places to retrieve similar data, and I decided that I wanted a method to cache the results of these calls in a generic way, so that I can reduce the amount of required client-server communication in a controlled fashion, to increase performance. So I wrote a generic, client-side RPC Call Cacher in JavaScript that can be used to wrap any RPC mechanism that you use.</p>
<p>To get started with it, the file can be downloaded: <a href="/projects/CallCache.js">CallCache.js</a> for your use.</p>]]></content:encoded>        <wfw:commentRSS>http://fugitivethought.com/viewthoughts.php?refer=rss&amp;index=94</wfw:commentRSS></item><item><title>Xen 3.4 on the Asus EEE 901&#8230;</title><link>http://fugitivethought.com/viewthoughts.php?refer=rss&amp;index=93</link><comments>http://fugitivethought.com/viewthoughts.php?refer=rss&amp;index=93</comments><pubDate>2009-05-09</pubDate><dc:creator>Steve Maresca</dc:creator><image>     <url>http://fugitivethought.com/images/Steve.jpg</url>          <title>Steve Maresca</title>          <link>http://fugitivethought.com/</link></image><category></category><guid isPermaLink="false">http://fugitivethought.com/viewthoughts.php?refer=rss&amp;index=93</guid><description><![CDATA[<p>In pursuit of easy <a href="http://www.zentific.com/">Zentific</a> development while on the go, I've been poking at my Asus EEE 901 for some time, trying to convince xen to work properly upon its somewhat unusual platform.  Xen isn't necessarily appropriate for workstation virtualization (even though I make it work), so thus the trouble. I ...]]></description>       <content:encoded><![CDATA[<p>In pursuit of easy <a href="http://www.zentific.com/">Zentific</a> development while on the go, I've been poking at my Asus EEE 901 for some time, trying to convince xen to work properly upon its somewhat unusual platform.  Xen isn't necessarily appropriate for workstation virtualization (even though I make it work), so thus the trouble. I can't promise an experience like that encountered on a nice Opteron 8xxx or Xeon/i7 platform, but if you're like me this may be a good solution for you.</p><p>In fact, I'm posting from my eee running Xen this very moment. </p><p>As with all such things, the devil is in the details. The trouble with the EEE is its relatively recent hardware. The 2.6.20 kernel distributed by Asus with its custom xandros derivative is very hacked to support such hardware - not that this is a bad thing, because it works wonderfully, but it implies that stepping outside of that rather custom-built box introduces some fun.  As  it is, the wifi drivers are - as of 2.6.30 - still in the unofficial, not-endorsed, 'staging' section of the kernel, otherwise known as the scary experimental department. Yes, that's ten versions after the .20 kernel originally running this thing, which demonstrates just how new some of this hardware is from a driver perspective.</p><p>But I digress, as usual.</p><p>I've been running the netbook remix version of Ubuntu Hardy.  This is essentially a normal Hardy install with a patched version of 2.6.24 to support hardware appropriately, plus a few userspace helpers and some nice interface tweaks for the tiny screen.  At any rate, this distribution is entirely sufficient for Xen (I take issue with the Ubuntu Xen package maintainer and moreover the way Canonical is approaching virtualization, but that's a different post. :)</p><p>So, the details:</p><p>I've built Xen 3.4-rc4 and a 2.6.30-xen kernel directly derived from Jeremy Fitzhardinge's paravirt-ops tree at git.kernel.org. The former includes its own 2.6.18 kernel (with many backported drivers), but the system is only barely usable in that state. With my kernel, however &quot;everything works&quot; - in quotations because it's not really everything (the webcam doesn't for example), but that's good enough for me for the time being. If someone really cares, I'll poke at it some more. </p><p>The meat can be found at <a href="http://zentific.com/files/eee/pvops-dom0-xen-kernel.tar.gz">http://zentific.com/files/eee/pvops-dom0-xen-kernel.tar.gz</a>  and <a href="http://zentific.com/files/eee/xen-3.4-rc3-eee.tar.gz">http://zentific.com/files/eee/xen-3.4-rc3-eee.tar.gz</a> -- but be sure to peruse the readme I've put together for particulars. <a href="http://zentific.com/files/eee/readme">http://zentific.com/files/eee/readme</a> </p><p>Hope this helps someone. If not, oh well. Fugitivethought is my personal braindump so I can forget about some of the details and come back to check later.</p><p>Any questions, notes, etc email me or leave a comment.</p><p>-s </p>]]></content:encoded>        <wfw:commentRSS>http://fugitivethought.com/viewthoughts.php?refer=rss&amp;index=93</wfw:commentRSS></item><item><title>Zentific updates&#8230;</title><link>http://fugitivethought.com/viewthoughts.php?refer=rss&amp;index=92</link><comments>http://fugitivethought.com/viewthoughts.php?refer=rss&amp;index=92</comments><pubDate>2009-03-24</pubDate><dc:creator>Steve Maresca</dc:creator><image>     <url>http://fugitivethought.com/images/Steve.jpg</url>          <title>Steve Maresca</title>          <link>http://fugitivethought.com/</link></image><category></category><guid isPermaLink="false">http://fugitivethought.com/viewthoughts.php?refer=rss&amp;index=92</guid><description><![CDATA[<p>Why yes, Zentific can do RDP.</p><p>and now, so can xen. :)</p><p>Email me or leave a comment if you are interested in the source.. </p>]]></description>       <content:encoded><![CDATA[<p>Why yes, Zentific can do RDP.</p><p>and now, so can xen. :)</p><p>Email me or leave a comment if you are interested in the source.. </p>]]></content:encoded>        <wfw:commentRSS>http://fugitivethought.com/viewthoughts.php?refer=rss&amp;index=92</wfw:commentRSS></item><item><title>Parallelization in PHP&#8230;</title><link>http://fugitivethought.com/viewthoughts.php?refer=rss&amp;index=91</link><comments>http://fugitivethought.com/viewthoughts.php?refer=rss&amp;index=91</comments><pubDate>January 7, 2009</pubDate><dc:creator>Justin DeMaris</dc:creator><image>     <url>http://fugitivethought.com/images/Justin.jpg</url>          <title>Justin DeMaris</title>          <link>http://fugitivethought.com//justin/index.php</link></image><category></category><guid isPermaLink="false">http://fugitivethought.com/viewthoughts.php?refer=rss&amp;index=91</guid><description><![CDATA[<p>This is a simple example you can re-use for splitting up processing of data across processes for faster execution. Put all of the data into the $set and fill in function process with what you want to do on the data, and let 'er loose! I'm personally using it for telnet scripts because the amount of time spent waiting for a single telnet session ...]]></description>       <content:encoded><![CDATA[<p>This is a simple example you can re-use for splitting up processing of data across processes for faster execution. Put all of the data into the $set and fill in function process with what you want to do on the data, and let 'er loose! I'm personally using it for telnet scripts because the amount of time spent waiting for a single telnet session is horrible and I can run many sessions at once while I wait for the responses.</p>
<p><pre class="php" name="code">

/**
 * Splits the given set into $count subsets that are of approximately equal size
 */
function array_split($set, $count) {
   $subset_size = ceil(count($set) / $count);
   return array_chunk($set, $subset_size);
}

/**
 * Forks into $process_count separate processes and executes the function
 * named in $job in each process to split up handling of the data in
 * $set across the processes.
 */
function fork_exec($set, $job, $process_count) {
   $subsets = array_split($set, $process_count);
   $children = array();

   // launch all of the children and store process list
   foreach ( $subsets as $a_set ) {
      $pid = pcntl_fork();

      if ( $pid == -1 ) die("Error forking");
      else if ( $pid == 0 ) { call_user_func($job, $a_set); exit(0); }
      else $children[] = $pid;
   }

   // wait for each process to end
   while ( count($children) > 0 ) {
      $pid = array_shift($children);
      pcntl_waitpid($pid, $status);
   }
}

// example set to work on
$set = array('a','b','c','d','e','f','g','h','i','j');

// Process the job with 3 threads and time it
$time = microtime(true);
fork_exec($set, 'process', 3);
$diff = microtime(true) - $time;
echo $diff . ' seconds for full run'."\n";

// This is the job to run on the set. Make sure it is multi-process safe!
function process($set) {
   foreach ( $set as $item ) {
      echo "Process [" . posix_getpid() . "] executing '" . $item . "'\n";
      sleep(1);
   }
}
</pre></p>]]></content:encoded>        <wfw:commentRSS>http://fugitivethought.com/viewthoughts.php?refer=rss&amp;index=91</wfw:commentRSS></item><item><title>Virtualization: Hardening Xen&#8230;</title><link>http://fugitivethought.com/viewthoughts.php?refer=rss&amp;index=90</link><comments>http://fugitivethought.com/viewthoughts.php?refer=rss&amp;index=90</comments><pubDate>2008 December 9</pubDate><dc:creator>Steve Maresca</dc:creator><image>     <url>http://fugitivethought.com/images/Steve.jpg</url>          <title>Steve Maresca</title>          <link>http://fugitivethought.com/</link></image><category></category><guid isPermaLink="false">http://fugitivethought.com/viewthoughts.php?refer=rss&amp;index=90</guid><description><![CDATA[<p>Coming soon in this entry, details about hardening your xen installations.</p><p>Topics to be discussed include:</p><blockquote> -paravirtual framebuffer: intended function, patch sets, and practical considerations. 3.0.4 and up.<br />-pygrub<br />-xenstore denial of service<br />-networking (ebtables, iptables, etc)<br /> -vnc over SSL<br /> ...]]></description>       <content:encoded><![CDATA[<p>Coming soon in this entry, details about hardening your xen installations.</p><p>Topics to be discussed include:</p><blockquote> -paravirtual framebuffer: intended function, patch sets, and practical considerations. 3.0.4 and up.<br />-pygrub<br />-xenstore denial of service<br />-networking (ebtables, iptables, etc)<br /> -vnc over SSL<br /> -xenapi over SSL<br />-minios, stubdomains, pvgrub<br />-driver domains<br />-pci passthrough (why DMA spells disaster when lacking an IOMMU)<br /><br /></blockquote>In progress and coming your way as time permits. Check back soon.<br /><br /><a href="http://zentific.com/software">http://www.zentific.com</a> :)]]></content:encoded>        <wfw:commentRSS>http://fugitivethought.com/viewthoughts.php?refer=rss&amp;index=90</wfw:commentRSS></item></channel></rss>