From c4104fcbe98bdf1a40977ac6bf411de94ac7eb41 Mon Sep 17 00:00:00 2001 From: gferg <> Date: Mon, 28 Oct 2002 14:17:25 +0000 Subject: [PATCH] updated --- LDP/howto/linuxdoc/FBB.sgml | 237 +++++++++++++++++++++++++++--------- 1 file changed, 180 insertions(+), 57 deletions(-) diff --git a/LDP/howto/linuxdoc/FBB.sgml b/LDP/howto/linuxdoc/FBB.sgml index 0b94f204..dedb8ea3 100644 --- a/LDP/howto/linuxdoc/FBB.sgml +++ b/LDP/howto/linuxdoc/FBB.sgml @@ -6,7 +6,7 @@
Well, soon after the installation of LinFBB v7.04 .rpm 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".
It seemed that a mouse click on that "xfbbd X Client" icon was not likely to return any -respond, although xfbbd daemon has been successfully +response, although xfbbd daemon has been successfully running before 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.
-The other day I was browsing the
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 scrolled
-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 scrolled traffic.
-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.
-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
xfbbX 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?)
-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
-The big disadvantage of the xfbbX
-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
+xfbbX 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 xfbbX 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 xfbbX 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.
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.
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, xfbbW
-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,
+xfbbW 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?
+
+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 xfbbX
+GUI environment, in order to avoid using two computers.
+
+
+
+
+2002-10-27
+
+
+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.
+
+
+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!
+
+
+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!
+
+
+That's why I have been trying to persuade all relevant
+factors to
+I have been thinking what to do, since early ninetees
+when I was the secretary of YU7 (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).
+
+
+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.
+
+
+Folks, I believe that amateur radio digital
+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,
-Copyright (c) 2001 by Miroslav "Misko" Skoric, YT7MPB.
+Copyright (c) 2002 by Miroslav "Misko" Skoric, YT7MPB.
Permission is granted to copy, distribute and/or modify
this document under the terms of the GNU Free Documentation
@@ -1660,3 +1782,4 @@ it
+