Re: UNIX and ease of use
On Tue, Mar 03, 1998 at 12:44:58PM -0500, Adam P. Harris wrote:
> >WvDial is very clever, but it and most of its competitors bypass the
> >standard configuration files. This locks the user into their system and
> >pretty much rules out manual editing if the 'EZ' system fails.
I do not like the phrase "locks the user into their system" -- it is
inaccurate. Obviously, if you want to use wvdial, you have to use wvdial.
Beyond that, there is no "locking" being done. WvDial does not modify _any_
pppd configuration files, except for the new /etc/ppp/pap-secrets support.
> Wow, that sucks. I was thinking about installing wvdial but for me this
> rules it out. Why can't it just read/write the standard configs?
I will attempt to argue feebly in favour of wvdial. The problem is: I
think almost everyone on this mailing list has already gone through the pppd
learning curve. We're all developers. We can handle that. WvDial was not
written for us (even though it's supposed to work for us anyway). And
that's why the following argument will seem feeble to us.
Dave Coombs and I wrote WvDial because:
- 'chat' was written with the idea that every modem and dialin server is
different. At the time, this was correct. WvDial was written with the
idea that _all_ modern modems support the base AT command set and handle
locked DTE rates, and that almost all modern ISP's will want you to log
in with some combination of login, password, PAP, and CHAP.
- pppd was designed wrong. GASP! How can I say that about such a
featureful, well-written program? Well, it's nicely _written_, but it
has the wrong design goals. Why does my PPP protocol manager have to
understand how to dial a modem, redial on disconnect, and now, dial on
demand?
The PPP protocol manager should be run from the program that does the
modem initialization and dialing, not the other way around. That way,
the dialer program can keep modem state information, and do redialing
intelligently. You can also run different protocol managers (pppd,
slattach, dip, etc) if you want. Dialing is dialing (and demand dialing
is demand dialing), and should be the same for every protocol manager; it
should be handled by a separate program. What's wrong with diald for
demand-dialing, anyway? Lots of people use it and like it, and it works
with SLIP just like it works with PPP.
- You can't properly detect a modem using a shell script. wvdialconf does
what many people say is an excellent job.
- You can still run 'chat' anyway, if things go wrong.
Now I'll throw something new at you: the first releases of WvDial are
deliberately inflexible because I want more bug reports. :)
The problem is: most people have been well-trained by Microsoft, Debian,
Sun, etc to believe that if their internet dialer doesn't know how to dial
into the internet, it's the user's fault, or at least the ISP's fault.
WvDial 0.x is exactly the opposite: if it can't reach your ISP, it is
undeniably a bug because it can't even be _configured_ to reach your ISP.
Does that sound ridiculous? Maybe, but I'd do it again. I've gotten mail
from a huge number of people about their connection problems -- which have
resulted in quick fixes from me, thus making WvDial better for everyone. I
sincerely doubt that I would have gotten nearly as much detailed information
about weird ISPs if people were permitted to simply add an entry to
wvdial.conf and override the chat script.
You know the interesting thing? Almost all the problems have been "repeats"
of each other. The same fix solves a lot of bug reports at the same time.
'chat' doesn't let us do this, because everyone has to solve the same
problems over and over. 'chat' doesn't grow in intelligence over time, while
wvdial does.
On the other hand, wvdial will grow in flexibility over time. Eventually we
will have to support the people with ISP's that use "Command:" as their
login prompt. (Yes, I actually got a message from a person with this
problem. WvDial cannot use this as a login prompt by default because it
attempts to answer command prompts differently!)
> We need a ppp config that can be run from a base system, allowing users
> to dialup to get the rest of the system if possible.
pppconfig can do this, if we put whiptail and libnewt on the base disks.
That would be quite an improvement over what we have currently.
WvDial will also work, and would make new users' lives much easier, IMHO.
It requires the 'ppp' package, so if something goes wrong with the wvdial
connection (which is hopefully very unlikely) then 'chat' is still
available, as always.
Have fun,
Avery
P.S. can pppconfig handle ISP's who require you to type "ppp" at the first
prompt, and then your username and password later? WvDial can (and
automatically), because James Treacy explained the problem so I could fix
it. If pppconfig cannot do this, maybe I will start arguing that wvdial is
all-around more useful than pppconfig.
P.P.S. If you want join the wvdial development mailing list and help fix
your own complaints, send a message with "Subject: subscribe" to
wvdial-list-request@worldvisions.ca
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: