Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.os.linux.misc > #90165 > unrolled thread
| Started by | Eli the Bearded <*@eli.users.panix.com> |
|---|---|
| First post | 2026-08-19 21:20 +0000 |
| Last post | 2026-08-29 18:15 +0100 |
| Articles | 20 on this page of 590 — 29 participants |
Back to article view | Back to comp.os.linux.misc
/dev/tcp Eli the Bearded <*@eli.users.panix.com> - 2026-08-19 21:20 +0000
Re: /dev/tcp Richard Kettlewell <invalid@invalid.invalid> - 2026-08-19 23:53 +0100
Re: /dev/tcp Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-19 23:42 +0000
Re: /dev/tcp Eli the Bearded <*@eli.users.panix.com> - 2026-08-20 00:59 +0000
Re: /dev/tcp Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-20 03:59 +0000
Re: /dev/tcp Nuno Silva <nunojsilva@invalid.invalid> - 2026-08-20 10:10 +0100
Re: /dev/tcp Eli the Bearded <*@eli.users.panix.com> - 2026-08-20 18:15 +0000
Re: /dev/tcp Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-20 23:30 +0000
Re: /dev/tcp Nuno Silva <nunojsilva@invalid.invalid> - 2026-08-21 01:18 +0100
Re: /dev/tcp Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-08-21 09:52 +0200
Re: /dev/tcp Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-21 08:12 +0000
Re: /dev/tcp Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-08-21 11:16 +0200
Re: /dev/tcp Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-21 22:57 +0000
Re: /dev/tcp Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-08-22 06:17 +0200
Re: /dev/tcp David De La Harpe Golden <david@harpegolden.net> - 2026-08-30 17:56 +0100
Re: /dev/tcp c186282 <c186282@nnada.net> - 2026-08-21 21:50 -0400
Re: /dev/tcp Anssi Saari <anssi.saari@usenet.mail.kapsi.fi> - 2026-08-24 17:42 +0300
Re: /dev/tcp Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-24 23:53 +0000
Re: /dev/tcp c186282 <c186282@nnada.net> - 2026-08-25 02:27 -0400
Re: /dev/tcp vallor <vallor@vallor.earth> - 2026-08-23 00:56 +0000
Re: /dev/tcp Rich <rich@example.invalid> - 2026-08-23 04:01 +0000
Re: /dev/tcp c186282 <c186282@nnada.net> - 2026-08-23 03:37 -0400
Re: /dev/tcp "Carlos E.R." <robin_listas@es.invalid> - 2026-08-23 13:50 +0200
Re: /dev/tcp vallor <vallor@vallor.earth> - 2026-08-23 22:28 +0000
Re: /dev/tcp "Carlos E.R." <robin_listas@es.invalid> - 2026-08-24 09:35 +0200
Overwriting with random data (was: Re: /dev/tcp) Nuno Silva <nunojsilva@invalid.invalid> - 2026-08-24 11:10 +0100
Re: Overwriting with random data "Carlos E.R." <robin_listas@es.invalid> - 2026-08-24 20:34 +0200
Re: Overwriting with random data Richard Kettlewell <invalid@invalid.invalid> - 2026-08-24 20:57 +0100
Re: Overwriting with random data "Carlos E.R." <robin_listas@es.invalid> - 2026-08-24 22:26 +0200
Re: Overwriting with random data c186282 <c186282@nnada.net> - 2026-08-25 02:39 -0400
Re: Overwriting with random data Richard Kettlewell <invalid@invalid.invalid> - 2026-08-25 08:45 +0100
Re: Overwriting with random data c186282 <c186282@nnada.net> - 2026-08-25 21:39 -0400
Re: Overwriting with random data Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-08-26 18:08 +0000
Re: Overwriting with random data Rich <rich@example.invalid> - 2026-08-28 00:49 +0000
Re: Overwriting with random data c186282 <c186282@nnada.net> - 2026-08-28 00:59 -0400
Re: Overwriting with random data The Natural Philosopher <tnp@invalid.invalid> - 2026-08-28 12:19 +0100
Re: Overwriting with random data "Carlos E.R." <robin_listas@es.invalid> - 2026-08-25 11:36 +0200
Re: Overwriting with random data Richard Kettlewell <invalid@invalid.invalid> - 2026-08-25 15:19 +0100
Re: Overwriting with random data c186282 <c186282@nnada.net> - 2026-08-26 03:33 -0400
Re: Overwriting with random data The Natural Philosopher <tnp@invalid.invalid> - 2026-08-26 09:18 +0100
Re: Overwriting with random data rbowman <bowman@montana.com> - 2026-08-26 17:34 +0000
Re: Overwriting with random data c186282 <c186282@nnada.net> - 2026-08-27 01:52 -0400
Re: Overwriting with random data The Natural Philosopher <tnp@invalid.invalid> - 2026-08-27 12:11 +0100
Re: Overwriting with random data Rich <rich@example.invalid> - 2026-08-28 01:00 +0000
Re: Overwriting with random data c186282 <c186282@nnada.net> - 2026-08-27 22:16 -0400
Re: Overwriting with random data Richard Kettlewell <invalid@invalid.invalid> - 2026-08-28 08:32 +0100
Re: Overwriting with random data c186282 <c186282@nnada.net> - 2026-08-28 03:34 -0400
Re: Overwriting with random data Pancho <Pancho.Jones@protonmail.com> - 2026-08-28 11:37 +0100
Re: Overwriting with random data The Natural Philosopher <tnp@invalid.invalid> - 2026-08-28 12:44 +0100
Re: Overwriting with random data Pancho <Pancho.Jones@protonmail.com> - 2026-08-28 13:25 +0100
Re: Overwriting with random data The Natural Philosopher <tnp@invalid.invalid> - 2026-08-28 15:27 +0100
Re: Overwriting with random data rbowman <bowman@montana.com> - 2026-08-28 19:30 +0000
Re: Overwriting with random data c186282 <c186282@nnada.net> - 2026-08-29 00:59 -0400
Re: Overwriting with random data c186282 <c186282@nnada.net> - 2026-08-29 01:57 -0400
Re: Overwriting with random data rbowman <bowman@montana.com> - 2026-08-29 20:42 +0000
Re: Overwriting with random data The Natural Philosopher <tnp@invalid.invalid> - 2026-08-28 12:33 +0100
Re: Overwriting with random data rbowman <bowman@montana.com> - 2026-08-28 19:50 +0000
Re: Overwriting with random data The Natural Philosopher <tnp@invalid.invalid> - 2026-08-29 10:11 +0100
Re: Overwriting with random data Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-08-29 05:25 +0000
Re: Overwriting with random data c186282 <c186282@nnada.net> - 2026-08-29 02:12 -0400
Re: Overwriting with random data The Natural Philosopher <tnp@invalid.invalid> - 2026-08-29 10:15 +0100
Re: Overwriting with random data c186282 <c186282@nnada.net> - 2026-08-29 21:56 -0400
Re: Overwriting with random data The Natural Philosopher <tnp@invalid.invalid> - 2026-08-28 12:29 +0100
Re: Overwriting with random data Pancho <Pancho.Jones@protonmail.com> - 2026-08-28 13:43 +0100
Re: Overwriting with random data Rich <rich@example.invalid> - 2026-08-28 20:15 +0000
Re: Overwriting with random data Leroy H <lh@somewhere.net> - 2026-08-28 21:59 +0000
Re: Overwriting with random data c186282 <c186282@nnada.net> - 2026-08-29 02:09 -0400
Re: Overwriting with random data Pancho <Pancho.Jones@protonmail.com> - 2026-08-29 08:59 +0100
Re: Overwriting with random data Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-29 09:25 +0000
Re: Overwriting with random data Pancho <Pancho.Jones@protonmail.com> - 2026-08-29 11:19 +0100
Re: Overwriting with random data rbowman <bowman@montana.com> - 2026-08-29 20:45 +0000
Re: Overwriting with random data Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-29 22:38 +0000
Re: Overwriting with random data Rich <rich@example.invalid> - 2026-09-02 19:33 +0000
Re: Overwriting with random data Leroy H <lh@somewhere.net> - 2026-09-02 20:21 +0000
Re: Overwriting with random data c186282 <c186282@nnada.net> - 2026-09-02 22:22 -0400
Re: Overwriting with random data Leroy H <lh@somewhere.net> - 2026-09-03 02:53 +0000
Re: Overwriting with random data c186282 <c186282@nnada.net> - 2026-09-02 23:28 -0400
Re: Overwriting with random data The Natural Philosopher <tnp@invalid.invalid> - 2026-09-03 11:51 +0100
Re: Overwriting with random data c186282 <c186282@nnada.net> - 2026-09-02 23:09 -0400
Re: Overwriting with random data The Natural Philosopher <tnp@invalid.invalid> - 2026-09-03 11:52 +0100
Re: Overwriting with random data Leroy H <lh@somewhere.net> - 2026-08-29 15:10 +0000
Re: Overwriting with random data Pancho <Pancho.Jones@protonmail.com> - 2026-08-30 08:58 +0100
Re: Overwriting with random data Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-30 23:45 +0000
Re: Overwriting with random data c186282 <c186282@nnada.net> - 2026-08-29 21:47 -0400
Re: Overwriting with random data Richard Kettlewell <invalid@invalid.invalid> - 2026-08-29 13:56 +0100
Re: Overwriting with random data Stéphane CARPENTIER <sc@fiat-linux.fr> - 2026-08-29 14:17 +0000
Re: Overwriting with random data Leroy H <lh@somewhere.net> - 2026-08-29 16:02 +0000
Re: Overwriting with random data "Carlos E. R." <robin_listas@es.invalid> - 2026-08-29 22:12 +0200
Re: Overwriting with random data Leroy H <lh@somewhere.net> - 2026-08-29 21:04 +0000
Re: Overwriting with random data Stéphane CARPENTIER <sc@fiat-linux.fr> - 2026-09-05 09:32 +0000
Re: Overwriting with random data Richard Kettlewell <invalid@invalid.invalid> - 2026-09-05 13:49 +0100
Re: Overwriting with random data Andreas Eder <a_eder_muc@web.de> - 2026-09-20 15:54 +0200
Re: Overwriting with random data Rich <rich@example.invalid> - 2026-08-28 00:58 +0000
Re: Overwriting with random data The Natural Philosopher <tnp@invalid.invalid> - 2026-08-28 12:23 +0100
Re: Overwriting with random data Rich <rich@example.invalid> - 2026-08-28 00:53 +0000
Re: Overwriting with random data The Natural Philosopher <tnp@invalid.invalid> - 2026-08-25 12:12 +0100
Re: Overwriting with random data c186282 <c186282@nnada.net> - 2026-08-26 00:09 -0400
Re: Overwriting with random data The Natural Philosopher <tnp@invalid.invalid> - 2026-08-26 08:52 +0100
Re: Overwriting with random data Rich <rich@example.invalid> - 2026-08-28 01:02 +0000
Re: Overwriting with random data Rich <rich@example.invalid> - 2026-08-28 00:48 +0000
Re: /dev/tcp c186282 <c186282@nnada.net> - 2026-08-25 00:37 -0400
Re: /dev/tcp c186282 <c186282@nnada.net> - 2026-08-24 00:31 -0400
Re: /dev/tcp "Carlos E.R." <robin_listas@es.invalid> - 2026-08-24 09:45 +0200
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-08-23 12:52 +0100
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-08-23 12:50 +0100
Re: /dev/tcp Rich <rich@example.invalid> - 2026-08-20 13:50 +0000
Re: /dev/tcp c186282 <c186282@nnada.net> - 2026-08-20 13:02 -0400
Re: /dev/tcp Rich <rich@example.invalid> - 2026-08-20 18:26 +0000
Re: /dev/tcp Stéphane CARPENTIER <sc@fiat-linux.fr> - 2026-08-29 13:48 +0000
Re: /dev/tcp Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-29 22:44 +0000
Re: /dev/tcp Robert Riches <spamtrap42@jacob21819.net> - 2026-08-29 23:05 +0000
Re: /dev/tcp vallor <vallor@vallor.earth> - 2026-08-30 00:58 +0000
Re: /dev/tcp Robert Riches <spamtrap42@jacob21819.net> - 2026-08-30 04:12 +0000
Re: /dev/tcp Stéphane CARPENTIER <sc@fiat-linux.fr> - 2026-08-30 09:25 +0000
Re: /dev/tcp Nuno Silva <nunojsilva@invalid.invalid> - 2026-08-30 11:00 +0100
Re: /dev/tcp Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-30 23:54 +0000
Re: /dev/tcp Richard Kettlewell <invalid@invalid.invalid> - 2026-08-31 09:34 +0100
Re: /dev/tcp Stéphane CARPENTIER <sc@fiat-linux.fr> - 2026-09-05 09:08 +0000
Re: /dev/tcp Richard Kettlewell <invalid@invalid.invalid> - 2026-09-05 10:25 +0100
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-05 19:19 +0100
Re: /dev/tcp Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-09-05 22:38 +0000
Re: /dev/tcp c186282 <c186282@nnada.net> - 2026-09-05 21:40 -0400
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-06 09:16 +0100
Re: /dev/tcp c186282 <c186282@nnada.net> - 2026-09-05 21:38 -0400
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-06 09:19 +0100
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-06 18:54 +0000
Re: /dev/tcp c186282 <c186282@nnada.net> - 2026-09-06 23:27 -0400
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-07 11:54 +0100
Re: /dev/tcp Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-09-07 03:52 +0000
Re: /dev/tcp c186282 <c186282@nnada.net> - 2026-09-07 00:12 -0400
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-07 12:00 +0100
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-07 19:34 +0000
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-07 22:23 +0100
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-08 05:45 +0000
Re: /dev/tcp Pancho <Pancho.Jones@protonmail.com> - 2026-09-07 22:24 +0100
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-08 05:48 +0000
Re: /dev/tcp c186282 <c186282@nnada.net> - 2026-09-08 01:52 -0400
Re: /dev/tcp Pancho <Pancho.Jones@protonmail.com> - 2026-09-08 08:46 +0100
[OT] /dev/economy (was: Re: /dev/tcp) Nuno Silva <nunojsilva@invalid.invalid> - 2026-09-08 10:28 +0100
Re: [OT] /dev/economy The Natural Philosopher <tnp@invalid.invalid> - 2026-09-08 13:43 +0100
Re: [OT] /dev/economy (was: Re: /dev/tcp) rbowman <bowman@montana.com> - 2026-09-08 18:32 +0000
Re: [OT] /dev/economy (was: Re: /dev/tcp) Robert Riches <spamtrap42@jacob21819.net> - 2026-09-08 20:38 +0000
Re: [OT] /dev/economy Nuno Silva <nunojsilva@invalid.invalid> - 2026-09-09 00:48 +0100
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-08 18:41 +0000
Re: /dev/tcp Nuno Silva <nunojsilva@invalid.invalid> - 2026-09-09 00:52 +0100
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-09 01:34 +0000
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-09 09:28 +0100
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-09 09:26 +0100
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-09 18:22 +0000
Re: /dev/tcp c186282 <c186282@nnada.net> - 2026-09-09 23:37 -0400
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-10 04:46 +0000
Re: /dev/tcp c186282 <c186282@nnada.net> - 2026-09-10 02:19 -0400
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-10 18:25 +0000
Re: /dev/tcp c186282 <c186282@nnada.net> - 2026-09-11 03:09 -0400
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-11 10:20 +0100
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-11 19:25 +0000
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-12 10:36 +0100
Re: /dev/tcp c186282 <c186282@nnada.net> - 2026-09-12 23:05 -0400
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-13 07:14 +0000
Re: /dev/tcp c186282 <c186282@nnada.net> - 2026-09-13 03:49 -0400
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-13 21:51 +0000
Re: /dev/tcp c186282 <c186282@nnada.net> - 2026-09-13 20:59 -0400
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-14 04:33 +0000
Re: /dev/tcp c186282 <c186282@nnada.net> - 2026-09-14 01:26 -0400
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-14 10:49 +0100
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-14 17:46 +0000
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-14 19:07 +0100
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-15 00:33 +0000
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-15 07:50 +0100
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-13 09:56 +0100
Re: /dev/tcp c186282 <c186282@nnada.net> - 2026-09-11 23:31 -0400
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-12 10:43 +0100
Re: /dev/tcp "Carlos E.R." <robin_listas@es.invalid> - 2026-09-12 14:05 +0200
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-12 17:40 +0100
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-12 19:29 +0000
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-11 19:21 +0000
Re: /dev/tcp c186282 <c186282@nnada.net> - 2026-09-12 02:37 -0400
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-10 11:31 +0100
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-10 18:38 +0000
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-11 00:26 +0100
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-11 04:10 +0000
Re: /dev/tcp c186282 <c186282@nnada.net> - 2026-09-09 01:00 -0400
Re: /dev/tcp c186282 <c186282@nnada.net> - 2026-09-09 00:55 -0400
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-08 09:32 +0100
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-08 18:44 +0000
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-08 21:05 +0100
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-09 01:35 +0000
Re: /dev/tcp c186282 <c186282@nnada.net> - 2026-09-09 03:47 -0400
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-09 18:18 +0000
Re: /dev/tcp c186282 <c186282@nnada.net> - 2026-09-09 23:22 -0400
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-10 04:44 +0000
Re: /dev/tcp c186282 <c186282@nnada.net> - 2026-09-10 02:13 -0400
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-10 11:26 +0100
Re: /dev/tcp "Carlos E.R." <robin_listas@es.invalid> - 2026-09-10 19:07 +0200
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-10 18:35 +0000
Re: /dev/tcp c186282 <c186282@nnada.net> - 2026-09-11 03:24 -0400
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-11 10:27 +0100
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-11 19:07 +0000
Re: /dev/tcp c186282 <c186282@nnada.net> - 2026-09-12 02:36 -0400
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-12 10:26 +0100
Re: /dev/tcp c186282 <c186282@nnada.net> - 2026-09-12 23:01 -0400
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-13 09:52 +0100
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-12 10:23 +0100
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-12 19:22 +0000
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-10 19:37 +0100
Re: /dev/tcp "Carlos E.R." <robin_listas@es.invalid> - 2026-09-10 20:58 +0200
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-11 00:25 +0100
Re: /dev/tcp "Carlos E. R." <robin_listas@es.invalid> - 2026-09-11 11:32 +0200
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-11 10:51 +0100
Re: /dev/tcp "Carlos E. R." <robin_listas@es.invalid> - 2026-09-11 12:03 +0200
[OT] Middle East (was: Re: /dev/tcp) Nuno Silva <nunojsilva@invalid.invalid> - 2026-09-12 00:43 +0100
Re: /dev/tcp c186282 <c186282@nnada.net> - 2026-09-12 02:09 -0400
Re: /dev/tcp Nuno Silva <nunojsilva@invalid.invalid> - 2026-09-12 10:26 +0100
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-12 11:45 +0100
[OT] Middle East (was: Re: /dev/tcp) Nuno Silva <nunojsilva@invalid.invalid> - 2026-09-13 09:56 +0100
Re: [OT] Middle East The Natural Philosopher <tnp@invalid.invalid> - 2026-09-13 10:37 +0100
Re: [OT] Middle East rbowman <bowman@montana.com> - 2026-09-13 19:33 +0000
Re: [OT] Middle East The Natural Philosopher <tnp@invalid.invalid> - 2026-09-13 21:01 +0100
Re: [OT] Middle East "Rinaldi J. Montessi" <rinaldij@alien.free> - 2026-09-13 17:30 -0500
Re: [OT] Middle East c186282 <c186282@nnada.net> - 2026-09-13 22:05 -0400
Re: [OT] Middle East rbowman <bowman@montana.com> - 2026-09-14 03:19 +0000
Re: [OT] Middle East c186282 <c186282@nnada.net> - 2026-09-13 23:35 -0400
Re: [OT] Middle East The Natural Philosopher <tnp@invalid.invalid> - 2026-09-14 10:52 +0100
Re: [OT] Middle East rbowman <bowman@montana.com> - 2026-09-14 02:37 +0000
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-12 10:47 +0100
Re: /dev/tcp "Carlos E.R." <robin_listas@es.invalid> - 2026-09-12 14:09 +0200
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-12 17:41 +0100
Re: /dev/tcp "Carlos E.R." <robin_listas@es.invalid> - 2026-09-12 14:07 +0200
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-12 17:45 +0100
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-12 10:13 +0100
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-12 19:05 +0000
[OT] Middle East (was: Re: /dev/tcp) Nuno Silva <nunojsilva@invalid.invalid> - 2026-09-13 10:01 +0100
Re: [OT] Middle East The Natural Philosopher <tnp@invalid.invalid> - 2026-09-13 10:11 +0100
Re: [OT] Middle East Nuno Silva <nunojsilva@invalid.invalid> - 2026-09-13 10:40 +0100
Re: [OT] Middle East The Natural Philosopher <tnp@invalid.invalid> - 2026-09-13 10:58 +0100
Re: [OT] Middle East "Carlos E.R." <robin_listas@es.invalid> - 2026-09-13 14:08 +0200
Re: [OT] Middle East The Natural Philosopher <tnp@invalid.invalid> - 2026-09-13 21:01 +0100
Re: [OT] Middle East c186282 <c186282@nnada.net> - 2026-09-13 20:48 -0400
Re: [OT] Middle East Nuno Silva <nunojsilva@invalid.invalid> - 2026-09-14 10:45 +0100
Re: [OT] Middle East The Natural Philosopher <tnp@invalid.invalid> - 2026-09-14 10:59 +0100
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-11 04:12 +0000
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-11 10:16 +0100
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-11 19:13 +0000
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-12 10:27 +0100
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-12 19:42 +0000
Re: /dev/tcp c186282 <c186282@nnada.net> - 2026-09-13 00:22 -0400
Re: /dev/tcp Pancho <Pancho.Jones@protonmail.com> - 2026-09-13 07:51 +0100
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-13 07:02 +0000
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-13 09:31 +0100
Re: /dev/tcp Pancho <Pancho.Jones@protonmail.com> - 2026-09-13 09:45 +0100
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-13 10:21 +0100
Re: /dev/tcp c186282 <c186282@nnada.net> - 2026-09-13 03:02 -0400
Re: /dev/tcp Pancho <Pancho.Jones@protonmail.com> - 2026-09-13 08:39 +0100
Re: /dev/tcp c186282 <c186282@nnada.net> - 2026-09-13 03:50 -0400
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-13 10:13 +0100
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-13 09:51 +0100
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-13 09:44 +0100
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-13 21:39 +0000
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-13 09:31 +0100
Re: /dev/tcp c186282 <c186282@nnada.net> - 2026-09-13 19:32 -0400
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-14 10:54 +0100
Re: /dev/tcp Pancho <Pancho.Jones@protonmail.com> - 2026-09-14 09:20 +0100
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-14 11:06 +0100
Re: /dev/tcp Pancho <Pancho.Jones@protonmail.com> - 2026-09-14 19:56 +0100
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-14 20:07 +0100
Re: /dev/tcp Pancho <Pancho.Jones@protonmail.com> - 2026-09-14 23:01 +0100
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-15 00:30 +0000
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-15 07:42 +0100
Re: /dev/tcp "Carlos E. R." <robin_listas@es.invalid> - 2026-09-15 09:26 +0200
[OT] "Democracy" Exports of the United States (was: Re: /dev/tcp) Nuno Silva <nunojsilva@invalid.invalid> - 2026-09-15 10:18 +0100
Re: [OT] "Democracy" Exports of the United States "Carlos E. R." <robin_listas@es.invalid> - 2026-09-15 20:24 +0200
Re: [OT] "Democracy" Exports of the United States The Natural Philosopher <tnp@invalid.invalid> - 2026-09-16 00:51 +0100
Re: [OT] "Democracy" Exports of the United States rbowman <bowman@montana.com> - 2026-09-16 00:56 +0000
Re: [OT] "Democracy" Exports of the United States "Carlos E. R." <robin_listas@es.invalid> - 2026-09-16 07:25 +0200
Re: [OT] "Democracy" Exports of the United States The Natural Philosopher <tnp@invalid.invalid> - 2026-09-16 11:13 +0100
Re: [OT] "Democracy" Exports of the United States The Natural Philosopher <tnp@invalid.invalid> - 2026-09-16 11:09 +0100
Re: [OT] "Democracy" Exports of the United States rbowman <bowman@montana.com> - 2026-09-16 00:52 +0000
Re: [OT] "Democracy" Exports of the United States "Carlos E. R." <robin_listas@es.invalid> - 2026-09-16 07:26 +0200
Re: [OT] "Democracy" Exports of the United States The Natural Philosopher <tnp@invalid.invalid> - 2026-09-16 11:09 +0100
Re: [OT] "Democracy" Exports of the United States rbowman <bowman@montana.com> - 2026-09-16 18:17 +0000
Re: [OT] "Democracy" Exports of the United States The Natural Philosopher <tnp@invalid.invalid> - 2026-09-17 11:24 +0100
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-15 16:34 +0100
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-15 18:27 +0000
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-15 18:21 +0000
Re: /dev/tcp "Carlos E. R." <robin_listas@es.invalid> - 2026-09-15 20:32 +0200
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-16 02:17 +0000
Re: /dev/tcp Richard Kettlewell <invalid@invalid.invalid> - 2026-09-15 18:30 +0100
Re: /dev/tcp Richard Kettlewell <invalid@invalid.invalid> - 2026-09-15 21:35 +0100
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-16 00:59 +0100
Re: /dev/tcp Pancho <Pancho.Jones@protonmail.com> - 2026-09-16 08:20 +0100
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-16 11:33 +0100
Re: /dev/tcp "Carlos E. R." <robin_listas@es.invalid> - 2026-09-16 18:16 +0200
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-16 17:50 +0100
Re: /dev/tcp "Carlos E.R." <robin_listas@es.invalid> - 2026-09-16 19:55 +0200
Re: /dev/tcp Nuno Silva <nunojsilva@invalid.invalid> - 2026-09-17 01:10 +0100
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-17 02:30 +0000
Re: /dev/tcp c186282 <c186282@nnada.net> - 2026-09-16 23:19 -0400
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-17 12:44 +0100
Re: /dev/tcp "Carlos E.R." <robin_listas@es.invalid> - 2026-09-17 20:19 +0200
Re: /dev/tcp Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-09-17 23:27 +0000
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-18 02:54 +0000
Re: /dev/tcp c186282 <c186282@nnada.net> - 2026-09-18 01:14 -0400
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-18 08:29 +0100
Re: /dev/tcp Lane W <cactus_DAC@yahoo.com> - 2026-09-18 08:29 -0600
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-18 08:27 +0100
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-18 20:07 +0000
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-19 11:24 +0100
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-19 10:53 +0000
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-19 13:35 +0100
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-19 19:29 +0000
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-20 10:29 +0100
Re: /dev/tcp "Carlos E.R." <robin_listas@es.invalid> - 2026-09-19 22:01 +0200
Re: /dev/tcp c186282 <c186282@nnada.net> - 2026-09-19 23:41 -0400
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-20 10:34 +0100
Re: /dev/tcp "Carlos E.R." <robin_listas@es.invalid> - 2026-09-20 14:07 +0200
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-20 17:40 +0000
Re: /dev/tcp "Carlos E.R." <robin_listas@es.invalid> - 2026-09-20 21:03 +0200
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-21 13:21 +0100
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-21 13:18 +0100
Re: /dev/tcp Chris Abraham <chris@gerriscorp.com> - 2026-09-21 13:16 -0400
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-21 23:13 +0100
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-22 03:38 +0000
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-22 06:49 +0100
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-21 19:14 +0000
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-21 23:31 +0100
Re: /dev/tcp Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-09-21 23:13 +0000
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-22 04:22 +0000
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-22 06:55 +0100
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-22 03:51 +0000
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-21 13:13 +0100
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-20 10:22 +0100
Re: /dev/tcp "Carlos E.R." <robin_listas@es.invalid> - 2026-09-17 08:05 +0200
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-17 12:46 +0100
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-17 20:31 +0000
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-17 12:16 +0100
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-17 20:48 +0000
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-17 12:11 +0100
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-17 20:52 +0000
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-17 22:16 +0100
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-17 11:12 +0100
Re: /dev/tcp Pancho <Pancho.Jones@protonmail.com> - 2026-09-17 07:16 +0100
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-17 06:37 +0000
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-17 13:43 +0100
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-17 13:32 +0100
Re: /dev/tcp Pancho <Pancho.Jones@protonmail.com> - 2026-09-17 21:51 +0100
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-17 22:15 +0100
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-16 18:22 +0000
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-17 11:25 +0100
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-17 20:35 +0000
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-17 22:06 +0100
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-18 03:23 +0000
Re: /dev/tcp c186282 <c186282@nnada.net> - 2026-09-18 01:24 -0400
Re: /dev/tcp Nuno Silva <nunojsilva@invalid.invalid> - 2026-09-17 00:58 +0100
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-17 11:55 +0100
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-17 20:28 +0000
Re: /dev/tcp c186282 <c186282@nnada.net> - 2026-09-17 22:19 -0400
Re: /dev/tcp Pancho <Pancho.Jones@protonmail.com> - 2026-09-17 21:58 +0100
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-17 22:25 +0100
Re: /dev/tcp Nuno Silva <nunojsilva@invalid.invalid> - 2026-09-18 00:57 +0100
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-18 03:02 +0000
[OT] Washington Treaty of 1949 (was: Re: /dev/tcp) Nuno Silva <nunojsilva@invalid.invalid> - 2026-09-18 10:59 +0100
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-18 02:58 +0000
Re: /dev/tcp Richard Kettlewell <invalid@invalid.invalid> - 2026-09-18 10:02 +0100
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-15 18:18 +0000
Re: /dev/tcp Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-09-15 18:49 +0000
Re: /dev/tcp "Carlos E. R." <robin_listas@es.invalid> - 2026-09-15 21:21 +0200
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-16 00:53 +0100
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-16 02:34 +0000
Re: /dev/tcp Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-09-16 04:31 +0000
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-16 06:36 +0000
Re: /dev/tcp Pancho <Pancho.Jones@protonmail.com> - 2026-09-16 08:30 +0100
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-16 02:29 +0000
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-14 17:43 +0000
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-14 19:05 +0100
Re: /dev/tcp Pancho <Pancho.Jones@protonmail.com> - 2026-09-14 19:50 +0100
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-14 20:00 +0100
Re: /dev/tcp Pancho <Pancho.Jones@protonmail.com> - 2026-09-14 23:05 +0100
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-15 00:18 +0000
Re: /dev/tcp c186282 <c186282@nnada.net> - 2026-09-15 01:52 -0400
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-15 07:48 +0100
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-15 17:30 +0000
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-16 00:43 +0100
Re: /dev/tcp c186282 <c186282@nnada.net> - 2026-09-16 00:37 -0400
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-16 06:33 +0000
[OT] /dev/middle-east (was: Re: /dev/tcp) Nuno Silva <nunojsilva@invalid.invalid> - 2026-09-16 11:37 +0100
Re: [OT] /dev/middle-east The Natural Philosopher <tnp@invalid.invalid> - 2026-09-16 11:45 +0100
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-16 11:26 +0100
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-16 18:38 +0000
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-17 11:33 +0100
Re: /dev/tcp Nuno Silva <nunojsilva@invalid.invalid> - 2026-09-17 11:54 +0100
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-17 13:58 +0100
Re: /dev/tcp c186282 <c186282@nnada.net> - 2026-09-17 23:25 -0400
Re: /dev/tcp Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-09-15 18:49 +0000
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-16 00:57 +0100
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-15 07:45 +0100
Re: /dev/tcp c186282 <c186282@nnada.net> - 2026-09-14 21:03 -0400
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-15 07:58 +0100
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-14 23:56 +0000
Re: /dev/tcp Nuno Silva <nunojsilva@invalid.invalid> - 2026-09-15 02:00 +0100
Re: /dev/tcp c186282 <c186282@nnada.net> - 2026-09-15 02:14 -0400
Re: /dev/tcp c186282 <c186282@nnada.net> - 2026-09-14 20:59 -0400
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-15 07:56 +0100
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-15 17:48 +0000
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-16 00:43 +0100
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-16 01:56 +0000
Re: /dev/tcp "Carlos E. R." <robin_listas@es.invalid> - 2026-09-15 21:28 +0200
Re: /dev/tcp Nuno Silva <nunojsilva@invalid.invalid> - 2026-09-16 00:04 +0100
Re: /dev/tcp Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-15 23:32 +0000
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-16 00:58 +0100
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-16 01:33 +0000
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-16 11:23 +0100
Re: /dev/tcp "Carlos E. R." <robin_listas@es.invalid> - 2026-09-16 09:01 +0200
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-16 11:29 +0100
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-16 01:20 +0000
Re: /dev/tcp "Carlos E. R." <robin_listas@es.invalid> - 2026-09-16 09:03 +0200
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-16 11:21 +0100
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-16 18:43 +0000
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-17 11:38 +0100
Re: /dev/tcp Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-09-17 17:44 +0000
[OT] Are Ceuta and Melilla actually part of the Schengen Area? (was: Re: /dev/tcp) Nuno Silva <nunojsilva@invalid.invalid> - 2026-09-16 11:31 +0100
Re: [OT] Are Ceuta and Melilla actually part of the Schengen Area? "Carlos E.R." <robin_listas@es.invalid> - 2026-09-16 20:35 +0200
Re: [OT] Are Ceuta and Melilla actually part of the Schengen Area? rbowman <bowman@montana.com> - 2026-09-17 02:24 +0000
Re: [OT] Are Ceuta and Melilla actually part of the Schengen Area? "Carlos E.R." <robin_listas@es.invalid> - 2026-09-17 08:09 +0200
Re: [OT] Are Ceuta and Melilla actually part of the Schengen Area? Nuno Silva <nunojsilva@invalid.invalid> - 2026-09-17 10:21 +0100
Re: [OT] Are Ceuta and Melilla actually part of the Schengen Area? "Carlos E.R." <robin_listas@es.invalid> - 2026-09-17 11:53 +0200
Re: [OT] Are Ceuta and Melilla actually part of the Schengen Area? The Natural Philosopher <tnp@invalid.invalid> - 2026-09-17 11:31 +0100
Re: [OT] Are Ceuta and Melilla actually part of the Schengen Area? rbowman <bowman@montana.com> - 2026-09-17 20:20 +0000
Re: [OT] Are Ceuta and Melilla actually part of the Schengen Area? The Natural Philosopher <tnp@invalid.invalid> - 2026-09-17 21:58 +0100
Re: [OT] Are Ceuta and Melilla actually part of the Schengen Area? rbowman <bowman@montana.com> - 2026-09-18 02:48 +0000
Re: [OT] Are Ceuta and Melilla actually part of the Schengen Area? The Natural Philosopher <tnp@invalid.invalid> - 2026-09-18 08:42 +0100
Re: [OT] Are Ceuta and Melilla actually part of the Schengen Area? rbowman <bowman@montana.com> - 2026-09-18 19:30 +0000
Re: [OT] Are Ceuta and Melilla actually part of the Schengen Area? rbowman <bowman@montana.com> - 2026-09-17 20:18 +0000
Re: [OT] Are Ceuta and Melilla actually part of the Schengen Area? The Natural Philosopher <tnp@invalid.invalid> - 2026-09-17 21:57 +0100
Re: [OT] Are Ceuta and Melilla actually part of the Schengen Area? rbowman <bowman@montana.com> - 2026-09-18 02:41 +0000
Re: [OT] Are Ceuta and Melilla actually part of the Schengen Area? The Natural Philosopher <tnp@invalid.invalid> - 2026-09-18 08:33 +0100
Re: [OT] Are Ceuta and Melilla actually part of the Schengen Area? rbowman <bowman@montana.com> - 2026-09-18 19:52 +0000
Re: [OT] Are Ceuta and Melilla actually part of the Schengen Area? The Natural Philosopher <tnp@invalid.invalid> - 2026-09-17 11:30 +0100
Re: [OT] Are Ceuta and Melilla actually part of the Schengen Area? The Natural Philosopher <tnp@invalid.invalid> - 2026-09-17 11:26 +0100
Re: [OT] Are Ceuta and Melilla actually part of the Schengen Area? Nuno Silva <nunojsilva@invalid.invalid> - 2026-09-17 11:47 +0100
Re: [OT] Are Ceuta and Melilla actually part of the Schengen Area? The Natural Philosopher <tnp@invalid.invalid> - 2026-09-17 13:52 +0100
Re: [OT] Are Ceuta and Melilla actually part of the Schengen Area? rbowman <bowman@montana.com> - 2026-09-17 20:16 +0000
Re: [OT] Are Ceuta and Melilla actually part of the Schengen Area? The Natural Philosopher <tnp@invalid.invalid> - 2026-09-17 21:54 +0100
Re: [OT] Are Ceuta and Melilla actually part of the Schengen Area? rbowman <bowman@montana.com> - 2026-09-18 02:45 +0000
Re: [OT] Are Ceuta and Melilla actually part of the Schengen Area? The Natural Philosopher <tnp@invalid.invalid> - 2026-09-18 08:37 +0100
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-13 09:03 +0100
Re: /dev/tcp c186282 <c186282@nnada.net> - 2026-09-11 23:07 -0400
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-12 10:40 +0100
Re: /dev/tcp c186282 <c186282@nnada.net> - 2026-09-12 23:06 -0400
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-09 09:29 +0100
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-09 18:20 +0000
Re: /dev/tcp c186282 <c186282@nnada.net> - 2026-09-09 23:26 -0400
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-10 11:29 +0100
Re: /dev/tcp c186282 <c186282@nnada.net> - 2026-09-11 00:58 -0400
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-11 10:19 +0100
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-10 11:27 +0100
Re: /dev/tcp Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-09-09 04:25 +0000
Re: /dev/tcp c186282 <c186282@nnada.net> - 2026-09-09 00:43 -0400
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-09 09:31 +0100
Re: /dev/tcp c186282 <c186282@nnada.net> - 2026-09-09 23:12 -0400
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-10 11:32 +0100
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-08 09:31 +0100
Re: /dev/tcp c186282 <c186282@nnada.net> - 2026-09-07 22:20 -0400
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-08 05:05 +0000
Re: /dev/tcp c186282 <c186282@nnada.net> - 2026-09-08 01:51 -0400
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-08 09:34 +0100
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-09-07 11:59 +0100
Re: /dev/tcp rbowman <bowman@montana.com> - 2026-09-07 19:18 +0000
Re: /dev/tcp c186282 <c186282@nnada.net> - 2026-09-05 21:35 -0400
Re: /dev/tcp Richard Kettlewell <invalid@invalid.invalid> - 2026-08-30 13:06 +0100
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-08-21 13:54 +0100
Re: /dev/tcp c186282 <c186282@nnada.net> - 2026-08-21 22:57 -0400
Re: /dev/tcp "Carlos E.R." <robin_listas@es.invalid> - 2026-08-22 21:47 +0200
The hammer is best (Was: /dev/tcp) gazelle@shell.xmission.com (Kenny McCormack) - 2026-08-22 23:50 +0000
Re: The hammer is best (Was: /dev/tcp) c186282 <c186282@nnada.net> - 2026-08-23 04:28 -0400
Re: The hammer is best Richard Kettlewell <invalid@invalid.invalid> - 2026-08-23 10:14 +0100
Re: The hammer is best "Carlos E.R." <robin_listas@es.invalid> - 2026-08-23 13:55 +0200
Re: The hammer is best The Natural Philosopher <tnp@invalid.invalid> - 2026-08-23 13:16 +0100
Re: The hammer is best Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-08-23 21:20 +0200
Re: The hammer is best c186282 <c186282@nnada.net> - 2026-08-24 02:18 -0400
Re: The hammer is best The Natural Philosopher <tnp@invalid.invalid> - 2026-08-24 11:26 +0100
Re: The hammer is best c186282 <c186282@nnada.net> - 2026-08-25 02:06 -0400
Re: The hammer is best The Natural Philosopher <tnp@invalid.invalid> - 2026-08-25 12:18 +0100
Re: The hammer is best c186282 <c186282@nnada.net> - 2026-08-26 00:51 -0400
Re: The hammer is best Joed Oakes <lost@noway.home.invalid> - 2026-08-23 19:42 -0400
Re: The hammer is best Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-23 23:56 +0000
Re: The hammer is best c186282 <c186282@nnada.net> - 2026-08-24 02:25 -0400
Re: The hammer is best rbowman <bowman@montana.com> - 2026-08-24 01:14 +0000
Re: The hammer is best "Carlos E.R." <robin_listas@es.invalid> - 2026-08-24 09:50 +0200
Re: The hammer is best c186282 <c186282@nnada.net> - 2026-08-25 00:56 -0400
Re: The hammer is best c186282 <c186282@nnada.net> - 2026-08-24 00:53 -0400
Re: The hammer is best rbowman <bowman@montana.com> - 2026-08-24 06:42 +0000
Re: The hammer is best c186282 <c186282@nnada.net> - 2026-08-24 23:34 -0400
Re: The hammer is best rbowman <bowman@montana.com> - 2026-08-25 04:08 +0000
Re: The hammer is best "Carlos E.R." <robin_listas@es.invalid> - 2026-08-25 11:29 +0200
Re: The hammer is best rbowman <bowman@montana.com> - 2026-08-25 18:52 +0000
Re: The hammer is best c186282 <c186282@nnada.net> - 2026-08-26 04:19 -0400
Re: The hammer is best The Natural Philosopher <tnp@invalid.invalid> - 2026-08-26 09:29 +0100
Re: The hammer is best rbowman <bowman@montana.com> - 2026-08-26 17:03 +0000
Re: The hammer is best The Natural Philosopher <tnp@invalid.invalid> - 2026-08-26 21:31 +0100
Re: The hammer is best c186282 <c186282@nnada.net> - 2026-08-25 22:18 -0400
Re: The hammer is best The Natural Philosopher <tnp@invalid.invalid> - 2026-08-24 11:28 +0100
Re: The hammer is best c186282 <c186282@nnada.net> - 2026-08-25 02:07 -0400
Re: The hammer is best rbowman <bowman@montana.com> - 2026-08-25 06:39 +0000
Re: The hammer is best The Natural Philosopher <tnp@invalid.invalid> - 2026-08-25 12:23 +0100
Re: The hammer is best Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-08-25 18:26 +0000
Re: The hammer is best The Natural Philosopher <tnp@invalid.invalid> - 2026-08-25 20:05 +0100
Re: The hammer is best "Carlos E.R." <robin_listas@es.invalid> - 2026-08-25 21:43 +0200
Re: The hammer is best The Natural Philosopher <tnp@invalid.invalid> - 2026-08-26 08:35 +0100
Re: The hammer is best Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-08-25 20:21 +0000
Re: The hammer is best "Carlos E.R." <robin_listas@es.invalid> - 2026-08-25 23:14 +0200
Re: The hammer is best rbowman <bowman@montana.com> - 2026-08-25 19:08 +0000
Re: The hammer is best c186282 <c186282@nnada.net> - 2026-08-26 04:38 -0400
Re: The hammer is best The Natural Philosopher <tnp@invalid.invalid> - 2026-08-26 10:22 +0100
Re: The hammer is best rbowman <bowman@montana.com> - 2026-08-26 17:26 +0000
Re: The hammer is best c186282 <c186282@nnada.net> - 2026-08-27 00:00 -0400
Re: The hammer is best c186282 <c186282@nnada.net> - 2026-08-27 03:44 -0400
Re: The hammer is best c186282 <c186282@nnada.net> - 2026-08-26 01:49 -0400
Re: The hammer is best The Natural Philosopher <tnp@invalid.invalid> - 2026-08-25 12:20 +0100
Re: The hammer is best c186282 <c186282@nnada.net> - 2026-08-26 01:23 -0400
Re: The hammer is best c186282 <c186282@nnada.net> - 2026-08-23 22:16 -0400
Re: /dev/tcp Geoff Clare <geoff@clare.See-My-Signature.invalid> - 2026-08-21 13:41 +0100
Re: /dev/tcp Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-21 22:58 +0000
Re: /dev/tcp c186282 <c186282@nnada.net> - 2026-08-21 22:28 -0400
ksh (was: /dev/tcp) Geoff Clare <geoff@clare.See-My-Signature.invalid> - 2026-08-24 13:56 +0100
Bash vs. ksh - Does it matter? And the 'vi' mode thing... (Was: ksh (was: /dev/tcp)) gazelle@shell.xmission.com (Kenny McCormack) - 2026-08-24 14:57 +0000
Re: Bash vs. ksh - Does it matter? And the 'vi' mode thing... (Was: ksh Andy Burns <usenet@andyburns.uk> - 2026-08-30 13:26 +0100
Re: Bash vs. ksh - Does it matter? And the 'vi' mode thing... (Was: ksh Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-30 23:49 +0000
Re: Bash vs. ksh - Does it matter? And the 'vi' mode thing... (Was: ksh c186282 <c186282@nnada.net> - 2026-08-31 01:35 -0400
Re: ksh (was: /dev/tcp) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-24 21:08 +0000
Re: ksh (was: /dev/tcp) gazelle@shell.xmission.com (Kenny McCormack) - 2026-08-24 21:28 +0000
Re: ksh (was: /dev/tcp) Stéphane CARPENTIER <sc@fiat-linux.fr> - 2026-08-29 13:29 +0000
Re: ksh (was: /dev/tcp) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-29 22:41 +0000
Re: ksh (was: /dev/tcp) Geoff Clare <geoff@clare.See-My-Signature.invalid> - 2026-08-31 13:43 +0100
Re: ksh (was: /dev/tcp) rbowman <bowman@montana.com> - 2026-08-25 01:11 +0000
Re: ksh (was: /dev/tcp) Geoff Clare <geoff@clare.See-My-Signature.invalid> - 2026-08-25 13:25 +0100
Re: ksh (was: /dev/tcp) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-25 21:58 +0000
Re: ksh (was: /dev/tcp) Geoff Clare <geoff@clare.See-My-Signature.invalid> - 2026-08-26 13:34 +0100
Re: ksh (was: /dev/tcp) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-27 02:23 +0000
Re: ksh c186282 <c186282@nnada.net> - 2026-08-27 03:40 -0400
Re: ksh c186282 <c186282@nnada.net> - 2026-08-27 01:40 -0400
Re: ksh (was: /dev/tcp) Stéphane CARPENTIER <sc@fiat-linux.fr> - 2026-08-29 13:40 +0000
Re: ksh c186282 <c186282@nnada.net> - 2026-08-25 02:25 -0400
Re: ksh rbowman <bowman@montana.com> - 2026-08-25 06:52 +0000
Re: ksh The Natural Philosopher <tnp@invalid.invalid> - 2026-08-25 12:27 +0100
Re: ksh Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-08-25 18:26 +0000
Re: ksh Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-25 22:03 +0000
Re: ksh c186282 <c186282@nnada.net> - 2026-08-26 04:04 -0400
Re: ksh rbowman <bowman@montana.com> - 2026-08-26 18:00 +0000
Re: ksh c186282 <c186282@nnada.net> - 2026-08-27 03:17 -0400
Re: ksh rbowman <bowman@montana.com> - 2026-08-27 15:22 +0000
Re: ksh The Natural Philosopher <tnp@invalid.invalid> - 2026-08-27 17:55 +0100
Re: ksh c186282 <c186282@nnada.net> - 2026-08-27 23:14 -0400
Re: ksh The Natural Philosopher <tnp@invalid.invalid> - 2026-08-28 12:48 +0100
Re: ksh c186282 <c186282@nnada.net> - 2026-08-27 22:43 -0400
Re: ksh rbowman <bowman@montana.com> - 2026-08-28 04:17 +0000
Re: ksh c186282 <c186282@nnada.net> - 2026-08-28 03:18 -0400
Re: ksh Robert Riches <spamtrap42@jacob21819.net> - 2026-08-28 15:54 +0000
Re: ksh rbowman <bowman@montana.com> - 2026-08-28 20:40 +0000
Re: ksh The Natural Philosopher <tnp@invalid.invalid> - 2026-08-29 10:14 +0100
Re: ksh rbowman <bowman@montana.com> - 2026-08-29 21:12 +0000
Re: ksh c186282 <c186282@nnada.net> - 2026-08-26 02:35 -0400
Re: ksh rbowman <bowman@montana.com> - 2026-08-26 18:17 +0000
Re: ksh Marco Moock <mm@dorfdsl.de> - 2026-08-25 09:56 +0200
Re: ksh "Carlos E.R." <robin_listas@es.invalid> - 2026-08-25 11:24 +0200
Re: ksh Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-08-25 20:36 +0200
Re: ksh rbowman <bowman@montana.com> - 2026-08-26 04:23 +0000
Re: ksh "Carlos E.R." <robin_listas@es.invalid> - 2026-08-26 10:04 +0200
Re: ksh Nuno Silva <nunojsilva@invalid.invalid> - 2026-08-26 10:03 +0100
Re: ksh c186282 <c186282@nnada.net> - 2026-08-25 21:50 -0400
Re: ksh Stéphane CARPENTIER <sc@fiat-linux.fr> - 2026-08-29 13:38 +0000
Re: ksh Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-29 22:42 +0000
Re: ksh "Carlos E. R." <robin_listas@es.invalid> - 2026-08-30 14:26 +0200
Re: ksh The Natural Philosopher <tnp@invalid.invalid> - 2026-08-25 12:27 +0100
Re: ksh c186282 <c186282@nnada.net> - 2026-08-26 02:43 -0400
Re: ksh Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-25 22:01 +0000
Re: ksh "Carlos E.R." <robin_listas@es.invalid> - 2026-08-26 01:32 +0200
Re: ksh c186282 <c186282@nnada.net> - 2026-08-25 21:46 -0400
Re: ksh rbowman <bowman@montana.com> - 2026-08-26 04:25 +0000
Re: /dev/tcp Eli the Bearded <*@eli.users.panix.com> - 2026-08-20 18:22 +0000
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-08-21 13:57 +0100
Re: /dev/tcp Lars Poulsen <lars@beagle-ears.com> - 2026-08-23 06:37 -0700
Re: /dev/tcp Richard Kettlewell <invalid@invalid.invalid> - 2026-08-23 14:49 +0100
Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-08-23 16:13 +0100
Re: /dev/tcp Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-23 22:31 +0000
Re: /dev/tcp Richard Kettlewell <invalid@invalid.invalid> - 2026-08-24 19:08 +0100
Re: /dev/tcp David De La Harpe Golden <david@harpegolden.net> - 2026-08-29 00:52 +0100
Re: /dev/tcp Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-29 04:14 +0000
Re: /dev/tcp David De La Harpe Golden <david@harpegolden.net> - 2026-08-29 19:06 +0100
[OT] Weather Underground (was: Re: /dev/tcp) Nuno Silva <nunojsilva@invalid.invalid> - 2026-08-29 08:58 +0100
Re: [OT] Weather Underground David De La Harpe Golden <david@harpegolden.net> - 2026-08-29 18:15 +0100
Page 6 of 30 — ← Prev page 1 … 4 5 [6] 7 8 … 30 Next page →
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2026-08-25 00:37 -0400 |
| Message-ID | <UaqcnZw5f_uEgRD3nZ2dnZfqn_SdnZ2d@giganews.com> |
| In reply to | #90443 |
On 8/24/26 03:35, Carlos E.R. wrote:
> On 2026-08-24 00:28, vallor wrote:
>> At Sun, 23 Aug 2026 13:50:30 +0200, "Carlos E.R."
>> <robin_listas@es.invalid> wrote:
>>
>>> On 2026-08-23 09:37, c186282 wrote:
>>>> On 8/23/26 00:01, Rich wrote:
>>>>> vallor <vallor@vallor.earth> wrote:
>>>>>> At Thu, 20 Aug 2026 23:30:40 -0000 (UTC), Lawrence D’Oliveiro
>>>>>> <ldo@nz.invalid> wrote:
>>>>>>
>>>>>>> On Thu, 20 Aug 2026 18:15:27 -0000 (UTC), Eli the Bearded wrote:
>>>>>>>
>>>>>>>> In comp.os.linux.misc, Lawrence DOliveiro <ldo@nz.invalid> wrote:
>>>>>>>>>
>>>>>>>>> On Thu, 20 Aug 2026 00:59:41 -0000 (UTC), Eli the Bearded wrote:
>>>>>>>>>>
>>>>>>>>>> This came up in the context of "how to test network on a system
>>>>>>>>>> with no root and no helpful utilities installed."
>>>>>>>>>
>>>>>>>>> So a version of bash that supports /dev/tcp is somehow excluded
>>>>>>>>> from that “no helpful utilities installed” assumption?
>>>>>>>>
>>>>>>>> The system being tested did not have bash installed. Busybox
>>>>>>>> provided /bin/sh there.
>>>>>>>
>>>>>>> I thought you said you were testing the *network*, not the *system*.
>>>>>>>
>>>>>>> You can’t really do that (in general) without access to a proper
>>>>>>> suite of diagnostic tools.
>>>>>>>
>>>>>>> In such a situation, I would try one (or both) of two things:
>>>>>>>
>>>>>>> * Reboot the machine with a SystemRescue USB stick
>>>>>>> <https://www.system-rescue.org/>. That way, I get unconstrained
>>>>>>> access to an entire system custom-designed precisely for running
>>>>>>> diagnostics.
>>>>>>> * Bring in my own machine, which already has my own custom setup on
>>>>>>> it, and connect it to the network.
>>>>>>>
>>>>>>> Both of these also have the advantage of ruling out screwups in the
>>>>>>> existing OS installation.
>>>>>>>
>>>>>>> And if you’re saying the situation would not allow me to do
>>>>>>> either of
>>>>>>> these things, then I would not have accepted the job in the first
>>>>>>> place.
>>>>>>
>>>>>> Have you ever agreed with someone?
>>>>>
>>>>> It's kind of the troll ethos, disagreeing brings on more chaos.
>>>>
>>>>
>>>> There are always a few ... being negative/disagreeable
>>>> or, worse, All-Superior is Their Main Thing. They feel
>>>> they "Gain Power" that way.
>>>>
>>>> No, I'm not basing that on Freud or Jung - just long
>>>> experience.
>>>>
>>>> I pref the "Let's All Get Along" approach. Everything
>>>> goes MUCH smoother and solutions, rather than conflict,
>>>> is the usual result.
>>>>
>>>> ANYway, /dev/tcp does have uses. It's worth exploring.
>>>> Maybe YOU can find a use to suit YOUR needs/desires.
>>>> I used it for a custom disk-scan/wipe app (had to
>>>> use a 'C' module because huge track/cluster/byte numbers
>>>> were needed for modern mag drives - the main app was
>>>> in Lazarus for the pretty display and buttons).
>>>>
>>>> Note Lazarus/FPC *says* it supports huge seek numbers
>>>> but DOESN'T ... limited to maybe 4gb.
>>>
>>> I wrote a program that writes bytes on big partitions.
>>>
>>>
>>> excerpted:
>>>
>>> const
>>> sourcefilename = './BigRandom';
>>> rawdest: string = ''; // example: '/dev/sda11'
>>>
>>> shuflecount = 1024;
>>> arraysize = 1023;
>>> ChunkSz=1048576;
>>> type
>>> tCacho= array [1..ChunkSz] of byte;
>>>
>>> var
>>> Fin, Fout: file of tCacho;
>>> gotresult: Word;
>>>
>>> BigData : array [1..shuflecount] of tCacho;
>>> OutputIndex : Int64; // counts MiB written.
>>>
>>>
>>> begin
>>>
>>> // writes one MiB
>>> {$I-}write(Fout,BigData[RandomIndex]);{$I+}
>>> gotresult:= ioresult;
>>>
>>>
>>>
>>> The purpose of the program is to fast fill a partition or disk with
>>> nearly true random data. It is as fast as dd could be.
>>
>> SHRED(1) User Commands SHRED(1)
>>
>> NAME
>> shred - overwrite a file to hide its contents, and
>> optionally delete it
>>
>> SYNOPSIS
>> shred [OPTION]... FILE...
>>
>> DESCRIPTION
>> Overwrite the specified FILE(s) repeatedly, in order to
>> make it harder for even very expensive hardware probing
>> to recover the data.
>
> Not the same thing.
And NO good for SSDs.
[toc] | [prev] | [next] | [standalone]
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2026-08-24 00:31 -0400 |
| Message-ID | <ViCdnRVVJp6KVBb3nZ2dnZfqnPudnZ2d@giganews.com> |
| In reply to | #90387 |
On 8/23/26 07:50, Carlos E.R. wrote:
> On 2026-08-23 09:37, c186282 wrote:
>> On 8/23/26 00:01, Rich wrote:
>>> vallor <vallor@vallor.earth> wrote:
>>>> At Thu, 20 Aug 2026 23:30:40 -0000 (UTC), Lawrence D’Oliveiro
>>>> <ldo@nz.invalid> wrote:
>>>>
>>>>> On Thu, 20 Aug 2026 18:15:27 -0000 (UTC), Eli the Bearded wrote:
>>>>>
>>>>>> In comp.os.linux.misc, Lawrence DOliveiro <ldo@nz.invalid> wrote:
>>>>>>>
>>>>>>> On Thu, 20 Aug 2026 00:59:41 -0000 (UTC), Eli the Bearded wrote:
>>>>>>>>
>>>>>>>> This came up in the context of "how to test network on a system
>>>>>>>> with no root and no helpful utilities installed."
>>>>>>>
>>>>>>> So a version of bash that supports /dev/tcp is somehow excluded
>>>>>>> from that “no helpful utilities installed” assumption?
>>>>>>
>>>>>> The system being tested did not have bash installed. Busybox
>>>>>> provided /bin/sh there.
>>>>>
>>>>> I thought you said you were testing the *network*, not the *system*.
>>>>>
>>>>> You can’t really do that (in general) without access to a proper
>>>>> suite of diagnostic tools.
>>>>>
>>>>> In such a situation, I would try one (or both) of two things:
>>>>>
>>>>> * Reboot the machine with a SystemRescue USB stick
>>>>> <https://www.system-rescue.org/>. That way, I get unconstrained
>>>>> access to an entire system custom-designed precisely for running
>>>>> diagnostics.
>>>>> * Bring in my own machine, which already has my own custom setup on
>>>>> it, and connect it to the network.
>>>>>
>>>>> Both of these also have the advantage of ruling out screwups in the
>>>>> existing OS installation.
>>>>>
>>>>> And if you’re saying the situation would not allow me to do either of
>>>>> these things, then I would not have accepted the job in the first
>>>>> place.
>>>>
>>>> Have you ever agreed with someone?
>>>
>>> It's kind of the troll ethos, disagreeing brings on more chaos.
>>
>>
>> There are always a few ... being negative/disagreeable
>> or, worse, All-Superior is Their Main Thing. They feel
>> they "Gain Power" that way.
>>
>> No, I'm not basing that on Freud or Jung - just long
>> experience.
>>
>> I pref the "Let's All Get Along" approach. Everything
>> goes MUCH smoother and solutions, rather than conflict,
>> is the usual result.
>>
>> ANYway, /dev/tcp does have uses. It's worth exploring.
>> Maybe YOU can find a use to suit YOUR needs/desires.
>> I used it for a custom disk-scan/wipe app (had to
>> use a 'C' module because huge track/cluster/byte numbers
>> were needed for modern mag drives - the main app was
>> in Lazarus for the pretty display and buttons).
>>
>> Note Lazarus/FPC *says* it supports huge seek numbers
>> but DOESN'T ... limited to maybe 4gb.
>
> I wrote a program that writes bytes on big partitions.
>
>
> excerpted:
>
> const
> sourcefilename = './BigRandom';
> rawdest: string = ''; // example: '/dev/sda11'
>
> shuflecount = 1024;
> arraysize = 1023;
> ChunkSz=1048576;
> type
> tCacho= array [1..ChunkSz] of byte;
>
> var
> Fin, Fout: file of tCacho;
> gotresult: Word;
>
> BigData : array [1..shuflecount] of tCacho;
> OutputIndex : Int64; // counts MiB written.
>
>
> begin
>
> // writes one MiB
> {$I-}write(Fout,BigData[RandomIndex]);{$I+}
> gotresult:= ioresult;
>
>
> The purpose of the program is to fast fill a partition or disk with
> nearly true random data. It is as fast as dd could be.
Um ... how many GB could that cope with ?
'Seek' counts can sometimes be supplimented
by an 'offset' value - so basically you're
getting the mult of two doubles. I didn't
do it that way, and thus needed very large
sector/track/cluster integers. An external 'C'
pgm using really large integer types was needed.
Anyway, it worked.
My app could ALSO just LOOK at data, kinda put
it into a "ghex"-looking sidebar (but with
ASCII translation if possible). So you could
just look, OR zap. Anyway, nothing TOO complex
aside from the sheer size of modern mag disks.
As useful utility. I encourage people to write
their own.
DID add one odd, maybe questionable, feature ...
you could spec on the CL x-number of gigs to
TOTALLY wipe at the beginning ... and then
a couple numbers for "shotgun" blasting of
later tracks. Most of the file-table/system
stuff tends to be early on, and data with
holes in it is "less useful". This made the
"wipes" much faster.
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2026-08-24 09:45 +0200 |
| Message-ID | <jd9tlmxhcg.ln2@Telcontar.valinor> |
| In reply to | #90426 |
On 2026-08-24 06:31, c186282 wrote:
> On 8/23/26 07:50, Carlos E.R. wrote:
>> On 2026-08-23 09:37, c186282 wrote:
>>> On 8/23/26 00:01, Rich wrote:
>>>> vallor <vallor@vallor.earth> wrote:
>>>>> At Thu, 20 Aug 2026 23:30:40 -0000 (UTC), Lawrence D’Oliveiro
>>>>> <ldo@nz.invalid> wrote:
>>> ANYway, /dev/tcp does have uses. It's worth exploring.
>>> Maybe YOU can find a use to suit YOUR needs/desires.
>>> I used it for a custom disk-scan/wipe app (had to
>>> use a 'C' module because huge track/cluster/byte numbers
>>> were needed for modern mag drives - the main app was
>>> in Lazarus for the pretty display and buttons).
>>>
>>> Note Lazarus/FPC *says* it supports huge seek numbers
>>> but DOESN'T ... limited to maybe 4gb.
>>
>> I wrote a program that writes bytes on big partitions.
>>
>>
>> excerpted:
>>
>> const
>> sourcefilename = './BigRandom';
>> rawdest: string = ''; // example: '/dev/sda11'
>>
>> shuflecount = 1024;
>> arraysize = 1023;
>> ChunkSz=1048576;
>> type
>> tCacho= array [1..ChunkSz] of byte;
>>
>> var
>> Fin, Fout: file of tCacho;
>> gotresult: Word;
>>
>> BigData : array [1..shuflecount] of tCacho;
>> OutputIndex : Int64; // counts MiB written.
>>
>>
>> begin
>>
>> // writes one MiB
>> {$I-}write(Fout,BigData[RandomIndex]);{$I+}
>> gotresult:= ioresult;
>>
>>
>> The purpose of the program is to fast fill a partition or disk with
>> nearly true random data. It is as fast as dd could be.
>
> Um ... how many GB could that cope with ?
I have done entire disks sized terabytes. But I don't actually use "seek".
>
> 'Seek' counts can sometimes be supplimented
> by an 'offset' value - so basically you're
> getting the mult of two doubles. I didn't
> do it that way, and thus needed very large
> sector/track/cluster integers. An external 'C'
> pgm using really large integer types was needed.
Can you seek not a byte, but a record or array?
Seek(var F; N: Int64)
File can be a file of some variable that is not a byte. And
type Int64 = - 9223372036854775808..9223372036854775807;
(why signed?)
Why not QWord?
type QWord = 0..18446744073709551615;
> Anyway, it worked.
>
> My app could ALSO just LOOK at data, kinda put
> it into a "ghex"-looking sidebar (but with
> ASCII translation if possible). So you could
> just look, OR zap. Anyway, nothing TOO complex
> aside from the sheer size of modern mag disks.
>
> As useful utility. I encourage people to write
> their own.
>
> DID add one odd, maybe questionable, feature ...
> you could spec on the CL x-number of gigs to
> TOTALLY wipe at the beginning ... and then
> a couple numbers for "shotgun" blasting of
> later tracks. Most of the file-table/system
> stuff tends to be early on, and data with
> holes in it is "less useful". This made the
> "wipes" much faster.
>
--
Cheers, Carlos.
ES🇪🇸, EU🇪🇺;
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2026-08-23 12:52 +0100 |
| Message-ID | <116emud$1sako$6@dont-email.me> |
| In reply to | #90376 |
On 23/08/2026 08:37, c186282 wrote: > There are always a few ... being negative/disagreeable > or, worse, All-Superior is Their Main Thing. They feel > they "Gain Power" that way. I think they just get a kick out of being responded to. It's sort of an idle occupation, like swatting flies or doodling. Piss someone off on the Internet. Imagine some guy on second line support who spends his life on front of a screen with nothing to do until shit happens -- "The great thing about Glasgow is that if there's a nuclear attack it'll look exactly the same afterwards." Billy Connolly
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2026-08-23 12:50 +0100 |
| Message-ID | <116emqf$1sako$5@dont-email.me> |
| In reply to | #90370 |
On 23/08/2026 05:01, Rich wrote: >> Have you ever agreed with someone? > It's kind of the troll ethos, disagreeing brings on more chaos. LOL... -- "The great thing about Glasgow is that if there's a nuclear attack it'll look exactly the same afterwards." Billy Connolly
[toc] | [prev] | [next] | [standalone]
| From | Rich <rich@example.invalid> |
|---|---|
| Date | 2026-08-20 13:50 +0000 |
| Message-ID | <11670nh$3hihn$1@dont-email.me> |
| In reply to | #90165 |
Eli the Bearded <*@eli.users.panix.com> wrote: > What system(s) have /dev/tcp/* natively? What "systems"? Only those with a /bin/bash compiled with this "special bash feature" compiled in. > $ man bash > [...] > REDIRECTION > [...] > Bash handles several filenames specially when they are used in > redirections, as described in the following table. If the > operating system on which bash is running provides these > special files, bash will use them; other wise it will emulate > them internally with the behavior described below. > [...] > /dev/tcp/host/port > If host is a valid hostname or Internet address, > and port is an integer port number or service name, > bash attempts to open the corresponding TCP socket. > > I don't see it on the various systems I have handy (Debian 13, Amazon > Linux 2023, Mac OS 15.7.x, NetBSD 10.1, Android 14). > is it a plan9 thing? It's a Bash feature. Note the man page quote you provided: > **Bash** handles several filenames specially when they are used in > redirections These are handled by Bash, they don't exist as part of the OS (system).
[toc] | [prev] | [next] | [standalone]
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2026-08-20 13:02 -0400 |
| Message-ID | <jLednbRwA9SGrhr3nZ2dnZfqn_udnZ2d@giganews.com> |
| In reply to | #90207 |
On 8/20/26 09:50, Rich wrote: > Eli the Bearded <*@eli.users.panix.com> wrote: >> What system(s) have /dev/tcp/* natively? > > What "systems"? Only those with a /bin/bash compiled with this > "special bash feature" compiled in. > >> $ man bash >> [...] >> REDIRECTION >> [...] >> Bash handles several filenames specially when they are used in >> redirections, as described in the following table. If the >> operating system on which bash is running provides these >> special files, bash will use them; other wise it will emulate >> them internally with the behavior described below. >> [...] >> /dev/tcp/host/port >> If host is a valid hostname or Internet address, >> and port is an integer port number or service name, >> bash attempts to open the corresponding TCP socket. >> >> I don't see it on the various systems I have handy (Debian 13, Amazon >> Linux 2023, Mac OS 15.7.x, NetBSD 10.1, Android 14). > >> is it a plan9 thing? > > It's a Bash feature. Note the man page quote you provided: > >> **Bash** handles several filenames specially when they are used in >> redirections > > These are handled by Bash, they don't exist as part of the OS (system). Correct. I've used the /dev/tcp trick before to check ports. Seems to only work with Bash. Others might add it eventually, but not too likely. Other odd Linux tricks - how many know you can read/write to a disk drive that has no file system ? GParted does have an option that creates a "blank" drive. It's an old trick, squeeze in more raw data. To a degree, it can make that data a bit more "portable" because it's not tied to EXT?/NTFS/XFS/etc. You just need a system that can open the 'blank' as an I/O device.
[toc] | [prev] | [next] | [standalone]
| From | Rich <rich@example.invalid> |
|---|---|
| Date | 2026-08-20 18:26 +0000 |
| Message-ID | <1167gt3$3neg1$1@dont-email.me> |
| In reply to | #90219 |
c186282 <c186282@nnada.net> wrote: > Other odd Linux tricks - how many know you can > read/write to a disk drive that has no file > system ? That is not a Linux trick, that's a Unix feature given that devices are mapped to files. Just write your data to /dev/sda (whole disk, including boot sector) or /dev/sda5 (5th partition on disk). That is where the 'dd' command is useful. You can "clone" a disk on Unix (if you are root, or if the two disk device files have write permission for your current user) by just doing: dd if=/dev/sda of=/dev/sdb bs=4096 Assuming the disks use 4096 byte sectors. No need for extra "disk cloning" machines to actually duplicate a disk. You can also backup the same way (although it is a rather wasteful way, as you also backup all the empty "free space" too): dd if=/dev/sda of=/tmp/disk-backup bs=4096 None of this is new to anyone who's used, and understood from an admin perspective, a Unix system for any short length of time.
[toc] | [prev] | [next] | [standalone]
| From | Stéphane CARPENTIER <sc@fiat-linux.fr> |
|---|---|
| Date | 2026-08-29 13:48 +0000 |
| Message-ID | <6a92e32c$0$28046$426a74cc@news.free.fr> |
| In reply to | #90227 |
Le 20-08-2026, Rich <rich@example.invalid> a écrit : > > That is where the 'dd' command is useful. You can "clone" a disk on > Unix (if you are root, or if the two disk device files have write > permission for your current user) by just doing: > > dd if=/dev/sda of=/dev/sdb bs=4096 I create a lot of USB sticks to boot Linux with dd. But I always add status=progress at the end of the line to be able to know when I can remove my usb stick. -- Si vous avez du temps à perdre : https://scarpet42.gitlab.io
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-08-29 22:44 +0000 |
| Message-ID | <116vncf$3jcff$15@dont-email.me> |
| In reply to | #90827 |
On 29 Aug 2026 13:48:28 GMT, Stéphane CARPENTIER wrote: > I create a lot of USB sticks to boot Linux with dd. But I always add > status=progress at the end of the line to be able to know when I can > remove my usb stick. Surely when the dd command terminates, that should be indication enough ...
[toc] | [prev] | [next] | [standalone]
| From | Robert Riches <spamtrap42@jacob21819.net> |
|---|---|
| Date | 2026-08-29 23:05 +0000 |
| Message-ID | <slrn1196pd1.bqu.spamtrap42@one.localnet> |
| In reply to | #90866 |
On 2026-08-29, Lawrence D’Oliveiro <ldo@nz.invalid> wrote: > On 29 Aug 2026 13:48:28 GMT, Stéphane CARPENTIER wrote: > >> I create a lot of USB sticks to boot Linux with dd. But I always add >> status=progress at the end of the line to be able to know when I can >> remove my usb stick. > > Surely when the dd command terminates, that should be indication > enough ... Unless the dd command was run without an option to do synchronous I/O and the tail end of the data is still being flushed from the queue. IIUC, doing a 'sync' afterward _should_ theoretically catch that case, too. -- Robert Riches spamtrap42@jacob21819.net (Yes, that is one of my email addresses.)
[toc] | [prev] | [next] | [standalone]
| From | vallor <vallor@vallor.earth> |
|---|---|
| Date | 2026-08-30 00:58 +0000 |
| Message-ID | <116vv86$3les3$2@dont-email.me> |
| In reply to | #90870 |
At 29 Aug 2026 23:05:05 GMT, Robert Riches <spamtrap42@jacob21819.net> wrote: > On 2026-08-29, Lawrence D’Oliveiro <ldo@nz.invalid> wrote: > > On 29 Aug 2026 13:48:28 GMT, Stéphane CARPENTIER wrote: > > > >> I create a lot of USB sticks to boot Linux with dd. But I always add > >> status=progress at the end of the line to be able to know when I can > >> remove my usb stick. > > > > Surely when the dd command terminates, that should be indication > > enough ... > > Unless the dd command was run without an option to do synchronous > I/O and the tail end of the data is still being flushed from the > queue. IIUC, doing a 'sync' afterward _should_ theoretically > catch that case, too. From inspecting the man pages for sync(1) (and sync(2)), it appears that running "sync" will only write out filesystem data. But there's ways to tell dd(1) to write data with various syncronization options. "oflag=sync" probably does what you want it to do. Kind of like: $ time -p dd if=/dev/zero of=/dev/null oflag=sync count=10000 \ bs=$[1024*1024] 10000+0 records in 10000+0 records out 10485760000 bytes (10 GB, 9.8 GiB) copied, 0.383306 s, 27.4 GB/s real 0.38 user 0.00 sys 0.38 -- -v System76 Thelio Mega v1.1 x86_64 Mem: 258G OS: Linux 7.2.1 D: Mint 22.3 DE: Xfce 4.18 (X11) NVIDIA GeForce RTX 3090Ti (24G) (610.57.04) "One way to better your lot is to do a lot better..."
[toc] | [prev] | [next] | [standalone]
| From | Robert Riches <spamtrap42@jacob21819.net> |
|---|---|
| Date | 2026-08-30 04:12 +0000 |
| Message-ID | <slrn1197bdj.rrn.spamtrap42@one.localnet> |
| In reply to | #90873 |
On 2026-08-30, vallor <vallor@vallor.earth> wrote: > At 29 Aug 2026 23:05:05 GMT, Robert Riches <spamtrap42@jacob21819.net> wrote: > >> On 2026-08-29, Lawrence D’Oliveiro <ldo@nz.invalid> wrote: >> > On 29 Aug 2026 13:48:28 GMT, Stéphane CARPENTIER wrote: >> > >> >> I create a lot of USB sticks to boot Linux with dd. But I always add >> >> status=progress at the end of the line to be able to know when I can >> >> remove my usb stick. >> > >> > Surely when the dd command terminates, that should be indication >> > enough ... >> >> Unless the dd command was run without an option to do synchronous >> I/O and the tail end of the data is still being flushed from the >> queue. IIUC, doing a 'sync' afterward _should_ theoretically >> catch that case, too. > > From inspecting the man pages for sync(1) (and sync(2)), it > appears that running "sync" will only write out filesystem data. > > But there's ways to tell dd(1) to write data with various > syncronization options. "oflag=sync" probably does what you > want it to do. Kind of like: > > $ time -p dd if=/dev/zero of=/dev/null oflag=sync count=10000 \ > bs=$[1024*1024] > 10000+0 records in > 10000+0 records out > 10485760000 bytes (10 GB, 9.8 GiB) copied, 0.383306 s, 27.4 GB/s > real 0.38 > user 0.00 > sys 0.38 Thanks for another perspective. That's interesting about the man page calling out specifically "filesystem data". I would have thought /dev/sdl (my USB stick) would qualify as "filesystem data" as a device node accessed via the /dev filesystem, but maybe it's doing at a different level of I/O stack. I did an experiment doing dd from /dev/zero to /dev/sdl (a USB stick), and in my case the "Dirty" line of /proc/meminfo never did not show increasingly large number as it usually does when writing to a regular file on a slower device. The sync command immediately after the dd command finished in essentially zero time. However, the lack of a build-up of queued writes would indicate the dd command never let writes accumulate, independent of whether sync would have waited for any that might have accumulated. I might ask a friend who has more kernel and internal I/O expertise than me. -- Robert Riches spamtrap42@jacob21819.net (Yes, that is one of my email addresses.)
[toc] | [prev] | [next] | [standalone]
| From | Stéphane CARPENTIER <sc@fiat-linux.fr> |
|---|---|
| Date | 2026-08-30 09:25 +0000 |
| Message-ID | <6a93f706$0$31866$426a74cc@news.free.fr> |
| In reply to | #90873 |
Le 30-08-2026, vallor <vallor@vallor.earth> a écrit : > At 29 Aug 2026 23:05:05 GMT, Robert Riches <spamtrap42@jacob21819.net> wrote: > >> On 2026-08-29, Lawrence D’Oliveiro <ldo@nz.invalid> wrote: >> > On 29 Aug 2026 13:48:28 GMT, Stéphane CARPENTIER wrote: >> > >> >> I create a lot of USB sticks to boot Linux with dd. But I always add >> >> status=progress at the end of the line to be able to know when I can >> >> remove my usb stick. >> > >> > Surely when the dd command terminates, that should be indication >> > enough ... No. You should try it by yourself. >> Unless the dd command was run without an option to do synchronous >> I/O and the tail end of the data is still being flushed from the >> queue. IIUC, doing a 'sync' afterward _should_ theoretically >> catch that case, too. I find it easier to put an option to be sure dd doesn't finish before everything is written on the USB stick than launching other commands after that. > From inspecting the man pages for sync(1) (and sync(2)), it > appears that running "sync" will only write out filesystem data. I'm not that sure about that. It looks like you can chose what file to synchronize. > But there's ways to tell dd(1) to write data with various > syncronization options. "oflag=sync" probably does what you > want it to do. Kind of like: I didn't say there was only one way to do it. I said that putting the option status=progress makes sure that the dd command doesn't terminate before everything is written on the USB stick, so I know I can remove it. -- Si vous avez du temps à perdre : https://scarpet42.gitlab.io
[toc] | [prev] | [next] | [standalone]
| From | Nuno Silva <nunojsilva@invalid.invalid> |
|---|---|
| Date | 2026-08-30 11:00 +0100 |
| Message-ID | <1170uv3$3u4us$3@dont-email.me> |
| In reply to | #90890 |
On 2026-08-30, Stéphane CARPENTIER wrote: > Le 30-08-2026, vallor <vallor@vallor.earth> a écrit : >> At 29 Aug 2026 23:05:05 GMT, Robert Riches <spamtrap42@jacob21819.net> wrote: >> >>> On 2026-08-29, Lawrence D’Oliveiro <ldo@nz.invalid> wrote: >>> > On 29 Aug 2026 13:48:28 GMT, Stéphane CARPENTIER wrote: >>> > >>> >> I create a lot of USB sticks to boot Linux with dd. But I always add >>> >> status=progress at the end of the line to be able to know when I can >>> >> remove my usb stick. >>> > >>> > Surely when the dd command terminates, that should be indication >>> > enough ... > > No. You should try it by yourself. > >>> Unless the dd command was run without an option to do synchronous >>> I/O and the tail end of the data is still being flushed from the >>> queue. IIUC, doing a 'sync' afterward _should_ theoretically >>> catch that case, too. > > I find it easier to put an option to be sure dd doesn't finish before > everything is written on the USB stick than launching other commands > after that. > >> From inspecting the man pages for sync(1) (and sync(2)), it >> appears that running "sync" will only write out filesystem data. > > I'm not that sure about that. It looks like you can chose what file to > synchronize. Here, the online manual does not imply it's only filesystem data, it merely says that *if a file is specified* it syncs the file or its filesystem, but you don't have to specify a file, but... (This for the GNU coreutils implementation.) ... now the pages for both Linux and POSIX sync() appear to be worded such that it's only "filesystem data", and that's also what's on IEEE 1003.1? <https://pubs.opengroup.org/onlinepubs/9799919799/functions/sync.html> >> But there's ways to tell dd(1) to write data with various >> syncronization options. "oflag=sync" probably does what you >> want it to do. Kind of like: > > I didn't say there was only one way to do it. I said that putting the > option status=progress makes sure that the dd command doesn't terminate > before everything is written on the USB stick, so I know I can remove > it. -- Nuno Silva
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-08-30 23:54 +0000 |
| Message-ID | <1172fr3$fkiu$4@dont-email.me> |
| In reply to | #90890 |
On 30 Aug 2026 09:25:26 GMT, Stéphane CARPENTIER wrote: > On Sat, 29 Aug 2026 22:44:32 -0000 (UTC), Lawrence D’Oliveiro wrote: > >> On 29 Aug 2026 13:48:28 GMT, Stéphane CARPENTIER wrote: >> >>> I create a lot of USB sticks to boot Linux with dd. But I always >>> add status=progress at the end of the line to be able to know when >>> I can remove my usb stick. >> >> Surely when the dd command terminates, that should be indication >> enough ... > > No. You should try it by yourself. I do this frequently. That’s why I raised the point. > I said that putting the option status=progress makes sure that the > dd command doesn't terminate before everything is written on the USB > stick, so I know I can remove it. You’re thinking of OS-level caches, I think. That’s not the option for controlling them; look at the “conv=” options with “sync” in their name: “fdatasync” and “fsync”.
[toc] | [prev] | [next] | [standalone]
| From | Richard Kettlewell <invalid@invalid.invalid> |
|---|---|
| Date | 2026-08-31 09:34 +0100 |
| Message-ID | <wwvo6eid6xu.fsf@LkoBDZeT.terraraq.uk> |
| In reply to | #90890 |
Stéphane CARPENTIER <sc@fiat-linux.fr> writes: > Le 30-08-2026, vallor <vallor@vallor.earth> a écrit : >> At 29 Aug 2026 23:05:05 GMT, Robert Riches <spamtrap42@jacob21819.net> wrote: >> >>> On 2026-08-29, Lawrence D’Oliveiro <ldo@nz.invalid> wrote: >>> > On 29 Aug 2026 13:48:28 GMT, Stéphane CARPENTIER wrote: >>> > >>> >> I create a lot of USB sticks to boot Linux with dd. But I always add >>> >> status=progress at the end of the line to be able to know when I can >>> >> remove my usb stick. >>> > >>> > Surely when the dd command terminates, that should be indication >>> > enough ... > > No. You should try it by yourself. > >>> Unless the dd command was run without an option to do synchronous >>> I/O and the tail end of the data is still being flushed from the >>> queue. IIUC, doing a 'sync' afterward _should_ theoretically >>> catch that case, too. > > I find it easier to put an option to be sure dd doesn't finish before > everything is written on the USB stick than launching other commands > after that. status=progress is not that option. >> From inspecting the man pages for sync(1) (and sync(2)), it >> appears that running "sync" will only write out filesystem data. > > I'm not that sure about that. It looks like you can chose what file to > synchronize. > >> But there's ways to tell dd(1) to write data with various >> syncronization options. "oflag=sync" probably does what you >> want it to do. Kind of like: > > I didn't say there was only one way to do it. I said that putting the > option status=progress makes sure that the dd command doesn't > terminate before everything is written on the USB stick, so I know I > can remove it. status=progress does not guarantee that data is on the USB stick before dd terminates. I have no idea why you would think it does. dd only turns on synchronization options, or adds synchronization syscalls, if you explicitly tell it to do so, and status=progress is not one of the options that does that. -- https://www.greenend.org.uk/rjk/
[toc] | [prev] | [next] | [standalone]
| From | Stéphane CARPENTIER <sc@fiat-linux.fr> |
|---|---|
| Date | 2026-09-05 09:08 +0000 |
| Message-ID | <6a9bdc2b$0$7092$426a74cc@news.free.fr> |
| In reply to | #90950 |
Le 31-08-2026, Richard Kettlewell <invalid@invalid.invalid> a écrit : > Stéphane CARPENTIER <sc@fiat-linux.fr> writes: >> >> I find it easier to put an option to be sure dd doesn't finish before >> everything is written on the USB stick than launching other commands >> after that. > > status=progress is not that option. Before using that option, I used no option, and when dd finished I had to "grep Dirty /proc/meminfo" to try to guess when I was able to remove my usb stick. Then one day I saw someone using that option. And now, I'm using it myself, so dd takes more time to finish and I never had any issue removing my usb stick once it finished. Maybe I'm the luckiest guy on earth, or there is a side effect which makes it work, one day it won't work as expected. But right now, having created dozens of usb sticks with that option, it never failed me. >> I didn't say there was only one way to do it. I said that putting the >> option status=progress makes sure that the dd command doesn't >> terminate before everything is written on the USB stick, so I know I >> can remove it. > > status=progress does not guarantee that data is on the USB stick before > dd terminates. I have no idea why you would think it does. Because it works. That helps believing in it. Before adding that option, dd finished well faster, with that option, it takes more time to finish and I never had any issue with usb sticks created in that way. So, that helps believing there is a relation between the option and the expected result. > dd only turns > on synchronization options, or adds synchronization syscalls, if you > explicitly tell it to do so, and status=progress is not one of the > options that does that. Maybe, but it's a really good imitation. -- Si vous avez du temps à perdre : https://scarpet42.gitlab.io
[toc] | [prev] | [next] | [standalone]
| From | Richard Kettlewell <invalid@invalid.invalid> |
|---|---|
| Date | 2026-09-05 10:25 +0100 |
| Message-ID | <wwva4pw2goz.fsf@LkoBDZeT.terraraq.uk> |
| In reply to | #91120 |
Stéphane CARPENTIER <sc@fiat-linux.fr> writes: > Richard Kettlewell <invalid@invalid.invalid> a écrit : >> Stéphane CARPENTIER <sc@fiat-linux.fr> writes: >>> I find it easier to put an option to be sure dd doesn't finish before >>> everything is written on the USB stick than launching other commands >>> after that. >> >> status=progress is not that option. > > Before using that option, I used no option, and when dd finished I had > to "grep Dirty /proc/meminfo" to try to guess when I was able to > remove my usb stick. Then one day I saw someone using that option. And > now, I'm using it myself, so dd takes more time to finish and I never > had any issue removing my usb stick once it finished. > > Maybe I'm the luckiest guy on earth, or there is a side effect which > makes it work, one day it won't work as expected. But right now, > having created dozens of usb sticks with that option, it never failed > me. There is no such side effect. Read the source or use strace. >>> I didn't say there was only one way to do it. I said that putting the >>> option status=progress makes sure that the dd command doesn't >>> terminate before everything is written on the USB stick, so I know I >>> can remove it. >> >> status=progress does not guarantee that data is on the USB stick before >> dd terminates. I have no idea why you would think it does. > > Because it works. That helps believing in it. Before adding that option, > dd finished well faster, with that option, it takes more time to finish > and I never had any issue with usb sticks created in that way. So, that > helps believing there is a relation between the option and the expected > result. People believe in all sorts of things, doesn’t make them true. -- https://www.greenend.org.uk/rjk/
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2026-09-05 19:19 +0100 |
| Message-ID | <117hmet$1nuga$5@dont-email.me> |
| In reply to | #91122 |
On 05/09/2026 10:25, Richard Kettlewell wrote: > People believe in all sorts of things, doesn’t make them true. It does in the New Left Mind, sadly -- Civilization exists by geological consent, subject to change without notice. – Will Durant
[toc] | [prev] | [next] | [standalone]
Page 6 of 30 — ← Prev page 1 … 4 5 [6] 7 8 … 30 Next page →
Back to top | Article view | comp.os.linux.misc
csiph-web