From: elendil@mintir.new-orleans.la.us (Edward J. Branley)
Newsgroups: alt.bbs
Subject: Re: Sad to say...
Date: Tue, 15 Sep 92 18:59:49 CDT
Organization: Minas Tirith BBS (Public Access Usenet for New Orleans)

davidg@aegis.or.jp (Dave McLane) writes:

> >Ok, I see I didn't do to well explaining that.  Here we batch and compress
> >netnews.  That's not bad, but ZIP and ARJ (which are the two leading
> >compression formats for xmitting FTN-sytle echomail) do a better job of
> >compression.  That's never really been a big issue in Usenet because of fast
> >transmission channels, multi-tasking hosts, etc.  It's a big deal to the sys
> >footing the bill himself, of course.
>
> I don't know about ARJ but I haven't found any consisten advantage
> between pkzip, lharc, and compress. All depends on the data (over
> which you have not control). As for faster communication channels,
> yes, on the backbones, but the dial-up links run at about the same
> speed as anything else.

Multitasking is also a big factor.  When my system pulls in a bunch of news
packets, it can be off-line for as much as an hour at a time, simply tossing
mail.  If that means sticking with compress forever, I'd go for it.

> I think the same thing could be done with UUCP which is, after all,
> only a file transfer protocol plus the ability to excute commands on
> the receiving side.
>
> IMHO what you're talking about is some kind of line charge
> efficiency at the cost of a lot of time and effort to make it
> happen. What seemed weird when I went to UNIX/UUCP was this kind of
> thinking pretty much gets thrown out the window. Instead, you use
> the simplest protocol you can so many places can link up without a
> lot of hassles (remember UUCP isn't dependent on any particular OS
> or hardware). This means that the sysadmins don't have to do so much
> to fiddle this and improve that to *save* money, they can do other
> things that *make* money or find other means of support. Make
> for some very different equations.

I'm sure that UUCP could handle file distribution in a more efficient way, but
to what end?  Given that source is the big deal in the *nix world, it's
probably a non-issue in this net.

You're right about the equations being different here.  My UUCP feed is from a
local university.  I'm quite sure that they wouldn't have been so gracious as
to give me a feed if it wasn't so easy to do.  I certainly wouldn't want
anything to change that ease of use on their part... <g>.

>
> >> Are you saying individual sysops can control their feeds from the
> >> receiving side? If so, this sound really great. I'd like to be able
> >> to do that with USENET.
>
> >Same here.  The program I used to use in fido was called AreaFix.  What you
> >was send mail to Areafix @ the node who was your feed.  The subject line of
> >message was a password and any params you wanted to pass to the program.  If
> >the pw agreed with the one in your feed's config file, then you the commands
> >you keyed into the body of the message were executed.  These commands normal
> >added/deleted your node number from the line for a particular echo.  I know
> >that something like this for Usenet would make many a sysadmin happy.
>
> Sure would make me happy! But a lot of sysadmins don't want to let
> anything operate on their machine except rnews & rmail. They are
> afraid of security problems with anything else. And perhaps rightly
> so...

Yeah, there are some security issues, given the larger size of many of the
systems at larger sites.  Only some of the larger fido hubs really come into
contact with more than a couple of systems, and most sites only contact their
feeds one at a time, since they're single-tasking.

> >I find the DOS-based compress that I run to be much less efficient than ZIP.
> >understand the rationales for using it, however, and all my calls on this ne
> >are local, so it doesn't really concern me.  Again, being able to adapt fast
> >when it comes to changing compression formats is one of the advantages Fidon
> >has being essentially an all-PC net.
>
> Yes, I believe Fidonet mainly (only?) runs on IBM-compat PC/XT/AT's.
> UNIX runs on AT's and many other machines as well so instead of being
> able to adapt fast, it uses the lowest-common-demoninator approach.

There are fido-compatible programs for IBM compats, Mac and Amiga for sure.
I believe that BinkleyTerm (a fido comm program) was ported to *nix, but I have
no idea which flavor.  The overwhelming majority are Intel-based.  We used to
give the local Mac user group a hard time because they run their BBS on s 386,
since the Mac-based fido-compatible software is so flaky!

>
> >> I'm curious: how much stuff were they typically getting on a daily
> >> basis?  How much were they paying in telco charges? And who was
> >> paying, exactly, the sysop of the users, both?
>
> >I don't know what they were paying, never thought to ask.  The
> >folks calling in did so about once a week or so, fetched my new
> >files list, then would call back if I had added anything of interest
> >to them.  I *assume* this was a better deal for them, since I know
> >that calling Europe from here runs about $2/minute.
>
> I see. I thought they were calling in at least once a day.
>
> FYI, calls from Japan to the U.S. are metered in terms of 6 second
> units. Lowest rate is at night which costs 22 yen/6-secs for the
> first 1 minute and then 11 yen/6-sec afterwards. In round numbers it
> takes 1 minute to CONNECT and get UUPC link running which costs 220
> yen ($1.76) and the rest goes at 110 yen/minute ($.88). Not so
> bad....
>

I know that US Sprint bills in 6-sec. units, since that's why I switched to
them some months back.  I believe that AT&T has also started this since then.



|Edward J. Branley                         elendil@mintir.New-Orleans.LA.US|
|Seashell Software                                UUCP:  rex!mintir!elendil|
|3508 North Woodlawn Avenue                          Compu$erve: 71237,2227|
|Metairie, LA   70006       voice: +1-504-455-5087     bbs: +1-504-455-8665|