Re: [gentoo-user] Re: OT: Is EVMS dead?

[Eric S. Johansson]

Alexander Skwar wrote:
> Eric S. Johansson <esj@××××××.org> wrote:
>
>> Dirk Heinrichs wrote:
>>
>>>> heap.  It's a classic example of "second system syndrome" as defined by
>>>>  "the mythical Man month".
>>> Errh, what?
>> rtfb  it was published in 1972, is still in print and the first five
>> chapters are as relevant today as they were when it was first published.
>> It explains why software projects fail.  I think it's pretty sad when
>> failings in an industry recognized 35 years ago are still happening today.
>>
>> Brooks says write one system to throw away because you are going to anyway.
>> The first time you implement, you don't understand the problem and you
>> frequently leave out functionality or implement things in a clumsy or
>> incorrect way. This next implementation you, in theory, understand the
>> problem and can do a better job which leads us to...
>>
>> second system syndrome.  when you implement a system for the second time
>> you think you have the problem fully understood, add lots of features and
>> capabilities and end up with a disaster on your hands because you over
>> estimated your capabilities.
>>
>> which is really Fred Brooks's way of saying write two system to throw away
>> because you're going to anyway.
>>
>> a great example of this is Microsoft.  They rarely get anything right until
>> the third version (implementation).  Other examples are easily found if you
>>  just look.
>>
>>>> It's overly complicated, poorly documented, and has a terrible user
>>>> interface that only a geek would even consider using.
>>> What's wrong with the excelent user guide on the project's site? Which of
>>>  the three UIs exactly do you think is horrible?
>> could never get the containers nesting right.
>
> What "container nesting"? Oh, you're talking about EVMS? I too never got the
> hang of it. I'm perfectly fine with using plain LVM.
>
>> If the instructions on how to use an LVM can't be explained on a postcard,
>> you don't understand how to communicate
>
> pvcreate /dev/hda vgcreate data /dev/hda lvcreate -L42g data mkfs
> /dev/data/lvol0
>
> What's so hard about that? Does that fit on a postcard?

  it needs a little more detail so a user can extrapolate to what they need but,
yeah that's basically what I'm looking for.  I guess it's time to start the
postcard series of documentation.  :-)

What is hard however is developing the postcard level documentation for disaster
recovery.  Again, that's something I'll work on when I have the time.
>
> -v: pvcreate /dev/hda: Intialize the device as a physical volume (pv), so
> that it can be used by LVM. One time job.

would need reference physical volume, physical device associations (i.e. single
disc or hardware raid).  is there any way to display/enumerate them independent
of non-LVM devices?  (note: don't need an answer on this, it's just illustrating
the kind of follow-on questions that come up.)

> vgcreate data /dev/hda: Create a container called "data" which will hold the
> different sub-containers. The "data" container is made up of the /dev/hda
> physical volume.

what is a sub container? why is it needed? when do you need it?  do/can you
create a container spanning multiple devices?  When, how, why?

> lvcreate -L42g data: Create a logical volume (lv) on the "data" volume group
> (vg). It's sized "42g" (42GiB).

again, is a logical volume a single physical volume?  If the volume group called
data (how did it get from container to volume group) is the same as the physical
volume, why not just use the physical volume?

> mkfs /dev/data/lvol0: Create a file system on the newly created lv.

in other words, the logical volume is  treated by the system in exactly the same
way as a physical volume.  It's a logical disk.

these are just some of the "naïve user" questions that come to mind.  They
aren't answers concisely in most of the documentation I have seen.  Part of the
reason I say "explain it on a postcard" is because the format forces you to
focus your thoughts and explain the system concisely.  the same technique as
used in communicating with the busy suit although it's usually explaining your
idea in 13 words or less.

>
>> with your users or the implementation is really off.
>
> Nope. Some things simply *ARE* complicated.

Richard Feynman, a great physicist, once stated that if you can not explain a
(physics) problem at a freshman level then you don't understand the problem.
Edward Tufte has a series of books on information design simplifying
complicated things so that you can communicate clearly.  Either of these men are
smarter than you and I put together.  I highly recommend reading Tufte's books 
or watch Feynman's testimony at the Challenger committee hearing where he shows 
with a glass of ice water the most likely explanation for the disaster.  Clear, 
simple and easily understood by most people.  If these men successfully 
live/lived by the guideline that complex explanations means you don't 
understand, I'm willing to accept it as true to make that one of my guiding 
principles.


-- 
Speech-recognition in use.  It makes mistakes, I correct some.
-- 
gentoo-user@g.o mailing list