Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #399792 > unrolled thread
| Started by | fir <profesor.fir@gmail.com> |
|---|---|
| First post | 2026-06-08 17:49 +0200 |
| Last post | 2026-06-14 14:44 +0200 |
| Articles | 20 on this page of 194 — 17 participants |
Back to article view | Back to comp.lang.c
this guy talks about fopen (and im thinking about fopen for network) fir <profesor.fir@gmail.com> - 2026-06-08 17:49 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) fir <profesor.fir@gmail.com> - 2026-06-08 18:16 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) fir <profesor.fir@gmail.com> - 2026-06-08 18:24 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-09 00:28 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) fir <profesor.fir@gmail.com> - 2026-06-09 08:56 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) fir <profesor.fir@gmail.com> - 2026-06-09 10:26 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-09 09:10 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) fir <profesor.fir@gmail.com> - 2026-06-09 11:34 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) David Brown <david.brown@hesbynett.no> - 2026-06-09 12:25 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) fir <profesor.fir@gmail.com> - 2026-06-09 12:31 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) fir <profesor.fir@gmail.com> - 2026-06-09 13:43 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) fir <profesor.fir@gmail.com> - 2026-06-09 13:53 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-10 00:02 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) fir <profesor.fir@gmail.com> - 2026-06-10 08:55 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-10 00:00 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) fir <profesor.fir@gmail.com> - 2026-06-10 09:06 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-10 00:34 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) fir <profesor.fir@gmail.com> - 2026-06-10 12:37 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-10 11:40 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-11 00:01 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-22 13:42 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-22 22:38 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-23 14:40 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-24 02:04 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-24 04:42 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Paul <nospam@needed.invalid> - 2026-06-09 06:02 -0400
Re: this guy talks about fopen (and im thinking about fopen for network) fir <profesor.fir@gmail.com> - 2026-06-09 12:18 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-09 23:45 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-09 13:55 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-09 23:56 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-09 21:52 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-09 21:55 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-09 22:05 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-10 06:03 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-10 00:24 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-11 00:07 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-19 16:47 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-20 02:49 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-19 19:52 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-20 03:57 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) scott@slp53.sl.home (Scott Lurndal) - 2026-06-20 15:49 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-21 16:30 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) scott@slp53.sl.home (Scott Lurndal) - 2026-06-22 14:56 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-22 12:23 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) scott@slp53.sl.home (Scott Lurndal) - 2026-06-10 14:56 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-09 13:54 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-09 23:47 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-09 21:42 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-10 06:21 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-10 00:14 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-10 00:31 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-11 00:15 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-11 21:08 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-13 00:10 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-09 23:01 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-10 06:47 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-11 13:27 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-12 01:35 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-13 14:26 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-13 14:32 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-14 00:45 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-14 13:55 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-16 04:36 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-16 13:08 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-16 13:11 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-17 03:11 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-17 12:13 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-17 23:47 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-17 20:26 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-18 07:30 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-18 04:36 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-18 04:38 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-18 23:03 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-19 13:42 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-19 22:40 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-19 16:40 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-20 02:50 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-19 19:53 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-20 03:59 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-21 16:31 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-22 00:59 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-22 14:06 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-22 22:40 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-23 14:41 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-24 02:05 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-24 04:36 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-24 12:19 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-24 21:47 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-25 12:44 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-10 12:02 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-11 00:16 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) BGB <cr88192@gmail.com> - 2026-06-17 18:41 -0500
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-18 07:30 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) BGB <cr88192@gmail.com> - 2026-06-18 03:49 -0500
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-18 23:06 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) BGB <cr88192@gmail.com> - 2026-06-19 01:20 -0500
Re: this guy talks about fopen (and im thinking about fopen for network) David Brown <david.brown@hesbynett.no> - 2026-06-19 08:56 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) Bart <bc@freeuk.com> - 2026-06-19 10:42 +0100
Re: this guy talks about fopen (and im thinking about fopen for network) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-19 10:18 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) Bart <bc@freeuk.com> - 2026-06-19 15:29 +0100
Re: this guy talks about fopen (and im thinking about fopen for network) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-19 16:18 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) Bart <bc@freeuk.com> - 2026-06-19 18:07 +0100
Re: this guy talks about fopen (and im thinking about fopen for network) scott@slp53.sl.home (Scott Lurndal) - 2026-06-19 18:51 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) Bart <bc@freeuk.com> - 2026-06-19 21:04 +0100
Re: this guy talks about fopen (and im thinking about fopen for network) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-19 19:55 +0000
[OT] Google AI - behavioral analysis (was: [something else]) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-20 01:52 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-20 03:03 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) scott@slp53.sl.home (Scott Lurndal) - 2026-06-19 18:50 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) David Brown <david.brown@hesbynett.no> - 2026-06-19 13:46 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) Bart <bc@freeuk.com> - 2026-06-19 15:49 +0100
Re: this guy talks about fopen (and im thinking about fopen for network) David Brown <david.brown@hesbynett.no> - 2026-06-19 17:25 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) Michael S <already5chosen@yahoo.com> - 2026-06-21 01:42 +0300
Re: this guy talks about fopen (and im thinking about fopen for network) David Brown <david.brown@hesbynett.no> - 2026-06-21 12:18 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) Michael S <already5chosen@yahoo.com> - 2026-06-21 23:15 +0300
Re: this guy talks about fopen (and im thinking about fopen for network) antispam@fricas.org (Waldek Hebisch) - 2026-06-22 04:33 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) David Brown <david.brown@hesbynett.no> - 2026-06-22 10:01 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) scott@slp53.sl.home (Scott Lurndal) - 2026-06-22 14:56 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) David Brown <david.brown@hesbynett.no> - 2026-06-23 07:25 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) scott@slp53.sl.home (Scott Lurndal) - 2026-06-23 15:35 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) David Brown <david.brown@hesbynett.no> - 2026-06-23 18:07 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-23 17:12 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) David Brown <david.brown@hesbynett.no> - 2026-06-23 21:07 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) Michael S <already5chosen@yahoo.com> - 2026-06-23 23:00 +0300
Re: this guy talks about fopen (and im thinking about fopen for network) David Brown <david.brown@hesbynett.no> - 2026-06-24 08:32 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) Michael S <already5chosen@yahoo.com> - 2026-06-24 21:54 +0300
Re: this guy talks about fopen (and im thinking about fopen for network) David Brown <david.brown@hesbynett.no> - 2026-06-24 21:09 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-24 10:48 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-24 10:47 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) David Brown <david.brown@hesbynett.no> - 2026-06-24 15:02 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-25 11:29 +0000
NIC interrupt rates (was UART discussion; previously was Re: this guy talks about fopen (and im thinking about fopen for network) scott@slp53.sl.home (Scott Lurndal) - 2026-06-25 15:31 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) David Brown <david.brown@hesbynett.no> - 2026-06-25 19:15 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) scott@slp53.sl.home (Scott Lurndal) - 2026-06-25 18:29 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) David Brown <david.brown@hesbynett.no> - 2026-06-25 20:52 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) scott@slp53.sl.home (Scott Lurndal) - 2026-06-26 14:58 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-26 11:46 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-27 01:57 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) Michael S <already5chosen@yahoo.com> - 2026-06-25 22:53 +0300
Re: this guy talks about fopen (and im thinking about fopen for network) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-27 01:52 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) David Brown <david.brown@hesbynett.no> - 2026-06-27 19:46 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-01 13:16 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) David Brown <david.brown@hesbynett.no> - 2026-07-03 17:00 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) Michael S <already5chosen@yahoo.com> - 2026-06-27 20:49 +0300
Re: this guy talks about fopen (and im thinking about fopen for network) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-01 13:17 +0000
UARTs (was Re: this guy talks about fopen (and im thinking about fopen for network)) scott@slp53.sl.home (Scott Lurndal) - 2026-06-27 18:50 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) scott@slp53.sl.home (Scott Lurndal) - 2026-06-23 17:39 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) David Brown <david.brown@hesbynett.no> - 2026-06-23 21:11 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-24 11:04 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) David Brown <david.brown@hesbynett.no> - 2026-06-24 15:27 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-25 11:56 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) David Brown <david.brown@hesbynett.no> - 2026-06-25 21:30 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-27 02:22 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) David Brown <david.brown@hesbynett.no> - 2026-06-28 18:59 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-07 23:19 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) scott@slp53.sl.home (Scott Lurndal) - 2026-07-08 14:52 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) David Brown <david.brown@hesbynett.no> - 2026-07-08 20:56 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) scott@slp53.sl.home (Scott Lurndal) - 2026-06-24 15:51 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-23 14:44 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Michael S <already5chosen@yahoo.com> - 2026-06-23 22:30 +0300
Re: this guy talks about fopen (and im thinking about fopen for network) Michael S <already5chosen@yahoo.com> - 2026-06-23 22:48 +0300
Re: this guy talks about fopen (and im thinking about fopen for network) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-24 12:18 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) Michael S <already5chosen@yahoo.com> - 2026-06-24 22:00 +0300
Re: this guy talks about fopen (and im thinking about fopen for network) scott@slp53.sl.home (Scott Lurndal) - 2026-06-24 20:09 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) Michael S <already5chosen@yahoo.com> - 2026-06-25 00:25 +0300
Re: this guy talks about fopen (and im thinking about fopen for network) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-25 12:00 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) scott@slp53.sl.home (Scott Lurndal) - 2026-06-25 15:37 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) pa@see.signature.invalid (Pierre Asselin) - 2026-06-24 21:21 +0000
Time from official time-services (was Re: ...some arbitrary subject...) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-28 00:15 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-19 16:31 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) Bart <bc@freeuk.com> - 2026-06-19 17:50 +0100
Re: this guy talks about fopen (and im thinking about fopen for network) scott@slp53.sl.home (Scott Lurndal) - 2026-06-19 18:54 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-19 19:58 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) Bart <bc@freeuk.com> - 2026-06-19 21:15 +0100
Re: this guy talks about fopen (and im thinking about fopen for network) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-19 22:09 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-20 03:00 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-19 10:33 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Bart <bc@freeuk.com> - 2026-06-19 19:04 +0100
Re: this guy talks about fopen (and im thinking about fopen for network) scott@slp53.sl.home (Scott Lurndal) - 2026-06-19 18:55 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) Bart <bc@freeuk.com> - 2026-06-19 21:07 +0100
Re: this guy talks about fopen (and im thinking about fopen for network) David Brown <david.brown@hesbynett.no> - 2026-06-20 13:53 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-06-20 19:25 -0400
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-19 22:49 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) BGB <cr88192@gmail.com> - 2026-06-19 18:06 -0500
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-19 06:59 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) BGB <cr88192@gmail.com> - 2026-06-19 14:47 -0500
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-19 22:47 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) David Brown <david.brown@hesbynett.no> - 2026-06-20 14:02 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-19 02:21 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-19 09:59 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-09 00:26 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) Kaz Kylheku <046-301-5902@kylheku.com> - 2026-06-09 21:21 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-10 12:28 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) Bonita Montero <Bonita.Montero@gmail.com> - 2026-06-11 07:24 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) Bonita Montero <Bonita.Montero@gmail.com> - 2026-06-14 14:44 +0200
Page 6 of 10 — ← Prev page 1 … 4 5 [6] 7 8 … 10 Next page →
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-19 16:18 +0000 |
| Message-ID | <1113q46$rp8$1@reader1.panix.com> |
| In reply to | #400123 |
In article <1113jni$3cklj$1@dont-email.me>, Bart <bc@freeuk.com> wrote:
>On 19/06/2026 11:18, Dan Cross wrote:
>> In article <11132u8$37hrh$1@dont-email.me>, Bart <bc@freeuk.com> wrote:
>>> On 19/06/2026 07:56, David Brown wrote:
>>>> On 19/06/2026 08:20, BGB wrote:
>>>>> On 6/18/2026 6:06 PM, Lawrence D’Oliveiro wrote:
>>>>>> On Thu, 18 Jun 2026 03:49:55 -0500, BGB wrote:
>>>>>>
>>>>>>> Just that it is also not a huge leap from:
>>>>>>> tcp://whatever
>>>>>>> udp://whatever
>>>>>>> http://whatever
>>>>>>> ftp://whatever
>>>>>>> ...
>>>>>>> To:
>>>>>>> c:/whatever...
>>>>>>
>>>>>> Yes it is.
>>>>>>
>>>>>> In the former, that part before the colon is a protocol. In the
>>>>>> latter, it is now down to just indicating a filesystem drive. And not
>>>>>> even in a unique fashion, like with a volume UUID or something, but
>>>>>> with an arbitarily-assigned “drive letter” which cannot be guaranteed
>>>>>> to be unique or persistent.
>>>>>>
>>>>>
>>>>> Well, on older Windows.
>>>>>
>>>>> On newer systems, the OS remembers and will assign the same drives to
>>>>> the same letter on each boot.
>>>>>
>>>>
>>>> I am not sure what you call "newer", but IIRC Windows has done that
>>>> since Windows 3.1. The only letters you could assign yourself were for
>>>> network drives, and they were persistent if you choose "persistent=yes".
>>>>
>>>> Later versions of Windows (maybe NT4 or W2K? I can't remember the
>>>> details) let you choose the letter to use for other drives, such as
>>>> additional harddrives, CD-ROMs and later still, USB drives. Those
>>>> choices were persistent.
>>>>
>>>> Automatically chosen drive letters were, of course, inconsistent. And
>>>> when you have a lot of drives and network shares, they run out.
>>>>
>>>>>
>>>>> But, yeah, probably wouldn't do it the Windows way. Either they could
>>>>> be specified as mounts (in mtab or such), or possibly treated as
>>>>> aliases, say:
>>>>> c:/ aliases to /mnt/c
>>>>
>>>> Drive letters make sense when users wanted to distinguish between their
>>>> 3.5" floppy "A:" and their 5.25" floppy "B:". They were still usable
>>>> when you had a hard drive with one partition. Once it was realistic to
>>>> have two drives in the one PC, and more than one partition on a disk,
>>>> they were outdated and too restrictive for comfort.
>>>
>>> How would you distinguish between two floppy drives on a Unix-like file
>>> system?
>>
>> Based on the directory name where you mount them.
>>
>>> If writing a common shell script for other people to use on their own
>>> machines, would you be able to use the same designations?
>>
>> You don't. You parameterize it. Why would I want to restrict a
>> shell script to only working with the contents of floppy disks?
>>
>> Obligatory plan 9 example:
>>
>> cpu% grep floppy /dev/drivers
>> #f floppy
>> cpu% ls '#f'
>> '#f/fd0ctl'
>> '#f/fd0disk'
>> '#f/fd1ctl'
>> '#f/fd1disk'
>> cpu% bind -a '#f' /dev
>> cpu% ls -l /dev/fd0disk
>> --rw-rw---- f 0 bootes bootes 1474560 Sep 20 2021 /dev/fd0disk
>> cpu% dossrv
>> dossrv: serving #s/dos
>> cpu% mount -c /srv/dos /n/floppy0 /dev/fd0disk
>> cpu% mount -c /srv/dos /n/floppy1 /dev/fd1disk
>> cpu%
>>
>> This was all wrapped up into a shell script:
>>
>> cpu% cat /bin/a:
>> #!/bin/rc
>> rfork e
>> flop=/dev/fd0disk
>> if(! test -r $flop)
>> flop='#f'/fd0disk
>> if(! test -f /srv/dos)
>> dossrv >/dev/null </dev/null >[2]/dev/null
>> unmount /n/a:>[2]/dev/null
>> mount -c /srv/dos /n/a: $flop
>> unmount /n/a >[2]/dev/null
>> mount -c /srv/dos /n/a $flop
>> cpu%
>>
>> The floppy device is built into the kernel. The names relative
>> to `/n` are arbitrary; the contents of both floppies are now
>> available on /n/floppy0 and /n/floppy1 respectively. `dossrv`
>> is a program that implements a few variations of FAT
>> filesystems.
>
>Machines that used floppy disks with drive letters tended to be used by
>non-technical members of the public.
>
>If I was doing technical support on the phone (which I actually did),
>what would I tell someone to type in to refer to say the leftmost of
>their two floppy drives:
Move the goalposts much? I was responding to a comment about a
shell script and Unix, not doing technical support over a
telephone for non-technical people.
That said....
>Would it actually be "/n/floppy0", or would that depend on what had been
>set up the client's specific machine? I assume it would have to be all
>in the right case too?
>
>The beauty of letter designations is that you just say 'type A colon';
>it doesn't matter if they do A: or a: either as those OSes tended to be
>case-insensitive.
I mentioned that Plan 9 wrapped all of this up into a shell
script that they called (I think somewhat ironically, `a:`). So
what you would say is, "type 'a:'...now type 'cd /n/a'". Not
that much different.
>This was also long before Windows, in my case on a CP/M clone.
I have been fortunate to not have to use Windows very much
throughout my career. That said, some of their kernel people
are amazing engineers.
>> The key observation is that shoehorning everything into `open`
>> is the wrong model; instead, conceptually splitting into
>> separate `mount` and access operations simplifies and permits
>> composition. Making `mount` unprivileged and allowing the user
>> to control their view of the file namespace makes all of this
>> natural.
>
>'Mount' wasn't a thing on those machines. It was usually plug-and-play.
The original question had to do with `fopen`; someone brought up
Unix and shell scripts; I have no idea why you're talking about
CP/M, which copied DEC OSes.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-06-19 18:07 +0100 |
| Message-ID | <1113t1c$3f4nm$2@dont-email.me> |
| In reply to | #400126 |
On 19/06/2026 17:18, Dan Cross wrote: > In article <1113jni$3cklj$1@dont-email.me>, Bart <bc@freeuk.com> wrote: >> On 19/06/2026 11:18, Dan Cross wrote: >>> In article <11132u8$37hrh$1@dont-email.me>, Bart <bc@freeuk.com> wrote: >>>> On 19/06/2026 07:56, David Brown wrote: >>>>> Drive letters make sense when users wanted to distinguish between their >>>>> 3.5" floppy "A:" and their 5.25" floppy "B:". They were still usable >>>>> when you had a hard drive with one partition. Once it was realistic to >>>>> have two drives in the one PC, and more than one partition on a disk, >>>>> they were outdated and too restrictive for comfort. >>>> >>>> How would you distinguish between two floppy drives on a Unix-like file >>>> system? >>> The floppy device is built into the kernel. The names relative >>> to `/n` are arbitrary; the contents of both floppies are now >>> available on /n/floppy0 and /n/floppy1 respectively. `dossrv` >>> is a program that implements a few variations of FAT >>> filesystems. >> >> Machines that used floppy disks with drive letters tended to be used by >> non-technical members of the public. >> >> If I was doing technical support on the phone (which I actually did), >> what would I tell someone to type in to refer to say the leftmost of >> their two floppy drives: > > Move the goalposts much? I haven't moved them at all. Someone made remarks about the scheme to designate drives with letters, which is very simple and which everyone could understand. I asked how that would have been done under Unix. Apparently, with some difficulty; you needed to be an expert (well, working under Unix seems to involve an awful lot of configuring anyway), and it's not even clear who has to do do all that: me, or my client. So my example showed that was it simpler to use the drive-letter scheme, and out-of-the box; you don't need to /make/ it 'simple'. > I was responding to a comment about a > shell script and Unix, not doing technical support over a > telephone for non-technical people. And the shell script presumably was part-answer to my question about what replaces A: and B: on Unix. >> This was also long before Windows, in my case on a CP/M clone. > > I have been fortunate to not have to use Windows very much > throughout my career. I've been even more fortunate in never needing to use Unix at all, although I tried a few times. > The original question had to do with `fopen`; someone brought up > Unix and shell scripts; I have no idea why you're talking about > CP/M, which copied DEC OSes. Because the earlier discussion was talking about Windows and drive letters were associated with Windows, so I made the point that they go back a lot further. Since people always like to stick it to Windows. But I've used a couple of DEC OSes and don't remember drive letters. Google AI tells me: "Drive letters originate from the CP/M operating system in the 1970s and were popularized by MS-DOS."
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-06-19 18:51 +0000 |
| Message-ID | <UcgZR.162791$WQ_e.147322@fx14.iad> |
| In reply to | #400129 |
Bart <bc@freeuk.com> writes: >On 19/06/2026 17:18, Dan Cross wrote: >> In article <1113jni$3cklj$1@dont-email.me>, Bart <bc@freeuk.com> wrote: <snip discussion of unix floppy disks> >>> If I was doing technical support on the phone (which I actually did), >>> what would I tell someone to type in to refer to say the leftmost of >>> their two floppy drives: >> >> Move the goalposts much? > >I haven't moved them at all. Someone made remarks about the scheme to >designate drives with letters, which is very simple and which everyone >could understand. "Someone" named Bart, per chance?
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-06-19 21:04 +0100 |
| Message-ID | <11147bp$3ioc8$1@dont-email.me> |
| In reply to | #400133 |
On 19/06/2026 19:51, Scott Lurndal wrote: > Bart <bc@freeuk.com> writes: >> On 19/06/2026 17:18, Dan Cross wrote: >>> In article <1113jni$3cklj$1@dont-email.me>, Bart <bc@freeuk.com> wrote: > > <snip discussion of unix floppy disks> > >>>> If I was doing technical support on the phone (which I actually did), >>>> what would I tell someone to type in to refer to say the leftmost of >>>> their two floppy drives: >>> >>> Move the goalposts much? >> >> I haven't moved them at all. Someone made remarks about the scheme to >> designate drives with letters, which is very simple and which everyone >> could understand. > > "Someone" named Bart, per chance? > Actually, no it wasn't. Why don't you read the fucking thread rather than make false accusations?
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-19 19:55 +0000 |
| Message-ID | <11146qu$2pj$1@reader1.panix.com> |
| In reply to | #400129 |
In article <1113t1c$3f4nm$2@dont-email.me>, Bart <bc@freeuk.com> wrote:
>On 19/06/2026 17:18, Dan Cross wrote:
>> In article <1113jni$3cklj$1@dont-email.me>, Bart <bc@freeuk.com> wrote:
>>> On 19/06/2026 11:18, Dan Cross wrote:
>>>> In article <11132u8$37hrh$1@dont-email.me>, Bart <bc@freeuk.com> wrote:
>>>>> On 19/06/2026 07:56, David Brown wrote:
>
>>>>>> Drive letters make sense when users wanted to distinguish between their
>>>>>> 3.5" floppy "A:" and their 5.25" floppy "B:". They were still usable
>>>>>> when you had a hard drive with one partition. Once it was realistic to
>>>>>> have two drives in the one PC, and more than one partition on a disk,
>>>>>> they were outdated and too restrictive for comfort.
>>>>>
>>>>> How would you distinguish between two floppy drives on a Unix-like file
>>>>> system?
>
>>>> The floppy device is built into the kernel. The names relative
>>>> to `/n` are arbitrary; the contents of both floppies are now
>>>> available on /n/floppy0 and /n/floppy1 respectively. `dossrv`
>>>> is a program that implements a few variations of FAT
>>>> filesystems.
>>>
>>> Machines that used floppy disks with drive letters tended to be used by
>>> non-technical members of the public.
>>>
>>> If I was doing technical support on the phone (which I actually did),
>>> what would I tell someone to type in to refer to say the leftmost of
>>> their two floppy drives:
>>
>> Move the goalposts much?
>
>I haven't moved them at all. Someone made remarks about the scheme to
>designate drives with letters, which is very simple and which everyone
>could understand.
>
>I asked how that would have been done under Unix. Apparently, with some
>difficulty; you needed to be an expert (well, working under Unix seems
>to involve an awful lot of configuring anyway), and it's not even clear
>who has to do do all that: me, or my client.
It doesn't seem difficult to me, but I recognize that that is
subjective.
>So my example showed that was it simpler to use the drive-letter scheme,
>and out-of-the box; you don't need to /make/ it 'simple'.
You do realize that that is subjective, right? Hopefully we
don't devolve into another discussion about the meaning of that
word (or how it's different from objective), but calling it
"simpler" is your opinion.
...and do you know how much engineering goes into that "out of
the box" statement?
>> I was responding to a comment about a
>> shell script and Unix, not doing technical support over a
>> telephone for non-technical people.
>
>And the shell script presumably was part-answer to my question about
>what replaces A: and B: on Unix.
It's funny that I showed you a shell script that was actually
called `a:`.
>>> This was also long before Windows, in my case on a CP/M clone.
>>
>> I have been fortunate to not have to use Windows very much
>> throughout my career.
>
>I've been even more fortunate in never needing to use Unix at all,
>although I tried a few times.
Its ok; not everybody is cut out for using it.
>> The original question had to do with `fopen`; someone brought up
>> Unix and shell scripts; I have no idea why you're talking about
>> CP/M, which copied DEC OSes.
>
>Because the earlier discussion was talking about Windows and drive
>letters were associated with Windows, so I made the point that they go
>back a lot further. Since people always like to stick it to Windows.
>
>But I've used a couple of DEC OSes and don't remember drive letters.
>
>Google AI tells me: "Drive letters originate from the CP/M operating
>system in the 1970s and were popularized by MS-DOS."
I don't think I've ever seen an instance where Google's AI is
right the first time.
DEC OSes were noted for using unique identifiers for each
storage device. For instance, on VMS one might refer to a file
on a specific disk as `DKA1:[SOME.DIRECTORY]FILE.EXT;3`, meaning
version 3 of a file named "FILE.EXT" in "some directory"
relative to the start of the filesystem on device DKA1.
It is known that Gary Kildall used a DEC PDP-10 running TOPS-10
(a DECsystem-10 machine) to do the initial development of CP/M;
the semblance in some places is unmistakable (e.g., the `PIP`
command, `DIR`, etc). File specifications on TOPS-10 include a
device or structure name; see sec 1.4.2.4 of this reference:
https://bitsavers.org/pdf/dec/pdp10/TOPS10/1972_PDP-10_Users_Handbook/08_commands.pdf
`DSKA:PROG2.FOR` is a valid TOPS-10 file spec, for example,
Of course, none of this has anything to do with C.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-06-20 01:52 +0200 |
| Subject | [OT] Google AI - behavioral analysis (was: [something else]) |
| Message-ID | <1114knh$305a3$1@dont-email.me> |
| In reply to | #400137 |
This post is, as seen in the subject, off-topic and rather longish.
Persons that have problems with such posts better leave here. :-)
On 2026-06-19 21:55, Dan Cross wrote:
> In article <1113t1c$3f4nm$2@dont-email.me>, Bart <bc@freeuk.com> wrote:
>> [...]
>>
>> Google AI tells me: "[...]"
>
> I don't think I've ever seen an instance where Google's AI is
> right the first time.
Sorry, but that "the first time" triggered a recent experience and
that statement should be refined; it fails even after issuing many
"doubting statements". I admit that I deliberately stressed the AI
after my first (seriously asked) question. - See it as "behavioral
analysis". ;-)
That recent request was _simple_; I'd asked for the north-south
orientation of a specific football stadium. The dialog was like
that (here much abbreviated, not literally, to see the pattern):
Q: north-south orientation of that stadium
A: that stadium is exactly N-S-oriented
(The AI claims even "exactly"; on maps you see that's wrong.)
Q: it's not exactly N-S-oriented
A: the orientation deviates by almost 14 deg to N-NE
(Now there's numbers and some [wrong] orientation.)
Q: the orientation does not deviate by almost 14 deg to N-NE
A: right, I [the AI] was again unprecise,
the orientation is N-NW about 11-14 deg
(N-NE became now N-NW, and that [wrong] number a [wrong] range.)
(The AI formulates former answers as being just "unprecise".)
At this point I used a map and Gimp and determined the orientation
myself as N-NW and 15.25 deg. - Okay, so give it a final kick...
Q: the orientation is not N-NW about 11-14 deg
A: (prompt to be heavily "thinking", and after many seconds ...)
I'll abstain from assumptions here and focus on provable facts
instead of constantly admitting you every orientation change
("Facts", even "provable"! And sort of a "pissed" comment; the AI
"doesn't like" its answers being doubted. :-)
(Its last line was indeed such a semantically strange formulation.)
In fact the last answer was a lot bulkier since it lists all sorts
of "facts" that have never been asked for. But that simple correct
fact I had asked for I've *never* got.
Note: I deliberately just negated the AI's wrong answers instead of
asking differently; the original question had been clearly defined,
and I didn't want to manipulate the AI's "response path" to trigger
yet more and other hallucinated "facts".
It's not only that it regularly produces wrong answers, and that it
presents them as facts, it also doesn't converge to a right answer
to a simple question on a mundane fact. It prefers hallucinating.
And Bart (and a few others) seriously tells us:
>> Google AI tells me: "[...]"
What that really tells us is obviously something about AI-believers.
Janis
> [...]
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-06-20 03:03 +0000 |
| Message-ID | <1114vub$3odnn$5@dont-email.me> |
| In reply to | #400129 |
On Fri, 19 Jun 2026 18:07:57 +0100, Bart wrote: > But I've used a couple of DEC OSes and don't remember drive letters. > > Google AI tells me: "Drive letters originate from the CP/M operating > system in the 1970s and were popularized by MS-DOS." DEC OSes had multi-character device names. Gary Kildall copied the idea (one of many) into CP/M, but simplified them down to single letters, just for the disk drives. Because who would want more than 26 drives on a single 8-bit machine, right? And then somebody invented “reserved” file names for non-disk devices (e.g. serial ports). For some reason, Microsoft still thinks “26 drive letters ought to be enough for anybody” ... And those “reserved” file names also continue to plague Windows today ...
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-06-19 18:50 +0000 |
| Message-ID | <CbgZR.162790$WQ_e.34751@fx14.iad> |
| In reply to | #400126 |
cross@spitfire.i.gajendra.net (Dan Cross) writes: >In article <1113jni$3cklj$1@dont-email.me>, Bart <bc@freeuk.com> wrote: > >>This was also long before Windows, in my case on a CP/M clone. > >I have been fortunate to not have to use Windows very much >throughout my career. That said, some of their kernel people >are amazing engineers. At least one of them used to be one of the architects of SVR4.2 ES/MP. (Enhanced Security, Multiprocessor). I think he may still be there. > >>> The key observation is that shoehorning everything into `open` >>> is the wrong model; instead, conceptually splitting into >>> separate `mount` and access operations simplifies and permits >>> composition. Making `mount` unprivileged and allowing the user >>> to control their view of the file namespace makes all of this >>> natural. >> >>'Mount' wasn't a thing on those machines. It was usually plug-and-play. > >The original question had to do with `fopen`; someone brought up >Unix and shell scripts; I have no idea why you're talking about >CP/M, which copied DEC OSes. It's Bart, the master of the non sequitor.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-06-19 13:46 +0200 |
| Message-ID | <1113a7i$398t8$1@dont-email.me> |
| In reply to | #400120 |
On 19/06/2026 11:42, Bart wrote: > On 19/06/2026 07:56, David Brown wrote: >> On 19/06/2026 08:20, BGB wrote: >>> On 6/18/2026 6:06 PM, Lawrence D’Oliveiro wrote: >>>> On Thu, 18 Jun 2026 03:49:55 -0500, BGB wrote: >>>> >>>>> Just that it is also not a huge leap from: >>>>> tcp://whatever >>>>> udp://whatever >>>>> http://whatever >>>>> ftp://whatever >>>>> ... >>>>> To: >>>>> c:/whatever... >>>> >>>> Yes it is. >>>> >>>> In the former, that part before the colon is a protocol. In the >>>> latter, it is now down to just indicating a filesystem drive. And not >>>> even in a unique fashion, like with a volume UUID or something, but >>>> with an arbitarily-assigned “drive letter” which cannot be guaranteed >>>> to be unique or persistent. >>>> >>> >>> Well, on older Windows. >>> >>> On newer systems, the OS remembers and will assign the same drives to >>> the same letter on each boot. >>> >> >> I am not sure what you call "newer", but IIRC Windows has done that >> since Windows 3.1. The only letters you could assign yourself were >> for network drives, and they were persistent if you choose >> "persistent=yes". >> >> Later versions of Windows (maybe NT4 or W2K? I can't remember the >> details) let you choose the letter to use for other drives, such as >> additional harddrives, CD-ROMs and later still, USB drives. Those >> choices were persistent. >> >> Automatically chosen drive letters were, of course, inconsistent. And >> when you have a lot of drives and network shares, they run out. >> >>> >>> But, yeah, probably wouldn't do it the Windows way. Either they could >>> be specified as mounts (in mtab or such), or possibly treated as >>> aliases, say: >>> c:/ aliases to /mnt/c >> >> Drive letters make sense when users wanted to distinguish between >> their 3.5" floppy "A:" and their 5.25" floppy "B:". They were still >> usable when you had a hard drive with one partition. Once it was >> realistic to have two drives in the one PC, and more than one >> partition on a disk, they were outdated and too restrictive for comfort. > > How would you distinguish between two floppy drives on a Unix-like file > system? To be honest, I have never come across the need. In my university days (with SunOS, then Solaris) the machines did not have floppies - most did not even have hard disks. By the time I started using Linux, at about the turn of the century, floppies were out of fashion. > > If writing a common shell script for other people to use on their own > machines, would you be able to use the same designations? > Filesystems are mounted on *nix systems. The exact placement of mount points varies, as does the extent to which attached filesystems are automounted, or the user is informed and given a choice, or mounting is manual. Different *nix systems have different habits, and in Linux it can vary by distro or desktop. And then administrators or users can have their own choices. Hardware is different - if I need to use a floppy these days, it would be via a USB floppy drive. More realistically, people would use USB memory sticks now. But someone might have several USB mass storage devices attached - I would not presume to know which they want to use for this script or program. So I would say the script should either require a path (for file / directory access - and I can't think why it would be limited to a floppy), or a device name (for something like a flash image writer). It would likely be better to have a gui or menu choice for some programs. Getting lists of the available block devices, mounted systems, filesystem types, etc., and detailed information about the devices, is not hard on Linux - but I don't know how portable that might be to other *nix systems.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-06-19 15:49 +0100 |
| Message-ID | <1113kuc$3cklj$2@dont-email.me> |
| In reply to | #400122 |
On 19/06/2026 12:46, David Brown wrote: > On 19/06/2026 11:42, Bart wrote: >> On 19/06/2026 07:56, David Brown wrote: >>> On 19/06/2026 08:20, BGB wrote: >>>> On 6/18/2026 6:06 PM, Lawrence D’Oliveiro wrote: >>>>> On Thu, 18 Jun 2026 03:49:55 -0500, BGB wrote: >>>>> >>>>>> Just that it is also not a huge leap from: >>>>>> tcp://whatever >>>>>> udp://whatever >>>>>> http://whatever >>>>>> ftp://whatever >>>>>> ... >>>>>> To: >>>>>> c:/whatever... >>>>> >>>>> Yes it is. >>>>> >>>>> In the former, that part before the colon is a protocol. In the >>>>> latter, it is now down to just indicating a filesystem drive. And not >>>>> even in a unique fashion, like with a volume UUID or something, but >>>>> with an arbitarily-assigned “drive letter” which cannot be guaranteed >>>>> to be unique or persistent. >>>>> >>>> >>>> Well, on older Windows. >>>> >>>> On newer systems, the OS remembers and will assign the same drives >>>> to the same letter on each boot. >>>> >>> >>> I am not sure what you call "newer", but IIRC Windows has done that >>> since Windows 3.1. The only letters you could assign yourself were >>> for network drives, and they were persistent if you choose >>> "persistent=yes". >>> >>> Later versions of Windows (maybe NT4 or W2K? I can't remember the >>> details) let you choose the letter to use for other drives, such as >>> additional harddrives, CD-ROMs and later still, USB drives. Those >>> choices were persistent. >>> >>> Automatically chosen drive letters were, of course, inconsistent. >>> And when you have a lot of drives and network shares, they run out. >>> >>>> >>>> But, yeah, probably wouldn't do it the Windows way. Either they >>>> could be specified as mounts (in mtab or such), or possibly treated >>>> as aliases, say: >>>> c:/ aliases to /mnt/c >>> >>> Drive letters make sense when users wanted to distinguish between >>> their 3.5" floppy "A:" and their 5.25" floppy "B:". They were still >>> usable when you had a hard drive with one partition. Once it was >>> realistic to have two drives in the one PC, and more than one >>> partition on a disk, they were outdated and too restrictive for comfort. >> >> How would you distinguish between two floppy drives on a Unix-like >> file system? > > To be honest, I have never come across the need. In my university days > (with SunOS, then Solaris) the machines did not have floppies - most did > not even have hard disks. By the time I started using Linux, at about > the turn of the century, floppies were out of fashion. > >> >> If writing a common shell script for other people to use on their own >> machines, would you be able to use the same designations? >> > > Filesystems are mounted on *nix systems. The exact placement of mount > points varies, as does the extent to which attached filesystems are > automounted, or the user is informed and given a choice, or mounting is > manual. Different *nix systems have different habits, and in Linux it > can vary by distro or desktop. And then administrators or users can > have their own choices. > > Hardware is different - if I need to use a floppy these days, it would > be via a USB floppy drive. More realistically, people would use USB > memory sticks now. But someone might have several USB mass storage > devices attached - I would not presume to know which they want to use > for this script or program. So I would say the script should either > require a path (for file / directory access - and I can't think why it > would be limited to a floppy), or a device name (for something like a > flash image writer). It would likely be better to have a gui or menu > choice for some programs. Getting lists of the available block devices, > mounted systems, filesystem types, etc., and detailed information about > the devices, is not hard on Linux - but I don't know how portable that > might be to other *nix systems. If you plug in a USB pen drive on Windows, it will be under a drive letter, but that it is not guaranteed to be consistent, especially if you plug in more than one. So that is a problem. It would be useful, IMV, if the USB sockets were labeled with specific letters. So, what's it like under Linux: if I plug a pen drive into my RPi, then the files will be at: /media/bart/EEBEBEBEC313CA9B Obviously. If I try another, then it's at /media/bart/NEW (note these are case-sensitive), and a third was at /media/bart/0159078ED. I assume that 'bart' is specific to my machine, so I can't assume anything if, say, I wanted to hardcode a path into a program or script that someone else runs. > > >
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-06-19 17:25 +0200 |
| Message-ID | <1113n0d$3db99$1@dont-email.me> |
| In reply to | #400124 |
On 19/06/2026 16:49, Bart wrote: > On 19/06/2026 12:46, David Brown wrote: >> On 19/06/2026 11:42, Bart wrote: >>> On 19/06/2026 07:56, David Brown wrote: >>>> On 19/06/2026 08:20, BGB wrote: >>>>> On 6/18/2026 6:06 PM, Lawrence D’Oliveiro wrote: >>>>>> On Thu, 18 Jun 2026 03:49:55 -0500, BGB wrote: >>>>>> >>>>>>> Just that it is also not a huge leap from: >>>>>>> tcp://whatever >>>>>>> udp://whatever >>>>>>> http://whatever >>>>>>> ftp://whatever >>>>>>> ... >>>>>>> To: >>>>>>> c:/whatever... >>>>>> >>>>>> Yes it is. >>>>>> >>>>>> In the former, that part before the colon is a protocol. In the >>>>>> latter, it is now down to just indicating a filesystem drive. And not >>>>>> even in a unique fashion, like with a volume UUID or something, but >>>>>> with an arbitarily-assigned “drive letter” which cannot be guaranteed >>>>>> to be unique or persistent. >>>>>> >>>>> >>>>> Well, on older Windows. >>>>> >>>>> On newer systems, the OS remembers and will assign the same drives >>>>> to the same letter on each boot. >>>>> >>>> >>>> I am not sure what you call "newer", but IIRC Windows has done that >>>> since Windows 3.1. The only letters you could assign yourself were >>>> for network drives, and they were persistent if you choose >>>> "persistent=yes". >>>> >>>> Later versions of Windows (maybe NT4 or W2K? I can't remember the >>>> details) let you choose the letter to use for other drives, such as >>>> additional harddrives, CD-ROMs and later still, USB drives. Those >>>> choices were persistent. >>>> >>>> Automatically chosen drive letters were, of course, inconsistent. >>>> And when you have a lot of drives and network shares, they run out. >>>> >>>>> >>>>> But, yeah, probably wouldn't do it the Windows way. Either they >>>>> could be specified as mounts (in mtab or such), or possibly treated >>>>> as aliases, say: >>>>> c:/ aliases to /mnt/c >>>> >>>> Drive letters make sense when users wanted to distinguish between >>>> their 3.5" floppy "A:" and their 5.25" floppy "B:". They were still >>>> usable when you had a hard drive with one partition. Once it was >>>> realistic to have two drives in the one PC, and more than one >>>> partition on a disk, they were outdated and too restrictive for >>>> comfort. >>> >>> How would you distinguish between two floppy drives on a Unix-like >>> file system? >> >> To be honest, I have never come across the need. In my university >> days (with SunOS, then Solaris) the machines did not have floppies - >> most did not even have hard disks. By the time I started using Linux, >> at about the turn of the century, floppies were out of fashion. >> >>> >>> If writing a common shell script for other people to use on their own >>> machines, would you be able to use the same designations? >>> >> >> Filesystems are mounted on *nix systems. The exact placement of mount >> points varies, as does the extent to which attached filesystems are >> automounted, or the user is informed and given a choice, or mounting >> is manual. Different *nix systems have different habits, and in Linux >> it can vary by distro or desktop. And then administrators or users >> can have their own choices. >> >> Hardware is different - if I need to use a floppy these days, it would >> be via a USB floppy drive. More realistically, people would use USB >> memory sticks now. But someone might have several USB mass storage >> devices attached - I would not presume to know which they want to use >> for this script or program. So I would say the script should either >> require a path (for file / directory access - and I can't think why it >> would be limited to a floppy), or a device name (for something like a >> flash image writer). It would likely be better to have a gui or menu >> choice for some programs. Getting lists of the available block >> devices, mounted systems, filesystem types, etc., and detailed >> information about the devices, is not hard on Linux - but I don't know >> how portable that might be to other *nix systems. > > If you plug in a USB pen drive on Windows, it will be under a drive > letter, but that it is not guaranteed to be consistent, especially if > you plug in more than one. > > So that is a problem. It would be useful, IMV, if the USB sockets were > labeled with specific letters. > That would be useful if you use a lot of different drives and plug them in and out a lot. But Windows can't handle anything like that. On Linux, setting up something like would be straightforward. In my work, I use a lot of USB serial cables, and have such a system set up so that when I (for example) plug one into port 3 on the hub I have on my electronics desk, it turns up as /dev/ttySerial_hub3. Doing something similar with usb drives would just be a few lines in a udev rules file. (It will look a bit like a magic incantation at first, but Google will lead you through it.) Sometimes I give specific names to specific cables independent of the physical address on the USB port tree - whatever is most useful for the situation. Compared to Windows machines with its pseudorandom system for assigning COM port numbers, it is a joy - especially on test machines when you find an old device suddenly gets COM port number 129 and the test software only shows a list up to COM port 128. (That is not a made-up story.) > So, what's it like under Linux: if I plug a pen drive into my RPi, then > the files will be at: > > /media/bart/EEBEBEBEC313CA9B > > Obviously. If I try another, then it's at /media/bart/NEW (note these > are case-sensitive), and a third was at /media/bart/0159078ED. > The names are not random - they are the filesystem labels. So if you have a USB stick and you have given the filesystem (vfat, ntfs, ext4, whatever you like) the label "Bart's files", then it will turn up with that directory name. If you haven't done anything to a new off-the-shelf drive, it will use the filesystem label provided by the manufacturer, or probably something like a serial number or block device UUID if the label is missing. Crucially, it will be consistent for the same drive (unless you rename it manually). > I assume that 'bart' is specific to my machine, so I can't assume > anything if, say, I wanted to hardcode a path into a program or script > that someone else runs. > "bart" is your username. When a user is logged on to a relatively full-featured desktop, as commonly used on Linux workstations, it is assumed that it is the current logged-on desktop user that has plugged in the device, and it is mounted in a directory private to them. Other options are easily possible if that does not fit your needs.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-06-21 01:42 +0300 |
| Message-ID | <20260621014240.00005562@yahoo.com> |
| In reply to | #400125 |
On Fri, 19 Jun 2026 17:25:01 +0200 David Brown <david.brown@hesbynett.no> wrote: > > Compared to Windows machines with its pseudorandom system for > assigning COM port numbers, There is a system in the madness. Behavior depends on either your USB-to-serial device has USB serial Id or lacks it. If it has Id then the same port will be assigned to the same device regardless of the USB port that device plugged in this time. Otherwise port number is assigned per USB port. Mostly. Cheap FTDI clones tend to not implement serial ID. Silicon Lab based converters tends to be of better quality, not just relatively to clones, but also relatively to genuine FTDI controllers.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-06-21 12:18 +0200 |
| Message-ID | <1118dpv$nb9j$1@dont-email.me> |
| In reply to | #400165 |
On 21/06/2026 00:42, Michael S wrote: > On Fri, 19 Jun 2026 17:25:01 +0200 > David Brown <david.brown@hesbynett.no> wrote: > >> >> Compared to Windows machines with its pseudorandom system for >> assigning COM port numbers, > > There is a system in the madness. Behavior depends on either your > USB-to-serial device has USB serial Id or lacks it. > If it has Id then the same port will be assigned to the same device > regardless of the USB port that device plugged in this time. > Otherwise port number is assigned per USB port. Mostly. > It is the "mostly" that is the killer. The port numbers are usually stable if you plug the same devices into the same physical ports. But sometimes if you have had a number of new devices attached in the meantime, then go back to the old ones, Windows might forget the previous numbers, or even re-use them, and your old devices get new numbers. Mixing devices from different manufacturers appears to make things worse, but I have not done extensive trials. If you just have a few devices that you use regularly, it's okay - so for most of our developers the port numbers don't get too high within the lifetime of a useable Windows system. For some test machines it's a different matter - when you build boards with a USB-to-serial chip onboard, if those chips have serial numbers then you chew through COM port numbers at an alarming rate. It is just one of many reasons why we usually try to use Linux (especially Pi's) for test machines. > Cheap FTDI clones tend to not implement serial ID. > Silicon Lab based converters tends to be of better quality, not just > relatively to clones, but also relatively to genuine FTDI controllers. > > I don't remember ever using an FTDI clone - FTDI devices and cables are not expensive enough for it to make sense for us. And FTDI devices have worked fine for our needs. I have used a few Silicon Labs devices too, but I don't see anything to suggest they are "better quality" - pretty much every USB-to-serial converter from every manufacturer works fine and does its job. Some do cause more pain with Windows then others, with different drivers and requirements, but that's Windows and/or driver problems, and usually those problems are surmountable. In the end, it is usually up to the customer - if they want a USB-to-serial converter on their board, and they've picked a type, that's what they get. Given a free choice, we generally go for FTDI ourselves. (Most common is that boards have a simple header with TTL signals and we use an external FTDI cable - the biggest use of serial ports between boards and PC's is for debugging and testing.)
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-06-21 23:15 +0300 |
| Message-ID | <20260621231554.000008db@yahoo.com> |
| In reply to | #400170 |
On Sun, 21 Jun 2026 12:18:39 +0200 David Brown <david.brown@hesbynett.no> wrote: > On 21/06/2026 00:42, Michael S wrote: > > On Fri, 19 Jun 2026 17:25:01 +0200 > > David Brown <david.brown@hesbynett.no> wrote: > > > >> > >> Compared to Windows machines with its pseudorandom system for > >> assigning COM port numbers, > > > > There is a system in the madness. Behavior depends on either your > > USB-to-serial device has USB serial Id or lacks it. > > If it has Id then the same port will be assigned to the same device > > regardless of the USB port that device plugged in this time. > > Otherwise port number is assigned per USB port. Mostly. > > > > It is the "mostly" that is the killer. > > The port numbers are usually stable if you plug the same devices into > the same physical ports. But sometimes if you have had a number of > new devices attached in the meantime, then go back to the old ones, > Windows might forget the previous numbers, or even re-use them, and > your old devices get new numbers. Mixing devices from different > manufacturers appears to make things worse, but I have not done > extensive trials. > > If you just have a few devices that you use regularly, it's okay - so > for most of our developers the port numbers don't get too high within > the lifetime of a useable Windows system. For some test machines > it's a different matter - when you build boards with a USB-to-serial > chip onboard, if those chips have serial numbers then you chew > through COM port numbers at an alarming rate. It is just one of many > reasons why we usually try to use Linux (especially Pi's) for test > machines. > Serial device API of Linux (inherited from early Unixes) is too kludgy to my liking. Why oh why do they think that serial port somehow has to be related to terminal ?! Windows API makes more sense. The difference mattered in the past, when we had to implement SCADA-style protocols on PC host. Fortunately, we do not doing it any longer. > > Cheap FTDI clones tend to not implement serial ID. > > Silicon Lab based converters tends to be of better quality, not just > > relatively to clones, but also relatively to genuine FTDI > > controllers. > > > > > > I don't remember ever using an FTDI clone - FTDI devices and cables > are not expensive enough for it to make sense for us. And FTDI > devices have worked fine for our needs. I have used a few Silicon > Labs devices too, but I don't see anything to suggest they are > "better quality" - pretty much every USB-to-serial converter from > every manufacturer works fine and does its job. I wish it was true. Unfortunately I had seen misdesigned hardware more than one time, including hardware from major manufactorer, like Aten. One case I can not forget is USB-1.1 device that claimed to support 912 Kbps, but had 64-byte recieve and transmit queues. Of course, USB polling rate is 1KHz, so it can't work even in theory, much less in practice. > Some do cause more > pain with Windows then others, with different drivers and > requirements, but that's Windows and/or driver problems, and usually > those problems are surmountable. In the end, it is usually up to the > customer - if they want a USB-to-serial converter on their board, and > they've picked a type, that's what they get. Given a free choice, we > generally go for FTDI ourselves. (Most common is that boards have a > simple header with TTL signals and we use an external FTDI cable - > the biggest use of serial ports between boards and PC's is for > debugging and testing.) > As long as requirements are minimal, everything goes. Try something just a little bit more demanding, like programming flash on ST or TI microcontroller by means of vendor-supplied utility, and many USB-to-serial converters will cause you problems.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-06-22 04:33 +0000 |
| Message-ID | <111adu3$vtir$3@paganini.bofh.team> |
| In reply to | #400173 |
Michael S <already5chosen@yahoo.com> wrote:
> On Sun, 21 Jun 2026 12:18:39 +0200
> David Brown <david.brown@hesbynett.no> wrote:
>
>> On 21/06/2026 00:42, Michael S wrote:
>> > On Fri, 19 Jun 2026 17:25:01 +0200
>> > David Brown <david.brown@hesbynett.no> wrote:
>> >
>> > Cheap FTDI clones tend to not implement serial ID.
>> > Silicon Lab based converters tends to be of better quality, not just
>> > relatively to clones, but also relatively to genuine FTDI
>> > controllers.
>> >
>> >
>>
>> I don't remember ever using an FTDI clone - FTDI devices and cables
>> are not expensive enough for it to make sense for us. And FTDI
>> devices have worked fine for our needs. I have used a few Silicon
>> Labs devices too, but I don't see anything to suggest they are
>> "better quality" - pretty much every USB-to-serial converter from
>> every manufacturer works fine and does its job.
IME at high speed different converters behave differently
and that can make difference between say dropping connection
and working OK. Also, theoretically supported speeds and
working ones may differ (higher speed may work while theoretically
supported lower speed may fail to work).
> I wish it was true.
> Unfortunately I had seen misdesigned hardware more than one time,
> including hardware from major manufactorer, like Aten.
> One case I can not forget is USB-1.1 device that claimed to support
> 912 Kbps, but had 64-byte recieve and transmit queues. Of course, USB
> polling rate is 1KHz, so it can't work even in theory, much less in
> practice.
1.1 device plugged in via 2.0 hub uses 8KHz polling rate (at least
Linux drivers seem to use this rate). There is measurable difference
in available throughput between converter connected directly to
USB port and converter connected as only device in 2.0 hub.
Theoretically driver could poll 1.1 device more frequently than 1KHz,
but apparently it is not doing this without appropriate hardware
support (like intermediate 2.0 hub).
AFAICS 912 Kbps claim is about speed on serial wire, what you get
trough USB may be lower. But even if you can not get full
throughput higher speed on serial wire may be useful.
>> Some do cause more
>> pain with Windows then others, with different drivers and
>> requirements, but that's Windows and/or driver problems, and usually
>> those problems are surmountable. In the end, it is usually up to the
>> customer - if they want a USB-to-serial converter on their board, and
>> they've picked a type, that's what they get. Given a free choice, we
>> generally go for FTDI ourselves. (Most common is that boards have a
>> simple header with TTL signals and we use an external FTDI cable -
>> the biggest use of serial ports between boards and PC's is for
>> debugging and testing.)
>>
>
> As long as requirements are minimal, everything goes.
> Try something just a little bit more demanding, like programming flash
> on ST or TI microcontroller by means of vendor-supplied utility, and
> many USB-to-serial converters will cause you problems.
I did this only few times (normally I use ST-Link) and on Linux side
I used non-ST tool, but each time it worked fine. But in general
I agree, I saw problems in some cases and people tell me that
there are problems in some other cases that I did not try.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-06-22 10:01 +0200 |
| Message-ID | <111aq54$1bt9t$1@dont-email.me> |
| In reply to | #400173 |
On 21/06/2026 22:15, Michael S wrote: > On Sun, 21 Jun 2026 12:18:39 +0200 > David Brown <david.brown@hesbynett.no> wrote: > >> On 21/06/2026 00:42, Michael S wrote: >>> On Fri, 19 Jun 2026 17:25:01 +0200 >>> David Brown <david.brown@hesbynett.no> wrote: >>> >>>> >>>> Compared to Windows machines with its pseudorandom system for >>>> assigning COM port numbers, >>> >>> There is a system in the madness. Behavior depends on either your >>> USB-to-serial device has USB serial Id or lacks it. >>> If it has Id then the same port will be assigned to the same device >>> regardless of the USB port that device plugged in this time. >>> Otherwise port number is assigned per USB port. Mostly. >>> >> >> It is the "mostly" that is the killer. >> >> The port numbers are usually stable if you plug the same devices into >> the same physical ports. But sometimes if you have had a number of >> new devices attached in the meantime, then go back to the old ones, >> Windows might forget the previous numbers, or even re-use them, and >> your old devices get new numbers. Mixing devices from different >> manufacturers appears to make things worse, but I have not done >> extensive trials. >> >> If you just have a few devices that you use regularly, it's okay - so >> for most of our developers the port numbers don't get too high within >> the lifetime of a useable Windows system. For some test machines >> it's a different matter - when you build boards with a USB-to-serial >> chip onboard, if those chips have serial numbers then you chew >> through COM port numbers at an alarming rate. It is just one of many >> reasons why we usually try to use Linux (especially Pi's) for test >> machines. >> > > Serial device API of Linux (inherited from early Unixes) is too kludgy > to my liking. Why oh why do they think that serial port somehow has to > be related to terminal ?! I can agree with you there. I have only once, that I can remember, actually used the serial API directly from C on Linux and "kludgy" is an appropriate description. Some kinds of programs are best written in C, other kinds are best written in other languages - serial port access from Python is simple, clear, and identical (except for the device names) for Windows and Linux, and that is what I use. > Windows API makes more sense. It's a long time since I have used the Windows API for serial port access, and that was probably from Pascal (Borland Pascal, then Delphi). I seem to remember accessing the port from the "OpenFile" call that could be used to open handles to all sorts of things, except files. But there was no need for anything involving terminals. > The difference mattered in the past, when we had to implement > SCADA-style protocols on PC host. Fortunately, we do not doing it any > longer. > I've done plenty of that, and use several - but I do it in Python on Linux. (It's C or C++ on the microcontroller side.) >>> Cheap FTDI clones tend to not implement serial ID. >>> Silicon Lab based converters tends to be of better quality, not just >>> relatively to clones, but also relatively to genuine FTDI >>> controllers. >>> >>> >> >> I don't remember ever using an FTDI clone - FTDI devices and cables >> are not expensive enough for it to make sense for us. And FTDI >> devices have worked fine for our needs. I have used a few Silicon >> Labs devices too, but I don't see anything to suggest they are >> "better quality" - pretty much every USB-to-serial converter from >> every manufacturer works fine and does its job. > > I wish it was true. > Unfortunately I had seen misdesigned hardware more than one time, > including hardware from major manufactorer, like Aten. > One case I can not forget is USB-1.1 device that claimed to support > 912 Kbps, but had 64-byte recieve and transmit queues. Of course, USB > polling rate is 1KHz, so it can't work even in theory, much less in > practice. > Maybe I've just been lucky :-) >> Some do cause more >> pain with Windows then others, with different drivers and >> requirements, but that's Windows and/or driver problems, and usually >> those problems are surmountable. In the end, it is usually up to the >> customer - if they want a USB-to-serial converter on their board, and >> they've picked a type, that's what they get. Given a free choice, we >> generally go for FTDI ourselves. (Most common is that boards have a >> simple header with TTL signals and we use an external FTDI cable - >> the biggest use of serial ports between boards and PC's is for >> debugging and testing.) >> > > As long as requirements are minimal, everything goes. > Try something just a little bit more demanding, like programming flash > on ST or TI microcontroller by means of vendor-supplied utility, and > many USB-to-serial converters will cause you problems. > The thing that is sometimes an issue, IME, is timing. Some protocols have particular timing requirements such maximum or minimum number of idle characters within or between packets. If the USB is not flowing smoothly, an unexpected break within a packet can cause trouble. This was especially true with early USB (1 ms cycle time), and earlier (or cheaper) converters with small buffers. It is also an issue with RS-485 if the drive enable is controlled "manually" from PC software side, rather than a dedicated drive enable output from the converter chip. And occasionally you meet and awkward protocol that uses 9-bit data, or break frames, which are not necessarily supported by converters.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-06-22 14:56 +0000 |
| Message-ID | <e2c_R.3741$Zhg2.867@fx12.iad> |
| In reply to | #400173 |
Michael S <already5chosen@yahoo.com> writes: >On Sun, 21 Jun 2026 12:18:39 +0200 >David Brown <david.brown@hesbynett.no> wrote: > >> > >Serial device API of Linux (inherited from early Unixes) is too kludgy >to my liking. Why oh why do they think that serial port somehow has to >be related to terminal ?! Can you elaborate on that? What do you mean 'related to a terminal'? The POSIX serial interface seems quite useful - using ioctl(2) to handle non-data-transfer interfaces (e.g. setting the baud rate, stop bits, parity, et alia) via library functions (tcsetattr/tcgetattr) and using standard filesystem calls for reading and writing. Once the serial port is opened, it is a simple byte stream just like any other unix file. Bitbanging RS232C for SCADA was never a design goal, unlike IEEE 488.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-06-23 07:25 +0200 |
| Message-ID | <111d5d4$202cp$1@dont-email.me> |
| In reply to | #400190 |
On 22/06/2026 16:56, Scott Lurndal wrote: > Michael S <already5chosen@yahoo.com> writes: >> On Sun, 21 Jun 2026 12:18:39 +0200 >> David Brown <david.brown@hesbynett.no> wrote: >> > >>> >> >> Serial device API of Linux (inherited from early Unixes) is too kludgy >> to my liking. Why oh why do they think that serial port somehow has to >> be related to terminal ?! > > Can you elaborate on that? What do you mean 'related to a terminal'? > > The POSIX serial interface seems quite useful - using ioctl(2) > to handle non-data-transfer interfaces (e.g. setting the baud rate, > stop bits, parity, et alia) via library functions (tcsetattr/tcgetattr) > and using standard filesystem calls for reading and writing. > > Once the serial port is opened, it is a simple byte stream just like > any other unix file. > > Bitbanging RS232C for SCADA was never a design goal, unlike > IEEE 488. > > Just look at the documentation: <https://docs.kernel.org/driver-api/serial/driver.html> or <https://en.wikibooks.org/wiki/Serial_Programming/Serial_Linux>. It's a total mess - it's all for handling serial terminals from the 1970's. Most of it is, of course, just a one-off setting - once you have got the termio stuff right, and haven't accidentally got some extra character translation or flow control, then it's just simple reads and writes. Of course it is hard to remove stuff once it is there - user space APIs are, rightly, as stable as they possibly can be.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-06-23 15:35 +0000 |
| Message-ID | <sJx_R.2$3sA7.0@fx20.iad> |
| In reply to | #400204 |
David Brown <david.brown@hesbynett.no> writes: >On 22/06/2026 16:56, Scott Lurndal wrote: >> Michael S <already5chosen@yahoo.com> writes: >>> On Sun, 21 Jun 2026 12:18:39 +0200 >>> David Brown <david.brown@hesbynett.no> wrote: >>> >> >>>> >>> >>> Serial device API of Linux (inherited from early Unixes) is too kludgy >>> to my liking. Why oh why do they think that serial port somehow has to >>> be related to terminal ?! >> >> Can you elaborate on that? What do you mean 'related to a terminal'? >> >> The POSIX serial interface seems quite useful - using ioctl(2) >> to handle non-data-transfer interfaces (e.g. setting the baud rate, >> stop bits, parity, et alia) via library functions (tcsetattr/tcgetattr) >> and using standard filesystem calls for reading and writing. >> >> Once the serial port is opened, it is a simple byte stream just like >> any other unix file. >> >> Bitbanging RS232C for SCADA was never a design goal, unlike >> IEEE 488. >> >> > >Just look at the documentation: ><https://docs.kernel.org/driver-api/serial/driver.html> Which describes how to write a kernel driver for a new serial port (of which there hasn't been new hardware since the PL011). Certainly not of interest or use to the average user. > or ><https://en.wikibooks.org/wiki/Serial_Programming/Serial_Linux>. Which describes several long-obsolete API implementations. > It's a >total mess - it's all for handling serial terminals from the 1970's. I'm sure that the microprocessors you routinely use all still support either the 16550 UART or the PL011 for debug purposes if not for production purposes. Our most recently taped out chip has a dozen pl011 compatible UARTS. Sure, the modem signals are obsolete and not often used. With 115k baud, it's less likely that the hardware flow control signals (RTS/CTS) are still used (although XON/XOFF is still useful) in most cases, but the classic serial port still lives and is useful, particularly in embedded hardware.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-06-23 18:07 +0200 |
| Message-ID | <111eavb$2c615$1@dont-email.me> |
| In reply to | #400205 |
On 23/06/2026 17:35, Scott Lurndal wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 22/06/2026 16:56, Scott Lurndal wrote: >>> Michael S <already5chosen@yahoo.com> writes: >>>> On Sun, 21 Jun 2026 12:18:39 +0200 >>>> David Brown <david.brown@hesbynett.no> wrote: >>>> >>> >>>>> >>>> >>>> Serial device API of Linux (inherited from early Unixes) is too kludgy >>>> to my liking. Why oh why do they think that serial port somehow has to >>>> be related to terminal ?! >>> >>> Can you elaborate on that? What do you mean 'related to a terminal'? >>> >>> The POSIX serial interface seems quite useful - using ioctl(2) >>> to handle non-data-transfer interfaces (e.g. setting the baud rate, >>> stop bits, parity, et alia) via library functions (tcsetattr/tcgetattr) >>> and using standard filesystem calls for reading and writing. >>> >>> Once the serial port is opened, it is a simple byte stream just like >>> any other unix file. >>> >>> Bitbanging RS232C for SCADA was never a design goal, unlike >>> IEEE 488. >>> >>> >> >> Just look at the documentation: >> <https://docs.kernel.org/driver-api/serial/driver.html> > > Which describes how to write a kernel driver for a new > serial port (of which there hasn't been new hardware since > the PL011). Certainly not of interest or use to the average > user. > OK - my mistake. >> or >> <https://en.wikibooks.org/wiki/Serial_Programming/Serial_Linux>. > > Which describes several long-obsolete API implementations. > OK. But there is still termio stuff needed in the setup of the UART, when all that is needed in almost all cases this century is picking the baud rate, possibly enabling the RTS line as an RS-485 driver enable, picking 8,n,1 (other options are rare, but not quite non-existent), and then reading and writing characters. There are other possible features that can be useful for UARTs, such as getting feedback when everything is sent (via a semaphore, condition variable, or similar synchronisation mechanism), getting feedback when there has been a pause since the last received character, and other such things. AFAIK these are not available with standard Linux serial port handling. >> It's a >> total mess - it's all for handling serial terminals from the 1970's. > > I'm sure that the microprocessors you routinely use all still > support either the 16550 UART or the PL011 for debug purposes > if not for production purposes. Our most recently taped out > chip has a dozen pl011 compatible UARTS. > 16550 UARTs are long obsolete. Some embedded processors might have UARTs that have register sets compatible with them, but I don't think it is common. Microcontrollers certainly don't make any attempt to have compatibility with those register sets. > Sure, the modem signals are obsolete and not often used. > > With 115k baud, it's less likely that the hardware flow > control signals (RTS/CTS) are still used (although XON/XOFF is > still useful) in most cases, but the classic serial port still > lives and is useful, particularly in embedded hardware. I use serial ports all the time. I've never had any use for XON/XOFF, or hardware flow control (the RTS signal is often used for RS-485 drive enable), and regularly use 3 MBaud for local connections to fast microcontrollers.
[toc] | [prev] | [next] | [standalone]
Page 6 of 10 — ← Prev page 1 … 4 5 [6] 7 8 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web