Hmm, interesting, jdow.
So, guestimating total time is a tricky problem, involving lots of
different things, and depending on what you'r guestimating (total
download time of a file, total install time for a set of packages, total
compile time of a program, etc)
Maybe this could be a fun project to look into for the not so serious
developers not working on serious projects :-)
It might even be me, some time in the future!
(I'm now working out how long it would take me to solve this problem)
Tino
Op za 19-07-2003, om 01:47 schreef jdow:
> I've looked at this from time to time. Each time I look I bounce.
> There are simply too many unknowns to get a good time estimate. You
> can get a "percent of the total number of packages installed." Beyond
> that you need to develop heuristics for the disk speed, the likely
> time to install an rpm of a given size, and so forth. Disk speed is
> fairly easy to nail down. Actual place a file on disk time may vary
> somewhat with the number of files in the destination location. The
> time to place an RPM on the disk is highly variable. It varies by
> the amount of data that needs to be transferred to disk, the number
> of files, and the amount of post copy prep that needs to be done.
> These may vary depending on what other packages are installed. The
> "Microsoft Minute" phenomenon is something that it's quite difficult
> to overcome. (Although Microsoft seems to carry it to an extreme of
> time estimating silliness. What would anyone expect? They cannot
> improve it because too many users would have coronaries if Microsoft
> actually made it accurate. The users would think the world had come
> to an end. {^_-})
>
> So it's probably easiest to go with percentage of the number of
> files to be installed and a very rude and crude time estimate.
> That way there's more time for the serious developers to work on
> serious problems. (Er like, let's get a GOOD 2.4 someday.)
>
> {^_-}
> ----- Original Message -----
> From: "Tino Meinen" <a.t.meinen@xxxxxxxxx>
> > But I see these kind of inaccurate guesses in other places as well.
> > Making an estimate for a progressbar or 'total-time', is a very common
> > thing to do for a program(mer), so I wonder if there is a generic
> > library available somewhere where these type of things are handled in a
> > more scientific manner.
> >
> > Tino Meinen
> >
> > > When installing Shrike (and all prior versions, for that matter), the
> > > estimated total time is grossly inaccurate. On a 1GHz P-III/M laptop
> with
--
Shrike-list mailing list
Shrike-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/shrike-list
