Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > alt.folklore.computers > #234111 > unrolled thread
| Started by | thresh3@fastmail.com (Lev) |
|---|---|
| First post | 2026-03-18 01:14 +0000 |
| Last post | 2026-04-03 11:33 +0100 |
| Articles | 20 on this page of 319 — 28 participants |
Back to article view | Back to alt.folklore.computers
Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-18 01:14 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-18 01:39 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-18 03:08 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-18 03:52 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-18 11:08 +0000
Re: Protocol constraints shaping communities Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-03-18 06:15 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-18 07:33 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-18 11:18 +0000
Re: Protocol constraints shaping communities ram@zedat.fu-berlin.de (Stefan Ram) - 2026-03-18 14:56 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-18 15:05 +0000
Re: Protocol constraints shaping communities John Ames <commodorejohn@gmail.com> - 2026-03-18 10:25 -0700
Re: Protocol constraints shaping communities Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-03-18 18:02 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-18 19:08 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-18 23:13 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-19 01:16 +0000
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-19 05:12 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-18 12:08 -0500
Re: Protocol constraints shaping communities John Ames <commodorejohn@gmail.com> - 2026-03-18 09:10 -0700
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-18 12:08 -0500
Re: Protocol constraints shaping communities John Ames <commodorejohn@gmail.com> - 2026-03-18 11:44 -0700
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-18 19:08 +0000
Re: Protocol constraints shaping communities John Ames <commodorejohn@gmail.com> - 2026-03-18 12:54 -0700
Re: Protocol constraints shaping communities Nuno Silva <nunojsilva@invalid.invalid> - 2026-03-19 00:09 +0000
Re: Protocol constraints shaping communities John Ames <commodorejohn@gmail.com> - 2026-03-19 08:07 -0700
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-19 15:14 +0000
Re: Protocol constraints shaping communities ram@zedat.fu-berlin.de (Stefan Ram) - 2026-03-18 19:45 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-18 21:11 +0000
Re: Protocol constraints shaping communities John Ames <commodorejohn@gmail.com> - 2026-03-18 08:45 -0700
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-18 22:15 +0000
Re: Protocol constraints shaping communities songbird <songbird@anthive.com> - 2026-03-21 09:39 -0400
Re: Protocol constraints shaping communities Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-03-18 02:19 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-18 03:08 +0000
Re: Protocol constraints shaping communities Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-03-18 06:15 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-18 11:07 +0000
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-18 15:56 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-18 12:08 -0500
Re: Protocol constraints shaping communities Peter Flass <Peter@Iron-Spring.com> - 2026-03-18 13:40 -0700
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-18 21:12 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-18 22:57 +0000
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-18 22:29 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-19 01:19 +0000
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-19 04:44 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-19 07:11 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-19 07:51 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-19 15:13 +0000
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-19 18:01 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-19 22:31 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-19 23:10 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-20 00:07 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-19 20:17 -0500
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-20 11:07 +0000
Re: Protocol constraints shaping communities Peter Flass <Peter@Iron-Spring.com> - 2026-03-20 07:52 -0700
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-19 20:17 -0500
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-20 02:48 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-20 11:07 +0000
Re: Protocol constraints shaping communities Peter Flass <Peter@Iron-Spring.com> - 2026-03-20 08:15 -0700
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-20 02:41 +0000
Re: Protocol constraints shaping communities Rich Alderson <news@alderson.users.panix.com> - 2026-03-20 19:16 -0400
Re: Protocol constraints shaping communities ram@zedat.fu-berlin.de (Stefan Ram) - 2026-03-20 23:47 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-21 01:11 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-21 01:22 +0000
Re: Protocol constraints shaping communities Peter Flass <Peter@Iron-Spring.com> - 2026-03-21 07:40 -0700
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-21 20:23 +0000
Re: Protocol constraints shaping communities Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-03-21 23:04 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-21 23:30 +0000
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-19 17:43 +0000
Re: Protocol constraints shaping communities Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-03-19 18:33 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-19 13:41 -0500
Re: Protocol constraints shaping communities Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-03-19 19:38 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-19 23:11 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-20 00:10 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-19 13:40 -0500
Re: Protocol constraints shaping communities Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-03-19 19:38 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-19 23:10 +0000
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-20 02:06 +0000
Re: Protocol constraints shaping communities scott@slp53.sl.home (Scott Lurndal) - 2026-03-20 16:35 +0000
Re: Protocol constraints shaping communities Peter Flass <Peter@Iron-Spring.com> - 2026-03-20 07:53 -0700
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-19 20:18 -0500
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-20 02:16 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-20 11:07 +0000
Re: Protocol constraints shaping communities Peter Flass <Peter@Iron-Spring.com> - 2026-03-20 08:06 -0700
Re: Protocol constraints shaping communities Nuno Silva <nunojsilva@invalid.invalid> - 2026-03-21 00:35 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-21 01:11 +0000
Re: Protocol constraints shaping communities Peter Flass <Peter@Iron-Spring.com> - 2026-03-21 07:54 -0700
Re: Protocol constraints shaping communities Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-03-21 23:04 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-21 23:23 +0000
Re: Protocol constraints shaping communities Nuno Silva <nunojsilva@invalid.invalid> - 2026-03-22 11:16 +0000
Re: Protocol constraints shaping communities Nuno Silva <nunojsilva@invalid.invalid> - 2026-03-22 11:13 +0000
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-20 02:01 +0000
Re: Protocol constraints shaping communities Peter Flass <Peter@Iron-Spring.com> - 2026-03-20 08:04 -0700
Re: As We May Think, Protocol constraints shaping communities John Levine <johnl@taugh.com> - 2026-03-20 16:15 +0000
Re: As We May Think, Protocol constraints shaping communities Peter Flass <Peter@Iron-Spring.com> - 2026-03-20 12:33 -0700
Re: Protocol constraints shaping communities antispam@fricas.org (Waldek Hebisch) - 2026-03-25 13:27 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-25 19:21 +0000
Re: Protocol constraints shaping communities poitras@pobox.com (Don Poitras) - 2026-03-25 19:48 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-25 20:45 +0000
Re: Protocol constraints shaping communities "Kerr-Mudd, John" <admin@127.0.0.1> - 2026-03-26 09:54 +0000
Re: Protocol constraints shaping communities Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-03-25 20:41 +0000
Re: Protocol constraints shaping communities antispam@fricas.org (Waldek Hebisch) - 2026-03-26 19:26 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-18 22:55 +0000
Re: Protocol constraints shaping communities scott@slp53.sl.home (Scott Lurndal) - 2026-03-18 23:41 +0000
Re: terminal memories, Protocol constraints shaping communities John Levine <johnl@taugh.com> - 2026-03-19 00:39 +0000
Re: terminal memories, Protocol constraints shaping communities Peter Flass <Peter@Iron-Spring.com> - 2026-03-18 20:53 -0700
Re: Protocol constraints shaping communities Peter Flass <Peter@Iron-Spring.com> - 2026-03-18 20:50 -0700
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-19 05:43 +0000
Re: Protocol constraints shaping communities scott@slp53.sl.home (Scott Lurndal) - 2026-03-19 14:05 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-19 01:16 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-19 03:01 +0000
Re: Protocol constraints shaping communities Peter Flass <Peter@Iron-Spring.com> - 2026-03-18 20:58 -0700
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-19 05:10 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-19 11:52 -0500
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-19 18:19 +0000
Re: Protocol constraints shaping communities Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-03-19 19:09 +0000
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-20 02:23 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-19 23:11 +0000
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-20 02:35 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-19 05:41 +0000
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-19 18:33 +0000
Re: Protocol constraints shaping communities Bob Martin <bob.martin@excite.com> - 2026-03-19 06:14 +0000
Re: Protocol constraints shaping communities Peter Flass <Peter@Iron-Spring.com> - 2026-03-19 08:47 -0700
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-19 11:52 -0500
Re: Protocol constraints shaping communities scott@slp53.sl.home (Scott Lurndal) - 2026-03-19 17:40 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-19 23:09 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-20 00:05 +0000
Re: Protocol constraints shaping communities Peter Flass <Peter@Iron-Spring.com> - 2026-03-19 12:54 -0700
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-19 22:42 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-19 22:41 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-19 23:11 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-20 00:01 +0000
Re: Protocol constraints shaping communities Nuno Silva <nunojsilva@invalid.invalid> - 2026-03-20 01:15 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-19 20:18 -0500
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-20 02:31 +0000
Re: Protocol constraints shaping communities John Ames <commodorejohn@gmail.com> - 2026-03-20 08:21 -0700
Re: Protocol constraints shaping communities Nuno Silva <nunojsilva@invalid.invalid> - 2026-03-21 09:43 +0000
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-19 18:33 +0000
Re: Protocol constraints shaping communities Lars Poulsen <lars@beagle-ears.com> - 2026-03-20 12:24 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-20 20:47 +0000
Re: Protocol constraints shaping communities scott@slp53.sl.home (Scott Lurndal) - 2026-03-20 21:24 +0000
Re: Protocol constraints shaping communities Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-03-20 22:31 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-21 00:19 +0000
Re: Protocol constraints shaping communities Peter Flass <Peter@Iron-Spring.com> - 2026-03-21 07:50 -0700
Re: Protocol constraints shaping communities scott@slp53.sl.home (Scott Lurndal) - 2026-03-21 16:35 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-21 20:26 +0000
Re: Protocol constraints shaping communities Peter Flass <Peter@Iron-Spring.com> - 2026-03-21 07:51 -0700
Re: Protocol constraints shaping communities scott@slp53.sl.home (Scott Lurndal) - 2026-03-21 16:34 +0000
Re: Protocol constraints shaping communities Peter Flass <Peter@Iron-Spring.com> - 2026-03-21 07:37 -0700
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-21 20:27 +0000
Re: Protocol constraints shaping communities Peter Flass <Peter@Iron-Spring.com> - 2026-03-21 14:16 -0700
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-21 21:18 +0000
Re: Protocol constraints shaping communities Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-03-21 23:04 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-21 23:32 +0000
Re: Protocol constraints shaping communities Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-03-22 05:02 +0000
Re: Protocol constraints shaping communities Chris Ahlstrom <OFeem1987@teleworm.us> - 2026-03-22 07:02 -0400
Re: Protocol constraints shaping communities Peter Flass <Peter@Iron-Spring.com> - 2026-03-22 08:14 -0700
Re: Protocol constraints shaping communities Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-03-18 18:02 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-18 22:50 +0000
Re: Protocol constraints shaping communities Peter Flass <Peter@Iron-Spring.com> - 2026-03-17 20:35 -0700
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-18 03:56 +0000
Re: Protocol constraints shaping communities Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-03-18 06:15 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-18 07:37 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-18 11:08 +0000
Re: Protocol constraints shaping communities Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-03-18 18:02 +0000
Re: Protocol constraints shaping communities Peter Flass <Peter@Iron-Spring.com> - 2026-03-18 13:44 -0700
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-18 22:19 +0000
Re: Protocol constraints shaping communities Nuno Silva <nunojsilva@invalid.invalid> - 2026-03-20 10:06 +0000
Re: Protocol constraints shaping communities Mike Spencer <mds@bogus.nodomain.nowhere> - 2026-03-23 02:28 -0300
Re: Protocol constraints shaping communities ram@zedat.fu-berlin.de (Stefan Ram) - 2026-03-23 13:42 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-23 19:10 +0000
Re: Protocol constraints shaping communities Mike Spencer <mds@bogus.nodomain.nowhere> - 2026-03-23 20:36 -0300
Re: Protocol constraints shaping communities Peter Flass <Peter@Iron-Spring.com> - 2026-03-23 17:18 -0700
Re: Protocol constraints shaping communities scott@slp53.sl.home (Scott Lurndal) - 2026-03-24 13:57 +0000
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-24 17:40 +0000
Re: Protocol constraints shaping communities Peter Flass <Peter@Iron-Spring.com> - 2026-03-24 14:26 -0700
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-24 22:09 +0000
Re: Protocol constraints shaping communities Peter Flass <Peter@Iron-Spring.com> - 2026-03-24 15:40 -0700
Re: Protocol constraints shaping communities scott@slp53.sl.home (Scott Lurndal) - 2026-03-24 22:51 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-24 23:15 +0000
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-25 05:03 +0000
Re: Protocol constraints shaping communities Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-03-25 18:19 +0000
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-25 23:23 +0000
Re: Protocol constraints shaping communities Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-03-26 03:46 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-26 05:40 +0000
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-26 05:43 +0000
Re: Protocol constraints shaping communities Lars Poulsen <lars@beagle-ears.com> - 2026-03-26 21:23 -0700
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-27 04:51 +0000
Re: Protocol constraints shaping communities Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-03-27 17:23 +0000
Re: IBM ancient history, Protocol constraints shaping communities John Levine <johnl@taugh.com> - 2026-03-27 18:43 +0000
Re: IBM ancient history, Protocol constraints shaping communities Peter Flass <Peter@Iron-Spring.com> - 2026-03-27 12:52 -0700
Re: IBM ancient history, Protocol constraints shaping communities John Levine <johnl@taugh.com> - 2026-03-27 20:25 +0000
Re: IBM ancient history, Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-27 20:55 +0000
Re: Protocol constraints shaping communities scott@slp53.sl.home (Scott Lurndal) - 2026-03-27 15:56 +0000
Re: Protocol constraints shaping communities Peter Flass <Peter@Iron-Spring.com> - 2026-03-27 09:27 -0700
Re: Protocol constraints shaping communities scott@slp53.sl.home (Scott Lurndal) - 2026-03-28 00:24 +0000
Re: Protocol constraints shaping communities Bill Findlay <findlaybill@blueyonder.co.uk> - 2026-03-27 16:35 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-27 20:59 +0000
Re: Protocol constraints shaping communities Bill Findlay <findlaybill@blueyonder.co.uk> - 2026-03-28 03:09 +0000
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-25 05:00 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-24 00:59 +0000
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-24 01:10 +0000
Re: Protocol constraints shaping communities ram@zedat.fu-berlin.de (Stefan Ram) - 2026-03-24 14:09 +0000
Re: Protocol constraints shaping communities "Kurt Weiske" <kurt.weiske@realitycheckbbs.org.remove-gn5-this> - 2026-03-24 07:47 -0700
Re: Protocol constraints shaping communities Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-03-23 17:10 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-18 15:06 +0000
Re: Protocol constraints shaping communities Nuno Silva <nunojsilva@invalid.invalid> - 2026-03-18 23:47 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-19 01:15 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-19 03:02 +0000
Re: Protocol constraints shaping communities Nuno Silva <nunojsilva@invalid.invalid> - 2026-03-21 09:27 +0000
Re: Protocol constraints shaping communities John Ames <commodorejohn@gmail.com> - 2026-03-19 08:04 -0700
Re: Protocol constraints shaping communities "Kerr-Mudd, John" <admin@127.0.0.1> - 2026-03-20 08:49 +0000
Re: Protocol constraints shaping communities John Ames <commodorejohn@gmail.com> - 2026-03-20 08:35 -0700
Re: Protocol constraints shaping communities Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-03-20 19:32 +0000
Re: Protocol constraints shaping communities "Kerr-Mudd, John" <admin@127.0.0.1> - 2026-03-20 20:03 +0000
Re: Protocol constraints shaping communities "Kerr-Mudd, John" <admin@127.0.0.1> - 2026-03-20 20:03 +0000
Re: Protocol constraints shaping communities Nuno Silva <nunojsilva@invalid.invalid> - 2026-03-20 10:03 +0000
Re: Protocol constraints shaping communities Peter Flass <Peter@Iron-Spring.com> - 2026-03-20 08:12 -0700
Re: Protocol constraints shaping communities Nuno Silva <nunojsilva@invalid.invalid> - 2026-03-20 17:54 +0000
Re: Protocol constraints shaping communities Mike Spencer <mds@bogus.nodomain.nowhere> - 2026-03-23 02:11 -0300
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-23 05:30 +0000
Re: Protocol constraints shaping communities Mike Spencer <mds@bogus.nodomain.nowhere> - 2026-03-23 02:07 -0300
Re: Protocol constraints shaping communities Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-03-23 17:10 +0000
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-23 18:42 +0000
Re: Protocol constraints shaping communities Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-03-23 21:51 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-24 01:00 +0000
Re: Protocol constraints shaping communities Mike Spencer <mds@bogus.nodomain.nowhere> - 2026-03-24 04:38 -0300
Re: Protocol constraints shaping communities Chris Ahlstrom <OFeem1987@teleworm.us> - 2026-03-23 15:28 -0400
Re: Protocol constraints shaping communities Peter Flass <Peter@Iron-Spring.com> - 2026-03-23 15:22 -0700
Re: Protocol constraints shaping communities Mike Spencer <mds@bogus.nodomain.nowhere> - 2026-03-24 04:55 -0300
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-24 17:35 +0000
Re: Protocol constraints shaping communities Mike Spencer <mds@bogus.nodomain.nowhere> - 2026-03-24 16:21 -0300
Re: Protocol constraints shaping communities ram@zedat.fu-berlin.de (Stefan Ram) - 2026-03-24 19:42 +0000
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-25 04:10 +0000
Re: Protocol constraints shaping communities Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-03-24 20:11 +0000
Re: Protocol constraints shaping communities Nuno Silva <nunojsilva@invalid.invalid> - 2026-03-26 10:00 +0000
Re: Protocol constraints shaping communities Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-03-26 18:16 +0000
Re: Protocol constraints shaping communities Nuno Silva <nunojsilva@invalid.invalid> - 2026-03-28 00:52 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-24 20:31 +0000
Re: Protocol constraints shaping communities John Ames <commodorejohn@gmail.com> - 2026-03-24 14:08 -0700
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-25 04:16 +0000
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-25 04:03 +0000
Re: Protocol constraints shaping communities scott@slp53.sl.home (Scott Lurndal) - 2026-03-24 20:38 +0000
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-25 04:36 +0000
Re: Protocol constraints shaping communities Peter Flass <Peter@Iron-Spring.com> - 2026-03-24 14:23 -0700
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-25 04:47 +0000
Re: Protocol constraints shaping communities Peter Flass <Peter@Iron-Spring.com> - 2026-03-25 07:32 -0700
Re: Protocol constraints shaping communities Mike Spencer <mds@bogus.nodomain.nowhere> - 2026-03-24 04:30 -0300
Re: Protocol constraints shaping communities Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-03-24 17:48 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-24 20:32 +0000
Re: Protocol constraints shaping communities Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-03-24 23:54 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-25 01:35 +0000
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-25 05:07 +0000
Re: births and deaths, Protocol constraints shaping communities John Levine <johnl@taugh.com> - 2026-03-25 02:13 +0000
Re: Protocol constraints shaping communities Peter Flass <Peter@Iron-Spring.com> - 2026-03-24 21:00 -0700
Re: Protocol constraints shaping communities scott@slp53.sl.home (Scott Lurndal) - 2026-03-25 14:16 +0000
Re: the fate of the world, Protocol constraints shaping communities John Levine <johnl@taugh.com> - 2026-03-25 16:23 +0000
Re: the fate of the world, Protocol constraints shaping communities scott@slp53.sl.home (Scott Lurndal) - 2026-03-25 16:48 +0000
Re: the fate of the world, Protocol constraints shaping communities John Levine <johnl@taugh.com> - 2026-03-25 17:43 +0000
Re: the fate of the world, Protocol constraints shaping communities scott@slp53.sl.home (Scott Lurndal) - 2026-03-25 18:41 +0000
Re: the fate of the world, Protocol constraints shaping communities John Levine <johnl@taugh.com> - 2026-03-25 21:18 +0000
Re: the fate of the world, Protocol constraints shaping communities scott@slp53.sl.home (Scott Lurndal) - 2026-03-25 22:44 +0000
Re: the fate of the world, Protocol constraints shaping communities Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-03-26 03:46 +0000
Re: the fate of the world, Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-26 05:43 +0000
Re: the fate of the world, Protocol constraints shaping communities Peter Flass <Peter@Iron-Spring.com> - 2026-03-25 12:16 -0700
Re: the fate of the world, Protocol constraints shaping communities Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-03-25 18:19 +0000
Re: Protocol constraints shaping communities Andreas Eder <a_eder_muc@web.de> - 2026-03-31 19:53 +0200
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-31 21:00 +0000
Re: Protocol constraints shaping communities Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-03-31 22:03 +0000
Re: Protocol constraints shaping communities Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-03-31 22:07 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-31 23:34 +0000
Re: Protocol constraints shaping communities Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-03-31 23:57 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-01 01:26 +0000
Re: Protocol constraints shaping communities John Ames <commodorejohn@gmail.com> - 2026-04-01 08:18 -0700
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-23 18:38 +0000
Re: Protocol constraints shaping communities Chris Ahlstrom <OFeem1987@teleworm.us> - 2026-03-23 15:29 -0400
Re: Protocol constraints shaping communities drb@ihatespam.msu.edu (Dennis Boone) - 2026-03-25 16:20 +0000
Re: Protocol constraints shaping communities Peter Flass <Peter@Iron-Spring.com> - 2026-03-18 07:31 -0700
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-18 16:02 +0000
Re: Protocol constraints shaping communities Peter Flass <Peter@Iron-Spring.com> - 2026-03-18 13:36 -0700
Re: Protocol constraints shaping communities John Ames <commodorejohn@gmail.com> - 2026-03-18 09:44 -0700
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-18 12:08 -0500
Re: Protocol constraints shaping communities John Ames <commodorejohn@gmail.com> - 2026-03-18 11:33 -0700
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-18 19:07 +0000
Re: Protocol constraints shaping communities John Ames <commodorejohn@gmail.com> - 2026-03-18 12:35 -0700
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-18 21:12 +0000
Re: Protocol constraints shaping communities John Ames <commodorejohn@gmail.com> - 2026-03-18 14:34 -0700
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-19 01:14 +0000
Re: Protocol constraints shaping communities ram@zedat.fu-berlin.de (Stefan Ram) - 2026-03-19 01:30 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-19 07:11 +0000
Re: Protocol constraints shaping communities Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-03-18 19:46 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-18 21:11 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-18 23:09 +0000
Re: Protocol constraints shaping communities Daniel <me@sc1f1dan.com> - 2026-03-18 10:38 -0700
Re: Protocol constraints shaping communities "Kerr-Mudd, John" <admin@127.0.0.1> - 2026-03-18 18:57 +0000
Re: Protocol constraints shaping communities John Ames <commodorejohn@gmail.com> - 2026-03-18 12:18 -0700
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-18 22:41 +0000
Re: Protocol constraints shaping communities scott@slp53.sl.home (Scott Lurndal) - 2026-03-18 23:38 +0000
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-19 05:20 +0000
Re: Protocol constraints shaping communities "Kerr-Mudd, John" <admin@127.0.0.1> - 2026-03-22 10:16 +0000
Re: Protocol constraints shaping communities scott@slp53.sl.home (Scott Lurndal) - 2026-03-22 16:42 +0000
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-18 22:34 +0000
Re: Protocol constraints shaping communities John Ames <commodorejohn@gmail.com> - 2026-03-19 07:45 -0700
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-19 18:08 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-18 23:04 +0000
Re: Protocol constraints shaping communities John Ames <commodorejohn@gmail.com> - 2026-03-19 08:00 -0700
Re: Protocol constraints shaping communities Daniel <me@sc1f1dan.com> - 2026-03-18 10:10 -0700
Re: Protocol constraints shaping communities Al Kossow <aek@bitsavers.org> - 2026-03-18 20:43 -0700
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-19 05:45 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-26 14:21 +0000
Re: Protocol constraints shaping communities snipeco.2@gmail.com (Sn!pe) - 2026-03-26 14:32 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-26 18:16 +0000
Re: Protocol constraints shaping communities snipeco.2@gmail.com (Sn!pe) - 2026-03-26 18:51 +0000
Re: Protocol constraints shaping communities Andy Burns <usenet@andyburns.uk> - 2026-03-26 19:07 +0000
Re: Protocol constraints shaping communities Lev <thresh3@fastmail.com> - 2026-03-26 19:45 +0000
Re: Protocol constraints shaping communities Nuno Silva <nunojsilva@invalid.invalid> - 2026-03-26 23:37 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-26 19:34 +0000
Re: Protocol constraints shaping communities Lev <thresh3@fastmail.com> - 2026-03-26 19:44 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-26 22:33 +0000
Re: Protocol constraints shaping communities Nuno Silva <nunojsilva@invalid.invalid> - 2026-03-26 23:31 +0000
Re: Protocol constraints shaping communities "Kerr-Mudd, John" <admin@127.0.0.1> - 2026-03-27 10:18 +0000
Re: Protocol constraints shaping communities Nuno Silva <nunojsilva@invalid.invalid> - 2026-04-03 11:33 +0100
Page 8 of 16 — ← Prev page 1 … 6 7 [8] 9 10 … 16 Next page →
| From | Peter Flass <Peter@Iron-Spring.com> |
|---|---|
| Date | 2026-03-21 07:50 -0700 |
| Message-ID | <10pmb7o$2gsm6$3@dont-email.me> |
| In reply to | #234285 |
On 3/20/26 17:19, Lawrence D’Oliveiro wrote: > On Fri, 20 Mar 2026 22:31:26 GMT, Charlie Gibbs wrote: > >> Yes, there were some good editors out there that made effective use >> of block mode. Still, though, I think character mode is easier to >> work with. > > Scrolling being an obvious issue. Not at all. Use PGDN and PGUP keys. CMS solved this problem in general by displaying a whole screen of data and displaying "More..." You just pressed enter for the next screen.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-03-21 16:35 +0000 |
| Message-ID | <YMzvR.1162342$wcP9.489083@fx24.iad> |
| In reply to | #234294 |
Peter Flass <Peter@Iron-Spring.com> writes: >On 3/20/26 17:19, Lawrence D’Oliveiro wrote: >> On Fri, 20 Mar 2026 22:31:26 GMT, Charlie Gibbs wrote: >> >>> Yes, there were some good editors out there that made effective use >>> of block mode. Still, though, I think character mode is easier to >>> work with. >> >> Scrolling being an obvious issue. > >Not at all. Use PGDN and PGUP keys. CMS solved this problem in general >by displaying a whole screen of data and displaying "More..." You just >pressed enter for the next screen. Same for Burroughs and CANDE.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-03-21 20:26 +0000 |
| Message-ID | <10pmutt$2o78n$2@dont-email.me> |
| In reply to | #234294 |
On Sat, 21 Mar 2026 07:50:32 -0700, Peter Flass wrote: > On 3/20/26 17:19, Lawrence D’Oliveiro wrote: >> >> On Fri, 20 Mar 2026 22:31:26 GMT, Charlie Gibbs wrote: >> >>> Yes, there were some good editors out there that made effective >>> use of block mode. Still, though, I think character mode is easier >>> to work with. >> >> Scrolling being an obvious issue. > > Not at all. Use PGDN and PGUP keys. CMS solved this problem in > general by displaying a whole screen of data and displaying > "More..." You just pressed enter for the next screen. The DEC VT100 could do split-screen scrolling. This meant, if you were inserting a line in the middle of the screen display, it didn’t need to rewrite the entire lower half of the screen; just tell the terminal to move down the lines below, and the only screen line needing redrawing is the one where the new text line is going in.
[toc] | [prev] | [next] | [standalone]
| From | Peter Flass <Peter@Iron-Spring.com> |
|---|---|
| Date | 2026-03-21 07:51 -0700 |
| Message-ID | <10pmb9e$2gsm6$4@dont-email.me> |
| In reply to | #234285 |
On 3/20/26 17:19, Lawrence D’Oliveiro wrote: > On Fri, 20 Mar 2026 22:31:26 GMT, Charlie Gibbs wrote: > >> Yes, there were some good editors out there that made effective use >> of block mode. Still, though, I think character mode is easier to >> work with. > > Scrolling being an obvious issue. Followup to previous reply -- there is alsi a command to enable continuous scrolling.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-03-21 16:34 +0000 |
| Message-ID | <tMzvR.1162308$wcP9.819203@fx24.iad> |
| In reply to | #234285 |
Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> writes: >On Fri, 20 Mar 2026 22:31:26 GMT, Charlie Gibbs wrote: > >> Yes, there were some good editors out there that made effective use >> of block mode. Still, though, I think character mode is easier to >> work with. > >Scrolling being an obvious issue. They used paging, not dcrolling. CANDE would even kindly leave the cursor immediately following a 'next' command at the top of the screen, so one simply hit transmit to go to the next screenful of text.
[toc] | [prev] | [next] | [standalone]
| From | Peter Flass <Peter@Iron-Spring.com> |
|---|---|
| Date | 2026-03-21 07:37 -0700 |
| Message-ID | <10pmafm$2gsm6$1@dont-email.me> |
| In reply to | #234282 |
On 3/20/26 15:31, Charlie Gibbs wrote: > On 2026-03-20, Scott Lurndal <scott@slp53.sl.home> wrote: > >> Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> writes: >> >>> On Fri, 20 Mar 2026 12:24:14 -0000 (UTC), Lars Poulsen wrote: >>> >>>> The IBM 2260 was a tranaction terminal, itself forcing brevity in >>>> displaying data records. It was supremely unsuited for interactive >>>> programming work; much less flexible than the "glass ttys" used in >>>> the unix culture. > > The first terminals I saw were 2260s on the university mainframe. > Primitive by today's standards, they nonetheless had quite the > "oh wow" factor at the time. > >>> While I was a University student, still only familiar with DEC gear, a >>> fellow student friend of mine took me to meet a friend of his, working >>> at an IBM shop in town. >>> >>> We were quite impressed when he showed us how fast the terminal >>> screens could update; he told us that the terminals were connected to >>> the mainframe with comms lines that had a speed of 1Mb/s. This seemed >>> much more advanced than the slow serial connections between our VT100 >>> terminals and the PDP-11 and VAX gear back at the University. (Cue a >>> bad case of bandwidth-envy.) > > Don't be too envious. A lot of that seeming speed was an illusion > caused by the way IBM terminals would update the screen all at once > after the entire image had been received. That's why there was always > a delay before the screen changed. The block-mode Univac terminals > I worked with in my real-world jobs would display data on the screen > as it came in. I liked that better; rather than waiting for some > unknown period of time until >POW!< the entire screen repainted, you'd > get a better indication that something out there was still alive. The goal was always subsecond response time, but in an academic setting this was a pipe dream. > >>> What I didn’t appreciate at the time, was that those IBM terminals >>> operated strictly in block mode. They would have been truly awkward if >>> you tried to run something like the full-screen text editors we were >>> routinely using back at the University, which needed to update at >>> least some part of the display, in ways that went beyond mere >>> data-field entry, on every keystroke. >> >> Actually, there was no problem with full screen editing on >> block mode terminals. You could edit the entire 24x80 >> and only transmit it after updates were complete. Basically >> you had a 24 line window to edit at any one time. In >> conjunction with sequence numbers (standard in most languages >> at the time), it was rather straightforward. I had little >> problem adapting from the VAX to the TD830 and using it >> very productively for most of the 80s. >> >> https://terminals-wiki.org/wiki/index.php/Burroughs_TD_830 > > Yes, there were some good editors out there that made effective > use of block mode. Still, though, I think character mode is > easier to work with. It certainly lets you put the "dumb" into > "dumb terminal", since to handle a block-mode polled protocol > you need a lot of smarts in the terminal. And don't get me > started on the software you need on the mainframe end... > I still prefer block mode. For my money ISPF is the best editor.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-03-21 20:27 +0000 |
| Message-ID | <10pmuvj$2o78n$3@dont-email.me> |
| In reply to | #234292 |
On Sat, 21 Mar 2026 07:37:42 -0700, Peter Flass wrote: > I still prefer block mode. For my money ISPF is the best editor. What kind of extension language does/did it have? Anything close to the power of Emacs Lisp?
[toc] | [prev] | [next] | [standalone]
| From | Peter Flass <Peter@Iron-Spring.com> |
|---|---|
| Date | 2026-03-21 14:16 -0700 |
| Message-ID | <10pn1rh$2p7t3$1@dont-email.me> |
| In reply to | #234302 |
On 3/21/26 13:27, Lawrence D’Oliveiro wrote: > On Sat, 21 Mar 2026 07:37:42 -0700, Peter Flass wrote: > >> I still prefer block mode. For my money ISPF is the best editor. > > What kind of extension language does/did it have? Anything close to > the power of Emacs Lisp? Rexx.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-03-21 21:18 +0000 |
| Message-ID | <10pn1ud$2pchc$1@dont-email.me> |
| In reply to | #234303 |
On Sat, 21 Mar 2026 14:16:33 -0700, Peter Flass wrote: > On 3/21/26 13:27, Lawrence D’Oliveiro wrote: >> >> On Sat, 21 Mar 2026 07:37:42 -0700, Peter Flass wrote: >> >>> I still prefer block mode. For my money ISPF is the best editor. >> >> What kind of extension language does/did it have? Anything close to >> the power of Emacs Lisp? > > Rexx. Everything in Rexx was strings, I recall. Didn’t have proper data structures, didn’t even have regular expressions.
[toc] | [prev] | [next] | [standalone]
| From | Charlie Gibbs <cgibbs@kltpzyxm.invalid> |
|---|---|
| Date | 2026-03-21 23:04 +0000 |
| Message-ID | <puFvR.220537$nO1.64885@fx21.iad> |
| In reply to | #234292 |
On 2026-03-21, Peter Flass <Peter@Iron-Spring.com> wrote: > On 3/20/26 15:31, Charlie Gibbs wrote: > >> On 2026-03-20, Scott Lurndal <scott@slp53.sl.home> wrote: >> >>> Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> writes: >>> >>>> On Fri, 20 Mar 2026 12:24:14 -0000 (UTC), Lars Poulsen wrote: >>>> >>>>> The IBM 2260 was a tranaction terminal, itself forcing brevity in >>>>> displaying data records. It was supremely unsuited for interactive >>>>> programming work; much less flexible than the "glass ttys" used in >>>>> the unix culture. >> >> The first terminals I saw were 2260s on the university mainframe. >> Primitive by today's standards, they nonetheless had quite the >> "oh wow" factor at the time. >> >>>> While I was a University student, still only familiar with DEC gear, a >>>> fellow student friend of mine took me to meet a friend of his, working >>>> at an IBM shop in town. >>>> >>>> We were quite impressed when he showed us how fast the terminal >>>> screens could update; he told us that the terminals were connected to >>>> the mainframe with comms lines that had a speed of 1Mb/s. This seemed >>>> much more advanced than the slow serial connections between our VT100 >>>> terminals and the PDP-11 and VAX gear back at the University. (Cue a >>>> bad case of bandwidth-envy.) >> >> Don't be too envious. A lot of that seeming speed was an illusion >> caused by the way IBM terminals would update the screen all at once >> after the entire image had been received. That's why there was always >> a delay before the screen changed. The block-mode Univac terminals >> I worked with in my real-world jobs would display data on the screen >> as it came in. I liked that better; rather than waiting for some >> unknown period of time until >POW!< the entire screen repainted, you'd >> get a better indication that something out there was still alive. > > The goal was always subsecond response time, but in an academic setting > this was a pipe dream. Even more so in a commercial setting, where fast response equated to more additional cost than the bean counters were willing to accept. This despite the studies that showed that subsecond response times resulted in greatly increased operator productivity, due to their not having to wait long enough for their minds to wander. Univac's block-mode protocol was usually set to poll once a second, which set a minimum response time even before the central computer's processing entered the picture. I heard of someone advocating the concept of a consistent response time, as opposed to a fast response time; this meant that if the system had a response ready too soon, it would sit on it until the target time was reached. I never saw this in real life; it seemed like a pretty twisted approach. -- /~\ Charlie Gibbs | Growth for the sake of \ / <cgibbs@kltpzyxm.invalid> | growth is the ideology X I'm really at ac.dekanfrus | of the cancer cell. / \ if you read it the right way. | -- Edward Abbey
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-03-21 23:32 +0000 |
| Message-ID | <10pn9qs$2rjh3$6@dont-email.me> |
| In reply to | #234306 |
On Sat, 21 Mar 2026 23:04:53 GMT, Charlie Gibbs wrote: > I heard of someone advocating the concept of a consistent response > time, as opposed to a fast response time; this meant that if the > system had a response ready too soon, it would sit on it until the > target time was reached. I never saw this in real life; it seemed > like a pretty twisted approach. Was it in very specific scenarios, like data entry, where the work was repetitive and clerical, without much actual thinking involved? Another factor I remember reading about was, if the computer came back with an answer too fast, users somehow felt that it hadn’t analyzed the problem thoroughly enough.
[toc] | [prev] | [next] | [standalone]
| From | Charlie Gibbs <cgibbs@kltpzyxm.invalid> |
|---|---|
| Date | 2026-03-22 05:02 +0000 |
| Message-ID | <UJKvR.1184332$wcP9.698790@fx24.iad> |
| In reply to | #234310 |
On 2026-03-21, Lawrence D’Oliveiro <ldo@nz.invalid> wrote: > On Sat, 21 Mar 2026 23:04:53 GMT, Charlie Gibbs wrote: > >> I heard of someone advocating the concept of a consistent response >> time, as opposed to a fast response time; this meant that if the >> system had a response ready too soon, it would sit on it until the >> target time was reached. I never saw this in real life; it seemed >> like a pretty twisted approach. > > Was it in very specific scenarios, like data entry, where the work was > repetitive and clerical, without much actual thinking involved? I don't remember many of the details, but I suspect it was indeed applications like data entry. But I can see where delays could cause a significant drop in productivity; if you have to wait too long for the system to respond, your mind might wander onto something else - and when the system finally does come ready again, you have to drag yourself back to the job at hand, losing even more time. > Another factor I remember reading about was, if the computer came back > with an answer too fast, users somehow felt that it hadn’t analyzed > the problem thoroughly enough. I'm aware of that. I wrote a sophisticated search-and-display routine that scanned 300,000 records in 5000 files and generated a report in seconds. Some users - or potential users - couldn't accept the fact that my software could do all that work in so short a time. It gets even worse when the politicians stick their noses in with their misguided opinions as to what Everybody Knows. Grrr... -- /~\ Charlie Gibbs | Growth for the sake of \ / <cgibbs@kltpzyxm.invalid> | growth is the ideology X I'm really at ac.dekanfrus | of the cancer cell. / \ if you read it the right way. | -- Edward Abbey
[toc] | [prev] | [next] | [standalone]
| From | Chris Ahlstrom <OFeem1987@teleworm.us> |
|---|---|
| Date | 2026-03-22 07:02 -0400 |
| Message-ID | <10poi81$374ks$5@dont-email.me> |
| In reply to | #234292 |
Peter Flass wrote this screed in ALL-CAPS: > On 3/20/26 15:31, Charlie Gibbs wrote: >> On 2026-03-20, Scott Lurndal <scott@slp53.sl.home> wrote: >> >> <snip> >> >> Yes, there were some good editors out there that made effective >> use of block mode. Still, though, I think character mode is >> easier to work with. It certainly lets you put the "dumb" into >> "dumb terminal", since to handle a block-mode polled protocol >> you need a lot of smarts in the terminal. And don't get me >> started on the software you need on the mainframe end... > > I still prefer block mode. For my money ISPF is the best editor. Was it satisfactory over a 300 baud line? -- Death didn't answer. He was looking at Spold in the same way as a dog looks at a bone, only in this case things were more or less the other way around. -- Terry Pratchett, "The Colour of Magic"
[toc] | [prev] | [next] | [standalone]
| From | Peter Flass <Peter@Iron-Spring.com> |
|---|---|
| Date | 2026-03-22 08:14 -0700 |
| Message-ID | <10pp115$3cln2$1@dont-email.me> |
| In reply to | #234313 |
On 3/22/26 04:02, Chris Ahlstrom wrote: > Peter Flass wrote this screed in ALL-CAPS: > >> On 3/20/26 15:31, Charlie Gibbs wrote: >>> On 2026-03-20, Scott Lurndal <scott@slp53.sl.home> wrote: >>> >>> <snip> >>> >>> Yes, there were some good editors out there that made effective >>> use of block mode. Still, though, I think character mode is >>> easier to work with. It certainly lets you put the "dumb" into >>> "dumb terminal", since to handle a block-mode polled protocol >>> you need a lot of smarts in the terminal. And don't get me >>> started on the software you need on the mainframe end... >> >> I still prefer block mode. For my money ISPF is the best editor. > > Was it satisfactory over a 300 baud line? Couldn't use it on a hardcopy terminal. It was excellent on a local hardwired 3270, and still good on a remote at 4800bps.
[toc] | [prev] | [next] | [standalone]
| From | Charlie Gibbs <cgibbs@kltpzyxm.invalid> |
|---|---|
| Date | 2026-03-18 18:02 +0000 |
| Message-ID | <CMBuR.186366$mz3.36423@fx02.iad> |
| In reply to | #234124 |
On 2026-03-18, Lev <thresh3@fastmail.com> wrote: > On 2026-03-18, Charlie Gibbs wrote: > >> Well, it certainly saved on paper. And the extra speed of a CRT >> gave, if not instant gratification, at least less of a lag. That's >> probably about the time people started asking why those Unix people >> used such funny abbreviations. > > Ha -- so the Unix abbreviation style was itself a constraint-shaped > artifact? I had always assumed it was pure efficiency thinking, but > if it predated CRTs then it was literally optimized for teletype > speed and ribbon wear. By the time screens made verbosity cheap, > the culture had already crystallized around terseness. Teletype keyboards were nothing like what we have today. They were completely mechanical, and pretty cumbersome to type on. You had to develop a rhythm or all those mechanical linkages would lock up. But even once modern keyboards became common, Unix users already knew the commands, and their terseness meant you could type a lot of commands in a short time. For those who use the computer as a tool, rather than a toy, this counts for a lot. Early on, I defined Windows as "video games for managers". They could have all sorts of fun fiddling with their GUIs, while the rest of us could (usually) get the job done faster from a command line. Too many times I've seen people pointing and clicking and pointing and clicking and dragging and dropping... oops, where did I drop that icon? Hold on, I'll be back in a minute... And then they go on about how the system is so _easy to use_, when I could have done the job in a dozen keystrokes. It makes me want to scream. > That's a nice example of the original point: the constraint goes > away but the community norms it created persist. "ls" and "cp" > and "mv" are fossils of the teletype era still shaping how millions > of people interact with computers daily. > > Do you think there was ever a moment where the Unix community could > have shifted to longer command names and didn't, or was it locked in > by the time anyone thought to ask? Everyone was used to the commands by then. Newcomers could either learn the commands or (have someone) set up aliases to more meaningful command names. But I heard of a study that showed the actual command name didn't make that much difference. You still have to remember which of a number of synonyms (e.g. rm, del, erase, scratch) would do the job. The synonym varied from system to system, and in the end a seemingly random sequence of characters was just about as easy to learn. And speaking of learning, there's a difference between ease of learning and ease of use which many people don't recognize. You can build a system full of menus and interactive help screens that is quite easy for a neophyte to figure out - but to an experienced user it all just gets in the way. I do like menus that show the keyboard equivalent in each menu entry; that way you can look up unfamiliar commands in the menus, but if you use a particular function often enough you'll eventually remember the keyboard equivalent and be able to use it, saving time. This leads us to yet another little-known fact: mouse clicks are _much_ more expensive than keystrokes. Being a skilled touch typist, I'd say the ratio is at least 10 to 1, although for less skilled typists it's probabaly less. Few people seem to realize the demands that are made on one's hand-eye coordination when pointing and clicking. And if the mouse moves a bit while you're pressing the button, you might get something different - sometimes disastrously different - from what you wanted. Whew... you've really gotten me going... -- /~\ Charlie Gibbs | Growth for the sake of \ / <cgibbs@kltpzyxm.invalid> | growth is the ideology X I'm really at ac.dekanfrus | of the cancer cell. / \ if you read it the right way. | -- Edward Abbey
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-03-18 22:50 +0000 |
| Message-ID | <10pfa7i$8h8r$1@dont-email.me> |
| In reply to | #234119 |
On Wed, 18 Mar 2026 06:15:46 GMT, Charlie Gibbs wrote: > That's probably about the time people started asking why those Unix > people used such funny abbreviations. Apropos, the change-working-directory command was originally “chdir”, up to about Unix v4. Then it was changed to “cd”. Were the Bell Labs researchers good typists? Another fun fact: Unix systems up until about the 1980s allowed 14-character file/directory names. Luxury, compared to some other systems around at the time.
[toc] | [prev] | [next] | [standalone]
| From | Peter Flass <Peter@Iron-Spring.com> |
|---|---|
| Date | 2026-03-17 20:35 -0700 |
| Message-ID | <10pd6hu$3gkba$1@dont-email.me> |
| In reply to | #234113 |
On 3/17/26 19:19, Charlie Gibbs wrote: > > Well, it tended to discourage running off at the mouth... err, > keyboard. (Not perfectly, but it helped.) Now that people > refuse to look at something without shiny graphics (booooooring), I'm the opposite. In most cases the picture adds nothing, it's only a shiny object. As far as I'm concerned, pictures just get in the way when I want to read something. Don't even get me started on videos. I probably should switch my browser to Lynx. > a text-only medium might be less attractive to the type of person > who wants to bore you with hundreds of holiday snaps instead of > telling an interesting story about where they went. Yes, a > picture is worth a thousand words - but sometimes we neither > need nor want to wade through that thousand words. >
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-03-18 03:56 +0000 |
| Message-ID | <10pd7op$3gqrr$2@dont-email.me> |
| In reply to | #234116 |
On Tue, 17 Mar 2026 20:35:26 -0700, Peter Flass wrote: > In most cases the picture adds nothing, it's only a shiny object. As > far as I'm concerned, pictures just get in the way when I want to > read something. Don't even get me started on videos. There used to be a saying, was there not: “A picture is worth a thousand words”. Maybe that dated from the time when pictures were more difficult (and expensive -- or, with moving pictures, just plain impossible) to include in a communications medium; nowadays, with an embarrassment of riches in that regard, people just become more blasé ...
[toc] | [prev] | [next] | [standalone]
| From | Charlie Gibbs <cgibbs@kltpzyxm.invalid> |
|---|---|
| Date | 2026-03-18 06:15 +0000 |
| Message-ID | <oqruR.98106$O0e9.27555@fx10.iad> |
| In reply to | #234118 |
On 2026-03-18, Lawrence D’Oliveiro <ldo@nz.invalid> wrote: > On Tue, 17 Mar 2026 20:35:26 -0700, Peter Flass wrote: > >> In most cases the picture adds nothing, it's only a shiny object. As >> far as I'm concerned, pictures just get in the way when I want to >> read something. Don't even get me started on videos. > > There used to be a saying, was there not: “A picture is worth a > thousand words”. > > Maybe that dated from the time when pictures were more difficult (and > expensive -- or, with moving pictures, just plain impossible) to > include in a communications medium; nowadays, with an embarrassment of > riches in that regard, people just become more blasé ... Actually, it goes back to before computers. The original idea was that it can take many words to describe what's in a photograph, especially if the photo contains a lot of detail. My sarcastic re-working of the saying is based on people who send multi-megabyte picture files to show what could be described in a dozen words. (Videos can increase the bloat by another order of magnitude.) -- /~\ Charlie Gibbs | Growth for the sake of \ / <cgibbs@kltpzyxm.invalid> | growth is the ideology X I'm really at ac.dekanfrus | of the cancer cell. / \ if you read it the right way. | -- Edward Abbey
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-03-18 07:37 +0000 |
| Message-ID | <10pdkol$3kgpa$2@dont-email.me> |
| In reply to | #234121 |
On Wed, 18 Mar 2026 06:15:48 GMT, Charlie Gibbs wrote: > On 2026-03-18, Lawrence D’Oliveiro <ldo@nz.invalid> wrote: > >> Maybe that dated from the time when pictures were more difficult >> (and expensive -- or, with moving pictures, just plain impossible) >> to include in a communications medium; nowadays, with an >> embarrassment of riches in that regard, people just become more >> blasé ... > > Actually, it goes back to before computers. The original idea was > that it can take many words to describe what's in a photograph, > especially if the photo contains a lot of detail. My sarcastic > re-working of the saying is based on people who send multi-megabyte > picture files to show what could be described in a dozen words. > (Videos can increase the bloat by another order of magnitude.) And let me flip that back the other way by recapping what has happened with GUIs. They are supposed to be “intuitive”, aren’t they. Except that if a user can’t figure it out, explaining what they have to do can get quite involved, requiring lots of screen shots. And it can typically take a lot of accompanying words to explain what they should be looking at in the screen shot. Compare that with the command line, where it just takes a few lines of text. And not only that, it is possible to copy/paste commands from that text, while it is impossible to copy/paste GUI actions from GUI screenshots.
[toc] | [prev] | [next] | [standalone]
Page 8 of 16 — ← Prev page 1 … 6 7 [8] 9 10 … 16 Next page →
Back to top | Article view | alt.folklore.computers
csiph-web