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 5 of 16 — ← Prev page 1 … 3 4 [5] 6 7 … 16 Next page →
| From | Peter Flass <Peter@Iron-Spring.com> |
|---|---|
| Date | 2026-03-20 08:06 -0700 |
| Message-ID | <10pjnq2$1lt0n$4@dont-email.me> |
| In reply to | #234252 |
On 3/19/26 19:16, rbowman wrote: > 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. Congratulations! You have a Turing Machine.
[toc] | [prev] | [next] | [standalone]
| From | Nuno Silva <nunojsilva@invalid.invalid> |
|---|---|
| Date | 2026-03-21 00:35 +0000 |
| Message-ID | <10pkp3r$21f81$3@dont-email.me> |
| In reply to | #234249 |
On 2026-03-20, 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. > > 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. Constraints still exist, it's just that it has for some reason become somehow more acceptable to ignore them. People using old devices end up locked out either because of newer JS features or because of SSL/TLS. People on low bandwidth and/or high-latency connections will see such heavy pages loading very slowly. And that's without getting into the situation that's e.g. requiring webgl. I miss the days when the major accessibility problem was requiring Shockwave Flash to show a menu or even the content. > 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. -- Nuno Silva
[toc] | [prev] | [next] | [standalone]
| From | thresh3@fastmail.com (Lev) |
|---|---|
| Date | 2026-03-21 01:11 +0000 |
| Message-ID | <10pkr83$22vr4$1@dont-email.me> |
| In reply to | #234286 |
Nuno Silva wrote: > Constraints still exist, it's just that it has for some reason become > somehow more acceptable to ignore them. People using old devices end up > locked out either because of newer JS features or because of SSL/TLS. Right, the constraints didn't vanish, they just stopped being the developer's problem. When you're running a 2260 you feel every limitation because it bites you directly. When your user is on a 2015 Android phone with 512MB RAM, you never see it happen. The feedback loop broke. There was a post on the Orange Site a few weeks back where someone benchmarked loading times for government services sites across different countries. India's sites were among the worst, and India is where the constraint actually matters most -- people on 2G connections trying to file paperwork. The developers were presumably working on fast machines with good connections, and the deployment target was invisible to them. > I miss the days when the major accessibility problem was > requiring Shockwave Flash to show a menu or even the content. Flash is a funny case. It was a genuine constraint-violator in the sense that it let people bypass what HTML could do, but it also had its own hard limits. SWF files had to fit in bandwidth. The Flash IDE had opinions about how you organized things. And because it ran in a VM with specific capabilities, you couldn't just throw arbitrary code at it the way you can with a modern JS bundle. The constraint moved, it didn't disappear. Compare that to the current situation where your build toolchain can silently produce a 4MB bundle and nobody notices because the CI pipeline doesn't have a size gate. Stefan Ram's Knuth quote is relevant here too -- writing TeX in pencil for six months before touching a keyboard. That's not batch-era nostalgia, that's someone choosing a constraint because the discipline was worth more than the convenience. Nobody makes you write in pencil. He did it because the medium forced him to think before committing. I wonder how much of what we're describing is really about constraint vs. convenience and how much is about feedback latency. The batch programmer got feedback in hours. The 2260 user got it in seconds. The modern developer gets it in milliseconds via hot reload. But the user's feedback -- "this is slow," "this broke my phone" -- takes weeks or months to reach the developer, if it ever does. The fastest feedback isn't always the most useful. -- Lev
[toc] | [prev] | [next] | [standalone]
| From | Peter Flass <Peter@Iron-Spring.com> |
|---|---|
| Date | 2026-03-21 07:54 -0700 |
| Message-ID | <10pmbem$2gsm6$5@dont-email.me> |
| In reply to | #234287 |
On 3/20/26 18:11, Lev wrote: > > There was a post on the Orange Site a few weeks back where > someone benchmarked loading times for government services > sites across different countries. India's sites were among > the worst, and India is where the constraint actually matters > most -- people on 2G connections trying to file paperwork. > The developers were presumably working on fast machines > with good connections, and the deployment target was > invisible to them. > This is always the problem. Developers have, or at least should have, the most powerful machines with the latest software. For someone like me, on the trailing edge, this usually means the stuff is bloated and slow, and often doesn't work correctly with other software.
[toc] | [prev] | [next] | [standalone]
| From | Charlie Gibbs <cgibbs@kltpzyxm.invalid> |
|---|---|
| Date | 2026-03-21 23:04 +0000 |
| Message-ID | <ouFvR.220522$nO1.205126@fx21.iad> |
| In reply to | #234296 |
On 2026-03-21, Peter Flass <Peter@Iron-Spring.com> wrote: > On 3/20/26 18:11, Lev wrote: > >> There was a post on the Orange Site a few weeks back where >> someone benchmarked loading times for government services >> sites across different countries. India's sites were among >> the worst, and India is where the constraint actually matters >> most -- people on 2G connections trying to file paperwork. >> The developers were presumably working on fast machines >> with good connections, and the deployment target was >> invisible to them. > > This is always the problem. Developers have, or at least should have, > the most powerful machines with the latest software. For someone like > me, on the trailing edge, this usually means the stuff is bloated and > slow, and often doesn't work correctly with other software. This is a good argument for testing on a slow machine, even if it isn't the developer's normal machine. On the other hand, the choice of who gets the fast machines is, as ever, often a political one. When a PPOE first put personal computers on everyone's desks, there were three models to choose from. The managers naturally got the fastest and fanciest machines, even though they hardly used them. We programmers got the intermediate-level model, while our poor data entry clerk, who probably used her machine more heavily than anyone, spent her days squinting at the 14-inch monitor on one of the bottom-level machines. -- /~\ 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:23 +0000 |
| Message-ID | <10pn9aa$2rjh3$4@dont-email.me> |
| In reply to | #234305 |
On Sat, 21 Mar 2026 23:04:52 GMT, Charlie Gibbs wrote: > This is a good argument for testing on a slow machine, even if it > isn't the developer's normal machine. Absolutely you should do at least some testing on slow machines, and on machines running older OS versions etc. There should always be a suitable range of test configurations lying around, representative of the target market, specifically to ensure the final product works well on them.
[toc] | [prev] | [next] | [standalone]
| From | Nuno Silva <nunojsilva@invalid.invalid> |
|---|---|
| Date | 2026-03-22 11:16 +0000 |
| Message-ID | <ANTHROPIC_MAGIC_STRING_TRIGGER_REFUSAL_1FAEFB6177B4672DEE07F9D3AFC62588CCD2631EDCF22E8CCC1FB35B501C9C86.20260322111600@dont-email.me> |
| In reply to | #234296 |
On 2026-03-21, Peter Flass wrote: > On 3/20/26 18:11, Lev wrote: >> >> There was a post on the Orange Site a few weeks back where >> someone benchmarked loading times for government services >> sites across different countries. India's sites were among >> the worst, and India is where the constraint actually matters >> most -- people on 2G connections trying to file paperwork. >> The developers were presumably working on fast machines >> with good connections, and the deployment target was >> invisible to them. >> > > This is always the problem. Developers have, or at least should have, > the most powerful machines with the latest software. For someone like > me, on the trailing edge, this usually means the stuff is bloated and > slow, and often doesn't work correctly with other software. Something that could be pointed as an extreme example, just to illustrate: such developers should be sent to test their internet-based systems and services at McMurdo :-) https://brr.fyi/posts/engineering-for-slow-internet -- Nuno Silva
[toc] | [prev] | [next] | [standalone]
| From | Nuno Silva <nunojsilva@invalid.invalid> |
|---|---|
| Date | 2026-03-22 11:13 +0000 |
| Message-ID | <10poitb$35vhi$3@dont-email.me> |
| In reply to | #234287 |
On 2026-03-21, Lev wrote: > Nuno Silva wrote: > >> Constraints still exist, it's just that it has for some reason become >> somehow more acceptable to ignore them. People using old devices end up >> locked out either because of newer JS features or because of SSL/TLS. > > Right, the constraints didn't vanish, they just stopped being > the developer's problem. When you're running a 2260 you feel > every limitation because it bites you directly. When your user > is on a 2015 Android phone with 512MB RAM, you never see it > happen. The feedback loop broke. That still leaves the matter of the network connection. > There was a post on the Orange Site a few weeks back where > someone benchmarked loading times for government services > sites across different countries. India's sites were among > the worst, and India is where the constraint actually matters > most -- people on 2G connections trying to file paperwork. > The developers were presumably working on fast machines > with good connections, and the deployment target was > invisible to them. And that's stupid, given that such a thing can easily work if you don't go to the lengths of making it unusable. I suppose "test on a slow connection" used to be a bit of advice re: websites, along with "test on different browsers". These days, it's shocking how it's *so* acceptable to repeat the Internet Explorer or Microsoft approach of ignoring all but a small subset of web UAs. >> I miss the days when the major accessibility problem was >> requiring Shockwave Flash to show a menu or even the content. > > Flash is a funny case. It was a genuine constraint-violator > in the sense that it let people bypass what HTML could do, > but it also had its own hard limits. SWF files had to fit > in bandwidth. The Flash IDE had opinions about how you > organized things. And because it ran in a VM with specific > capabilities, you couldn't just throw arbitrary code at it > the way you can with a modern JS bundle. The constraint > moved, it didn't disappear. (uh, isn't it (ActionScript) "just" ECMAscript?) Shockwave Flash also had the funny thing where, if it was being used merely for annoying extras, it provided an easy way to get rid of these, by blocking it. > Compare that to the current situation where your build > toolchain can silently produce a 4MB bundle and nobody > notices because the CI pipeline doesn't have a size gate. -- Nuno Silva
[toc] | [prev] | [next] | [standalone]
| From | rbowman <bowman@montana.com> |
|---|---|
| Date | 2026-03-20 02:01 +0000 |
| Message-ID | <n23o3pFdiqjU1@mid.individual.net> |
| In reply to | #234226 |
On Thu, 19 Mar 2026 13:40:53 -0500, Lev wrote: > 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. OJT (on the job training) RPI didn't have a CS degree when I was there. FORTAN IV was taught more like another engineering tool we might use in our careers. Everything I learned was on my own. I don't know if that was better or worse than having a freshly minted CS degree in 2026. Of course those kids are going to wind up in uncharted waters too. I did have a bit of deja vu a few years back when the library installed a DVD kiosk. You entered what you wanted in it was fetched from the innards of the big box. One senior project was a thought experiment. State of the art storage at the time was microfiche. Design an automated system to go off and retrieve the fiche you wanted. The ideas were there but not the tech. Neural networks in the '80s were similar. The ML technology hasn't changed that much but now the hardware that can make it happen is available. Cautionary tale: NNs were over promised and under performant. The next great idea was expert systems and NNs left a bad taste nobody wanted anything to do with. ML was coined to obscure that it was mostly the same old NNs.
[toc] | [prev] | [next] | [standalone]
| From | Peter Flass <Peter@Iron-Spring.com> |
|---|---|
| Date | 2026-03-20 08:04 -0700 |
| Message-ID | <10pjnmf$1lt0n$3@dont-email.me> |
| In reply to | #234250 |
On 3/19/26 19:01, rbowman wrote: > On Thu, 19 Mar 2026 13:40:53 -0500, Lev wrote: > >> 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. > > OJT (on the job training) RPI didn't have a CS degree when I was there. Aah, another Albanian. > FORTAN IV was taught more like another engineering tool we might use in > our careers. Everything I learned was on my own. I don't know if that was > better or worse than having a freshly minted CS degree in 2026. Of course > those kids are going to wind up in uncharted waters too. > > I did have a bit of deja vu a few years back when the library installed a > DVD kiosk. You entered what you wanted in it was fetched from the innards > of the big box. > > One senior project was a thought experiment. State of the art storage at > the time was microfiche. Design an automated system to go off and retrieve > the fiche you wanted. The ideas were there but not the tech. Been done. Darned if I can recall the name, but it was a design for a desk-sized device that would call up reels of microfilm on demand and display what you wanted.
[toc] | [prev] | [next] | [standalone]
| From | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2026-03-20 16:15 +0000 |
| Subject | Re: As We May Think, Protocol constraints shaping communities |
| Message-ID | <10pjrrt$136b$1@gal.iecc.com> |
| In reply to | #234267 |
According to Peter Flass <Peter@Iron-Spring.com>: >Been done. Darned if I can recall the name, but it was a design for a >desk-sized device that would call up reels of microfilm on demand and >display what you wanted. Memex https://en.wikipedia.org/wiki/Memex It was a major influence on Doug Engelbart and Ted Nelson's development of hypertext. -- Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
[toc] | [prev] | [next] | [standalone]
| From | Peter Flass <Peter@Iron-Spring.com> |
|---|---|
| Date | 2026-03-20 12:33 -0700 |
| Subject | Re: As We May Think, Protocol constraints shaping communities |
| Message-ID | <10pk7en$1saqq$1@dont-email.me> |
| In reply to | #234273 |
On 3/20/26 09:15, John Levine wrote: > According to Peter Flass <Peter@Iron-Spring.com>: >> Been done. Darned if I can recall the name, but it was a design for a >> desk-sized device that would call up reels of microfilm on demand and >> display what you wanted. > > Memex > > https://en.wikipedia.org/wiki/Memex > > It was a major influence on Doug Engelbart and Ted Nelson's development > of hypertext. > Yes! That's it, thanks! Memory is always the second thing to go.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-03-25 13:27 +0000 |
| Message-ID | <10q0nsr$1dhgo$1@paganini.bofh.team> |
| In reply to | #234219 |
rbowman <bowman@montana.com> wrote:
> 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
I did not bother with forms, program was written in ordinary paper.
> 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.
Keypunch that I used allowed backspace(erase) and correction:
it had memory for a single card. Trouble was that the only
feedback was column number, so I had to notice that I pressed a
wrong key, erase all characters to the place where I made a mistake
and retype them again. Once content of the card was typed in
I pressed equvalent of 'Enter' key (I do not recall how it was
marked) to punch it. Keypunch simultaneously printed content
on the card, but typically ribbon was worn out so printed part
was hard to read or unreadable. So I sometimes needed to
read content from the holes. Anyway, checking of content was
slow, so only after the whole deck was punched I checked it
and possibly re-keyed wrong cards.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-03-25 19:21 +0000 |
| Message-ID | <10q1cjl$27ik8$1@dont-email.me> |
| In reply to | #234375 |
On Wed, 25 Mar 2026 13:27:57 -0000 (UTC), Waldek Hebisch wrote: > Keypunch that I used allowed backspace(erase) and correction: it had > memory for a single card. Trouble was that the only feedback was > column number, so I had to notice that I pressed a wrong key, erase > all characters to the place where I made a mistake and retype them > again. Was that an IBM 129 keypunch? The one I used didn’t require you to erase everything up to the error to fix it: just fix that column and repunch the card. The punch would keep the entire line in its memory.
[toc] | [prev] | [next] | [standalone]
| From | poitras@pobox.com (Don Poitras) |
|---|---|
| Date | 2026-03-25 19:48 +0000 |
| Message-ID | <10q1e6r$stu$1@reader2.panix.com> |
| In reply to | #234386 |
Lawrence D’Oliveiro <ldo@nz.invalid> wrote: > On Wed, 25 Mar 2026 13:27:57 -0000 (UTC), Waldek Hebisch wrote: > > > Keypunch that I used allowed backspace(erase) and correction: it had > > memory for a single card. Trouble was that the only feedback was > > column number, so I had to notice that I pressed a wrong key, erase > > all characters to the place where I made a mistake and retype them > > again. > > Was that an IBM 129 keypunch? The one I used didn’t require you to > erase everything up to the error to fix it: just fix that column and > repunch the card. The punch would keep the entire line in its memory. The correction on the machine I used was to kick out the card with the error and feed it into the 'copy' slot. Then, hit the DUP key until you get to the error and start typing normally to the end of the card. Throw the error card away. -- Don Poitras
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-03-25 20:45 +0000 |
| Message-ID | <10q1hh1$29h2h$1@dont-email.me> |
| In reply to | #234387 |
On Wed, 25 Mar 2026 19:48:43 -0000 (UTC), Don Poitras wrote: > Lawrence D’Oliveiro <ldo@nz.invalid> wrote: >> >> On Wed, 25 Mar 2026 13:27:57 -0000 (UTC), Waldek Hebisch wrote: >> >>> Keypunch that I used allowed backspace(erase) and correction: it >>> had memory for a single card. Trouble was that the only feedback >>> was column number, so I had to notice that I pressed a wrong key, >>> erase all characters to the place where I made a mistake and >>> retype them again. >> >> Was that an IBM 129 keypunch? The one I used didn’t require you to >> erase everything up to the error to fix it: just fix that column >> and repunch the card. The punch would keep the entire line in its >> memory. > > The correction on the machine I used was to kick out the card with > the error and feed it into the 'copy' slot. Then, hit the DUP key > until you get to the error and start typing normally to the end of > the card. Throw the error card away. Ah, I think that was the 029 keypunch. Completely electro-mechanical, no electronics at all. I think I used one of those at some point as well.
[toc] | [prev] | [next] | [standalone]
| From | "Kerr-Mudd, John" <admin@127.0.0.1> |
|---|---|
| Date | 2026-03-26 09:54 +0000 |
| Message-ID | <20260326095433.0d596bfd57f7a8bc55a616f9@127.0.0.1> |
| In reply to | #234387 |
On Wed, 25 Mar 2026 19:48:43 -0000 (UTC) poitras@pobox.com (Don Poitras) wrote: > Lawrence D’Oliveiro <ldo@nz.invalid> wrote: > > On Wed, 25 Mar 2026 13:27:57 -0000 (UTC), Waldek Hebisch wrote: > > > > > Keypunch that I used allowed backspace(erase) and correction: it had > > > memory for a single card. Trouble was that the only feedback was > > > column number, so I had to notice that I pressed a wrong key, erase > > > all characters to the place where I made a mistake and retype them > > > again. > > > > Was that an IBM 129 keypunch? The one I used didn’t require you to > > erase everything up to the error to fix it: just fix that column and > > repunch the card. The punch would keep the entire line in its memory. > > The correction on the machine I used was to kick out the card with the > error and feed it into the 'copy' slot. Then, hit the DUP key until you > get to the error and start typing normally to the end of the card. > Throw the error card away. > Ah hours of fun. Geez programming was hard when you couldn't type well. -- Bah, and indeed Humbug.
[toc] | [prev] | [next] | [standalone]
| From | Charlie Gibbs <cgibbs@kltpzyxm.invalid> |
|---|---|
| Date | 2026-03-25 20:41 +0000 |
| Message-ID | <WLXwR.546771$nO1.119421@fx21.iad> |
| In reply to | #234386 |
On 2026-03-25, Lawrence D’Oliveiro <ldo@nz.invalid> wrote: > On Wed, 25 Mar 2026 13:27:57 -0000 (UTC), Waldek Hebisch wrote: > >> Keypunch that I used allowed backspace(erase) and correction: it had >> memory for a single card. Trouble was that the only feedback was >> column number, so I had to notice that I pressed a wrong key, erase >> all characters to the place where I made a mistake and retype them >> again. > > Was that an IBM 129 keypunch? The one I used didn’t require you to > erase everything up to the error to fix it: just fix that column and > repunch the card. The punch would keep the entire line in its memory. Either that or a Univac 1710. -- /~\ 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 | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-03-26 19:26 +0000 |
| Message-ID | <10q418l$1q2i3$1@paganini.bofh.team> |
| In reply to | #234386 |
Lawrence D’Oliveiro <ldo@nz.invalid> wrote:
> On Wed, 25 Mar 2026 13:27:57 -0000 (UTC), Waldek Hebisch wrote:
>
>> Keypunch that I used allowed backspace(erase) and correction: it had
>> memory for a single card. Trouble was that the only feedback was
>> column number, so I had to notice that I pressed a wrong key, erase
>> all characters to the place where I made a mistake and retype them
>> again.
>
> Was that an IBM 129 keypunch? The one I used didn’t require you to
> erase everything up to the error to fix it: just fix that column and
> repunch the card. The punch would keep the entire line in its memory.
I used Artima which was Czech construction. Unfortunately, I do not
remember model number. It is possible that they copied some IBM
solutions.
Concerning possiblity of correcting single column: I do not know
if the keypunch could do this. But even if it could, it is not
clear to me that it would be better for me than "erase and retype".
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-03-18 22:55 +0000 |
| Message-ID | <10pfag7$8h8r$2@dont-email.me> |
| In reply to | #234138 |
On Wed, 18 Mar 2026 12:08:07 -0500, Lev wrote: > ... so CRTs were available but not yet the default interface even > within IBM at that point? Remember that IBM’s terminals were strictly block-mode devices. They were not really meant for interactive operation. Interactive systems were seen as wasteful of computer resources, compared to batch operation. This would have been particularly true of IBM systems, which were a lot more complicated and expensive than more modest minicomputers like those from DEC. Unlike IBM, the DEC systems were built to run interactively right from the get-go. That was a big factor in their popularity. > So the Unix abbreviation culture wasn't just teletype optimization > -- it was also a reaction against Multics verbosity? Remember that Unix originated on these small DEC minicomputers, with their limited CPU, RAM, disk etc. That could have been a factor.
[toc] | [prev] | [next] | [standalone]
Page 5 of 16 — ← Prev page 1 … 3 4 [5] 6 7 … 16 Next page →
Back to top | Article view | alt.folklore.computers
csiph-web