mirror of https://github.com/tLDP/LDP
updated
This commit is contained in:
parent
def7ea819d
commit
c4104fcbe9
|
@ -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>
|
||||
|
||||
|
|
Loading…
Reference in New Issue