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 240 — 16 participants |
Back to article view | Back to comp.os.linux.misc
Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-26 02:21 -0400
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-05-26 08:46 +0200
Re: Redundancy/Survival Marco Moock <mm@dorfdsl.de> - 2026-05-26 09:49 +0200
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-26 04:47 -0400
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-05-26 11:25 +0200
Re: Redundancy/Survival Rich <rich@example.invalid> - 2026-05-26 09:53 +0000
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-26 04:38 -0400
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-05-26 11:35 +0200
Re: Redundancy/Survival Rich <rich@example.invalid> - 2026-05-26 22:09 +0000
Re: Redundancy/Survival John Ames <commodorejohn@gmail.com> - 2026-05-26 16:17 -0700
Re: Redundancy/Survival Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-05-27 00:02 +0000
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-27 00:11 -0400
Re: Redundancy/Survival Marco Moock <mm@dorfdsl.de> - 2026-05-28 10:32 +0200
Re: Redundancy/Survival Nuno Silva <nunojsilva@invalid.invalid> - 2026-05-27 08:41 +0100
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-05-27 11:04 +0200
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-28 03:31 -0400
Re: Redundancy/Survival The Natural Philosopher <tnp@invalid.invalid> - 2026-05-28 09:18 +0100
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-05-28 13:42 +0200
Re: Redundancy/Survival The Natural Philosopher <tnp@invalid.invalid> - 2026-05-28 15:01 +0100
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-28 21:34 -0400
Re: Redundancy/Survival The Natural Philosopher <tnp@invalid.invalid> - 2026-05-29 11:07 +0100
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-05-29 12:55 +0200
Re: Redundancy/Survival The Natural Philosopher <tnp@invalid.invalid> - 2026-05-29 12:14 +0100
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-05-29 13:36 +0200
Re: Redundancy/Survival The Natural Philosopher <tnp@invalid.invalid> - 2026-05-29 13:26 +0100
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-05-29 19:36 +0200
Re: Redundancy/Survival Richard Kettlewell <invalid@invalid.invalid> - 2026-05-29 17:24 +0100
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-05-29 19:37 +0200
Re: Redundancy/Survival The Natural Philosopher <tnp@invalid.invalid> - 2026-05-29 19:36 +0100
Re: Redundancy/Survival Richard Kettlewell <invalid@invalid.invalid> - 2026-05-29 22:34 +0100
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-30 04:29 -0400
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-05-30 13:09 +0200
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-30 23:29 -0400
Re: Redundancy/Survival InterLinked <usenet@phreaknet.org> - 2026-05-31 21:45 -0400
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-01 12:15 +0200
Re: Redundancy/Survival InterLinked <usenet@phreaknet.org> - 2026-06-01 18:53 -0400
Re: Redundancy/Survival Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-06-02 01:46 +0000
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-06-02 03:01 -0400
Re: Redundancy/Survival Rich <rich@example.invalid> - 2026-06-02 18:12 +0000
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-02 10:16 +0200
Re: Redundancy/Survival Rich <rich@example.invalid> - 2026-06-02 18:09 +0000
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-02 21:26 +0200
Re: Redundancy/Survival Nuno Silva <nunojsilva@invalid.invalid> - 2026-06-03 12:48 +0100
Re: Redundancy/Survival Rich <rich@example.invalid> - 2026-06-03 14:35 +0000
Re: Redundancy/Survival Nuno Silva <nunojsilva@invalid.invalid> - 2026-06-03 17:25 +0100
Re: Redundancy/Survival Rich <rich@example.invalid> - 2026-06-04 03:51 +0000
Re: Redundancy/Survival Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-06-04 04:30 +0000
Re: Redundancy/Survival The Natural Philosopher <tnp@invalid.invalid> - 2026-06-04 09:34 +0100
Re: Redundancy/Survival Nuno Silva <nunojsilva@invalid.invalid> - 2026-06-04 16:06 +0100
Re: Redundancy/Survival The Natural Philosopher <tnp@invalid.invalid> - 2026-06-04 09:30 +0100
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-03 19:24 +0200
Re: Redundancy/Survival Nuno Silva <nunojsilva@invalid.invalid> - 2026-06-03 20:04 +0100
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-03 22:25 +0200
Re: Redundancy/Survival Rich <rich@example.invalid> - 2026-06-04 04:15 +0000
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-04 07:36 +0200
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-06-04 02:19 -0400
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-04 08:34 +0200
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-06-04 10:26 -0400
Re: Redundancy/Survival Andy Burns <usenet@andyburns.uk> - 2026-06-04 08:18 +0100
Re: Redundancy/Survival Nuno Silva <nunojsilva@invalid.invalid> - 2026-06-04 09:48 +0100
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-06-04 10:36 -0400
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 The Natural Philosopher <tnp@invalid.invalid> - 2026-06-04 09:31 +0100
Re: Redundancy/Survival Rich <rich@example.invalid> - 2026-05-29 04:30 +0000
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-29 01:34 -0400
Re: Redundancy/Survival rbowman <bowman@montana.com> - 2026-05-29 06:36 +0000
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-31 00:38 -0400
Re: Redundancy/Survival TheLastSysop <thelastsysop@dev.null> - 2026-05-31 05:09 +0000
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-31 03:10 -0400
Re: Redundancy/Survival TheLastSysop <thelastsysop@dev.null> - 2026-05-31 07:14 +0000
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-06-01 00:49 -0400
Re: Redundancy/Survival TheLastSysop <thelastsysop@dev.null> - 2026-06-01 04:57 +0000
Re: Redundancy/Survival Rich <rich@example.invalid> - 2026-06-01 03:20 +0000
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-01 19:45 +0200
Re: Redundancy/Survival Rich <rich@example.invalid> - 2026-06-01 18:30 +0000
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-01 22:27 +0200
Re: Redundancy/Survival TheLastSysop <thelastsysop@dev.null> - 2026-06-02 10:49 +0000
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-02 13:16 +0200
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-06-03 00:00 -0400
Re: Redundancy/Survival Rich <rich@example.invalid> - 2026-06-03 14:43 +0000
Re: Redundancy/Survival Rich <rich@example.invalid> - 2026-06-02 18:35 +0000
Re: Redundancy/Survival Rich <rich@example.invalid> - 2026-06-02 18:21 +0000
Re: Redundancy/Survival TheLastSysop <thelastsysop@dev.null> - 2026-06-02 18:25 +0000
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-02 21:36 +0200
Re: Redundancy/Survival Rich <rich@example.invalid> - 2026-06-03 02:06 +0000
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-03 11:32 +0200
Re: Redundancy/Survival Nuno Silva <nunojsilva@invalid.invalid> - 2026-06-03 11:43 +0100
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-03 13:05 +0200
Re: Redundancy/Survival The Natural Philosopher <tnp@invalid.invalid> - 2026-06-03 12:14 +0100
Re: Redundancy/Survival Nuno Silva <nunojsilva@invalid.invalid> - 2026-06-03 12:31 +0100
Re: Redundancy/Survival The Natural Philosopher <tnp@invalid.invalid> - 2026-06-03 14:43 +0100
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-03 19:28 +0200
Re: Redundancy/Survival Nuno Silva <nunojsilva@invalid.invalid> - 2026-06-03 20:10 +0100
Re: Redundancy/Survival Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-06-03 18:00 +0000
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-03 22:27 +0200
Re: Redundancy/Survival The Natural Philosopher <tnp@invalid.invalid> - 2026-06-03 12:13 +0100
Re: Redundancy/Survival Rich <rich@example.invalid> - 2026-06-03 14:48 +0000
Re: Redundancy/Survival rbowman <bowman@montana.com> - 2026-06-03 18:58 +0000
Re: Redundancy/Survival Rich <rich@example.invalid> - 2026-06-03 14:46 +0000
Re: Redundancy/Survival InterLinked <usenet@phreaknet.org> - 2026-06-01 19:00 -0400
Re: Redundancy/Survival Robert Riches <spamtrap42@jacob21819.net> - 2026-06-02 17:44 +0000
Re: Redundancy/Survival TheLastSysop <thelastsysop@dev.null> - 2026-06-02 17:54 +0000
Re: Redundancy/Survival InterLinked <usenet@phreaknet.org> - 2026-06-02 16:57 -0400
Re: Redundancy/Survival TheLastSysop <thelastsysop@dev.null> - 2026-06-02 21:02 +0000
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-03 11:41 +0200
Re: Redundancy/Survival Rich <rich@example.invalid> - 2026-06-03 02:13 +0000
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-03 11:47 +0200
Re: Redundancy/Survival Nuno Silva <nunojsilva@invalid.invalid> - 2026-06-04 01:01 +0100
Re: Redundancy/Survival InterLinked <usenet@phreaknet.org> - 2026-06-03 21:18 -0400
Re: Redundancy/Survival Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-06-04 04:30 +0000
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-04 07:44 +0200
Re: Redundancy/Survival The Natural Philosopher <tnp@invalid.invalid> - 2026-06-04 09:48 +0100
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-06-04 00:26 -0400
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-04 07:53 +0200
Re: Redundancy/Survival The Natural Philosopher <tnp@invalid.invalid> - 2026-06-03 11:49 +0100
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-06-04 01:03 -0400
Re: Redundancy/Survival The Natural Philosopher <tnp@invalid.invalid> - 2026-06-04 10:07 +0100
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-06-04 10:57 -0400
Re: Redundancy/Survival The Natural Philosopher <tnp@invalid.invalid> - 2026-06-04 16:31 +0100
Re: Redundancy/Survival Rich <rich@example.invalid> - 2026-06-03 02:10 +0000
Re: Redundancy/Survival InterLinked <usenet@phreaknet.org> - 2026-06-02 22:29 -0400
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-03 11:52 +0200
Re: Redundancy/Survival Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-06-03 18:00 +0000
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-03 11:49 +0200
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-06-04 00:30 -0400
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-04 07:55 +0200
Re: Redundancy/Survival The Natural Philosopher <tnp@invalid.invalid> - 2026-06-04 09:51 +0100
Re: Redundancy/Survival The Natural Philosopher <tnp@invalid.invalid> - 2026-06-03 11:56 +0100
Re: Redundancy/Survival Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-06-03 18:00 +0000
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-06-04 02:11 -0400
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-29 02:17 -0400
Re: Redundancy/Survival Rich <rich@example.invalid> - 2026-06-01 03:50 +0000
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-06-01 01:07 -0400
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-01 12:47 +0200
Re: Redundancy/Survival Rich <rich@example.invalid> - 2026-06-01 17:36 +0000
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-01 22:33 +0200
Re: Redundancy/Survival Rich <rich@example.invalid> - 2026-06-03 02:25 +0000
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-06-03 02:12 -0400
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-03 12:03 +0200
Re: Redundancy/Survival The Natural Philosopher <tnp@invalid.invalid> - 2026-06-03 12:06 +0100
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-06-04 00:46 -0400
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-04 08:09 +0200
Re: Redundancy/Survival The Natural Philosopher <tnp@invalid.invalid> - 2026-06-03 12:02 +0100
Re: Redundancy/Survival Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-06-03 18:00 +0000
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-03 22:31 +0200
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-06-04 01:36 -0400
Re: Redundancy/Survival The Natural Philosopher <tnp@invalid.invalid> - 2026-06-01 12:26 +0100
Re: Redundancy/Survival Rich <rich@example.invalid> - 2026-06-01 17:31 +0000
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-01 22:49 +0200
Re: Redundancy/Survival Rich <rich@example.invalid> - 2026-06-03 02:37 +0000
Re: Redundancy/Survival not@telling.you.invalid (Computer Nerd Kev) - 2026-05-30 09:09 +1000
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-05-30 13:17 +0200
Re: Redundancy/Survival not@telling.you.invalid (Computer Nerd Kev) - 2026-05-31 07:33 +1000
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-31 00:14 -0400
Re: Redundancy/Survival The Natural Philosopher <tnp@invalid.invalid> - 2026-05-31 12:09 +0100
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-06-01 00:51 -0400
Re: Redundancy/Survival The Natural Philosopher <tnp@invalid.invalid> - 2026-06-01 12:28 +0100
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-05-31 12:58 +0200
Re: Redundancy/Survival Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-05-27 20:51 +0000
Re: Redundancy/Survival John Ames <commodorejohn@gmail.com> - 2026-05-27 14:02 -0700
Re: Redundancy/Survival not@telling.you.invalid (Computer Nerd Kev) - 2026-05-28 08:54 +1000
Re: Redundancy/Survival Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-05-28 05:04 +0000
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-28 03:54 -0400
Re: Redundancy/Survival Andy Burns <usenet@andyburns.uk> - 2026-05-28 09:15 +0100
Re: Redundancy/Survival Rich <rich@example.invalid> - 2026-06-01 12:29 +0000
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-05-28 13:45 +0200
Re: Redundancy/Survival Robert Riches <spamtrap42@jacob21819.net> - 2026-05-29 02:50 +0000
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-29 01:17 -0400
Re: Redundancy/Survival rbowman <bowman@montana.com> - 2026-05-29 06:48 +0000
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-30 04:25 -0400
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-05-30 13:20 +0200
Re: Redundancy/Survival Robert Riches <spamtrap42@jacob21819.net> - 2026-05-30 14:16 +0000
Re: Redundancy/Survival Robert Riches <spamtrap42@jacob21819.net> - 2026-05-30 04:00 +0000
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-26 23:41 -0400
Re: Redundancy/Survival The Natural Philosopher <tnp@invalid.invalid> - 2026-05-27 14:09 +0100
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-28 03:51 -0400
Re: Redundancy/Survival rbowman <bowman@montana.com> - 2026-05-28 17:08 +0000
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-28 22:14 -0400
Re: Redundancy/Survival rbowman <bowman@montana.com> - 2026-05-29 04:41 +0000
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-29 01:53 -0400
Re: Redundancy/Survival rbowman <bowman@montana.com> - 2026-05-29 06:32 +0000
Re: Redundancy/Survival Rich <rich@example.invalid> - 2026-06-01 13:19 +0000
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-01 22:52 +0200
Re: Redundancy/Survival Rich <rich@example.invalid> - 2026-06-03 02:46 +0000
Re: Redundancy/Survival InterLinked <usenet@phreaknet.org> - 2026-06-03 00:27 -0400
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-06-03 03:26 -0400
Re: Redundancy/Survival InterLinked <usenet@phreaknet.org> - 2026-06-03 21:30 -0400
Re: Redundancy/Survival Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-06-04 04:30 +0000
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-04 08:13 +0200
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-06-03 03:03 -0400
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-03 12:12 +0200
Re: Redundancy/Survival The Natural Philosopher <tnp@invalid.invalid> - 2026-06-03 12:08 +0100
Re: Redundancy/Survival Nuno Silva <nunojsilva@invalid.invalid> - 2026-06-03 12:33 +0100
Re: Redundancy/Survival The Natural Philosopher <tnp@invalid.invalid> - 2026-06-03 14:45 +0100
Re: Redundancy/Survival Rich <rich@example.invalid> - 2026-06-01 13:08 +0000
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-01 22:55 +0200
Re: Redundancy/Survival Nuno Silva <nunojsilva@invalid.invalid> - 2026-06-02 10:39 +0100
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-02 13:21 +0200
Re: Redundancy/Survival Rich <rich@example.invalid> - 2026-06-03 02:57 +0000
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-26 22:39 -0400
Re: Redundancy/Survival The Natural Philosopher <tnp@invalid.invalid> - 2026-05-27 14:10 +0100
Re: Redundancy/Survival not@telling.you.invalid (Computer Nerd Kev) - 2026-05-28 09:05 +1000
Re: Redundancy/Survival The Natural Philosopher <tnp@invalid.invalid> - 2026-05-28 08:19 +0100
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-28 03:52 -0400
Re: Redundancy/Survival The Natural Philosopher <tnp@invalid.invalid> - 2026-05-28 09:20 +0100
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-28 20:34 -0400
Re: Redundancy/Survival InterLinked <usenet@phreaknet.org> - 2026-05-28 21:07 -0400
Re: Redundancy/Survival Rich <rich@example.invalid> - 2026-06-01 13:40 +0000
Re: Redundancy/Survival InterLinked <usenet@phreaknet.org> - 2026-06-01 19:12 -0400
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-02 10:28 +0200
Re: Redundancy/Survival InterLinked <usenet@phreaknet.org> - 2026-06-02 12:15 -0400
Re: Redundancy/Survival TheLastSysop <thelastsysop@dev.null> - 2026-06-02 16:19 +0000
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-02 18:30 +0200
Re: Redundancy/Survival The Natural Philosopher <tnp@invalid.invalid> - 2026-06-02 18:29 +0100
Re: Redundancy/Survival InterLinked <usenet@phreaknet.org> - 2026-06-02 16:49 -0400
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-03 12:18 +0200
Re: Redundancy/Survival Marco Moock <mm@dorfdsl.de> - 2026-06-02 17:38 +0200
Re: Redundancy/Survival TheLastSysop <thelastsysop@dev.null> - 2026-06-02 15:48 +0000
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-06-03 00:39 -0400
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-02 17:55 +0200
Re: Redundancy/Survival TheLastSysop <thelastsysop@dev.null> - 2026-06-02 16:03 +0000
Re: Redundancy/Survival InterLinked <usenet@phreaknet.org> - 2026-06-02 12:22 -0400
Re: Redundancy/Survival TheLastSysop <thelastsysop@dev.null> - 2026-06-02 16:36 +0000
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-02 18:39 +0200
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-06-03 00:48 -0400
Re: Redundancy/Survival rbowman <bowman@montana.com> - 2026-05-29 01:21 +0000
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-29 02:08 -0400
Re: Redundancy/Survival rbowman <bowman@montana.com> - 2026-05-29 06:41 +0000
Re: Redundancy/Survival Rich <rich@example.invalid> - 2026-06-01 13:23 +0000
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-01 23:00 +0200
Re: Redundancy/Survival Marco Moock <mm@dorfdsl.de> - 2026-05-26 09:44 +0200
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-26 04:45 -0400
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-05-26 11:38 +0200
Re: Redundancy/Survival "Worst Case" <fritz@spamexpire-202605.rodent.frell.theremailer.net> - 2026-05-26 17:21 +0200
Page 3 of 12 — ← Prev page 1 2 [3] 4 5 … 12 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 | Rich <rich@example.invalid> |
|---|---|
| Date | 2026-06-04 03:51 +0000 |
| Message-ID | <10vqsof$4r3b$2@dont-email.me> |
| In reply to | #87446 |
Nuno Silva <nunojsilva@invalid.invalid> wrote: > 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. I suspect you are using a different meaning of "off-line". I mean "no computer or network needed to make a charge" as in the really good old days where your card would be run through a carbon copy press with a charge slip above it to impress the raised card numerals into the charge slip. >> 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? You can't "charge" to a modern credit card via paper methods anymore. You need a computer and network (i.e. internet) connectivity to do so. >> 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. Mag stripes disappeared one or two cargs ago on my cards. They no longer have one on the card. You either do "chip" or you do "NFC" but no more mag stripe. And the numbers have not been embossed and raised for even longer than that, so the really old carbon copy paper slips have been long gone for what feels like forever.
[toc] | [prev] | [next] | [standalone]
| From | Charlie Gibbs <cgibbs@kltpzyxm.invalid> |
|---|---|
| Date | 2026-06-04 04:30 +0000 |
| Message-ID | <Mb7UR.4$xD2.1@fx39.iad> |
| In reply to | #87468 |
On 2026-06-04, Rich <rich@example.invalid> wrote: > Mag stripes disappeared one or two cargs ago on my cards. They no > longer have one on the card. You either do "chip" or you do "NFC" but > no more mag stripe. And the numbers have not been embossed and raised > for even longer than that, so the really old carbon copy paper slips > have been long gone for what feels like forever. My newly-renewed credit card arrived last week, and it has both a mag stripe and raised numbers. On the other hand, on my latest bank card, which I use for debit transfers, the numbers are not raised. Go figure. -- /~\ Charlie Gibbs | Growth for the sake of \ / <cgibbs@kltpzyxm.invalid> | growth is the ideology X I'm really at ac.dekanfrus | of the cancer cell. / \ if you read it the right way. | -- Edward Abbey
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2026-06-04 09:34 +0100 |
| Message-ID | <10vrdb2$894o$3@dont-email.me> |
| In reply to | #87474 |
On 04/06/2026 05:30, Charlie Gibbs wrote: > On 2026-06-04, Rich <rich@example.invalid> wrote: > >> Mag stripes disappeared one or two cargs ago on my cards. They no >> longer have one on the card. You either do "chip" or you do "NFC" but >> no more mag stripe. And the numbers have not been embossed and raised >> for even longer than that, so the really old carbon copy paper slips >> have been long gone for what feels like forever. > > My newly-renewed credit card arrived last week, and it has both > a mag stripe and raised numbers. On the other hand, on my latest > bank card, which I use for debit transfers, the numbers are not > raised. Go figure. > My debit card has both mag and embossing -- How fortunate for governments that the people they administer don't think. Adolf Hitler
[toc] | [prev] | [next] | [standalone]
| From | Nuno Silva <nunojsilva@invalid.invalid> |
|---|---|
| Date | 2026-06-04 16:06 +0100 |
| Message-ID | <10vs48t$e7vd$1@dont-email.me> |
| In reply to | #87468 |
On 2026-06-04, Rich wrote: > Nuno Silva <nunojsilva@invalid.invalid> wrote: >> 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. > > I suspect you are using a different meaning of "off-line". I mean "no > computer or network needed to make a charge" as in the really good old > days where your card would be run through a carbon copy press with a > charge slip above it to impress the raised card numerals into the > charge slip. Ah - as far as I know, in the bank card industry, the definition is that "on-line" means there is that balance check as part of the transaction and "off-line" means it doesn't happen. Possibly with other things in the mix. But this all for *electronic* use of cards, i.e. smartcard of magstripe, but I suppose "electronic use" could have another definition of its own in this industry, which may or may not align with this; at one point, Electron presented the words "electronic use only", I'll guess that meant precisely that you can't use it the carbon copy way, even if numbers are engraved. >>> 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? > > You can't "charge" to a modern credit card via paper methods anymore. > You need a computer and network (i.e. internet) connectivity to do so. > >>> 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. > > Mag stripes disappeared one or two cargs ago on my cards. They no > longer have one on the card. You either do "chip" or you do "NFC" but > no more mag stripe. And the numbers have not been embossed and raised > for even longer than that, so the really old carbon copy paper slips > have been long gone for what feels like forever. I've not had a card without it yet, but, in my experience from the past few years, even if present the stripe is often refused if the terminal has a smartcard interface. -- Nuno Silva
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2026-06-04 09:30 +0100 |
| Message-ID | <10vrd2j$894o$1@dont-email.me> |
| In reply to | #87441 |
On 03/06/2026 15:35, Rich wrote:
> 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.
few places are out of 2G or broadband range
--
"Strange as it seems, no amount of learning can cure stupidity, and
higher education positively fortifies it."
- Stephen Vizinczey
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2026-06-03 19:24 +0200 |
| Message-ID | <ri46fmx7a6.ln2@Telcontar.valinor> |
| In reply to | #87438 |
On 2026-06-03 13:48, Nuno Silva 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?)
Apparently not. Maybe because the majority are debit cards, not credit
cards. But I have seen nobody with that paper thing that was used to
print a charge paper with the relief letters/numbers on the cards. Cards
no longer have relief lettering.
I asked ChatGPT, so take the answer with a grain of salt.
Q: Can payments be done with credit or debit cards, while off line? Say,
pay on a small remote restaurant that has intermitent internet, and
doesn't work "now".
A: Yes, **sometimes**, but it depends on the card terminal, the card
network, the amount, and the merchant's setup.
Traditionally, card payments could be processed in **offline mode**:
* The terminal stores the transaction locally.
* The customer leaves with the goods or meal.
* When connectivity returns, the terminal uploads the transactions for
authorization and settlement.
This is still possible in some circumstances, but it's much less common
than it used to be because fraud controls are stricter.
For a small remote restaurant in Spain today, several scenarios are
possible:
1. **Terminal supports offline transactions**
* The payment may be accepted even without an internet connection.
* The restaurant assumes some risk because the transaction could
later be declined.
2. **Terminal requires online authorization**
* The payment is refused until connectivity returns.
* This is increasingly common.
3. **Card and terminal support EMV offline authentication**
* The chip can prove the card is genuine without contacting the bank.
* However, this does not necessarily guarantee that the account has
funds available.
4. **Restaurant uses a mobile-data terminal**
* Sometimes the problem is local Wi-Fi, but the terminal has its own
SIM card and can still process payments.
* Other times both connections are unavailable.
In very remote areas, merchants often have practical workarounds:
* waiting for the connection to come back,
* asking for cash,
* manually recording card details (much rarer now and often discouraged),
* or processing the transaction later if their payment provider allows it.
One thing many people don't realize is that contactless payments can
occasionally appear to work "offline" even in normal conditions. The
card and terminal may approve a transaction locally and only later
synchronize with the bank. The rules for when this is allowed are set by
the card issuer and payment network.
So the answer is: **yes, card payments can sometimes be made while
offline, but whether a particular restaurant can do it depends on its
payment terminal configuration and the payment provider's rules.** Many
modern terminals will simply refuse the transaction if they cannot reach
the authorization network.
--
Cheers, Carlos.
ES🇪🇸, EU🇪🇺;
[toc] | [prev] | [next] | [standalone]
| From | Nuno Silva <nunojsilva@invalid.invalid> |
|---|---|
| Date | 2026-06-03 20:04 +0100 |
| Message-ID | <10vpts4$3tl9m$1@dont-email.me> |
| In reply to | #87447 |
On 2026-06-03, Carlos E.R. wrote: > On 2026-06-03 13:48, Nuno Silva 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?) > > Apparently not. Maybe because the majority are debit cards, not credit > cards. But I have seen nobody with that paper thing that was used to > print a charge paper with the relief letters/numbers on the > cards. Cards no longer have relief lettering. This isn't about relief lettering at all, but whether the card itself requires on-line transactions, where (probably among other things) funds are normally expected to be guaranteed as available to approve the transaction. This used to be the key difference between Visa Debit and Visa Electron, for example. > I asked ChatGPT, so take the answer with a grain of salt. > > Q: Can payments be done with credit or debit cards, while off line? > Say, pay on a small remote restaurant that has intermitent internet, > and doesn't work "now". > > A: Yes, **sometimes**, but it depends on the card terminal, the card > network, the amount, and the merchant's setup. I've also heard many years ago of merchants possibly setting payment terminals to require on-line transactions, even for normally off-line cards. > Traditionally, card payments could be processed in **offline mode**: > > * The terminal stores the transaction locally. > * The customer leaves with the goods or meal. > * When connectivity returns, the terminal uploads the transactions for > authorization and settlement. While I was mentioning this in the context of lack of network connectivity, unless I'm mistaken off-line transactions also happen in the presence of network connectivity - although I'm not sure of what details that entails more precisely, besides faster transaction approval? > This is still possible in some circumstances, but it's much less > common than it used to be because fraud controls are stricter. This is what's puzzling me now, given both Visa and Mastercard actually did away with their on-line cards - or is this because the off-line cards have changed and now act more like on-line cards? > For a small remote restaurant in Spain today, several scenarios are > possible: > > 1. **Terminal supports offline transactions** > > * The payment may be accepted even without an internet connection. > * The restaurant assumes some risk because the transaction could > later be declined. > > 2. **Terminal requires online authorization** > > * The payment is refused until connectivity returns. > * This is increasingly common. > > 3. **Card and terminal support EMV offline authentication** > > * The chip can prove the card is genuine without contacting the bank. > * However, this does not necessarily guarantee that the account has > funds available. > > 4. **Restaurant uses a mobile-data terminal** > > * Sometimes the problem is local Wi-Fi, but the terminal has its > own SIM card and can still process payments. > * Other times both connections are unavailable. > > In very remote areas, merchants often have practical workarounds: > > * waiting for the connection to come back, > * asking for cash, > * manually recording card details (much rarer now and often discouraged), > * or processing the transaction later if their payment provider allows it. > > One thing many people don't realize is that contactless payments can > occasionally appear to work "offline" even in normal conditions. The > card and terminal may approve a transaction locally and only later > synchronize with the bank. The rules for when this is allowed are set > by the card issuer and payment network. I think that's not just appearance, that's literally an off-line card transaction? > So the answer is: **yes, card payments can sometimes be made while > offline, but whether a particular restaurant can do it depends on its > payment terminal configuration and the payment provider's rules.** > Many modern terminals will simply refuse the transaction if they > cannot reach the authorization network. This also puzzles me, because I was under the impression credit cards have been expected to allow off-line transactions. (And, after all, being *credit* cards, allowing transactions without sufficient funds would be a - or perhaps *the* - feature?) -- Nuno Silva
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2026-06-03 22:25 +0200 |
| Message-ID | <67f6fmxvvh.ln2@Telcontar.valinor> |
| In reply to | #87458 |
On 2026-06-03 21:04, Nuno Silva wrote: > On 2026-06-03, Carlos E.R. wrote: > >> On 2026-06-03 13:48, Nuno Silva 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?) >> >> Apparently not. Maybe because the majority are debit cards, not credit >> cards. But I have seen nobody with that paper thing that was used to >> print a charge paper with the relief letters/numbers on the >> cards. Cards no longer have relief lettering. > > This isn't about relief lettering at all, but whether the card itself > requires on-line transactions, where (probably among other things) funds > are normally expected to be guaranteed as available to approve the > transaction. This used to be the key difference between Visa Debit and > Visa Electron, for example. > >> I asked ChatGPT, so take the answer with a grain of salt. >> >> Q: Can payments be done with credit or debit cards, while off line? >> Say, pay on a small remote restaurant that has intermitent internet, >> and doesn't work "now". >> >> A: Yes, **sometimes**, but it depends on the card terminal, the card >> network, the amount, and the merchant's setup. > > I've also heard many years ago of merchants possibly setting payment > terminals to require on-line transactions, even for normally off-line > cards. > >> Traditionally, card payments could be processed in **offline mode**: >> >> * The terminal stores the transaction locally. >> * The customer leaves with the goods or meal. >> * When connectivity returns, the terminal uploads the transactions for >> authorization and settlement. > > While I was mentioning this in the context of lack of network > connectivity, unless I'm mistaken off-line transactions also happen in > the presence of network connectivity - although I'm not sure of what > details that entails more precisely, besides faster transaction > approval? > >> This is still possible in some circumstances, but it's much less >> common than it used to be because fraud controls are stricter. > > This is what's puzzling me now, given both Visa and Mastercard actually > did away with their on-line cards - or is this because the off-line > cards have changed and now act more like on-line cards? > >> For a small remote restaurant in Spain today, several scenarios are >> possible: >> >> 1. **Terminal supports offline transactions** >> >> * The payment may be accepted even without an internet connection. >> * The restaurant assumes some risk because the transaction could >> later be declined. >> >> 2. **Terminal requires online authorization** >> >> * The payment is refused until connectivity returns. >> * This is increasingly common. >> >> 3. **Card and terminal support EMV offline authentication** >> >> * The chip can prove the card is genuine without contacting the bank. >> * However, this does not necessarily guarantee that the account has >> funds available. >> >> 4. **Restaurant uses a mobile-data terminal** >> >> * Sometimes the problem is local Wi-Fi, but the terminal has its >> own SIM card and can still process payments. >> * Other times both connections are unavailable. >> >> In very remote areas, merchants often have practical workarounds: >> >> * waiting for the connection to come back, >> * asking for cash, >> * manually recording card details (much rarer now and often discouraged), >> * or processing the transaction later if their payment provider allows it. >> >> One thing many people don't realize is that contactless payments can >> occasionally appear to work "offline" even in normal conditions. The >> card and terminal may approve a transaction locally and only later >> synchronize with the bank. The rules for when this is allowed are set >> by the card issuer and payment network. > > I think that's not just appearance, that's literally an off-line card > transaction? > >> So the answer is: **yes, card payments can sometimes be made while >> offline, but whether a particular restaurant can do it depends on its >> payment terminal configuration and the payment provider's rules.** >> Many modern terminals will simply refuse the transaction if they >> cannot reach the authorization network. > > This also puzzles me, because I was under the impression credit cards > have been expected to allow off-line transactions. (And, after all, > being *credit* cards, allowing transactions without sufficient funds > would be a - or perhaps *the* - feature?) > Indeed. -- Cheers, Carlos. ES🇪🇸, EU🇪🇺;
[toc] | [prev] | [next] | [standalone]
| From | Rich <rich@example.invalid> |
|---|---|
| Date | 2026-06-04 04:15 +0000 |
| Message-ID | <10vqu43$4r3b$3@dont-email.me> |
| In reply to | #87458 |
Nuno Silva <nunojsilva@invalid.invalid> wrote: > On 2026-06-03, Carlos E.R. wrote: > >> On 2026-06-03 13:48, Nuno Silva 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?) >> >> Apparently not. Maybe because the majority are debit cards, not credit >> cards. But I have seen nobody with that paper thing that was used to >> print a charge paper with the relief letters/numbers on the >> cards. Cards no longer have relief lettering. > > This isn't about relief lettering at all, but whether the card itself > requires on-line transactions, where (probably among other things) funds > are normally expected to be guaranteed as available to approve the > transaction. This used to be the key difference between Visa Debit and > Visa Electron, for example. In the US, both Debit and Credit cards work very similarily (from the customer using the card point of view) other than Debit cards often require entry of a PIN as part of the transaction. But both have limited to no usefulness without network connectivity to "run the purchase" unless (as ChatGPT said) the merchants agreement with the network allows for the merchant to collect the card info and only later process each transaction. And I would presume that if the merchant's agreement allows the "collect info, process over network later" mode, that the agreement also foists a significant amount of the transaction risk onto the merchant as well, further discuraging many from choosing this route. >> This is still possible in some circumstances, but it's much less >> common than it used to be because fraud controls are stricter. > > This is what's puzzling me now, given both Visa and Mastercard actually > did away with their on-line cards - or is this because the off-line > cards have changed and now act more like on-line cards? Not sure what you mean by Visa or Mastercard "on-line cards". As to standard credit cards, they are, for all intents and purposes, always processed anymore via instant network transaction through the payment rails to the issuing bank. No one writes down or otherwise records anything from the cards. One either "chips" or "NFC" taps the card, the machine pops "approved" or "denied", and if approved, the transaction is already listed in your account at the point you see "approved" on the charge card terminal. >> So the answer is: **yes, card payments can sometimes be made while >> offline, but whether a particular restaurant can do it depends on its >> payment terminal configuration and the payment provider's rules.** >> Many modern terminals will simply refuse the transaction if they >> cannot reach the authorization network. > > This also puzzles me, because I was under the impression credit cards > have been expected to allow off-line transactions. (And, after all, > being *credit* cards, allowing transactions without sufficient funds > would be a - or perhaps *the* - feature?) Not from the issuing banks perspective. Their "fraud detection algorithms" work by seeing the transactions as they come over the rails (not by batch processing them 12 hours later). So effectively, even if credit cards still might officially support a "no network use" mode, it is all but never used anymore.
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2026-06-04 07:36 +0200 |
| Message-ID | <4gf7fmxo8g.ln2@Telcontar.valinor> |
| In reply to | #87469 |
On 2026-06-04 06:15, Rich wrote: > Nuno Silva <nunojsilva@invalid.invalid> wrote: >> On 2026-06-03, Carlos E.R. wrote: >> >>> On 2026-06-03 13:48, Nuno Silva 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?) >>> >>> Apparently not. Maybe because the majority are debit cards, not credit >>> cards. But I have seen nobody with that paper thing that was used to >>> print a charge paper with the relief letters/numbers on the >>> cards. Cards no longer have relief lettering. >> >> This isn't about relief lettering at all, but whether the card itself >> requires on-line transactions, where (probably among other things) funds >> are normally expected to be guaranteed as available to approve the >> transaction. This used to be the key difference between Visa Debit and >> Visa Electron, for example. > > In the US, both Debit and Credit cards work very similarily (from the > customer using the card point of view) other than Debit cards often > require entry of a PIN as part of the transaction. > > But both have limited to no usefulness without network connectivity to > "run the purchase" unless (as ChatGPT said) the merchants agreement > with the network allows for the merchant to collect the card info and > only later process each transaction. And I would presume that if the > merchant's agreement allows the "collect info, process over network > later" mode, that the agreement also foists a significant amount of the > transaction risk onto the merchant as well, further discuraging many > from choosing this route. There should be no risk with credit cards, that's what they were designed for. But there would be need for some special "hardware" at the merchant, able to store and forward later the transactions. But then, some rural sites have never internet. Not intermittent. > >>> This is still possible in some circumstances, but it's much less >>> common than it used to be because fraud controls are stricter. >> >> This is what's puzzling me now, given both Visa and Mastercard actually >> did away with their on-line cards - or is this because the off-line >> cards have changed and now act more like on-line cards? > > Not sure what you mean by Visa or Mastercard "on-line cards". debit. > > As to standard credit cards, they are, for all intents and purposes, > always processed anymore via instant network transaction through the > payment rails to the issuing bank. No one writes down or otherwise > records anything from the cards. One either "chips" or "NFC" taps the > card, the machine pops "approved" or "denied", and if approved, the > transaction is already listed in your account at the point you see > "approved" on the charge card terminal. > Except if you choose "credit". They charge end of month or whatever you have agreed. >>> So the answer is: **yes, card payments can sometimes be made while >>> offline, but whether a particular restaurant can do it depends on its >>> payment terminal configuration and the payment provider's rules.** >>> Many modern terminals will simply refuse the transaction if they >>> cannot reach the authorization network. >> >> This also puzzles me, because I was under the impression credit cards >> have been expected to allow off-line transactions. (And, after all, >> being *credit* cards, allowing transactions without sufficient funds >> would be a - or perhaps *the* - feature?) > > Not from the issuing banks perspective. Their "fraud detection > algorithms" work by seeing the transactions as they come over the rails > (not by batch processing them 12 hours later). So effectively, even if > credit cards still might officially support a "no network use" mode, it > is all but never used anymore. Mmm. -- Cheers, Carlos. ES🇪🇸, EU🇪🇺;
[toc] | [prev] | [next] | [standalone]
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2026-06-04 02:19 -0400 |
| Message-ID | <5oKdnbyvkdiYhLz3nZ2dnZfqn_idnZ2d@giganews.com> |
| In reply to | #87478 |
Note - USA - there are considerable fraud/BS *protection* laws covering Credit Cards. There are NOT for direct bank xfers. MANY now DEMAND direct bank routing numbers for their services. Looked into T-Mobile/Verizon ... they both wanted direct xfer. Easier for THEM, but big potential disaster for ME. And, no matter their claims, Vlad/Xi/Kim/etc CAN cut into their 'safe' systems like a hot knife thru butter and steal all yer numbers. MAY have to set up a 'tiny acct' just for direct xfers. ONLY give out that number. Would still have to check it every few days alas ... what a pain !
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2026-06-04 08:34 +0200 |
| Message-ID | <5si7fmx04v.ln2@Telcontar.valinor> |
| In reply to | #87485 |
On 2026-06-04 08:19, c186282 wrote: > Note - USA - there are considerable fraud/BS *protection* > laws covering Credit Cards. > > There are NOT for direct bank xfers. > > MANY now DEMAND direct bank routing numbers for > their services. Looked into T-Mobile/Verizon ... > they both wanted direct xfer. Easier for THEM, > but big potential disaster for ME. > > And, no matter their claims, Vlad/Xi/Kim/etc > CAN cut into their 'safe' systems like a hot > knife thru butter and steal all yer numbers. > > MAY have to set up a 'tiny acct' just for > direct xfers. ONLY give out that number. > Would still have to check it every few > days alas ... what a pain ! > In Spain, all subscription services work by direct bank payments. You can not have electricity or water or gas at home without that system, plain simple. Of course there are protective laws. -- Cheers, Carlos. ES🇪🇸, EU🇪🇺;
[toc] | [prev] | [next] | [standalone]
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2026-06-04 10:26 -0400 |
| Message-ID | <N_WdnRyfmcapFrz3nZ2dnZfqnPidnZ2d@giganews.com> |
| In reply to | #87486 |
On 6/4/26 02:34, Carlos E.R. wrote: > On 2026-06-04 08:19, c186282 wrote: >> Note - USA - there are considerable fraud/BS *protection* >> laws covering Credit Cards. >> >> There are NOT for direct bank xfers. >> >> MANY now DEMAND direct bank routing numbers for >> their services. Looked into T-Mobile/Verizon ... >> they both wanted direct xfer. Easier for THEM, >> but big potential disaster for ME. >> >> And, no matter their claims, Vlad/Xi/Kim/etc >> CAN cut into their 'safe' systems like a hot >> knife thru butter and steal all yer numbers. >> >> MAY have to set up a 'tiny acct' just for >> direct xfers. ONLY give out that number. >> Would still have to check it every few >> days alas ... what a pain ! >> > > In Spain, all subscription services work by direct bank payments. You > can not have electricity or water or gas at home without that system, > plain simple. > > Of course there are protective laws. Not in USA. CCards yes, direct withdrawals, no. I suspect that's not going to change soon. So, Vlad can suck out ALL your money and it's just Tuff Titty.
[toc] | [prev] | [next] | [standalone]
| From | Andy Burns <usenet@andyburns.uk> |
|---|---|
| Date | 2026-06-04 08:18 +0100 |
| Message-ID | <n8cn5eF9f0eU1@mid.individual.net> |
| In reply to | #87469 |
Rich wrote: > In the US, both Debit and Credit cards work very similarily (from the > customer using the card point of view) other than Debit cards often > require entry of a PIN as part of the transaction. Last time I was there (in 2002) all my cards were chip and PIN, but all payments still used magstripe, also there was the alien concept of having to press a credit or debit button first, but sometimes I had to press the "wrong" button for the type of card to get it to work ...
[toc] | [prev] | [next] | [standalone]
| From | Nuno Silva <nunojsilva@invalid.invalid> |
|---|---|
| Date | 2026-06-04 09:48 +0100 |
| Message-ID | <10vre51$8f0a$3@dont-email.me> |
| In reply to | #87487 |
On 2026-06-04, Andy Burns wrote: > Rich wrote: > >> In the US, both Debit and Credit cards work very similarily (from the >> customer using the card point of view) other than Debit cards often >> require entry of a PIN as part of the transaction. > > Last time I was there (in 2002) all my cards were chip and PIN, but > all payments still used magstripe, also there was the alien concept of > having to press a credit or debit button first, but sometimes I had to > press the "wrong" button for the type of card to get it to work ... This usually has more to do with terminal payments and local regulations. IIRC some countries say you don't need PIN for credit cards, others have waived that and required signature for magstripe, while requiring PIN for "chip" transactions. The smartcards have to support all of this and IIRC this is what was taken advantage of in a proof-of-concept attempt to have a card (or was it the payment terminal) accept an incorrect PIN many years ago. .pt in the past had terminals choosing one payment method as default, but then changed (possibly by EU rules?) to always give the menu when a card offers more than one payment method. Most debit cards issued there are dual-network (SIBS Multibanco and usually one of Visa or Mastercard), so I guess this meant national cards started seeing that menu. -- Nuno Silva
[toc] | [prev] | [next] | [standalone]
Page 3 of 12 — ← Prev page 1 2 [3] 4 5 … 12 Next page →
Back to top | Article view | comp.os.linux.misc
csiph-web