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 230 — 25 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 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 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 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 5 of 12 — ← Prev page 1 … 3 4 [5] 6 7 … 12 Next page →
| From | Leroy H <lh@somewhere.net> |
|---|---|
| Date | 2026-08-29 16:02 +0000 |
| Subject | Re: Overwriting with random data |
| Message-ID | <18d05221bff76e57$199370$821642$802601b3@news.usenetexpress.com> |
| In reply to | #90829 |
On 29 Aug 2026 14:17:45 GMT, Stéphane CARPENTIER wrote: > > Shakespeare didn't used words at random: you can > understand what he meant. A random generator wouldn't provide only > Shakespeare text, it would provide meaningless thing among which the > Shakespeare would appear. but you can understand everything Shakespeare > provided, so that wasn't random. > My associate on Planet X^X, with whom I communicate via universal thought patterns, would find the Shakespeare text to be meaningless gibberish. He (or it?) does not comprehend human language and thus the text would seem quite random (although it would not pass many rigorous tests of randomness). OTOH, I presented my associate on Planet X^X with a sequence of digits that passed many rigorous tests for randomness. But he (or it?) immediately recognized it as the real root of a certain math equation. It is well known that "almost all" real numbers are "normal," that is their digit sequences are essentially random. But my associate was able predict every digit in the sequence even though it qualified, through testing, as being quite random.
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E. R." <robin_listas@es.invalid> |
|---|---|
| Date | 2026-08-29 22:12 +0200 |
| Subject | Re: Overwriting with random data |
| Message-ID | <nfgspfF3giU6@mid.individual.net> |
| In reply to | #90831 |
On 2026-08-29 18:02, Leroy H wrote:
> On 29 Aug 2026 14:17:45 GMT, Stéphane CARPENTIER wrote:
>
>>
>> Shakespeare didn't used words at random: you can
>> understand what he meant. A random generator wouldn't provide only
>> Shakespeare text, it would provide meaningless thing among which the
>> Shakespeare would appear. but you can understand everything Shakespeare
>> provided, so that wasn't random.
>>
>
> My associate on Planet X^X, with whom I communicate via universal
> thought patterns, would find the Shakespeare text to be meaningless
> gibberish. He (or it?) does not comprehend human language and thus
> the text would seem quite random (although it would not pass many
> rigorous tests of randomness).
No, he would not.
--
Cheers,
Carlos E.R.
ES🇪🇸, EU🇪🇺.
[toc] | [prev] | [next] | [standalone]
| From | Leroy H <lh@somewhere.net> |
|---|---|
| Date | 2026-08-29 21:04 +0000 |
| Subject | Re: Overwriting with random data |
| Message-ID | <18d0629725493544$177297$916528$802601b3@news.usenetexpress.com> |
| In reply to | #90839 |
On Sat, 29 Aug 2026 22:12:31 +0200, Carlos E. R. wrote: > > No, he would not. > Would you, an intelligent human (i.e. Homo sapiens), consider the following 1000 char sequence of hexadecimal chars to be random: 3243f6a8885a308d313198a2e03707344a4093822299f31d0082efa98ec4e6c8 9452821e638d01377be5466cf34e90c6cc0ac29b7c97c50dd3f84d5b5b5470917 9216d5d98979fb1bd1310ba698dfb5ac2ffd72dbd01adfb7b8e1afed6a267e96b a7c9045f12c7f9924a19947b3916cf70801f2e2858efc16636920d871574e69a4 58fea3f4933d7e0d95748f728eb658718bcd5882154aee7b54a41dc25a59b59c3 0d5392af26013c5d1b023286085f0ca417918b8db38ef8e79dcb0603a180e6c9e 0e8bb01e8a3ed71577c1bd314b2778af2fda55605c60e65525f3aa55ab9457489 86263e8144055ca396a2aab10b6b4cc5c341141e8cea15486af7c72e993b3ee14 11636fbc2a2ba9c55d741831f6ce5c3e169b87931eafd6ba336c24cf5c7a32538 1289586773b8f48986b4bb9afc4bfe81b6628219361d809ccfb21a991487cac60 5dec8032ef845d5de98575b1dc262302eb651b8823893e81d396acc50f6d6ff38 3f442392e0b4482a484200469c8f04a9e1f9b5e21c66842f6e96c9a670c9c61ab d388f06a51a0d2d8542f68960fa728ab5133a36eef0b6c137a3be4ba3bf0507ef b2a98a1f1651d39af017666ca593e82430e888cee8619456f9fb47d84a5c33b8b 5ebee06f75d885c12073401a449f56c16aa64ed3aa62363f77061bfedf72429b0 23d37d0d724d00a1248db0fea 1000 chars may not be sufficient for meaningful tests but I have to make the cut-off at a reasonable level for this post. It may appear random and it may test random but these are actually the first 1000 hexadecimal digits of Pi. Thus, it is a completely deterministic sequence. My associate from Planet X^X can easily discern this. For him (or it?) it would be Shakespeare.
[toc] | [prev] | [next] | [standalone]
| From | Rich <rich@example.invalid> |
|---|---|
| Date | 2026-08-28 00:58 +0000 |
| Subject | Re: Overwriting with random data |
| Message-ID | <116qmge$1u4ip$4@dont-email.me> |
| In reply to | #90602 |
c186282 <c186282@nnada.net> wrote: > On 8/25/26 10:19, Richard Kettlewell wrote: >> "Carlos E.R." <robin_listas@es.invalid> writes: >>> The kernel provides two sources: one that waits if there is not >>> enough random data, and the other that doesn't wait and provides >>> what it can. >> >> /dev/random and /dev/urandom are functionally equivalent today; >> disregarding some details about system startup which don’t apply to >> most use caes, neither will block. >> >>> I call the former "true random". More true random I consider >>> unobtainium and go without. >> >> “True random” means something different, you need to change your >> terminology. > > Yep. "Random" is still kind of unobtanium. Nope. Only if you limit yourself to trying to program a deterministic computer program to create the randomness. > Though only the top-level crypto people worry about it very much. > > "Damned-near Random" can be had quite easily. > > TRUE 'random' ... not even sure quantum trix can deliver that. > Quantum is statistical, which narrows-down potential options. > People with a lot of CPU might take advantage. You can get a true random generator yourself for a relatively small amount of cash. Most are based on counting radioactive decay of some isotope of some element (I am not bothering to look up which one). It seems there's even a Hackaday project about building your own DIY version: https://hackaday.io/project/4628-nuclear-random-number-generator It's not hard, nor difficult, it's just very unnecessary for 99.999% of folks who are doing anything that wants a random number input.
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2026-08-28 12:23 +0100 |
| Subject | Re: Overwriting with random data |
| Message-ID | <116rr2l$28guo$9@dont-email.me> |
| In reply to | #90706 |
On 28/08/2026 01:58, Rich wrote: > You can get a true random generator yourself for a relatively small > amount of cash. Most are based on counting radioactive decay of some > isotope of some element (I am not bothering to look up which one). > Its a lot easier to get a true flat noise generator like a resistor or a Zener diode, that generates noise up into the gigahertz band, amplify it and apply it to a fast comparator. Simply read off a sequence of bits from the comparator. > It seems there's even a Hackaday project about building your own DIY > version: > > https://hackaday.io/project/4628-nuclear-random-number-generator > > It's not hard, nor difficult, it's just very unnecessary for 99.999% of > folks who are doing anything that wants a random number input. Exactly. -- Socialism is the philosophy of failure, the creed of ignorance and the gospel of envy. Its inherent virtue is the equal sharing of misery. Winston Churchill
[toc] | [prev] | [next] | [standalone]
| From | Rich <rich@example.invalid> |
|---|---|
| Date | 2026-08-28 00:53 +0000 |
| Subject | Re: Overwriting with random data |
| Message-ID | <116qm5p$1u4ip$3@dont-email.me> |
| In reply to | #90506 |
Carlos E.R. <robin_listas@es.invalid> wrote: > On 2026-08-25 08:39, c186282 wrote: >> On 8/24/26 16:26, Carlos E.R. wrote: >>> On 2026-08-24 21:57, Richard Kettlewell wrote: >>>> "Carlos E.R." <robin_listas@es.invalid> writes: >>>>> Using true random data is slow, specially if the disk or partition is >>>>> very big. Depends on how fast can the machine create new random data >>>>> (see man random and urandom). So I do tricks to do it faster. >>>> >>>> With very few exceptions nobody uses true random[1] data directly. >>>> /dev/random is a DRBG seeded from the random sources the kernel finds; >>>> shred sees its internal RNG with 32 bytes from the kernel (strace >>>> it...); I don’t know where you’re getting random data from but the >>>> chances that it’s direct from a TRNG are negligible. >>> >>> Normally >>> >>> dd if=/dev/urandom of=$BIGRANDOM count=1024 bs=1M >>> >>> or in pascal >>> >>> var >>> randomsource : file of byte; >>> x: Integer; >>> begin >>> try >>> assign(randomsource, '/dev/urandom'); >>> reset(randomsource); >>> for x:= 1 to shuflecount do >>> read(randomsource, BigData[Index, x]); >>> finally >>> close(randomsource); >>> end; >>> end; >> >> MIGHT not be as "random" as you hope. This has >> LONG been a problem. > > Sure. > > Right now I have the doubt if I should have used /dev/random instead (I > never remember which is which). But it is not that important. They are both driven by the same generator underneath. The big difference used to be that /dev/random would block when its "entropy estimate" dropped below some arbitrary threshold. With newer kernels that only happens at first bootup. After that, they are both the same now. >> Rather than rely on some canned function, DO add some shit from >> very transient machine-related vars as well. Video vars, CPU >> temps, that kind of shit. STILL not really truly "random" - but >> a lot closer. >> >> If you want TRUE "random", I suspect some kind of little >> quantum device will be needed. > > it is true random in the sense that the kernel provides it as random. > That is enough. > > The kernel provides two sources: one that waits if there is not enough > random data, and the other that doesn't wait and provides what it can. I > call the former "true random". More true random I consider unobtainium > and go without. Both retreive their output from the exact same generator inside the kernel. Neither is more random than the other, they are one and the same. The only difference was the blocking action, and that was always based on a misunderstanding early on, which is why it eventually was dropped from the driver in later kernels.
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2026-08-25 12:12 +0100 |
| Subject | Re: Overwriting with random data |
| Message-ID | <116jta2$3l7js$9@dont-email.me> |
| In reply to | #90495 |
On 25/08/2026 07:39, c186282 wrote: > If you want TRUE "random", I suspect some kind of > little quantum device will be needed. Run a Zener diodes amplified output through an A to D converter. That's quantum... -- “it should be clear by now to everyone that activist environmentalism (or environmental activism) is becoming a general ideology about humans, about their freedom, about the relationship between the individual and the state, and about the manipulation of people under the guise of a 'noble' idea. It is not an honest pursuit of 'sustainable development,' a matter of elementary environmental protection, or a search for rational mechanisms designed to achieve a healthy environment. Yet things do occur that make you shake your head and remind yourself that you live neither in Joseph Stalin’s Communist era, nor in the Orwellian utopia of 1984.” Vaclav Klaus
[toc] | [prev] | [next] | [standalone]
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2026-08-26 00:09 -0400 |
| Subject | Re: Overwriting with random data |
| Message-ID | <ZfqcnXZt_dTR-hP3nZ2dnZfqnPWdnZ2d@giganews.com> |
| In reply to | #90519 |
On 8/25/26 07:12, The Natural Philosopher wrote: > On 25/08/2026 07:39, c186282 wrote: >> If you want TRUE "random", I suspect some kind of >> little quantum device will be needed. > > Run a Zener diodes amplified output through an A to D converter. > That's quantum... Pretty much, theoretically. Tunnel diodes might be exploited in a similar fashion. Anything where 'quantum noise' gets involved. Anyway, STILL hear paranoia from the "Top People" about pseudo-random numbers for hard core crypto. For most of us it's not really a thing, but at the very high/secret levels ... stuff evil players will invest millions/billions into cracking .... Oh, even quantum obeys some statistical rules, on a larger scale states/events ARE kinda constrained. IF you can put enough CPU/AI on the case it could narrow down the best attacks on crypto systems.
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2026-08-26 08:52 +0100 |
| Subject | Re: Overwriting with random data |
| Message-ID | <116m60p$e9qm$2@dont-email.me> |
| In reply to | #90587 |
On 26/08/2026 05:09, c186282 wrote: > On 8/25/26 07:12, The Natural Philosopher wrote: >> On 25/08/2026 07:39, c186282 wrote: >>> If you want TRUE "random", I suspect some kind of >>> little quantum device will be needed. >> >> Run a Zener diodes amplified output through an A to D converter. >> That's quantum... > > Pretty much, theoretically. Tunnel diodes might > be exploited in a similar fashion. Anything where > 'quantum noise' gets involved. > TBH any noise source - even thermal noise - can be used -- “It is hard to imagine a more stupid decision or more dangerous way of making decisions than by putting those decisions in the hands of people who pay no price for being wrong.” Thomas Sowell
[toc] | [prev] | [next] | [standalone]
| From | Rich <rich@example.invalid> |
|---|---|
| Date | 2026-08-28 01:02 +0000 |
| Subject | Re: Overwriting with random data |
| Message-ID | <116qmn5$1u4ip$6@dont-email.me> |
| In reply to | #90606 |
The Natural Philosopher <tnp@invalid.invalid> wrote: > On 26/08/2026 05:09, c186282 wrote: >> On 8/25/26 07:12, The Natural Philosopher wrote: >>> On 25/08/2026 07:39, c186282 wrote: >>>> If you want TRUE "random", I suspect some kind of >>>> little quantum device will be needed. >>> >>> Run a Zener diodes amplified output through an A to D converter. >>> That's quantum... >> >> Pretty much, theoretically. Tunnel diodes might >> be exploited in a similar fashion. Anything where >> 'quantum noise' gets involved. >> > > TBH any noise source - even thermal noise - can be used Yup. I even saw once someone using an input on a sound card as the noise source for a random number generater. I no longer have the link to it however. But speed-of-light guy won't depart from his incorrect preconcieved notion, no matter how much evidence we present to the contrary.
[toc] | [prev] | [next] | [standalone]
| From | Rich <rich@example.invalid> |
|---|---|
| Date | 2026-08-28 00:48 +0000 |
| Subject | Re: Overwriting with random data |
| Message-ID | <116qlsf$1u4ip$1@dont-email.me> |
| In reply to | #90495 |
c186282 <c186282@nnada.net> wrote: > On 8/24/26 16:26, Carlos E.R. wrote: >> On 2026-08-24 21:57, Richard Kettlewell wrote: >>> "Carlos E.R." <robin_listas@es.invalid> writes: >>>> Using true random data is slow, specially if the disk or partition is >>>> very big. Depends on how fast can the machine create new random data >>>> (see man random and urandom). So I do tricks to do it faster. >>> >>> With very few exceptions nobody uses true random[1] data directly. >>> /dev/random is a DRBG seeded from the random sources the kernel finds; >>> shred sees its internal RNG with 32 bytes from the kernel (strace >>> it...); I don’t know where you’re getting random data from but the >>> chances that it’s direct from a TRNG are negligible. >> >> Normally >> >> dd if=/dev/urandom of=$BIGRANDOM count=1024 bs=1M >> >> or in pascal >> >> var >> randomsource : file of byte; >> x: Integer; >> begin >> try >> assign(randomsource, '/dev/urandom'); >> reset(randomsource); >> for x:= 1 to shuflecount do >> read(randomsource, BigData[Index, x]); >> finally >> close(randomsource); >> end; >> end; > > MIGHT not be as "random" as you hope. This has > LONG been a problem. /dev/urandom is going to be by far more random than anything you yourself will cook up thinking you've created random data. > Rather than rely on some canned function, DO add some shit from > very transient machine-related vars as well. Video vars, CPU > temps, that kind of shit. STILL not really truly "random" - but a > lot closer. That's exactly how /dev/urandom randomizes itself, so you get that, already done for you, by using /dev/urandom's output. > If you want TRUE "random", I suspect some kind of little quantum > device will be needed. Yes, you need a hardware element for true random, and often they produce randomness slowly, so you won't be reading from your hardware random generator to overwrite a disk with random data anyway.
[toc] | [prev] | [next] | [standalone]
| 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]
Page 5 of 12 — ← Prev page 1 … 3 4 [5] 6 7 … 12 Next page →
Back to top | Article view | comp.os.linux.misc
csiph-web