bdubbs at swbell.net
Thu Jul 26 05:08:58 PDT 2001
Mark Hymers wrote:
>On Thu, 26, Jul, 2001 at 12:03:24AM -0500, Bruce Dubbs wrote:
>>>OK. There's been no opposition.
>>>Compile times are going :-)
>>According to my system, you posted the first message at 05:16 and this
>>message at 15:00. 10 Hours. Please give us a chance to reply before
>>implementing a policy. At least 24 hours. 48 hours would be better.
>>I don't know where you are based, but I am in Texas and sometimes can't
>>get to my system until late.
>Sorry about that. I hope that you understand that because the book is
>just starting, I'm anxious to try and get it moving quickly before
>inertia is lost. Out of interest, I'm based in the Newcastle; in the
>north of England. If you really want compile times to go back in then
>I'm still willing to listen but again my problem is that I probably
>won't have time to compile each package under similar conditions (i.e.
>with X closed - at at console prompt) and I'm not totally convinced it's
>necessary anyway. If you look at the relative size of the Estimated
>Disk Space entry, you should be able to gauge the length of the
>compilation time from there (i.e. 1MB disk space required --> 30 secs,
>while 1GB disk space required --> Mozilla^H^H^H^H^H^H^H sorry - 1.5
As I said on my earlier post on this subject, We don't need a lot in
this area. Something on the order of:
Approximate compile time: 24 minutes on a P3 800MHz ssytem.
Where the variables are the time, type, and speed, of the sytem. Of
course there are other variables like RAM, disck speed, etc, but I'm not
advocating a complete system descriprion.
Certainly I don't expect you to time everything in the book. Each
contribution can give this data. Its really as simple as:
I'm sure you will have losts of volunteers.
The relative size of the package size is an indirect measure. I just
feel the time on a specificde system is more direct and useful for the
reader. See my KDE hint for an example.
More information about the blfs-book