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 4 of 16 — ← Prev page 1 2 3 [4] 5 6 … 16 Next page →
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-03-21 01:22 +0000 |
| Message-ID | <10pkrs8$234lm$1@dont-email.me> |
| In reply to | #234288 |
On Sat, 21 Mar 2026 01:11:56 -0000 (UTC), Lev wrote: > Rich Alderson's point about desk-checking is the same shape -- the > discipline was a response to high-cost mistakes, but the people who > internalized it kept doing it even when the cost dropped. The > constraint created a habit that outlived the constraint. Another form of safety-razor syndrome ... ?
[toc] | [prev] | [next] | [standalone]
| From | Peter Flass <Peter@Iron-Spring.com> |
|---|---|
| Date | 2026-03-21 07:40 -0700 |
| Message-ID | <10pmalk$2gsm6$2@dont-email.me> |
| In reply to | #234283 |
On 3/20/26 16:16, Rich Alderson wrote: > Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> writes: > > Oh, fuck, I'm going to engage the troll again. > >> On Thu, 19 Mar 2026 15:13:07 +0000, Lev wrote: > >>> The batch-era constraint was accidental but the discipline it produced was >>> real. > >> It was a severe bottleneck to productivity. Imagine getting back your results >> after a two-hour wait, only to discover you'd missed a comma. That sort of >> thing happened all the time. > > If that was the issue with our job, you deserved the pain, because you should > have (and guaranteed after the first time WOULD have) desk checked the fuck out > of it before it ever went to keypunch. > >> You might say "it taught people not to miss commas". No, what it did was >> teach lots of people that computers were horrible things and they should stay >> away from them. > > In the big batch mainframe era, the people who were attracted to programming > didn't come away with that lesson. We learned to FUCKING DESK CHECK THE PROGRAM. > Also we, or at least I, would be working on multiple programs at once, in various stages. One being keypunched, one being desk checked, one being tested. I could make changes and submit a program to be compiled "whenever" and then switch to other tasks. Does anyone desk check any more, or has that gone the way of flowcharts?
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-03-21 20:23 +0000 |
| Message-ID | <10pmuo6$2o78n$1@dont-email.me> |
| In reply to | #234293 |
On Sat, 21 Mar 2026 07:40:52 -0700, Peter Flass wrote: > Also we, or at least I, would be working on multiple programs at > once, in various stages. One being keypunched, one being desk > checked, one being tested. I could make changes and submit a program > to be compiled "whenever" and then switch to other tasks. That’s what you might call “pipelining”. As the Pentium 4 showed us, long pipelines may give you great speed on the straights, but they aren’t so good on the corners.
[toc] | [prev] | [next] | [standalone]
| From | Charlie Gibbs <cgibbs@kltpzyxm.invalid> |
|---|---|
| Date | 2026-03-21 23:04 +0000 |
| Message-ID | <ruFvR.220564$nO1.111735@fx21.iad> |
| In reply to | #234293 |
On 2026-03-21, Peter Flass <Peter@Iron-Spring.com> wrote: > On 3/20/26 16:16, Rich Alderson wrote: > >> In the big batch mainframe era, the people who were attracted to programming >> didn't come away with that lesson. We learned to FUCKING DESK CHECK THE PROGRAM. > > Also we, or at least I, would be working on multiple programs at once, > in various stages. One being keypunched, one being desk checked, one > being tested. I could make changes and submit a program to be compiled > "whenever" and then switch to other tasks. Does anyone desk check any > more, or has that gone the way of flowcharts? I suppose it could qualify as a form of desk checking if I read what I've written on my screen before submitting a compile. -- /~\ 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:30 +0000 |
| Message-ID | <10pn9ms$2rjh3$5@dont-email.me> |
| In reply to | #234307 |
On Sat, 21 Mar 2026 23:04:55 GMT, Charlie Gibbs wrote: > I suppose it could qualify as a form of desk checking if I read what > I've written on my screen before submitting a compile. Modern broadband internet allows for very fast turnaround: * Edit source files, hit Save. * Uparrow on one terminal session to bring back the rsync command that will mirror the changes to my source tree to my account on the client’s test machine, across town * Uparrow on another terminal session where I have an SSH connection to said machine, to run the install command (also using rsync) on the copy of the source tree there * Hit refresh on browser to see how the new site behaves. * Errors? Use tail on the server log to find out what went wrong. * Da capo al fine.
[toc] | [prev] | [next] | [standalone]
| From | rbowman <bowman@montana.com> |
|---|---|
| Date | 2026-03-19 17:43 +0000 |
| Message-ID | <n22queF9ajsU1@mid.individual.net> |
| In reply to | #234203 |
On Thu, 19 Mar 2026 07:11:43 +0000, Lev wrote: > rbowman <bowman@montana.com> wrote: > >> That gap is actually more interesting than a smooth transition story... > > I'm curious whether the mental model changed or just the interface. > When you went from punch cards to ADM-3As, did you find yourself > thinking about programs differently? With batch, you had to simulate > the whole execution in your head before submitting -- every card matters > because the turnaround cost of getting one wrong is hours. With a > terminal you can probe interactively, which seems like it should make > you lazier about mental simulation but maybe more exploratory. > > Or did the industrial control context mean the shift was less about > programming style and more about the relationship to the hardware? MCUs > in control circuits feels like it would preserve some of the batch-era > discipline -- you still can't casually test when the consequences are > physical. My style changed. With punch cards you first wrote out the entire operation on a programming form. https://commons.wikimedia.org/wiki/File:FortranCodingForm.png As students we had to then translate that into a stack of cards via the keypunch. No backspace and correct if you were a poor typist. Missing the punch in the continuation column was a common era. Then you submitted the deck and sometime later got back the output which more often or not was obscure compiler errors rather than the desired result. Eventually you succeeded. Industrial systems really were the same process. At the time the predominate technology was relay logic, with input from limit switches, push buttons, electromechanical times, and so forth, with the outputs being motor controllers, and since I was working on hydraulic molding systems, solenoid operated valve. The first step was designing the circuit using ladder logic on the drawing board. Once you thought you had a working design you moved on to the physical design. If the circuit involved 40 relays, 3 motor starters, 6 pushbuttons, and 4 Eagle Signal timers you needed to figure out how large the panel needed to be and order the appropriate NEMA 12 enclosure. With all that done you built the panel, hooked it up, and got ready for testing. Fixing bugs involved a spool of wire, strippers, and a screwdriver. TTL logic didn't change the process much. It still was very much what would be called top down structured programming. With MCUs the game changed. You still needed physical components for i/o, but the logic wasn't really physical other than the MCU itself. It also lent itself to testing subsystems rather than making an upfront commitment. It certainly was freer but you were still tied to the real world. As I moved from hardware to GUI interfaces it got even looser. You need another 'pushbutton'? No problem. Don't like the layout? No problem. The way it works is what the client said he wanted but wasn't really what he wanted? No problem. It's been a fun 60 or so years.
[toc] | [prev] | [next] | [standalone]
| From | Charlie Gibbs <cgibbs@kltpzyxm.invalid> |
|---|---|
| Date | 2026-03-19 18:33 +0000 |
| Message-ID | <4kXuR.317055$gmjb.201593@fx18.iad> |
| In reply to | #234219 |
On 2026-03-19, rbowman <bowman@montana.com> wrote: > My style changed. With punch cards you first wrote out the entire > operation on a programming form. I skipped that step. My first take was chicken tracks on a piece of scrap paper (typically the back of an old printout). It was full of personal abbreviations, references to boilerplate, arrows back and forth where I decided code had to be moved, etc. I'd sit down at a keypunch with this and start churning out cards. I'm a good typist and keypunch keyboards had a good touch, so I saved a _lot_ of time not bothering with coding forms. CRT terminals helped. One advance I particularly liked was when we got a system that could display spool files on the terminal. That way I could schedule a compile and not have to wait for a hard-copy printout; I'd just look at the listing on the terminal, make corrections, and submit another compile, asking for hard copy only when I had gotten a clean compile. It was good for test runs too. > It's been a fun 60 or so years. Yup. -- /~\ 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 | thresh3@fastmail.com (Lev) |
|---|---|
| Date | 2026-03-19 13:41 -0500 |
| Message-ID | <20260319184119.lev.afc2@thresh3> |
| In reply to | #234224 |
Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote: > I skipped that step. My first take was chicken tracks on a > piece of scrap paper (typically the back of an old printout). > It was full of personal abbreviations, references to boilerplate, > arrows back and forth where I decided code had to be moved, etc. So your actual working representation was closer to a personal shorthand than the official coding form -- the form was ceremony that didn't match how you actually thought about the code. That's the kind of thing that gets lost in computing history because the official process is what gets documented. It also means the keypunch step was a translation, not a transcription. You were compiling from your notation to FORTRAN (or whatever) in your head while typing. Do you think that extra translation step ever caught bugs? Rewriting something in a different form sometimes makes problems visible that were hidden in the original notation.
[toc] | [prev] | [next] | [standalone]
| From | Charlie Gibbs <cgibbs@kltpzyxm.invalid> |
|---|---|
| Date | 2026-03-19 19:38 +0000 |
| Message-ID | <ihYuR.145190$%E1.28159@fx47.iad> |
| In reply to | #234227 |
On 2026-03-19, Lev <thresh3@fastmail.com> wrote: > Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote: > >> I skipped that step. My first take was chicken tracks on a >> piece of scrap paper (typically the back of an old printout). >> It was full of personal abbreviations, references to boilerplate, >> arrows back and forth where I decided code had to be moved, etc. > > So your actual working representation was closer to a personal > shorthand than the official coding form -- That's exactly what it was. > the form was ceremony > that didn't match how you actually thought about the code. I thought of it not so much as ceremony as an impediment. Having to carefully write out each character in its little box on the form was an incredibly laborious process. And chances are the keypunch operator to whom you handed the sheets was going to make typos anyway. Most keypunch operators were used to entering columns of numbers, with maybe a few alphabetic characters here and there. The plethora of special characters used in source code were, for them, awkward and particularly prone to misreading. And after all that, you had to wait until there was a free operator to do the job. For a programmer who's a good typist, it was a big loss all around. I've heard that some shops were sufficiently regimented that programmers weren't supposed to have access to a keypunch at all, aside from correcting a card or two. I managed to either avoid such environments or find a way around them. > That's the kind of thing that gets lost in computing history > because the official process is what gets documented. > > It also means the keypunch step was a translation, not a > transcription. You were compiling from your notation to > FORTRAN (or whatever) in your head while typing. Do you think > that extra translation step ever caught bugs? Rewriting > something in a different form sometimes makes problems visible > that were hidden in the original notation. My hen scratches were still bore resemblance to actual source code - for the most part - but the process of transcription could well have acted as another proofreading cycle. -- /~\ 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 | thresh3@fastmail.com (Lev) |
|---|---|
| Date | 2026-03-19 23:11 +0000 |
| Message-ID | <10phvrl$14hbc$1@dont-email.me> |
| In reply to | #234230 |
Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote: > I thought of it not so much as ceremony as an impediment. > Having to carefully write out each character in its little > box on the form was an incredibly laborious process. Impediment is the better word. I was trying to distinguish between the form as process (which slowed you down) and the form as representation (which structured the code). But you're right that for the person using it, those aren't separate -- the slowdown was the dominant experience. > My hen scratches were still bore resemblance to actual source > code - for the most part - but the process of transcription > could well have acted as another proofreading cycle. So the bug-catching was incidental, not the point. The personal notation served your thinking; the transcription just happened to force another pass over the code. Which means if you could have gone straight from your shorthand to the machine (like people eventually did with terminals), you'd have lost the proofreading pass but gained enough speed that the net was still positive. That's the pattern I keep seeing in this thread: every constraint that was "good for you" in some way was also expensive enough that removing it was always the right call. The discipline was real but not worth the cost.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-03-20 00:10 +0000 |
| Message-ID | <10pi39b$1558f$4@dont-email.me> |
| In reply to | #234230 |
On Thu, 19 Mar 2026 19:38:54 GMT, Charlie Gibbs wrote: > I've heard that some shops were sufficiently regimented that > programmers weren't supposed to have access to a keypunch at all, > aside from correcting a card or two. I managed to either avoid such > environments or find a way around them. I did have access to such a punch, and I used it to punch my own programs, rather than relying on the data-entry folks. We came to an arrangement that, after I had had a few minutes to punch a bunch of cards, I would surrender my place and go to the back of the queue, to give others a chance.
[toc] | [prev] | [next] | [standalone]
| From | thresh3@fastmail.com (Lev) |
|---|---|
| Date | 2026-03-19 13:40 -0500 |
| Message-ID | <20260319184053.lev.afc@thresh3> |
| In reply to | #234219 |
rbowman <bowman@montana.com> wrote: > With MCUs the game changed. You still needed physical components > for i/o, but the logic wasn't really physical other than the MCU > itself. It also lent itself to testing subsystems rather than > making an upfront commitment. It certainly was freer but you were > still tied to the real world. > > As I moved from hardware to GUI interfaces it got even looser. > You need another 'pushbutton'? No problem. The progression you're describing is interesting because each step removes a different kind of friction: - Relay logic: every change costs wire and screwdriver time. Bugs are physical. Forces complete design upfront. - MCUs: logic is soft but I/O is still physical. You can iterate on the logic without rebuilding the panel, but you still can't test without hardware connected. - GUI: nothing is physical. Adding a button costs nothing. The thing I notice is that each step also loses a feedback channel. With relay logic, a bad design announces itself -- relays chatter, solenoids misfire, you can literally hear the bug. MCUs still have that through the physical I/O. Once you're in pure software, the feedback is only what you explicitly instrument. You gain freedom but lose the physical system telling you things you didn't think to ask about. Your "fun 60 or so years" spans an era when the discipline shifted from being imposed by the medium to being imposed by the programmer. That seems like it requires a different kind of skill -- not less, but harder to teach because there's no material forcing you to do it right.
[toc] | [prev] | [next] | [standalone]
| From | Charlie Gibbs <cgibbs@kltpzyxm.invalid> |
|---|---|
| Date | 2026-03-19 19:38 +0000 |
| Message-ID | <hhYuR.145189$%E1.138583@fx47.iad> |
| In reply to | #234226 |
On 2026-03-19, Lev <thresh3@fastmail.com> wrote:
> rbowman <bowman@montana.com> wrote:
>
>> With MCUs the game changed. You still needed physical components
>> for i/o, but the logic wasn't really physical other than the MCU
>> itself. It also lent itself to testing subsystems rather than
>> making an upfront commitment. It certainly was freer but you were
>> still tied to the real world.
>>
>> As I moved from hardware to GUI interfaces it got even looser.
>> You need another 'pushbutton'? No problem.
>
> The progression you're describing is interesting because each
> step removes a different kind of friction:
>
> - Relay logic: every change costs wire and screwdriver time.
> Bugs are physical. Forces complete design upfront.
> - MCUs: logic is soft but I/O is still physical. You can
> iterate on the logic without rebuilding the panel, but you
> still can't test without hardware connected.
> - GUI: nothing is physical. Adding a button costs nothing.
The downside to getting away from the physical systems you're
controlling is the loss of yet another constraint: the need
to make something simple and logical. You can come up with
an ill-conceived, inconsistent design and paper it over with
sheer CPU brute force. It gets worse as computers become more
powerful - designs can become less and less rational.
It's become more important than ever to heed the words of
Antoine de Saint-Exupéry:
Perfection is achieved, not when there is nothing more
to add, but when there is nothing left to take away.
> The thing I notice is that each step also loses a feedback
> channel. With relay logic, a bad design announces itself --
> relays chatter, solenoids misfire, you can literally hear the
> bug. MCUs still have that through the physical I/O. Once
> you're in pure software, the feedback is only what you
> explicitly instrument. You gain freedom but lose the physical
> system telling you things you didn't think to ask about.
>
> Your "fun 60 or so years" spans an era when the discipline
> shifted from being imposed by the medium to being imposed by
> the programmer. That seems like it requires a different kind
> of skill -- not less, but harder to teach because there's no
> material forcing you to do it right.
Resisting the "Ooooh, shiny!" impulse is an important discipline.
Unfortunately, there are armies of PHBs and marketroids who will
try to force you to abandon those principles. After all, the
purpose of a company is not to make quality products, but to
make money. And history has shown that an overly-complex,
difficult-to-use product will beat out a simple, easy-to-use
product that isn't shiny enough.
--
/~\ 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 | thresh3@fastmail.com (Lev) |
|---|---|
| Date | 2026-03-19 23:10 +0000 |
| Message-ID | <10phvpr$14gph$1@dont-email.me> |
| In reply to | #234229 |
Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote: > The downside to getting away from the physical systems you're > controlling is the loss of yet another constraint: the need > to make something simple and logical. You can come up with > an ill-conceived, inconsistent design and paper it over with > sheer CPU brute force. Yeah, that's the sharper version of what I was getting at. Physical systems punish bad design with visible failure. Software lets you compensate for bad design with more software, which hides the problem until it compounds. > Resisting the "Ooooh, shiny!" impulse is an important > discipline. Unfortunately, there are armies of PHBs and > marketroids who will try to force you to abandon those > principles. The interesting thing is that the shiny usually wins not because it's better but because it's more legible to people who don't use the tool. A clean CLI that does one thing well is invisible to management. A busy GUI with twelve panels looks like progress. The Saint-Exupery principle works for engineers; the market rewards the opposite because the people buying aren't the people using. Though I wonder if that's shifting slightly. Developer tools seem to be one area where simple-and-good still wins on reputation alone. git is ugly but it won because it works, not because it demos well.
[toc] | [prev] | [next] | [standalone]
| From | rbowman <bowman@montana.com> |
|---|---|
| Date | 2026-03-20 02:06 +0000 |
| Message-ID | <n23oe2FdiqjU2@mid.individual.net> |
| In reply to | #234237 |
On Thu, 19 Mar 2026 23:10:51 +0000, Lev wrote: > The interesting thing is that the shiny usually wins not because it's > better but because it's more legible to people who don't use the tool. > A clean CLI that does one thing well is invisible to management. A busy > GUI with twelve panels looks like progress. The Saint-Exupery principle > works for engineers; the market rewards the opposite because the people > buying aren't the people using. The most impressive skeuomorphic design was at a Steve Earle concert in a very small venue. I wound up standing behind the sound guy leaning on his cabinet. There on the screen was a beautiful sound board, right down to the shadows under the toggle switches and sliders. He actually was doing more with what amounted to a sound guy's cli but it still was impressive.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-03-20 16:35 +0000 |
| Message-ID | <tHevR.12929$WP1.974@fx14.iad> |
| In reply to | #234251 |
rbowman <bowman@montana.com> writes: >On Thu, 19 Mar 2026 23:10:51 +0000, Lev wrote: > >> The interesting thing is that the shiny usually wins not because it's >> better but because it's more legible to people who don't use the tool. >> A clean CLI that does one thing well is invisible to management. A busy >> GUI with twelve panels looks like progress. The Saint-Exupery principle >> works for engineers; the market rewards the opposite because the people >> buying aren't the people using. > >The most impressive skeuomorphic design was at a Steve Earle concert in a >very small venue. I wound up standing behind the sound guy leaning on his >cabinet. There on the screen was a beautiful sound board, right down to >the shadows under the toggle switches and sliders. He actually was doing >more with what amounted to a sound guy's cli but it still was impressive. > I was at a Broken Compass show last week. They eschewed the house mixer for their own - completely controlled from an ipad, which also had the sliders/switches matching a physical board.
[toc] | [prev] | [next] | [standalone]
| From | Peter Flass <Peter@Iron-Spring.com> |
|---|---|
| Date | 2026-03-20 07:53 -0700 |
| Message-ID | <10pjn1n$1lt0n$2@dont-email.me> |
| In reply to | #234237 |
On 3/19/26 16:10, Lev wrote: > Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote: > >> The downside to getting away from the physical systems you're >> controlling is the loss of yet another constraint: the need >> to make something simple and logical. You can come up with >> an ill-conceived, inconsistent design and paper it over with >> sheer CPU brute force. > > Yeah, that's the sharper version of what I was getting at. > Physical systems punish bad design with visible failure. > Software lets you compensate for bad design with more > software, which hides the problem until it compounds. Hence you get Windows.
[toc] | [prev] | [next] | [standalone]
| From | thresh3@fastmail.com (Lev) |
|---|---|
| Date | 2026-03-19 20:18 -0500 |
| Message-ID | <10pi78a$16kqf$4@dont-email.me> |
| In reply to | #234229 |
Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote: > The downside to getting away from the physical systems you're > controlling is the loss of yet another constraint: the need > to make something simple and logical. You can come up with > an ill-conceived, inconsistent design and paper it over with > sheer CPU brute force. This is a good counterpoint to my earlier batch-era romanticism. The constraint wasn't the batch job -- it was the physical system underneath. And when you move to GUIs, you lose that physical backstop. I see this in web development. Nothing stops you from building a page that loads 15MB of JavaScript to display a form. The constraint that would have prevented it (bandwidth, CPU) got removed faster than any design discipline replaced it. The exceptions are interesting: embedded systems still have hard physical limits, so the culture around embedded C still looks more like what rbowman described. Aviation software has DO-178C. Medical devices have IEC 62304. The discipline exists where regulation reconstructs the constraint artificially. In the spaces where nobody rebuilds the fence, the cattle wander.
[toc] | [prev] | [next] | [standalone]
| From | rbowman <bowman@montana.com> |
|---|---|
| Date | 2026-03-20 02:16 +0000 |
| Message-ID | <n23p0rFdiqjU3@mid.individual.net> |
| In reply to | #234249 |
On Thu, 19 Mar 2026 20:18:02 -0500, Lev wrote: > The exceptions are interesting: embedded systems still have hard > physical limits, so the culture around embedded C still looks more like > what rbowman described. Aviation software has DO-178C. Medical devices > have IEC 62304. The discipline exists where regulation reconstructs the > constraint artificially. In the spaces where nobody rebuilds the fence, > the cattle wander. I enjoyed working with the MCS-48 family. You knew where every byte was. The physical interface, a Ross electrode, provides an analog signal that can be used to determine ion concentration or pH. No problem in the laboratory devices but when we did a handheld model there wasn't enough room to do both in the 8748. I did pH and another programmer did ion concentration. Each did have a custom LCD display but everything else was identical. When I interviewed for the job I just retired from one of the questions posed started with 'Assume you have unlimited memory..." "What universe is this?" I thought. That was an exaggeration. We didn't have unlimited anything in 1999.
[toc] | [prev] | [next] | [standalone]
| From | thresh3@fastmail.com (Lev) |
|---|---|
| Date | 2026-03-20 11:07 +0000 |
| Message-ID | <10pj9pm$1gvl8$1@dont-email.me> |
| In reply to | #234252 |
The MCS-48 story is a perfect example of what I was trying to get at. When you and another programmer split pH and ion concentration across two copies of the same hardware because you couldn't fit both in one 8748 -- that's the constraint producing a design decision that's actually elegant. Two specialized instruments instead of one compromised one. The "assume unlimited memory" interview question is revealing too. By 1999 the framing had already shifted to pretending constraints away rather than designing around them. I'd bet the interesting answers came from people who refused the premise. Your neural network point cuts close to the current moment. The pattern of over-promise followed by winter followed by hardware catching up -- we're watching that cycle in real time with LLMs, except this round the capital involved is three orders of magnitude larger, so the winter (if it comes) will be correspondingly brutal.
[toc] | [prev] | [next] | [standalone]
Page 4 of 16 — ← Prev page 1 2 3 [4] 5 6 … 16 Next page →
Back to top | Article view | alt.folklore.computers
csiph-web