[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Some technical suggestions
> >> perhaps:
> >> alias howto="lynx /usr/doc/howto/html/index.html"
> >A bit more finesse would be required, we cannot assume that everyone
> >has Lynx installed, they might use any nomber of alternatives such as
> >Netscape, Amaya etc. In fact we cannot be sure what form the HOWTOs
> >are stored in, text, compressed text, HTML etc.
> I agree about the reader, but I think the majority of people will have the
> HOWTOs in html format, as this is what the distributions I've used seem to
> default to. This is an assumption I used while writing my program.
Documentation has to be installed too, perhaps adding a snity check
to your program weould be an idea, so that if nothing is found in the
expected places you get an informative error message. Debian, for
instance, requires you to actually install the docs, in the relevant
> >> This could also update a file called update.howto on the local machine
> >> that said when each file had last been updated.
> >The idea is intersting but also rather difficult. Few install
> >raw HOWTOs temselves but rather use .rpm or .deb packages, and
> >directly manipulating parts of such packages would be messy.
> >Also it would mean that the LDP would have to make the package
> >files rather than the distributors and I am not sure what people
> >would think of that. Do we have the capacity to take on that
> >task (not yet I think), and what does the current packaging
> >maintainers think?
> Once the package had been installed (from .rpm .deb etc..), wouldn't it be
> easier to provide a program that can download only the updated files,
> rather than creating a program that packages up only the files that have
> been updated since the user last updated his HOWTO files, then downloads
> this package and installs the package on the users computer.
It is possible but potentially hazardous. Remember that the package
managers have a database of existing files, that is, files they know
they installed. So when new files appear (say another chapter was
added to a HOWTO) this is not listed in the database and the system
ends up in an unknown state.
> >> > HELP FILES
> >> > ==========
> >> >
> >> > I believe we need to add a SMALL text file into /etc/skel/ so all
> >> > beginners get a starting point. How about this:
> >> also, the line:
> >> For information on how to get help, type "less help.txt"
> >> could be added to the motd. That way people would notice the file, and
> >> realise that they can use it to get help on getting help.
> >I don't agree on this. The motd should be kept lean and be a
> >message for everyone, not just the beginners. A message on
> >first logging in or an automated mail message should do the
> >same trick I think.
> This would give the user the command only once, and it could be easily
> forgotten. If you see it often, it is more likely to be remembered.
> Perhaps, on the first login the user could be presented with the option to
> display the line everytime the user logs in, on not to display it at all.
For desktop use installing a LDP icon or button might do the
trick. In Debian the documentation is available from the on screen
menu system, rather deeply buried methinks.
> Or we could look at it like the user who doesn't need help is the one who
> knows everything, and if they know everything, they should be able to
> manually edit the motd.
This assumes single user machines and that is not always so.
> Perhaps putting the line in the ~/.bashrc would be a better place.
This is a far better solution.
Another idea: use the fortune program to dispense LDP cookies. This
conjures up some odd images... More seriously, similar things are
in everyday use on certain other operating systems, "Tip of the day".
Making a LDP cookie jar shouldn't be too hard.
> >Perhaps the LDP could make some presentation material for
> >people to use in the LUG meetings?
> That is a good idea.
> >> If you'd like me to give coding an example "howto" program ago, let me
> >> know, I don't think it'd be too hard in shell script.
> >It could be interesting but also difficult if you want to make it work
> >on a wide range of platforms, spanning numerous file formats
> >(.txt, .txt.gz, .txt.bz2, .html), numerous readers (lynx, amaya, mc),
> >and also several file locations depending on file standard used
> >( /usr/doc/HOWTO/ and /usr/share/doc/HOWTO/ ).
> I got bored, so started coding it last night. I should have a mostly
> finished product by tonight, as I've just got a few more things to sort
> I'd tar it in its current state, and post it, but, I'm at college, and the
> prog isn't. So I'll sort it out tonight.
I am looking forward to seeing this.
To UNSUBSCRIBE, email to email@example.com
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org