[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: Gary Preckshot <>
- Subject: Re: Authorship
- From: "der.hans" <>
- Date: Thu, 8 Jun 2000 03:19:41 -0700 (MST)
- Cc: LDP <>
- Resent-Date: Thu, 8 Jun 2000 06:29:07 -0400 (EDT)
- Resent-Message-ID: <V_YO3B.A.71H.zV3P5@murphy>
On Wed, 31 May 2000, Gary Preckshot wrote:
> Pal Domokos wrote:
>> SGML tools: the second paragraph here, I think, is needless. If a
>> prospective LDP author does not know how to download files from the
>> Internet, then he/she has much to learn before qualifying for an
I agree with this one. I just can't think of a case where someone could be
giving us good information, but not know how to d/l a file. I can, OTOH,
think of cases where they don't have the option to d/l a file. There are
less and less places where that's a case, but it still comes up once in a
>> author. I also do not understand what "If [...] your preferred
>> operating system is Linux" means: what else would it be?
> One symptom of extreme geekness is assuming that people know how to do
> things the author knows how to do or that the system set up the author
> has is the be-all and end-all and anybody who doesn't have it is
> nobody. This section was in there because HOWTOs are not for people
> who already know how to, but for people who don't. Likewise, a lot of
> people who currently have Windows read the howtos. What would their
> preferred operating system be? A geek would say if they're using
A HOWTO author doesn't necessarily need to be a big user of Linux. What if
one of the os/2 people out there needs Linux for work and figures out how
to duel-boot them. That person might be able to write a very good HOWTO
I even know some very knowledgable Linux people who prefer other
OSes. Usually another *NIX :).
>> I do not think we should recommend tools but rather list them. I
We need to recommend tools, e.g. the translation process the LDP uses has
been listed and the scripts used have been made available. By virtue of
those scripts we are recommending Jade and whatever else they're
using. The recommended tools become the "supported" tools. Others might
still have great coverage, just aren't recommended.
>> particularly do not like the conclusion: if you have money and you
>> also have Windows, use WordPerfect. Let the author decide what he/she
I think that could be worded better, but saying that WordPerfect is a good
solution when writing on m$ is fine. We need to add info on how the
support is to be used, etc. Gary's working on that. I doubt I'll look at
it as other than Linux I've only used AIX and Solaris in the last 4 years
I agree with Gary that we need to have support for something on m$.
>> likes. (By the way, if you have money and Windows, you can choose from
>> professional SGML/XML editors - XMetaL from SoftQuad is one.)
These should be listed and described as well as we can get someone to do
for us :).
BTW, I think we should choose at most one or two editors in line that will
have supporting documentation and the rest should link to
appendices. Maybe all of them should. I like to be able to go to
"next" and not have to wade through a whole bunch of crap. Due to the size
of what we're describing most editors probably need their own section, aka
> Provincial. We should list anything that works, with pros and cons. If
I agree. It was pointed out that work might be done on a work computer
where someone isn't allowed to run Linux. Also, not every author has to
prefer Linux. They have to bring in relevant knowledge that is missing
from the LDP at the time.
I do think that preference should be given to Linux and Open Source tools,
but Gary's work with WordPerfect indicates to me that it also needs to be
Coverage of tools beyond the few we decide should be "supported" would
then emerge if someone wished to supply the relevent portions. The docs
for the "supported" tools should be encouraged and solicited as well as
> vi is an option only if you are into pain.
vi is awesome. I'm not a trained pianist, so emacs is painful :). I've not
yet met a GUI editor or word processor worth my time. I'm writing to input
data, not to play with menus.
In any case I agree it should be lumped under the "do-it-by-hand" section.
That section might appropriately point to say an SGML or DocBook HOWTO.
I just pulled up my HOWTO in vim and it has color support for syntax
highlighting. Don't know about other stuff, I'll be looking into that
>> sgmltools: I do not think you actually need this software.
> That was my impression. So why is it there?
We should leave a reference to it. If it's to no longer be used, we should
leave that as the reference. I think we still need some legacy support for
it, from what I've understood. In that case we should put in a "don't use
it for new stuff" disclaimer and then add documentation for it. Some of
the needed documentation would be how to move off of it :).
> So we need a lot more detail on emacs. Including screen shots.
The screen shots also have to have text to replace them. Maybe have a link
the the replacement text. I don't always have pictures as an option. Yes,
I actually run X on my desktops, but I'm not always reading stuff from a
desktop. I wouldn't usually be reading the HOWTO-HOWTO from elsewhere, but
might have need, especially from a PDA.
>> WordPerfect: again, "recommended for those with money and [...]
>> Windows". I do not know WordPerfect but what the figure shows and you
>> write about it Gary, is very similar to what Emacs and sgedit can do.
>> I do not think it (WP) is "a good reason for having a mult-boot
No reason for not describing both. Personally, I think the "good
reason" part should be left out. It's more that WordPerfect is an option
when on m$, here's why and how to use it...
> No. It's stupid. Why learn something a tool can do for you? To show
> your virtue? That went out in the middle ages with hair shirts.
The tools can't do all I need them to do. One of the things I need to do
is learn much more about sgml and xml. Using them by hand is one way to do
so. I learned vi from the command line, not from within vi BTW :).
Also, with that generalization one presumes that we should never learn
math. A calculator can do it, so we don't need to. Learning math is one
way to learn logic. Also, I don't always have a calculator and for most
things where I need some math done it's too slow.
> Like it or not, the HOWTO-HOWTO is the flagship HOWTO of the LDP.
That's a good way to put it. It's the intro for prospective authors and
needs to be in good shape to impress them. Our manifest isn't to serve
authors, rather those in need of knowledge to do with Linux, but we can
better serve that by getting more and better authors.
> 1) it should be up-to-date. For example, sgmltools are a dead letter.
> LyX may not be relevant.
Again, they should be listed and then covered as to why they're not
applicable. That coverage can be in an appendix, but they should either be
listed in the doc or there should be a link to "check here for tools not
listed inline" ...
> 2) it should not be provincial. HOWTOs are the way the non-Linux world
> gets to be the Linux world. Tools should not be eschewed just because
> they are commercial or they run on a different OS. LILO is there for a
I agree. I still say that we should prefer free and Open Source. I also
think we *have* to support at least some free and Open Source solution.
> 5) it should not require extreme sacrifice on the part of prospective
> authors. Vi sucks as an editor. So does writing SGML by hand. Emacs
vi is an awesome editor :). It sucks as a word processor. Template support
is word processing :).
> should be explored. There may be a reason it's not more popular. Find
> 6) Graphics are modern. Use them.
Only if they can be replaced with text. I read docs on PDA. Soon I will do
so from my cell phone when I'm bored in meetings :). I use wasted time to
learn. The HOWTOs are a great source of knowledge.
# der.hans@LuftHans.com home.pages.de/~lufthans/ www.OpNIX.com
# Magic is science unexplained. - der.hans
To UNSUBSCRIBE, email to email@example.com
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org