<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	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/"
		>
<channel>
	<title>Comments on: Why we&#8217;re getting vertical &#8211; again</title>
	<atom:link href="http://storagemojo.com/2009/05/18/why-were-getting-vertical-again/feed/" rel="self" type="application/rss+xml" />
	<link>http://storagemojo.com/2009/05/18/why-were-getting-vertical-again/</link>
	<description>Data storage info &#38; analysis</description>
	<lastBuildDate>Tue, 07 Feb 2012 16:02:02 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Pete Steege</title>
		<link>http://storagemojo.com/2009/05/18/why-were-getting-vertical-again/comment-page-1/#comment-201802</link>
		<dc:creator>Pete Steege</dc:creator>
		<pubDate>Thu, 21 May 2009 17:58:08 +0000</pubDate>
		<guid isPermaLink="false">http://storagemojo.com/?p=1352#comment-201802</guid>
		<description>Great post Robin.  I think the chum is in the high end waters, but not so much in mainstream IT.  The proprietary approach works well for clouds, mega data centers and single sourcers.  Not so well for your average IT shop that&#039;s got a bunch of stuff they have to keep working.</description>
		<content:encoded><![CDATA[<p>Great post Robin.  I think the chum is in the high end waters, but not so much in mainstream IT.  The proprietary approach works well for clouds, mega data centers and single sourcers.  Not so well for your average IT shop that&#8217;s got a bunch of stuff they have to keep working.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Rex</title>
		<link>http://storagemojo.com/2009/05/18/why-were-getting-vertical-again/comment-page-1/#comment-201738</link>
		<dc:creator>Rex</dc:creator>
		<pubDate>Wed, 20 May 2009 19:27:40 +0000</pubDate>
		<guid isPermaLink="false">http://storagemojo.com/?p=1352#comment-201738</guid>
		<description>Robin,
What&#039;s your take on how the 3 GHz/core wall, and multi-core CPUs might affect vertical integration?  Old apps won&#039;t get automatically faster by moving to new hardware, so there might be some incentive to rework old apps to make them more efficient, or rewrite old apps to use multi-core CPUs.  New apps that need lots more speed through multi-core CPUs will be very expensive to develop -- especially since this is an open research problem.  Some apps simply can&#039;t take advantage of multi-core CPUs and might require radical re-thinking.  

Similar issues come up with disk and RAM I/O bottlenecks.

-- Rex</description>
		<content:encoded><![CDATA[<p>Robin,<br />
What&#8217;s your take on how the 3 GHz/core wall, and multi-core CPUs might affect vertical integration?  Old apps won&#8217;t get automatically faster by moving to new hardware, so there might be some incentive to rework old apps to make them more efficient, or rewrite old apps to use multi-core CPUs.  New apps that need lots more speed through multi-core CPUs will be very expensive to develop &#8212; especially since this is an open research problem.  Some apps simply can&#8217;t take advantage of multi-core CPUs and might require radical re-thinking.  </p>
<p>Similar issues come up with disk and RAM I/O bottlenecks.</p>
<p>&#8211; Rex</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Walter</title>
		<link>http://storagemojo.com/2009/05/18/why-were-getting-vertical-again/comment-page-1/#comment-201734</link>
		<dc:creator>Walter</dc:creator>
		<pubDate>Wed, 20 May 2009 18:20:51 +0000</pubDate>
		<guid isPermaLink="false">http://storagemojo.com/?p=1352#comment-201734</guid>
		<description>Robin,

This is analogus to predator prey systems and such complex systems are unstable and oscillate . 

Walter</description>
		<content:encoded><![CDATA[<p>Robin,</p>
<p>This is analogus to predator prey systems and such complex systems are unstable and oscillate . </p>
<p>Walter</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dmitry Afanasiev</title>
		<link>http://storagemojo.com/2009/05/18/why-were-getting-vertical-again/comment-page-1/#comment-201715</link>
		<dc:creator>Dmitry Afanasiev</dc:creator>
		<pubDate>Wed, 20 May 2009 11:05:52 +0000</pubDate>
		<guid isPermaLink="false">http://storagemojo.com/?p=1352#comment-201715</guid>
		<description>Jerry,  
TCP (actually, whole TCP/IP stack) has it&#039;s share of problems and some future competition is probably already here. Next 5-10 years are going to be very interesting:
- location/ID split.  How about endpoint based mobility and multihoming?  Process migration across L2 domains and increased availability through connections to multiple providers without pain of BGP may become easy  - should be very relevant to everything cloud. Just don&#039;t  forget about another layer of indirection and ID lookup.
- IPv4 addresses are runnig out, but there is no decent solution for interoperability  between v4 only and v6 only hosts so far.
- DNS is still the name resolution protocol for the Internet, but DHT is finding more and more applications.
- IETF is working on congestion control protocol for background transfers, and Bittorent Inc is actively involved: &lt;a href=&quot;http://tools.ietf.org/wg/ledbat/&quot; rel=&quot;nofollow&quot;&gt;.</description>
		<content:encoded><![CDATA[<p>Jerry,<br />
TCP (actually, whole TCP/IP stack) has it&#8217;s share of problems and some future competition is probably already here. Next 5-10 years are going to be very interesting:<br />
- location/ID split.  How about endpoint based mobility and multihoming?  Process migration across L2 domains and increased availability through connections to multiple providers without pain of BGP may become easy  &#8211; should be very relevant to everything cloud. Just don&#8217;t  forget about another layer of indirection and ID lookup.<br />
- IPv4 addresses are runnig out, but there is no decent solution for interoperability  between v4 only and v6 only hosts so far.<br />
- DNS is still the name resolution protocol for the Internet, but DHT is finding more and more applications.<br />
- IETF is working on congestion control protocol for background transfers, and Bittorent Inc is actively involved: <a href="http://tools.ietf.org/wg/ledbat/" rel="nofollow">.</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jerry Leichter</title>
		<link>http://storagemojo.com/2009/05/18/why-were-getting-vertical-again/comment-page-1/#comment-201692</link>
		<dc:creator>Jerry Leichter</dc:creator>
		<pubDate>Wed, 20 May 2009 01:04:14 +0000</pubDate>
		<guid isPermaLink="false">http://storagemojo.com/?p=1352#comment-201692</guid>
		<description>There&#039;s another side to this great cycle:  Many decisions that seemed fixed for a decade or more are open to debate again.

For quite some time, it was clear that *the* OS was Windows (in most uses) and some Unix variant in a few others.  Now, Windows is under attack in its areas of greatest strength from Mac OS.  Virtual machines running on bare metal - with the OS just some kind of funny application layer - are a whole new alternative.  Even Microsoft&#039;s research organization is going public with an incompatible post-Windows OS.

It was &quot;settled&quot; that strongly typed languages were the way of the future, and Java was the answer to every programming question  - except in certain specialized areas where C/C++ were the answer, and of course for the Microsoft specialists, there was always C# (larger in actual use than its mind share).  Now, for many application areas, Ruby and Python and other weakly-typed languages have taken over.  Even functional languages are making a comeback as actual, practical programming tools.

Depending on whether you were lower-end Unix, Windows, or very high end, you accessed remote files with NFS, CIFS, or an FC SAN.  That&#039;s all becoming mixed up now, with iSCSI as the new guy on the block, competing with all three.

The x86 architecture so far continues to reign supreme, but ARM is a viable alternative - and the two are overlapping, which never happened before.  For the first time in years, many applications need to worry about portability to multiple architectures.  (There have been rumors about an ARM port of Windows.  They don&#039;t make a whole load of sense, but it&#039;s hard to imagine anyone even bother to repeat such a rumor a couple of years back.)  Beyond that, the emergence of GPU&#039;s as general-purpose programming resources also destroys the &quot;everything is an x86&quot; mindset.

The outlier here is networking, where we are still seeing convergence of distinct technologies.  If you think about it, why do we have USB, Ethernet, WiFi, Bluetooth, FC, Firewire?  Yes, they all differ in some important characteristics - but those increasingly overlap.   The newest Bluetooth will shift over to WiFi-style connections for large transfers.  Firewire is likely fading.  Ethernet will kill FC.  So at these levels, networking is in the convergence phase, not the new divergence.  On the other hand, TCP still has no challengers.  My prediction:  It *will* see competition.  It&#039;s impossible to say exactly where and how - but it would be very odd if TCP were a unique, eternal fixed point with everything below and above it changing.</description>
		<content:encoded><![CDATA[<p>There&#8217;s another side to this great cycle:  Many decisions that seemed fixed for a decade or more are open to debate again.</p>
<p>For quite some time, it was clear that *the* OS was Windows (in most uses) and some Unix variant in a few others.  Now, Windows is under attack in its areas of greatest strength from Mac OS.  Virtual machines running on bare metal &#8211; with the OS just some kind of funny application layer &#8211; are a whole new alternative.  Even Microsoft&#8217;s research organization is going public with an incompatible post-Windows OS.</p>
<p>It was &#8220;settled&#8221; that strongly typed languages were the way of the future, and Java was the answer to every programming question  &#8211; except in certain specialized areas where C/C++ were the answer, and of course for the Microsoft specialists, there was always C# (larger in actual use than its mind share).  Now, for many application areas, Ruby and Python and other weakly-typed languages have taken over.  Even functional languages are making a comeback as actual, practical programming tools.</p>
<p>Depending on whether you were lower-end Unix, Windows, or very high end, you accessed remote files with NFS, CIFS, or an FC SAN.  That&#8217;s all becoming mixed up now, with iSCSI as the new guy on the block, competing with all three.</p>
<p>The x86 architecture so far continues to reign supreme, but ARM is a viable alternative &#8211; and the two are overlapping, which never happened before.  For the first time in years, many applications need to worry about portability to multiple architectures.  (There have been rumors about an ARM port of Windows.  They don&#8217;t make a whole load of sense, but it&#8217;s hard to imagine anyone even bother to repeat such a rumor a couple of years back.)  Beyond that, the emergence of GPU&#8217;s as general-purpose programming resources also destroys the &#8220;everything is an x86&#8243; mindset.</p>
<p>The outlier here is networking, where we are still seeing convergence of distinct technologies.  If you think about it, why do we have USB, Ethernet, WiFi, Bluetooth, FC, Firewire?  Yes, they all differ in some important characteristics &#8211; but those increasingly overlap.   The newest Bluetooth will shift over to WiFi-style connections for large transfers.  Firewire is likely fading.  Ethernet will kill FC.  So at these levels, networking is in the convergence phase, not the new divergence.  On the other hand, TCP still has no challengers.  My prediction:  It *will* see competition.  It&#8217;s impossible to say exactly where and how &#8211; but it would be very odd if TCP were a unique, eternal fixed point with everything below and above it changing.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

