[Ffmpeg-devel] [PATCH] Remove "bufsize" OptionDef option

Uoti Urpala uoti.urpala
Mon Sep 18 19:37:57 CEST 2006


On Mon, 2006-09-18 at 12:05 -0400, Rich Felker wrote:
> On Mon, Sep 18, 2006 at 11:34:59AM +0200, Panagiotis Issaris wrote:
> REASON to reject a name. I guarantee if you go in a computer store and
> ask for a machine with 2 "gibibytes" of ram they'll either stare
> blankly at you like you can't talk, or they'll think (correctly) that
> you're a fucking nerd. :)

The usage with memory sizes is unambiguous only because the possible
sizes are widely spaced. If it was possible to purchase arbitrary byte
amounts of memory the situation would be different.

> > Well, frankly, I cannot agree with that. 'k' and kilo are defined by SI
> > and have defined meanings namely 1000, not 1024.
> 
> That's what it means in the SI system of units. Bytes are not an SI
> unit of measure and thus SI is irrelevant to them. Legitimate

The prefixes do come from the SI system, so calling consistency with SI
units "irrelevant" is stupid.

> standards bodies and processes formalize existing practice/convention.
> Illegitimate ones tell people that existing practice is wrong and that
> they must change.

Informing people that a new standard is better than their existing
practice is a completely valid thing to do. Also there obviously needs
to be some kind of specification _before_ it can become existing
practice. Your complaints about the standardization process are beside
the point. If there had been a better proposal for the names of the new
units then not adopting that would have been a valid reason to complain;
complaining about there being a specification for unambiguous names at
all is not valid. People are told to change not because "it's a
standard" but because it's better than existing practice; whether it's
an official standard or an inofficial one isn't that important.

> > because it was "close enough". They should have tried to find a new
> > set of prefixes, not reuse existing ones with an already defined meaning.
> 
> And I suppose we shouldn't have called the computer keyboard a
> keyboard because only a typewriter keyboard is a keyboard. And we

The term "keyboard" is broad enough to cover both cases.

> shouldn't call a mouse a mouse because a mouse is a little animal. And

Here the same word has different meanings, and in this case they're so
completely different that both rarely make sense in the same context.


The units do not fit either of these cases. They're not so imprecise
that "M" would mean "something around 1000000" with a broad enough
meaning to cover everything up to 1048576 too, and they're not so
distinct that both couldn't make sense in the same context.

> we shouldn't call the desktop a desktop because the desktop is the top
> of your desk...

In this case I think "desktop" is more a shorthand for "desktop
computer" than a completely separate word.

> The point being....
> 
> > Maybe we should all just accept the annoyance and all start using Ki, Mi
> > and Gi postfixes, for the sake of the future generations! Do it for the kids!
> > ;) How can they live in a world with this horrible ambguity!
> 
> ...human language contains ambiguity because unlike computers, humans
> can deal with it just fine!! In mathematics we have symbols and terms

True in some sense but also so vague that this alone isn't much of an
argument for the specific case of Ki/Mi/Gi usage.

> with at least 5 or 10 different common meanings depending on context.
> If it weren't for that "ambiguity" we would have either so many
> symbols it would look like Chinese or else so much verbosity it would
> take 10 lines to express a simple concept.

Not strictly true - I think one extra word/symbol would resolve the
ambiguity of almost all existing words/symbols, so removing the
ambiguity caused by reusing words/symbols in mathematics would less than
double the length of any text. Also there certainly isn't a maximal
amount of ambiguity, so using the general existence of "some ambiguity"
as an argument about the specific case of Ki/Mi/Gi fails again.





More information about the ffmpeg-devel mailing list