On 7/28/09, Marco Peereboom <sl...@peereboom.us> wrote: >> 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. >
I didn't say this (although I also did not express any support for having this general attitude towards standards as 'retarded documents written by retards'). I think your (and others) emotions are getting in a way of seeing the point I was making. I am not imposing a qualitative resolution that everything which is concerned with source code implementation must be standardized by a committee. You appear to have concluded that I am frowning at the fact that some parts of the source code are somehow not committee-standardized -- this is not so. I am simply noting (i.e. observing w/o blaming-others or anything of such sort) that, in the absence of such (or similar) standards, any consideration for what kernel's mood may bring in a future (e.g. arbitrary changes of interpretation of what "entire physical disk" equates to; ala "forward-compatibility") are not sufficient for the arguments at hand. In fact, I am not even suggesting that someone had made such arguments, I was simply enumerating the reasons I thought were relevant (and rather are easy to agree-on) when considering as to what "kernel's mood" may be interpreted in the context of the originally raised question (e.g. man pages implications for the disk to be functional without any disklabel being written to it [man 5 disklabel], the reasons given for not using c partition in [man vnconfig, caveats section] et al -- as per original email). >> >> > 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. Sure. But if such guidelines do exist -- should one not, at the very least, attempt/strive towards meeting them (provided, of course, that the standard/guidelines have been accepted by the implementing community)? We are basically starting to enter the whole discussion of viewing what "implementation" vs "definition" mean and this was so not the point of the original question. Besides, I am sure you already realize, that just because one may not be implementing the standard correctly -- it does not mean that one should simply ignore the standard altogether. > 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. > Not every person on this planet may interpret the language the same -- but this does not mean that everyone should abandon well-defined semantics attached to well-known words and start speaking their own non-interoperable junk. This is even more so w.r.t. technical/programming languages. >> >> 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. This is a bit of a moot point -- and I am sure you realize this yourself. Not adhering to the specs does not equate to ignoring them altogether. >> 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. How you choose to represent the behavior's definition is irrelevant (code or words, on paper or on screen). I am, at this stage of conversation (if one can call it such), noting the difference (in my opinion) between implementation and definition -- and whilst there are cases when code represents both of such concepts in one place; there are other places when there simply *must* be multiple implementations (i.e. a source code of a given app/library) of a given behavior/interface (standard) so that different processes/boxes/entities/etc can inter-operate with each other. For instance: "Hello, how are you?" whether being written by me or by you, on screen or on paper is still better than "AOAURRAOREAr naoe as10 ao" ... right? >> 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. :-) :-) :-) Ignoring a point and making nonsensical noises are two different things. >> 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. :-) When did I ever stated that some committee should standardize this? I was commenting on man pages and that I was unclear on how I was reading their content (one page appears to tell me that the disk does not *need* to have disklabel to be installed at all and that the kernel will provide one for it 'on-the-fly'; the other page appears to say that c partition should not be used *because* fsck will need disklabel for sector/block-finding purposes thus implying that c partition needs a disklabel; yet another page implies a constant semantic guarantee that 'c' partition does represent an entire and physical disk; and then the email appeared to tell me that kernel's "mood" can change c partition at will)... just look at the first couple of emails in this thread for details. All I was doing afterward is trying to restrict the context of what is reasonable to expect w.r.t. to "kernel's mood" changing "arbitrarily" and how such expectations should really only be conducted in the context of current/static codebase (as there is no standard-based commitment to future-compatibility -- *without* stating that I expected such a future-compatible behavior to be made available). > 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. > It's like I am trying to talk to you about apples and you are vigorously arguing about oranges. I am *not* disagreeing with you about oranges. Leon.
