Discussion:
Can my Kaypro 2X connect to a BBS?
Add Reply
fadeToblack
2010-01-28 18:08:41 UTC
Reply
Permalink
I just got a working Kaypro 2X with a built in 300 baud modem.
The TERM program on the CP/M 2.2g floppy does nothing.
What can I do to connect to a BBS?
Thanks for any help.
Michael Black
2010-01-28 19:10:21 UTC
Reply
Permalink
On Thu, 28 Jan 2010, fadeToblack wrote:

> I just got a working Kaypro 2X with a built in 300 baud modem.
> The TERM program on the CP/M 2.2g floppy does nothing.
> What can I do to connect to a BBS?
> Thanks for any help.
>
First you have to find a BBS. They haven't completely disappeared, but
mostly have, as interest moved to the internet (or to look at it
from another angle, once the internet became accessible and cheap,
alternatives were less appealing). The only local BBS that I know
about nowadays hasn't had a phone line in most of a decade, you have
to telnet in.

So you'd have to find a BBS and a phone number for it. That may actually
mean at this point making a long distance call.

It may be even more complicated, since the modem is only 300baud. Even 15
years ago, there were some BBSs that wouldn't accept such slow modems, and
that may be even more the case now.

You may have to dial manually, if you go far enough back the modems
weren't smart and thus didn't respond to "AT" commands. At the very
least, you'd have to run a program that activated the relay in the modem
at the right speed to do the dialing.

If it is a "smart" modem, then you'd send commands to it using the
terminal program. You'd look up the "AT" commands with a websearch,
and then send them to the modem, and see what you were hearing from
the modem's speaker (assuming it had a speaker), listen for a dialtone,
and the dialing and then the ringing.

If the terminal program is young enough, there may be a menu that allows
you to do the dialing from that.

Beyond that, one would need specific information on what wasn't working.

Michael
jim
2010-01-28 20:20:49 UTC
Reply
Permalink
On Jan 28, 2:10 pm, Michael Black <***@ncf.ca> wrote:
> On Thu, 28 Jan 2010, fadeToblack wrote:
> > I just got a working Kaypro 2X with a built in 300 baud modem.
> > The TERM program on the CP/M 2.2g floppy does nothing.
> > What can I do to connect to a BBS?
> > Thanks for any help.
>
> First you have to find a BBS.  They haven't completely disappeared, but
> mostly have, as interest moved to the internet (or to look at it
> from another angle, once the internet became accessible and cheap,
> alternatives were less appealing).  The only local BBS that I know
> about nowadays hasn't had a phone line in most of a decade, you have
> to telnet in.
>
> So you'd have to find a BBS and a phone number for it.  That may actually
> mean at this point making a long distance call.
>
> It may be even more complicated, since the modem is only 300baud.  Even 15
> years ago, there were some BBSs that wouldn't accept such slow modems, and
> that may be even more the case now.
>
> You may have to dial manually, if you go far enough back the modems
> weren't smart and thus didn't respond to "AT" commands.  At the very
> least, you'd have to run a program that activated the relay in the modem
> at the right speed to do the dialing.
>
> If it is a "smart" modem, then you'd send commands to it using the
> terminal program.  You'd look up the "AT" commands with a websearch,
> and then send them to the modem, and see what you were hearing from
> the modem's speaker (assuming it had a speaker), listen for a dialtone,
> and the dialing and then the ringing.
>
> If the terminal program is young enough, there may be a menu that allows
> you to do the dialing from that.
>
> Beyond that, one would need specific information on what wasn't working.
>
>    Michael

Hello:

I am sorry but I "Lurk" here a lot but if you need Procomm program let
me know

JIM
***@care2.com
Peter Flass
2010-01-28 23:22:16 UTC
Reply
Permalink
Michael Black wrote:
> On Thu, 28 Jan 2010, fadeToblack wrote:
>
>> I just got a working Kaypro 2X with a built in 300 baud modem.
>> The TERM program on the CP/M 2.2g floppy does nothing.
>> What can I do to connect to a BBS?
>> Thanks for any help.
>>
> First you have to find a BBS. They haven't completely disappeared, but
> mostly have, as interest moved to the internet (or to look at it
> from another angle, once the internet became accessible and cheap,
> alternatives were less appealing). The only local BBS that I know
> about nowadays hasn't had a phone line in most of a decade, you have
> to telnet in.
>
> So you'd have to find a BBS and a phone number for it. That may
> actually mean at this point making a long distance call.
>
> It may be even more complicated, since the modem is only 300baud. Even
> 15 years ago, there were some BBSs that wouldn't accept such slow
> modems, and that may be even more the case now.
>
> You may have to dial manually, if you go far enough back the modems
> weren't smart and thus didn't respond to "AT" commands. At the very
> least, you'd have to run a program that activated the relay in the modem
> at the right speed to do the dialing.
>
> If it is a "smart" modem, then you'd send commands to it using the
> terminal program. You'd look up the "AT" commands with a websearch,
> and then send them to the modem, and see what you were hearing from
> the modem's speaker (assuming it had a speaker), listen for a dialtone,
> and the dialing and then the ringing.
>
> If the terminal program is young enough, there may be a menu that allows
> you to do the dialing from that.
>
> Beyond that, one would need specific information on what wasn't working.
>
> Michael
>
>

Get another pc and run Kermit, connecting the two with a null modem.
John Crane
2010-01-29 16:12:23 UTC
Reply
Permalink
I have a Kaypro and what I do is connect to a local UNIX time-share system
(yes, they still exist too, I use SDF). But I use an external modem
connected to my serial port. I can get 4800 baud from it reliably, but the
old Kaypro starts to drop bits at 9600. Once I'm in UNIX, I telnet to
whatever BBS I want. It works for me.

-J
John Crane
2010-01-30 15:40:32 UTC
Reply
Permalink
As far as software, I use MODEM on the Kaypro with an overlay for an
external smartmodem. I've also used MEX on my Osborne and that's a good one
too.

There are lots of comm programs and associated overlays on the Walnut CP/M
CD-ROM. Some assembly & loading is usually required, but the more popular
machines (like the Kaypros & Osbornes) have some ready-to-run programs that
have the overlays "pre-attached" to the body of the main program.

If you're unfamiliar with this two-part approach; it's done to seperate the
main program (what the user sees), from the underlying I/O routines (which
are frequently machine specific in the CP/M world).

If you want to contact BBSs with your Kaypro, just do it. Remembering that
computers of that era took a little more work than today's PCs & MACs.
Don't listen to the naysayers who say "just use an old PC". You have a nice
CP/M machine and it's fully capable of doing what you want. And who knows,
you may just learn something about your machine along the way.

-J


"John Crane" <***@yahoo.com> wrote in message
news:***@pghconnect.com...
>I have a Kaypro and what I do is connect to a local UNIX time-share system
>(yes, they still exist too, I use SDF). But I use an external modem
>connected to my serial port. I can get 4800 baud from it reliably, but the
>old Kaypro starts to drop bits at 9600. Once I'm in UNIX, I telnet to
>whatever BBS I want. It works for me.
>
> -J
>
fadeToblack
2010-02-03 03:44:27 UTC
Reply
Permalink
On Jan 30, 7:40 am, "John Crane" <***@yahoo.com> wrote:
> As far as software, I use MODEM on the Kaypro with an overlay for an
> external smartmodem.  I've also used MEX on my Osborne and that's a good one
> too.
>
> There are lots of comm programs and associated overlays on the Walnut CP/M
> CD-ROM.  Some assembly & loading is usually required, but the more popular
> machines (like the Kaypros & Osbornes) have some ready-to-run programs that
> have the overlays "pre-attached" to the body of the main program.
>
> If you're unfamiliar with this two-part approach; it's done to seperate the
> main program (what the user sees), from the underlying I/O routines (which
> are frequently machine specific in the CP/M world).
>
> If you want to contact BBSs with your Kaypro, just do it.  Remembering that
> computers of that era took a little more work than today's PCs & MACs.
> Don't listen to the naysayers who say "just use an old PC".  You have a nice
> CP/M machine and it's fully capable of doing what you want.  And who knows,
> you may just learn something about your machine along the way.
>
> -J
>
> "John Crane" <***@yahoo.com> wrote in message
>
> news:***@pghconnect.com...
>
> >I have a Kaypro and what I do is connect to a local UNIX time-share system
> >(yes, they still exist too, I use SDF).  But I use an external modem
> >connected to my serial port.  I can get 4800 baud from it reliably, but the
> >old Kaypro starts to drop bits at 9600.  Once I'm in UNIX, I telnet to
> >whatever BBS I want.  It works for me.
>
> > -J



Is there anyway you could send me the MODEM program on a 5.25" floppy
with the overlay for an
external Smartmodem?
I have a serial cable and can buy a
Hayes Smartmodem 9600. V-Series off ebay no problem.

I'm a novice at this tho I did have an Amiga 500 with a 2400 baud
modem in the late 80s.

Thanks for any info.
dwillsxbr(AT)gmail(DOT)com
Chris Barts
2010-02-13 01:37:12 UTC
Reply
Permalink
"John Crane" <***@yahoo.com> writes:
> "John Crane" <***@yahoo.com> wrote in message
> news:***@pghconnect.com...
>>I have a Kaypro and what I do is connect to a local UNIX time-share system
>>(yes, they still exist too, I use SDF). But I use an external modem
>>connected to my serial port. I can get 4800 baud from it reliably, but the
>>old Kaypro starts to drop bits at 9600. Once I'm in UNIX, I telnet to
>>whatever BBS I want. It works for me.
>>
>> -J
>>
< moron-posting fixed. >
<snip>
> There are lots of comm programs and associated overlays on the Walnut CP/M
> CD-ROM. Some assembly & loading is usually required, but the more popular
> machines (like the Kaypros & Osbornes) have some ready-to-run programs that
> have the overlays "pre-attached" to the body of the main program.
>
> If you're unfamiliar with this two-part approach; it's done to seperate the
> main program (what the user sees), from the underlying I/O routines (which
> are frequently machine specific in the CP/M world).

This is usually done with dynamic libraries in modern systems. This
'pre-attached overlay' business sounds a lot like static linking, which
is derided on modern systems as a waste of disk space (replicating all
that library code into every program that uses it). Interesting to know
it's done so routinely on smaller systems.

(Disk space isn't the only reason. You also want bugfixes to propagate
without rebuilding the world.)

> If you want to contact BBSs with your Kaypro, just do it. Remembering
> that computers of that era took a little more work than today's PCs &
> MACs.

MACs? Do machines without a network card get a MAC?

> Don't listen to the naysayers who say "just use an old PC". You have
> a nice CP/M machine and it's fully capable of doing what you want.

If 'what you want' is 'connecting to BBSes', you can do that with
machines more limited than anything running CP/M.

> And who knows, you may just learn something about your machine along
> the way.

What's more is that you'll have to, in order to use it.

GUI and text menu learning curve: Gentle and slow, then stops at a low
plateau.

Command line learning curve: Brick wall, then as steep as you want, as
high as you can manage.

CP/M is all, or nearly all, command line.

(Front-panel-only means a higher brick wall, but is otherwise similar to
the command line curve.)
Charlie Gibbs
2010-02-14 15:29:47 UTC
Reply
Permalink
In article <***@chbarts.motzarella.org>,
chbarts+***@gmail.com (Chris Barts) writes:

> This is usually done with dynamic libraries in modern systems. This
> 'pre-attached overlay' business sounds a lot like static linking,
> which is derided on modern systems as a waste of disk space
> (replicating all that library code into every program that uses it).
> Interesting to know it's done so routinely on smaller systems.

It's ironic, though, that this argument is used by distributors
of bloatware. Lean-and-mean static-linked executables can take
up less disk space than bloated modules that use dynamic libraries.

> (Disk space isn't the only reason. You also want bugfixes to propagate
> without rebuilding the world.)

Or, in the case of Microsoft, you want "fixes" to break everything
else in the system.

> GUI and text menu learning curve: Gentle and slow, then stops at a low
> plateau.
>
> Command line learning curve: Brick wall, then as steep as you want, as
> high as you can manage.

That's a nice way of putting it. I've always thought of the GUI
learning curve as gentle and slow, ending in a brick wall where
it becomes very difficult to impossible to do tasks beyond a
certain complexity - but your "plateau" image sounds much more
(appropriately) final.

--
/~\ ***@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!
Walter Bushell
2010-02-14 18:52:17 UTC
Reply
Permalink
In article <***@kltpzyxm.invalid>,
"Charlie Gibbs" <***@kltpzyxm.invalid> wrote:

> In article <***@chbarts.motzarella.org>,
> chbarts+***@gmail.com (Chris Barts) writes:
>
> > This is usually done with dynamic libraries in modern systems. This
> > 'pre-attached overlay' business sounds a lot like static linking,
> > which is derided on modern systems as a waste of disk space
> > (replicating all that library code into every program that uses it).
> > Interesting to know it's done so routinely on smaller systems.
>
> It's ironic, though, that this argument is used by distributors
> of bloatware. Lean-and-mean static-linked executables can take
> up less disk space than bloated modules that use dynamic libraries.
>
> > (Disk space isn't the only reason. You also want bugfixes to propagate
> > without rebuilding the world.)
>
> Or, in the case of Microsoft, you want "fixes" to break everything
> else in the system.
>
> > GUI and text menu learning curve: Gentle and slow, then stops at a low
> > plateau.
> >
> > Command line learning curve: Brick wall, then as steep as you want, as
> > high as you can manage.
>
> That's a nice way of putting it. I've always thought of the GUI
> learning curve as gentle and slow, ending in a brick wall where
> it becomes very difficult to impossible to do tasks beyond a
> certain complexity - but your "plateau" image sounds much more
> (appropriately) final.

But only the types who would post here or technical fora are going to go
beyond the plateau of the GUI. Many don't get very far towards the
plateau and that's OK.

For types like me, having a Unix command line beneath the hood is a
great comfort, but I do most of my scripting in Applescript.

--
A computer without Microsoft is like a chocolate cake without mustard.
jmfbahciv
2010-02-15 12:36:24 UTC
Reply
Permalink
Walter Bushell wrote:
> In article <***@kltpzyxm.invalid>,
> "Charlie Gibbs" <***@kltpzyxm.invalid> wrote:
>
>> In article <***@chbarts.motzarella.org>,
>> chbarts+***@gmail.com (Chris Barts) writes:
>>
>>> This is usually done with dynamic libraries in modern systems. This
>>> 'pre-attached overlay' business sounds a lot like static linking,
>>> which is derided on modern systems as a waste of disk space
>>> (replicating all that library code into every program that uses it).
>>> Interesting to know it's done so routinely on smaller systems.
>> It's ironic, though, that this argument is used by distributors
>> of bloatware. Lean-and-mean static-linked executables can take
>> up less disk space than bloated modules that use dynamic libraries.
>>
>>> (Disk space isn't the only reason. You also want bugfixes to propagate
>>> without rebuilding the world.)
>> Or, in the case of Microsoft, you want "fixes" to break everything
>> else in the system.
>>
>>> GUI and text menu learning curve: Gentle and slow, then stops at a low
>>> plateau.
>>>
>>> Command line learning curve: Brick wall, then as steep as you want, as
>>> high as you can manage.
>> That's a nice way of putting it. I've always thought of the GUI
>> learning curve as gentle and slow, ending in a brick wall where
>> it becomes very difficult to impossible to do tasks beyond a
>> certain complexity - but your "plateau" image sounds much more
>> (appropriately) final.
>
> But only the types who would post here or technical fora are going to go
> beyond the plateau of the GUI. Many don't get very far towards the
> plateau and that's OK.

Wrong. think of all the wasted time non-technical people are
spending trying to find one thing.

>
> For types like me, having a Unix command line beneath the hood is a
> great comfort, but I do most of my scripting in Applescript.
>

it's not a comfort to me.

/BAH
Charlie Gibbs
2010-02-15 14:49:38 UTC
Reply
Permalink
In article <***@news3.newsguy.com>, ***@aol (jmfbahciv)
writes:

> Walter Bushell wrote:
>
>> In article <***@kltpzyxm.invalid>,
>> "Charlie Gibbs" <***@kltpzyxm.invalid> wrote:
>>
>>> In article <***@chbarts.motzarella.org>,
>>> chbarts+***@gmail.com (Chris Barts) writes:
>>>
>>>> GUI and text menu learning curve: Gentle and slow, then stops
>>>> at a low plateau.
>>>>
>>>> Command line learning curve: Brick wall, then as steep as you want,
>>>> as high as you can manage.
>>>
>>> That's a nice way of putting it. I've always thought of the GUI
>>> learning curve as gentle and slow, ending in a brick wall where
>>> it becomes very difficult to impossible to do tasks beyond a
>>> certain complexity - but your "plateau" image sounds much more
>>> (appropriately) final.
>>
>> But only the types who would post here or technical fora are going to
>> go beyond the plateau of the GUI. Many don't get very far towards the
>> plateau and that's OK.
>
> Wrong. think of all the wasted time non-technical people are
> spending trying to find one thing.

Screw 'em. They can point and click to their hearts' content,
and are usually having such a good time that they resent any
efforts to help them. It's when they finally get tired of it
and try to draw me into the morass that I bitch about wasted
time - because now it's my time that's being wasted.

--
/~\ ***@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!
Charles Richmond
2010-02-16 01:47:02 UTC
Reply
Permalink
Charlie Gibbs wrote:
> In article <***@news3.newsguy.com>, ***@aol (jmfbahciv)
> writes:
>
>> Walter Bushell wrote:
>>
>>> In article <***@kltpzyxm.invalid>,
>>> "Charlie Gibbs" <***@kltpzyxm.invalid> wrote:
>>>
>>>> In article <***@chbarts.motzarella.org>,
>>>> chbarts+***@gmail.com (Chris Barts) writes:
>>>>
>>>>> GUI and text menu learning curve: Gentle and slow, then stops
>>>>> at a low plateau.
>>>>>
>>>>> Command line learning curve: Brick wall, then as steep as you want,
>>>>> as high as you can manage.
>>>> That's a nice way of putting it. I've always thought of the GUI
>>>> learning curve as gentle and slow, ending in a brick wall where
>>>> it becomes very difficult to impossible to do tasks beyond a
>>>> certain complexity - but your "plateau" image sounds much more
>>>> (appropriately) final.
>>> But only the types who would post here or technical fora are going to
>>> go beyond the plateau of the GUI. Many don't get very far towards the
>>> plateau and that's OK.
>> Wrong. think of all the wasted time non-technical people are
>> spending trying to find one thing.
>
> Screw 'em. They can point and click to their hearts' content,
> and are usually having such a good time that they resent any
> efforts to help them. It's when they finally get tired of it
> and try to draw me into the morass that I bitch about wasted
> time - because now it's my time that's being wasted.
>

Having spoken with secretaries about their word processor usage,
ISTM that they mostly know *one* way to do each thing they do. And
they believe that their *one* way is the *only* way it can be done.

--
+----------------------------------------+
| Charles and Francis Richmond |
| |
| plano dot net at aquaporin4 dot com |
+----------------------------------------+
jmfbahciv
2010-02-16 14:18:52 UTC
Reply
Permalink
Charles Richmond wrote:
> Charlie Gibbs wrote:
>> In article <***@news3.newsguy.com>, ***@aol (jmfbahciv)
>> writes:
>>
>>> Walter Bushell wrote:
>>>
>>>> In article <***@kltpzyxm.invalid>,
>>>> "Charlie Gibbs" <***@kltpzyxm.invalid> wrote:
>>>>
>>>>> In article <***@chbarts.motzarella.org>,
>>>>> chbarts+***@gmail.com (Chris Barts) writes:
>>>>>
>>>>>> GUI and text menu learning curve: Gentle and slow, then stops
>>>>>> at a low plateau.
>>>>>>
>>>>>> Command line learning curve: Brick wall, then as steep as you want,
>>>>>> as high as you can manage.
>>>>> That's a nice way of putting it. I've always thought of the GUI
>>>>> learning curve as gentle and slow, ending in a brick wall where
>>>>> it becomes very difficult to impossible to do tasks beyond a
>>>>> certain complexity - but your "plateau" image sounds much more
>>>>> (appropriately) final.
>>>> But only the types who would post here or technical fora are going to
>>>> go beyond the plateau of the GUI. Many don't get very far towards the
>>>> plateau and that's OK.
>>> Wrong. think of all the wasted time non-technical people are
>>> spending trying to find one thing.
>>
>> Screw 'em. They can point and click to their hearts' content,
>> and are usually having such a good time that they resent any
>> efforts to help them. It's when they finally get tired of it
>> and try to draw me into the morass that I bitch about wasted
>> time - because now it's my time that's being wasted.
>>
>
> Having spoken with secretaries about their word processor usage, ISTM
> that they mostly know *one* way to do each thing they do. And they
> believe that their *one* way is the *only* way it can be done.
>
Or course. It's been an obstacle course for the last 20 years;
a feature of MShit.

/BAH
jmfbahciv
2010-02-16 14:16:08 UTC
Reply
Permalink
Charlie Gibbs wrote:
> In article <***@news3.newsguy.com>, ***@aol (jmfbahciv)
> writes:
>
>> Walter Bushell wrote:
>>
>>> In article <***@kltpzyxm.invalid>,
>>> "Charlie Gibbs" <***@kltpzyxm.invalid> wrote:
>>>
>>>> In article <***@chbarts.motzarella.org>,
>>>> chbarts+***@gmail.com (Chris Barts) writes:
>>>>
>>>>> GUI and text menu learning curve: Gentle and slow, then stops
>>>>> at a low plateau.
>>>>>
>>>>> Command line learning curve: Brick wall, then as steep as you want,
>>>>> as high as you can manage.
>>>> That's a nice way of putting it. I've always thought of the GUI
>>>> learning curve as gentle and slow, ending in a brick wall where
>>>> it becomes very difficult to impossible to do tasks beyond a
>>>> certain complexity - but your "plateau" image sounds much more
>>>> (appropriately) final.
>>> But only the types who would post here or technical fora are going to
>>> go beyond the plateau of the GUI. Many don't get very far towards the
>>> plateau and that's OK.
>> Wrong. think of all the wasted time non-technical people are
>> spending trying to find one thing.
>
> Screw 'em. They can point and click to their hearts' content,
> and are usually having such a good time that they resent any
> efforts to help them. It's when they finally get tired of it
> and try to draw me into the morass that I bitch about wasted
> time - because now it's my time that's being wasted.
>
I just got a report that manufacturers around here are expecting
people to work productively all the time (no more lounging around
for 3/4 of the day any more). Instead of screwing them, offer
time-saving methodologies. Companies are going to be very interested
in getting more strokes or clicks/minute than before.

/BAH
Charlie Gibbs
2010-02-16 16:26:57 UTC
Reply
Permalink
In article <***@news4.newsguy.com>, ***@aol (jmfbahciv)
writes:

> I just got a report that manufacturers around here are expecting
> people to work productively all the time (no more lounging around
> for 3/4 of the day any more). Instead of screwing them, offer
> time-saving methodologies. Companies are going to be very interested
> in getting more strokes or clicks/minute than before.

Unfortunately, a lot of them will probably once again choose the
wrong metric - number of clicks/minute - rather than measuring
the actual amount of work that gets done. And modern GUIs -
which promote lots of mouse clicks to do what a few keystrokes
can accomplish - will score much higher (in addition to being
pretty enough to dazzle management).

--
/~\ ***@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!
jmfbahciv
2010-02-17 13:28:40 UTC
Reply
Permalink
Charlie Gibbs wrote:
> In article <***@news4.newsguy.com>, ***@aol (jmfbahciv)
> writes:
>
>> I just got a report that manufacturers around here are expecting
>> people to work productively all the time (no more lounging around
>> for 3/4 of the day any more). Instead of screwing them, offer
>> time-saving methodologies. Companies are going to be very interested
>> in getting more strokes or clicks/minute than before.
>
> Unfortunately, a lot of them will probably once again choose the
> wrong metric - number of clicks/minute - rather than measuring
> the actual amount of work that gets done. And modern GUIs -
> which promote lots of mouse clicks to do what a few keystrokes
> can accomplish - will score much higher (in addition to being
> pretty enough to dazzle management).
>
But I'm trusting _you_ to figure out which is the best
improvement :-). I was trying to point out a wonderful
business opportunity with the exquisite side-effect
of getting rid of crappy bloat.

/BAH
D.J.
2010-02-15 15:45:14 UTC
Reply
Permalink
On Mon, 15 Feb 2010 07:36:24 -0500, jmfbahciv <***@aol> wrote:
>Walter Bushell wrote:
>> In article <***@kltpzyxm.invalid>,
>> "Charlie Gibbs" <***@kltpzyxm.invalid> wrote:
>>
>>> In article <***@chbarts.motzarella.org>,
>>> chbarts+***@gmail.com (Chris Barts) writes:
>>>
>>>> This is usually done with dynamic libraries in modern systems. This
>>>> 'pre-attached overlay' business sounds a lot like static linking,
>>>> which is derided on modern systems as a waste of disk space
>>>> (replicating all that library code into every program that uses it).
>>>> Interesting to know it's done so routinely on smaller systems.
>>> It's ironic, though, that this argument is used by distributors
>>> of bloatware. Lean-and-mean static-linked executables can take
>>> up less disk space than bloated modules that use dynamic libraries.
>>>
>>>> (Disk space isn't the only reason. You also want bugfixes to propagate
>>>> without rebuilding the world.)
>>> Or, in the case of Microsoft, you want "fixes" to break everything
>>> else in the system.
>>>
>>>> GUI and text menu learning curve: Gentle and slow, then stops at a low
>>>> plateau.
>>>>
>>>> Command line learning curve: Brick wall, then as steep as you want, as
>>>> high as you can manage.
>>> That's a nice way of putting it. I've always thought of the GUI
>>> learning curve as gentle and slow, ending in a brick wall where
>>> it becomes very difficult to impossible to do tasks beyond a
>>> certain complexity - but your "plateau" image sounds much more
>>> (appropriately) final.
>>
>> But only the types who would post here or technical fora are going to go
>> beyond the plateau of the GUI. Many don't get very far towards the
>> plateau and that's OK.
>
>Wrong. think of all the wasted time non-technical people are
>spending trying to find one thing.

I know a number of non-technical people who prefer the GUI, and
dislike the shell/command line. Doesn't seem to slow down their job
performance at all.

JimP.
--
Brushing aside the thorns so I can see the stars.
http://www.linuxgazette.net/ Linux Gazette
http://www.drivein-jim.net/ Drive-In movie theaters
http://crestar.drivein-jim.net/ Feb 2, 2010
Charles Richmond
2010-02-16 01:47:47 UTC
Reply
Permalink
D.J. wrote:
> On Mon, 15 Feb 2010 07:36:24 -0500, jmfbahciv <***@aol> wrote:
>> Walter Bushell wrote:
>>> In article <***@kltpzyxm.invalid>,
>>> "Charlie Gibbs" <***@kltpzyxm.invalid> wrote:
>>>
>>>> In article <***@chbarts.motzarella.org>,
>>>> chbarts+***@gmail.com (Chris Barts) writes:
>>>>
>>>>> This is usually done with dynamic libraries in modern systems. This
>>>>> 'pre-attached overlay' business sounds a lot like static linking,
>>>>> which is derided on modern systems as a waste of disk space
>>>>> (replicating all that library code into every program that uses it).
>>>>> Interesting to know it's done so routinely on smaller systems.
>>>> It's ironic, though, that this argument is used by distributors
>>>> of bloatware. Lean-and-mean static-linked executables can take
>>>> up less disk space than bloated modules that use dynamic libraries.
>>>>
>>>>> (Disk space isn't the only reason. You also want bugfixes to propagate
>>>>> without rebuilding the world.)
>>>> Or, in the case of Microsoft, you want "fixes" to break everything
>>>> else in the system.
>>>>
>>>>> GUI and text menu learning curve: Gentle and slow, then stops at a low
>>>>> plateau.
>>>>>
>>>>> Command line learning curve: Brick wall, then as steep as you want, as
>>>>> high as you can manage.
>>>> That's a nice way of putting it. I've always thought of the GUI
>>>> learning curve as gentle and slow, ending in a brick wall where
>>>> it becomes very difficult to impossible to do tasks beyond a
>>>> certain complexity - but your "plateau" image sounds much more
>>>> (appropriately) final.
>>> But only the types who would post here or technical fora are going to go
>>> beyond the plateau of the GUI. Many don't get very far towards the
>>> plateau and that's OK.
>> Wrong. think of all the wasted time non-technical people are
>> spending trying to find one thing.
>
> I know a number of non-technical people who prefer the GUI, and
> dislike the shell/command line. Doesn't seem to slow down their job
> performance at all.
>
> JimP.

Maybe these non-technical types were *not* doing much of anything
in the first place... ;-)

--
+----------------------------------------+
| Charles and Francis Richmond |
| |
| plano dot net at aquaporin4 dot com |
+----------------------------------------+
Huge
2010-02-16 08:37:52 UTC
Reply
Permalink
On 2010-02-15, D.J <***@cableone.net> wrote:

> I know a number of non-technical people who prefer the GUI, and
> dislike the shell/command line. Doesn't seem to slow down their job
> performance at all.

Until they come to do something the GUI designer didn't think of. And then
they come and see me.

--
219361311
email me, if you must, at huge {at} huge (dot) org <dot> uk]
jmfbahciv
2010-02-16 14:19:44 UTC
Reply
Permalink
Huge wrote:
> On 2010-02-15, D.J <***@cableone.net> wrote:
>
>> I know a number of non-technical people who prefer the GUI, and
>> dislike the shell/command line. Doesn't seem to slow down their job
>> performance at all.
>
> Until they come to do something the GUI designer didn't think of. And then
> they come and see me.
>
<grin> Do you wean them off the GUI addition?

/BAH
jmfbahciv
2010-02-16 14:17:51 UTC
Reply
Permalink
D.J. wrote:
> On Mon, 15 Feb 2010 07:36:24 -0500, jmfbahciv <***@aol> wrote:
>> Walter Bushell wrote:
>>> In article <***@kltpzyxm.invalid>,
>>> "Charlie Gibbs" <***@kltpzyxm.invalid> wrote:
>>>
>>>> In article <***@chbarts.motzarella.org>,
>>>> chbarts+***@gmail.com (Chris Barts) writes:
>>>>
>>>>> This is usually done with dynamic libraries in modern systems. This
>>>>> 'pre-attached overlay' business sounds a lot like static linking,
>>>>> which is derided on modern systems as a waste of disk space
>>>>> (replicating all that library code into every program that uses it).
>>>>> Interesting to know it's done so routinely on smaller systems.
>>>> It's ironic, though, that this argument is used by distributors
>>>> of bloatware. Lean-and-mean static-linked executables can take
>>>> up less disk space than bloated modules that use dynamic libraries.
>>>>
>>>>> (Disk space isn't the only reason. You also want bugfixes to propagate
>>>>> without rebuilding the world.)
>>>> Or, in the case of Microsoft, you want "fixes" to break everything
>>>> else in the system.
>>>>
>>>>> GUI and text menu learning curve: Gentle and slow, then stops at a low
>>>>> plateau.
>>>>>
>>>>> Command line learning curve: Brick wall, then as steep as you want, as
>>>>> high as you can manage.
>>>> That's a nice way of putting it. I've always thought of the GUI
>>>> learning curve as gentle and slow, ending in a brick wall where
>>>> it becomes very difficult to impossible to do tasks beyond a
>>>> certain complexity - but your "plateau" image sounds much more
>>>> (appropriately) final.
>>> But only the types who would post here or technical fora are going to go
>>> beyond the plateau of the GUI. Many don't get very far towards the
>>> plateau and that's OK.
>> Wrong. think of all the wasted time non-technical people are
>> spending trying to find one thing.
>
> I know a number of non-technical people who prefer the GUI, and
> dislike the shell/command line. Doesn't seem to slow down their job
> performance at all.
>
That performance is based on wastage of time. We've been laxing
over the last 30 years. The economic correction which is going
to happen over the next 10 years will be fixing that.

/BAH
D.J.
2010-02-16 23:56:30 UTC
Reply
Permalink
On Tue, 16 Feb 2010 09:17:51 -0500, jmfbahciv <***@aol> wrote:
>D.J. wrote:
>> On Mon, 15 Feb 2010 07:36:24 -0500, jmfbahciv <***@aol> wrote:
>>> Walter Bushell wrote:
>>>> In article <***@kltpzyxm.invalid>,
>>>> "Charlie Gibbs" <***@kltpzyxm.invalid> wrote:
>>>>
>>>>> In article <***@chbarts.motzarella.org>,
>>>>> chbarts+***@gmail.com (Chris Barts) writes:
>>>>>
>>>>>> This is usually done with dynamic libraries in modern systems. This
>>>>>> 'pre-attached overlay' business sounds a lot like static linking,
>>>>>> which is derided on modern systems as a waste of disk space
>>>>>> (replicating all that library code into every program that uses it).
>>>>>> Interesting to know it's done so routinely on smaller systems.
>>>>> It's ironic, though, that this argument is used by distributors
>>>>> of bloatware. Lean-and-mean static-linked executables can take
>>>>> up less disk space than bloated modules that use dynamic libraries.
>>>>>
>>>>>> (Disk space isn't the only reason. You also want bugfixes to propagate
>>>>>> without rebuilding the world.)
>>>>> Or, in the case of Microsoft, you want "fixes" to break everything
>>>>> else in the system.
>>>>>
>>>>>> GUI and text menu learning curve: Gentle and slow, then stops at a low
>>>>>> plateau.
>>>>>>
>>>>>> Command line learning curve: Brick wall, then as steep as you want, as
>>>>>> high as you can manage.
>>>>> That's a nice way of putting it. I've always thought of the GUI
>>>>> learning curve as gentle and slow, ending in a brick wall where
>>>>> it becomes very difficult to impossible to do tasks beyond a
>>>>> certain complexity - but your "plateau" image sounds much more
>>>>> (appropriately) final.
>>>> But only the types who would post here or technical fora are going to go
>>>> beyond the plateau of the GUI. Many don't get very far towards the
>>>> plateau and that's OK.
>>> Wrong. think of all the wasted time non-technical people are
>>> spending trying to find one thing.
>>
>> I know a number of non-technical people who prefer the GUI, and
>> dislike the shell/command line. Doesn't seem to slow down their job
>> performance at all.
>>
>That performance is based on wastage of time. We've been laxing
>over the last 30 years. The economic correction which is going
>to happen over the next 10 years will be fixing that.

The people I refer to use Word, Excel, and powerpoint. They aren't
computer science majors, and I would prefer they never knew the
command line was there.

JimP.
--
Brushing aside the thorns so I can see the stars.
http://www.linuxgazette.net/ Linux Gazette
http://www.drivein-jim.net/ Drive-In movie theaters
http://crestar.drivein-jim.net/ Feb 2, 2010
jmfbahciv
2010-02-17 13:29:38 UTC
Reply
Permalink
D.J. wrote:
> On Tue, 16 Feb 2010 09:17:51 -0500, jmfbahciv <***@aol> wrote:
>> D.J. wrote:
>>> On Mon, 15 Feb 2010 07:36:24 -0500, jmfbahciv <***@aol> wrote:
>>>> Walter Bushell wrote:
>>>>> In article <***@kltpzyxm.invalid>,
>>>>> "Charlie Gibbs" <***@kltpzyxm.invalid> wrote:
>>>>>
>>>>>> In article <***@chbarts.motzarella.org>,
>>>>>> chbarts+***@gmail.com (Chris Barts) writes:
>>>>>>
>>>>>>> This is usually done with dynamic libraries in modern systems. This
>>>>>>> 'pre-attached overlay' business sounds a lot like static linking,
>>>>>>> which is derided on modern systems as a waste of disk space
>>>>>>> (replicating all that library code into every program that uses it).
>>>>>>> Interesting to know it's done so routinely on smaller systems.
>>>>>> It's ironic, though, that this argument is used by distributors
>>>>>> of bloatware. Lean-and-mean static-linked executables can take
>>>>>> up less disk space than bloated modules that use dynamic libraries.
>>>>>>
>>>>>>> (Disk space isn't the only reason. You also want bugfixes to propagate
>>>>>>> without rebuilding the world.)
>>>>>> Or, in the case of Microsoft, you want "fixes" to break everything
>>>>>> else in the system.
>>>>>>
>>>>>>> GUI and text menu learning curve: Gentle and slow, then stops at a low
>>>>>>> plateau.
>>>>>>>
>>>>>>> Command line learning curve: Brick wall, then as steep as you want, as
>>>>>>> high as you can manage.
>>>>>> That's a nice way of putting it. I've always thought of the GUI
>>>>>> learning curve as gentle and slow, ending in a brick wall where
>>>>>> it becomes very difficult to impossible to do tasks beyond a
>>>>>> certain complexity - but your "plateau" image sounds much more
>>>>>> (appropriately) final.
>>>>> But only the types who would post here or technical fora are going to go
>>>>> beyond the plateau of the GUI. Many don't get very far towards the
>>>>> plateau and that's OK.
>>>> Wrong. think of all the wasted time non-technical people are
>>>> spending trying to find one thing.
>>> I know a number of non-technical people who prefer the GUI, and
>>> dislike the shell/command line. Doesn't seem to slow down their job
>>> performance at all.
>>>
>> That performance is based on wastage of time. We've been laxing
>> over the last 30 years. The economic correction which is going
>> to happen over the next 10 years will be fixing that.
>
> The people I refer to use Word, Excel, and powerpoint. They aren't
> computer science majors, and I would prefer they never knew the
> command line was there.
>
I don't give a shit what these people are doing. I do know that
having to go more than 1 level deep to set an option or get
a piece of information sucks.

/BAH
jmfbahciv
2010-02-15 12:34:19 UTC
Reply
Permalink
Charlie Gibbs wrote:
> In article <***@chbarts.motzarella.org>,
> chbarts+***@gmail.com (Chris Barts) writes:
>
>> This is usually done with dynamic libraries in modern systems. This
>> 'pre-attached overlay' business sounds a lot like static linking,
>> which is derided on modern systems as a waste of disk space
>> (replicating all that library code into every program that uses it).
>> Interesting to know it's done so routinely on smaller systems.
>
> It's ironic, though, that this argument is used by distributors
> of bloatware. Lean-and-mean static-linked executables can take
> up less disk space than bloated modules that use dynamic libraries.
>
>> (Disk space isn't the only reason. You also want bugfixes to propagate
>> without rebuilding the world.)
>
> Or, in the case of Microsoft, you want "fixes" to break everything
> else in the system.
>
>> GUI and text menu learning curve: Gentle and slow, then stops at a low
>> plateau.
>>
>> Command line learning curve: Brick wall, then as steep as you want, as
>> high as you can manage.
>
> That's a nice way of putting it. I've always thought of the GUI
> learning curve as gentle and slow, ending in a brick wall where
> it becomes very difficult to impossible to do tasks beyond a
> certain complexity - but your "plateau" image sounds much more
> (appropriately) final.
>
It is not gentle! My low plateau is below sea level. I really,
really, really hate GUI.

/BAH
Charles Richmond
2010-01-29 08:03:46 UTC
Reply
Permalink
fadeToblack wrote:
> I just got a working Kaypro 2X with a built in 300 baud modem.
> The TERM program on the CP/M 2.2g floppy does nothing.
> What can I do to connect to a BBS?
> Thanks for any help.

Acquire another older PC, get some BBS software, and start you
*own* BBS. Then dial in and log on... :-)

--
+----------------------------------------+
| Charles and Francis Richmond |
| |
| plano dot net at aquaporin4 dot com |
+----------------------------------------+
j***@gmail.com
2020-08-10 13:52:16 UTC
Reply
Permalink
On Thursday, January 28, 2010 at 12:08:41 PM UTC-6, fadeToblack wrote:
> I just got a working Kaypro 2X with a built in 300 baud modem.
> The TERM program on the CP/M 2.2g floppy does nothing.
> What can I do to connect to a BBS?
> Thanks for any help.

The Kaypro 2x '84 I purchased way back when, also had a 300 baud modem port. Exploration I made on this issue found that the circuitry to support the 300 baud modem was not populated on the motherboard. :(, I had access at that time to a Kaypro 4 '84 which did have the circuitry populated and I made notes and wrote down a list of the components needed, but my knowledge of electronics at that time was very small, plus I didn't want to destroy the computer, so instead I bought an external 1200 baud modem and connected that way.
Douglas Miller
2020-08-10 17:38:03 UTC
Reply
Permalink
I think the Kaypro built-in 300 baud modem was nearly-instantly obsolete. Plus it had no standard command set (no commands at all, really - software had to directly manipulate the telco interface). I toyed with building it out on my 2X (a lot of soldering on the mainboard), and also considered trying to use it once I got a replacement "universal" mainboard (fully populated). I might have connected once to my university, but never really used it seriously. 300 baud was just too slow by then. I was better off walking up to campus and finding a free terminal.
j***@gmail.com
2020-08-12 20:44:32 UTC
Reply
Permalink
I was friends with the guy where I bought my Kaypro 2x, he used to program in assembly language and wrote his own BBS software. He told me that Kaypro used the wrong Texas Instrument chip, was way too slow (if it even worked at all). He used a 1200 baud external modem, and then upgraded to a 2400 baud modem before I eventually moved away. We eventually lost touch and I haven't been able to locate him since the advent of the internet.
Andreas Kohlbach
2020-08-12 23:39:57 UTC
Reply
Permalink
On Wed, 12 Aug 2020 13:44:32 -0700 (PDT), ***@gmail.com wrote:
>
> I was friends with the guy where I bought my Kaypro 2x, he used to
> program in assembly language and wrote his own BBS software. He told
> me that Kaypro used the wrong Texas Instrument chip, was way too slow
> (if it even worked at all). He used a 1200 baud external modem, and
> then upgraded to a 2400 baud modem before I eventually moved away. We
> eventually lost touch and I haven't been able to locate him since the
> advent of the internet.

Suppose you checked out his name and city. If he moved may be without city
might show something.

Otherwise, did you try Classmates?
--
Andreas
JimP
2020-08-11 14:36:44 UTC
Reply
Permalink
On Mon, 10 Aug 2020 06:52:16 -0700 (PDT), ***@gmail.com
wrote:
>On Thursday, January 28, 2010 at 12:08:41 PM UTC-6, fadeToblack wrote:
>> I just got a working Kaypro 2X with a built in 300 baud modem.
>> The TERM program on the CP/M 2.2g floppy does nothing.
>> What can I do to connect to a BBS?
>> Thanks for any help.
>
>The Kaypro 2x '84 I purchased way back when, also had a 300 baud modem port. Exploration I made on this issue found that the circuitry to support the 300 baud modem was not populated on the motherboard. :(, I had access at that time to a Kaypro 4 '84 which did have the circuitry populated and I made notes and wrote down a list of the components needed, but my knowledge of electronics at that time was very small, plus I didn't want to destroy the computer, so instead I bought an external 1200 baud modem and connected that way.

The OP was 10 years ago.

--
Jim
Peter Flass
2020-08-11 17:33:00 UTC
Reply
Permalink
JimP <***@gmail.com> wrote:
> On Mon, 10 Aug 2020 06:52:16 -0700 (PDT), ***@gmail.com
> wrote:
>> On Thursday, January 28, 2010 at 12:08:41 PM UTC-6, fadeToblack wrote:
>>> I just got a working Kaypro 2X with a built in 300 baud modem.
>>> The TERM program on the CP/M 2.2g floppy does nothing.
>>> What can I do to connect to a BBS?
>>> Thanks for any help.
>>
>> The Kaypro 2x '84 I purchased way back when, also had a 300 baud modem
>> port. Exploration I made on this issue found that the circuitry to
>> support the 300 baud modem was not populated on the motherboard. :(, I
>> had access at that time to a Kaypro 4 '84 which did have the circuitry
>> populated and I made notes and wrote down a list of the components
>> needed, but my knowledge of electronics at that time was very small,
>> plus I didn't want to destroy the computer, so instead I bought an
>> external 1200 baud modem and connected that way.
>
> The OP was 10 years ago.
>

I guess he finally got his question answered ;-)

--
Pete
Peter Flass
2020-08-11 17:33:03 UTC
Reply
Permalink
JimP <***@gmail.com> wrote:
> On Mon, 10 Aug 2020 06:52:16 -0700 (PDT), ***@gmail.com
> wrote:
>> On Thursday, January 28, 2010 at 12:08:41 PM UTC-6, fadeToblack wrote:
>>> I just got a working Kaypro 2X with a built in 300 baud modem.
>>> The TERM program on the CP/M 2.2g floppy does nothing.
>>> What can I do to connect to a BBS?
>>> Thanks for any help.
>>
>> The Kaypro 2x '84 I purchased way back when, also had a 300 baud modem
>> port. Exploration I made on this issue found that the circuitry to
>> support the 300 baud modem was not populated on the motherboard. :(, I
>> had access at that time to a Kaypro 4 '84 which did have the circuitry
>> populated and I made notes and wrote down a list of the components
>> needed, but my knowledge of electronics at that time was very small,
>> plus I didn't want to destroy the computer, so instead I bought an
>> external 1200 baud modem and connected that way.
>
> The OP was 10 years ago.
>

Google news needs to have an automatic filter - only show posts from the
last week by default, and let you expand your search if you want. I have a
lot of trouble with various “support” fora. When I search for a solution to
a problem I get lots of stuff that’s several years, and probably several
releases, old. It’s hard to filter out anything relevant, especially when
posters don’t mention what software version their reply applies to.

--
Pete
Dan Espen
2020-08-11 19:02:42 UTC
Reply
Permalink
Peter Flass <***@yahoo.com> writes:

> JimP <***@gmail.com> wrote:
>> On Mon, 10 Aug 2020 06:52:16 -0700 (PDT), ***@gmail.com
>> wrote:
>>> On Thursday, January 28, 2010 at 12:08:41 PM UTC-6, fadeToblack wrote:
>>>> I just got a working Kaypro 2X with a built in 300 baud modem.
>>>> The TERM program on the CP/M 2.2g floppy does nothing.
>>>> What can I do to connect to a BBS?
>>>> Thanks for any help.
>>>
>>> The Kaypro 2x '84 I purchased way back when, also had a 300 baud modem
>>> port. Exploration I made on this issue found that the circuitry to
>>> support the 300 baud modem was not populated on the motherboard. :(, I
>>> had access at that time to a Kaypro 4 '84 which did have the circuitry
>>> populated and I made notes and wrote down a list of the components
>>> needed, but my knowledge of electronics at that time was very small,
>>> plus I didn't want to destroy the computer, so instead I bought an
>>> external 1200 baud modem and connected that way.
>>
>> The OP was 10 years ago.
>
> Google news needs to have an automatic filter - only show posts from the
> last week by default, and let you expand your search if you want. I have a
> lot of trouble with various “support” fora. When I search for a solution to
> a problem I get lots of stuff that’s several years, and probably several
> releases, old. It’s hard to filter out anything relevant, especially when
> posters don’t mention what software version their reply applies to.

They could put the equivalent of .newsrc in a cookie and only show
unread articles.

--
Dan Espen
JimP
2020-08-11 21:46:49 UTC
Reply
Permalink
On Tue, 11 Aug 2020 10:33:03 -0700, Peter Flass
<***@yahoo.com> wrote:
>JimP <***@gmail.com> wrote:
>> On Mon, 10 Aug 2020 06:52:16 -0700 (PDT), ***@gmail.com
>> wrote:
>>> On Thursday, January 28, 2010 at 12:08:41 PM UTC-6, fadeToblack wrote:
>>>> I just got a working Kaypro 2X with a built in 300 baud modem.
>>>> The TERM program on the CP/M 2.2g floppy does nothing.
>>>> What can I do to connect to a BBS?
>>>> Thanks for any help.
>>>
>>> The Kaypro 2x '84 I purchased way back when, also had a 300 baud modem
>>> port. Exploration I made on this issue found that the circuitry to
>>> support the 300 baud modem was not populated on the motherboard. :(, I
>>> had access at that time to a Kaypro 4 '84 which did have the circuitry
>>> populated and I made notes and wrote down a list of the components
>>> needed, but my knowledge of electronics at that time was very small,
>>> plus I didn't want to destroy the computer, so instead I bought an
>>> external 1200 baud modem and connected that way.
>>
>> The OP was 10 years ago.
>>
>
>Google news needs to have an automatic filter - only show posts from the
>last week by default, and let you expand your search if you want. I have a
>lot of trouble with various “support” fora. When I search for a solution to
>a problem I get lots of stuff that’s several years, and probably several
>releases, old. It’s hard to filter out anything relevant, especially when
>posters don’t mention what software version their reply applies to.

Yeah. There are some old posts in another froup I would like to
read/look up. But the interface is a farce.

--
Jim
Jan van den Broek
2020-08-26 12:52:55 UTC
Reply
Permalink
Tue, 11 Aug 2020 10:33:03 -0700
Peter Flass <***@yahoo.com> schrieb:

[Google hates Usenet-schnipp]

>Google news needs to have an automatic filter - only show posts from the
>last week by default, and let you expand your search if you want.

It would be better if it wouldn't be possible to react to post older
than a year. Or a least, show a warning in large unfriendly letters.
--
Jan van den Broek
***@xs4all.nl

Frisbeeterianism: n. The belief that when one dies, one's soul gets
stuck on the roof.
Niklas Karlsson
2020-08-26 13:17:20 UTC
Reply
Permalink
On 2020-08-26, Jan van den Broek <***@xs4all.nl> wrote:
> Tue, 11 Aug 2020 10:33:03 -0700
> Peter Flass <***@yahoo.com> schrieb:
>
> [Google hates Usenet-schnipp]
>
>>Google news needs to have an automatic filter - only show posts from the
>>last week by default, and let you expand your search if you want.
>
> It would be better if it wouldn't be possible to react to post older
> than a year. Or a least, show a warning in large unfriendly letters.

That would be a pretty nice feature for traditional newsreaders as well.
I mean, if you're new to a group, you get a whole bunch of posts, some
of them potentially pretty old. Maybe not as old as some of the thread
necrophilia cases we see coming from Google News, but still.

Niklas
--
"We are raised to honor all the wrong explorers and discoverers - thieves
planting flags, murderers carrying crosses. Let us at last praise the colonizers
of dreams."
-- Peter S. Beagle
Daniel
2020-08-27 16:58:59 UTC
Reply
Permalink
Niklas Karlsson <***@yahoo.se> writes:

> On 2020-08-26, Jan van den Broek <***@xs4all.nl> wrote:
>> Tue, 11 Aug 2020 10:33:03 -0700
>> Peter Flass <***@yahoo.com> schrieb:
>>
>> [Google hates Usenet-schnipp]
>>
>>>Google news needs to have an automatic filter - only show posts from the
>>>last week by default, and let you expand your search if you want.
>>
>> It would be better if it wouldn't be possible to react to post older
>> than a year. Or a least, show a warning in large unfriendly letters.
>
> That would be a pretty nice feature for traditional newsreaders as well.
> I mean, if you're new to a group, you get a whole bunch of posts, some
> of them potentially pretty old. Maybe not as old as some of the thread
> necrophilia cases we see coming from Google News, but still.
>
> Niklas

Back when I was using thunderbird for news, it would show me the oldest
first so... posts from 2003.

Glad I don't use that hog anymore.
--
Daniel
Visit me at: gopher://gcpp.world
Bud Spencer
2020-08-27 18:25:28 UTC
Reply
Permalink
On Thu, 27 Aug 2020, Daniel wrote:

> Back when I was using thunderbird for news, it would show me the oldest
> first so... posts from 2003.
>
> Glad I don't use that hog anymore.

I like to use Alpine and I just go through new posts and delete them as I
go ... Doesn't matter if they are in chronological order. And it's nice to
read them that way, well those that I do read. I think 90% of posts I just
skip.

/
Bud
/

a1=S0
b1=[1..2,'L0L']
a2=2*a1
a3=S1.4#b1
a4=(a2,a3)
a5=64*a4
Peter Flass
2020-08-27 23:40:20 UTC
Reply
Permalink
Daniel <***@sci.fidan.com> wrote:
> Niklas Karlsson <***@yahoo.se> writes:
>
>> On 2020-08-26, Jan van den Broek <***@xs4all.nl> wrote:
>>> Tue, 11 Aug 2020 10:33:03 -0700
>>> Peter Flass <***@yahoo.com> schrieb:
>>>
>>> [Google hates Usenet-schnipp]
>>>
>>>> Google news needs to have an automatic filter - only show posts from the
>>>> last week by default, and let you expand your search if you want.
>>>
>>> It would be better if it wouldn't be possible to react to post older
>>> than a year. Or a least, show a warning in large unfriendly letters.
>>
>> That would be a pretty nice feature for traditional newsreaders as well.
>> I mean, if you're new to a group, you get a whole bunch of posts, some
>> of them potentially pretty old. Maybe not as old as some of the thread
>> necrophilia cases we see coming from Google News, but still.
>>
>> Niklas
>
> Back when I was using thunderbird for news, it would show me the oldest
> first so... posts from 2003.

I think that’s an option, but I mostly use newstap on my iPad for news.
>
> Glad I don't use that hog anymore.



--
Pete
Andreas Kohlbach
2020-08-11 21:16:01 UTC
Reply
Permalink
On Tue, 11 Aug 2020 09:36:44 -0500, JimP wrote:
>
> On Mon, 10 Aug 2020 06:52:16 -0700 (PDT), ***@gmail.com
> wrote:
>>On Thursday, January 28, 2010 at 12:08:41 PM UTC-6, fadeToblack wrote:

[...]

> The OP was 10 years ago.

But didn't age a day. ;-)
--
Andreas
JimP
2020-08-11 21:50:09 UTC
Reply
Permalink
On Tue, 11 Aug 2020 17:16:01 -0400, Andreas Kohlbach
<***@spamfence.net> wrote:
>On Tue, 11 Aug 2020 09:36:44 -0500, JimP wrote:
>>
>> On Mon, 10 Aug 2020 06:52:16 -0700 (PDT), ***@gmail.com
>> wrote:
>>>On Thursday, January 28, 2010 at 12:08:41 PM UTC-6, fadeToblack wrote:
>
>[...]
>
>> The OP was 10 years ago.
>
>But didn't age a day. ;-)

True, but ya gotta pay attention.

That's what my grandpa always told me, to pay attention. I might miss
something.

--
Jim
Loading...