[UFO Chicago] Recommendations Please: ISP with Shell Access
Neil R. Ormos
ormos@enteract.com
Thu, 15 Aug 2002 00:24:23 -0500 (CDT)
Ian Bicking wrote:
> Neil R. Ormos wrote:
>> RCN/Enteract has announced the elimination of user
>> access to its shell machines, so I'm looking for a new
>> ISP. Any recommendations?
> I always thought those sorts of services were a bit
> superfluous to an ISP. An ISP just connects you to the
> internet...
Oh? That's a bit doctrinaire. And factually incorrect.
Since when did an ISP just connect you to the internet?
Even the cheap ones still provide mail and primitive web
hosting.
> things like mail addresses, web space, and
> shell accounts should be separate. Since it's not the
> primary focus of the ISP, they usually aren't terribly
> good at providing these (except for mail -- but you just
> get trapped by using the ISP address, so it's still no
> good).
I don't see any particular user benefit that necessarily
obtains by separating mail, web space, and shell accounts
from the access interface and backbone interface functions
of an ISP. (Seems a lot like natural gas utility
deregulation, where you buy the service of having the gas
distributed from the incumbent distribution network
operator, but you can buy the gas itself from any of several
vendors.) It's just more vendors to deal with and pay, and
more hassle to select the vendor, but not necessarily any
*better*. It's also more expensive, because now you're
paying for several administrative and billing organizations,
etc.
In point of fact, many ISPs evolved from dial-up BBSs of one
sort or another, or computer timesharing service bureaus,
and had no problem providing shell. For others, shell
access was seen as the part of the core mission, and they
did it well. For example, Enteract's shell, mail, and web
services for individual users were just fine, and even quite
progressive, when it *was* Enteract.
Although it may be a fact of life that most ISPs don't care
about anything but access, and therefore do it poorly, that
doesn't necessarily mean that the services *should* be
separate. The access interface and backbone interface
functions could also be separate, but IMO, that doesn't make
sense either.