> Perhaps, but I am not going to enter any 'p*issing contests' of who's > got whose name where (besides, I am not implying to be an uber-coder, > but I do reserve the right to express my opinion wrt matter at hand). > I would like to retain the concentration on the matter discussed.
Your opinion is wrong and uninteresting. The only thing you have expressed so far is your detachment from the real world by implying that some sort of retarded document written by committee retards is somehow important. > > > The source code _does_ define the behaviour. Exactly. Perhaps the > > source code is wrong, but it *EXACTLY DEFINES THE BEHAVIOUR*. > > All I was saying that it is not always the case. For example: > > the code in various http client/server applications *implements* the > behavior (correctly or incorrectly as it may be), but the behavior is > *defined* elsewhere (e.g. a standard); And in the real world all these standards are treated as guidelines. Anyone who has written code from a "standard" know this. This also means that every person on this planet would interpret language the same. In the open source world people can't even agree what the word "free" means. > > similar things could be said about the code in c compiler vs the c > standard et al. Show me 2 compilers and I'll show you 2 compilers that don't adhere to the spec. > Sometimes this may not be the case, of course, but to categorically > imply that 'code defines behavior' is not right in my opinion. It does. Code is absolute, words on paper are not. > On the other hand -- perhaps we differ in our understanding of the > term "defines". You probably implying "defines" as in "results in a > given behavior", I am implying "defines" more in terms of > standardization/documentation (i.e. outline/definition of > rules/behavior). blah blah blah. > Either way -- this only reinforces what I was saying wrt to not > expecting any future-compatible behavior of system and thus reducing > the scope of disklabel and 'c' partition arguments to the > "static/current" codebase behavior. Compatible with what? The c partition is the whole disk, end of discussion. Don't know what a committee could ever add to that. In fact I do know; they'd attach some arbitrary rules to show how smart they are or to push some corporation's agenda. The last thing they'd do is push anything useful. BTW, don't believe me? Go read ACPI, SCSI & IPMI specs. Then go write the code. Let me know how that went.
