<?xml version="1.0" encoding="UTF-8"?>

<rdf:RDF 
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns="http://purl.org/rss/1.0/"
  xmlns:dc="http://purl.org/dc/elements/1.1/"
  xmlns:syn="http://purl.org/rss/1.0/modules/syndication/"
>

  <channel rdf:about="http://lwn.net/headlines/248878/">
    <title>LWN: Comments on "KS2007: The customer panel"</title>
    <link>http://lwn.net/Articles/248878/</link>
    <description>
This is a special feed containing comments posted
to the individual LWN article titled &quot;KS2007: The customer panel&quot;.

    </description>

    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>2</syn:updateFrequency>
    <items>
      <rdf:Seq>
	<rdf:li resource="http://lwn.net/Articles/250650/rss" />
	<rdf:li resource="http://lwn.net/Articles/249314/rss" />
	<rdf:li resource="http://lwn.net/Articles/249117/rss" />
	<rdf:li resource="http://lwn.net/Articles/249047/rss" />
	<rdf:li resource="http://lwn.net/Articles/248973/rss" />
	<rdf:li resource="http://lwn.net/Articles/248913/rss" />
	<rdf:li resource="http://lwn.net/Articles/248909/rss" />
	<rdf:li resource="http://lwn.net/Articles/248902/rss" />
	<rdf:li resource="http://lwn.net/Articles/248899/rss" />
      
      </rdf:Seq>
    </items>

  </channel>
    <item rdf:about="http://lwn.net/Articles/250650/rss">
      <title>KS2007: The customer panel</title>
      <link>http://lwn.net/Articles/250650/rss</link>
      <dc:date>2007-09-20T11:05:00+00:00</dc:date>
      <dc:creator>renox</dc:creator>
      <description>
      About the need to send quicky small packets: we have a similar need in my company for redondancy purpose (pinging other computer to ensure that they are working): a 40ms delay is a lot (we're not using TCP though to do this but UDP, and we're still in 2.4, so I don't know if in 2.6 we would have the same issue of not).&lt;br&gt;
&lt;p&gt;
About the 'swap prefetch', it's sad how it was rejected out of the kernel as kernel dev saw no need of this feature: here's a customer complaining, maybe kernel devs will change their mind (though it would need a new maintainer..).&lt;br&gt;
      
      </description>
    </item>
    <item rdf:about="http://lwn.net/Articles/249314/rss">
      <title>Dreamworks</title>
      <link>http://lwn.net/Articles/249314/rss</link>
      <dc:date>2007-09-12T01:13:56+00:00</dc:date>
      <dc:creator>landley</dc:creator>
      <description>
      There are historical reasons as well.  Don't forget that Silicon Graphics &lt;br&gt;
was a Unix shop (VAX through Irix), and SGI discontinued Irix in favor of &lt;br&gt;
Linux at the start of the decade.&lt;br&gt;
      
      </description>
    </item>
    <item rdf:about="http://lwn.net/Articles/249117/rss">
      <title>Dreamworks</title>
      <link>http://lwn.net/Articles/249117/rss</link>
      <dc:date>2007-09-10T23:52:46+00:00</dc:date>
      <dc:creator>pr1268</dc:creator>
      <description>
      &lt;p&gt;&lt;font class=&quot;QuotedText&quot;&gt;&amp;gt; They don't use Linux because it's Free Software, they use it because it's free software.&lt;/font&gt;&lt;/p&gt;

&lt;p&gt;That's an interesting perspective.  It didn't initially occur to me that Dreamworks' server farms of thousands of computers would pose an enormous expense just for the operating system licensing alone, had they decided to use a proprietary OS.  Not to mention that certain OSes charge license fees based on the number of physical CPUs per server, or by the number of incoming connections (I won't mention any names).&lt;/p&gt;

      
      </description>
    </item>
    <item rdf:about="http://lwn.net/Articles/249047/rss">
      <title>KS2007: The customer panel</title>
      <link>http://lwn.net/Articles/249047/rss</link>
      <dc:date>2007-09-10T18:39:49+00:00</dc:date>
      <dc:creator>garloff</dc:creator>
      <description>
      I'm glad someone found /proc/$PID/oom_adj.&lt;br&gt;
      
      </description>
    </item>
    <item rdf:about="http://lwn.net/Articles/248973/rss">
      <title>Dreamworks</title>
      <link>http://lwn.net/Articles/248973/rss</link>
      <dc:date>2007-09-10T13:20:30+00:00</dc:date>
      <dc:creator>joedrew</dc:creator>
      <description>
      &lt;p&gt;I work in the &lt;a href=&quot;http://www.sidefx.com&quot;&gt;3D animation business&lt;/a&gt;, so Dreamworks' presentation isn't surprising to me. For those who don't know, it's not just Dreamworks that runs Linux -- it's the entire 3D animation industry. Sony Pictures Imageworks, Digital Domain, Dreamworks, Disney, etc. All large studios run Linux. (And they're the &lt;em&gt;real&lt;/em&gt; reason that companies like NVIDIA and AMD have had good, but proprietary, 3D drivers for so long -- there's &lt;em&gt;huge&lt;/em&gt; money in the high-end professional market.)&lt;/p&gt;

&lt;p&gt;Their apparent lack of technical knowledge isn't surprising, though. Their core competency isn't Linux, it's 3D, and so they spend their R&amp;amp;D budget on that. They don't use Linux because it's Free Software, they use it because it's free software. (Its capabilities help too.) That's a good thing, though -- 3D animation companies are a huge user of Linux, but they're a user of Linux that tends much more towards the &quot;Aunt Mae&quot; than the usual user of Linux.&lt;/p&gt;
      
      </description>
    </item>
    <item rdf:about="http://lwn.net/Articles/248913/rss">
      <title>Nagle and Credit Suisse</title>
      <link>http://lwn.net/Articles/248913/rss</link>
      <dc:date>2007-09-09T13:36:52+00:00</dc:date>
      <dc:creator>corbet</dc:creator>
      <description>
      They &lt;i&gt;do&lt;/i&gt; disable Nagle and do just about everything else they can possibly think of.  But they still run into problems.
      
      </description>
    </item>
    <item rdf:about="http://lwn.net/Articles/248909/rss">
      <title>Nagle and Credit Suisse</title>
      <link>http://lwn.net/Articles/248909/rss</link>
      <dc:date>2007-09-09T08:32:42+00:00</dc:date>
      <dc:creator>gdt</dc:creator>
      <description>
      &lt;p&gt;Did Credit Suisse say why their application does not disable the Nagle algorithm using the TCP_NODELAY socket option?  If the application source is not available then they can write a Netfilter module to set the socket option (I wrote a similar module to select the TCP algorithm for binary programs, I owe the netdev people a similar patch which uses the routing table).&lt;/p&gt;
      
      </description>
    </item>
    <item rdf:about="http://lwn.net/Articles/248902/rss">
      <title>KS2007: The customer panel</title>
      <link>http://lwn.net/Articles/248902/rss</link>
      <dc:date>2007-09-09T05:14:07+00:00</dc:date>
      <dc:creator>NCunningham</dc:creator>
      <description>
      +1. I just about habitually tell TuxOnIce users to apply it when they're trying to diagnose problems with hibernation. It's pretty useful for finding out which driver is stopping them from successfully hibernating. (It doesn't help in all circumstances, but it does in a good proportion).&lt;br&gt;
      
      </description>
    </item>
    <item rdf:about="http://lwn.net/Articles/248899/rss">
      <title>KS2007: The customer panel</title>
      <link>http://lwn.net/Articles/248899/rss</link>
      <dc:date>2007-09-09T01:40:22+00:00</dc:date>
      <dc:creator>linuxbox</dc:creator>
      <description>
      Is no one really sure why people ask for an integrated kernel debugger?  I value KDB a great deal.  I regularly patch it into mainline kernels.  I'm obviously not alone.&lt;br&gt;
      
      </description>
    </item>
</rdf:RDF>

