| |
PA2AGA > HDDIG 27.09.99 14:27l 205 Lines 7932 Bytes #-9757 (0) @ EU
BID : HD_99_242B
Read: GUEST
Subj: HamDigitalDigest 99/242B
Path: DB0AAB<DB0PV<DB0MAK<DB0ERF<DB0HSK<PI8DRS<PI8DAZ<PI8GCB<PI8HGL<PE1NMB<
EA7URC<PE0MAR<PI8VNW
Sent: 990926/2218Z @:PI8VNW.#ZH2.NLD.EU #:3119 [HvHolland] FBB7.00g $:HD_99_242
From: PA2AGA@PI8VNW.#ZH2.NLD.EU
To : HDDIG@EU
Received: from pa2aga by pi1hvh with SMTP
id AA20023 ; Sun, 26 Sep 99 21:49:39 UTC
Received: from pa2aga by pa2aga (NET/Mac 2.3.67/7.5.3) with SMTP
id AA00015991 ; Sun, 26 Sep 99 23:31:48 MET
Date: Sun, 26 Sep 99 23:29:57 MET
Message-Id: <hd_99_242B>
From: pa2aga
To: hd_broadcast@pa2aga
Subject: HamDigitalDigest 99/242B
X-BBS-Msg-Type: B
those using X-Window.
This program is a host mode terminal program for the Kam Plus TNC. It
can be obtained (with the ncurses version) from my webpage on:
http://www.cvine.freeserve.co.uk/
It requires Qt-1.4* - if you use KDE-1.1*, then you will already have
this installed (it probably works with Qt-2.* also, but I have not
tested it with 2.*).
User reports and suggestions for improvements would be welcome.
Chris G3XXF.
--
If replying by e-mail, remove the --nospam--
>.
------------------------------
Date: Sat, 25 Sep 1999 11:51:58 GMT
From: steve_sampson@my-deja.com
Subject: Let's look at real numbers for TNC software sales
> Funny coincidence there... In my dealings with my ISP, old Packet
> radio habits tended to come into play, such as planning what I wanted
> to do before I ever connect, scheduling most of my use during off-
> peak hours, and in general attempting to reduce the amount of time I
> spend actually connected, as in downloading the mail and
> disconnecting before reading it, then composing offline and only
> hooking up long enough to send what I have queued and pick up any new
> incoming stuff.
This is basically the store and forward paradigm. The other is the
client-server networking paradigm.
Both are valid means of computer data transfer. It wasn't that many
years ago, that UUCP was the King, and SLIP was unheard of as an option.
In UUCP, you spool up your work, wait for a set time/or times, and
transfer the spooled-up work and data to the neighbor machine. Then
you disconnect, and call them back at the next spool time, and pick up
your work. UUCP was even available for the Radio Shack color computer
running OS-9.
Today, you are given an IP address and become part of the network. The
client connects to the server and does everything via TCP or UDP rather
than the "g" UUCP protocol. The difference of course, is that one is
real-time, or can be, and the other is store and forward.
Your ISP technique works well for you, but is unworkable to those who
use the http protocol ("web browsers"). A good friend, now deceased,
said that anything over 9600 baud on a telephone was a waste, and that
the World Wide Web was the biggest joke on humanity there ever was.
It's not true of course, because you can't believe the productivity
increase, when we move a customer off of a 3270 mainframe terminal
to a screen on their PC, and reduce their computing bill by 12k a month.
In almost every case the mainframe computer people say that the Server
we have running Oracle, Web Server, and RAID, will crater under the
load. It hasn't happened yet, and we are running 50% of what used to
be on the mainframe, and have budgeted the transfer of the other half.
Users can now import data into a spreadsheet, add that into a Word
document, and then email that to the branch office in real-time, rather
than overnight.
My red flag goes up sometimes though. For example, this great new
program that collects data and feeds it TCP to the Server, and they can
produce it in one man year of programmer time. Excuse me? How about
we collect it, FTP it on a cron, and then import it into Oracle?
Oh, well yea, you COULD do that, but it's SO low tech! OK, go ahead
with your plan, but here's your budget: $0.00, let me know when you're
done...
Steve
Sent via Deja.com http://www.deja.com/
Before you buy.
>.
------------------------------
Date: Sat, 25 Sep 1999 07:56:10 -0500
From: "Peter O. Brackett" <ab4bc@ix.netcom.com>
Subject: Let's look at real numbers for TNC software sales
Eric:
Yes!
The diggers of ditches and layers of cable, like the owners of bandwidth
often have a natural monopoly, but that does not also apply to the purveyors
of services over those infrastructure providers.
I believe that the diggers of ditches, layers of cable, owners of bandwidth,
et al should be strongly regulated by our Public Service
Commissions/Municipalities, and kept out of the competitive communications
services and content business.
Then the services and content should carried by those natural monopolies
should be wide open for competition.
The problem today is that the equipment that connects to cables and
bandwidth is designed for the use of monopolists, and not for a competitive
environment.
Therein lies a great opportunity for new access products, but the customers
are not the current monopolists, either de jure or de facto.
Regards,
Peter AB4BC
Eric S. Johansson <esj@harvee.billerica.ma.us> wrote in message
news:7shaun$vjq$1@harvee.billerica.ma.us...
> Rob Janssen <nomail@pe1chl.demon.nl> wrote:
> > Peter O. Brackett <ab4bc@ix.netcom.com> wrote:
> >>Isn't competition great?
>
> > I don't think it is. Competition in a small network as we have here
only
> > means extra interconnection costs and overhead because of multiple small
> > companies operating the same services (administration, customer support,
> > etc). Up to now, competition has only increased the prices here because
> > these extra costs somehow need to be recovered.
>
> welcome to the wonderful world of natural monopolies. A natural
> monopoly is any service in which it doesn't make sense to have
> competition. Examples of natural monopolies are: water, sewer, power
> lines, telephone lines, and roads. Note that I did not include power
> generation, water production, and telecommunication services.
>
> As you pointed out Rob, there are tremendous inefficiencies when there
> is competition at the natural monopoly level. It makes no sense to
> replicate last mile infrastructure (wire, switches etc.).
>
> However, even in a small town it makes sense to have competition if
> you allow for competition at the right level. For example, it makes
> good economic and social sense for a municipality to manage the
> quality of water, roads, power lines, and telecommunications lines
> (copper and fiber). Competition is then had at the entry points to
> these "natural monopoly" services. In the case of electrical power,
> paying for electricity from different generation sources. In the case
> of telecommunications, buying local loop, long distance, and data
> services from different vendors.
>
> one white paper I'm working on is exploring the economic and social
> impacts of a municipality providing fiber to the house and allowing
> multiple content providers access at the head end of the fiber
> network. One of the interesting twists is that it makes it possible
> for easy development of metropolitan area exchanges and caches which
> would reduce load on major backbones. It also is a key to breaking
> the monopoly lock cable companies have on various cities.
>
> --- eric
>
> --
> Eric S. Johansson ka1eec esj@harvee.billerica.ma.us
> This message was composed almost entirely using NaturallySpeaking
>.
------------------------------
Date: 25 Sep 1999 15:58:36 GMT
From: Brian Mullaney <mullaneb@tecoma.mccc.edu>
Subject: Let's look at real numbers for TNC software sales
Charles Brabham <n5pvl@texoma.net> wrote:
> Uh, Oh! Here comes the nasty, personal suff that you get when you hit the
> "sore spot", dead center.
Yes, Gary forgot the Cardinal Rule, which is "Only Charles is allowed to
insult people"
> Are you claiming that all of those communications with "the rest of the
> world" are strictly via Amateur Radio, and that no Internet links are
> used to, let's say, communicate with and within other tcpip LANS,
> download packet bulletins via telnet, or perhaps telnet to join in on
To be continued in digest: hd_99_242C
Read previous mail | Read next mail
| |
