Jóhann B. Guðmundsson wrote:
> Arguably we should not have any specific target image size but rather a
> list of valid image sizes ( cd/dvd/usb keys ) for spins to aim at which
> SIG's themselves choose to use each release cycle and can adjust
> accordingly which gives them the ability to shrink/expand to suit
> *their* targets audience needs at any given time.
A good target size would be the size of a CD-R90. The problem there is that
it's ill-specified: the media usually say "90 min / 800 MB", but 800 decimal
MB of data are less than 90 minutes of audio, 800 MiB are more. There's also
no standard which specifies a minimum capacity in sectors as for the "80 min
/ 700 MB" case (where you actually get 703 MiB of guaranteed capacity). Add
to that that you need to use the overburn option even to use the medium's
advertised (to humans) capacity (as it advertises only the standard 80
minutes to the burner), so it is really hard to figure out how much space
the manufacturers really are providing you. It probably also depends on the
manufacturer. Some manufacturers give instructions saying to set the limit
to 89:30, while at the same time advertising 90 minutes on the label, and
even then it doesn't necessarily mean you can't actually burn 90:00 or maybe
even 800 MiB on the medium. And then it can also depend on the burner. The
reasonably safe target size would probably be somewhere around 700 * 89.5 /
80 = 783 ⅛ MiB (matching the "89:30" recommendation). (The exact computation
would have to take the overheads into account.) Whether that'd be enough for
the KDE spin after MiniDebugInfo, I don't know yet, we'll have to wait and
see.
The next higher capacity is CD-R99, but there too, the size is poorly
specified and burner support even more lackluster. (You can expect most
current burners to burn CD-R90s just fine, but not necessarily CD-R99s.)
So I really wonder whether it isn't more practical to set an arbitrary limit
and let the user find a suitable medium to burn it on (if in doubt, a DVD;
we'll probably call it a "Live DVD" in the first place).
Kevin Kofler
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
