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 227 — 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 Rich <rich@example.invalid> - 2026-06-04 03:51 +0000
Re: Redundancy/Survival Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-06-04 04:30 +0000
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 Rich <rich@example.invalid> - 2026-06-04 04:15 +0000
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-04 07:36 +0200
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-06-04 02:19 -0400
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-04 08:34 +0200
Re: Redundancy/Survival Andy Burns <usenet@andyburns.uk> - 2026-06-04 08:18 +0100
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 Nuno Silva <nunojsilva@invalid.invalid> - 2026-06-04 01:01 +0100
Re: Redundancy/Survival InterLinked <usenet@phreaknet.org> - 2026-06-03 21:18 -0400
Re: Redundancy/Survival Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-06-04 04:30 +0000
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-04 07:44 +0200
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-06-04 00:26 -0400
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-04 07:53 +0200
Re: Redundancy/Survival The Natural Philosopher <tnp@invalid.invalid> - 2026-06-03 11:49 +0100
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-06-04 01:03 -0400
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 c186282 <c186282@nnada.net> - 2026-06-04 00:30 -0400
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-04 07:55 +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-06-04 02:11 -0400
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 c186282 <c186282@nnada.net> - 2026-06-04 00:46 -0400
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-04 08:09 +0200
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 InterLinked <usenet@phreaknet.org> - 2026-06-03 21:30 -0400
Re: Redundancy/Survival Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-06-04 04:30 +0000
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-04 08:13 +0200
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 12 — ← Prev page 1 2 3 [4] 5 6 … 12 Next page →
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2026-06-03 11:57 +0100 |
| Message-ID | <10vp1bb$3igml$4@dont-email.me> |
| In reply to | #87399 |
On 03/06/2026 03:15, c186282 wrote: > One strength of StarLink though is that it > is very DISPERSED .... thousands of sats. > I think they can kinda do "zig-bee". I wonder if they run OSPF internally? -- "An intellectual is a person knowledgeable in one field who speaks out only in others...” Tom Wolfe
[toc] | [prev] | [next] | [standalone]
| From | Rich <rich@example.invalid> |
|---|---|
| Date | 2026-06-03 14:40 +0000 |
| Message-ID | <10vped6$3n936$2@dont-email.me> |
| In reply to | #87399 |
c186282 <c186282@nnada.net> wrote: > On 6/2/26 06:11, The Natural Philosopher wrote: >> On 02/06/2026 07:58, c186282 wrote: >>> and Satanic coup those WON'T get at the satellites. >> >> wanna bet yer life on that? Bhwahahaha... > > > As mentioned somewhere, you can still do basic TELEGRAPHY over > copper pairs. That's very robust 1860 tech. Hey, worst case ... > we'd still have SOMETHING. Yes, but first you need a "copper pair" connecting the two points between which you wish to communicate. And today, those bespoke copper pairs no longer exist (most have been replaced with thin glass strands over which laser light is transmitted, which won't allow for "basic telegraphy"). So you'd have to start by stringing miles upon miles of copper pairs between each location that you wanted to communicate. That's a massive undertaking, which has to happen *before* you can communicate via basic telegraphy.
[toc] | [prev] | [next] | [standalone]
| From | Rich <rich@example.invalid> |
|---|---|
| Date | 2026-05-29 04:30 +0000 |
| Message-ID | <10vb4pn$3tios$1@dont-email.me> |
| In reply to | #87217 |
c186282 <c186282@nnada.net> wrote: > Kind of agree with the sentiment that copper should always be at > hand for 'emergency' communications at a minimum. Towers die, cell > contracts expire, copper keeps on going. The legacy copper phones only "kept on going" because POTS (copper) phone service was a highly regulated utility with requirements for upkeep and maintence so that it /would/ just keep on going. Without that upkeep, it eventually falls into disrepair and stops working just like the rest. It's only real difference from towers is fewer possibilities to go wrong when the 'system' is just a long pair of copper wires vs. complex electronics systems for a radio tower (i.e., no capicators to dry out and fail in a long pair of copper wires). Most failures were mechanical (something physically tearing down the wires) or chemical (water infiltration corroding the connection points). But fail it did. If the lines were above ground then tree branches (or automobiles) would take out the lines. If the lines were underground then water infiltration into the conduits would result in noise or nothing working. I had this one myself on my pair once. Line that had been nice and quiet (and worked well for DSL) suddenly sounded like someone was scraping a turntable needle over a vinyl record constantly. Reported it to Verizon, they took some time to fix, but I eventually learned the cause was an underground wiring vault a couple miles away had flooded. In areas with significant winter ice storms and above ground copper then ice storms would routinely take out the copper phones until the wires were repaired. This routinely happened in very rural areas that also got ice storms. But your individual experience dependend upon what happened with your specific pair. If you were lucky and no falling trees, drunk drivers, or ice storms happened to pull down your copper pair, and no leaky underground conduits soaked it, then to you it appeared to be impervious to failure. Reality from the other size (the phone company) viewpoint is that something, somewhere, was always failing and needing repair.
[toc] | [prev] | [next] | [standalone]
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2026-05-29 01:34 -0400 |
| Message-ID | <UYicndKFJtzjuIT3nZ2dnZfqnPSdnZ2d@giganews.com> |
| In reply to | #87255 |
On 5/29/26 00:30, Rich wrote: > c186282 <c186282@nnada.net> wrote: >> Kind of agree with the sentiment that copper should always be at >> hand for 'emergency' communications at a minimum. Towers die, cell >> contracts expire, copper keeps on going. > > The legacy copper phones only "kept on going" because POTS (copper) > phone service was a highly regulated utility with requirements for > upkeep and maintence so that it /would/ just keep on going. > > Without that upkeep, it eventually falls into disrepair and stops > working just like the rest. Well ... KEEP the requirements ! The USA sill keeps a few old battleships and bombers and such alive - Just In Case. Still supports the HAMs, Just In Case. The THEME of this thread is Tech Redundancy - and that means one or MORE back-layers you can employ - Just In Case. IMHO, those who do NOT have "Just In Case" hardwired in are DOOMED if the shit hits the fan. Does starving/rotting to death sound good to you ??? The AARL handbook even includes Spark-Gap transmitters/receivers - 1899 tech. Ya NEVER KNOW when things might suddenly get SO SHITTY that such methods are All That's Left. Frankly I see every copper pair as a Potential Asset. "They" shouldn't be ALLOWED to pull it all out. > It's only real difference from towers is fewer possibilities to go > wrong when the 'system' is just a long pair of copper wires vs. complex > electronics systems for a radio tower (i.e., no capicators to dry out > and fail in a long pair of copper wires). Most failures were > mechanical (something physically tearing down the wires) or chemical > (water infiltration corroding the connection points). 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. > But fail it did. If the lines were above ground then tree branches (or > automobiles) would take out the lines. If the lines were underground > then water infiltration into the conduits would result in noise or > nothing working. I had this one myself on my pair once. Line that had > been nice and quiet (and worked well for DSL) suddenly sounded like > someone was scraping a turntable needle over a vinyl record constantly. > Reported it to Verizon, they took some time to fix, but I eventually > learned the cause was an underground wiring vault a couple miles away > had flooded. > > In areas with significant winter ice storms and above ground copper > then ice storms would routinely take out the copper phones until the > wires were repaired. This routinely happened in very rural areas that > also got ice storms. > > But your individual experience dependend upon what happened with your > specific pair. If you were lucky and no falling trees, drunk drivers, > or ice storms happened to pull down your copper pair, and no leaky > underground conduits soaked it, then to you it appeared to be > impervious to failure. Reality from the other size (the phone company) > viewpoint is that something, somewhere, was always failing and needing > repair. I do understand the basics here ... copper CAN be a pain in the ass sometimes. However it's EASY to fix, nice LOW tech. Don't throw it away. I've been in Total Disaster zones TWICE in my life. ALL infrastructure TRASHED. No communications. However the COPPER either stays up, or comes BACK up first. The lower-tech aspect is a POSITIVE. Until we have like 'sub-space radio' as a USB dongle, KEEP most of the copper. The theme of this thread is "REDUNDANCY" - and it's an IMPORTANT thing. Very important. Should add "alt.survival" to the groups .....
[toc] | [prev] | [next] | [standalone]
| From | rbowman <bowman@montana.com> |
|---|---|
| Date | 2026-05-29 06:36 +0000 |
| Message-ID | <n7sqf4Fu3pfU4@mid.individual.net> |
| In reply to | #87260 |
On Fri, 29 May 2026 01:34:37 -0400, c186282 wrote: > The AARL handbook even includes Spark-Gap transmitters/receivers - > 1899 tech. Ya NEVER KNOW when things might suddenly get SO SHITTY that > such methods are All That's Left. My code needs a little brush up. It never came easy but I did manage to get good enough to get the Advanced ticket. I still am Advanced. It's grandfathered in although it doesn't exist anymore. Extra is more administrative than tech so I never bothered to get it even after they dropped code.
[toc] | [prev] | [next] | [standalone]
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2026-05-31 00:38 -0400 |
| Message-ID | <mRWdnV86O9inJob3nZ2dnZfqnPSdnZ2d@giganews.com> |
| In reply to | #87267 |
On 5/29/26 02:36, rbowman wrote: > On Fri, 29 May 2026 01:34:37 -0400, c186282 wrote: > >> The AARL handbook even includes Spark-Gap transmitters/receivers - >> 1899 tech. Ya NEVER KNOW when things might suddenly get SO SHITTY that >> such methods are All That's Left. > > My code needs a little brush up. It never came easy but I did manage to > get good enough to get the Advanced ticket. I still am Advanced. It's > grandfathered in although it doesn't exist anymore. > > Extra is more administrative than tech so I never bothered to get it even > after they dropped code. 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. Using the '-n' param on several of those utils DOES let me store pix and vids ... you just don't see it 'live'. The OTHER prob ... almost all the good utils are tuned to work with Web and/or IP cams. The PiCams are neither. It IS possible to do a udp or tcp h-264 stream ... but it's not rtsp or mjpeg and haven't been able yet to get even VLC to pick up the stream. So, future ... USB cams. Gotta find connectors that aren't huge though. My otherwise useless P-0 ... it IS still tiny and I can fit it into a weatherproof box I have that would NOT quite fit the full PI profile. Oh, the Pi4 I finally got the cam to work with, DAMN that CPU chip can get HOT, even WITH a heat-sink attached ! By luck I had a spare little FAN ..... My Dremel Tool JUST managed to carve-out a space in the plastic case for the cam ribbon cable, and then DIED - motor not coupled to the output shaft. Must be some plastic/rubber LoveJoy or something. Never had one of those die before. Oh well, straight into the trash (KEPT the cord though).
[toc] | [prev] | [next] | [standalone]
| From | TheLastSysop <thelastsysop@dev.null> |
|---|---|
| Date | 2026-05-31 05:09 +0000 |
| Message-ID | <d371c36a695dc3112b7d@dev.null> |
| In reply to | #87301 |
>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.
A safe first check is whether the current stack sees the camera at all:
libcamera-hello --list-cameras
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
Then on another box, tell VLC what it is receiving rather than letting it guess:
vlc tcp/h264://PI_ADDRESS:8888
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.
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.
--
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-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]
Page 4 of 12 — ← Prev page 1 2 3 [4] 5 6 … 12 Next page →
Back to top | Article view | comp.os.linux.misc
csiph-web