<?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/168225/">
    <title>LWN: Comments on "What's New in Fedora Core 5 Test2"</title>
    <link>http://lwn.net/Articles/168225/</link>
    <description>
This is a special feed containing comments posted
to the individual LWN article titled &quot;What's New in Fedora Core 5 Test2&quot;.

    </description>

    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>2</syn:updateFrequency>
    <items>
      <rdf:Seq>
	<rdf:li resource="http://lwn.net/Articles/168884/rss" />
	<rdf:li resource="http://lwn.net/Articles/168761/rss" />
	<rdf:li resource="http://lwn.net/Articles/168510/rss" />
	<rdf:li resource="http://lwn.net/Articles/168496/rss" />
	<rdf:li resource="http://lwn.net/Articles/168424/rss" />
	<rdf:li resource="http://lwn.net/Articles/168347/rss" />
	<rdf:li resource="http://lwn.net/Articles/168340/rss" />
      
      </rdf:Seq>
    </items>

  </channel>
    <item rdf:about="http://lwn.net/Articles/168884/rss">
      <title>What's New in Fedora Core 5 Test2</title>
      <link>http://lwn.net/Articles/168884/rss</link>
      <dc:date>2006-01-23T21:40:30+00:00</dc:date>
      <dc:creator>roelofs</dc:creator>
      <description>
      &lt;FONT COLOR=&quot;#440088&quot;&gt;&lt;I&gt;My first thought is, who cares if you like it or not? Tell us why and we might try to sympathize.&lt;/I&gt;&lt;/FONT&gt;

&lt;P&gt;
I thought it was implicit in his description: 
&lt;FONT COLOR=&quot;#880044&quot;&gt;The informational pane on the left of the installation screens has been removed and many of the installation dialogs have been simplified, with more advanced options hidden behind an extra click.&lt;/FONT&gt; Many of us dislike it when information is hidden away in an attempt to make it more palatable to newbies. A better approach, IMHO, would have been to have the first info pane give the user an option:  &quot;Technical information will be presented here for those who wish to know more about the internal of Linux, but it's not necessary that you understand it.  If you'd rather turn it off entirely, click here.&quot;

&lt;P&gt;
(That said, I'm still a Slackware user for precisely this kind of reason, so don't mind me too much...)

&lt;P&gt;
Greg
      
      </description>
    </item>
    <item rdf:about="http://lwn.net/Articles/168761/rss">
      <title>What's New in Fedora Core 5 Test2</title>
      <link>http://lwn.net/Articles/168761/rss</link>
      <dc:date>2006-01-23T00:46:16+00:00</dc:date>
      <dc:creator>hazelsct</dc:creator>
      <description>
      &lt;dl&gt;&lt;dd&gt;Personally, I can't say I like the changes. Anaconda, a de facto standard among Linux installers, has been barely touched for years, so why the sudden need for a major interface surgery?&lt;/dd&gt;&lt;/dl&gt;

Uh, more explanation please?  You describe the new interface, and then say, &quot;I don't like it, why did it need to change?&quot;  My first thought is, who cares if you like it or not?  Tell us why and we might try to sympathize.
      
      </description>
    </item>
    <item rdf:about="http://lwn.net/Articles/168510/rss">
      <title>Re: release cycle</title>
      <link>http://lwn.net/Articles/168510/rss</link>
      <dc:date>2006-01-19T22:33:36+00:00</dc:date>
      <dc:creator>katzj</dc:creator>
      <description>
      Note that the 9 month release cycle for Fedora Core 5 is a one time thing so that some of the big infrastructural changes that have landed could happen.  For Fedora Core 6, we should be going back to the more regular 6-ish months.&lt;br&gt;
      
      </description>
    </item>
    <item rdf:about="http://lwn.net/Articles/168496/rss">
      <title>What's New in Fedora Core 5 Test2</title>
      <link>http://lwn.net/Articles/168496/rss</link>
      <dc:date>2006-01-19T21:39:59+00:00</dc:date>
      <dc:creator>error27</dc:creator>
      <description>
      I haven't installed FC5 yet, but Anaconda in FC4 is seriously show its age.&lt;br&gt;
&lt;p&gt;
The error handling for automated loads is poor.  The driver disk support painful and poorly documented.  The tools to create software RAID are difficult to use.  When you create a software RAID 1 /boot partition, the boot loader is not set up on both harddrives.&lt;br&gt;
&lt;p&gt;
For me one of the big issues with anaconda is that developing it is difficult.  It uses the very recent and obscure libraries.&lt;br&gt;
&lt;p&gt;
It needs to be generalized and simplified.  For example, you should be able to use Anaconda to create live cds.  There is work being done here, but I'm not sure the status.&lt;br&gt;
&lt;p&gt;
The process to create respins is really complicated.  You have to type commands like:&lt;br&gt;
&lt;p&gt;
buildinstall --comp Test --pkgorder $BASE/pkgorder.txt \&lt;br&gt;
    --version 4 --product &quot;Fedora 4 Respin 2&quot; --release &quot;4&quot; \&lt;br&gt;
    --prodpath Fedora $BASE/fedora-custom&lt;br&gt;
&lt;p&gt;
Sometimes you have to type the same command twice with different options in a specific order.  Afterwards you can't really be sure you have done everything correctly.&lt;br&gt;
&lt;p&gt;
I haven't tried FC5, but I bet that I'll like the UI changes...  FC5 moved to yum so hopefully that makes creating respins a bit easier.  Also the kickstart parsing was completely rewritten so hopefully error handling is improved.  It's a pain to relearn commands and to rewrite all your scripts to deal with changes, but it's worth it in the long run.&lt;br&gt;
&lt;p&gt;
&lt;p&gt;
      
      </description>
    </item>
    <item rdf:about="http://lwn.net/Articles/168424/rss">
      <title>What's New in Fedora Core 5 Test2</title>
      <link>http://lwn.net/Articles/168424/rss</link>
      <dc:date>2006-01-19T16:02:33+00:00</dc:date>
      <dc:creator>liljencrantz</dc:creator>
      <description>
      I don't think that the lack of mention of Mono is surprising, and it shows that RedHat knows what really matters. Mono itself is just yet another language and yet another runtime, which is boring. Applications which use Mono, like F-spot and Beagle, however, are _very_ exciting, and they are widely advertised. &lt;br&gt;
      
      </description>
    </item>
    <item rdf:about="http://lwn.net/Articles/168347/rss">
      <title>What's New in Fedora Core 5 Test2</title>
      <link>http://lwn.net/Articles/168347/rss</link>
      <dc:date>2006-01-19T10:34:42+00:00</dc:date>
      <dc:creator>nix</dc:creator>
      <description>
      The old patch was called, variously, `SSP' and `ProPolice' at different times (and by different people? Its history is murky.)&lt;br&gt;
&lt;p&gt;
`Assign a random and verifiable value to the stack' is a bad description. It populates a random `stack canary' from /dev/urandom at process initialization, then puts it at the top of the stack frame of all functions containing a char array above a certain size (or, with -fstack-protector-all, any function containing a char array); it also reorders the stack frame to ensure that parameters also appear on one side of the canary, while the function return address is on the other side of it. The effect is to ensure that buffer overruns that smash the return address will always smash the canary too, making `return-into-libc' attacks and many other classes of buffer overrun much harder.&lt;br&gt;
&lt;p&gt;
(The only downside is that this drains /dev/urandom's entropy pool. gentoo at least has a patch that creates a /dev/frandom device that is seeded just once from the entropy pool and then becomes a normal PRNG, and a patch to SSP that uses it, but the frandom patch was rejected from the kernel tree on the basis that some daemon could equally well do the job. It could: but that would stop you from using it in SSP...)&lt;br&gt;
      
      </description>
    </item>
    <item rdf:about="http://lwn.net/Articles/168340/rss">
      <title>What's New in Fedora Core 5 Test2</title>
      <link>http://lwn.net/Articles/168340/rss</link>
      <dc:date>2006-01-19T10:21:38+00:00</dc:date>
      <dc:creator>nix</dc:creator>
      <description>
      The stack-protector has long been available as a patch by Hiroaki Etoh, but it operated by directly mangling raw RTL and was pretty much completely nonportable as a consequence (crashing GCC on SPARC, for instance): the feature in GCC 4.1 is a reimplementation by Richard Henderson and others.&lt;br&gt;
&lt;p&gt;
However, the ABI used at runtime to call e.g. the stack-guard checks *has changed*, which means that any code compiled with -fstack-protector with the old patches *must be recompiled*, and if your libc includes a copy of the old stack guard code (as Gentoo's does), you'll have to take it out of there. (glibc-2.4 includes the new stack guard code, so FC5 is fine. This is hardly surprising given how many people @redhat.com were involved in the reimplementation :) )&lt;br&gt;
      
      </description>
    </item>
</rdf:RDF>

