dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) (10/24/89)
Should I go shareware with some of my better programs? That is,
request $$ ? I was thinking of this:
DME $10
DCron $10
DNet $10
DMouse $10
Is that too little? Probably :-) . Once you 'buy' the program
updates would be free. It wouldn't retroactive for the large number
of people and friends who already use these programs, but there
would be an obligation to pay once when they get their next update.
As I said, updates would be free, but the user will need a
modem. I would commit time to make the programs spiffy.
I will be setting up a simplistic BBS on my Amiga from which
people will be able to dial up and retrieve the latest of these
programs. I can't commit HD space for a general upload/download
area because I can't afford too much connect-time bandwidth to
build up if it becomes too popular :-). The BBS will be
auto-newuser and based on private mail boxes (i.e. no chat yet).
If I can manage to get a local UUCP feed, users would have access
to the USENET for private mail (but not news).
The reason being that I would like to reserve most of the time
for UUCP dialups, and a busy BBS precludes being able to use the
machine for any real work. My Amiga is now on full time 100% and
has a dedicated dialup number that isn't even connected to a phone!
I'll announce that once I get my BBS up.
Speaking of which, I am now running UUCP. Anybody else who
runs UUCP and wants me to setup a UUCP login for them on my
machine (overload) is welcome to email me! I am based in
Berkeley California. I might even be able to manage a news
feed but that is WAYYYY in the future. You would have to call
me but would be able to do so almost any time of the day... the
worst that would happen is that you would get a busy signal or
ring ring ring forever if the machine is down.
I have also written a couple of new programs. One especially,
Getty, is really awesome. It sits on the serial.device (you can
run a getty for each of your serial ports) and waits for incomming
calls. It is completely passive to any program that uses SERF_SHARED.
It deals with connecting, Login:, Password:, and runs an arbitrary
program specified from a Passwd file.
I have hacked UUCICO (UUCP) To be runnable from the password file
which makes the whole implementation very, very clean, because you
no longer need to leave UUCICO running waiting for connections and
taking up room and stealing the serial.device ... and with Getty,
one can setup his machine to handle different kinds of dialups...
i.e. one login would run your BBS while another would run UUCICO
for a UUCP transaction, while another would do something else, etc...
The Getty takes all the work out of writing a serial port
interaction program in that it deals with accepting the calls,
the CONNECT message, getting the baud rate right, etc... and
it deals with the disconnect sequence after the program it runs
exits.
The Getty provides a central point from which many programs
can be selected by a person dialing up (provided he knows the login
and (optional) password). The catch is that it really needs some
backing to get people to take the extra 10 minutes and fix up
their serial.port interaction programs to be compatible with Getty
(This involves interpreting a few options on the command line...
The getty passes the name of the serial.device and unit to the
programs it runs for complete generality), and ripping out any
already existing code to deal with connecting and disconnecting,
Terminal emulators should always open the serial.device
SERF_SHARED (This is *really* easy to do !!) to be compatible with
Getty. The idea is that Getty would be run for each serial port
you've got connected to a modem from your startup sequence and
remain resident forever.
It *REALLY* brings out the machine's communication capabilities.
My problem is that I would like Getty to become at the minimum,
Shareware, which precludes making it part of the UUCP distribution
unless I can convince all the people holding copyrights on the UUCP
code (William Loftus, Dan Schein mainly) to make UUCP shareware as
well. I've put in maybe 60 hours of work into W.L's 0.40 release
and it's really hot, and I really want to reach some sort of
compromise so I can make the stuff available to people.
----
Lastly, I have written a UUSER: device which works like AUX: but is
really meant for programs run from Getty.... It allows you to write
very general programs that use stdin and stdout to talk to the
serial port in a relatively clean fashion instead of having to
write complicated serial.device routines, which is what most people
do now. This is what my BBS will use to communicate. Since stdio
is used the BBS could be run from a CLI just as easily as from the
Getty.
I would like to make Getty and UUSER: shareware ($10), and Licensable
for people to include in their own distributions at a reasonable
figure, say $2/copy of your software package that you distribute.
(The idea here being that I can make this part of the UUCP
distribution... I have to talk to William Loftus on that).
So, what do you all think? This message is being cross posted
to BIX too, by the way.
-Mattvalentin@cbmvax.UUCP (Valentin Pepelea) (10/25/89)
In article <8910240722.AA22726@postgres.Berkeley.EDU> dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) writes: > I have also written a couple of new programs. One especially, > Getty, is really awesome. It sits on the serial.device (you can > run a getty for each of your serial ports) and waits for incomming > calls. It is completely passive to any program that uses SERF_SHARED. > It deals with connecting, Login:, Password:, and runs an arbitrary > program specified from a Passwd file. Great, this is something really needed. You see, the best language a BBS should be be written in is REXX. Why? Because all a BBS does is present menus and type up files to the user. Sometimes it also shuffles files around. It is to this purpose that macro s(scripting) languages such as REXX excel. On the IBM mainframe I used at university, the news and mail readers were all written in REXX. And they blow the UNIX rn readers away. And here we see that even the password requester should be written in REXX. All that Getty should be doing is calling the PASSWD program, giving it the name, unit number, parity and baud of the connecting call. > The Getty takes all the work out of writing a serial port > interaction program in that it deals with accepting the calls, > the CONNECT message, getting the baud rate right, etc... and > it deals with the disconnect sequence after the program it runs > exits. Wonderful! Now get the password requester out of there! > Lastly, I have written a UUSER: device which works like AUX: but is > really meant for programs run from Getty.... It allows you to write > very general programs that use stdin and stdout to talk to the > serial port in a relatively clean fashion instead of having to > write complicated serial.device routines, which is what most people > do now. This is what my BBS will use to communicate. Since stdio > is used the BBS could be run from a CLI just as easily as from the > Getty. Neat, but I'd say that AUX: should handle the problem right anyway. You have to explain a little more just what exactly UUSER: does that AUX: does not. Valentin -- "An operating system without Name: Valentin Pepelea virtual memory is an operating Phone: (215) 431-9100 system without virtue." Usenet: uunet!cbmvax!valentin Bitnet: cbmvax!valentin@uunet.uu.net - Ancient Inca Proverb Claimer: these aren't Commodore thoughts
usenet@cps3xx.UUCP (Usenet file owner) (10/25/89)
I use a Supra internal modem that runs a modem0.device. Any time I want to use a program that needs the serial.device I have to run a conversion program on it (it doesn't work with Handshake). I would find it helpful if you didn't require programs to use the serial.device. Maybe make it the default but include a command line option for other devices. zik
peter@sugar.hackercorp.com (Peter da Silva) (10/25/89)
Some people don't have REXX:. Why should they need it to run getty? If the code exists, there's no point ripping it out. -- Peter "Have you hugged your wolf today" da Silva `-_-' ...texbell!sugar!peter, or peter@sugar.hackercorp.com 'U` ``Back off dude! I'm a topologist!'' -- Andrew Molitor <amolitor@eagle.wesleyan.edu>
jwright@atanasoff.cs.iastate.edu (Jim Wright) (10/25/89)
In article <5114@cps3xx.UUCP> symanzik@frith.UUCP (Ed Symanzik) writes: | I use a Supra internal modem that runs a modem0.device. Me too. | I would find it | helpful if you didn't require programs to use the serial.device. Maybe | make it the default but include a command line option for other devices. "It's in there!" :-) -- Jim Wright jwright@atanasoff.cs.iastate.edu (ignore the Reply-To: line)
dbk@teroach.UUCP (Dave Kinzer) (10/26/89)
In article <8910240722.AA22726@postgres.Berkeley.EDU> dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) writes: > > I have also written a couple of new programs. One especially, > Getty, is really awesome. It sits on the serial.device (you can > run a getty for each of your serial ports) and waits for incomming > calls. It is completely passive to any program that uses SERF_SHARED. > It deals with connecting, Login:, Password:, and runs an arbitrary > program specified from a Passwd file. > Check Fred Fish disk 247 for my implementation of this function. It does not require a shared serial port (but is not exactly clean, as explained in the documents.) I have noticed a problem running Atrterm (atredes terminal), but not with anything else. It is freeware. * * * Imminent use of deathnet predicted. * * * // Dave Kinzer (602)897-3085 asuvax!mcdphx!teroach!dbk Opinions are mine. \X/
UH2@PSUVM.BITNET (Lee Sailer) (10/27/89)
<4427@sugar.hackercorp.com> <8276@cbmvax.UUCP>
After Matt Dillon asked about whether or not he should "go commercial"
all the replies seem to be about other topics.
Sure, Dillon. Go commercial. If you just go the shareware route, it
looks to me like your stuff is enough beloved that you might make a few bucks.
I seem to recall that about one year ago, Bill Hawes reported about 300
registered users of ConMan, which amounts to $3000. But he also seemed
to think that it hadn't been worth it.
On the other hand, the PCWrite people in msdos-land made a lot of money.
Maybe another idea would be to farm out your software to some small
company that already has a few products of it's own, and wants to add
some technical systems software like your to the product line. Seems to me
there are a half dozen or so tiny software companies here in comp.sys.amiga
that might accomplish some exonomies of scale by banding together to share
order processing, taxes, and so on. (You know who you are, and you look
mahvelous.)
leehcobb@walt.cc.utexas.edu (Henry J. Cobb) (10/27/89)
I've looked at DME, and its Arexx support looks real familiar. I.e. "I call Arexx macros, they don't call me". This is not a gripe vs DME, everybody else does just the same thing. I have this ideal of an editor: The user types in "edit foo", and then the edit command (which is rather small and easily residentable) checks to see if the manager process is running (there will only be one on any system), if not it starts it up and hands it the command line it was given. It then returns the error result, if any, to the user and exits. The manager process runs all the time at a fairly high priority, waiting for messages. When it is told to edit a file, it first checks to see if any buffer tasks have been assigned to that file, and if so it sends one of them a message to "pop to the front", and then goes back to waiting. It also can receive Arexx messages and acts as a host for Arexx scripts being run by other programs or outside macros. It is the only process in the editor and so is the gateway to the file system. The buffer tasks are each just responceable for one window, and one buffer, but two or more of them can share a buffer and provide two different views into it. When the user makes a save, load or browse request of them they wake up the manager to handle it, but they do they're own editing (search, replace, word-wrap, etc.) through shared code. In addition to the standard cut and paste operations, every buffer is 'posted' to the clipboard device, and so when other programs request the data, the manager asks the buffer task responceable to make it available. Note that this scheme allows independent operations on shared buffers, and will take great advantage of Arexx, without requiring it. Henry J. Cobb hcobb@walt.cc.utexas.edu
dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) (10/27/89)
Since the UUCP stuff still has GNU stuff in it, it must be
Freeware. So, Getty will most definitely be Freeware too since
Its current best use is with UUCP.
Re: ARexx... Writing a BBS, news reader in ARexx sounds like
a nice solution, but the Getty itself should not be written in
ARexx... don't go overboard with ARexx!
Getty is self contained. It exists to serve an explicit
function... front end people/programs dialing up, get the baud
rate, and run the right program (based on a UNIX like passwd file),
then run the appropriate disconnect sequence when the program
exits.
At the moment its best use is with UUCP and BBSs... especially
systems on which people want to run both UUCP and a BBS.
I don't know exactly how AUX: is supposed to work, but unless
it deals with the carrier properly, has a programmable timeout for
read()s, and an asynchronous write buffer, AND can handle multiple
serial ports, it's useless for most applications that I can think
of.
---
UUCICO: I've added security (people can't overwrite your
startup sequence with UUCP transfers, for example), rewritten
GIO.C (the G protocol) completely, rewritten SYSDEP.C, redone
quite a big hunk of UUCICO.C, and added various other miscellanious
items. Combined with Getty it makes UUCP into an extremely useful
distribution.
The whole UUCP dist should appear via the moderator in a week
or two. It will appear via anonymous FTP to ucbvax.berkeley.edu
in a couple of days.
-Mattdillon@POSTGRES.BERKELEY.EDU (Matt Dillon) (10/27/89)
:I use a Supra internal modem that runs a modem0.device. Any time I want
:to use a program that needs the serial.device I have to run a conversion
:program on it (it doesn't work with Handshake). I would find it
:helpful if you didn't require programs to use the serial.device. Maybe
:make it the default but include a command line option for other devices.
:
:zik
??? As long as modem0.device uses the same commands as a
serial.device, the Getty stuff and UUCP, at least *my* UUCP stuff
should work just fine on it.
-Mattkjohn@richsun.UUCP (John Kjellman) (10/28/89)
In article <8910240722.AA22726@postgres.Berkeley.EDU> dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) writes: > > Should I go shareware with some of my better programs? That is, > request $$ ? I was thinking of this: > > DME $10 > DCron $10 > DNet $10 > DMouse $10 I think this is far too little, maybe a higher (say $20 ?) price with a package deal (all 4 for $50 ?) would be better (for you :-). > [......] > As I said, updates would be free, but the user will need a > modem. I would commit time to make the programs spiffy. Distribution of upgrades via modem is great FOR LOCAL RESIDENTS.... How would users w/o USENET access find out about new upgrades? Maybe a mailing of some sort? I dunno ...... Mailing update disks would be the best, but that would require some sort of annual fee ...... I dunno about the rest of you, but I would (if I can ever get financing for my new Amiga :-) certainly purchase all 4 programs, they are a big part of what makes the Amiga so great..... > [.....] > I have also written a couple of new programs. One especially, Sounds like a couple more winners to me Matt..... Maybe a company is in order MattWare, MWare, M-Dimensional Software, <insert your favorite M-word here> Software, ..... > [.....] > -Matt KJohn P.S. If I knew what I was talking about someone would be paying me for this :-) -- | Only /// | #include <std/disclaimer> /*KJohn - The man without an Amiga*/ | | Amiga \XX/ | kjohn@richp1 or [ purdue | cs.ubc | mcdchg ] ! richp1 ! kjohn |
perry@madnix.UUCP (Perry Kivolowitz) (10/28/89)
In article <20170@ut-emx.UUCP> hcobb@walt.cc.utexas.edu (Henry J. Cobb) writes: > I have this ideal of an editor: For the most part you just described CygnusEd Professional. In release 1 ced itself was rarely invoked directly (or rather, shouldn't have been). Instead a 1K program called ``ed'' is invoked. In release 2, there's even less of a reason to ever invoke ced directly. pk (p.s. yes yes, release 2 is coming...) -- Perry Kivolowitz, ASDG Inc. ``We look for things. Things that make us go.'' UUCP: {harvard|rutgers|ucbvax}!uwvax!astroatc!nicmad!madnix!perry CIS: 76004,1765 PLINK: pk-asdg
FelineGrace@cup.portal.com (Dana B Bourgeois) (10/30/89)
[line eater food] Matt: I use several of your programs and I think that going commercial is a good thing. $10 sounds OK, $20 is fine too. I like the idea of $50 for all of the programs you mentioned. If you do go commercial, I think it is important that you figure out a better way to notify customers of updates then via a local BBS. I don't want to contact a BBS long-distance simply to see if there is an update. Usenet would work for me, I don't know about other people. A notice in Amazing? Dana
bjornk@bula.se (Bjorn Knutsson) (11/03/89)
In article <8910240722.AA22726@postgres.Berkeley.EDU> dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) writes: > As I said, updates would be free, but the user will need a > modem. I would commit time to make the programs spiffy. Which means that you probably will lock all foreign users out. I'd be willing to pay for the software, but I would NOT be willing to pay for support that I can't afford to use. --- Bjorn Knutsson / USENET: bjornk@bula.se or enea!sics!bula!bjornk Stangholmsbacken 44 / Phone: +46-8-710 5306 or +46-8-710 7223 S-127 40 SKARHOLMEN / S W E D E N / "That must be wonderful! I don't understand it at all."