<div>I tend to agree Barry , and thank you for your "help desk service" for me, what I would like to see is a better effort made in documenting the setup of Jnos and other flavours. What I see now is the documentation seems to assume a prior knowledge and understanding of xnos and new users (like myself ) are lost in the setup....altho I am not 100% functional yet I have a much better understanding of the process and with more research will have a full understanding of what needs to be done.
</div>
<div> </div>
<div>I see alot of basic questions come through that , in my opinion, would be answered if the project documentation was "dumbed down" for new users , no offence to anyone intended , I am new to all this too<br>
</div>
<div>Dave , ve3bnf<br> </div>
<div><span class="gmail_quote">On 9/14/06, <b class="gmail_sendername">Barry Siegfried</b> <<a href="mailto:k2mf@nnj.k2mf.ampr.org">k2mf@nnj.k2mf.ampr.org</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">["Maiko Langelaar (ve4klm)" <<a href="mailto:maiko@pcs.mb.ca">maiko@pcs.mb.ca</a>> wrote]:
<br><br>> > I'm building an easy to install JNOS ...<br>> > First step was to move all the config files into one place<br>> > Comments in general on the move of files and renaming ?<br>><br>> I have no plans on doing so for the official version (not anytime
<br>> soon).<br>><br>> To me, the issue is not so much directory and file structure.<br>><br>> Perhaps a more important issue from the WINDOWS point of view, is<br>> that most users don't even know where configs are stored, transparent
<br>> to the general user, so does it really matter what the files are called,<br>> or where they are stored ? That *is* the windows way, isn't it ?<br><br>And that *is* unfortunate. Anyone whose sole experience in computing
<br>is operating on a Windows platform is learning absolutely nothing<br>about computing and how it works.<br><br>> An alternate method of simplifying JNOS setup is perhaps an installer<br>> program (so that the user never needs to see the directory and file
<br>> structure). I made a prototype installer some time ago just to do that.<br>> It OBVIOUSLY requires more work (understatement), but that was the<br>> idea. To keep general users AWAY from the configuration files.
<br><br>I take a slightly different point of view on this. I feel that the<br>more we *insulate* people from how to configure their programs properly,<br>the more we are simply dumbing down the users of xNOS. And the more
<br>we dumb down the users of xNOS, then the more those of us who do have<br>some knowledge about how the program works with all of its config<br>options are required to provide assistance when these people get into<br>trouble. The burden then falls to us. Time and time again I have
<br>seen thie happen and I know that Maiko and I both have gotten sucked<br>into situations where we are providing "help-desk" type services<br>for people who haven't a clue about where to start looking in order
<br>to solve a problem or something that is mis-configured. This can<br>get out of control VERY quickly.<br><br>> I mean, look at the darn REWRITE file. You don't know how badly I want<br>> to *get rid* of it, in the sense that it would be nice if the USER never
<br>> had to deal with it. Heck, I have trouble with it. You need a PHD or<br>> worse.<br><br>Yes. We all have had trouble with rewrite at one time or another in<br>our NOS experience. But how else can we learn? It is also probably
<br>not quite as bad as it is to configure sendmail on a linux machine.<br>Can we hardcode NOS to do some of the things that we always put into<br>rewrite? Of course we can, but even if we do that there is still<br>*some* degree of personalization we have to do to make parts of NOS
<br>do what we want them to do. And in order to do that, we need to<br>know SOMETHING about where the config files live and how to edit<br>them.<br><br>> On another note, the people that are going to use your installs need
<br>> to know that the directory structure may not conform to the official<br>> structure, so that if they search for help topics, they may get<br>> frustrated.<br><br>Yes, this *could* be a problem, but it hasn't been a show stopper
<br>for me or anyone else that uses the NOS that I use. Like Bill,<br>15 years ago I was extremely frustrated that some config files<br>were dumped here and some were dumped there for apparently no<br>other reason than this is where the originators of them decided
<br>to place them without any regard for how they functionally<br>integrated with the already existing other config files in NOS.<br><br>I dunno, for me it has been a help to "organize" the directory<br>and file structure of NOS into something coherent that made
<br>sense from both a functional standpoint and from a standpoint<br>of making it more organized where new config files could be<br>placed without having to guess where the best places for them<br>to live would be.<br><br>
73, de Barry, K2MF >><br> o<br> <|> Barry Siegfried<br>+---------/-\---------------------------+<br>| Internet | <a href="mailto:bgs@mfnos.net">bgs@mfnos.net</a> |<br>| HomePage |
<a href="http://www.mfnos.net/~bgs">http://www.mfnos.net/~bgs</a> |<br>+----------+----------------------------+<br>| Amprnet | <a href="mailto:k2mf@nnj.k2mf.ampr.org">k2mf@nnj.k2mf.ampr.org</a> |<br>| PBBS | k2mf@k2ge
.#cnj.nj.usa.noam |<br>+----------+----------------------------+<br><br>_______________________________________________<br>nos-bbs mailing list<br><a href="mailto:nos-bbs@lists.tapr.org">nos-bbs@lists.tapr.org</a><br><a href="https://lists.tapr.org/cgi-bin/mailman/listinfo/nos-bbs">
https://lists.tapr.org/cgi-bin/mailman/listinfo/nos-bbs</a><br></blockquote></div><br><br clear="all"><br>-- <br>Homer: Aequam memento rebus in arduis servare mentem Remember when life's path is steep to keep your mind even