On 7/29/09, leon zadorin wrote:
> On 7/29/09, Atle Kristensen wrote:
>
>>> > I am, at this stage of conversation (if one can call it such), noting
>>> > the difference (in my opinion) between implementation and definition
>>
>> There is ALWAYS a di
On 7/29/09, Atle Kristensen wrote:
>> > I am, at this stage of conversation (if one can call it such), noting
>> > the difference (in my opinion) between implementation and definition
>
> There is ALWAYS a difference while dealing with two "languages":
> code <-> specification/documentation.
Sur
On 7/28/09, leon zadorin wrote:
> 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
On 7/28/09, Marco Peereboom 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 7/27/09, Marco Peereboom wrote:
>> :-) :-) :-) 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 behavi
On 7/27/09, Theo de Raadt wrote:
>> On 7/27/09, Theo de Raadt wrote:
>> >> On 7/27/09, Theo de Raadt 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 e
On 7/27/09, Theo de Raadt wrote:
>> On 7/27/09, Theo de Raadt 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
On 7/27/09, Theo de Raadt 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* cha
On 7/27/09, Theo de Raadt wrote:
>> I'd say. Anywhere does it say this? My understanding was that 'c'
>> partition depicts the entire device. If this is correct, than it's not
>> even close to describing it as 'freely changing' it's semantics as per
>> kernel's mood. Artistic perhaps, but precise.
On 7/27/09, Kenneth R Westerback wrote:
> On Mon, Jul 27, 2009 at 11:11:21AM +1000, leon zadorin wrote:
>> On 7/27/09, Kenneth R Westerback wrote:
>> > On Sun, Jul 26, 2009 at 04:44:45AM +1100, leon zadorin wrote:
>> >> Man page for mount_vnd states:
>> &
On 7/27/09, Kenneth R Westerback wrote:
> On Sun, Jul 26, 2009 at 04:44:45AM +1100, leon zadorin wrote:
>> Man page for mount_vnd states:
>> "
>> The `c' partition of a vnd image should not be used. When a superblock
>> becomes damaged, fsck_ffs(
Man page for mount_vnd states:
"
The `c' partition of a vnd image should not be used. When a superblock
becomes damaged, fsck_ffs(8) needs information contained in the disklabel
to determine the location of alternate superblocks. This information is
not available when directly usin
Hi,
Man pages for vnconfig state that one of the useful things for "vnd"
devices (not svnd ones) is to make them be used for swap.
Given that vnconfig associates a vnd device with a regular file -- the
above comments reduce to allowing one to use regular file as a swap
space... only... why would
13 matches
Mail list logo
