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 118 — 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 "Carlos E.R." <robin_listas@es.invalid> - 2026-06-02 10:16 +0200
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-06-02 02:58 -0400
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 InterLinked <usenet@phreaknet.org> - 2026-06-01 19:00 -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 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 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-01 13:08 +0000
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-01 22:55 +0200
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 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 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
| 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 | InterLinked <usenet@phreaknet.org> |
|---|---|
| Date | 2026-06-01 19:00 -0400 |
| Message-ID | <10vl2v5$2icdr$1@dont-email.me> |
| In reply to | #87341 |
On 6/1/2026 2:30 PM, Rich wrote: > Carlos E.R. <robin_listas@es.invalid> wrote: >> On 2026-06-01 05:20, Rich wrote: >> 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 lead acid is the older variety and the D cell is the newer one. I had to buy the older kind on eBay as they are not really available anymore. Neither is sufficient, you can get 8-24 hours of standby power with these kinds, but that's woefully inadequate in an extended outage, and both are now a significant cost that consumers are now expected to bear.
[toc] | [prev] | [next] | [standalone]
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2026-05-29 02:17 -0400 |
| Message-ID | <97OcnWwzhIQAsoT3nZ2dnZfqnPSdnZ2d@giganews.com> |
| In reply to | #87255 |
Argue crap all you want - the providers are generally REQUIRED to keep the POTS running and I support that. Note the theme here - "Redundancy". Keep EVERYTHING that worked. Add on new stuff all you want, but ..... Use the Laws. Hire class-action lawyers if needed to kick ass. Oh, and even TELEGRAPH service should be preserved over a few copper lines. Slow, but WORKED and was very robust. First comm network that could use pre-Tube/Transistor amplifiers ... just relays. Edison figured out how to record the traffic even as a youth. On the whole, "new" is MUCH more technically complicated at every level. That complication means MANY more ways for it to FAIL. OK ... believable ... North Korea sets off several EMP bombs high over the USA. ALL the 'complicated' tech immediately DIES for a LONG time. So HOW do you call an ambulance ? Your bank ? You AREN'T ... unless we've maintained some lower-tech REDUNDANCY.
[toc] | [prev] | [next] | [standalone]
| From | Rich <rich@example.invalid> |
|---|---|
| Date | 2026-06-01 03:50 +0000 |
| Message-ID | <10vivi4$1us3j$2@dont-email.me> |
| In reply to | #87265 |
c186282 <c186282@nnada.net> wrote: > Argue crap all you want - the providers are > generally REQUIRED to keep the POTS running > and I support that. And there you are slowly beginning to maybe see why POTS service was mostly "always working". The "providers are generally required" part is why. > OK ... believable ... North Korea sets off > several EMP bombs high over the USA. ALL the > 'complicated' tech immediately DIES for a > LONG time. Sadly, I have bad news for you. Your wonderful copper POTS line that begins at the side of your house, and travels however far from pole to pole to reach you local telephone switch, well, guess what it connects to at that switch now in 2026? The old electromechanical step-by-step switches, or electromechanical crossbar switches? Nope. Those were, mostly, long gone by the early 70's. It connects to...... a modern digitizer that digitizes the signals on the line, and the entire rest of the switch, in 2026, is a fancy computer system (usually running Erlang) that routes digital bits and bytes around. Guess what happens to those digital computer switches should that EMP be exploded? While you /might/ have 48v of power on the line, for a while (until the diesel generators run out of fuel) you won't have any communications, because *everything* after your copper wires terminate at the local switch is, and has been since the early 70's, essentially VOIP service now (not literally VOIP, but digital networking and/or digital computerized circuit switching (i.e. ATM)).
[toc] | [prev] | [next] | [standalone]
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2026-06-01 01:07 -0400 |
| Message-ID | <bIScnQGbw7sQjoD3nZ2dnZfqnPidnZ2d@giganews.com> |
| In reply to | #87318 |
On 5/31/26 23:50, Rich wrote: > c186282 <c186282@nnada.net> wrote: >> Argue crap all you want - the providers are >> generally REQUIRED to keep the POTS running >> and I support that. > > And there you are slowly beginning to maybe see why POTS service was > mostly "always working". The "providers are generally required" part > is why. > >> OK ... believable ... North Korea sets off >> several EMP bombs high over the USA. ALL the >> 'complicated' tech immediately DIES for a >> LONG time. > > Sadly, I have bad news for you. Your wonderful copper POTS line that > begins at the side of your house, and travels however far from pole to > pole to reach you local telephone switch, well, guess what it connects > to at that switch now in 2026? > > The old electromechanical step-by-step switches, or electromechanical > crossbar switches? Nope. Those were, mostly, long gone by the early > 70's. Saw 'em in action, late 60s. Neat ! > It connects to...... a modern digitizer that digitizes the signals on > the line, and the entire rest of the switch, in 2026, is a fancy > computer system (usually running Erlang) that routes digital bits and > bytes around. > > Guess what happens to those digital computer switches should that EMP > be exploded? > > While you /might/ have 48v of power on the line, for a while (until the > diesel generators run out of fuel) you won't have any communications, > because *everything* after your copper wires terminate at the local > switch is, and has been since the early 70's, essentially VOIP service > now (not literally VOIP, but digital networking and/or digital > computerized circuit switching (i.e. ATM)). Well, if the digital stuff fries they can STILL manually connect at least a sub-portion of the copper. Most tech fried ... hey ... telegraphy works :-) Simple relay-based line amps. Worked in 1850 and can work now over remaining POTS lines. Find a neighborhood 'telegraph guy'.
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2026-06-01 12:47 +0200 |
| Message-ID | <ni40fmxe5o.ln2@Telcontar.valinor> |
| In reply to | #87324 |
On 2026-06-01 07:07, c186282 wrote: > On 5/31/26 23:50, Rich wrote: >> c186282 <c186282@nnada.net> wrote: >>> Argue crap all you want - the providers are >>> generally REQUIRED to keep the POTS running >>> and I support that. >> >> And there you are slowly beginning to maybe see why POTS service was >> mostly "always working". The "providers are generally required" part >> is why. >> >>> OK ... believable ... North Korea sets off >>> several EMP bombs high over the USA. ALL the >>> 'complicated' tech immediately DIES for a >>> LONG time. >> >> Sadly, I have bad news for you. Your wonderful copper POTS line that >> begins at the side of your house, and travels however far from pole to >> pole to reach you local telephone switch, well, guess what it connects >> to at that switch now in 2026? >> >> The old electromechanical step-by-step switches, or electromechanical >> crossbar switches? Nope. Those were, mostly, long gone by the early >> 70's. > >  Saw 'em in action, late 60s. Neat ! > >> It connects to...... a modern digitizer that digitizes the signals on >> the line, and the entire rest of the switch, in 2026, is a fancy >> computer system (usually running Erlang) that routes digital bits and >> bytes around. >> >> Guess what happens to those digital computer switches should that EMP >> be exploded? >> >> While you /might/ have 48v of power on the line, for a while (until the >> diesel generators run out of fuel) you won't have any communications, >> because *everything* after your copper wires terminate at the local >> switch is, and has been since the early 70's, essentially VOIP service >> now (not literally VOIP, but digital networking and/or digital >> computerized circuit switching (i.e. ATM)). > >  Well, if the digital stuff fries they can STILL >  manually connect at least a sub-portion of the >  copper. Manually? You need an expert to go in the exchange and rewire the cables to connect two phones permanently. Maybe, because the batteries are the wrong voltage. Certainly no dialing. > >  Most tech fried ... hey ... telegraphy works :-) >  Simple relay-based line amps. Worked in 1850 and >  can work now over remaining POTS lines. Find a >  neighborhood 'telegraph guy'. > -- Cheers, Carlos. ES🇪🇸, EU🇪🇺;
[toc] | [prev] | [next] | [standalone]
| From | Rich <rich@example.invalid> |
|---|---|
| Date | 2026-06-01 17:36 +0000 |
| Message-ID | <10vkfub$2ci6m$2@dont-email.me> |
| In reply to | #87330 |
Carlos E.R. <robin_listas@es.invalid> wrote: > On 2026-06-01 07:07, c186282 wrote: >> On 5/31/26 23:50, Rich wrote: >>> c186282 <c186282@nnada.net> wrote: >>>> Argue crap all you want - the providers are >>>> generally REQUIRED to keep the POTS running >>>> and I support that. >>> >>> And there you are slowly beginning to maybe see why POTS service was >>> mostly "always working". The "providers are generally required" part >>> is why. >>> >>>> OK ... believable ... North Korea sets off >>>> several EMP bombs high over the USA. ALL the >>>> 'complicated' tech immediately DIES for a >>>> LONG time. >>> >>> Sadly, I have bad news for you. Your wonderful copper POTS line that >>> begins at the side of your house, and travels however far from pole to >>> pole to reach you local telephone switch, well, guess what it connects >>> to at that switch now in 2026? >>> >>> The old electromechanical step-by-step switches, or electromechanical >>> crossbar switches? Nope. Those were, mostly, long gone by the early >>> 70's. >> >>  Saw 'em in action, late 60s. Neat ! >> >>> It connects to...... a modern digitizer that digitizes the signals on >>> the line, and the entire rest of the switch, in 2026, is a fancy >>> computer system (usually running Erlang) that routes digital bits and >>> bytes around. >>> >>> Guess what happens to those digital computer switches should that EMP >>> be exploded? >>> >>> While you /might/ have 48v of power on the line, for a while (until the >>> diesel generators run out of fuel) you won't have any communications, >>> because *everything* after your copper wires terminate at the local >>> switch is, and has been since the early 70's, essentially VOIP service >>> now (not literally VOIP, but digital networking and/or digital >>> computerized circuit switching (i.e. ATM)). >> >>  Well, if the digital stuff fries they can STILL >>  manually connect at least a sub-portion of the >>  copper. > > Manually? You need an expert to go in the exchange and rewire the cables > to connect two phones permanently. Maybe, because the batteries are the > wrong voltage. Certainly no dialing. I've not even pointed out to him yet that in most of those "bundles" of 4000 pairs, that there's only about 8 or 10 different colors (certianly not 4000 colors). So "working out" which red/black, from the 10,000 red/black pairs that terminate at the switch, connect to "joe's pizza" is a non-trivial job for the non-expert.
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2026-06-01 22:33 +0200 |
| Message-ID | <9u61fmxgao.ln2@Telcontar.valinor> |
| In reply to | #87339 |
On 2026-06-01 19:36, Rich wrote: > Carlos E.R. <robin_listas@es.invalid> wrote: >> On 2026-06-01 07:07, c186282 wrote: >>> On 5/31/26 23:50, Rich wrote: >>>> c186282 <c186282@nnada.net> wrote: >>>>> Argue crap all you want - the providers are >>>>> generally REQUIRED to keep the POTS running >>>>> and I support that. >>>> >>>> And there you are slowly beginning to maybe see why POTS service was >>>> mostly "always working". The "providers are generally required" part >>>> is why. >>>> >>>>> OK ... believable ... North Korea sets off >>>>> several EMP bombs high over the USA. ALL the >>>>> 'complicated' tech immediately DIES for a >>>>> LONG time. >>>> >>>> Sadly, I have bad news for you. Your wonderful copper POTS line that >>>> begins at the side of your house, and travels however far from pole to >>>> pole to reach you local telephone switch, well, guess what it connects >>>> to at that switch now in 2026? >>>> >>>> The old electromechanical step-by-step switches, or electromechanical >>>> crossbar switches? Nope. Those were, mostly, long gone by the early >>>> 70's. >>> >>>  Saw 'em in action, late 60s. Neat ! >>> >>>> It connects to...... a modern digitizer that digitizes the signals on >>>> the line, and the entire rest of the switch, in 2026, is a fancy >>>> computer system (usually running Erlang) that routes digital bits and >>>> bytes around. >>>> >>>> Guess what happens to those digital computer switches should that EMP >>>> be exploded? >>>> >>>> While you /might/ have 48v of power on the line, for a while (until the >>>> diesel generators run out of fuel) you won't have any communications, >>>> because *everything* after your copper wires terminate at the local >>>> switch is, and has been since the early 70's, essentially VOIP service >>>> now (not literally VOIP, but digital networking and/or digital >>>> computerized circuit switching (i.e. ATM)). >>> >>>  Well, if the digital stuff fries they can STILL >>>  manually connect at least a sub-portion of the >>>  copper. >> >> Manually? You need an expert to go in the exchange and rewire the cables >> to connect two phones permanently. Maybe, because the batteries are the >> wrong voltage. Certainly no dialing. > > I've not even pointed out to him yet that in most of those "bundles" of > 4000 pairs, that there's only about 8 or 10 different colors (certianly > not 4000 colors). So "working out" which red/black, from the 10,000 > red/black pairs that terminate at the switch, connect to "joe's pizza" > is a non-trivial job for the non-expert. Heh, absolutely. Although you can find the cable at the... I don't know the English name, a rack of wire wrapping pins. 4000 at one side, connecting to 4000 at the other side which go to the actual switch. These are labelled, but you need to know the system. I have not wired these, so here I have to guess, but the phone number is not written here. Rather wire number of the bundle on the one side, and equipment number on the other side. You need a table to find out which is which, possibly computerized, possibly printed and stored in large binders. -- Cheers, Carlos. ES🇪🇸, EU🇪🇺;
[toc] | [prev] | [next] | [standalone]
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
Back to top | Article view | comp.os.linux.misc
csiph-web