On 7/27/09, Theo de Raadt <dera...@cvs.openbsd.org> wrote: >> On 7/27/09, Theo de Raadt <dera...@cvs.openbsd.org> wrote: >> >> On 7/27/09, Theo de Raadt <dera...@cvs.openbsd.org> wrote: >> >> >> Sounds a little nonsensical to me. >> >> >> >> >> >> 1) for example, it would make no sense to 'shrink' the size of >> >> >> conceptual 'whole disk' (esp. if such represents the entire >> >> >> *physical* >> >> >> disk as per man pages) to be less than other partitions -- so >> >> >> '*arbitrary* changing its [disk's] limits' is an over-generalization >> >> >> in my opinion. >> >> >> >> >> >> 2) w.r.t. forward-compatibility, one cannot make any suppositions >> >> >> for >> >> >> system's (kernel or userland) behavior in future versions/releases >> >> >> for >> >> >> practically anything (e.g. the key-generating hash in vnconfig may >> >> >> not >> >> >> be guaranteed to forever remain the same; the format of system calls >> >> >> may change/evolve, disklabel format may/may-not change, sector-size >> >> >> may become editable, etc.)... and I am certainly not looking this >> >> >> far >> >> >> into the future (i.e. namely and most-likely I am considering the >> >> >> behavior wrt current kernel w/o such being upgraded continuously). >> >> >> In >> >> >> other words, I am perfectly happy to accept the failed 'mount/fsck' >> >> >> attempts when/if differently-behaving kernel is being deployed. >> >> > >> >> > The source code defines the behaviour. >> >> > >> >> > Your words don't. >> >> > >> >> >> >> Neither do yours :-) Although, some would also say that source code is >> >> not always *defining*, but rather *implementing* the behavior (which >> >> is standardized perhaps elsewhere)... but anyway -- potato, potato :-) >> > >> > Oh cut the crap. >> > >> > krw and I have a view how it should work, and we code it. >> > Then the code is the behaviour. >> > >> > Perhaps we made mistakes. Perhaps they'll be changed. >> > >> > But you are just spouting bullshit. >> > >> >> :-) :-) :-) relax, take a pill -- no need to get emotional. >> >> besides I don't think we are seeing things that much differently. I >> didn't say you were making mistakes, but if you make krap-inviting >> statements like "the source code *defines* the behavior" then expect >> the likewise, albeit not-that-serious, replies. >> >> Besides, the code may well be acting like implementation and >> definition in one place, so no need to take such a heated bait to my >> light replies. I'll stop now :-) >> >> >> chill -- I don't mean to get a flame-war started, peace dude :-) > > I don't know who you are, but you do nothing. What do you do? > > I don't see your name on any the source code.
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. > 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); similar things could be said about the code in c compiler vs the c standard et al. Sometimes this may not be the case, of course, but to categorically imply that 'code defines behavior' is not right in my opinion. 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). 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. > So you shut up, loser. Just go away. > Ok then. Be happy, take it easy. leon.
