Alexander Skwar wrote:
Eric S. Johansson <[EMAIL PROTECTED]> 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.
--
[EMAIL PROTECTED] mailing list
