On Sat, 1 Sep 2007, Jan Engelhardt wrote:
>
> On Aug 31 2007 21:33, Robert P. J. Day wrote:
> >
> >perhaps. all i'm begging for is that these attributes be defined
> >cleanly and clearly, and following those two conditions i suggested
> >earlier:
> >
> >1) all attributes are orthogonal to one another, and
>
> This "orthogonal" argument is reserved for the cdrecord maintainer;
>
> I cannot figure out what you mean by orthogonal. If A is orthogonal
> to B and B is orthogonal to C, then A is parallel to C. If there are
> more objects than dimensions, at least one pair of them is not
> orthogonal. That is what orthogonal means to me ;-)
you're being too literal in a purely mathematical sense.
"orthogonality" has a much more general definition in the context of
computer science -- see here:
http://dict.die.net/orthogonal/
"The term is used loosely to mean mutually independent or well
separated. It is used to describe sets of primitives or capabilities
that, like linearly independent vectors in geometry, span the entire
"capability space" and are in some sense non-overlapping or mutually
independent."
and here:
"Computer science
"Orthogonality is a system design property facilitating feasibility
and compactness of complex designs. Orthogonality guarantees that
modifying the technical effect produced by a component of a system
neither creates nor propagates side effects to other components of the
system."
in the case of Kconfig "attributes", a set of orthogonal attributes
might be a variable's maturity, its colour and its flavour (i'm just
making those last two up, of course). and each of those clearly
orthogonal attributes is allowed to have at most one value, and that
value is entirely independent of what the value is of any of the
*other* attributes for that kernel feature.
i'm harping on this because it seems to me that lumping together
values such as experimental, deprecated, obsolete and broken in a
single attribute is creating a dangerously ill-defined attribute
that's trying to do two things at once -- identify both a variable's
"age", if you will, and its current code quality. and i'm simply
arguing that those are two different things and, if you do that, it
would prevent you from saying that some kernel feature is both
experimental *and* broken.
note: the above is assuming that an attribute is *defined* as being
allowed to have at most one possible value at a time, as in deprecated
*or* obsolete, and never deprecated *and* obsolete. if you go down
that second road, very bad things await you.
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://crashcourse.ca
========================================================================
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
