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 @@ 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> +