diff --git a/LDP/howto/docbook/HOWTO-INDEX/hwSect.sgml b/LDP/howto/docbook/HOWTO-INDEX/hwSect.sgml
index 9e88b501..f3183d27 100644
--- a/LDP/howto/docbook/HOWTO-INDEX/hwSect.sgml
+++ b/LDP/howto/docbook/HOWTO-INDEX/hwSect.sgml
@@ -1442,6 +1442,18 @@ A guide to setting up your GNU/Linux workstation as a digital
VCR using the video4linux driver and a supported tuner card.
+
+
+
+Xterminals,
+Connecting X Terminals to Linux Mini-HOWTO
+
+
+Updated: December 2002.
+How to connect X Terminals with a Linux host using nfs, xfs, xdm and xdmcp.
+
+
+
diff --git a/LDP/howto/docbook/HOWTO-INDEX/miniChap.sgml b/LDP/howto/docbook/HOWTO-INDEX/miniChap.sgml
index 6324d409..086457d6 100644
--- a/LDP/howto/docbook/HOWTO-INDEX/miniChap.sgml
+++ b/LDP/howto/docbook/HOWTO-INDEX/miniChap.sgml
@@ -472,7 +472,7 @@ FBB,
FBB Packet-radio BBS mini-HOWTO
-Updated: November 2002.
+Updated: December 2002.
Covers the installation and use of the most popular amateur packet-radio
BBS software FBB.
diff --git a/LDP/howto/docbook/HOWTO-INDEX/miscSect.sgml b/LDP/howto/docbook/HOWTO-INDEX/miscSect.sgml
index f69ce38a..40cd7a1e 100644
--- a/LDP/howto/docbook/HOWTO-INDEX/miscSect.sgml
+++ b/LDP/howto/docbook/HOWTO-INDEX/miscSect.sgml
@@ -364,7 +364,7 @@ FBB,
FBB Packet-radio BBS mini-HOWTO
-Updated: November 2002.
+Updated: December 2002.
Covers the installation and use of the most popular amateur packet-radio
BBS software FBB.
diff --git a/LDP/howto/linuxdoc/FBB.sgml b/LDP/howto/linuxdoc/FBB.sgml
index b58dc011..4da1c601 100644
--- a/LDP/howto/linuxdoc/FBB.sgml
+++ b/LDP/howto/linuxdoc/FBB.sgml
@@ -6,11 +6,11 @@
FBB Packet-radio BBS mini-HOWTO
<author>Miroslav "Misko" Skoric, YT7MPB,
<tt/m.skoric@eunet.yu/
-<date>v1.16, 2002-11-30
+<date>v1.17, 2003-01-01
<abstract>
<nidx>linux windows nt amateur packet radio</nidx>
This mini-HOWTO covers the installation and use of
-the most popular amateur packet-radio BBS
+the most popular amateur packet-radio BBS server
software "FBB". That software works under Linux,
DOS and Windows operating systems. It serves as a
bulletin board system (BBS), a mailbox for
@@ -28,16 +28,16 @@ I have been using FBB amateur radio software since
early nineties. It was the time of DOS operating
system, so most of us, system administrators (or, so
called system operators - sysop's), used various
-packet radio software for DOS. Versions of FBB
-packet radio BBS software for DOS, today are
-known as "DosFBB".
+packet radio <em>server</em> software for DOS.
+Versions of FBB packet radio BBS <em>server</em>
+software for DOS, today are known as "DosFBB".
<p>
I still administer one DosFBB database in the SRV
(Amateur Radio Union of Vojvodina, a part of SRJ).
It is DosFBB v7.00g23 that runs on a 486DX computer
with 16 MB of RAM and Hercules b/w graphics. Since
-last December, it runs without any re-boot (excepting
+December 1999, it runs without any re-boot (excepting
some power failures). Before that, it was a bit
tricky to set up all memory management properly, in
order to avoid "frozen" system. Although this server
@@ -47,16 +47,15 @@ their client software under DOS, Windows, Linux
or any other operating system that offer amateur
packet radio abilities.
-<p>I have also used DosFBB v5.15c at home. Three years
-ago, when I got my new box, Pentium 166 with 32 MB of
-RAM and VGA color graphics, I switched to a Windows
-version of FBB ("WinFBB"). Author of the software, an
-radio amateur from France, Jean-Paul F6FBB, has made many
-versions of WinFBB, including 16 bit variant for
-Windows 3.x and Windows 9x as well as 32 bit variant for
-Windows NT. I have run both variants until now
-(at the moment it is 16 bit WinFBB v7.00g25 that runs
-ok under Windows NT 4.0).
+<p>I have also used DosFBB v5.15c on a 286/12 box at home.
+Five years ago, when I got better box, Pentium I at 166 MHz with
+32 MB of RAM and VGA color graphics, I switched to a Windows
+version of FBB ("WinFBB"). Author of the software, a radio amateur
+from France, Jean-Paul F6FBB, has made many versions of WinFBB,
+including 16 bit variant for Windows 3.x and Windows 9x as well as
+32 bit variant for Windows NT. I have run both variants until now
+(at the moment it is 16 bit WinFBB v7.00g25 that runs great under
+Windows NT 4.0).
<p>New: Since Spring 2001, I run WinFBB v7.00i
(17 March 2001) under Windows 2000 Professional.
@@ -75,8 +74,8 @@ Celeron 400 MHz with 96 MB of RAM and a big hard
disk that has enough room to install Linux and try
LinFBB ...
-<p>New: In July 2001, I added 128 MB of RAM so my
-home system is very confortable now.
+<p>New: In July 2001, I added more 128 MB of RAM
+so my home system is very confortable now.
<p>Finally, you should be aware what I want to
have here:
@@ -92,13 +91,13 @@ have here:
that runs in the background. In addition,
an interface for a local user (myself)
is needed, as well as an interface to
- monitor the radio chanell.
+ monitor the radio channel.
4. All three versions must be capable to
share the same configuration files, i.e.
to be able, for example, to begin a new
- session from the exact position where the
- other version has finished its own last
+ session from the exact position where the
+ other version has finished its own last
session.
5. I am not an expert in Linux, so I am
@@ -106,7 +105,8 @@ have here:
packages for Linux (just like to install
self executing software packages under
Windows). I mean of RPM packages. So, there
- are no source (re)compilations here :-)
+ are no source (re)compilations here at the
+ moment, but in the future we will see :-)
</verb></tscreen>
@@ -118,7 +118,7 @@ have here:
<item>First of all, you should have running Linux
with a GUI installed. I am fully satisfied
with Gnome GUI but I suppose that KDE will
- be ok too (or any other GUI available).
+ be OK too (or any other GUI available).
<p>
<item>Download or copy LinFBB (the main ftp site
@@ -126,19 +126,19 @@ have here:
"ftp.f6fbb.org"> but there are many mirror
sites too). For example, if you get a file
like <tscreen><verb>x700e_full.tgz</verb></tscreen>
- it means that it is X11 version 7.00e and it
- contains all you need in tgz archive to install
- the BBS. On the other hand, a name like
- <tscreen><verb>xd700g_full.tgz</verb></tscreen>
+ it means that it is X11 version 7.00e and it
+ contains all you need in tgz archive to install
+ the BBS. On the other hand, a name like
+ <tscreen><verb>xd700g_full.tgz</verb></tscreen>
means that it is not X11 but daemon version 7.00g
and it is also complete to unpack. Further,
- <tscreen><verb>x700f01.tgz</verb></tscreen>
- and <tscreen><verb>x700g.tgz</verb></tscreen>
+ <tscreen><verb>x700f01.tgz</verb></tscreen>
+ and <tscreen><verb>x700g.tgz</verb></tscreen>
are "upgrades" to any previous "full" package.
For example, after I have upgraded to <tt>x700g.tgz</tt>
I started to run X11 LinFBB 7.00g (04 August 1998).
Btw, X11 versions are not maintained anymore, but
- I still run it here. It has some bugs but I like it.
+ I still run it here. It has some bugs but I like it.
<p>
<item>Copy the archive file in <bf>/tmp</bf> directory.
@@ -167,19 +167,19 @@ have here:
where FBB will be installed. If you chose
<bf>/usr/local/fbb</bf> again, you will be told that
such directory already exists and all files
- will be overwritten. It is ok, so you should
- answer yes. If everything is ok, you should
- see on the screen that fbb system
+ will be overwritten. It is OK, so you should
+ answer yes. If everything is fine, you should
+ see on the screen that fbb system
directories are created. At the beginning
of that procedure, program will ask you for
- bbs's callsign, name of the city, QTH
+ BBS's callsign, name of the city, QTH
locator, your name etc. That details will
become a part of <bf>/usr/local/fbb/init.srv</bf>
- file.
+ file.
<p>
<item>After that, you MUST check this file
- <bf>again</bf> manually in order to fix some other
+ <bf>again</bf> manually in order to fix some other
details needed (because installation script does
not fix all parts within that file).
@@ -204,32 +204,32 @@ Linux (each of them having their own partition(s)
and file system). I wanted to have 'independent'
operating systems that won't see each other. So I
made two NT's partitions as NTFS partitions and
-rest of the space used Linux as ext2 partitions.
-Well, first I have installed WinFBB under NT and X11
+rest of the space used Linux as ext2 & swap partitions.
+Well, at first I have installed WinFBB under NT and X11
LinFBB under Linux. Both of them worked, but there
was a big "problem": I could not share their
system files. You might say: So, what a big deal.
-But, my FBB's should serve as packet-radio forwarding
+But, my FBB's should serve as packet-radio forwarding
stations (regardless of which one I boot at the
-moment), so it was really needed for new LinFBB
-to "know", for example, the position where WinFBB
-has stopped the mail exchange last time (and vice
+moment), so it was really needed for new LinFBB
+to "know", for example, the position where WinFBB
+has stopped the mail exchange last time (and vice-
versa, of course).</em>
-
+
<p>
<itemize>
<item>Well, in order to allow both WinFBB under
Windows NT and LinFBB under Linux to use
- some common files, it is needed to put these
- files in a place where both operating systems can
- "see". So I do that by re-installing
+ the same system files, it is needed to put these
+ files in a place that both operating systems are
+ able to "see". So I do that by re-installing
WinFBB onto a FAT (FAT16) partition that is
- recognized by NT and Linux too. The best way to do
+ recognized by NT and Linux too. The best way to do
that is to install a "fresh" copy of WinFBB on
- a FAT partition and to copy complete "old"
- WinFBB from NTFS partition over the fresh
- installation (whenever you are asked to
+ a FAT partition and to copy complete "old"
+ WinFBB from NTFS partition over the fresh
+ installation (whenever you are asked to
rewrite existing files, you should answer
"yes").
@@ -237,8 +237,8 @@ versa, of course).</em>
<item>When that is finished, you should have a "clone"
of the existing old WinFBB, but this time on
the FAT partition that is visible from under
- Linux. Anyway, you should check if the "new"
- installation is able to run as the "old" one.
+ Linux. Anyway, you should check if the "new" one
+ installation is able to run properly as the "old" one.
<p>
<item>I could also recommend you to check the file
@@ -249,7 +249,7 @@ versa, of course).</em>
<p>
<item>Some files can't be used as they are under <em>both</em>
- operating systems (without some neccesary
+ operating systems (without some necessary
changes). That's why some file names should
be renamed (or, at least, you should make
appropriate copies of some files):
@@ -266,13 +266,13 @@ versa, of course).</em>
FBB is able to recognize and accept those renamed files.
<p>
-<item>Make a backup of the actual WinFBB (I do this
+<item>Make a backup of the actual WinFBB (I do that
by copying the whole WinFBB file structure into
the other Windows partition that <em>won't</em> be
shared with Linux, like NTFS one). You'll never
know when a catastrophe may happen, so as a result,
- you won't be able to start neither of WinFBB or new
- LinFBB. As a precaution, the backup might be the
+ you won't be able to start neither of the "old" WinFBB or
+ the "new" LinFBB. As a precaution, the backup might be the
easiest way to recover at least the old WinFBB for
a while (until you configure your new LinFBB, ok?).
@@ -284,7 +284,8 @@ versa, of course).</em>
<p>
<item>Mount a shared FAT directory (where FBB files are):
<bf>mount -t vfat /dev/hda2 /mnt/win</bf>
- (for example).
+ (for example). If that works, later you may adopt that
+ change within your <bf>/etc/fstab</bf> configuration.
<p>
<item>Copy LinFBB archive to <bf>/tmp</bf> directory.
@@ -304,14 +305,14 @@ versa, of course).</em>
directory already exists so existing files
will be overwritten (by the way, if you
choose a mounted directory shared with NT,
- many original WinFBB files, located there, would be
- over-written by LinFBB files, so after returning
- to Windows, WinFBB might not be functional
- like before).
+ many original WinFBB files, located there, would be
+ over-written by LinFBB files, so after returning
+ to Windows, WinFBB might not be as functional
+ as before this installation).
<p>
<item>Copy <bf>/usr/local/fbb</bf> to <bf>/mnt/win/fbb</bf> but do
- *not* rewrite existing files with the new files
+ *not* rewrite existing files with the new files
having the same names.
<p>
@@ -327,7 +328,7 @@ versa, of course).</em>
<item>Copy newly edited <bf>/mnt/win/fbb/init_l.srv</bf>
over the <bf>/mnt/win/fbb/init.srv</bf> (if you do
not do that, maybe you wouldn't be able to start LinFBB
- using <bf>./xfbb.sh</bf>, like me at first).
+ using <bf>./xfbb.sh</bf>, like me at the first time).
<p>
<item>Copy <bf>/mnt/win/fbb/system/port_w.sys</bf> to
@@ -349,19 +350,19 @@ versa, of course).</em>
<p>
<item>Start the script <bf>./xfbb.sh</bf> to run LinFBB.
- If everything is ok, your LinFBB under Linux
- should run with the same configuration as
+ If everything is OK, your LinFBB under Linux
+ should run with the <em>same</em> configuration as
your "old" WinFBB under Windows. From this point,
both FBB's should behave very similar (actually,
I must admit that WinFBB has much better visual
quality than X11 LinFBB, but probably the reasons
for that you may find in Windows-vs.-Linux-GUI
- quality battles). FYI, my actual WinFBB is v7.00g25
+ quality "battle field"). FYI, my actual WinFBB is v7.00g25
(05 January 2000) and X11 LinFBB is v7.00g (04 August
1998).
<p>
-<item>Although this combination WinFBB/X11 LinFBB works ok, I
+<item>Although this combination WinFBB/X11 LinFBB works fine, I
have noticed some problems. For example, LinFBB
was not able to use <tt>amsat</tt> forward_to_file routine
(located in <bf>/mnt/win/fbb/system/fwd</bf> directory),
@@ -383,7 +384,7 @@ versa, of course).</em>
<p>
On the other side, LinFBB's <tt>amsat.sys</tt> (located
- in <bf>/etc/ax25/fbb/fwd</bf> directory) has suggested
+ in <bf>/etc/ax25/fbb/fwd</bf> directory) has suggested
something like this:
<p>
@@ -403,11 +404,11 @@ versa, of course).</em>
<p>
Well, then I copied LinFBB's <tt>amsat.sys</tt>
into <bf>/mnt/win/fbb/system/fwd</bf> directory so
- it could become functional. As a result, I got
- <em>two</em> <tt>amsat.txt</tt> files, one of them
- for each of WinFBB/LinFBB, and of course, both files
- appeared on different locations: the first one was
- <bf>/mnt/win/fbb/system/sat/amsat.txt</bf> and it
+ it could become functional. As a result, I got
+ <em>two</em> <tt>amsat.txt</tt> files, one of them
+ for each of WinFBB/LinFBB, and of course, both files
+ appeared on different locations: the first one was
+ <bf>/mnt/win/fbb/system/sat/amsat.txt</bf> and it
was filled by WinFBB; the other one was in
<bf>/var/ax25/fbb/sat/amsat.txt</bf> and was filled by
LinFBB. I didn't like it that way.
@@ -434,25 +435,25 @@ versa, of course).</em>
<p>
As you can see now, when LinFBB is active, its
- <tt>amsat.sys</tt> will not forward into
- its "native" location of <tt>amsat.txt</tt>.
- Instead of that, it will go to the location
- of the WinFBB's <tt>amsat.txt</tt> and just
+ <tt>amsat.sys</tt> will not forward into
+ its "native" location of <tt>amsat.txt</tt>.
+ Instead of that, it will go to the location
+ of the WinFBB's <tt>amsat.txt</tt> and just
add some new materials into it, ok?
<p>
- Well, now it's up to you to decide what to do
+ Well now it's up to you to decide what to do
with your growing <tt>amsat.txt</tt>. An old
- DosFBB manual says that the 'batch' file
- (I suppose, the old good <tt>APPEL.BAT</tt>)
+ DosFBB manual says that the 'batch' file
+ (I suppose, the old good <tt>APPEL.BAT</tt>)
should be adopted in order for <bf>SATUPDAT.EXE</bf>
- can update <em>sat</em> tracking data and, after
- that, to erase AMSAT.TXT because it is not
- needed anymore. Well, I haven't found a way to
- manage that in both WinFBB and LinFBB. Actually,
- whenever I perform housekeeping from either of them,
- it seems that AMSAT.TXT remains intact. Happily,
- it doesn't grow too much, so it's not a big problem.
+ can update <em>sat</em> tracking data and, after
+ that, to erase AMSAT.TXT because it is not
+ needed anymore. Well, I haven't found a way to
+ manage that in both WinFBB and LinFBB. Actually,
+ whenever I perform housekeeping from either of them,
+ it seems that AMSAT.TXT remains intact. Happily,
+ it doesn't grow too much, so it's not a big problem.
Any suggestion here?
</itemize>
@@ -462,18 +463,18 @@ versa, of course).</em>
<p>
<em>Notice: Well, I have been using Protus
-connection filters for a long time now. At
-first, it was version 3.1/1.2 for DosFBB515c
-and, later, version 3.3 for Dos/WinFBB700.
-I have found Protus as very useful utility
-because of its implementation of BBS-to-BBS
-forwarding protection using MD2 algorythm.
-One of the reasons I am going to cover Protus
-in this document is a fact that its author
-haven't made a manual in english yet. I keep
-trying to translate the original manuals
-from spanish into english, but it is a hard
-process. Any good 'spanish-to-english'
+<bf>connection filters</bf> for a long time now.
+At first, it was the version 3.1/1.2 for DosFBB515c
+and, later, version 3.3 for Dos/WinFBB700. I have
+found Protus as very useful utility because of its
+implementation of automated BBS-to-BBS
+forwarding protection, using MD2 algorithm.
+One of the reasons to cover Protus
+in this document is the fact that its author
+haven't made a manual in English yet. I keep
+trying to translate original manuals
+from Spanish into English, but it is a hard work.
+Any good 'spanish-to-english'
translator is welcomed to contact me:
<htmlurl url="mailto:m.skoric@eunet.yu"
name="m.skoric@eunet.yu">.</em>
@@ -490,8 +491,8 @@ Protus offers several interesting features:
<p>
<item>It can send messages to users who have
- normal access, informing about utility's
- existence,
+ usual, non-restricted access, informing about
+ utility's existence,
<p>
<item>It can send messages to users who have no
@@ -514,14 +515,14 @@ Protus offers several interesting features:
<p>
<item>Messages mentioned above could be translated
into various languages and used similarly as various
- language files that FBB uses,
+ language files that FBB system use,
<p>
<item>Messages mentioned above could be different
for different BBS ports,
<p>
-<item>Protus could be activated/deactivated at various
+<item>Protus could be activated/deactivated at various
intervals of time using CRON.SYS system file,
<p>
@@ -531,7 +532,7 @@ Protus offers several interesting features:
<p>
<item>...
-</itemize>
+</itemize>
<p>
@@ -544,43 +545,43 @@ radio BBS, using Protus type of, so called, <em>c_filter</em>:
<item>Users of Dos/WinFBB versions of Protus
already know that it is needed to create a new
- directory <bf>\FBB\PROTUS</bf> where several *.PRT
- files should be placed. In addition, the
+ directory <bf>\FBB\PROTUS</bf> where several
+ *.PRT files should be placed. In addition, the
main C_FILT*.DLL files should be copied
- into <bf>\FBB\BIN</bf> as well as a couple of "system",
- (i.e. config) *.PRT files that are going to be
- within <bf>\FBB\SYSTEM</bf> directory.
+ into <bf>\FBB\BIN</bf> directory, as well as a couple
+ of "system", (i.e. config) *.PRT files that are going to
+ be within <bf>\FBB\SYSTEM</bf> directory.
<p>
<item>After the sysop has copied all files into
- the proper locations, it is needed to make
+ their proper locations, it is needed to make
some configuration. The most important files
- are two "system" ones: <tt>CONFIG.PRT</tt> and <tt>USERS.PRT</tt>
- that should be carefully adopted to any
- particular situation. Other *.PRT files will
- work as they are in original, but they might
+ are two "system" ones: <tt>CONFIG.PRT</tt> and
+ <tt>USERS.PRT</tt> that should be carefully
+ adopted to any particular situation. Other *.PRT
+ files will work as they are in original, but they may
be translated because they are originated
- in spanish (those files are just textual
+ in Spanish (those files are just the parts of
information that are sent to users who
connect to the BBS). For your information,
I usualy don't care much about, because my
BBS's are so called "open systems". It means
they work quite normal for <em>all</em> users in the
- same way as they worked <em>before</em> implementing Protus.
- Only a couple of callsigns have password
- installed and, when connecting, they know
- what they are doing, so, they don't need
+ same way as they worked <em>before</em>
+ implementing Protus. Only a couple of callsigns
+ have password installed and, when connecting,
+ they know what they are doing, so, they don't need
any additional info. Your mileage may vary.
<p>
-<item>So far - so good. When everything mentioned is
- done, you have to restart your FBB in order
+<item>So far - so good. After everything mentioned has
+ been done, you have to restart your FBB in order
for Protus utility to be activated. In all
connections to your BBS (including console),
you should see a line like this: <bf>{PROTUS-4.0}</bf>
- just after a line [[FBB-7.00-AB1FHMRX$]. It
+ just after the well known line [[FBB-7.00-AB1FHMRX$]. It
only gives an information that Protus is active on the
- system. Users of your system who don't have
+ system. Users of your BBS who don't have
their passwords, connect just normally as before.
Users who's callsigns have password implemented,
are prompted for password just after their connections.
@@ -588,21 +589,21 @@ radio BBS, using Protus type of, so called, <em>c_filter</em>:
<p>
<item>The author of Protus, Jesus EB5AGF, has made
several working "modes" of its utility. It
- is possible for users to get various kinds
- of security: a fixed phrase as a password
- (similar when you connect to the Internet
+ is possible for users to have various kinds
+ of passwords: a fixed phrase (similar as those you
+ are used to when connect to the Internet
via telephone line, but this way the phrase
can be masqueraded within the longer answer);
- a changeable answer to the 5 numbers (just
+ a changeable answer to the 5 random numbers (just
like usual FBB sysop's password); a mode
that uses automatic answer from user's client
packet programs; implementation of MD2 and
- MD5 algorythms; FBB-to-FBB automatic forward
+ MD5 algorithms; FBB-to-FBB automatic
protection etc. FYI, my WinFBB is equipped
- with 16-bit Protus 4.0 (13. August 1999).
+ with 16-bit Protus 4.0 (13 August 1999).
There is also a 32-bit module of the same date
that would be called from within 32-bit WinFBB
- (I haven't tested those two).
+ (I haven't tested those 32-bit applications).
<p>
<item>Well, the situation regarding working location
@@ -610,43 +611,43 @@ radio BBS, using Protus type of, so called, <em>c_filter</em>:
I have become familiar to the directory structure
that DosFBB and WinFBB versions of Protus have
been using, so I considered that it was enough
- just to copy the same directory structure when
- I started the installation of Protus under LinFBB.
+ to implement the same directory structure when
+ I started the installation of Protus under LinFBB.
It was wrong. After having pulled out the
remaining hair, the things started to work, so,
now I am going to tell you what to do.
<p>
-<item>I have already told you that I have
- been running here both WinFBB under Windows NT
- and LinFBB under Linux (see also <tt>Linux+WinNT
- mini-HOWTO</tt> and <tt>Lilo mini-HOWTO</tt>). That means
- all Protus stuff has already been installed in
- a way WinFBB has required, except <em>Linux</em>
- executable of <em>c_filter</em> file. I
- put that file into <bf>/fbb/bin</bf> directory and,
- after the next restart of LinFBB, I got the
+<item>I have already told you that I have been running
+ here both WinFBB under Windows NT and LinFBB
+ under Linux (see also <tt>Linux+WinNT mini-HOWTO</tt>
+ and <tt>Lilo mini-HOWTO</tt>). That means all Protus
+ stuff has already been installed in a way WinFBB has
+ required, except <em>Linux</em> executable of
+ <em>c_filter</em> file. I put that one file into <bf>/fbb/bin</bf>
+ directory and, after the next restart of LinFBB, I got the
info mentioned above: {PROTUS-4.0}. But the
password protection was not likely to work.
- I was told to make a new directory <bf>/var/ax25/fbb/protus</bf>
- and put *.prt files there. I <em>didn't move</em> *.PRT
- files from <bf>\FBB\PROTUS</bf> but <em>copied</em> them into
- the new location, because I wanted Protus to
- run further under WinFBB as before. The utility
- still didn't want to run, unless I copied
- <em>also</em> *.PRT files from <bf>\FBB\SYSTEM</bf> to the
- new location (<bf>/var/ax25/fbb/protus</bf>). After I
- did that, Protus became fully functional.
+ I was told by the author to make a new directory
+ <bf>/var/ax25/fbb/protus</bf> and put *.PRT files there.
+ I <em>didn't move</em> files from <bf>\FBB\PROTUS</bf>
+ but rather <em>copied</em> them into the new location,
+ because I wanted Protus to continue working under WinFBB
+ as before. The utility still didn't want to run, unless I
+ <em>also</em> copied additional two *.PRT files from
+ <bf>\FBB\SYSTEM</bf> to the same new location
+ (<bf>/var/ax25/fbb/protus</bf>). After I did that, Protus
+ became functional.
<p>
<item>Well, I suppose, the above info would be
useful for those of you who intend to run
*both* Windows and Linux FBB's on the same machine.
For the majority of LinFBB-only users, it is just
- important to make <bf>/var/ax25/fbb/protus</bf>
- where <em>all</em> *.prt files should be placed. <em>Only</em>
- c_filter executable should go to <bf>/fbb/bin</bf>
- and that's it.
+ important to make <bf>/var/ax25/fbb/protus</bf>
+ where <em>all</em> *.prt files should be placed.
+ <em>Only</em> c_filter executable should go to
+ <bf>/fbb/bin</bf> and that's it.
<p>
<item>About FBB-to-FBB protection: *both* partners
@@ -655,55 +656,53 @@ radio BBS, using Protus type of, so called, <em>c_filter</em>:
same at *both* sides of the link. The versions
of Protus don't need to be the same (neither
the versions of FBB, neither the operating
- systems, HI!). Anyway, MD5 algorythm will only
+ systems, HI!). Anyway, MD5 algorithm will only
work if both parties have Protus 4.x and
above (I still don't use that, but it is not
- a problem, because my two boxes, DosFBB/Protus3.3 and
- WinFBB/LinFBB/Protus4.0, make all things ok with MD2).
+ a problem, because my two boxes, DosFBB-Protus3.3 and
+ WinFBB/LinFBB-Protus4.0, make all things OK with MD2).
<p>
<item>One of the interesting features of Protus is to
- log unsuccessful connections. Due to the
+ log unsuccessful connections. Due to the
<em>different</em> locations of *.prt files here, I have
- separate logs for WinFBB and LinFBB c_filtering.
- Those of you who are going to run only one version of
- FBB, will have <em>one</em> complete log of connection
- errors, your users make when they try
- connecting your BBS.
+ separate logs for WinFBB and LinFBB "c_filtering".
+ Those of you who are going to run only one operating
+ system and appropriate version of FBB, will have <em>one</em>
+ complete log of connection errors, users make when try to
+ connect your BBS.
<p>
<item>As it was told earlier, if you implemented
password protection for only <em>some</em> of your
users (but not for all of them who connect
normally) - your system is considered as
- an "open" one. It means that will be logged
+ the "open" one. It means that will be logged
only unsuccessful tries to enter the system
by "protected" callsigns. But, if you decided
that your BBS can be accessed by <em>only</em> those
- callsigns who are protected with Protus, it
- means that your system is the "closed" one.
+ callsigns who have Protus password, that
+ means your system is the "closed" one.
Then, there is no way a user could enter your
FBB unless its callsign has given a password
within your Protus. Any unauthorized try to
- connect your BBS is logged.
+ connect your BBS is also logged.
<p>
-<item>In addition,
- you may decide to have a "guest" access or
- a "read-only" as <em>default</em> for some ports
- and/or for users who enter the wrong password.
- Many combinations are possible. You could
- even password protect your own FBB console!
+<item>In addition, you may decide to have a "guest"
+ access or a "read-only" as <em>default</em> for
+ some BBS's access ports and/or for users who enter
+ the wrong password. Many combinations are possible.
+ You could even password protect your own FBB console!
<p>
<item>To finish with this topic for now, just to
inform you that my X11 LinFBB is equipped
- with Protus v4.1b7 (15. February 2000). It
+ with Protus v4.1b7 (15 February 2000). It
has some minor bugs, for example, it logs
- incoming connections with a SSID of -48 if
- a user doesn't have a SSID at all (of
- course, a SSID of -0 would be expectible
- in such case).
+ incoming connections with a SSID of -48 if
+ a user doesn't have a SSID at all (of course,
+ in such case a SSID of -0 would be expected).
</itemize>
@@ -716,7 +715,7 @@ as many as possible versions of this great
software (Jean-Paul, F6FBB, must be very proud after
reading these words now). What I think when mention
"as many as possible versions" means that we have
-learned how to get both WinFBB and X11 LinFBB on
+learned how to get both WinFBB and X11 LinFBB on
the same computer. But, that's not all. There is a
variety of daemon versions of LinFBB. In this section
we are going to discuss how to *add* a daemon LinFBB
@@ -726,10 +725,10 @@ to the existing two: X11 LinFBB and WinFBB!</em>
<itemize>
<item>Well, many amateurs have suggested me to install
- a couple of packages that weren't look to me as
- too much needed for LinFBB daemon - to be run.
- Anyway, I installed those packages <em>before</em>
- the installation of LinFBB itself:
+ a couple of packages that weren't look to me as
+ really requested for LinFBB daemon to work.
+ Anyway, I installed those packages <em>before</em>
+ the installation of LinFBB itself:
<p>
<tscreen><verb>
@@ -742,8 +741,8 @@ to the existing two: X11 LinFBB and WinFBB!</em>
<item>Now it is the right time to install <tt>fbbsrv.rpm</tt>
package. The archive was composed to make its
own directories, as "base" directories. The last new
- version to start with, that I have managed to find as
- a <tt>.rpm</tt> package, was 7.01f Release 4 (09. December
+ version to start with, that I have managed to find as
+ a <tt>.rpm</tt> package, was 7.01f Release 4 (09 December
1999).
<p>
@@ -791,8 +790,8 @@ to the existing two: X11 LinFBB and WinFBB!</em>
<p>
<item>Directory of users, instead of .../home/fbbdos/...,
- should be ...<bf>/mnt/win/fbb/users</bf>... (case you
- don't mind that both your WinFBB and LinFBB users handle
+ should be ...<bf>/mnt/win/fbb/users</bf>... (case you
+ don't mind that both your WinFBB and LinFBB users handle
the same location for users' files)
<p>
@@ -830,7 +829,7 @@ to the existing two: X11 LinFBB and WinFBB!</em>
be executed within an <em>xterm</em>. If
everything is OK, you should get several
system messages on your screen, ending with
- something like:
+ something like:
<p>
<tscreen><verb>
@@ -847,17 +846,17 @@ to the existing two: X11 LinFBB and WinFBB!</em>
also be activated within another <em>xterm</em>.
<p>
-<item>If you are like me, you would like to activate one
+<item>If you are like me, you would like to activate one
more <em>xterm</em> with xfbbC in a way to monitor
your radio frequency. If you have enough room on
- your screen, you may place all three <em>xterm</em>
- windows side by side.
+ your screen, you may place all three <em>xterm</em>
+ windows side by side.
<p>
<item>When you finish your xfbbC console session, it is suitable
to use the same <em>xterm</em> to eventually stop the
daemon. First of all, with the command <bf>ps ax</bf>
- you should locate PIDs of xfbb.sh shell and daemon itself,
+ you should locate PIDs of xfbb.sh shell and daemon itself,
that you may <bf>kill</bf> after that.
</itemize>
@@ -869,7 +868,7 @@ to the existing two: X11 LinFBB and WinFBB!</em>
<sect1>LinFBB v7.02g
<p>
-<em>Notice: Well, the main trouble I have discovered with 7.01f
+<em>Notice: Well, the main trouble I have discovered with 7.01f
daemon was the absence of Protus c_filter protection. As I told you
before, Protus is a "third-party" product, so it might have
some problems with the compatibility to LinFBB itself. Anyway,
@@ -880,15 +879,15 @@ special requirements over some "third-party" software.</em>
<itemize>
<item>I also noticed that my version of Protus was <em>newer</em>
- than the version of daemon LinFBB I had at first. Beside
- that, some hams, as well as F6FBB himself, have suggested me
+ than the version of daemon LinFBB I had at first. Besides
+ that, some hams, including F6FBB himself, have suggested me
to upgrade LinFBB. I have also found a "problem" that I am
still new in compiling Linux software, so, I'd rather
- look for pre-compiled packages to install easily.
+ look for pre-compiled packages for easy installation.
<p>
-<item>Jose, HI8GN, has offered daemon LinFBB v7.02g as a
- <tt>.rpm</tt> package (18 September 2000). I got it
+<item>Jose, HI8GN, has offered daemon LinFBB v7.02g as a
+ <tt>.rpm</tt> package (18 September 2000). I got it
from his site:
<url url="http://hi8gn.dynip.com/indice.html" name=
"http://hi8gn.dynip.com/indice.html">. But, when I tried
@@ -897,45 +896,45 @@ special requirements over some "third-party" software.</em>
<p>
<item>Then I had to uninstall the old package, after what
- some config files remained in their locations, but
- with new <tt>.rpmsave</tt> extensions. It was nice,
- so I could use them later to update my new-installed
+ some config files remained in their locations, but
+ with new <tt>.rpmsave</tt> extensions. It was nice,
+ so I could use them later to update my new-installed
config files.
<p>
<item>Btw, the installation of Jose's package was performed
without problems, but the new daemon was not likely to run
- as I expected, although I tried to configure it as best
+ as I expected, although I tried to configure it as best
as I could. Not quite sure, but it looked to me that F6FBB
is likely to implement some changes not only to the main
executables but to shell files too. So, I have decided to
- save copies of these new
- <tt>xfbbd</tt> and <tt>xfbbC</tt> executables from 7.02g
- package (I have made it with adding extensions like
+ save copies of these new
+ <tt>xfbbd</tt> and <tt>xfbbC</tt> executables from 7.02g
+ package (I have made it with adding extensions like
.702 to the files). After that, I *uninstalled* the rest
of that 7.02 <tt>.rpm</tt>, in order to install the previous
version of LinFBB once again - the version that I was
satisfied with.
<p>
-<item>So far - so good. The "old" 7.01f version was installed again
- and tested one more time to be sure it was ok. Then, I just
+<item>So far - so good. The "old" 7.01f version was installed again
+ and tested one more time to be sure it was OK. Then, I just
copied the previously saved executables from the new package,
- over the "old" executables. In a couple of minutes, the new
+ over the "old" executables. In a couple of minutes, the new
daemon LinFBB v7.02g has come in place and function. Comments...?
<p>
<item>Well, the new daemon is likely to check for some more directories
- than the older version (mostly regarding <tt>7plus</tt>
+ than the older version (mostly related to <tt>7plus</tt>
operations). Next, its <tt>xfbbC</tt> console client looks better
- than the previous version. But, I still miss
- <tt>xfbbX</tt> client, that I have found not functional.
- I hope it will be fixed soon. Finally, Protus
+ than the previous version. But, I still miss graphical
+ <tt>xfbbX</tt> client, that I have found not able to become
+ activated. I hope it will be fixed soon. Finally, Protus
<tt>c_filter</tt> utility is active too.
<p>
<item>An interesting question might be: is that now a really upgraded
- LinFBB daemon or not? Actually, I haven't changed the "old"
+ LinFBB daemon or not? Actually, I haven't changed the "old"
script <tt>xfbbd.sh</tt> with the new one, because during the
first tests with the new 7.02 I was getting lots of error messages.
Looks that the directory structure was a bit complicated for me
@@ -943,9 +942,9 @@ special requirements over some "third-party" software.</em>
After I returned to <tt>xfbbd.sh</tt> from 7.01 package, the
BBS finally started to be run, though without some functions
like over-night maintaining (that one problem I solve in a way
- to boot the BBS as WinFBB under Windows NT where that task is ok).
+ to boot the BBS as WinFBB under Windows NT where that task is OK).
In addition, there are still some mysterious messages telling
- that <tt>m_filter</tt> has not been found or something like that.
+ that <tt>m_filter</tt> has not been found or something like that.
The next tasks are to solve these issues.
</itemize>
@@ -954,28 +953,28 @@ special requirements over some "third-party" software.</em>
<sect1>LinFBB v7.03
<p>
-<em>Notice: As I have said in the previous section,
+<em>Notice: As I have said in the previous section,
I haven't found an easy way to upgrade FBB's (its main
executables), without temporary uninstalling an
older version, then to install the new version - in
-order to get new executables. After that is done, a
+order to get new executables. After that is done, a
reverse procedure must be put in place.</em>
<p>
<itemize>
-<item>Well, it was needed to get 7.03 package (09 December 2000)
- as an <tt>.rpm</tt> package from
- <url url="http://www.f6fbb.org/versions.html"
+<item>Well, it was needed to get 7.03 package (09 December 2000)
+ as an <tt>.rpm</tt> package from
+ <url url="http://www.f6fbb.org/versions.html"
name="www.f6fbb.org/versions.html">,
that was suggested by Jean-Paul, F6FBB. Anyway,
- soon after there appeared several mirror sites,
+ soon after there appeared several mirror sites,
offering 7.03 too.
<p>
<item>If you use <em>GnomeRPM</em>, it is easy to uninstall
your actual LinFBB (If you just try to install new
- <tt>.rpm</tt> over the existing LinFBB you will get
+ <tt>.rpm</tt> over the existing LinFBB you will get
some error messages complaining that you already have
FBB installed on the computer). Anyway, after
the uninstallation, there you will find some config
@@ -991,17 +990,18 @@ reverse procedure must be put in place.</em>
<p>
<item>So far - so good. Now you should *uninstall* the
7.03 package (of course, <tt>.703</tt> files won't
- be unistalled automatically).
+ be unistalled automatically). Uninstall? Why? You will
+ find out soon, read on ...
-<p>
+<p>
<item>Once again, you should *install* the <em>last</em>
- one version of LinFBB daemon, that works ok with its
+ one version of LinFBB daemon, that works OK with its
own <tt>xfbb.sh</tt> (in my case, that is 7.01f).
<p>
<item>For sure, many of you might find it odd, but
now it is the right time for the executables from
- <bf>/usr/sbin</bf> (I mean of all fbb executables,
+ <bf>/usr/sbin</bf> (I mean of all fbb executables,
except those who were renamed to <tt>.703</tt>) to get
their new extensions (in my case, that is <tt>.701</tt>).
@@ -1048,8 +1048,9 @@ reverse procedure must be put in place.</em>
<p>
<item>Recently, I was informed that <bf>xfbbC</bf>
is suitable mostly for sysops, so the other users
- (who might also have access to the local
- keyboard) should rather try something like this:
+ (who might also have access to the local
+ keyboard) should rather try something less
+ dangerous, like this:
<p>
<tscreen><verb>
@@ -1058,89 +1059,87 @@ reverse procedure must be put in place.</em>
<p>
<item>... where 'localhost' and '6300' may vary from
- bbs to bbs. I was pleasently surprised
+ BBS to BBS. I was pleasantly surprised
when discovered that <bf>telnet</bf> is much more
- practical for ordinary bbs users than <bf>xfbbC</bf>.
+ suitable for ordinary BBS users than <em>sysops'</em>
+ client <bf>xfbbC</bf>.
<p>
-<item>Folks, I also think of writing a chapter about
+<item>Folks, I also think of writing a chapter about
FBB's system configuration. Until something
like that appears in this howto, you should know
that all of those callsigns who are going to
use <bf>xfbbC</bf> have to be added into
- your <tt>passwd.sys</tt> file. In addition, all
- of these folks who are going to <bf>telnet</bf>
+ your <tt>passwd.sys</tt> file. In addition, all
+ of these folks who are going to <bf>telnet</bf>
the BBS, have to be declared as users with
the 'M' flag (modem users). It is up to your
security precautions, if either of them would
- eventually have <em>'root'</em> capabilities
- to that Linux box itself.
+ eventually have <em>'root'</em> capabilities
+ to that one Linux machine itself.
<p>
<item>My next task is to use an old i286/12 MHz box,
having only 1 MB of RAM, running DOS 5.0, as a
'telnet client' computer. That box has a network
card so I would like to 'connect' to the
BBS from that one 'telnet client' box. If that
- succeedes, it would be a good preparation for
- installing another LinFBB (in the local school
- club), where I would have several similar 286
- computers. It would be nice to offer more than
- one school kid the opportunity to 'connect' the
- BBS simultanously, using a bunch of vintage
- 'telnet client' computers.
-
-</itemize>
+ succeeds, it would be a good preparation for
+ installing another LinFBB (in the local school
+ club), where several old 286 computers will also
+ be available. It would be nice to offer more than
+ one student-amateur the opportunity to 'connect' the
+ BBS simultaneously, using a bunch of vintage
+ 'telnet client' computers.
+
+</itemize>
<p>
<sect1>LinFBB v7.04
<p>
-<em>Notice: Maybe I have already explained that I
-use Red Hat 6.2 at home. That's why I usualy look
-for <tt>.rpm</tt> packages that have been made for
-that particular Linux distribution. And not only that. I have
+<em>Notice: Maybe I have already explained that I
+use Red Hat 6.2 at home. That's why I usually look
+for <tt>.rpm</tt> packages that have been made for
+that particular Linux distribution, but not only that. I have
also tried to use Red Hat 7.1 but it seemed not to support
-an older Xwindows application, LinFBB 7.00g (04 August 1998).
-When I noticed that, I returned back to Red Hat 6.2.</em>
+an older Xwindows application, LinFBB 7.00g (04 August 1998).
+When I noticed that issue, I returned back to Red Hat 6.2.</em>
<p>
<itemize>
-<item>Well, I started with downloading the package
- <tt>xfbb-7.04-2.i386.rpm</tt> (07 August 2001)
- from
- <url url="http://www.f6fbb.org/versions.html"
+<item>Well, I started by downloading the package
+ <tt>xfbb-7.04-2.i386.rpm</tt> (07 August 2001)
+ from <url url="http://www.f6fbb.org/versions.html"
name="www.f6fbb.org/versions.html">
<p>
-<item>Folks, this time I finally decided to install
- version 7.04
- as a completely "fresh" installation, i.e.
- without some parts of any previously used "daemon"
- on the disk.
- It means that I have uninstalled the last
- daemon version I was using before, and, in addition,
- I also removed the old executables. Of course,
+<item>Folks, this time I finally decided to install
+ version 7.04 as a completely "fresh" installation, i.e.
+ without some parts of any previously used "daemon"
+ on the disk. It means that I have uninstalled the last
+ daemon version I was using before, and, in addition,
+ I also removed the old executables. Of course,
before the uninstalation, I made the backup of some
config files that are not version depending
(like <tt>/etc/fbb.conf</tt>), in order to avoid
editing the same "defaults" once again and again :-)
-<p>
+<p>
<item>The setup procedure has reported some dependency
- issues. I didn't want to get bored with them
- so I repeated the installation once again with
- "--force" and "--nodeps" options.
+ issues. I didn't want to get bored with them so I repeated
+ the installation once again with "--force" and "--nodeps"
+ options.
<p>
-<item>So far - so good. Then, I replaced a couple of
- "default" files with the <em>saved</em> ones.
+<item>So far - so good. Then, I replaced a couple of
+ "default" files with the <em>saved</em> ones.
After that being accomplished, I mounted a
- FAT partition with WinFBB's system files,
- made a pray and started LinFBB's daemon. It was
- an interesting new experience to try HI8GN's
+ FAT partition with WinFBB's system files,
+ made a pray and started LinFBB's daemon. It was
+ also an interesting new experience to try HI8GN's
script <bf>/usr/sbin/fbb start</bf> (activated in an
- <em>xterm</em>) to start the server. Although there
+ <em>xterm</em>) to start the server. Although there
were no usual lines:
<p>
<tscreen><verb>
@@ -1149,12 +1148,12 @@ When I noticed that, I returned back to Red Hat 6.2.</em>
</verb></tscreen>
<p>
-on the screen, TNC's <em>PTT</em> lamp confirmed
+on my screen, TNC's <em>PTT</em> lamp confirmed
that a <em>beacon</em> was really transmitted.
<p>
-<item>Then I wanted to try HI8GN's script
- <bf>/usr/sbin/monitor</bf> to see what's
+<item>Then I wanted to try HI8GN's script
+ <bf>/usr/sbin/monitor</bf> to see what's
going on the frequency. Although
I got something like:
<p>
@@ -1175,43 +1174,43 @@ and type:
</verb></tscreen>
<p>
-Bingo! From FBB's prompt I have entered the gateway
+Bingo! From the usual FBB's prompt I entered the gateway
and typed the familiar "M" ("Monitor") command.
-Interestingly, as soon as I "telneted" to the
+Interestingly, as soon as I "telnet-ed" to the
BBS, <bf>/usr/sbin/monitor</bf> window, mentioned
-above, started to copy whatever was going on the
-"telnet" <em>xterm</em> as long as that telnet session
-was closed. I was in doubt if that was ok or not,
-because I expected to see the traffic on the radio
+above, started to copy whatever was going on the
+telnet <em>xterm</em> as long as that telnet session
+was closed. I was in doubt if that was OK or not,
+because there I expected to see the traffic from the radio
channel - regardless being connected to the system or
not. Any suggestion here?
<p>
-<item>Well, then I wanted to use
- <bf>/usr/sbin/bbs</bf>, in order to connect
- to the client_console (<em>xfbbC</em>). Looks
- that there was a line in HI8GN's script:
+<item>Well, then I wanted to use <bf>/usr/sbin/bbs</bf>,
+ in order to connect to the client's (or better to say: sysop's)
+ console (<em>xfbbC</em>). Looks that there was a line in
+ HI8GN's script:
<p>
<tscreen><verb>
xfbbC -c -f -h localhost -i [callsign] -w [password]
</verb></tscreen>
<p>
-with missing ./ (dot slash) before xfbbC, so the script
-was not likely to be executed. Instead of that it reported
-that command couldn't be found. Anyway, <em>xfbbC v3.01</em>
-itself appeared to work nice. It is possible to monitor the
+with missing ./ (dot slash) before xfbbC, so the script
+was not likely to be executed. Instead of that it reported
+that command couldn't be found. Anyway, <em>xfbbC v3.01</em>
+itself appeared to work nice. It is still possible to monitor the
working channel too (using the "M" command from within the
gateway), but this is not a valuable solution because
while "Monitor ON", it is not confortable to do
-anything else within the gateway. Once again, solutions
-are welcomed!
+anything else within the gateway. Once again, solutions
+are welcomed!
<p>
-<item>Although the active <em>xfbbC</em> session can be
+<item>Although the active <em>xfbbC</em> session can be
easily terminated using "B" ("Bye") command, a fooled
<bf>/usr/sbin/monitor</bf> can not. The user has to
- find its <em>process number</em> using <bf>ps ax</bf>
+ find its <em>process number</em>, (PID), using <bf>ps ax</bf>
command and then kill that process.
<p>
@@ -1236,17 +1235,17 @@ but <bf>/usr/sbin/fbb status</bf>
<p>
Looks that <bf>/usr/sbin/fbb stop</bf> does not terminate
-daemon *every* time the command is executed, but re-start it
+daemon *every* time the command is executed, but re-start it
(the only difference is the new PID of the process and
<bf>ps ax</bf> can show that new PID). So, there is
a question why it returns that [OK] when it is
-obvious that daemon is not stopped, but re-started.
+obvious that daemon is not stopped, but rather re-started.
<p>
-<item>Well, if you are like me, you may also want to
+<item>Well, if you are like me, you may also want to
experiment with some special sysop's commands, from
- within an <em>xfbbC</em> session. For example, "/R"
- command ("Reboot PC") shuts down <em>xfbbC</em>
+ within an <em>xfbbC</em> session. For example, "/R"
+ command ("Re-boot PC") shuts down <em>xfbbC</em>
and <bf>/usr/sbin/fbb status</bf> reports:
<p>
<tscreen><verb>
@@ -1262,12 +1261,12 @@ while "/A" command ("Stop BBS") returns:
</verb></tscreen>
<p>
-before shutting down <em>xfbbC</em> client itself.
+before shutting down <em>xfbbC</em> client itself.
<p>
-Further tries to re-start either <em>xfbbC</em> client
-or <em>xfbbd</em> server (using <bf>/usr/sbin/fbb start</bf>)
-are not successful, unless an additional
+Further attempts to re-start either <em>xfbbC</em> client
+or <em>xfbbd</em> server (using <bf>/usr/sbin/fbb start</bf>)
+are not successful, unless an additional
<bf>/usr/sbin/fbb stop</bf> is executed. The result is:
<p>
@@ -1276,7 +1275,7 @@ are not successful, unless an additional
</verb></tscreen>
<p>
-Then <bf>/usr/sbin/fbb status</bf> reports:
+Now another <bf>/usr/sbin/fbb status</bf> reports:
<p>
<tscreen><verb>
@@ -1285,27 +1284,27 @@ Then <bf>/usr/sbin/fbb status</bf> reports:
</verb></tscreen>
<p>
-so, daemon might be re-started again. Here it is
+so finally, daemon might be re-started again. Here it is
also a mystery why it returns that [FAILED]
when it is obvious that daemon is really
-stopped (maybe it is a "failure" if somebody tries to
+stopped (maybe it is a "failure" when we try to
stop the same thing <em>twice</em>).
<p>
-There are some other commands: "/K" (Reboot BBS with
-housekeeping), "/M" (Reboot BBS imediatelly) and
-"/L" (Reboot BBS, waiting users to disconnect) -
-all of them with slightly different behaviour.
-Anyway, those three have something in common: they
-re-start daemon (with different PIDs, of course).
+There are some other commands: "/K" (Re-boot BBS with
+housekeeping), "/M" (Re-boot BBS immediatelly) and
+"/L" (Re-boot BBS, waiting users to disconnect) -
+all of them with slight different behavior. Anyway, those
+three commands have something in common: they all re-start
+the daemon (with different PIDs, of course).
<p>
-<item>Finally, what I would like to have is to
+<item>Finally, what I would like to have is to
manage housekeeping and other maintaining
- tasks. Untill now, that is not accomplished.
+ tasks. Until now, that is not accomplished.
I suppose that I should make some more fine
customization in system paths. Any suggestion
- is welcomed.
+ about is welcomed.
</itemize>
@@ -1316,29 +1315,29 @@ re-start daemon (with different PIDs, of course).
2002-10-20
<p>
-Well, soon after the installation of LinFBB v7.04
-<em>.rpm</em> package, I noticed
+Well, soon after the installation of LinFBB v7.04
+<em>.rpm</em> package, I noticed
a new "kid on the block", i.e. a new item within the
Start menu (under Gnome environment). That was a
-"HamRadio" group, having several "Xfbb version 7.04"
+"HamRadio" group, having several "Xfbb version 7.04"
sub-items and one of them was "xfbbd X Client".
<p>
It seemed that a mouse <em>click</em> on that
-"xfbbd X Client" icon was not likely to return any
-response, although <em>xfbbd</em> daemon has been successfully
-running <em>before</em> invoking the client. That's why I have
-been asking for help (related to that issue) from other LinFBB
-users, but it seemed there is no one capable to solve the
+"xfbbd X Client" icon was not likely to return any
+response, although <em>xfbbd</em> daemon has been successfully
+running <em>before</em> invoking the client. That's why I have
+been asking for help (related to that issue) from other LinFBB
+users, but it seemed there was no one capable to solve that
problem. Anyway, it looks to me that there is a "dead" link
-from this "xfbbd X Client" icon to an usable executable.
+from this "xfbbd X Client" icon to an existing executable.
<p>
-Trying to find a solution, the other day I was browsing the
-<bf>/usr/sbin</bf> directory. I have noticed something that
-I have already seen for several times. That was <bf>xfbbX</bf>
-file. Well, I am sure that I tried to use that <em>executable</em>
-earlier, but without much success. This time, I have entered
+Trying to find a solution, the other day I was browsing the
+<bf>/usr/sbin</bf> directory. I have noticed something that
+I have already seen for several times. That was <bf>xfbbX</bf>
+file. Well, I am sure that I tried to use this <em>executable</em>
+earlier, but without much success. This time, I have entered
the full path, like this:
<p>
@@ -1351,91 +1350,93 @@ and, finally, the GUI client appeared on the screen.
<p>
So far - so good. Soon after, I realized that 'Monitoring'
-window was capable to monitor the actual traffic on the radio
-frequency, but not only that. Headers of all packets appear
+window was capable to monitor the actual traffic on the radio
+frequency, but not only that. Headers of all packets appear
in green and the actual information is in blue, so it is easy
-to distinguish what is the header and what is the text info.
-What I could describe as a disadvantage of the 'Monitoring'
-window, is that the scroll bar does not give you much of the
+to distinguish what is the header and what is the text info
+(comparing to my old X11 LinFBB application where everything
+came in black).
+What I could describe as a disadvantage of the 'Monitoring'
+window, is that the scroll bar does not give you much of the
previous, already <em>scrolled</em> traffic.
<p>
The 'All channels' screen was even better, so the system
-user correspondents' traffic appeared in green, the local
-user's traffic was in black and the port information was
-yellow. Unfortunatelly, there's no easy way (if any) to
-change colors (and that's the standard feature in WinFBB)
+user correspondents' traffic appeared in green, the local
+user's traffic was in black and the port information was in
+yellow. Unfortunately, there's no easy way (if any) to
+change colors (and that's the standard feature in WinFBB)
for both 'Monitoring' and 'All channels' windows. Maybe I
haven't managed yet to find a switch for that, so any
useful info about is appreciated.
<p>
-What I have also found a bit annoying, was that both
-windows mentioned above, appear not arranged side-by-side,
+What I have also found a bit annoying, was that both
+windows mentioned above, appear not arranged side-by-side,
a form that would be more suitable. Besides that, the
third window, 'Console', has to be activated with another
-mouse click (instead of being activated automaticaly
+mouse click (instead of being activated automatically
with the other two windows). Actually, the whole thing of
-<em>xfbbX</em> client seems to be primarily useful for
+<em>xfbbX</em> client seems to be primarily useful for
sysops looking only for BBS's command line, in order to
-execute some server's commands etc. That's why I have found
+execute some server's commands etc. That's why I have found
a bit strange why the console window must be activated
-separately (ok, I know that's the same with WinFBB's
+separately (OK, I know that's the same with WinFBB's
windows, but why not to add some additional feature?)
<p>
Anyway, the 'Console' connection window has almost the same
functionality as WinFBB's 'Console' window. Here I think
-of the commands given at the BBS's command prompt, because
-they are invoked from the usual <language>.TXT files.
+of the commands given at the BBS's command prompt, because
+they are invoked from the usual language *.TXT files.
<p>
-But, the big disadvantage of today's version of
+But, the big disadvantage of today's version of
<em>xfbbX</em> client, I've found here, is the absence of
several useful icons, that I was very fond of within
the WinFBB's user interface. For example, there are
no icons for pending mail, users information,
disconnect a user, edit a message text or a header
-etc. It looks to me that <em>xfbbX</em> developers are
-not likely to offer the full comfortability, that we have
+etc. It looks to me that <em>xfbbX</em> developers are
+not likely to offer the full comfort that we have
within WinFBB's GUI. It makes me wonder why? There are lots
of commands that can not be easily activated without the
proper icons. It drives me crazy whenever I have to
re-boot to Windows to start WinFBB, in order to perform
-some tasks mentioned, using the mouse.
+some simple tasks mentioned, using the mouse.
<p>
Besides that, there is no way to activate that nice
message editor screen, very useful in WinFBB
-(and also in an old Xwindows LinFBB application
-v7.00g from 1998)! The same goes for replying
+(also existed in an old Xwindows LinFBB application
+v7.00g from 1998!) The same goes for replying
a message, where a sender does not get the text
of a message to be replied to, within the new
message body. In short, I don't like absence of
-all those already implemented, but now abandoned
+all those earlier implemented, but now abandoned
features.
<p>
-Well, I can't imagine what Jean-Paul, F6FBB, and
-other developers would do in the future, but I am not
-satisfied with the idea to only keep further development
-of LinFBB server side, but, in the same time, to abandon
-the development of LinFBB's graphical client side. And not
-only that: It looks that MS Windows client for LinFBB server,
-<em>xfbbW</em> has been reported to be much more functional
-that described xfbbX, while, in the same time, WinFBB server
-development has been also stopped. A bit confusing situation,
-isn't it?
+Well, I can't imagine what Jean-Paul, F6FBB, and
+other developers would do in the future, but I am not
+satisfied with the idea to only keep further development
+of LinFBB server side, but, in the same time, to abandon
+the development of LinFBB's graphical client side. And not
+only that: It looks that MS Windows client for LinFBB server,
+<em>xfbbW</em> has been reported to be much more functional
+that described xfbbX, while, in the same time, WinFBB server
+development has been also stopped. A bit confusing situation,
+isn't it?
<p>
Some amateurs think that it is just a result of "global" IT
-situation: Linux (and other Unix-type platforms) is better
+situation: Linux (as well as other Unix-type platforms) is better
suited for servers, but Windows is better for clients. If so,
it looks that LinFBB packet-radio system operators, "sysop's",
seem to be forced to run at least two computers, in order
-to get the same functionality they already have with WinFBB.
+to get the same functionality they always had with WinFBB.
I'd rather suggest to Jean-Paul, F6FBB, and other developers
-to transfer all known WinFBB's GUI features to <em>xfbbX</em>
+to transfer all known WinFBB's GUI features to <em>xfbbX</em>
GUI environment, in order to avoid using two computers.
<p>
@@ -1445,38 +1446,38 @@ GUI environment, in order to avoid using two computers.
A couple of paragraphs ago, I said that "xfbbd X Client" icon
didn't work under Gnome environment. It did make me wonder
if it would work under KDE graphical user interface. So, this
-time I started KDE (and I did it as "root" so, in addition, I
+time I started KDE (and I did it as "root" so, in addition, I
also got a mailbox icon on the desktop, named "fbb X11". When I
-located the mouse pointer over that icon, there appeared some
+located the mouse pointer over that icon, there appeared some
more description: "F6FBB bbs Server for Packet Radio").
<p>
-Well, when I tried to <em>click</em> on that icon, I got a
-KFM Warning message box explaining that program
-<bf>/root/.xfbbX</bf> could not be executed. Fortunately,
-a "right click" on the icon allowed to enter file's Properties.
-The Execute card gave me a possibility to change the path
-for a program to be used. So, I did some browsing and located
-the new path: <bf>/usr/sbin/xfbbX</bf>. After that, another
+Well, when I tried to <em>click</em> on that icon, I got a
+KFM Warning message box explaining that program
+<bf>/root/.xfbbX</bf> could not be executed. Fortunately,
+a "right click" on the icon allowed to enter file's Properties.
+The Execute card gave me a possibility to change the path
+for a program to be used. So, I did some browsing and located
+the new path: <bf>/usr/sbin/xfbbX</bf>. After that, another
<em>click</em> resulted in running the GUI client.
<p>
-Interestingly, there is some slight difference between
-<em>xfbbX</em> appereance under KDE and Gnome. Actually,
-each KDE's <em>xfbbX</em> window has "FBB" logo in the upper
-left corner (Gnome's windows have not). That may indicate
-that <em>xfbbX</em> client was produced primarily for KDE
-environment. Besides that, it seems that other features
-are almost the same, regardless being within KDE or Gnome
+Interestingly, there is some slight difference between
+<em>xfbbX</em> appearance under KDE and Gnome. Actually,
+each KDE's <em>xfbbX</em> window has "FBB" logo in the upper
+left corner (Gnome's windows haven't that). That may indicate
+that <em>xfbbX</em> client was produced primarily for KDE
+environment. Besides that, it seems that other features
+are almost the same, regardless being within KDE or Gnome
environment.
-
+
<p>
On the other side, the already mentioned "xfbbd X Client"
-item (within the Start menu, under "HamRadio" group), still
-does not work. I suppose that there should also be some
-modifications, related to program executable paths, but I
-do not know how to manage that. Anyway, it does not matter
-because <em>xfbbX</em> is running this or that way.
+item (within the Start menu, under yhe "HamRadio" group), still
+does not work. I suppose that there should also be some
+modifications, related to program executable paths, but I
+do not know how to manage that. Anyway, it does not matter
+because <em>xfbbX</em> is running here this or that way.
<p>
<sect>How to use LinFBB's "xfbbW", a GUI client for Windows
@@ -1518,17 +1519,17 @@ was already installed per default within RH 6.2 Linux. I
found the right place to add the information related to NIC's
IRQ and I/O address. There I seemed to make a little mistake,
so I put the value of <em>220</em> (for the I/O address), instead
-of <em>0x220</em> that would better fit there. The result was as one
+of <em>0x220</em> that would better fit. The result was as one
may expect: the interface <bf>eth0</bf> continued to
report that a <em>ne</em> module had not found a card
at that one address. Then I checked the actual I/O address
the card uses under Windows OS (was the same) and
-tried to fix the parameters (Thanks goes to a GB ham who advised
+tried to fix the parameters (Thanks goes to a UK ham who advised
me to have to let Linux know the proper IRQ and I/O
addresses).
<p>
-Interestingly, <em>Linuxconf</em> added a couple of new lines
+Interestingly, <em>Linuxconf</em> added a couple of new lines
into <bf>/etc/conf.modules</bf> too. In short, the next time
during the system boot, the interface <bf>eth0</bf>
reported a green <em>[OK]</em>, so I could
@@ -1537,13 +1538,13 @@ establish the link. So far - so good.
<p>
The next task was to download the client package from the
FBB's main site. I did it from the <em>"Newest version"</em>
-web page and the number of the version was 1.12 (it
+web page and the number of the version was 1.12 (it
seems that was not a pretty much new version, or maybe the
content on that <em>"newest"</em> page has not been updated
-recently). Anyway, I installed it without any
-problem, configured its part related to the LinFBB
-server it was about to access, changed the console font to my
-favourite one (Tahoma) and started the utility.
+recently - another task for Jean-Paul?). Anyway, I installed it
+without any problem, configured its part related to the LinFBB
+server it was about to access, changed the console font to my
+favorite one (Tahoma) and started the utility.
<p>
At the first sight, the client looked great, because
@@ -1551,31 +1552,175 @@ Linux clients still prefer so small letters, that are
hard to read (compared to characters on a Windows screen).
Now I tried the most used commands like List, Read, Send Reply
etc. All of them worked great. What I have found a bit
-strange, was that the <em>message justification</em> did
+strange, was that the <em>message justification</em> did
not work in its message editor window. You see, I like
-my messages to be justified on both sides. I hope a solution
-for that will be found soon.
+my messages to be justified on both sides. I hope a solution
+for that problem will be found soon.
<p>
-Another issue with <em>xfbbW</em> client is that seems not to
+Another issue with <em>xfbbW</em> client is that seems not to
allow a multiple click onto more than one
-bbs callsign within <em>pending forward</em> list,
-comparing to WinFBB's behaviour. You know, I am not very fond of
-opening the same <em>pending forward</em> window repeatedly
-again and again, in order to start (or to stop) more than
-one forwarding task at a time.
+BBS callsign within <em>pending forward</em> list,
+comparing to WinFBB's behavior. You know, I am not very fond of
+opening the same <em>pending forward</em> window repeatedly
+again and again, in order to start (or to stop) more than
+one forwarding action.
<p>
In general, I like <em>xfbbW</em> client. I hope to
-install a newer version soon, as well as some of
-its features to be upgraded and some new ones to be added
+install some newer version(s) soon, and I hope some of
+its features will be upgraded and some new ones will be added
in the future. What I would also like to have, is to
activate the maintenance of the BBS (a "housekeeping" task)
-from the client's menu. Another thing I miss at the moment, is the
+from that client's menu. Another thing I miss at the moment, is the
absence of the <em>xfbbW</em>'s help system. I mean
of a <em>real</em> Windows help, because there's not
-much use of its <em>Help</em> menu, having only
-<em>Copyright</em> and <em>About</em> :-)
+much use of a <em>Help</em> menu, having only
+<em>Copyright</em> and <em>About</em> information :-))
+
+<p>
+<sect>How to compile LinFBB's <em>executable</em> files
+
+<p>
+2003-01-01
+
+<p>
+<em>Notice: Until recently, I preferred to download "factory-made"
+executables in RPM format (something like ZIP in MS Windows world).
+After getting a RPM package, a click on it activates the program
+that unpack and install its content. Well, it is great whenever
+your RPM has been "manufactured" for the very similar distribution
+of Linux you have. If not ...</em>
+
+<p>
+<itemize>
+
+<item>Well, I have already had the package
+ <tt>xfbb-7.04-2.i386.rpm</tt> (07 August 2001), that was
+ running OK under RH 6.2 distro. And not only that. Its
+ "packager", Jose HI8GN, has explained that this package
+ was actually compiled and linked with utilities that came
+ with RH 6.2 - so under that distribution should be no
+ problems at all.
+
+<p>
+<item>The other day, I finally decided to abandon that 4-5 year
+ old version of X11 LinFBB <em>application</em> that I knew it would
+ not run under something newer than RH 6.2 distro. In short,
+ I decided to stay with daemon LinFBB's only, so it was the
+ right time to upgrade the Linux system itself. Another handy
+ installation that I had, was RH 7.1 and I used it. After
+ finishing that task, I rushed to re-install the RPM package
+ above, but it just didn't want to run.
+
+<p>
+<item>I had no choice but to browse fbb web sites in order to find
+ a RPM package that would fit RH 7.1 distribution. Unfortunately,
+ it looked that there were no LinFBB precompiled RPMs for 7.1
+ version of RedHat. The only solution was to try with <em>tarballs</em>.
+ So, what I have downloaded from <url url="http://www.f6fbb.org/versions.html"
+ name="www.f6fbb.org/versions.html">, was <tt>xd704h-src.tgz</tt>
+ archive.
+
+<p>
+<item>So far - so good. Well, folks, I am not very good in "deepest"
+ secrets of Linux, so I was not sure where might be the best
+ location to unpack the archive. According a <em>readme</em>
+ file, it should be "fbbsrc" directory, so I considered that
+ <bf>/usr/src</bf> would be the best place to copy archive's
+ <bf>fbbsrc.704h</bf> directory.
+
+<p>
+<item><bf>fbbsrc.704h</bf> directory has been made of 12 files and 7
+ subdirectories, one of which is <bf>src</bf> subdirectory. As
+ I said, the <em>readme</em> suggests a user to "goto fbbsrc/src"
+ directory, and I concluded that <bf>/usr/src/fbbsrc.704h/src</bf>
+ was the right place.
+
+<p>
+<item>The <em>readme</em> also suggests to "update the variables" at
+ the beginning of <em>Makefile</em> files, but I did not do that
+ because I was not sure what should be replaced there. I have
+ just left the file(s) intact.
+
+<p>
+<item>The next task was to run <em>make</em> command from the shell
+ and it took half a minute to be finished. The result were few new
+ <em>xfbb</em> executable files that I quickly moved to
+ <bf>/usr/sbin</bf> directory. BTW, some people rather suggest to run
+ <em>make install</em>, in order to avoid multiple copying of
+ compiled executables, but I found that way as not functional.
+
+<p>
+<item>Soon after, I tried to activate LinFBB's <em>daemon</em> and
+ it seemed to work without visible difficulties (using a temporary home
+ LAN with a laptop, I also started <bf>fbbW</bf>, a LinFBB Windows client.
+ It recognized the <em>daemon</em> in a second and I've only
+ noticed that there was no Protus password utility running).
+
+<p>
+<item>According the <em>readme</em>, the next task should be to "compile
+ the xfbbC client". That operation is to be performed from a place
+ called "fbbsrc/client" but the only directory available under
+ <bf>/usr/src/fbbsrc.704h/src</bf> was <bf>X11</bf> subdir.
+
+<p>
+<item>After clicking on its icon, I recognized the second one file
+ with a name <em>Makefile</em> (they have mentioned "updating"
+ of <em>both</em> Makefile files, so I hoped to reach the proper
+ place once again, regardless of two unknown paths). Besides that,
+ they have suggested to use "at least the version 2.1.37b of
+ ax25-utils" and I found <em>not</em> to have something like that
+ installed (case they mean of a <em>suit</em> of libax25, ax25apps
+ and ax25tool - than it is OK). Anyway, one more time I activated
+ <em>make</em> command from the shell and the result was in
+ getting <em>xfbbC</em> executable.
+
+<p>
+<item>As usual, <bf>xfbbC</bf> client is invoked from within an
+ <em>xterm</em> (or similar) window and it seemed that it was
+ also fully functional. So far - so good.
+
+<p>
+<item>The next issue is to "compile the xfbbX client", but this time
+ a user is requested to have a version of Motif installed. Well,
+ what I knew was that I had no Motif in the box, but a couple of Lesstif
+ RPM packages were somewhere around. Anyway, I installed them
+ with <tt>--force</tt> and <tt>--nodeps</tt> options to avoid
+ several <em>dependency</em> obstacles. In sum, Lestiff has come
+ to its place on the disk.
+
+<p>
+<item>This time, I did make some "updates" related to <em>Makefile</em>
+ paths and tried to run <em>make</em> command from the shell (for
+ the 3rd time now). Seems that I got no answer, because there appeared
+ neither <bf>xfbbX</bf> nor <bf>xfbbX_cl</bf> new executable files.
+ In order to "solve" that issue, I just applied the executables
+ from the earlier version I have backup-ed on the system.
+
+<p>
+<item>Finally, I managed to activate <bf>xfbbX</bf> client without
+ problems, although I knew it was not an updated version (compared
+ to the daemon itself). Regardless of that fact, a GUI client
+ works properly.
+
+<p>
+<item>As I just mentioned, I noticed that the first console connections
+ were without familiar <bf>{PROTUS-4.1b7}</bf> designation. So, I had
+ to check and double-check all the paths and system directories,
+ described in the Protus section of this mini-HOWTO. At the first
+ sight, it looked to me that everything was fine, but the utility
+ was not likely to start. Finally, I copied its main executable
+ into the yet another system location: <bf>/usr/lib/fbb/filter</bf>,
+ re-started the system and Protus returned back to its function.
+
+<p>
+<item>What I have to do in the future, is to check if the procedure
+ described in this section was the right one, although most of the
+ BBS's main features seem to be active - like they were with RH 6.2
+ distribution and mentioned LinFBB packages in RPM format.
+
+</itemize>
<p>
<sect>How to make better ham radio rules?
@@ -1587,36 +1732,36 @@ much use of its <em>Help</em> menu, having only
<em>Notice: Folks, here I am going to discuss some
rule'n'regulation issues that we, radio amateurs, face to
every day. These problems are big obstacles for this nice
-way of communication to be more developped and widely
-used.</em>
+way of communication to be more developed and widely
+used.</em>
<p>
First of all, anybody who might be interested in
running Linux amateur radio software, as a way of
using radio amateur stations on the international
-HF waves, in a <em>digital</em> manner, has to learn
-<bf>manual <em>analog</em></bf> Morse telegraphy and
-pass <bf>manual</bf> Morse skill test. For a long time
-now, I have been trying to explain myself, why manual
-Morse telegraphy is still being kept as the requirement
-without an amateur is not allowed to use HF frequencies
-under 30 MHz, in order to contact other Linux and other
+HF waves, in a <em>digital</em> manner, has to learn
+<bf>manual <em>analog</em></bf> Morse telegraphy and
+pass <bf>manual</bf> Morse skill test. For a long time
+now, I have been trying to explain myself, why manual
+Morse telegraphy is still being kept as the requirement
+without an amateur is not allowed to use HF frequencies
+under 30 MHz, in order to contact other Linux and other
radio amateurs world-wide. I still have no answer, except
that all of those who have wasted lots of time learning
Morse, now don't want to allow newcomers to use the
-same capabilities - without the same (now useless) tests!
+same capabilities - without the same (useless) tests!
<p>
You all know, there are so many Linux enthusiasts world-wide
-(including myself) who have been fighting against all types
-of <bf>monopols</bf> (like a company from Redmond). The Morse
-obligatory test is the same: just another type of a
+(including myself) who have been fighting against all types
+of <bf>monopols</bf> (like a company from Redmond). The Morse
+obligatory test is the same: just another type of a
<bf>monopoly!</bf>
<p>
-That's why I have been trying to persuade all relevant
-factors to <bf>remove</bf> such outdated regulatory
-principles, that make more and more obstacles for not
+That's why I have been trying to persuade all relevant
+factors to <bf>remove</bf> such outdated regulatory
+principles, that make more and more obstacles for not
only Linux users, but for other kinds of computer users
- when it comes to use modern ICT technologies. I hope,
all of you, readers of this mini-HOWTO, can now
@@ -1631,21 +1776,21 @@ have to pass the Morse test, as the legal requirement
remote packet radio users world-wide, using the HF
radio bands and devices. I am sure, the absence of
those high educated people in the ham radio is one
-of the most negative facts we face to in ICT areas.
+of the most negative consequences we face to in ICT areas.
<p>
I have been thinking what to do, since early ninetees
when I was the secretary of <em>YU7</em> (Vojvodina
province in Serbia) amateur radio union. It seemed to
me that it was a hard job to persuade people who govern
-the amateur radio, to just remove that outdated rule.
+the amateur radio, just to remove that outdated rule.
So, I have decided to suggest the implementation of
another regulatory principle: To adopt a new type
-of amateur radio licences, a <bf>H</bf>am <bf>D</bf>igital
-<bf>L</bf>icence (the <bf>HDL</bf> in short). HDL holders
-would be allowed to use ALL amateur radio frequencies,
+of amateur radio licenses, a <bf>H</bf>am <bf>D</bf>igital
+<bf>L</bf>icence (the <bf>HDL</bf> in short). HDL holders
+would be allowed to use ALL amateur radio frequencies,
including ALL international HF bands
-under 30 MHz. But, they would be allowed to use ONLY
+under 30 MHz. But, they would be allowed to use ONLY
digital types of amateur activities, including the use of
computers with LinFBB packet radio software. HDL holders
might use some dedicated radio transmitters, without
@@ -1657,17 +1802,18 @@ unwanted amateur activities (like voice operations).
All HDL candidates would have to learn topics like
hardware and software in general, connecting amateur
radio stations to computers, building antennas,
-English language in written exam etc. The Morse
+English language in written exam etc. The Morse
requirement would not be used anymore, as well as
some other obsolete tests, like complicated radio
-circuits, building home-brew radios (instead of
-buying modern factory manufactured devices) etc.
+circuits, building home-brew radios from the scratch
+(instead of buying modern factory manufactured devices)
+etc.
<p>
Folks, I believe that amateur radio <em>digital</em>
activities have their future, only if we all do
our best to improve the regulatory principles that
-govern this fine hobby. Besides the telegraphy
+govern this fine hobby. Besides the telegraphy
requirement, here in Serbia we also have to be
members of the national amateur radio union, as the
legal requirement, <bf>before</bf> we become allowed
@@ -1678,13 +1824,13 @@ principles, that do not require to join <em>any</em>
type of organizational system, i.e. amateur radio
society that only wants to get your membership
money, you are asked to lobby for that. Our outdated
-amateur society leadership has an email address:
-yu0srj@eunet.yu (I suppose they may have more than
-one email address, but you may try to use this one
+amateur society leadership has an email address:
+yu0srj@eunet.yu (I suppose they may have more than
+one email address, but you may try to use this one
and/or to search for more info related to "Savez radio
amatera Jugoslavije", "Savez radio amatera Srbije",
etc). Your valuable help would be appreciated. Case
-you need more info regarding these legal issues, do
+you need more info regarding these legal issues, do
not hesitate to contact me.
<p>
@@ -1693,16 +1839,16 @@ amateur radio rules and regulations better and
updated (say to widen the idea of liberalize the
ICT areas and free them of any kind of monopols),
I would suggest you to look for your national radio
-amateur society and/or national telecommunication
-regulatory agency. Lobby to them in order to remove
+amateur society and/or national telecommunication
+regulatory agency. Lobby to them in order to remove
the obsolete manual Morse proficiency test.
<p>
Case we all do our best to remove all those obstacles
-for so many new people, to enjoy amateur radio digital and
-Linux-related operations, the technology would become
+for new people who may wish to enjoy amateur radio digital
+and Linux-related operations, the technology would become
the part of more homes. I hope you, the readers, may
-help so I look forward to hear from you soon!
+help. So I look forward to hear from you soon!
<p>
<sect>Bibliography
@@ -1713,11 +1859,11 @@ help so I look forward to hear from you soon!
<em>Notice: Folks, I often visit some (inter)national
ICT conferences all around the country, submitting papers
and having presentations. What I want to do is to spread - as
-wide as possible - the basic idea and the useful mission of
+wide as possible - the basic idea and the useful mission of
the amateur radio hobby and, you bet, whenever possible to
-make it with Linux. Besides that, I have been writing various
+make it with Linux. Besides that, I have been writing various
articles for a variety of scientific and other magazines.
-Here you have a list of the articles that I have written,
+Here you have a list of the articles that I have written,
and the papers submitted to the conferences.</em>
<p>
@@ -1765,14 +1911,14 @@ and the papers submitted to the conferences.</em>
- "Paket-radio (2) - Modemi za radio-veze",
proceedings, "Info-Teh", Vrnjacka Banja, Serbia, 2002.
- - "Alternativne racunarske mreze", festival catalogue,
+ - "Alternativne racunarske mreze", festival catalog,
"INFOFEST", Budva, Montenegro, 2002.
- - "Alternative computer networks", proceedings, "TELFOR",
+ - "Alternative computer networks", proceedings, "TELFOR",
Belgrade, Serbia, 2002.
- "With rule and regulation improvements to the progress"
- proceedings, "TELFOR", Belgrade, Serbia, 2002.
+ proceedings, Belgrade, Serbia, 2002.
</verb></tscreen>
<sect>Further information
@@ -1820,8 +1966,8 @@ This is not the first release of this mini-HOWTO. I
hope to improve it whenever possible. Beside that,
there are other documents that may help you to
use amateur radio stuff on your computer. You may
-look for AX.25 (mini-)HOWTO at the same location
-where you get FBB mini-HOWTO.
+also look for AX.25 (mini-)HOWTO at the same
+location where you get FBB mini-HOWTO.
<em>This mini-HOWTO would be improved from time
to time. If you think that the HOWTO on your
@@ -1838,10 +1984,11 @@ homepage.
<em>This version of mini-HOWTO can thanks to:</em>
<tscreen><verb>
-Jean-Paul Roubelat, F6FBB, the author of FBB.
-Per Olsen, LA6CU, the author of FBB documentation.
-Jesus R., EB5AGF, the author of Protus.
-Jose Marte, HI8GN, the packager of 7.02g package.
+Jean-Paul Roubelat, F6FBB, the author of FBB,
+Per Olsen, LA6CU, the author of FBB documentation,
+Jesus R., EB5AGF, the author of Protus,
+Jose Marte, HI8GN, the packager of 7.02g package,
+and a variety of helpful radio amateurs world-wide.
</verb></tscreen>
@@ -1870,7 +2017,7 @@ Some relevant mini-HOWTOs are
<tt/Backup-With-MSDOS/, <tt/Diskless/, <tt/LILO/, <tt/Large Disk/,
<tt/Linux+DOS+Win95+OS2/, <tt/Linux+OS2+DOS/, <tt/Linux+Win95/,
<tt/Linux+WindowsNT/, <tt/Linux+NT-Loader/, <tt/NFS-Root/,
-<tt/Win95+Win+Linux/, <tt/ZIP Drive/, <tt/FBB packet-radio BBS/.
+<tt/Win95+Win+Linux/, <tt/ZIP Drive/, <tt/FBB packet-radio BBS/ etc.
You can find these at the same place as the HOWTOs, usually in a sub directory
called <tt/mini/. Note that these are scheduled to be converted into SGML and
become proper HOWTOs in the near future.
@@ -2012,3 +2159,6 @@ little annoying.
</article>
+
+
+