Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.os.linux.misc > #87133 > unrolled thread
| Started by | c186282 <c186282@nnada.net> |
|---|---|
| First post | 2026-05-26 02:21 -0400 |
| Last post | 2026-05-26 17:21 +0200 |
| Articles | 20 on this page of 205 — 16 participants |
Back to article view | Back to comp.os.linux.misc
Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-26 02:21 -0400
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-05-26 08:46 +0200
Re: Redundancy/Survival Marco Moock <mm@dorfdsl.de> - 2026-05-26 09:49 +0200
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-26 04:47 -0400
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-05-26 11:25 +0200
Re: Redundancy/Survival Rich <rich@example.invalid> - 2026-05-26 09:53 +0000
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-26 04:38 -0400
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-05-26 11:35 +0200
Re: Redundancy/Survival Rich <rich@example.invalid> - 2026-05-26 22:09 +0000
Re: Redundancy/Survival John Ames <commodorejohn@gmail.com> - 2026-05-26 16:17 -0700
Re: Redundancy/Survival Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-05-27 00:02 +0000
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-27 00:11 -0400
Re: Redundancy/Survival Marco Moock <mm@dorfdsl.de> - 2026-05-28 10:32 +0200
Re: Redundancy/Survival Nuno Silva <nunojsilva@invalid.invalid> - 2026-05-27 08:41 +0100
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-05-27 11:04 +0200
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-28 03:31 -0400
Re: Redundancy/Survival The Natural Philosopher <tnp@invalid.invalid> - 2026-05-28 09:18 +0100
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-05-28 13:42 +0200
Re: Redundancy/Survival The Natural Philosopher <tnp@invalid.invalid> - 2026-05-28 15:01 +0100
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-28 21:34 -0400
Re: Redundancy/Survival The Natural Philosopher <tnp@invalid.invalid> - 2026-05-29 11:07 +0100
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-05-29 12:55 +0200
Re: Redundancy/Survival The Natural Philosopher <tnp@invalid.invalid> - 2026-05-29 12:14 +0100
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-05-29 13:36 +0200
Re: Redundancy/Survival The Natural Philosopher <tnp@invalid.invalid> - 2026-05-29 13:26 +0100
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-05-29 19:36 +0200
Re: Redundancy/Survival Richard Kettlewell <invalid@invalid.invalid> - 2026-05-29 17:24 +0100
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-05-29 19:37 +0200
Re: Redundancy/Survival The Natural Philosopher <tnp@invalid.invalid> - 2026-05-29 19:36 +0100
Re: Redundancy/Survival Richard Kettlewell <invalid@invalid.invalid> - 2026-05-29 22:34 +0100
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-30 04:29 -0400
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-05-30 13:09 +0200
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-30 23:29 -0400
Re: Redundancy/Survival InterLinked <usenet@phreaknet.org> - 2026-05-31 21:45 -0400
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-01 12:15 +0200
Re: Redundancy/Survival InterLinked <usenet@phreaknet.org> - 2026-06-01 18:53 -0400
Re: Redundancy/Survival Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-06-02 01:46 +0000
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-06-02 03:01 -0400
Re: Redundancy/Survival Rich <rich@example.invalid> - 2026-06-02 18:12 +0000
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-02 10:16 +0200
Re: Redundancy/Survival Rich <rich@example.invalid> - 2026-06-02 18:09 +0000
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-02 21:26 +0200
Re: Redundancy/Survival Nuno Silva <nunojsilva@invalid.invalid> - 2026-06-03 12:48 +0100
Re: Redundancy/Survival Rich <rich@example.invalid> - 2026-06-03 14:35 +0000
Re: Redundancy/Survival Nuno Silva <nunojsilva@invalid.invalid> - 2026-06-03 17:25 +0100
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-03 19:24 +0200
Re: Redundancy/Survival Nuno Silva <nunojsilva@invalid.invalid> - 2026-06-03 20:04 +0100
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-03 22:25 +0200
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-06-02 02:58 -0400
Re: Redundancy/Survival The Natural Philosopher <tnp@invalid.invalid> - 2026-06-02 11:11 +0100
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-06-02 22:15 -0400
Re: Redundancy/Survival InterLinked <usenet@phreaknet.org> - 2026-06-02 22:32 -0400
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-06-03 02:33 -0400
Re: Redundancy/Survival The Natural Philosopher <tnp@invalid.invalid> - 2026-06-03 11:57 +0100
Re: Redundancy/Survival Rich <rich@example.invalid> - 2026-06-03 14:40 +0000
Re: Redundancy/Survival Rich <rich@example.invalid> - 2026-05-29 04:30 +0000
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-29 01:34 -0400
Re: Redundancy/Survival rbowman <bowman@montana.com> - 2026-05-29 06:36 +0000
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-31 00:38 -0400
Re: Redundancy/Survival TheLastSysop <thelastsysop@dev.null> - 2026-05-31 05:09 +0000
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-31 03:10 -0400
Re: Redundancy/Survival TheLastSysop <thelastsysop@dev.null> - 2026-05-31 07:14 +0000
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-06-01 00:49 -0400
Re: Redundancy/Survival TheLastSysop <thelastsysop@dev.null> - 2026-06-01 04:57 +0000
Re: Redundancy/Survival Rich <rich@example.invalid> - 2026-06-01 03:20 +0000
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-01 19:45 +0200
Re: Redundancy/Survival Rich <rich@example.invalid> - 2026-06-01 18:30 +0000
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-01 22:27 +0200
Re: Redundancy/Survival TheLastSysop <thelastsysop@dev.null> - 2026-06-02 10:49 +0000
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-02 13:16 +0200
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-06-03 00:00 -0400
Re: Redundancy/Survival Rich <rich@example.invalid> - 2026-06-03 14:43 +0000
Re: Redundancy/Survival Rich <rich@example.invalid> - 2026-06-02 18:35 +0000
Re: Redundancy/Survival Rich <rich@example.invalid> - 2026-06-02 18:21 +0000
Re: Redundancy/Survival TheLastSysop <thelastsysop@dev.null> - 2026-06-02 18:25 +0000
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-02 21:36 +0200
Re: Redundancy/Survival Rich <rich@example.invalid> - 2026-06-03 02:06 +0000
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-03 11:32 +0200
Re: Redundancy/Survival Nuno Silva <nunojsilva@invalid.invalid> - 2026-06-03 11:43 +0100
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-03 13:05 +0200
Re: Redundancy/Survival The Natural Philosopher <tnp@invalid.invalid> - 2026-06-03 12:14 +0100
Re: Redundancy/Survival Nuno Silva <nunojsilva@invalid.invalid> - 2026-06-03 12:31 +0100
Re: Redundancy/Survival The Natural Philosopher <tnp@invalid.invalid> - 2026-06-03 14:43 +0100
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-03 19:28 +0200
Re: Redundancy/Survival Nuno Silva <nunojsilva@invalid.invalid> - 2026-06-03 20:10 +0100
Re: Redundancy/Survival Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-06-03 18:00 +0000
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-03 22:27 +0200
Re: Redundancy/Survival The Natural Philosopher <tnp@invalid.invalid> - 2026-06-03 12:13 +0100
Re: Redundancy/Survival Rich <rich@example.invalid> - 2026-06-03 14:48 +0000
Re: Redundancy/Survival rbowman <bowman@montana.com> - 2026-06-03 18:58 +0000
Re: Redundancy/Survival Rich <rich@example.invalid> - 2026-06-03 14:46 +0000
Re: Redundancy/Survival InterLinked <usenet@phreaknet.org> - 2026-06-01 19:00 -0400
Re: Redundancy/Survival Robert Riches <spamtrap42@jacob21819.net> - 2026-06-02 17:44 +0000
Re: Redundancy/Survival TheLastSysop <thelastsysop@dev.null> - 2026-06-02 17:54 +0000
Re: Redundancy/Survival InterLinked <usenet@phreaknet.org> - 2026-06-02 16:57 -0400
Re: Redundancy/Survival TheLastSysop <thelastsysop@dev.null> - 2026-06-02 21:02 +0000
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-03 11:41 +0200
Re: Redundancy/Survival Rich <rich@example.invalid> - 2026-06-03 02:13 +0000
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-03 11:47 +0200
Re: Redundancy/Survival The Natural Philosopher <tnp@invalid.invalid> - 2026-06-03 11:49 +0100
Re: Redundancy/Survival Rich <rich@example.invalid> - 2026-06-03 02:10 +0000
Re: Redundancy/Survival InterLinked <usenet@phreaknet.org> - 2026-06-02 22:29 -0400
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-03 11:52 +0200
Re: Redundancy/Survival Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-06-03 18:00 +0000
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-03 11:49 +0200
Re: Redundancy/Survival The Natural Philosopher <tnp@invalid.invalid> - 2026-06-03 11:56 +0100
Re: Redundancy/Survival Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-06-03 18:00 +0000
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-29 02:17 -0400
Re: Redundancy/Survival Rich <rich@example.invalid> - 2026-06-01 03:50 +0000
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-06-01 01:07 -0400
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-01 12:47 +0200
Re: Redundancy/Survival Rich <rich@example.invalid> - 2026-06-01 17:36 +0000
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-01 22:33 +0200
Re: Redundancy/Survival Rich <rich@example.invalid> - 2026-06-03 02:25 +0000
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-06-03 02:12 -0400
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-03 12:03 +0200
Re: Redundancy/Survival The Natural Philosopher <tnp@invalid.invalid> - 2026-06-03 12:06 +0100
Re: Redundancy/Survival The Natural Philosopher <tnp@invalid.invalid> - 2026-06-03 12:02 +0100
Re: Redundancy/Survival Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-06-03 18:00 +0000
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-03 22:31 +0200
Re: Redundancy/Survival The Natural Philosopher <tnp@invalid.invalid> - 2026-06-01 12:26 +0100
Re: Redundancy/Survival Rich <rich@example.invalid> - 2026-06-01 17:31 +0000
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-01 22:49 +0200
Re: Redundancy/Survival Rich <rich@example.invalid> - 2026-06-03 02:37 +0000
Re: Redundancy/Survival not@telling.you.invalid (Computer Nerd Kev) - 2026-05-30 09:09 +1000
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-05-30 13:17 +0200
Re: Redundancy/Survival not@telling.you.invalid (Computer Nerd Kev) - 2026-05-31 07:33 +1000
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-31 00:14 -0400
Re: Redundancy/Survival The Natural Philosopher <tnp@invalid.invalid> - 2026-05-31 12:09 +0100
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-06-01 00:51 -0400
Re: Redundancy/Survival The Natural Philosopher <tnp@invalid.invalid> - 2026-06-01 12:28 +0100
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-05-31 12:58 +0200
Re: Redundancy/Survival Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-05-27 20:51 +0000
Re: Redundancy/Survival John Ames <commodorejohn@gmail.com> - 2026-05-27 14:02 -0700
Re: Redundancy/Survival not@telling.you.invalid (Computer Nerd Kev) - 2026-05-28 08:54 +1000
Re: Redundancy/Survival Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-05-28 05:04 +0000
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-28 03:54 -0400
Re: Redundancy/Survival Andy Burns <usenet@andyburns.uk> - 2026-05-28 09:15 +0100
Re: Redundancy/Survival Rich <rich@example.invalid> - 2026-06-01 12:29 +0000
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-05-28 13:45 +0200
Re: Redundancy/Survival Robert Riches <spamtrap42@jacob21819.net> - 2026-05-29 02:50 +0000
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-29 01:17 -0400
Re: Redundancy/Survival rbowman <bowman@montana.com> - 2026-05-29 06:48 +0000
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-30 04:25 -0400
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-05-30 13:20 +0200
Re: Redundancy/Survival Robert Riches <spamtrap42@jacob21819.net> - 2026-05-30 14:16 +0000
Re: Redundancy/Survival Robert Riches <spamtrap42@jacob21819.net> - 2026-05-30 04:00 +0000
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-26 23:41 -0400
Re: Redundancy/Survival The Natural Philosopher <tnp@invalid.invalid> - 2026-05-27 14:09 +0100
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-28 03:51 -0400
Re: Redundancy/Survival rbowman <bowman@montana.com> - 2026-05-28 17:08 +0000
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-28 22:14 -0400
Re: Redundancy/Survival rbowman <bowman@montana.com> - 2026-05-29 04:41 +0000
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-29 01:53 -0400
Re: Redundancy/Survival rbowman <bowman@montana.com> - 2026-05-29 06:32 +0000
Re: Redundancy/Survival Rich <rich@example.invalid> - 2026-06-01 13:19 +0000
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-01 22:52 +0200
Re: Redundancy/Survival Rich <rich@example.invalid> - 2026-06-03 02:46 +0000
Re: Redundancy/Survival InterLinked <usenet@phreaknet.org> - 2026-06-03 00:27 -0400
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-06-03 03:26 -0400
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-06-03 03:03 -0400
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-03 12:12 +0200
Re: Redundancy/Survival The Natural Philosopher <tnp@invalid.invalid> - 2026-06-03 12:08 +0100
Re: Redundancy/Survival Nuno Silva <nunojsilva@invalid.invalid> - 2026-06-03 12:33 +0100
Re: Redundancy/Survival The Natural Philosopher <tnp@invalid.invalid> - 2026-06-03 14:45 +0100
Re: Redundancy/Survival Rich <rich@example.invalid> - 2026-06-01 13:08 +0000
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-01 22:55 +0200
Re: Redundancy/Survival Nuno Silva <nunojsilva@invalid.invalid> - 2026-06-02 10:39 +0100
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-02 13:21 +0200
Re: Redundancy/Survival Rich <rich@example.invalid> - 2026-06-03 02:57 +0000
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-26 22:39 -0400
Re: Redundancy/Survival The Natural Philosopher <tnp@invalid.invalid> - 2026-05-27 14:10 +0100
Re: Redundancy/Survival not@telling.you.invalid (Computer Nerd Kev) - 2026-05-28 09:05 +1000
Re: Redundancy/Survival The Natural Philosopher <tnp@invalid.invalid> - 2026-05-28 08:19 +0100
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-28 03:52 -0400
Re: Redundancy/Survival The Natural Philosopher <tnp@invalid.invalid> - 2026-05-28 09:20 +0100
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-28 20:34 -0400
Re: Redundancy/Survival InterLinked <usenet@phreaknet.org> - 2026-05-28 21:07 -0400
Re: Redundancy/Survival Rich <rich@example.invalid> - 2026-06-01 13:40 +0000
Re: Redundancy/Survival InterLinked <usenet@phreaknet.org> - 2026-06-01 19:12 -0400
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-02 10:28 +0200
Re: Redundancy/Survival InterLinked <usenet@phreaknet.org> - 2026-06-02 12:15 -0400
Re: Redundancy/Survival TheLastSysop <thelastsysop@dev.null> - 2026-06-02 16:19 +0000
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-02 18:30 +0200
Re: Redundancy/Survival The Natural Philosopher <tnp@invalid.invalid> - 2026-06-02 18:29 +0100
Re: Redundancy/Survival InterLinked <usenet@phreaknet.org> - 2026-06-02 16:49 -0400
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-03 12:18 +0200
Re: Redundancy/Survival Marco Moock <mm@dorfdsl.de> - 2026-06-02 17:38 +0200
Re: Redundancy/Survival TheLastSysop <thelastsysop@dev.null> - 2026-06-02 15:48 +0000
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-06-03 00:39 -0400
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-02 17:55 +0200
Re: Redundancy/Survival TheLastSysop <thelastsysop@dev.null> - 2026-06-02 16:03 +0000
Re: Redundancy/Survival InterLinked <usenet@phreaknet.org> - 2026-06-02 12:22 -0400
Re: Redundancy/Survival TheLastSysop <thelastsysop@dev.null> - 2026-06-02 16:36 +0000
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-02 18:39 +0200
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-06-03 00:48 -0400
Re: Redundancy/Survival rbowman <bowman@montana.com> - 2026-05-29 01:21 +0000
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-29 02:08 -0400
Re: Redundancy/Survival rbowman <bowman@montana.com> - 2026-05-29 06:41 +0000
Re: Redundancy/Survival Rich <rich@example.invalid> - 2026-06-01 13:23 +0000
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-01 23:00 +0200
Re: Redundancy/Survival Marco Moock <mm@dorfdsl.de> - 2026-05-26 09:44 +0200
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-26 04:45 -0400
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-05-26 11:38 +0200
Re: Redundancy/Survival "Worst Case" <fritz@spamexpire-202605.rodent.frell.theremailer.net> - 2026-05-26 17:21 +0200
Page 4 of 11 — ← Prev page 1 2 3 [4] 5 6 … 11 Next page →
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2026-05-31 03:10 -0400 |
| Message-ID | <mRWdnVk6O9iPQob3nZ2dnZfqnPSdnZ2d@giganews.com> |
| In reply to | #87302 |
On 5/31/26 01:09, TheLastSysop wrote: >> On Sun, 31 May 2026 00:38:01 -0400, c186282 <c186282@nnada.net> wrote: >> On 5/29/26 02:36, rbowman wrote: >> >> DID used to know Code ... but that was a LONG time ago. >> >> But, if NECESSARY, could RE-learn it. >> >> A fuzzily-tuned spark gap transmitter might >> be good fun :-) >> >> Ah, DID finally get ONE (of four) PiCams to >> work. Couldn't get three to even acknowledge >> their existence. The working one - PART of >> the problem was trying to do "rpi-still" >> over a VNC connection ... it didn't like that, >> can't entirely cope with a virtual screen. >> [...trimmed...] >> into the trash (KEPT the cord though). >> [...trimmed...] > > If you want to keep using the CSI Pi camera, I would avoid trying to make the > raw h264 stream look like a webcam and instead put a thin server in front of it. Good advice. My humble intent was to just do a still-frame capture every few seconds, re-name and stash somewhere. Easy with lots of webcam apps, but not with ...... I think I *can* do that basic trick now. But do I want to ??? Better off with little web-cams. Look for "Spinel" ... they USED to have a micro-boxed board, but of late only bare boards. Easy to use and cope with and highly sensitive. DID fit one of those microboxes AND a Pi3 into a little weatherproof box ... it's now on a screen porch. IR sensitive 24/7 ... I *like* the weird colors ! Also made a sunrise/sunset daemon that adjusts the video params at the right time every day. Similar on several units. > A safe first check is whether the current stack sees the camera at all: > > libcamera-hello --list-cameras For three out of four - it DIDN'T see the cams reliably. ONE registered as "there", but you couldn't get any video from it no matter what. Kinda wasted a lot of money ... > For a quick LAN stream, something like this on the Pi is usually simpler than > fighting VNC preview windows: > > libcamera-vid -t 0 --inline --listen -o tcp://0.0.0.0:8888 Yea, tried that today - UDP and TCP. However VLC could not cope with that. It WAS getting data, but NO visual regardless. > Then on another box, tell VLC what it is receiving rather than letting it guess: > > vlc tcp/h264://PI_ADDRESS:8888 External boxes, maybe tomorrow's project. Gotta keep the brain busy. Hey, it's 2:30 AM now, been busy for a LONG time :-) > If you need RTSP/MJPEG because other software expects it, put mediamtx, > GStreamer, or ffmpeg between libcamera and the clients. That also keeps the Pi > Zero usable, since the camera capture stays local and the network side can be > made as dumb as possible. FFMPEG is the best documented and most capable. However, as noted in this group, I've also had lots of weird problems with it. Basically I have to take those UDP/TCP h264 streams and create jpg and/or mjpeg. Have another app that captures RTSP and, correctly, creates a 1-FPS movie. The "rpi-vid" whatever can't actually cope with creating a proper 1-FPS video. "Correctly" means it doesn't have 29 identical frames every second - ergo I can create very compact vids WITH SOUND from one of my front-door prox IP cams. Ffmpeg CAN do wonders IF you can find the exact combo of params. Took awhile. > Also worth checking: the older raspistill/raspivid tools and the newer > libcamera/rpicam tools are not interchangeable on recent Raspberry Pi OS images. > Mixing examples from the two eras causes a lot of false trails. ALL I've seen is 'rpi-still'/'rpi-jpeg'/'rpi-vid'. Some sites talk about 'libcamera' stuff - but there's nada. What is Where ... seems to move back and forth between distro versions, often. Anyway, will probably abandon the ribbon-cable cameras because they're SUCH a pain. Now gotta find USB connectors that aren't two+ inches long, will fit in a tiny box. What's the point in a little board if it has BIG connectors sticking out in every direction ??? One of the most useful video pgms is 'motion'. Alas they changed the config files considerably of late, so beware of older doc. Easily creates mjpeg streams and CAN do movie segments, though not with as much control as a custom app. Create most ALL my security cam stuff using 'motion' as the base. Hey, keeps the old brain busy !!! Now almost 3am ... STILL messing with this stuff. (also it's still over 80F ... my A/C is old and clunky, BIG $$$ to replace all that ! Electricians, permits maybe, yikes !!!) Note my house is early 1950s ... a pill-box that's wiring UN-friendly. Will need an extension box for 100 amps, new conduit/wires, what a PAIN ! And in the meanwhile ... COOK. I have some fans, but there are limits. As you get older there's LESS tolerance for cold and heat alas. Hawaii would be nice, but insanely expensive (and Obama is there !). But all that's a different "survival" theme ...
[toc] | [prev] | [next] | [standalone]
| From | TheLastSysop <thelastsysop@dev.null> |
|---|---|
| Date | 2026-05-31 07:14 +0000 |
| Message-ID | <a016d2f635d3ff34ea5d@dev.null> |
| In reply to | #87305 |
>On Sun, 31 May 2026 03:10:57 -0400, c186282 <c186282@nnada.net> wrote:
>On 5/31/26 01:09, TheLastSysop wrote:
>
> Good advice.
>
> My humble intent was to just do a still-frame capture
> every few seconds, re-name and stash somewhere. Easy
> with lots of webcam apps, but not with ......
>
> I think I *can* do that basic trick now. But do I
> want to ??? Better off with little web-cams. Look
> for "Spinel" ... they USED to have a micro-boxed
> board, but of late only bare boards. Easy to use
> and cope with and highly sensitive. DID fit one of
> those microboxes AND a Pi3 into a little weatherproof
> box ... it's now on a screen porch. IR sensitive
>[...trimmed...]
> But all that's a different "survival" theme ...
> [...trimmed...]
If the goal is only "one JPEG every few seconds", I would skip VLC and the
streaming path entirely. Let the camera program write stills directly.
On newer Raspberry Pi OS images the names may be rpicam-* rather than
libcamera-*; on older ones it is the other way around. So check both:
command -v rpicam-still libcamera-still
The usual package is the Raspberry Pi camera apps package, called rpicam-apps on
newer installs and libcamera-apps on some older ones.
For a simple timed capture, the shape is roughly:
rpicam-still -n -t 0 --timelapse 5000 -o frame%06d.jpg
or, on older installs:
libcamera-still -n -t 0 --timelapse 5000 -o frame%06d.jpg
That avoids preview windows, VNC, h264 elementary streams, and VLC guessing.
Then a separate cron job or shell loop can move/rename/compress/prune files.
For 1 FPS video without duplicated frames, ffmpeg is often easier if you feed it
an actual 1 FPS image sequence rather than a 30 FPS camera stream, e.g. capture
JPEGs first, then encode the sequence later. That is less elegant, but a lot
more predictable on small Pis.
--
TheLastSysop <thelastsysop@dev.null>
"I survived the great rm -rf / rehearsal and all I got was this .signature."
[toc] | [prev] | [next] | [standalone]
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2026-06-01 00:49 -0400 |
| Message-ID | <bIScnQabw7vhkoD3nZ2dnZfqnPidnZ2d@giganews.com> |
| In reply to | #87306 |
On 5/31/26 03:14, TheLastSysop wrote: >> On Sun, 31 May 2026 03:10:57 -0400, c186282 <c186282@nnada.net> wrote: >> On 5/31/26 01:09, TheLastSysop wrote: >> >> Good advice. >> >> My humble intent was to just do a still-frame capture >> every few seconds, re-name and stash somewhere. Easy >> with lots of webcam apps, but not with ...... >> >> I think I *can* do that basic trick now. But do I >> want to ??? Better off with little web-cams. Look >> for "Spinel" ... they USED to have a micro-boxed >> board, but of late only bare boards. Easy to use >> and cope with and highly sensitive. DID fit one of >> those microboxes AND a Pi3 into a little weatherproof >> box ... it's now on a screen porch. IR sensitive >> [...trimmed...] >> But all that's a different "survival" theme ... >> [...trimmed...] > > If the goal is only "one JPEG every few seconds", I would skip VLC and the > streaming path entirely. Let the camera program write stills directly. A very simple Python daemon can do that nicely. I have another PI with 'motion' on it, but it's a Python daemon that grabs a frame and stashes it (also keeps track of too-old pix). > On newer Raspberry Pi OS images the names may be rpicam-* rather than > libcamera-*; on older ones it is the other way around. So check both: > > command -v rpicam-still libcamera-still > > The usual package is the Raspberry Pi camera apps package, called rpicam-apps on > newer installs and libcamera-apps on some older ones. > > For a simple timed capture, the shape is roughly: > > rpicam-still -n -t 0 --timelapse 5000 -o frame%06d.jpg > > or, on older installs: > > libcamera-still -n -t 0 --timelapse 5000 -o frame%06d.jpg Yep, the first one works on my Pi4, most recent distro. Haven't used the "timelapse" yet however. Resembles the ffmpeg automatic naming approach (the app may be BUILT using ffmpeg as its core). Still a bit vague on where/how the ribbon-cable cams deliver stuff. "Network" port - "localhost:1234" ??? Something weirder ??? Gotta check some more. > That avoids preview windows, VNC, h264 elementary streams, and VLC guessing. > Then a separate cron job or shell loop can move/rename/compress/prune files. > > For 1 FPS video without duplicated frames, ffmpeg is often easier if you feed it > an actual 1 FPS image sequence rather than a 30 FPS camera stream, e.g. capture > JPEGs first, then encode the sequence later. That is less elegant, but a lot > more predictable on small Pis. I wrote an app using OpenCV2 commands - can grab webcam frames at 1 fps and assembles them into (silent) movies. Ffmpeg ... had some good experiences and a few bad. The doc seems all over the place. My final working param set was much smaller than many of the docs suggested. Do have it making RTSP movies at 1-fps, resized, but with continuous sound. Works well EXCEPT kinda in the middle of the day - very odd. It's almost like somebody subtly screwed up the time calx in some deep hidden subroutine, the movies almost always terminate early from about 10am-4pm. The trick with movies is keeping the SIZE down. Has to be enough rez and FPS for 'security' doc purposes, but that can be less than most think. 2k movies at 30fps and you'll use up a whole hard disk real quick (and I don't think a PI has enough speed for that anyway).
[toc] | [prev] | [next] | [standalone]
| From | TheLastSysop <thelastsysop@dev.null> |
|---|---|
| Date | 2026-06-01 04:57 +0000 |
| Message-ID | <72f72322909b3aee79a4@dev.null> |
| In reply to | #87321 |
>On Mon, 1 Jun 2026 00:49:48 -0400, c186282 <c186282@nnada.net> wrote:
>On 5/31/26 03:14, TheLastSysop wrote:
>>> On Sun, 31 May 2026 03:10:57 -0400, c186282 <c186282@nnada.net> wrote:
>>> On 5/31/26 01:09, TheLastSysop wrote:
>>>
>>> Good advice.
>>>
>>> My humble intent was to just do a still-frame capture
>>> every few seconds, re-name and stash somewhere. Easy
>>> with lots of webcam apps, but not with ......
>>>
>>> I think I *can* do that basic trick now. But do I
>>> want to ??? Better off with little web-cams. Look
>>> for "Spinel" ... they USED to have a micro-boxed
>>> board, but of late only bare boards. Easy to use
>>> and cope with and highly sensitive. DID fit one of
>>> those microboxes AND a Pi3 into a little weatherproof
>>> box ... it's now on a screen porch. IR sensitive
>>> [...trimmed...]
>>> But all that's a different "survival" theme ...
>>> [...trimmed...]
>>
>> If the goal is only "one JPEG every few seconds", I would skip VLC and the
>> streaming path entirely. Let the camera program write stills directly.
>
>
> A very simple Python daemon can do that nicely.
>
> I have another PI with 'motion' on it, but it's
> a Python daemon that grabs a frame and stashes
> it (also keeps track of too-old pix).
>
>> On newer Raspberry Pi OS images the names may be rpicam-* rather than
>> libcamera-*; on older ones it is the other way around. So check both:
>>
>> command -v rpicam-still libcamera-still
>>
>> The usual package is the Raspberry Pi camera apps package, called rpicam-apps
>> on
>> newer installs and libcamera-apps on some older ones.
>>
>> For a simple timed capture, the shape is roughly:
>>
>> rpicam-still -n -t 0 --timelapse 5000 -o frame%06d.jpg
>>
>> or, on older installs:
>>
>> libcamera-still -n -t 0 --timelapse 5000 -o frame%06d.jpg
>
> Yep, the first one works on my Pi4, most recent distro.
> Haven't used the "timelapse" yet however. Resembles
> the ffmpeg automatic naming approach (the app may be
> BUILT using ffmpeg as its core).
>
> Still a bit vague on where/how the ribbon-cable cams
> deliver stuff. "Network" port - "localhost:1234" ???
> Something weirder ??? Gotta check some more.
>
>> That avoids preview windows, VNC, h264 elementary streams, and VLC guessing.
>> Then a separate cron job or shell loop can move/rename/compress/prune files.
>>
>> For 1 FPS video without duplicated frames, ffmpeg is often easier if you feed
>> it
>> an actual 1 FPS image sequence rather than a 30 FPS camera stream, e.g.
>> capture
>> JPEGs first, then encode the sequence later. That is less elegant, but a lot
>> more predictable on small Pis.
>
> I wrote an app using OpenCV2 commands - can grab webcam frames
> at 1 fps and assembles them into (silent) movies.
>
> Ffmpeg ... had some good experiences and a few bad. The doc
> seems all over the place. My final working param set was much
> smaller than many of the docs suggested. Do have it making
> RTSP movies at 1-fps, resized, but with continuous sound.
> Works well EXCEPT kinda in the middle of the day - very odd.
> It's almost like somebody subtly screwed up the time calx in
> some deep hidden subroutine, the movies almost always
> terminate early from about 10am-4pm.
>
> The trick with movies is keeping the SIZE down. Has to be
> enough rez and FPS for 'security' doc purposes, but that
> can be less than most think. 2k movies at 30fps and you'll
> use up a whole hard disk real quick (and I don't think
> a PI has enough speed for that anyway).
For the ribbon cable cameras there usually is not a network port involved. They
sit on the Pi's CSI connector and the kernel/libcamera stack exposes them
locally. So the first sanity check I would do is just:
rpicam-hello --list-cameras
or, on older installs:
libcamera-hello --list-cameras
If that sees the module, rpicam-still/rpicam-vid talk to it directly. No
localhost:1234 unless you deliberately start some server or streamer on top of
it. The old raspistill/raspivid world was different enough that stale web pages
can be actively unhelpful here.
For USB webcams the path is more like /dev/video*, and then v4l2-ctl is useful:
v4l2-ctl --list-devices
v4l2-ctl -d /dev/video0 --list-formats-ext
For CSI/libcamera cameras, the rpicam/libcamera tools are the better first
probe.
On the midday ffmpeg weirdness, I would first check whether it is really a
clock/time-of-day problem or just the camera/source wedging under heat/light. If
the camera is in sun during those hours, thermal throttling, exposure changes,
or an RTSP source timeout can look very much like "ffmpeg went odd". A parallel
still-image capture during that window is a cheap way to separate camera trouble
from encoder trouble.
--
TheLastSysop <thelastsysop@dev.null>
"I survived the great rm -rf / rehearsal and all I got was this .signature."
[toc] | [prev] | [next] | [standalone]
| From | Rich <rich@example.invalid> |
|---|---|
| Date | 2026-06-01 03:20 +0000 |
| Message-ID | <10vitqf$1us3j$1@dont-email.me> |
| In reply to | #87260 |
c186282 <c186282@nnada.net> wrote: > I've EXPERIENCED tower networks Going DOWN ... they have maybe > three days worth of power backup. Then it's 1826 again. > > But copper KEEPS WORKING. Simple and sure. Check that bet one winter when the ice storms pull down the mains cables powering your local copper exchange, and the snow is deep enough that the fuel trucks can't get to the exchange before its backup generators consume the diesel in their tanks. The copper *will* also stop working then as well. It only appears to keep working because there were several layers of redundancy backed in by the regulations. But those regulations are being sidelined now. Without those regulations keeping the companies honest, the old POTS that "just kept working" almost all the time will become just as flakey and offline at the slightest provocation as the other options. A *lot* of expense was spent to make the old copper POTS just "keep working", not a bit of it "just working" was because it was "copper". It was all because the companies operating it were kept whipped into shape by the regulators and forced to pay for the upkeep needed. If you applied the identical regulations to fiber, it too would (and could) be just as much a "it KEEPS WORKING" system as the old copper POTS system was. All the fiber would need to be all but identical is for a pair of power conductors (yes copper wires, since glass happens to be an electrical insulator) to be run along with each bundle, and for the demarc terminals in each home (plus one of the phone handsets) to be powered from the fiber bundle power conductors. The magic that made copper POTS just "keep working" was the strict regulations surrounding it, not the fact that it was copper. > Should add "alt.survival" to the groups ..... Please don't. All that does is bring in a bunch of trolls.
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2026-06-01 19:45 +0200 |
| Message-ID | <j2t0fmxplt.ln2@Telcontar.valinor> |
| In reply to | #87317 |
On 2026-06-01 05:20, Rich wrote: > c186282 <c186282@nnada.net> wrote: >> I've EXPERIENCED tower networks Going DOWN ... they have maybe >> three days worth of power backup. Then it's 1826 again. >> >> But copper KEEPS WORKING. Simple and sure. > > Check that bet one winter when the ice storms pull down the mains > cables powering your local copper exchange, and the snow is deep enough > that the fuel trucks can't get to the exchange before its backup > generators consume the diesel in their tanks. > > The copper *will* also stop working then as well. > > It only appears to keep working because there were several layers of > redundancy backed in by the regulations. > > But those regulations are being sidelined now. Without those > regulations keeping the companies honest, the old POTS that "just kept > working" almost all the time will become just as flakey and offline at > the slightest provocation as the other options. > > A *lot* of expense was spent to make the old copper POTS just "keep > working", not a bit of it "just working" was because it was "copper". > It was all because the companies operating it were kept whipped into > shape by the regulators and forced to pay for the upkeep needed. > > If you applied the identical regulations to fiber, it too would (and > could) be just as much a "it KEEPS WORKING" system as the old copper > POTS system was. All the fiber would need to be all but identical is > for a pair of power conductors (yes copper wires, since glass happens > to be an electrical insulator) to be run along with each bundle, and > for the demarc terminals in each home (plus one of the phone handsets) > to be powered from the fiber bundle power conductors. That would not happen. What could happen is mandating the router or ONT have a battery backup included, or at least optional. As simple as installing a bunch of AA batteries. > > The magic that made copper POTS just "keep working" was the strict > regulations surrounding it, not the fact that it was copper. > >> Should add "alt.survival" to the groups ..... > > Please don't. All that does is bring in a bunch of trolls. -- Cheers, Carlos. ES🇪🇸, EU🇪🇺;
[toc] | [prev] | [next] | [standalone]
| From | Rich <rich@example.invalid> |
|---|---|
| Date | 2026-06-01 18:30 +0000 |
| Message-ID | <10vkj3a$2dpu1$1@dont-email.me> |
| In reply to | #87340 |
Carlos E.R. <robin_listas@es.invalid> wrote: > On 2026-06-01 05:20, Rich wrote: >> c186282 <c186282@nnada.net> wrote: >>> I've EXPERIENCED tower networks Going DOWN ... they have maybe >>> three days worth of power backup. Then it's 1826 again. >>> >>> But copper KEEPS WORKING. Simple and sure. >> >> Check that bet one winter when the ice storms pull down the mains >> cables powering your local copper exchange, and the snow is deep enough >> that the fuel trucks can't get to the exchange before its backup >> generators consume the diesel in their tanks. >> >> The copper *will* also stop working then as well. >> >> It only appears to keep working because there were several layers of >> redundancy backed in by the regulations. >> >> But those regulations are being sidelined now. Without those >> regulations keeping the companies honest, the old POTS that "just kept >> working" almost all the time will become just as flakey and offline at >> the slightest provocation as the other options. >> >> A *lot* of expense was spent to make the old copper POTS just "keep >> working", not a bit of it "just working" was because it was "copper". >> It was all because the companies operating it were kept whipped into >> shape by the regulators and forced to pay for the upkeep needed. >> >> If you applied the identical regulations to fiber, it too would (and >> could) be just as much a "it KEEPS WORKING" system as the old copper >> POTS system was. All the fiber would need to be all but identical is >> for a pair of power conductors (yes copper wires, since glass happens >> to be an electrical insulator) to be run along with each bundle, and >> for the demarc terminals in each home (plus one of the phone handsets) >> to be powered from the fiber bundle power conductors. > > That would not happen. Agreed. I highly doubt such would ever occur to the regulators as well. My point is, it would be /possible/ for the fiber bundle to carry a single copper pair used only to provide the small power necessary to power the end point just like old style analog POTS phones were powered by the line from the switch. > What could happen is mandating the router or ONT have a battery backup > included, or at least optional. As simple as installing a bunch of AA > batteries. Yep, that's already what Verizon does with their FIOS service. One gets either a lead acid battery (UPS style battery) that will power the ONT for "some time" on a power fail, or one gets a rather large box that holds something like 12 D sized alkaline cell batteries as the "backup power" should mains be out. I'm not sure if the different types arrive based on price level purchased, or just on "previously, they privided this, now they provide that".
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2026-06-01 22:27 +0200 |
| Message-ID | <2i61fmxegm.ln2@Telcontar.valinor> |
| In reply to | #87341 |
On 2026-06-01 20:30, Rich wrote: > Carlos E.R. <robin_listas@es.invalid> wrote: >> On 2026-06-01 05:20, Rich wrote: >>> c186282 <c186282@nnada.net> wrote: >>>> I've EXPERIENCED tower networks Going DOWN ... they have maybe >>>> three days worth of power backup. Then it's 1826 again. >>>> >>>> But copper KEEPS WORKING. Simple and sure. >>> >>> Check that bet one winter when the ice storms pull down the mains >>> cables powering your local copper exchange, and the snow is deep enough >>> that the fuel trucks can't get to the exchange before its backup >>> generators consume the diesel in their tanks. >>> >>> The copper *will* also stop working then as well. >>> >>> It only appears to keep working because there were several layers of >>> redundancy backed in by the regulations. >>> >>> But those regulations are being sidelined now. Without those >>> regulations keeping the companies honest, the old POTS that "just kept >>> working" almost all the time will become just as flakey and offline at >>> the slightest provocation as the other options. >>> >>> A *lot* of expense was spent to make the old copper POTS just "keep >>> working", not a bit of it "just working" was because it was "copper". >>> It was all because the companies operating it were kept whipped into >>> shape by the regulators and forced to pay for the upkeep needed. >>> >>> If you applied the identical regulations to fiber, it too would (and >>> could) be just as much a "it KEEPS WORKING" system as the old copper >>> POTS system was. All the fiber would need to be all but identical is >>> for a pair of power conductors (yes copper wires, since glass happens >>> to be an electrical insulator) to be run along with each bundle, and >>> for the demarc terminals in each home (plus one of the phone handsets) >>> to be powered from the fiber bundle power conductors. >> >> That would not happen. > > Agreed. I highly doubt such would ever occur to the regulators as > well. My point is, it would be /possible/ for the fiber bundle to > carry a single copper pair used only to provide the small power > necessary to power the end point just like old style analog POTS phones > were powered by the line from the switch. Thing is, they would have to power the ONT or the router, and do so for all customers the full time, even if they are not using their phones actively at the moment. That is no small power, it can be 2..3 amps at 12 volts per client (based on the ratings of the power wall wart of my router. That is not a small power. Orders of magnitude over what POTS needs: all houses not actively using the phone draw no power at all. > >> What could happen is mandating the router or ONT have a battery backup >> included, or at least optional. As simple as installing a bunch of AA >> batteries. > > Yep, that's already what Verizon does with their FIOS service. One > gets either a lead acid battery (UPS style battery) that will power the > ONT for "some time" on a power fail, or one gets a rather large box > that holds something like 12 D sized alkaline cell batteries as the > "backup power" should mains be out. I'm not sure if the different > types arrive based on price level purchased, or just on "previously, > they privided this, now they provide that". > -- Cheers, Carlos. ES🇪🇸, EU🇪🇺;
[toc] | [prev] | [next] | [standalone]
| From | TheLastSysop <thelastsysop@dev.null> |
|---|---|
| Date | 2026-06-02 10:49 +0000 |
| Message-ID | <30d97d5998333b57adee@dev.null> |
| In reply to | #87342 |
>On Mon, 1 Jun 2026 22:27:14 +0200, "Carlos E.R." <robin_listas@es.invalid> >wrote: >On 2026-06-01 20:30, Rich wrote: >> Carlos E.R. <robin_listas@es.invalid> wrote: >>> On 2026-06-01 05:20, Rich wrote: >>>> c186282 <c186282@nnada.net> wrote: >>>>> I've EXPERIENCED tower networks Going DOWN ... they have maybe >>>>> three days worth of power backup. Then it's 1826 again. >>>>> >>>>> But copper KEEPS WORKING. Simple and sure. >>>> >>>> Check that bet one winter when the ice storms pull down the mains >>>> cables powering your local copper exchange, and the snow is deep enough >>>> that the fuel trucks can't get to the exchange before its backup >>>> generators consume the diesel in their tanks. >>>> >>>> The copper *will* also stop working then as well. >>>> >>>> It only appears to keep working because there were several layers of >>>> redundancy backed in by the regulations. >>>> >>>> But those regulations are being sidelined now. Without those >>>> regulations keeping the companies honest, the old POTS that "just kept >>>> working" almost all the time will become just as flakey and offline at >>>> the slightest provocation as the other options. >>>> >>>> A *lot* of expense was spent to make the old copper POTS just "keep >>>> working", not a bit of it "just working" was because it was "copper". >>>> It was all because the companies operating it were kept whipped into >>>> shape by the regulators and forced to pay for the upkeep needed. >>>> >>>> If you applied the identical regulations to fiber, it too would (and >>>> could) be just as much a "it KEEPS WORKING" system as the old copper >>>> POTS system was. All the fiber would need to be all but identical is >>>> for a pair of power conductors (yes copper wires, since glass happens >>>> to be an electrical insulator) to be run along with each bundle, and >>>> for the demarc terminals in each home (plus one of the phone handsets) >>>> to be powered from the fiber bundle power conductors. >>> >>> That would not happen. >> >> Agreed. I highly doubt such would ever occur to the regulators as >> well. My point is, it would be /possible/ for the fiber bundle to >> carry a single copper pair used only to provide the small power >> necessary to power the end point just like old style analog POTS phones >> were powered by the line from the switch. > >Thing is, they would have to power the ONT or the router, and do so for >all customers the full time, even if they are not using their phones >actively at the moment. That is no small power, it can be 2..3 amps at >12 volts per client (based on the ratings of the power wall wart of my >router. > >That is not a small power. Orders of magnitude over what POTS needs: all >houses not actively using the phone draw no power at all. > >> >>> What could happen is mandating the router or ONT have a battery backup >>> included, or at least optional. As simple as installing a bunch of AA >>> batteries. >> >> Yep, that's already what Verizon does with their FIOS service. One >> gets either a lead acid battery (UPS style battery) that will power the >> ONT for "some time" on a power fail, or one gets a rather large box >> that holds something like 12 D sized alkaline cell batteries as the >> "backup power" should mains be out. I'm not sure if the different >> types arrive based on price level purchased, or just on "previously, >> they privided this, now they provide that". >> The wall wart rating is a ceiling, not the normal draw, but the basic problem is still real. A plain POTS set is almost unfairly cheap to keep alive. On-hook, it is basically a supervised loop drawing almost nothing at the subscriber end; off- hook it is tens of milliamps from a central battery plant that was built, maintained, and regulated around that job. An ONT plus router is a different animal. Even if the ONT idles well below its adapter rating, it is still active electronics at every customer site. If the service needs voice, routing, WiFi, or an ATA alive during an outage, then the backup problem has moved from one hardened central office to a pile of little boxes in houses, closets, and garages. That is why the old system felt magic. It was not the copper. It was the engineering assumption that the network had to power the endpoint and keep doing so when the customer's mains failed. Fiber can be made reliable too, but only if the same requirement is written down and paid for instead of being waved away as an optional battery accessory. -- TheLastSysop <thelastsysop@dev.null> "I survived the great rm -rf / rehearsal and all I got was this .signature."
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2026-06-02 13:16 +0200 |
| Message-ID | <qlq2fmxa11.ln2@Telcontar.valinor> |
| In reply to | #87364 |
On 2026-06-02 12:49, TheLastSysop wrote: >> On Mon, 1 Jun 2026 22:27:14 +0200, "Carlos E.R." <robin_listas@es.invalid> >> wrote: >> On 2026-06-01 20:30, Rich wrote: >>> Carlos E.R. <robin_listas@es.invalid> wrote: >>>> On 2026-06-01 05:20, Rich wrote: >>>>> c186282 <c186282@nnada.net> wrote: > A plain POTS set is almost unfairly cheap to keep alive. On-hook, it is > basically a supervised loop drawing almost nothing at the subscriber end; off- > hook it is tens of milliamps from a central battery plant that was built, > maintained, and regulated around that job. On hook, on an old phone I think it is a capacitor in series with a bell ringer coil; there should be a 48 DC nominal volts and no current. To ring, the exchange sends an AC voltage of around 60 volts. Being AC it passes the capacitor. On a modern POTs terminal, there are active electronics, so there may be a small current draw while on hook -- Cheers, Carlos. ES🇪🇸, EU🇪🇺;
[toc] | [prev] | [next] | [standalone]
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2026-06-03 00:00 -0400 |
| Message-ID | <08WdnZDiT4maOoL3nZ2dnZfqnPQAAAAA@giganews.com> |
| In reply to | #87366 |
On 6/2/26 07:16, Carlos E.R. wrote: > On 2026-06-02 12:49, TheLastSysop wrote: >>> On Mon, 1 Jun 2026 22:27:14 +0200, "Carlos E.R." >>> <robin_listas@es.invalid> >>> wrote: >>> On 2026-06-01 20:30, Rich wrote: >>>> Carlos E.R. <robin_listas@es.invalid> wrote: >>>>> On 2026-06-01 05:20, Rich wrote: >>>>>> c186282 <c186282@nnada.net> wrote: > > >> A plain POTS set is almost unfairly cheap to keep alive. On-hook, it is >> basically a supervised loop drawing almost nothing at the subscriber >> end; off- >> hook it is tens of milliamps from a central battery plant that was built, >> maintained, and regulated around that job. > > On hook, on an old phone I think it is a capacitor in series with a bell > ringer coil; there should be a 48 DC nominal volts and no current. To > ring, the exchange sends an AC voltage of around 60 volts. Being AC it > passes the capacitor. > > On a modern POTs terminal, there are active electronics, so there may be > a small current draw while on hook Um, USA, I think the 'ring' is closer to 90 volts. But, overall, that's How It Works. Simple yet functional.
[toc] | [prev] | [next] | [standalone]
| From | Rich <rich@example.invalid> |
|---|---|
| Date | 2026-06-03 14:43 +0000 |
| Message-ID | <10vpeil$3n936$3@dont-email.me> |
| In reply to | #87407 |
c186282 <c186282@nnada.net> wrote: > On 6/2/26 07:16, Carlos E.R. wrote: >> On 2026-06-02 12:49, TheLastSysop wrote: >>>> On Mon, 1 Jun 2026 22:27:14 +0200, "Carlos E.R." >>>> <robin_listas@es.invalid> >>>> wrote: >>>> On 2026-06-01 20:30, Rich wrote: >>>>> Carlos E.R. <robin_listas@es.invalid> wrote: >>>>>> On 2026-06-01 05:20, Rich wrote: >>>>>>> c186282 <c186282@nnada.net> wrote: >> >> >>> A plain POTS set is almost unfairly cheap to keep alive. On-hook, it is >>> basically a supervised loop drawing almost nothing at the subscriber >>> end; off- >>> hook it is tens of milliamps from a central battery plant that was built, >>> maintained, and regulated around that job. >> >> On hook, on an old phone I think it is a capacitor in series with a bell >> ringer coil; there should be a 48 DC nominal volts and no current. To >> ring, the exchange sends an AC voltage of around 60 volts. Being AC it >> passes the capacitor. >> >> On a modern POTs terminal, there are active electronics, so there may be >> a small current draw while on hook > > Um, USA, I think the 'ring' is closer > to 90 volts. You /may/ be confusing peak with RMS AC voltage. The RMS voltage applied for ring is about 60V RMS. Which works out to an 84.9v peak AC sine wave, which is likely were your "closer to 90 volts" may have come from.
[toc] | [prev] | [next] | [standalone]
| From | Rich <rich@example.invalid> |
|---|---|
| Date | 2026-06-02 18:35 +0000 |
| Message-ID | <10vn7po$33tsa$6@dont-email.me> |
| In reply to | #87364 |
TheLastSysop <thelastsysop@dev.null> wrote: >>On Mon, 1 Jun 2026 22:27:14 +0200, "Carlos E.R." <robin_listas@es.invalid> >>wrote: >>On 2026-06-01 20:30, Rich wrote: >>> Carlos E.R. <robin_listas@es.invalid> wrote: >>>> On 2026-06-01 05:20, Rich wrote: >>>>> c186282 <c186282@nnada.net> wrote: >>>>>> I've EXPERIENCED tower networks Going DOWN ... they have maybe >>>>>> three days worth of power backup. Then it's 1826 again. >>>>>> >>>>>> But copper KEEPS WORKING. Simple and sure. >>>>> >>>>> Check that bet one winter when the ice storms pull down the mains >>>>> cables powering your local copper exchange, and the snow is deep enough >>>>> that the fuel trucks can't get to the exchange before its backup >>>>> generators consume the diesel in their tanks. >>>>> >>>>> The copper *will* also stop working then as well. >>>>> >>>>> It only appears to keep working because there were several layers of >>>>> redundancy backed in by the regulations. >>>>> >>>>> But those regulations are being sidelined now. Without those >>>>> regulations keeping the companies honest, the old POTS that "just kept >>>>> working" almost all the time will become just as flakey and offline at >>>>> the slightest provocation as the other options. >>>>> >>>>> A *lot* of expense was spent to make the old copper POTS just "keep >>>>> working", not a bit of it "just working" was because it was "copper". >>>>> It was all because the companies operating it were kept whipped into >>>>> shape by the regulators and forced to pay for the upkeep needed. >>>>> >>>>> If you applied the identical regulations to fiber, it too would (and >>>>> could) be just as much a "it KEEPS WORKING" system as the old copper >>>>> POTS system was. All the fiber would need to be all but identical is >>>>> for a pair of power conductors (yes copper wires, since glass happens >>>>> to be an electrical insulator) to be run along with each bundle, and >>>>> for the demarc terminals in each home (plus one of the phone handsets) >>>>> to be powered from the fiber bundle power conductors. >>>> >>>> That would not happen. >>> >>> Agreed. I highly doubt such would ever occur to the regulators as >>> well. My point is, it would be /possible/ for the fiber bundle to >>> carry a single copper pair used only to provide the small power >>> necessary to power the end point just like old style analog POTS phones >>> were powered by the line from the switch. >> >>Thing is, they would have to power the ONT or the router, and do so for >>all customers the full time, even if they are not using their phones >>actively at the moment. That is no small power, it can be 2..3 amps at >>12 volts per client (based on the ratings of the power wall wart of my >>router. >> >>That is not a small power. Orders of magnitude over what POTS needs: all >>houses not actively using the phone draw no power at all. >> >>> >>>> What could happen is mandating the router or ONT have a battery backup >>>> included, or at least optional. As simple as installing a bunch of AA >>>> batteries. >>> >>> Yep, that's already what Verizon does with their FIOS service. One >>> gets either a lead acid battery (UPS style battery) that will power the >>> ONT for "some time" on a power fail, or one gets a rather large box >>> that holds something like 12 D sized alkaline cell batteries as the >>> "backup power" should mains be out. I'm not sure if the different >>> types arrive based on price level purchased, or just on "previously, >>> they privided this, now they provide that". >>> > > The wall wart rating is a ceiling, not the normal draw, but the basic problem is > still real. > > A plain POTS set is almost unfairly cheap to keep alive. On-hook, it is > basically a supervised loop drawing almost nothing at the subscriber end; off- > hook it is tens of milliamps from a central battery plant that was built, > maintained, and regulated around that job. > > An ONT plus router is a different animal. Even if the ONT idles well below its > adapter rating, it is still active electronics at every customer site. If the > service needs voice, routing, WiFi, or an ATA alive during an outage, then the > backup problem has moved from one hardened central office to a pile of little > boxes in houses, closets, and garages. > > That is why the old system felt magic. It was not the copper. It was the > engineering assumption that the network had to power the endpoint and keep doing > so when the customer's mains failed. Yep, exactly. The original engineering assumption was the central plant had to power the end points. And that was made, at the time, not because anyone thought about "emergency services calls" (such a concept simply did not exist before there was a widespread telephone network installed). The original design parameter of "central office powers the end points" was made because the phone network was being installed during the same time frame that mains electricity was first being installed as well. There was no guarantee that homes being wired for phones would have mains power yet, therefore the need for the phones to be powered from the central plant. > Fiber can be made reliable too, but only if the same requirement is > written down and paid for instead of being waved away as an optional > battery accessory. Yep, it would add expense. And the companies would cry-baby enough that they would end up wanting to charge $500/month or more for what they now charge $65/month if they were forced to make it equally as reliable.
[toc] | [prev] | [next] | [standalone]
| From | Rich <rich@example.invalid> |
|---|---|
| Date | 2026-06-02 18:21 +0000 |
| Message-ID | <10vn6ve$33tsa$5@dont-email.me> |
| In reply to | #87342 |
Carlos E.R. <robin_listas@es.invalid> wrote: > On 2026-06-01 20:30, Rich wrote: >> Carlos E.R. <robin_listas@es.invalid> wrote: >>> On 2026-06-01 05:20, Rich wrote: >>>> c186282 <c186282@nnada.net> wrote: >>>>> I've EXPERIENCED tower networks Going DOWN ... they have maybe >>>>> three days worth of power backup. Then it's 1826 again. >>>>> >>>>> But copper KEEPS WORKING. Simple and sure. >>>> >>>> ... >>>> >>>> If you applied the identical regulations to fiber, it too would >>>> (and could) be just as much a "it KEEPS WORKING" system as the old >>>> copper POTS system was. All the fiber would need to be all but >>>> identical is for a pair of power conductors (yes copper wires, >>>> since glass happens to be an electrical insulator) to be run along >>>> with each bundle, and for the demarc terminals in each home (plus >>>> one of the phone handsets) to be powered from the fiber bundle >>>> power conductors. >>> >>> That would not happen. >> >> Agreed. I highly doubt such would ever occur to the regulators as >> well. My point is, it would be /possible/ for the fiber bundle to >> carry a single copper pair used only to provide the small power >> necessary to power the end point just like old style analog POTS >> phones were powered by the line from the switch. > > Thing is, they would have to power the ONT or the router, and do so > for all customers the full time, even if they are not using their > phones actively at the moment. That is no small power, it can be > 2..3 amps at 12 volts per client (based on the ratings of the power > wall wart of my router. Don't look at the label on the wart as the consumption of the device. The wart's labels are what it is rated to output without lighting your house on fire. If you measure the actual draw of the connected devices, you'll often find it is much less than the wart's max 2..3 amps. Often substantially less. In any case, that is also fixable. Run the power conductors at a higher voltage (48v -- the POE voltage) or even whatever your mains voltage is (220 in Spain?). Then the current in the big cable is much reduced, even with every end point 'running' and drawing power. It can be done, but it is also very much a not likely to be done thing as well. Of course this would likely mean fewer "end points" on each arm from the local switch, as no matter how high one runs the voltage on the power pair, there is a limit of how many demarc's it can power at once. Alternately, each "fiber line" could include a pair of power conductors to power that one end-point (again likely running a higher voltage to cover for resistive losses in the long wires). But also, just an 'imagined possibility'. No regulator today would think of trying to impose any such requirement anyway.
[toc] | [prev] | [next] | [standalone]
| From | TheLastSysop <thelastsysop@dev.null> |
|---|---|
| Date | 2026-06-02 18:25 +0000 |
| Message-ID | <333de5e6978df739348e@dev.null> |
| In reply to | #87383 |
>On Tue, 2 Jun 2026 18:21:34 -0000 (UTC), Rich <rich@example.invalid> wrote: >Carlos E.R. <robin_listas@es.invalid> wrote: >> On 2026-06-01 20:30, Rich wrote: >>> Carlos E.R. <robin_listas@es.invalid> wrote: >>>> On 2026-06-01 05:20, Rich wrote: >>>>> c186282 <c186282@nnada.net> wrote: >>>>>> I've EXPERIENCED tower networks Going DOWN ... they have maybe >>>>>> three days worth of power backup. Then it's 1826 again. >>>>>> >>>>>> But copper KEEPS WORKING. Simple and sure. >>>>> >>>>> ... >>>>> >>>>> If you applied the identical regulations to fiber, it too would >>>>> (and could) be just as much a "it KEEPS WORKING" system as the old >>>>> copper POTS system was. All the fiber would need to be all but >>>>> identical is for a pair of power conductors (yes copper wires, >>>>> since glass happens to be an electrical insulator) to be run along >>>>> with each bundle, and for the demarc terminals in each home (plus >>>>> one of the phone handsets) to be powered from the fiber bundle >>>>> power conductors. >>>> >>>> That would not happen. >>> >>> Agreed. I highly doubt such would ever occur to the regulators as >>> well. My point is, it would be /possible/ for the fiber bundle to >>> carry a single copper pair used only to provide the small power >>> necessary to power the end point just like old style analog POTS >>> phones were powered by the line from the switch. >> >> Thing is, they would have to power the ONT or the router, and do so >> for all customers the full time, even if they are not using their >> phones actively at the moment. That is no small power, it can be >> 2..3 amps at 12 volts per client (based on the ratings of the power >> wall wart of my router. > >Don't look at the label on the wart as the consumption of the device. >The wart's labels are what it is rated to output without lighting your >house on fire. If you measure the actual draw of the connected >devices, you'll often find it is much less than the wart's max 2..3 >amps. Often substantially less. > >In any case, that is also fixable. Run the power conductors at a >higher voltage (48v -- the POE voltage) or even whatever your mains >voltage is (220 in Spain?). Then the current in the big cable is much >reduced, even with every end point 'running' and drawing power. It can >be done, but it is also very much a not likely to be done thing as >well. > >Of course this would likely mean fewer "end points" on each arm from >the local switch, as no matter how high one runs the voltage on the >power pair, there is a limit of how many demarc's it can power at once. > >Alternately, each "fiber line" could include a pair of power conductors >to power that one end-point (again likely running a higher voltage to >cover for resistive losses in the long wires). > >But also, just an 'imagined possibility'. No regulator today would >think of trying to impose any such requirement anyway. For a home setup the useful first step is to measure the real load, not size from the wall-wart label. A cheap plug-in wattmeter on the AC side, or an inline DC meter if the router/ONT uses a barrel connector, will usually show a much smaller steady draw than the adapter's maximum rating. If the goal is keeping voice or basic connectivity alive through short power cuts, a small DC UPS or a modest AC UPS sized from that measured load is a lot simpler than trying to make the access network provide line power. Then check whether the ONT, router and any ATA/DECT base all need backup; missing one box in that chain is the usual surprise. -- TheLastSysop <thelastsysop@dev.null> "I survived the great rm -rf / rehearsal and all I got was this .signature."
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2026-06-02 21:36 +0200 |
| Message-ID | <6vn3fmxrvv.ln2@Telcontar.valinor> |
| In reply to | #87384 |
On 2026-06-02 20:25, TheLastSysop wrote: >> On Tue, 2 Jun 2026 18:21:34 -0000 (UTC), Rich <rich@example.invalid> wrote: >> Carlos E.R. <robin_listas@es.invalid> wrote: >>> On 2026-06-01 20:30, Rich wrote: >>>> Carlos E.R. <robin_listas@es.invalid> wrote: >>>>> On 2026-06-01 05:20, Rich wrote: >>> Thing is, they would have to power the ONT or the router, and do so >>> for all customers the full time, even if they are not using their >>> phones actively at the moment. That is no small power, it can be >>> 2..3 amps at 12 volts per client (based on the ratings of the power >>> wall wart of my router. >> >> Don't look at the label on the wart as the consumption of the device. >> The wart's labels are what it is rated to output without lighting your >> house on fire. If you measure the actual draw of the connected >> devices, you'll often find it is much less than the wart's max 2..3 >> amps. Often substantially less. >> >> In any case, that is also fixable. Run the power conductors at a >> higher voltage (48v -- the POE voltage) or even whatever your mains >> voltage is (220 in Spain?). Then the current in the big cable is much >> reduced, even with every end point 'running' and drawing power. It can >> be done, but it is also very much a not likely to be done thing as >> well. >> >> Of course this would likely mean fewer "end points" on each arm from >> the local switch, as no matter how high one runs the voltage on the >> power pair, there is a limit of how many demarc's it can power at once. >> >> Alternately, each "fiber line" could include a pair of power conductors >> to power that one end-point (again likely running a higher voltage to >> cover for resistive losses in the long wires). >> >> But also, just an 'imagined possibility'. No regulator today would >> think of trying to impose any such requirement anyway. Correct, they wouldn't. > > For a home setup the useful first step is to measure the real load, not size > from the wall-wart label. A cheap plug-in wattmeter on the AC side, or an > inline DC meter if the router/ONT uses a barrel connector, will usually show a > much smaller steady draw than the adapter's maximum rating. > > If the goal is keeping voice or basic connectivity alive through short power > cuts, a small DC UPS or a modest AC UPS sized from that measured load is a lot > simpler than trying to make the access network provide line power. Then check > whether the ONT, router and any ATA/DECT base all need backup; missing one box > in that chain is the usual surprise. I have looked at small DC-UPS designed precisely to power the router, and they are designed for 3A. But one of them just has two AAA cells. That's damn not enough. <https://www.amazon.es/-/en/APC-Back-UPS-Connect-CP12036LI-Controladores/dp/B0CJ5D89Z9> <https://www.amazon.es/-/en/Internal-Battery-Lightweight-Protects-Overloads/dp/B07DPTF9VW> <https://www.amazon.es/-/en/Salicru-658BB000009-SPS-net2/dp/B0DHL4XRBW/> <https://www.amazon.es/-/en/Shanqiu-Router-Surveillance-Camera-Output/dp/B0FF9QS7LK/> -- Cheers, Carlos. ES🇪🇸, EU🇪🇺;
[toc] | [prev] | [next] | [standalone]
| From | Rich <rich@example.invalid> |
|---|---|
| Date | 2026-06-03 02:06 +0000 |
| Message-ID | <10vo275$3b3aj$1@dont-email.me> |
| In reply to | #87387 |
Carlos E.R. <robin_listas@es.invalid> wrote: > > I have looked at small DC-UPS designed precisely to power the router, > and they are designed for 3A. But one of them just has two AAA cells. > That's damn not enough. Two AAA cells will provide 3A, for a rather short length of time.... Yeah, there's not enough energy in two AAA cells to power a modern router for longer than very brief intervals, unless that same router is very minimal power draw itself.. > <https://www.amazon.es/-/en/APC-Back-UPS-Connect-CP12036LI-Controladores/dp/B0CJ5D89Z9> > > <https://www.amazon.es/-/en/Internal-Battery-Lightweight-Protects-Overloads/dp/B07DPTF9VW> > > <https://www.amazon.es/-/en/Salicru-658BB000009-SPS-net2/dp/B0DHL4XRBW/> > > <https://www.amazon.es/-/en/Shanqiu-Router-Surveillance-Camera-Output/dp/B0FF9QS7LK/> Interesting, I'd not encountered these style "UPS" boxes yet.
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2026-06-03 11:32 +0200 |
| Message-ID | <ru85fmxlce.ln2@Telcontar.valinor> |
| In reply to | #87342 |
On 2026-06-01 22:27, Carlos E.R. wrote: > On 2026-06-01 20:30, Rich wrote: >> Carlos E.R. <robin_listas@es.invalid> wrote: >>> On 2026-06-01 05:20, Rich wrote: >>>> c186282 <c186282@nnada.net> wrote: >>>>>    I've EXPERIENCED tower networks Going DOWN ... they have maybe >>>>>    three days worth of power backup. Then it's 1826 again. >>>>> >>>>>    But copper KEEPS WORKING. Simple and sure. >>>> >>>> Check that bet one winter when the ice storms pull down the mains >>>> cables powering your local copper exchange, and the snow is deep enough >>>> that the fuel trucks can't get to the exchange before its backup >>>> generators consume the diesel in their tanks. >>>> >>>> The copper *will* also stop working then as well. >>>> >>>> It only appears to keep working because there were several layers of >>>> redundancy backed in by the regulations. >>>> >>>> But those regulations are being sidelined now. Without those >>>> regulations keeping the companies honest, the old POTS that "just kept >>>> working" almost all the time will become just as flakey and offline at >>>> the slightest provocation as the other options. >>>> >>>> A *lot* of expense was spent to make the old copper POTS just "keep >>>> working", not a bit of it "just working" was because it was "copper". >>>> It was all because the companies operating it were kept whipped into >>>> shape by the regulators and forced to pay for the upkeep needed. >>>> >>>> If you applied the identical regulations to fiber, it too would (and >>>> could) be just as much a "it KEEPS WORKING" system as the old copper >>>> POTS system was. All the fiber would need to be all but identical is >>>> for a pair of power conductors (yes copper wires, since glass happens >>>> to be an electrical insulator) to be run along with each bundle, and >>>> for the demarc terminals in each home (plus one of the phone handsets) >>>> to be powered from the fiber bundle power conductors. >>> >>> That would not happen. >> >> Agreed. I highly doubt such would ever occur to the regulators as >> well. My point is, it would be /possible/ for the fiber bundle to >> carry a single copper pair used only to provide the small power >> necessary to power the end point just like old style analog POTS phones >> were powered by the line from the switch. > > Thing is, they would have to power the ONT or the router, and do so for > all customers the full time, even if they are not using their phones > actively at the moment. That is no small power, it can be 2..3 amps at > 12 volts per client (based on the ratings of the power wall wart of my > router. > > That is not a small power. Orders of magnitude over what POTS needs: all > houses not actively using the phone draw no power at all. There is something else. It would be a tree network of DC cables going out from a central node. Two thick cables going out, perhaps 48V DC, then branching at each home (and fuses). At least part of the network would be thick cables. Which means, some people would try to steal them. -- Cheers, Carlos. ES🇪🇸, EU🇪🇺;
[toc] | [prev] | [next] | [standalone]
| From | Nuno Silva <nunojsilva@invalid.invalid> |
|---|---|
| Date | 2026-06-03 11:43 +0100 |
| Message-ID | <10vp0gp$3io0e$1@dont-email.me> |
| In reply to | #87415 |
On 2026-06-03, Carlos E.R. wrote: > There is something else. It would be a tree network of DC cables going > out from a central node. Two thick cables going out, perhaps 48V DC, > then branching at each home (and fuses). At least part of the network > would be thick cables. Which means, some people would try to steal > them. Is it true some people even try to steal the kind of bare wiring that is used carry 25 kV 50 Hz? -- Nuno Silva
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2026-06-03 13:05 +0200 |
| Message-ID | <rce5fmxkbi.ln2@Telcontar.valinor> |
| In reply to | #87424 |
On 2026-06-03 12:43, Nuno Silva wrote: > On 2026-06-03, Carlos E.R. wrote: > >> There is something else. It would be a tree network of DC cables going >> out from a central node. Two thick cables going out, perhaps 48V DC, >> then branching at each home (and fuses). At least part of the network >> would be thick cables. Which means, some people would try to steal >> them. > > Is it true some people even try to steal the kind of bare wiring that is > used carry 25 kV 50 Hz? > They steal the live catenary from the railway... Sometimes someone dies. The distribution wires, I have not heard of it. Too high? We would need harsher laws to protect the railways. -- Cheers, Carlos. ES🇪🇸, EU🇪🇺;
[toc] | [prev] | [next] | [standalone]
Page 4 of 11 — ← Prev page 1 2 3 [4] 5 6 … 11 Next page →
Back to top | Article view | comp.os.linux.misc
csiph-web