home *** CD-ROM | disk | FTP | other *** search
/ HAM Radio 1 / HamRadio.cdr / packet / packpro2 / pd91033.txt < prev    next >
Internet Message Format  |  1991-02-03  |  10KB

  1. From wang!elf.wang.com!ucsd.edu!packet-radio-relay Sun Feb  3 18:01:39 1991 remote from tosspot
  2. Received: by tosspot (1.63/waf)
  3.     via UUCP; Sun, 03 Feb 91 19:32:04 EST
  4.     for lee
  5. Received: from somewhere by elf.wang.com id aa15380; Sun, 3 Feb 91 18:01:38 GMT
  6. Received: from ucsd.edu by uunet.UU.NET (5.61/1.14) with SMTP 
  7.     id AA05451; Sun, 3 Feb 91 12:31:23 -0500
  8. Received: by ucsd.edu; id AA04587
  9.     sendmail 5.64/UCSD-2.1-sun
  10.     Sun, 3 Feb 91 04:30:18 -0800 for hpbbrd!db0sao!dg4scv
  11. Received: by ucsd.edu; id AA04568
  12.     sendmail 5.64/UCSD-2.1-sun
  13.     Sun, 3 Feb 91 04:30:09 -0800 for /usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi -fpacket-radio-relay packet-radio-list
  14. Message-Id: <9102031230.AA04568@ucsd.edu>
  15. Date: Sun,  3 Feb 91 04:30:06 PST
  16. From: Packet-Radio Mailing List and Newsgroup </dev/null@ucsd.edu>
  17. Reply-To: Packet-Radio@ucsd.edu
  18. Subject: Packet-Radio Digest V91 #33
  19. To: packet-radio@ucsd.edu
  20.  
  21.  
  22. Packet-Radio Digest         Sun,  3 Feb 91       Volume 91 : Issue  33
  23.  
  24. Today's Topics:
  25.                  HELP with compiling Xenix SysV NET.
  26.                        PACKET->Internet Gateway
  27.                        recommended NOS version?
  28.                          Shareware on Packet
  29.  
  30. Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu>
  31. Send subscription requests to: <Packet-Radio-REQUEST@UCSD.Edu>
  32. Problems you can't solve otherwise to brian@ucsd.edu.
  33.  
  34. Archives of past issues of the Packet-Radio Digest are available 
  35. (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".
  36.  
  37. We trust that readers are intelligent enough to realize that all text
  38. herein consists of personal comments and does not represent the official
  39. policies or positions of any party.  Your mileage may vary.  So there.
  40. ----------------------------------------------------------------------
  41.  
  42. Date: 3 Feb 91 01:44:31 GMT
  43. From: munnari.oz.au!manuel!csc.canberra.edu.au!echo!skcm@uunet.uu.net  (Carl Makin)
  44. Subject: HELP with compiling Xenix SysV NET.
  45. To: packet-radio@ucsd.edu
  46.  
  47. Hi,
  48. I got a copy of the System V version of Net from TOMCAT for the house
  49. Xenix system here and am having a REAL problem compiling it.  The code seems 
  50. to compile OK but before I actually get to compiling it the MAKE program
  51. falls over screaming "out of memory". :-(
  52.  
  53. Now I'm reasonably new to Xenix/Unix and C but as far as I can see the
  54. only solutions would be either to compile it manually (urk) or split the
  55. makefile.
  56.  
  57. Has anyone else had this sort of problem?
  58.  
  59. The machine I'm trying to compile it on is a 12Mhz 80286 running SCO Xenix
  60. 2.2.3 in 2.5Mb of RAM and 105Mb of Hard disk.
  61.  
  62. (Hopefully in a couple of weeks we can borrow 8Mb of RAM for a couple of days
  63. but I'm not sure that will help. :-( )
  64.  
  65. Carl.
  66.  
  67. ------------------------------
  68.  
  69. Date: 2 Feb 91 20:43:50 GMT
  70. From: zaphod.mps.ohio-state.edu!rpi!uupsi!uhasun!jbloom@tut.cis.ohio-state.edu  (Jon Bloom)
  71. Subject: PACKET->Internet Gateway
  72. To: packet-radio@ucsd.edu
  73.  
  74. In article <253@platypus.uofs.edu>, bill@platypus.uofs.edu (Bill Gunshannon) writes:
  75. > I have heard numerous times that because the remote station would be 
  76. > controlling the transmitter and he is (possibly) a non-ham that this
  77. > would be illegal.  Now lets look at this from a practical technical
  78. > aspect.  
  79. > If I put up a 10M <-> 2M cross-band repeater, a TECH can come on 2M
  80. > and initiate a contact on 10M.  This is not considered illegal although
  81. > the TECH is initiating the contact.  I have heard that this is OK under
  82. > the rules covering 3rd Party traffic cause the TECH isn't the control
  83. > operator of the 10M station.  Well, I'm sorry, but that doesn't wash 
  84. > either.  Cause then all the 10M contacts with G-land AND DL-land etc.
  85. > are illegal cause we don;t have 3rd party agreements with them.  The 
  86. > fact of the matter is that the TECH on 2M never has control of the
  87. > signal generated on 10M and that is why the FCC allows it.  I think 
  88.  
  89. The reason this doesn't fall under the normal third-party rules is that
  90. the FCC has made explicit exceptions in the case of repeaters.  While
  91. third-party traffic normally requires a control operator to be
  92. present at the control point (see 97.109), automatic control of a
  93. repeater is explicitly allowed [see 97.205(d)].  In the case of the
  94. cross-band repeater with an output on 10m, the Technician cannot be
  95. the control operator.  Fortunately, since a repeater is allowed to
  96. be under automatic control, no control operator is needed.  But if
  97. the originating signal is not coming from an amateur station, as would
  98. be the case with Internet-originated data, the station is not, by
  99. definition, a repeater [see 97.3(a)(34)].  So the analogy between cross-
  100. band repeaters and an Internet gateway is false.
  101.  
  102. > the time has come to look at possible INTERNET<->AMPR gateways the same
  103. > way.  If it takes letters to the FCC to convince them then so be it.
  104. > If I put up such a gateway, I am controling the emissions of the transmitter
  105. > not the guy in Odessa, TX who sent a message to one of the hams on the
  106. > local LAN.
  107.  
  108. But you are *not* controlling the content of the messages being transmitted
  109. by your station.  No ham is controlling that, and therein lies the problem.
  110.  
  111. > As long as all other rules are abided by, I can't see where there is any
  112. > kind of legal problem.  I don't see a lot of difference between this and 
  113. > NTS traffic which is non-ham (Happy Birthday, Merry Christmas etc.) put is
  114. > placed into the amateur system at one point by a ham.  Basicly the same
  115. > should apply to gateways.  I would be considered the ham putting the traffic
  116. > into the amateur system.  
  117. > The potential gain would be great.  Hams would be able to exchange ideas
  118. > and colaborate with hams and non-hams alike in their technological projects.
  119.  
  120. I completely agree with your last statement.  But there *is* a legal
  121. difference between the gateway and the NTS example.  See below.
  122.  
  123. [...Internet legalities deleted]
  124.  
  125. > So, would someone out there care to show me the error of my ways??  :-)
  126. > I'm not interested in "Well, it you just can't do it, so there."
  127. > I want concrete evidence that shows that the arguments that apply to one
  128. > type of technology (cross-band repeaters) can't be applied to a new
  129. > technology.
  130.  
  131. At the risk of (once again) being accused of being a technology-bashing,
  132. Luddite, ARRL old fart, let me try to (once again) explain how it is that
  133. the existing rules unfortunately prohibit unattended Internet->AMPR
  134. gateways.
  135.  
  136. 97.109(e) allows packet stations operating above 50 MHz to pass third-
  137. party traffic under automatic control, but "The retransmitted messages
  138. must originate at a station that is being locally or remotely controlled."
  139. Even worse, messages originated by non-hams (where the notion of a control
  140. operator can't possibly be stretched to cover the originator) surely come
  141. under the requirements of 97.115(b) which states in part:
  142.  
  143. (b) The third party may participate in stating the message where:
  144.    (1) The control operator is present at the control point and is
  145.        continuously *monitoring* and supervising the third party's
  146.        participation.  [Emphasis mine.]
  147.  
  148. This means that, under the current rules, you have to monitor (read)
  149. the data being sent by the Internet participant.  A bit difficult in
  150. an IP gateway!
  151.  
  152. Once again... cross-band repeaters are repeaters and fall under the
  153. repeater rules.  An Internet gateway is *not* a repeater and does
  154. *not* fall under these rules.  The reason the repeater rules were
  155. created in the first place was to provide relief from the third-
  156. party rules when only relay of *amateur* signals was involved.  Trying
  157. to interpret these rules in some way that would allow automatic relay
  158. of nonamateur signals violates both the spirit and letter of the repeater
  159. rules.  Sorry.
  160.  
  161. -- 
  162. Jon Bloom, KE3Z                              | American Radio Relay League
  163. Internet: jbloom@uhasun.hartford.edu         |
  164. Snail:    225 Main St., Newington, CT 06111  | "I have no opinions."
  165.  
  166. ------------------------------
  167.  
  168. Date: 2 Feb 91 21:17:02 GMT
  169. From: modcomp!dan@uunet.uu.net  (Dan Grostick)
  170. Subject: recommended NOS version?
  171. To: packet-radio@ucsd.edu
  172.  
  173. Can anyone recommend their favorite NOS version and where to get
  174. it from. I have access to uunet but not directly to internet - 
  175. except via a ftp-request mechanism that requires internet address
  176. and file names.
  177.  
  178. Thanks
  179.  
  180. -Dan
  181.  
  182. N4IXP
  183.  
  184. ------------------------------
  185.  
  186. Date: 2 Feb 91 17:10:00 GMT
  187. From: zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!wa4mei!ke4zv!gary@tut.cis.ohio-state.edu  (Gary Coffman)
  188. Subject: Shareware on Packet
  189. To: packet-radio@ucsd.edu
  190.  
  191. In article <1991Jan31.044034.21294@maverick.ksu.ksu.edu> steve@matt.ksu.ksu.edu (Steve Schallehn) writes:
  192. >A question was posed to me by an amateur who is interested in getting
  193. >into packet.  It seems he has a large collection of shareware on his
  194. >land-line BBS and he was wondering if he could legally set up his
  195. >BBS on packet and allow shareware downloads.  
  196. >
  197. >I know about the avoiding business in amateur radio, but does 
  198. >shareware count?
  199.  
  200. Shareware authors ask for and expect money for their product just like
  201. any other business. They're just freeloading their marketing dept off
  202. on to the public access systems. While shareware is probably the most
  203. often pirated software, it's still a commercial product. Therefore it
  204. would certainly be illegal to distribute it over amateur radio. Think 
  205. of shareware as digital pizzas. :-)
  206.  
  207. On the other hand, true freeware and public domain software are perfectly 
  208. ok to send over amateur radio.
  209.  
  210. Gary KE4ZV 
  211.  
  212. ------------------------------
  213.  
  214. End of Packet-Radio Digest
  215. ******************************
  216.