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 193 — 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 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 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 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 "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 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 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 3 of 10 — ← Prev page 1 2 [3] 4 5 … 10 Next page →
| From | Rich <rich@example.invalid> |
|---|---|
| Date | 2026-06-02 18:09 +0000 |
| Message-ID | <10vn68q$33tsa$3@dont-email.me> |
| In reply to | #87348 |
InterLinked <usenet@phreaknet.org> wrote: > On 6/1/2026 6:15 AM, Carlos E.R. wrote: >> On 2026-06-01 03:45, InterLinked wrote: >>> If you are waiting for some "regulator" to come and save POTS service >>> for everyone, you are sadly mistaken. But you can still submit >>> comments, make calls, etc. to try to fight back against AT&T and the FCC. >> >> In Spain, the official minimum internet service the Spanish government >> guarantees as part of the Universal Telecommunications Service is 10 >> Mbps >> (<https://avance.digital.gob.es/es-es/servicios/informeuniversal/paginas/index.aspx?utm_source=chatgpt.com>). >> The obligation is currently provided through Movistar as the designated >> operator. What they don't specify is the technology. POTS is out of the >> picture. >> >> And they are considering increasing the minimum to 100 Mbps. > > Except that's the wrong priority. We'll guarantee everyone have 100 > Mbps, but not the ability to call 911 (or whatever your local emergency > number is)? *If* the regulators applied the same serive guarantees to that 100Mbps pipe that they previously applied to the POTS phone lines, you'd have the ability to call 911 during an actual emergency even when the 100Mbps service replaced your old POTS line. But sadly the 100Mbps replacements don't have the same regulatory service and uptime requirements, and so they are not an equivalent replacement for the old POTS service.
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2026-06-02 21:26 +0200 |
| Message-ID | <scn3fmxols.ln2@Telcontar.valinor> |
| In reply to | #87381 |
On 2026-06-02 20:09, Rich wrote: > InterLinked <usenet@phreaknet.org> wrote: >> On 6/1/2026 6:15 AM, Carlos E.R. wrote: >>> On 2026-06-01 03:45, InterLinked wrote: >>>> If you are waiting for some "regulator" to come and save POTS service >>>> for everyone, you are sadly mistaken. But you can still submit >>>> comments, make calls, etc. to try to fight back against AT&T and the FCC. >>> >>> In Spain, the official minimum internet service the Spanish government >>> guarantees as part of the Universal Telecommunications Service is 10 >>> Mbps >>> (<https://avance.digital.gob.es/es-es/servicios/informeuniversal/paginas/index.aspx?utm_source=chatgpt.com>). >>> The obligation is currently provided through Movistar as the designated >>> operator. What they don't specify is the technology. POTS is out of the >>> picture. >>> >>> And they are considering increasing the minimum to 100 Mbps. >> >> Except that's the wrong priority. We'll guarantee everyone have 100 >> Mbps, but not the ability to call 911 (or whatever your local emergency >> number is)? > > *If* the regulators applied the same serive guarantees to that 100Mbps > pipe that they previously applied to the POTS phone lines, you'd have > the ability to call 911 during an actual emergency even when the > 100Mbps service replaced your old POTS line. > > But sadly the 100Mbps replacements don't have the same regulatory > service and uptime requirements, and so they are not an equivalent > replacement for the old POTS service. Absolutely. Spot on. I assume that the long paper on things that everybody must have access to, even in rural communities, include that everybody can dial 911 (112 here). And many things. It does not only say that people most have 10 Mbps. Notice that having 10 Mbps, or better, 100, is not just something to look good. It is needed so that people can work from home or run small businesses even if they live in the middle of nowhere. Today, if people do not have network, they leave the area to live elsewhere. It is a serious need. For example, if there is a village with 200 inhabitants with a small shop and a bar, those places need internet in order to be able to accept plastic card payments. And considering there is not a bank at the site to get cash to pay, the villagers have to pay with plastic. Or the visitors. What they don't currently say is that Internet/phone must survive an Energy zero for, say, 8 hours. But truth be said, the government here did query the industry to tell what would be needed to guarantee service during a zero. -- Cheers, Carlos. ES🇪🇸, EU🇪🇺;
[toc] | [prev] | [next] | [standalone]
| From | Nuno Silva <nunojsilva@invalid.invalid> |
|---|---|
| Date | 2026-06-03 12:48 +0100 |
| Message-ID | <10vp49g$3io0e$5@dont-email.me> |
| In reply to | #87386 |
On 2026-06-02, Carlos E.R. wrote: [...] > For example, if there is a village with 200 inhabitants with a small > shop and a bar, those places need internet in order to be able to > accept plastic card payments. And considering there is not a bank at > the site to get cash to pay, the villagers have to pay with > plastic. Or the visitors. (Out of curiosity, if Visa and Mastercard cards are common in .es: Is there no way to process card payments off-line in such towns?) -- Nuno Silva
[toc] | [prev] | [next] | [standalone]
| From | Rich <rich@example.invalid> |
|---|---|
| Date | 2026-06-03 14:35 +0000 |
| Message-ID | <10vpe2r$3n936$1@dont-email.me> |
| In reply to | #87438 |
Nuno Silva <nunojsilva@invalid.invalid> wrote: > On 2026-06-02, Carlos E.R. wrote: > > [...] >> For example, if there is a village with 200 inhabitants with a small >> shop and a bar, those places need internet in order to be able to >> accept plastic card payments. And considering there is not a bank at >> the site to get cash to pay, the villagers have to pay with >> plastic. Or the visitors. > > (Out of curiosity, if Visa and Mastercard cards are common in .es: Is > there no way to process card payments off-line in such towns?) The card networks moved away from "off-line" card processing long ago. At this point they (the card networks) likely don't care about supporting tiny "locations" with only a few hundred folks for accepting card payments "offline" as the amounts would be such a tiny fraction of their gross, but amount to a huge amount of work, effor, and expense to support. Couple that with the fact that "offline" processing can provide additional avenues for attempted or actual fraud and they simply expect merchants to be able to have one of the 'nfc scan terminals' and to be able to network back to their servers for all the authentication and authorization.
[toc] | [prev] | [next] | [standalone]
| From | Nuno Silva <nunojsilva@invalid.invalid> |
|---|---|
| Date | 2026-06-03 17:25 +0100 |
| Message-ID | <10vpkhs$3p8ag$1@dont-email.me> |
| In reply to | #87441 |
On 2026-06-03, Rich wrote: > Nuno Silva <nunojsilva@invalid.invalid> wrote: >> On 2026-06-02, Carlos E.R. wrote: >> >> [...] >>> For example, if there is a village with 200 inhabitants with a small >>> shop and a bar, those places need internet in order to be able to >>> accept plastic card payments. And considering there is not a bank at >>> the site to get cash to pay, the villagers have to pay with >>> plastic. Or the visitors. >> >> (Out of curiosity, if Visa and Mastercard cards are common in .es: Is >> there no way to process card payments off-line in such towns?) > > The card networks moved away from "off-line" card processing long ago. ... wait, then why did these two axe precisely the "on-line" cards - Electron and Maestro? I thought they decided to *prefer* "off-line" processing. > At this point they (the card networks) likely don't care about > supporting tiny "locations" with only a few hundred folks for accepting > card payments "offline" as the amounts would be such a tiny fraction of > their gross, but amount to a huge amount of work, effor, and expense to > support. Aren't "credit" cards usually "off-line"? Or that changed? > Couple that with the fact that "offline" processing can provide > additional avenues for attempted or actual fraud and they simply expect > merchants to be able to have one of the 'nfc scan terminals' and to be > able to network back to their servers for all the authentication and > authorization. I'm not so sure about fraud, I'd not be surprised if magstripes, where still present, or the optionality of PIN allowed more fraud than smartcard "off-line" transactions. -- Nuno Silva
[toc] | [prev] | [next] | [standalone]
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2026-06-02 02:58 -0400 |
| Message-ID | <fnidnaxJ3ful4oP3nZ2dnZfqnPadnZ2d@giganews.com> |
| In reply to | #87329 |
On 6/1/26 06:15, Carlos E.R. wrote: > On 2026-06-01 03:45, InterLinked wrote: >> On 5/30/2026 11:29 PM, c186282 wrote: >>> On 5/30/26 07:09, Carlos E.R. wrote: >>>> On 2026-05-30 10:29, c186282 wrote: >>>>> >>>>> I don't disagree. >>>>> >>>>> However SOMETIMES it's worth mandating >>>>> a backwards-compatible system be kept >>>>> alive and working. >>>>> >>>>> Having experienced major service problems, >>>>> I'm gonna say that keeping the copper going >>>>> for at least another 10 years IS good sense. >>>>> >>>> >>>> Not going to happen. >>> >>> We shall see. >>> >>> In USA there *are* some federal regs. Corps >>> trying to get AROUND those might be held >>> guilty/culpable. >>> >> >> I hate to burst your bubble, but the FCC here in the US is a captured >> agency. They've been catering to the industry for years now, and >> especially under the current administration, have only been seeking to >> heavily deregulate and boost industry profits, consumers be damned. >> >> I mentioned earlier that back in March, the FCC released an order >> where they declared they would preempt state requirements that had the >> effect of requiring companies to retain traditional service, as part >> of the FCC's agenda of advancing the "IP transition" and sunsetting POTS. >> >> This is playing out in California right now. AT&T sued the California >> Public Utilities Commission and AG last week and asked the FCC to >> preempt California's requirements that all consumers have access to >> basic voice service. 200,000 customers just got notices that AT&T >> intends to disconnect their service. Separately, there is a >> constitutional amendment being quietly considered to bar the CPUC from >> regulating telecom. AT&T is sure trying to cover its bases... >> >> It's a timely discussion. If you want to keep POTS around, submit >> comments/opposition to the FCC on the relevant dockets until June 22, >> see https://savelandlines.org/ >> >> If you are waiting for some "regulator" to come and save POTS service >> for everyone, you are sadly mistaken. But you can still submit >> comments, make calls, etc. to try to fight back against AT&T and the FCC. > > In Spain, the official minimum internet service the Spanish government > guarantees as part of the Universal Telecommunications Service is 10 > Mbps (<https://avance.digital.gob.es/es-es/servicios/informeuniversal/ > paginas/index.aspx?utm_source=chatgpt.com>). The obligation is currently > provided through Movistar as the designated operator. What they don't > specify is the technology. POTS is out of the picture. > > And they are considering increasing the minimum to 100 Mbps. Hmmm ... had to switch to 5G internet for several annoying reasons. The old Gen2 DSL was actually better. RARELY get 10mbps - I'm too far from the towers, metal roof, reinforced concrete. Tried every place in the house. HAVE seen 'bursts' to 30mbps ... but those only last a few minutes. 5 to 8 mbps is more 'typical'. Less is often seen too alas. NOT sure how Spain is gonna guarentee this fast net to all. LOTS more (subsidized) towers operating at a de-facto loss ??? Typical 'socialist' thinking. I've looked into StarLink. Price isn't TOO bad, but the allowed daily/monthly data consumption is too low for my needs. I often download Linux/etc distros for eval or use - typically 1-4 gigs these days. Many distros can 'update' with a gig more more. Did that several times the last month. The only good bit is that if there's a hurricane with tornadoes and tidal surge and Satanic coup those WON'T get at the satellites. MAY buy basic pkg as a 'safety' so I could do simple mail/banking/ordering.
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2026-06-02 11:11 +0100 |
| Message-ID | <10vma8l$2rkdb$1@dont-email.me> |
| In reply to | #87357 |
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... -- Canada is all right really, though not for the whole weekend. "Saki"
[toc] | [prev] | [next] | [standalone]
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2026-06-02 22:15 -0400 |
| Message-ID | <08WdnZbiT4mmE4L3nZ2dnZfqnPSdnZ2d@giganews.com> |
| In reply to | #87363 |
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... Well Vlad/Xi *can* get to the satellites :-) A super-massive solar flare can too. One strength of StarLink though is that it is very DISPERSED .... thousands of sats. I think they can kinda do "zig-bee". So still, imho, we need SOME at least domestic layer that's DIFFICULT for Vlad to get at. Not much to do about the solar flare alas ... 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.
[toc] | [prev] | [next] | [standalone]
| From | InterLinked <usenet@phreaknet.org> |
|---|---|
| Date | 2026-06-02 22:32 -0400 |
| Message-ID | <10vo3o7$3bkkd$2@dont-email.me> |
| In reply to | #87399 |
On 6/2/2026 10:15 PM, c186282 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... > > Well Vlad/Xi *can* get to the satellites :-) > > A super-massive solar flare can too. > > One strength of StarLink though is that it > is very DISPERSED .... thousands of sats. > I think they can kinda do "zig-bee". > > So still, imho, we need SOME at least domestic > layer that's DIFFICULT for Vlad to get at. > > Not much to do about the solar flare alas ... > > 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. I fully expect that with the total devolution of telephony going on, some people might resort back to doing telephony over barbed wire fences again... and not by choice! It's incredible the kind of double speak that exists today... "progress" and "21st century" really means going back 100+ years in a lot ways, before common battery, and back to when a lot of rural areas lacked phone service because phone companies didn't want to run lines to them, so they ran their own party lines over barbed wire networks... here we go again...
[toc] | [prev] | [next] | [standalone]
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2026-06-03 02:33 -0400 |
| Message-ID | <a9qdnfdK25dyV4L3nZ2dnZfqn_adnZ2d@giganews.com> |
| In reply to | #87402 |
On 6/2/26 22:32, InterLinked wrote: > On 6/2/2026 10:15 PM, c186282 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... >> >> Well Vlad/Xi *can* get to the satellites :-) >> >> A super-massive solar flare can too. >> >> One strength of StarLink though is that it >> is very DISPERSED .... thousands of sats. >> I think they can kinda do "zig-bee". >> >> So still, imho, we need SOME at least domestic >> layer that's DIFFICULT for Vlad to get at. >> >> Not much to do about the solar flare alas ... >> >> 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. > > I fully expect that with the total devolution of telephony going on, > some people might resort back to doing telephony over barbed wire fences > again... Do NOT entirely disagree with that ! > and not by choice! It's incredible the kind of double speak > that exists today... "progress" and "21st century" really means going > back 100+ years in a lot ways, before common battery, and back to when a > lot of rural areas lacked phone service because phone companies didn't > want to run lines to them, so they ran their own party lines over barbed > wire networks... here we go again... ENDLESS bullshit from the corps about the Great Virtues of nuking the Old Stuff. Sounds SO sane. It's not. Has become VERY clear the past few years how EASILY all the 'modern' stuff can be TRASHED. Vlad/Xi are part of the problem, but Nature is a significant other. "Telegraph" stations DID/CAN work. They'd have to be kind of a per-neighborhood/block thing. The tech, as said, is robust 1860 - relay-based amplifiers. But you have to HAVE some copper Still There. Otherwise, well, 1919 radio tech. Also works even after a huge disaster, but more complicated and less-directed. Find an older AARL Radio manual, even "spark gap" radio is discussed - the how, the equations. LOVE to see that stuff ! It's how to basically hold up comm tech even AFTER a Worst Case situation. Some HAMs also still work TUBE/VALVE radios for fun. Those are mostly immune to EMP or solar flares and you're not gonna HACK them - almost NON-tech. Something BAD is gonna happen - by human or other means. Happens in localities even now, but could become worldwide. Even crappy comm tech can make all the diff between now and the Dark Ages. Early 1800s USA ... you sent mail by crude early trains or horse-mounted delivery guys. Took like two or three WEEKS to get even a short message from NYC to California. Telegraph finally did come along, but 'finally' - and they charged by the word/letter. The Old Shitty World is NOT that far behind us. Current High-Tech is oft TOO sensitive, TOO vulnerable. It's not good policy. "Commercial" may not agree - but govt/mil really OUGHT to know.
[toc] | [prev] | [next] | [standalone]
| 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]
Page 3 of 10 — ← Prev page 1 2 [3] 4 5 … 10 Next page →
Back to top | Article view | comp.os.linux.misc
csiph-web