This commit is contained in:
gferg 2002-10-28 14:17:25 +00:00
parent def7ea819d
commit c4104fcbe9
1 changed files with 180 additions and 57 deletions

View File

@ -6,7 +6,7 @@
<title>FBB Packet-radio BBS mini-HOWTO
<author>Miroslav "Misko" Skoric, YT7MPB,
<tt/m.skoric@eunet.yu/
<date>v1.12, 2002-10-22
<date>v1.13, 2002-10-27
<abstract>
<nidx>linux windows nt amateur packet radio</nidx>
This mini-HOWTO covers the installation and use of
@ -1318,7 +1318,7 @@ re-start daemon (with different PIDs, of course).
<p>
Well, soon after the installation of LinFBB v7.04
<em>.rpm</em> package, I noticed
the new "kid on the block", i.e. a new item within the
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"
sub-items and one of them was "xfbbd X Client".
@ -1326,17 +1326,20 @@ 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
respond, although <em>xfbbd</em> daemon has been successfully
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 from other LinFBB users, but it seemed
there was no one capable to solve the problem.
been asking for help (related to that issue) from other LinFBB
users, but it seemed there is no one capable to solve the
problem. Anyway, it looks to me that there is a "dead" link
from this "xfbbd X Client" icon to an usable executable.
<p>
The other day I was browsing the <bf>/usr/sbin</bf> directory
and 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 file earlier, but without much
success. This time, I have entered the full path, like this:
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 executable
earlier, but without much success. This time, I have entered
the full path, like this:
<p>
<tscreen><verb>
@ -1348,88 +1351,207 @@ and, finally, the GUI client appeared on the screen.
<p>
So far - so good. Soon after, I realized that 'Monitoring'
window showed the actual radio traffic on the frequency,
but not only that. Headers of packets appeared in green
and the actual information was in blue, so it was easily
to distinguish what was the header and what was the
real text info. What I could describe a disadvantage
of the 'Monitoring' window, is that the scroll bar does
not give you much of the previous, already <em>scrolled</em>
traffic.
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
previous, already <em>scrolled</em> traffic.
<p>
The 'All channels' screen was even better, so the
partners' traffic appeared in green, the local user's
traffic was in black and port information was in yellow.
Unfortunatelly, there's no easy way (if any) to change
the colors (an usual feature in WinFBB) for both
'Monitoring' and 'All channels' windows. Maybe I
haven't managed to find a switch for that, so any
useful info will be welcomed.
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)
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 found a bit annoying, was that both windows
mentioned above, appeared 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 a
third window, 'Console', has to be activated with another
mouse click (instead of being activated automaticaly
with the other two windows). Actually, the whole thing of
<em>xfbbX</em> client seems to be primarily useful for
sysops looking for a command line, maintain the server
etc. So it is strange why the console window must be activated
sysops looking only for BBS's command line, in order to
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
windows, but...)
windows, but why not to add some additional feature?)
<p>
Anyway, the 'Console' connection window is almost the same
functional as WinFBB's 'Console' window. Actually,
the commands are the same, because they are invoked
from the <language>.TXT files.
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.
<p>
The big disadvantage of the <em>xfbbX</em>
client, I have found here, is the absence of
several useful icons, that I was fond of within
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 comfort that we have within
WinFBB's GUI. It makes me wonder why? There are lots
etc. It looks to me that <em>xfbbX</em> developers are
not likely to offer the full comfortability, 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 and WinFBB in order to perform
some simple tasks, using the mouse.
re-boot to Windows to start WinFBB, in order to perform
some tasks mentioned, using the mouse.
<p>
Besides that, there is no way to activate that nice
message editor screen, very useful in WinFBB
(also in the old Xwindows LinFBB application
v7.00g from 1998!). The same goes for replying
(and also 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
so many, already implemented but abandoned, features.
all those already 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 keep further development of LinFBB server side,
but, in the same time, to abandon the development
of LinFBB's GUI client side. And not only that. It
looks that Windows client for LinFBB server, <em>xfbbW</em>
has been reported to be much more functional that xfbbX,
while, in the same time, WinFBB server development is
also stopped. A bit confusing situation, isn't it?
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
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.
I'd rather suggest to Jean-Paul, F6FBB, and other developers
to transfer all known WinFBB's GUI features to <em>xfbbX</em>
GUI environment, in order to avoid using two computers.
<p>
<sect>How to make better ham radio rules?
<p>
2002-10-27
<p>
<em>Notice: Folks, here I am going to discuss some
rule'n'regulation issues that we, radio amateurs, face to
every day. These issues are obstacles for this nice
way of communication to be more developped and widely
used.</em>
<p>
First of all, anybody who might be interested in
running Linux amateur radio software, as a way of
controlling radio amateur stations on the international
HF waves, has to learn Morse telegraphy and pass Morse
skill test. For a long time now, I have been trying to explain
myself, why manual Morse telegraphy is still kept as the
requirement without one 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!
<p>
You all know, there are so many Linux enthusiasts world-wide
(including myself) who have been fighting against all types
of monopols (like a company from Redmond). The Morse obligatory
test is the same: just another type of a monopol!
<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
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
understand what does it mean to endlessly use outdated
rules and regulations. For example, I often contact
people from the academic world, students and scientists,
in order to motivate them to join amateur radio wireless
activities. They mostly refuse to start with amateur
(also called "ham") radio, as soon as they hear they
have to pass the Morse test, as the legal requirement
<em>before</em> they become allowed to connect to
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.
<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.
So, I have decided to suggest the implementation of
another regulatory principle: To adopt a new type
of amateur radio licences, a Ham Digital Licence (the HDL
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
digital types of amateur activities, including the use of
computers with LinFBB packet radio software. HDL holders
might use some dedicated radio transmitters, without
the ability for voice microphone and Morse key
connections, in order to avoid possible misuse of
unwanted amateur activities (like voice operations).
<p>
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
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.
<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
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
to use <em>any</em> type of amateur radio activity.
Such a stupid rule does not exist elsewhere! Should
you want to help us to adopt internationally known
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
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
not hesitate to contact me.
<sect>Further information
<p>
<sect1>Copyright
<p>
Copyright (c) 2001 by Miroslav "Misko" Skoric, YT7MPB.
Copyright (c) 2002 by Miroslav "Misko" Skoric, YT7MPB.
<P>
Permission is granted to copy, distribute and/or modify
this document under the terms of the GNU Free Documentation
@ -1660,3 +1782,4 @@ it <em/brief/ as a complete log file dumped to Usenet News is more than a
little annoying.
</article>