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-24 19:08 +0100 |
| Articles | 20 on this page of 137 — 18 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 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 "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 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: /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 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-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: 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) 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 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-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 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
Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2026-08-23 03:37 -0400 |
| Message-ID | <5b2dnb6l8sPvPhf3nZ2dnZfqnPGdnZ2d@giganews.com> |
| In reply to | #90370 |
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.
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2026-08-23 13:50 +0200 |
| Message-ID | <6d3rlmxqg4.ln2@Telcontar.valinor> |
| In reply to | #90376 |
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.
--
Cheers, Carlos.
ES🇪🇸, EU🇪🇺;
[toc] | [prev] | [next] | [standalone]
| From | vallor <vallor@vallor.earth> |
|---|---|
| Date | 2026-08-23 22:28 +0000 |
| Message-ID | <116fs5p$28rhg$2@dont-email.me> |
| In reply to | #90387 |
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.
--
-v System76 Thelio Mega v1.1 x86_64 Mem: 258G
OS: Linux 7.2.0 D: Mint 22.3 DE: Xfce 4.18 (X11)
NVIDIA GeForce RTX 3090Ti (24G) (610.57.04)
"Diplomacy is saying "nice doggy" until you find a rock."
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2026-08-24 09:35 +0200 |
| Message-ID | <6r8tlmxeb9.ln2@Telcontar.valinor> |
| In reply to | #90414 |
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.
--
Cheers, Carlos.
ES🇪🇸, EU🇪🇺;
[toc] | [prev] | [next] | [standalone]
| From | Nuno Silva <nunojsilva@invalid.invalid> |
|---|---|
| Date | 2026-08-24 11:10 +0100 |
| Subject | Overwriting with random data (was: Re: /dev/tcp) |
| Message-ID | <116h5be$2nco1$1@dont-email.me> |
| In reply to | #90443 |
On 2026-08-24, 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:
>
[snipping a lot to keep this shorter, apologies if I ended up snipping
too much]
>
>>> 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.
IIRC shred can do the same, and on block devices too, what's the
difference here? block sizes?
--
Nuno Silva
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2026-08-24 20:34 +0200 |
| Subject | Re: Overwriting with random data |
| Message-ID | <vefulmxca.ln2@Telcontar.valinor> |
| In reply to | #90446 |
On 2026-08-24 12:10, Nuno Silva wrote:
> On 2026-08-24, 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:
>>
> [snipping a lot to keep this shorter, apologies if I ended up snipping
> too much]
>>
>>>> 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.
>
> IIRC shred can do the same, and on block devices too, what's the
> difference here? block sizes?
I mentioned my code because it accesses huge devices in pascal, way
beyond 4G.
c186282 said:
Note Lazarus/FPC *says* it supports huge seek numbers
but DOESN'T ... limited to maybe 4gb.
Some functions work, others don't. This does not work:
const
rawdest: string = ''; // example: '/dev/sda11'
ChunkSz=1048576;
type
tCacho= array [1..ChunkSz] of byte;
var
Fin, Fout: file of tCacho;
begin
rawdest:= ParamStr(1);
writeln('Apparent size of ', rawdest, ' is ', filesize(Fout));
It writes '0' (I am currently erasing an 8TB disk)
Notice that I am not using a file of bytes, but a file of 1 MiB arrays.
And I am not using seek, but writing contiguously.
Now the shred part.
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. And shred
does it several times.
The algorithm I use is:
Fill a 1 GiB file with true random data.
Read that file into ram.
repeat
take 1 MiB of that and write it into the destination device
advance
Every 100 advances, replace 1 MiB of the array of random bytes
with new random data
until end of device
So, the data is truly random, but used repeatedly (and slowly renovated).
--
Cheers, Carlos.
ES🇪🇸, EU🇪🇺;
[toc] | [prev] | [next] | [standalone]
| From | Richard Kettlewell <invalid@invalid.invalid> |
|---|---|
| Date | 2026-08-24 20:57 +0100 |
| Subject | Re: Overwriting with random data |
| Message-ID | <wwvfr03z3ye.fsf@LkoBDZeT.terraraq.uk> |
| In reply to | #90457 |
"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.
[1] in the sense described by
e.g. https://link.springer.com/content/pdf/10.1007/978-3-540-85053-3_10.pdf
--
https://www.greenend.org.uk/rjk/
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2026-08-24 22:26 +0200 |
| Subject | Re: Overwriting with random data |
| Message-ID | <71mulmxumi.ln2@Telcontar.valinor> |
| In reply to | #90463 |
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;
>
> [1] in the sense described by
> e.g. https://link.springer.com/content/pdf/10.1007/978-3-540-85053-3_10.pdf
>
--
Cheers, Carlos.
ES🇪🇸, EU🇪🇺;
[toc] | [prev] | [next] | [standalone]
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2026-08-25 02:39 -0400 |
| Subject | Re: Overwriting with random data |
| Message-ID | <4R-dndpP7cWGpBD3nZ2dnZfqn_adnZ2d@giganews.com> |
| In reply to | #90465 |
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. 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. >> >> [1] in the sense described by >> e.g. https://link.springer.com/content/ >> pdf/10.1007/978-3-540-85053-3_10.pdf >>
[toc] | [prev] | [next] | [standalone]
| From | Richard Kettlewell <invalid@invalid.invalid> |
|---|---|
| Date | 2026-08-25 08:45 +0100 |
| Subject | Re: Overwriting with random data |
| Message-ID | <wwvqzjmk5j7.fsf@LkoBDZeT.terraraq.uk> |
| In reply to | #90495 |
c186282 <c186282@nnada.net> writes: > 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. Nonsense. It’s at least as random as Carlos or I hope. Read some documentation for once. -- https://www.greenend.org.uk/rjk/
[toc] | [prev] | [next] | [standalone]
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2026-08-25 21:39 -0400 |
| Subject | Re: Overwriting with random data |
| Message-ID | <ZfqcnXlt_dS92RP3nZ2dnZfqnPWdnZ2d@giganews.com> |
| In reply to | #90500 |
On 8/25/26 03:45, Richard Kettlewell wrote: > c186282 <c186282@nnada.net> writes: >> 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. > > Nonsense. It’s at least as random as Carlos or I hope. Read some > documentation for once. All the docs I've ever read FRET about how 'random' number generators aren't QUITE random enough for everyone to feel good. Now for the 99.999% of us it really isn't going to be a problem. However for top national security entities ......
[toc] | [prev] | [next] | [standalone]
| From | Charlie Gibbs <cgibbs@kltpzyxm.invalid> |
|---|---|
| Date | 2026-08-26 18:08 +0000 |
| Subject | Re: Overwriting with random data |
| Message-ID | <UYFjS.152$oQ_6.80@fx11.iad> |
| In reply to | #90577 |
On 2026-08-26, c186282 <c186282@nnada.net> wrote:
> All the docs I've ever read FRET about how 'random'
> number generators aren't QUITE random enough for
> everyone to feel good.
>
> Now for the 99.999% of us it really isn't going to
> be a problem. However for top national security
> entities ......
The generation of random numbers
is too important to be left to chance.
-- Robert R. Coveyou
--
/~\ Charlie Gibbs | In this world there are
\ / <cgibbs@kltpzyxm.invalid> | two kinds of people:
X I'm really at ac.dekanfrus | 1. Those who can extrapolate
/ \ if you read it the right way. | from incomplete data.
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2026-08-25 11:36 +0200 |
| Subject | Re: Overwriting with random data |
| Message-ID | <4a40mmx4l5.ln2@Telcontar.valinor> |
| In reply to | #90495 |
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. > > 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. > >>> >>> [1] in the sense described by >>> e.g. https://link.springer.com/content/ >>> pdf/10.1007/978-3-540-85053-3_10.pdf >>> > -- Cheers, Carlos. ES🇪🇸, EU🇪🇺;
[toc] | [prev] | [next] | [standalone]
| From | Richard Kettlewell <invalid@invalid.invalid> |
|---|---|
| Date | 2026-08-25 15:19 +0100 |
| Subject | Re: Overwriting with random data |
| Message-ID | <wwvtsoimgeo.fsf@LkoBDZeT.terraraq.uk> |
| In reply to | #90506 |
"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. -- https://www.greenend.org.uk/rjk/
[toc] | [prev] | [next] | [standalone]
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2026-08-26 03:33 -0400 |
| Subject | Re: Overwriting with random data |
| Message-ID | <shWdncVO7NhkCxP3nZ2dnZfqnPoAAAAA@giganews.com> |
| In reply to | #90538 |
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. 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. The universe doesn't seem to like TRUE "random".
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2026-08-26 09:18 +0100 |
| Subject | Re: Overwriting with random data |
| Message-ID | <116m7h8$e9qm$6@dont-email.me> |
| In reply to | #90602 |
On 26/08/2026 08:33, c186282 wrote: > > 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. > > The universe doesn't seem to like TRUE "random". > Thermal and shot noise are true random, and are used to generate random numbers -- All political activity makes complete sense once the proposition that all government is basically a self-legalising protection racket, is fully understood.
[toc] | [prev] | [next] | [standalone]
| From | rbowman <bowman@montana.com> |
|---|---|
| Date | 2026-08-26 17:34 +0000 |
| Subject | Re: Overwriting with random data |
| Message-ID | <nf8mdtFprcuU4@mid.individual.net> |
| In reply to | #90614 |
On Wed, 26 Aug 2026 09:18:48 +0100, The Natural Philosopher wrote: > Thermal and shot noise are true random, and are used to generate random > numbers https://hackaday.io/project/21054-true-random-number-generator
[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]
Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
Back to top | Article view | comp.os.linux.misc
csiph-web