<?xml version="1.0" encoding="UTF-8"?>
<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/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>keeping simple &#187; security+fault-tolerance</title>
	<atom:link href="http://www.yodaiken.com/category/software-engineering/securityfault-tolerance/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.yodaiken.com</link>
	<description>Systems software technology and business</description>
	<lastBuildDate>Mon, 06 Sep 2010 14:16:12 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.1</generator>
		<item>
		<title>parallel processing and bash reduce</title>
		<link>http://www.yodaiken.com/2009/07/parallel-processing-and-bash-reduce/</link>
		<comments>http://www.yodaiken.com/2009/07/parallel-processing-and-bash-reduce/#comments</comments>
		<pubDate>Thu, 23 Jul 2009 23:00:02 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[data center]]></category>
		<category><![CDATA[operating systems]]></category>
		<category><![CDATA[security+fault-tolerance]]></category>
		<category><![CDATA[software engineering]]></category>
		<category><![CDATA[map reduce]]></category>
		<category><![CDATA[parallel computing]]></category>

		<guid isPermaLink="false">http://www.yodaiken.com/?p=498</guid>
		<description><![CDATA[It&#8217;s sad that after all this time, one can look at any random article on parallel programming and find some variation of: for i = 1 ... n create thread i do something end for as if that was the only way to express parallel computation. This is such an awkward way of looking at [...]]]></description>
			<content:encoded><![CDATA[<p>It&#8217;s sad that after all this time, one can look at any random article on parallel programming and find some variation of:</p>
<pre>for i = 1 ... n
      create thread i
             do something
end for</pre>
<p>as if that was the only way to express parallel computation. This is such an awkward way of looking at problems.Â  I think many problems come from the sloppy &#8220;non-determinism&#8221; of the operating systems and multi-core machines.Â  One of the fewÂ  interesting ideas seen in the last 20 years on parallel processing is the Google <a title="google map reduce" href="http://labs.google.com/papers/mapreduce.html" target="_blank" onclick="pageTracker._trackPageview('/outgoing/labs.google.com/papers/mapreduce.html?referer=');">map-reduce scheme</a> ( . But what I find impressive is <a title="bash reduce" href="http://github.com/erikfrey/bashreduce/blob/71619384b2ab07ff61443a4ca54591b03c44dce0/br" target="_blank" onclick="pageTracker._trackPageview('/outgoing/github.com/erikfrey/bashreduce/blob/71619384b2ab07ff61443a4ca54591b03c44dce0/br?referer=');">bashreduce.</a> This is really a clever trick and a great validation of the UNIX toolset design (as if it needed another validation).</p>
]]></content:encoded>
			<wfw:commentRss>http://www.yodaiken.com/2009/07/parallel-processing-and-bash-reduce/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>Power Systems Reliability Challenges</title>
		<link>http://www.yodaiken.com/2009/04/power-systems-reliability-challenges/</link>
		<comments>http://www.yodaiken.com/2009/04/power-systems-reliability-challenges/#comments</comments>
		<pubDate>Thu, 02 Apr 2009 23:42:08 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[communications]]></category>
		<category><![CDATA[green power]]></category>
		<category><![CDATA[security+fault-tolerance]]></category>
		<category><![CDATA[electric power]]></category>
		<category><![CDATA[fire ants]]></category>
		<category><![CDATA[system reliability]]></category>

		<guid isPermaLink="false">http://www.yodaiken.com/?p=256</guid>
		<description><![CDATA[It is becoming more common for fire ants to build nests in pad mounted equipment. Their nesting materials can cause short circuits, the ants can eat away at conductor insulation, and they make equipment maintenance a challenge. from Power System Reliability, by Richard Brown, in the Electric Power Engineering Handbook The subdued poetry of engineering [...]]]></description>
			<content:encoded><![CDATA[<blockquote><p><em>It is becoming more common for fire ants to build nests in pad moun<a href="http://www.yodaiken.com/wp-content/uploads/2009/04/fire-ant300.jpg"><img class="size-medium wp-image-257 alignright" title="fire-ant300" src="http://www.yodaiken.com/wp-content/uploads/2009/04/fire-ant300.jpg" alt="fire ant" width="270" height="179" /></a>ted equipment. Their nesting materials can cause short circuits, the ants can eat away at conductor insulation, and they make equipment maintenance a challenge.</em></p>
<p>from Power System Reliability, by Richard Brown, in the Electric Power Engineering Handbook</p></blockquote>
<p>The subdued poetry of engineering documents &#8220;<span style="text-decoration: underline;">and they make equipment maintenance a challenge</span>&#8220;.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.yodaiken.com/2009/04/power-systems-reliability-challenges/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Marine One Blueprints via Pirates Bay</title>
		<link>http://www.yodaiken.com/2009/03/marine-one-blueprints-via-pirates-bay/</link>
		<comments>http://www.yodaiken.com/2009/03/marine-one-blueprints-via-pirates-bay/#comments</comments>
		<pubDate>Mon, 02 Mar 2009 05:32:13 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[communications]]></category>
		<category><![CDATA[real-time]]></category>
		<category><![CDATA[security+fault-tolerance]]></category>
		<category><![CDATA[software security]]></category>
		<category><![CDATA[computer security]]></category>

		<guid isPermaLink="false">http://www.yodaiken.com/?p=240</guid>
		<description><![CDATA[Goodness. The US blueprints for Marine1 show up in Iran. &#8220;What appears to be a defense contractor in Bethesda, Md., had a file-sharing program on one of their systems that also contained highly sensitive blueprints for Marine One,&#8221; Boback said. Tiversa also found sensitive financial information about the cost of the helicopter on that same [...]]]></description>
			<content:encoded><![CDATA[<p>Goodness. The US blueprints for Marine1 <a title="MSNBC story" href="http://www.msnbc.msn.com/id/29447088/" target="_blank" onclick="pageTracker._trackPageview('/outgoing/www.msnbc.msn.com/id/29447088/?referer=');">show up</a> in Iran.</p>
<blockquote><p>&#8220;What appears to be a defense contractor in Bethesda, Md., had a file-sharing program on one of their systems that also contained highly sensitive blueprints for Marine One,&#8221; Boback said.</p>
<p class="textBodyBlack">Tiversa also found sensitive financial information about the cost of the helicopter on that same computer, WPXI-TV reported.</p>
</blockquote>
]]></content:encoded>
			<wfw:commentRss>http://www.yodaiken.com/2009/03/marine-one-blueprints-via-pirates-bay/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Mobile device security and President Obama</title>
		<link>http://www.yodaiken.com/2009/01/mobile-device-security-and-president-obama/</link>
		<comments>http://www.yodaiken.com/2009/01/mobile-device-security-and-president-obama/#comments</comments>
		<pubDate>Thu, 22 Jan 2009 17:41:57 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[security+fault-tolerance]]></category>
		<category><![CDATA[software security]]></category>

		<guid isPermaLink="false">http://www.yodaiken.com/?p=215</guid>
		<description><![CDATA[Obama&#8217;s fighting hard to keep his Blackberry President Barack Obama will have a beloved BlackBerry â€” and maybe a second, more secure smartphone-like device â€” with him in the White House. The president has been adamant about continuing to use a BlackBerry, a smartphone with Internet and e-mail access, despite concerns that are likely making [...]]]></description>
			<content:encoded><![CDATA[<p>Obama&#8217;s fighting hard to keep his Blackberry</p>
<blockquote><p>President Barack Obama will have a beloved BlackBerry â€” and maybe a second, more secure smartphone-like device â€” with him in the White House.</p>
<p class="textBodyBlack">The president has been adamant about continuing to use a BlackBerry, a smartphone with Internet and <a class="iAs" style="border-bottom: 0.075em solid darkgreen ! important; font-weight: normal ! important; font-size: 100% ! important; text-decoration: underline ! important; padding-bottom: 1px ! important; color: darkgreen ! important; background-color: transparent ! important;" href="http://www.msnbc.msn.com/id/28780205/#" target="_blank" onclick="pageTracker._trackPageview('/outgoing/www.msnbc.msn.com/id/28780205/?referer=');">e-mail access</a>, despite concerns that are likely making the National Security Agency as nervous as the Secret Service on Inauguration Day when Obama left his presidential limo twice to walk and wave to crowds along Pennsylvania Avenue. <a title="MSNBC article on Obama's phone" href="http://www.msnbc.msn.com/id/28780205/" target="_blank" onclick="pageTracker._trackPageview('/outgoing/www.msnbc.msn.com/id/28780205/?referer=');">MSNBC</a></p>
</blockquote>
]]></content:encoded>
			<wfw:commentRss>http://www.yodaiken.com/2009/01/mobile-device-security-and-president-obama/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Great software patents: fault tolerance</title>
		<link>http://www.yodaiken.com/2009/01/great-software-patents-fault-tolerance/</link>
		<comments>http://www.yodaiken.com/2009/01/great-software-patents-fault-tolerance/#comments</comments>
		<pubDate>Sun, 04 Jan 2009 22:12:00 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[architecture]]></category>
		<category><![CDATA[auragen]]></category>
		<category><![CDATA[data center]]></category>
		<category><![CDATA[intellectual property]]></category>
		<category><![CDATA[security+fault-tolerance]]></category>

		<guid isPermaLink="false">http://www.yodaiken.com/?p=204</guid>
		<description><![CDATA[software patent]]></description>
			<content:encoded><![CDATA[<blockquote><p>A parallel computer system which has a primary task processor, a second      primary task processor, a secondary task processor acting as a backup for      the second primary task processor transfers messages by: sending messages from the primary task processor to the second primary      processor with the second primary task processor operating on the messages      by initially storing a received message in a queue and thereafter reading      the message from the queue for processing in accordance with the task      associated therewith and accumulating a count of the messages read from      its queue; and sending the same messages from the first primary task      processor to the secondary task processor which stores the messages in a      message queue for possible use if the second primary task processor fails.      If a primary task processor fails after processing a given number of      messages, the secondary task processor associated therewith starts      processing the messages in its queue but after having discarded the first      given number of messages.</p></blockquote>
<table border="0" width="100%">
<tbody>
<tr>
<td width="10%" align="left" valign="top">Inventors:</td>
<td width="90%" align="left"><strong><a name="h3" href="http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&amp;Sect2=HITOFF&amp;u=%2Fnetahtml%2FPTO%2Fsearch-adv.htm&amp;r=1&amp;f=G&amp;l=50&amp;d=PTXT&amp;p=1&amp;p=1&amp;S1=%28glazer.INNM.+AND+fault%29&amp;OS=IN/glazer+and+fault&amp;RS=%28IN/glazer+AND+fault%29#h2" onclick="pageTracker._trackPageview('/outgoing/patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2_amp_Sect2=HITOFF_amp_u=_2Fnetahtml_2FPTO_2Fsearch-adv.htm_amp_r=1_amp_f=G_amp_l=50_amp_d=PTXT_amp_p=1_amp_p=1_amp_S1=_28glazer.INNM.+AND+fault_29_amp_OS=IN/glazer+and+fault_amp_RS=_28IN/glazer+AND+fault_29_h2&amp;referer=');"></a><strong><em>Glazer</em></strong>; Sam D.</strong> (New York, NY)<strong>, Baumbach; James</strong> (Brooklyn, NY)<strong>, Borg; Anita</strong> (New York, NY)<strong>, Wittels; Emanuel</strong> (Englewood Cliffs, NJ)</td>
</tr>
<tr>
<td width="10%" align="left" valign="top">Assignee:</td>
<td width="90%" align="left"><strong>Parallel Computers Systems, Inc.</strong> (Fort Lee,  NJ)</td>
</tr>
<tr>
<td width="10%" align="left" valign="top">Appl. No.:</td>
<td width="90%" align="left"><strong> 06/443,937</strong></td>
</tr>
<tr>
<td width="10%" align="left" valign="top">Filed:</td>
<td width="90%" align="left"><strong>November 23, 1982</strong></td>
</tr>
</tbody>
</table>
]]></content:encoded>
			<wfw:commentRss>http://www.yodaiken.com/2009/01/great-software-patents-fault-tolerance/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Updated Dijkstra vs Perlis (really, DeMillo)</title>
		<link>http://www.yodaiken.com/2008/11/updated-dijkstra-vs-perlis-really-demillo/</link>
		<comments>http://www.yodaiken.com/2008/11/updated-dijkstra-vs-perlis-really-demillo/#comments</comments>
		<pubDate>Tue, 25 Nov 2008 14:09:46 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[architecture]]></category>
		<category><![CDATA[security+fault-tolerance]]></category>
		<category><![CDATA[software engineering]]></category>
		<category><![CDATA[software security]]></category>
		<category><![CDATA[dijkstra]]></category>
		<category><![CDATA[formal methods]]></category>
		<category><![CDATA[verification]]></category>

		<guid isPermaLink="false">http://www.yodaiken.com/?p=183</guid>
		<description><![CDATA[See below.]]></description>
			<content:encoded><![CDATA[<p>See <a href="http://www.yodaiken.com/2008/11/dijkstra-versus-perlisdijkstra-versus-perlis/" target="_self">below</a>.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.yodaiken.com/2008/11/updated-dijkstra-vs-perlis-really-demillo/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Dijkstra versus Perlis (updated)</title>
		<link>http://www.yodaiken.com/2008/11/dijkstra-versus-perlis/</link>
		<comments>http://www.yodaiken.com/2008/11/dijkstra-versus-perlis/#comments</comments>
		<pubDate>Mon, 10 Nov 2008 17:00:51 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[security+fault-tolerance]]></category>
		<category><![CDATA[software engineering]]></category>
		<category><![CDATA[software security]]></category>
		<category><![CDATA[demillo]]></category>
		<category><![CDATA[dijkstra]]></category>
		<category><![CDATA[formal methods]]></category>
		<category><![CDATA[perlis]]></category>
		<category><![CDATA[verification]]></category>

		<guid isPermaLink="false">http://www.yodaiken.com/?p=175</guid>
		<description><![CDATA[Here&#8217;s Dijkstra He [Perlis] published a very obnoxious paper arguing against a mathematical approach to programming cite Here&#8217;s the paper by De Millo, Lipton and Perlis. It starts as follows: Many people have argued that computer programming should strive to become more like mathematics. Maybe so, but not in the way they seem to think. [...]]]></description>
			<content:encoded><![CDATA[<p>Here&#8217;s Dijkstra</p>
<blockquote><p><em>He [Perlis] published a very obnoxious paper arguing against a mathematical approach to programming</em> <a title="Perlis" href="http://www.cbi.umn.edu/oh/pdf.phtml?id=296" onclick="pageTracker._trackPageview('/outgoing/www.cbi.umn.edu/oh/pdf.phtml?id=296&amp;referer=');">cite</a></p></blockquote>
<p><a title="de_millo paper" href="http://www.yodaiken.com/papers/p271-de_millo.pdf">Here&#8217;s</a> the paper by De Millo, Lipton and Perlis. It starts as follows:</p>
<blockquote><p>Many people have argued that computer programming should strive to become more like mathematics. Maybe so, but not in the way they seem to think. The aim of program verification, an attempt to make programming more mathematics-like, is to increase dramatically one&#8217;s confidence in the correct functioning of a piece of software, and the device that verifiers use to achieve this goal is a long chain of formal, deductive logic. In mathematics, the aim is to increase one&#8217;s confidence in the correctness of a theorem, and it&#8217;s true that one of the devices mathematicians could in theory use to achieve this goal is a long chain of formal logic. But in fact they don&#8217;t. What they use is a proof, a very different animal. Nor does the proof settle the matter; contrary to what its name suggests, a proof is only one step in the direction of confidence. We believe that, in the end, it is a social process that determines whether mathematicians feel confident about a theorem&#8211;and we believe that, because no comparable social process can take place among program verifiers, program verification is bound to fail.</p></blockquote>
<p>To me, the problem with Dijkstra is that he was so sharp and such a good writer that he was able to make persuasive cases out of wrong ideas. Dijkstra wanted to be a scientist in the model of theoretical physics, not an engineer. I&#8217;m pretty confident that Dijkstra was wrong: programming is engineering &#8211; in fact, physics is not as far from engineering as some people would like to believe. I&#8217;m not a huge fan of the engineering discipline as it exists in the USA. It has all sorts of negative aspects &#8211; including those Dijkstra railed against. But the vision of a programmer as, not a mathematician, but a formal logician flying far above the grubby compromises and trade-offs of mere engineering in a platonic bubble of pure reasoning is wrongheaded.</p>
<p>Dijkstra published some criticism of the Demillo paper at the time and <a title="ACM link to discussion " href="http://portal.acm.org/citation.cfm?id=1005888.1005891" target="_blank" onclick="pageTracker._trackPageview('/outgoing/portal.acm.org/citation.cfm?id=1005888.1005891&amp;referer=');">in their response</a> the authors stated something that, as far as I know, remains true</p>
<blockquote><p>We must begin by refusing to concede that our confidence in a piece of<br />
real software has ever been increased by a proof of its correctness</p></blockquote>
<p>When I was in graduate school, a famous formal methods scholar came for a talk and explained to us that formal methods were needed if we were ever going to develop fault tolerant software. I pointed out that, for example, the Tandem Software worked pretty well in practice. &#8220;It cannot&#8221;, retorted the famous scholar.</p>
<p>So there.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.yodaiken.com/2008/11/dijkstra-versus-perlis/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>future of the data center</title>
		<link>http://www.yodaiken.com/2008/10/future-of-the-data-center/</link>
		<comments>http://www.yodaiken.com/2008/10/future-of-the-data-center/#comments</comments>
		<pubDate>Thu, 16 Oct 2008 07:48:44 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[architecture]]></category>
		<category><![CDATA[communications]]></category>
		<category><![CDATA[data center]]></category>
		<category><![CDATA[operating systems]]></category>
		<category><![CDATA[security+fault-tolerance]]></category>
		<category><![CDATA[software security]]></category>
		<category><![CDATA[distributed data]]></category>
		<category><![CDATA[power use]]></category>
		<category><![CDATA[virtualization]]></category>

		<guid isPermaLink="false">http://www.yodaiken.com/?p=172</guid>
		<description><![CDATA[This article from Ars Technica discusses a talk over the summer by Merrill Lynch&#8217;s chief technology architect, Jeffrey Birnbaum on &#8220;stateless cloud computing&#8221; &#8211; most concretely on distributed file systems. Birnbaum believes that one of the key foundational elements of a stateless computing environment is a networked storage system that enables ubiquitous availability of software. [...]]]></description>
			<content:encoded><![CDATA[<p>This <a title="ars tecnica article on birnbaum" href="http://arstechnica.com/news.ars/post/20080806-stateless-computing-the-future-of-the-cloud.html" target="_blank" onclick="pageTracker._trackPageview('/outgoing/arstechnica.com/news.ars/post/20080806-stateless-computing-the-future-of-the-cloud.html?referer=');">article </a>from Ars Technica discusses a talk over the summer by Merrill Lynch&#8217;s chief technology architect, Jeffrey Birnbaum on &#8220;stateless cloud computing&#8221; &#8211; most concretely on distributed file systems.</p>
<blockquote><p><em>Birnbaum believes that one of the key foundational elements of a stateless computing environment is a networked storage system that enables ubiquitous availability of software. The file paths of the individual applications should be based on clearly defined nomenclature, much like the domain of a web site. All application dependencies should be accessible through the network filesystem, and version numbers should be expressed with the path nomenclature. </em></p></blockquote>
<p>Big distributed file system &#8211; sure. Why should version numbers be expressed with the path nomenclature (a Plan9 idea, btw)?Â  Now we go on to the ancient problem of caching distributed data.</p>
<blockquote><p><em>The obvious challenge posed by rolling out worldwide network storage infrastructure is scalability. If everyone in a global organization is depending on a network storage solution, then it needs to be fast and consistently reliable. The solution that Birnbaum proposes is regional mirroring and caching. The storage system would be universally synchronized between mirrors that have all the data. Caching can also be used at individual facilities to further improve performance. To achieve this kind of global scalability, he says, the best approach is similar to that of Akamai. </em></p></blockquote>
<p>So even with a non-globally distributed file system, the problem of shared access is non-trivial. A global file system makes things quite challenging. Suppose we have a file recording trades and the Singapore, London, NY, and Espanola main offices all are reading and writing at the same time. Caching and cache coherency is an utter nightmare.Â  Akamai, like Google, solves the problem of massive amounts of distributed data by focusing on &#8220;delivery&#8221; &#8211; otherwise known as &#8220;read only content&#8221; or &#8220;many readers one writer&#8221; and with no requirement for true synchronization.Â  But the ML problem is more difficult even if we ignore multiple writers because, presumably, you want Singapore to actually see every trade made in Espanola even though for Akamai, it&#8217;s ok if the cache is not fresh. How to solve multiple readers and writers is something else as well.</p>
<blockquote><p><em>These concepts don&#8217;t cover a whole lot of new ground yet. Much of this was already possible with conventional thin-client systems. The point at which it becomes immensely valuable, according to Birnbaum, is when all of these technologies are used together with virtualization to abstract the processes away from the hardware. Once this is done, individual operations can seamlessly float around data centers and balance out in a manner that offers a more optimal level of resource utilization. </em></p></blockquote>
<p>And this seems to me to gloss over the even harder problem. Imagine a serious Oracle application &#8220;seamlessly floating&#8221; from some set of machines in one data-center to another set.Â  I can&#8217;t imagine how that works. Imagining little jobs floating is easier, but is that really an interesting problem? And this brings us to the most interesting claim:</p>
<blockquote><p><em>He claims that 61 percent of a company&#8217;s enterprise server capacity goes completely unused and proposes an automated load balancing solutionâ€”</em></p></blockquote>
<p>SIXTY ONE PERCENT!Â  Think of the power use.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.yodaiken.com/2008/10/future-of-the-data-center/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Reliable broadcast algorithms: after 20 years</title>
		<link>http://www.yodaiken.com/2008/10/reliable-broadcast-algorithms-after-20-years/</link>
		<comments>http://www.yodaiken.com/2008/10/reliable-broadcast-algorithms-after-20-years/#comments</comments>
		<pubDate>Sun, 05 Oct 2008 13:34:08 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[communications]]></category>
		<category><![CDATA[security+fault-tolerance]]></category>
		<category><![CDATA[chang]]></category>
		<category><![CDATA[reliable broadcast]]></category>
		<category><![CDATA[verfication]]></category>

		<guid isPermaLink="false">http://www.yodaiken.com/?p=168</guid>
		<description><![CDATA[New paper with short description of the Chang/Maxmchuk algorithm I have been championing for 20 years or more.]]></description>
			<content:encoded><![CDATA[<p>New <a title="Reliable network broadcast protocols paper" href="http://www.yodaiken.com/papers/chang.pdf" target="_blank">paper</a> with short description of the Chang/Maxmchuk algorithm I have been championing for 20 years or more.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.yodaiken.com/2008/10/reliable-broadcast-algorithms-after-20-years/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>SCADA system security in the internet era</title>
		<link>http://www.yodaiken.com/2008/09/scada-system-security-in-the-internet-era/</link>
		<comments>http://www.yodaiken.com/2008/09/scada-system-security-in-the-internet-era/#comments</comments>
		<pubDate>Sun, 28 Sep 2008 01:04:23 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[security+fault-tolerance]]></category>
		<category><![CDATA[software business]]></category>
		<category><![CDATA[software engineering]]></category>
		<category><![CDATA[hatch nuclear plant]]></category>
		<category><![CDATA[nuclear power]]></category>
		<category><![CDATA[SCADA]]></category>
		<category><![CDATA[software error]]></category>

		<guid isPermaLink="false">http://www.yodaiken.com/?p=166</guid>
		<description><![CDATA[This Washinton Post article on a SCADA failure at a US nuclear power plant was noted in Slashdot, but not much elsewhere. Specifically, experts worry that vulnerabilities were introduced into the systems that regulate the electrical grid as power companies transferred control of generation and distribution equipment from internal networks to supervisory control and data [...]]]></description>
			<content:encoded><![CDATA[<p>This Washinton Post article on a <a title="WP article on Hatch failure" href="http://www.washingtonpost.com/wp-dyn/content/article/2008/06/05/AR2008060501958.html" target="_blank" onclick="pageTracker._trackPageview('/outgoing/www.washingtonpost.com/wp-dyn/content/article/2008/06/05/AR2008060501958.html?referer=');">SCADA failure at a US nuclear power plant</a> was noted in <a title="slashdot article" href="http://tech.slashdot.org/article.pl?sid=08/06/06/2235233&amp;from=rss" target="_blank" onclick="pageTracker._trackPageview('/outgoing/tech.slashdot.org/article.pl?sid=08/06/06/2235233_amp_from=rss&amp;referer=');">Slashdot,</a> but not much elsewhere.</p>
<blockquote><p>Specifically, experts worry that vulnerabilities were introduced into the systems that regulate the electrical grid as power companies transferred control of generation and distribution equipment from internal networks to supervisory control and data acquisition, or SCADA, systems that can be accessed through the Internet or by phone lines, according to consultants and government reports.</p></blockquote>
<p>The article also discusses an earlier nuclear power plant software failure caused by message overload when two pumps failed.Â  The fundamental problem is that SCADA software is being written to two very different but completely inadequate standards: standards coming from the embedded software business where software is still an afterthought and standards coming from the PC/Server world where functionality is king and security/time-guarantees/robustness etc. are competing for a distant second place.</p>
<p>As we move into an era where there are many distributed power sources connected to the grid, and where machinery that uses power does so under ever more sophisticated software control, the potential for cascading failures is quite real and unanticipated interactions between business software and control software is one good source of failure injection.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.yodaiken.com/2008/09/scada-system-security-in-the-internet-era/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
