1 |
Eric S. Johansson <esj@××××××.org> wrote: |
2 |
|
3 |
> Dirk Heinrichs wrote: |
4 |
> |
5 |
>>> heap. It's a classic example of "second system syndrome" as defined by |
6 |
>>> "the mythical Man month". |
7 |
>> |
8 |
>> Errh, what? |
9 |
> |
10 |
> rtfb it was published in 1972, is still in print and the first five |
11 |
> chapters |
12 |
> are as relevant today as they were when it was first published. It |
13 |
> explains why |
14 |
> software projects fail. I think it's pretty sad when failings in an |
15 |
> industry recognized 35 years ago are still happening today. |
16 |
> |
17 |
> Brooks says write one system to throw away because you are going to |
18 |
> anyway. The first time you implement, you don't understand the problem |
19 |
> and you frequently |
20 |
> leave out functionality or implement things in a clumsy or incorrect way. |
21 |
> This next implementation you, in theory, understand the problem and can do |
22 |
> a better job which leads us to... |
23 |
> |
24 |
> second system syndrome. when you implement a system for the second time |
25 |
> you think you have the problem fully understood, add lots of features and |
26 |
> capabilities and end up with a disaster on your hands because you over |
27 |
> estimated your capabilities. |
28 |
> |
29 |
> which is really Fred Brooks's way of saying write two system to throw away |
30 |
> because you're going to anyway. |
31 |
> |
32 |
> a great example of this is Microsoft. They rarely get anything right |
33 |
> until the |
34 |
> third version (implementation). Other examples are easily found if you |
35 |
> just look. |
36 |
> |
37 |
>> |
38 |
>>> It's overly complicated, poorly documented, and |
39 |
>>> has a terrible user interface that only a geek would even consider |
40 |
>>> using. |
41 |
>> |
42 |
>> What's wrong with the excelent user guide on the project's site? Which of |
43 |
>> the three UIs exactly do you think is horrible? |
44 |
> |
45 |
> could never get the containers nesting right. |
46 |
|
47 |
What "container nesting"? Oh, you're talking about EVMS? I too never |
48 |
got the hang of it. I'm perfectly fine with using plain LVM. |
49 |
|
50 |
> If the instructions on how |
51 |
> to use an LVM can't be explained on a postcard, you don't understand how |
52 |
> to communicate |
53 |
|
54 |
pvcreate /dev/hda |
55 |
vgcreate data /dev/hda |
56 |
lvcreate -L42g data |
57 |
mkfs /dev/data/lvol0 |
58 |
|
59 |
What's so hard about that? Does that fit on a postcard? |
60 |
|
61 |
-v: |
62 |
pvcreate /dev/hda: Intialize the device as a physical volume (pv), |
63 |
so that it can be used by LVM. One time job. |
64 |
vgcreate data /dev/hda: Create a container called "data" which will |
65 |
hold the different sub-containers. The "data" container is made up |
66 |
of the /dev/hda physical volume. |
67 |
lvcreate -L42g data: Create a logical volume (lv) on the "data" |
68 |
volume group (vg). It's sized "42g" (42GiB). |
69 |
mkfs /dev/data/lvol0: Create a file system on the newly created lv. |
70 |
|
71 |
> with your users or the implementation is really off. |
72 |
|
73 |
Nope. Some things simply *ARE* complicated. |
74 |
|
75 |
Alexander Skwar |
76 |
|
77 |
-- |
78 |
gentoo-user@g.o mailing list |