Boot speedup with readahead

[Seth Vidal]

On Mon, 2008-09-15 at 19:11 -0400, James Antill wrote:
> On Mon, 2008-09-15 at 13:02 -0400, Behdad Esfahbod wrote:
> 
> > The question is: if one could throw RPM away and design a new one, could one
> > do significantly better?
> 
>  Of course one could, the relevant question is _how long_ would it take.
> And could it be done faster by just fixing rpm, and I've not seen any
> compelling arguments that it would be faster to throw away what we have.
> 
>  It is also wide believed as true in the software field that "re-write
> from scratch" is a last resort, and will always take longer and be more
> expensive etc.
>  There are cases where the subset of problems people care about is
> smaller than those solved by the original program, "everyone" dislikes
> the original program and a small group of good programmers are willing
> to spend/invest a _lot_ of time to create a replacement. But I can only
> think of a handful of examples here, and there's a reason for that.
> 
> > Lets look back at the problem at hand: we all agree that custom-installed
> > glob-matched post-transaction triggers are useful things.  I think I can also
> > say that we agree that it should be in the lowest-level package management
> > system.  What has been up to debate so far is whether that lowest-level is
> > RPM, or that RPM is a lost case and yum is considered the lowest-level.
> 
>  That is a severe mis-reading of the discussion, the question is given
> that rpm+yum are currently how all Fedora users manage their system. Do
> we want to still require that all packaging problems should be solved at
> the rpm layer, or should we try to move up and allow some more of the
> problems to be solved at the yum layer.
>  There are many advantages to doing this, including just plain ease of
> implementation. The only real disadvantage is that apt/smart/zypp/etc.
> will become even more of a second class citizen in Fedora than they
> already are (although I'm confident that the change proposed by Seth
> could easily be ported to work in all of the above).
> 

s/easily/trivially/

it's a colon-delimited file format with pretty simple rules.

-sv