<?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/211152/">
    <title>LWN: Comments on "Fedora considers user metrics"</title>
    <link>http://lwn.net/Articles/211152/</link>
    <description>
This is a special feed containing comments posted
to the individual LWN article titled &quot;Fedora considers user metrics&quot;.

    </description>

    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>2</syn:updateFrequency>
    <items>
      <rdf:Seq>
	<rdf:li resource="http://lwn.net/Articles/212156/rss" />
	<rdf:li resource="http://lwn.net/Articles/212062/rss" />
	<rdf:li resource="http://lwn.net/Articles/212054/rss" />
	<rdf:li resource="http://lwn.net/Articles/211752/rss" />
	<rdf:li resource="http://lwn.net/Articles/211295/rss" />
      
      </rdf:Seq>
    </items>

  </channel>
    <item rdf:about="http://lwn.net/Articles/212156/rss">
      <title>Fedora considers user metrics</title>
      <link>http://lwn.net/Articles/212156/rss</link>
      <dc:date>2006-11-30T23:14:13+00:00</dc:date>
      <dc:creator>dmarti</dc:creator>
      <description>
      For an ideal Linux distribution, the set of all users would be a subset of the subscriber list for the Really Important Security Alerts mailing list.  Installers should probably be doing more to encourage users to subscribe to such lists.&lt;br&gt;
&lt;p&gt;
Does Fedora use the Red Hat NTP servers by default?  That's another place to look for &quot;light up&quot; data.&lt;br&gt;
&lt;p&gt;
Ubuntu's hardware compatibility report would be another interesting thing to look at.&lt;br&gt;
&lt;p&gt;
&lt;p&gt;
      
      </description>
    </item>
    <item rdf:about="http://lwn.net/Articles/212062/rss">
      <title>Fedora considers user metrics</title>
      <link>http://lwn.net/Articles/212062/rss</link>
      <dc:date>2006-11-30T16:53:48+00:00</dc:date>
      <dc:creator>pjones</dc:creator>
      <description>
      &lt;blockquote&gt;&lt;i&gt;Actually I think that at least that 'PPC debugging' is pretty bad example.&lt;br&gt;
&lt;br&gt;
Look at this way.. In a linux distribution there realy isn't much that is very hardware dependent. Aside from endian issues not many people need to be terribly concerned about weither their software runs on x86 vs PPC vs Arm or whatnot unless they are trying to tricks to improve performance.&lt;/i&gt;&lt;/blockquote&gt;
As one of the developers who spends way more time debugging PPC machines than he'd like, I completely, totally disagree.  These type of bugs aren't just endian issues or the like.  They're &quot;this driver is only on this platform&quot;, or &quot;the bootloader doesn't work right on this machine&quot;.  There are also bugs that exist on other platforms, but which only get *seen* on some architectures, for various reasons.  For FC5, for example, allocating a new tty while using fbcon caused the console's color palette to be reset -- this was a serious installation issue that took a not-insignificant amount of time.&lt;br&gt;
&lt;br&gt;
There are *plenty* of 'only this one platform' types of bugs, and they take a lot of time.  So no, it's not really a poor example.
      
      </description>
    </item>
    <item rdf:about="http://lwn.net/Articles/212054/rss">
      <title>Fedora considers user metrics</title>
      <link>http://lwn.net/Articles/212054/rss</link>
      <dc:date>2006-11-30T16:31:17+00:00</dc:date>
      <dc:creator>dvdeug</dc:creator>
      <description>
      There's a lot of things that could be bugs on one system but not on another. Little-endian versus big-endian issues and data sizes aren't going to suddenly change on one system, but will be problems on other systems. To port a lot of modern software to a computer with decimal numbers or 36-bit words would be very hard and not improve the system one bit. Similar if lesser difficulties would be involved in porting code to a 128-bit system, which is entirely plausible, and that work would improve the code not one bit.&lt;br&gt;
      
      </description>
    </item>
    <item rdf:about="http://lwn.net/Articles/211752/rss">
      <title>Fedora considers user metrics</title>
      <link>http://lwn.net/Articles/211752/rss</link>
      <dc:date>2006-11-29T15:13:01+00:00</dc:date>
      <dc:creator>bilzinho</dc:creator>
      <description>
      I just went to the Fedora page in question and the string &quot;PPC&quot; appears to have been replaced by &quot;x86_64&quot;&lt;br&gt;
      
      </description>
    </item>
    <item rdf:about="http://lwn.net/Articles/211295/rss">
      <title>Fedora considers user metrics</title>
      <link>http://lwn.net/Articles/211295/rss</link>
      <dc:date>2006-11-27T22:51:24+00:00</dc:date>
      <dc:creator>drag</dc:creator>
      <description>
      Actually I think that at least that 'PPC debugging' is pretty bad example.&lt;br&gt;
&lt;p&gt;
Look at this way.. In a linux distribution there realy isn't much that is very hardware dependent. Aside from endian issues not many people need to be terribly concerned about weither their software runs on x86 vs PPC vs Arm or whatnot unless they are trying to tricks to improve performance.&lt;br&gt;
&lt;p&gt;
So if bugs crop up on a PPC platfrom that don't appear on a x86 version still means that more then likely that x86 version still has the bug. It just has not come up for some reason.&lt;br&gt;
&lt;p&gt;
So if you get the bug that is exposed in a recompile for a different platform then that is just one less bug that is going to come around and bite you in the rear later on.&lt;br&gt;
&lt;p&gt;
I don't know about other people, but I have a PPC Linux computer and almost without exception the best and most bug free software has been stuff that runs on both my x86 and PPC computer equaly well. When stuff hasn't been aviable for my PPC laptop and I tried to use it on the x86 then almost all the time nasty bugs crop up.&lt;br&gt;
&lt;p&gt;
&lt;p&gt;
Another example.&lt;br&gt;
&lt;p&gt;
Say back in in the 2.5 kernel days the kernel developers used metrics to gauge weither or not it was important to have the kernel work well on more then 4 cpus.&lt;br&gt;
&lt;p&gt;
So if they based their decisions on metrics... How many people were actually running Linux on systems with more then 2 or 4 cpus?&lt;br&gt;
&lt;p&gt;
So it would of been obvious through metrics that it's not worth it to redo the scedualer and make it scale above 8 cpus as there was nearly no-one actually using machines like that. It would of been a waste...&lt;br&gt;
&lt;p&gt;
but nowadays, obviously, more people are running more cpus. In another year and half it will be as cheap for people to run 8 cpus (cores) as it was to run a SMP machine back in 2001. So obviously making sure Linux scaled well was a good move, but it would of been non-obvious if you depended on metrics.&lt;br&gt;
&lt;p&gt;
Although I am not saying that it's not worth doing metrics, of course. It can be very usefull. Just that it can be very misleading also.&lt;br&gt;
      
      </description>
    </item>
</rdf:RDF>

