I ran two or three sites on Minivend during the past five years. I found performance to be quite good, even for the most popular of the sites, the UCI Anime Store. I was running Minivend with six catalogs on a Pentium Pro 180 with 128 Mb RAM using RedHat 5.2, and I did not experience the performance degradations that others have reported. The Minivend page language was admittedly a bit difficult to learn straight from the manual, but it offered a great deal of flexibility which offset its cryptic character. (Hmm... sounds like a certain OS...)
Minivend helped my educational organization to avoid complex contraptions like the Netscape Commerce Server and InterShop, which might have done the same thing at a cost of many thousands of dollars.
Mike Heins was personally very good to work with, and the couple of times when I needed his consulting help, he was quick, accurate, and right on the money. I hope that the no-cost interactions with him via the Minivend mailing list will continue under the new corporate structure, and that ordinary Minivend site owners will continue to have influence over the development process.
As a technical writer, my perspective on Linux docs is that, in general, they are structured as reference manuals, with a great deal of prior knowledge assumed on the part of the reader. The usual way in which people master these docs is to study them religiously, perceive their interrelations, and eventually gain wisdom. The necessity of reading documentation this way means that a technical writer has not touched the material.
Technical writers' foremost concern is the user. Will the user understand this material? Do the instructions include all the steps the user needs to get the job done? Are there adequate illustrations to get the point across? These kinds of questions are the bread and butter of what we do every day.
We can produce reference manuals, which contain compressed, complete technical information. We can also produce user manuals, which structure this information in such a way that people of average intelligence and technical ability can use it.
What Linux documentation needs is better organization and structuring of the reference manuals, and the fresh writing of a series of user manuals.
When I see the average Linux documentation set, e.g., Dr. Linux from Red Hat, or the Yggdrasil book, I am amazed at the poor organization and mish-mash of topics that result from a whole tub of HOWTO's and administrator's guides being scrambled together in no discernible order. Dr. Linux doesn't even have an *index*!
The Linux documentation is living proof that programmers *need* professional technical writers. If we weren't paid so poorly, perhaps some of us would have the spare time to take a whack at getting Linux documentation into the shape it deserves to be in.
Slashdot Mirror
I ran two or three sites on Minivend during the
past five years. I found performance to be quite good, even for the most popular of the sites, the UCI Anime Store. I was running Minivend with six catalogs on a Pentium Pro 180 with 128 Mb RAM using RedHat 5.2, and I did not experience the performance degradations that others have reported. The Minivend page language was admittedly a bit difficult to learn straight from the manual, but it offered a great deal of flexibility which offset its cryptic character. (Hmm... sounds like a certain OS...)
Minivend helped my educational organization to avoid complex contraptions like the Netscape Commerce Server and InterShop, which might have done the same thing at a cost of many thousands of dollars.
Mike Heins was personally very good to work with, and the couple of times when I needed his consulting help, he was quick, accurate, and right on the money. I hope that the no-cost interactions with him via the Minivend mailing list will continue under the new corporate structure, and that ordinary Minivend site owners will continue to have influence over the development process.
As a technical writer, my perspective on Linux docs is that, in general, they are structured as reference manuals, with a great deal of prior knowledge assumed on the part of the reader. The usual way in which people master these docs is to study them religiously, perceive their interrelations, and eventually gain wisdom. The necessity of reading documentation this way means that a technical writer has not touched the material.
Technical writers' foremost concern is the user. Will the user understand this material? Do the instructions include all the steps the user needs to get the job done? Are there adequate illustrations to get the point across? These kinds of questions are the bread and butter of what we do every day.
We can produce reference manuals, which contain compressed, complete technical information. We can also produce user manuals, which structure this information in such a way that people of average intelligence and technical ability can use it.
What Linux documentation needs is better organization and structuring of the reference manuals, and the fresh writing of a series of user manuals.
When I see the average Linux documentation set, e.g., Dr. Linux from Red Hat, or the Yggdrasil book, I am amazed at the poor organization and mish-mash of topics that result from a whole tub of HOWTO's and administrator's guides being scrambled together in no discernible order. Dr. Linux doesn't even have an *index*!
The Linux documentation is living proof that programmers *need* professional technical writers.
If we weren't paid so poorly, perhaps some of us would have the spare time to take a whack at getting Linux documentation into the shape it deserves to be in.
A tech writing URL: http://www.stc.org/