I am writing a "per file" backup program in gambas (btw, If
sb is intrested into, I can send him/her the sourcecode,
which has one issue I must fix *)
Now, it took more or less 24 hours backupping
compressed 526282 regular files : 613,5 GB (614,9 GB on disk)
original (most of large ones just compressed and left as
such) 699,8 GB (701,1 GB on disk)

now I have added the feature to COMPRESS most, but COPY the
pre-compressed ones as such, basing on a list (user
modifiable) of popular compressed extentions :
.7z .7Z .Z .zip .rar .arj .gz .bz2 .xz .lzma .lzh .arj .bz
which is far from complete ... apropos : any hint here is
WELCOME !
The very poor compression ratio (slightly less than 88 % in
size), is surely in part due to the fact that a lot of
stuff, expecially LARGE files, were just compressed before
the backup.
But inquiring with k4DirStat and QDirStat looking for large
stuff in the backup, I have noticed a lot of MULTIMEDIA
files, that have been sillily compressed, were the same size.
It was a mistake not to have considered that many multimedia
stuff is just a lot optimized (often in a lossy way) that
makes stupid to try to squeeze further (the backup was
annoyingly SLOW, since I have selected the .BZIP2 algorithm,
with MAXIMUM compression option, which theoretically gives
the best results at the expence of execution time ... but
this best with a lot of video / audio files is really
negligible).
So, in your opinion, which multimedia files, by extention
(the program is not smart as to look into files trying to
guess entropy, it considers just the extention alone),
deserves compression and which would be a lot faster to
store as such ?

ig . .BMP, .WAV, .AVI seems fit for compression
.MP3, .MP4, .MKV, .WEBM and a lot more I cannot recall,
seems very well pre.compressed.
For future use I'd like to add this extentions to the
Copy-As-Such list.
I need some advices, the media extentions are really
numerous, and I don't know which are the most frequent. I
don't have a program that scans the disk and produces a
count for each extention.
Adding a file type mentioned just a couple of times, would
change nothing. But if mentioned some hundredth times would !
Tnx for any advice to my "skip list"
***
I still am unable to REFRESH (little confidence with the
events loop, tried to use WAIT statement with unexpected
outcome, and then removed it and left only REFRESH, which
delays indefinitely until the end of the duty cycle :\)
I followed the course in the debugger, but this is very
annoying for sb who wants to run a sw in normal mode, in
that case having the interface frozen for a day (that seems
stuck and broken, but internally really traps / catches
every kind of errors and LOGS them to a file, to manually
check the backup problem, it was written with reliability in
mind, not speed). But it is annoying to see no progress bar
move, and at completion they jump to 100% :\ I'll maybe try
to use a timer object to force refresh every X seconds.

--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
MarioCPPP

On 6/9/2023 6:20 AM, MarioCPPP wrote:
>
> I am writing a "per file" backup program in gambas (btw, If sb is intrested into, I can send him/her the sourcecode, which has one issue I must fix *)
>
> Now, it took more or less 24 hours backupping
>
> compressed  526282  regular files : 613,5 GB (614,9 GB on disk)
> original (most of large ones just compressed and left as such) 699,8 GB (701,1 GB on disk)
>
>
> now I have added the feature to COMPRESS most, but COPY the pre-compressed ones as such, basing on a list (user modifiable) of popular compressed extentions :
> .7z .7Z .Z .zip .rar .arj .gz .bz2 .xz .lzma .lzh .arj .bz
> which is far from complete ... apropos : any hint here is WELCOME !
>
> The very poor compression ratio (slightly less than 88 % in size), is surely in part due to the fact that a lot of stuff, expecially LARGE files, were just compressed before the backup.
>
> But inquiring with k4DirStat and QDirStat looking for large stuff in the backup, I have noticed a lot of MULTIMEDIA files, that have been sillily compressed, were the same size.
>
> It was a mistake not to have considered that many multimedia stuff is just a lot optimized (often in a lossy way) that makes stupid to try to squeeze further (the backup was annoyingly SLOW, since I have selected the .BZIP2 algorithm, with MAXIMUM compression option, which theoretically gives the best results at the expence of execution time ... but this best with a lot of video / audio files is really negligible).
>
> So, in your opinion, which multimedia files, by extention (the program is not smart as to look into files trying to guess entropy, it considers just the extention alone), deserves compression and which would be a lot faster to store as such ?
>
>
> ig . .BMP, .WAV, .AVI  seems fit for compression
> .MP3, .MP4, .MKV, .WEBM and a lot more I cannot recall, seems very well pre.compressed.
>
> For future use I'd like to add this extentions to the Copy-As-Such list.
>
> I need some advices, the media extentions are really numerous, and I don't know which are the most frequent. I don't have a program that scans the disk and produces a count for each extention.
> Adding a file type mentioned just a couple of times, would change nothing. But if mentioned some hundredth times would !
>
> Tnx for any advice to my "skip list"
>
> ***
>
> I still am unable to REFRESH (little confidence with the events loop, tried to use WAIT statement with unexpected outcome, and then removed it and left only REFRESH, which delays indefinitely until the end of the duty cycle :\)
>
> I followed the course in the debugger, but this is very annoying for sb who wants to run a sw in normal mode, in that case having the interface frozen for a day (that seems stuck and broken, but internally really traps / catches every kind of errors and LOGS them to a file, to manually check the backup problem, it was written with reliability in mind, not speed). But it is annoying to see no progress bar move, and at completion they jump to 100% :\ I'll maybe try to use a timer object to force refresh every X seconds.
>

If you have individually compressed a large file set from your sample
disk, then you likely have all the data you need. You could compare
the filelist of the original files, versus the filelist of the individually
compressed files. And then noticed the pattern of the ones that do not
compress well.

In the following example, DO NOT run this on large files, if you can help
it. This is just a way to determine how much compression can be achieved,
without using a compressor as such.

$ sudo apt install ent

$ ent sample.mp4

Entropy = 7.998724 bits per byte. <=== almost incompressible, like /dev/random below

Optimum compression would reduce the size
of this 23730017 byte file by 0 percent.

$ dd if=/dev/zero of=zero.bin bs=1024 count=1024
$ ent zero.bin

Entropy = 0.000000 bits per byte. <=== very very compressible, much redundancy

Optimum compression would reduce the size
of this 1048576 byte file by 100 percent. <=== there is always a little overhead...

$ dd if=/dev/random of=devrandom.bin bs=1024 count=1024
$ ent devrandom.bin

Entropy = 7.999825 bits per byte. <=== crypto-quality source

Optimum compression would reduce the size
of this 1048576 byte file by 0 percent.

$ dd if=/dev/urandom of=devurandom.bin bs=1024 count=1024
$ ent devurandom.bin

Entropy = 7.999793 bits per byte. <=== not a crypto-quality source, tiny diff in entropy

Optimum compression would reduce the size
of this 1048576 byte file by 0 percent.

Also note, that of the various compression algorithms, some "speed up"
when they hit really low entropy materials. Arithmetic compressors don't
speed up quite like that. BZ2 is likely an excellent compressor, but on
the other hand, if you compress a file of zeros with it, it takes more
time for BZ2 to do that, than for gzip to do the same file.

Backup programs, commercial ones, tend to use "lightweight" compressors.
It is the opinion, of the developer, that a short backup time, is more
important than absolutely smallest output. I don't agree with this
particularly, because disk drives cost money. The degree of compression used,
the lightness, is intended to approximately match the write speed of the
destination disk drive. So if the average backup drive does 100MB/sec ,
then the compression method selected is intended to create that level
of output (100MB/sec) during a backup. They do not want the compressor
to be the rate limiting step.

It is inevitable, that if you select high compression from an arithmetic
compressor, it will never match the I/O rates of the storage devices.
It will behave like a pig. Customers will be unimpressed.

*******

By using multi-core compression (all the CPU cores busy on the
compression), you can improve the performance. An arithmetic compressor
can be memory-bandwidth-bound, which is why you would hope a 5800X3D
(with extra cache) would run faster than a vanilla 5800 CPU. Now, one
reason that does not happen, is the L3 on such a chip, is only a bit
faster than main memory. The larger a cache becomes, generally there
is an access speed penalty on that. Some caches are also "segmented"
and the "distance" from the core to the cache, the routing, slows it down.
This is why the large cache on an Epyc or a Milan, isn't as effective
as you might like.

As an example of a multi-core one, you could experiment with "pigz".
I do not know how well it scales, and exactly how many cores it can use,
but it's an example of a multi-core on compression program. On decompression,
it is still a single thread of execution, last time I checked.

https://linux.die.net/man/1/pigz

But if you were hoping to "set the world on fire" with your programming
skills in this topic, others have been there and "got their Tshirt" :-)
You are not going to beat any other developer at this game, on your
first try.

Summary: If you consider disk drives expensive, than BZ2 is the answer.
If you consider disk drives cheap, you can try pigz instead.
And yes, if you want, you can avoid compressing the .mp4 file.
Good idea. PDF files can be compressed a bit, but not much.

Make sure the CPU has a good cooler, for jobs like this, as the
CPU is going to get warm. To compress all the data on a decent
sized hard drive, costs about $1 in electricity. Released as heat.

Paul

On 2023-06-09, MarioCPPP wrote:
> [...]
> So, in your opinion, which multimedia files, by extention
> (the program is not smart as to look into files trying to
> guess entropy, it considers just the extention alone),
> deserves compression and which would be a lot faster to
> store as such ?

All of them. They're already compressed. It's probably easier talking
about what is viable for compression --> text documents (*odf, *txt,
sourcecode, etc.)

--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860

On 09/06/23 12:20, MarioCPPP wrote:
>
CUT

here is an "in fieri" updated list of recent searches

..fsa .squashfs .squash .lzw .lz77
..ppm .mp3 .aac .ogg .ogx .vorbis .gif .png .jpeg .jpg .heif
..mpeg .mpg .mp4 .m4v .hevc
..webm .mkv .mk3d .avi .wmv .asf .DivX .mkv .mov .qt .FLV
..F4V .SWF
..m2p .ps .ts .tsv .m2ts .mts .vob .evo .3gp
..jr .jz ?? jahr archives ?
..apk .msi .deb

also, the APT packages, are .deb or some other intermediate
format that is cached ?

(I mentioned also some tipically windows format .MSI since
here and there some installers lingers in backups)

pls share your experience with other rarer formats (also for
media), and if you know some media (video, audio, images)
for sure to be NOT compressed ...

>
>

--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
MarioCPPP

On 09/06/23 13:45, Paul wrote:
> On 6/9/2023 6:20 AM, MarioCPPP wrote:
>>
CUT my question
>>
>
> If you have individually compressed a large file set from
> your sample
> disk, then you likely have all the data you need. You could
> compare
> the filelist of the original files, versus the filelist of
> the individually
no need, ALL of the problems are logged. I found some 14
amputated symlinks (maybe due to the fact that in "DIR" cmd
i stated FOLLOW SYMLINKS = FALSE, in order not to spread the
scan to other disks) and just 1 single file whose name part
was just exactly 255 bytes long, and that produced error
trying to add a further .bz2 (four chars).
There seem to be no limit as to the whole PATH size, but 255
chars in every single piece of the path (filename included)

> compressed files. And then noticed the pattern of the ones
> that do not
> compress well.
yes, but I am just "sampling", since I cannot examine each
of a 500 K files and above.
>
> In the following example, DO NOT run this on large files, if
> you can help
> it. This is just a way to determine how much compression can
> be achieved,
> without using a compressor as such.
>
>  $ sudo apt install ent
>
>  $ ent sample.mp4
>
>    Entropy = 7.998724 bits per byte.    <=== almost
> incompressible, like /dev/random below
>
>    Optimum compression would reduce the size
>    of this 23730017 byte file by 0 percent.
>
>  $ dd if=/dev/zero of=zero.bin bs=1024 count=1024
>  $ ent zero.bin
>
>    Entropy = 0.000000 bits per byte.          <=== very
> very compressible, much redundancy

very intresting indeed !
but I am really at a loss in esteemating how much time (a
sunk cost) I spend in advance for calculating entropy
compared with the time I spare not compressing the high entropy.


>
>    Optimum compression would reduce the size
>    of this 1048576 byte file by 100 percent.  <=== there is
> always a little overhead...
>
>  $ dd if=/dev/random of=devrandom.bin bs=1024 count=1024
>  $ ent devrandom.bin
>
>    Entropy = 7.999825 bits per byte.     <===
> crypto-quality source
>
>    Optimum compression would reduce the size
>    of this 1048576 byte file by 0 percent.
>
>  $ dd if=/dev/urandom of=devurandom.bin bs=1024 count=1024
>  $ ent devurandom.bin
>
>    Entropy = 7.999793 bits per byte.     <=== not a
> crypto-quality source, tiny diff in entropy
>
>    Optimum compression would reduce the size
>    of this 1048576 byte file by 0 percent.
>
> Also note, that of the various compression algorithms, some
> "speed up"
> when they hit really low entropy materials. Arithmetic
> compressors don't
> speed up quite like that. BZ2 is likely an excellent
> compressor, but on
> the other hand, if you compress a file of zeros with it, it
> takes more
> time for BZ2 to do that, than for gzip to do the same file.
well, no algo. is perfect, but I don't know well every
detail to try to chose a different algo. for each kind of file
>
> Backup programs, commercial ones, tend to use "lightweight"
> compressors.
this is by far not commercial, just for my use.
the highest care was in the LOG feature, that helps outcome
analysis. The log contains "formats" that help the location
of different errors using RegEx

> It is the opinion, of the developer, that a short backup
> time, is more
> important than absolutely smallest output. I don't agree
> with this
> particularly, because disk drives cost money.
sure ! I think this too. Also, a larger set of backups can
be stored if more compressed.
I am thinking of using two kind of backups
One on a "per-folder" basis (like AWIT DBACKUP does), for
longer storage and more sporadic use, which surely achieves
better ratios, expecially with a lot o small files, and one
on a "per-file" basis, worse performing on compression (the
overhead is duplicated for each small file ... luckily
enough in each cluster some waste space in the original file
could accomodate this overhead, from time to time, I mean,
the coarse granularity of allocation space tend to damp this
problem), but Which is more usable in finding single items
and RETAINS file names, which is useful for SEARCHES in the
FS, while the filenames are not exposed in the per-folder
backup from awit dbackup (so just the structure is exposed,
but is not searchable).
This way (single files) is the most resilient : any i/o
error can affect just one file.
Maybe the worst drawback is the heavy disk structure,
containing millions of files. Disks so burdened with
filenames are slow to scan and analize by tools. There is no
free meal :\

What I will no longer be doing is : compress on a per-disk
basis. It not only produce huge files (which might be not so
resilient to error recovery), but these images are horribly
slow to "mount" in the compressor, and also to be checked at
the end.
for instance, per-disk compressors (like .FSA from
FileSystemArchiver and images from DAR) are really good in
the compression. I forgot to add .fsa to the exclusion list,
and one backup was compressed. Here the result :
original actual disk size (.fsa) : 29529489408 byte
compressed size (.bz2) : 28779950080 byte
ratio = 97,4617260812 %
just 2,6 % of gain, simply ridiculous !
It might have taken an hour or so, I guess (the log does not
contain times ... I am considering to produce a second log
for stats, which would be a text file not very amenable to
editors, due to its size).

> The degree of
> compression used,
> the lightness, is intended to approximately match the write
> speed of the
> destination disk drive. So if the average backup drive does
> 100MB/sec ,
I have a new 8 TB external (USB 3.1) disk, which does NOT
reach that high, but is said 95 MBs in reading and 85 MBs in
writing.
> then the compression method selected is intended to create
> that level
> of output (100MB/sec) during a backup. They do not want the
> compressor
> to be the rate limiting step.
well, too far fetched for me :D
>
> It is inevitable, that if you select high compression from
> an arithmetic
> compressor, it will never match the I/O rates of the storage
> devices.
> It will behave like a pig. Customers will be unimpressed.
>
> *******
>
> By using multi-core compression (all the CPU cores busy on the
> compression), you can improve the performance. An arithmetic
> compressor
> can be memory-bandwidth-bound, which is why you would hope a
> 5800X3D
> (with extra cache) would run faster than a vanilla 5800 CPU.
> Now, one
> reason that does not happen, is the L3 on such a chip, is
> only a bit
> faster than main memory. The larger a cache becomes,
> generally there
> is an access speed penalty on that. Some caches are also
> "segmented"
> and the "distance" from the core to the cache, the routing,
> slows it down.
> This is why the large cache on an Epyc or a Milan, isn't as
> effective
> as you might like.
>
> As an example of a multi-core one, you could experiment with
> "pigz".
Gambas component just supports 3 algos.
gzip, bzip and another I cannot recall (the fastest and
worse in ratios).
I 've chosen the bzip2. I don't even know if it has parallel
versions or not. I guess not, since even during duty I did
not notice slowing in any other running SW and CPU usage did
not peak too much.

> I do not know how well it scales, and exactly how many cores
> it can use,
> but it's an example of a multi-core on compression program.
> On decompression,
> it is still a single thread of execution, last time I checked.
>
>    https://linux.die.net/man/1/pigz
>
> But if you were hoping to "set the world on fire" with your
> programming
> skills in this topic, others have been there and "got their
> Tshirt" :-)
no no, not at all. Just using existing components in gambas
to perform compression.
which btw does not support a per-folder compression.
I am evaluating using shell / exec and invoking TAR to add a
layer and then to feed the .tar to the compressor.
But this would add nothing useful to AWIT DBACKUP, which is
very good in per-folder backup. It can even update backups
(but it's me that is unable to exploit this feature).

Click here to read the complete article

On Sat, 10 Jun 2023 09:38:02 +0200, MarioCPPP wrote:
> On 09/06/23 13:45, Paul wrote:
>> On 6/9/2023 6:20 AM, MarioCPPP wrote:
>>>
> CUT my question
>
>>>
>>
>> If you have individually compressed a large file set from
>> your sample
>> disk, then you likely have all the data you need. You could
>> compare
>> the filelist of the original files, versus the filelist of
>> the individually
>
> no need, ALL of the problems are logged. I found some 14
> amputated symlinks

I always report dangling link on any software install/update package.
MY install script winds up running
symlinks -r / | grep dangling
as root, to warn me of any 'amputated' symlinks

<BIG SNIP>

On 2023-06-10 09:38, MarioCPPP wrote:
> On 09/06/23 13:45, Paul wrote:
>> On 6/9/2023 6:20 AM, MarioCPPP wrote:

>> The degree of compression used,
>> the lightness, is intended to approximately match the write speed of the
>> destination disk drive. So if the average backup drive does 100MB/sec ,
>
> I have a new 8 TB external (USB 3.1) disk, which does NOT reach that
> high, but is said 95 MBs in reading and 85 MBs in writing.
>
>> then the compression method selected is intended to create that level
>> of output (100MB/sec) during a backup. They do not want the compressor
>> to be the rate limiting step.
>
> well, too far fetched for me :D

It is also my criteria. I adjust the compression ratio so that the
backup runs at 150 MB/S or thereabouts. If it runs at only 80, the
compression is slowing it down.

--
Cheers, Carlos.

On 2023-06-09 at 08:45 ADT, Paul <nospam@needed.invalid> wrote:
> On 6/9/2023 6:20 AM, MarioCPPP wrote:
>>
>> I am writing a "per file" backup program in gambas (btw, If sb is intrested into, I can send him/her the sourcecode, which has one issue I must fix *)
>>
>> Now, it took more or less 24 hours backupping
>>
>> compressed  526282  regular files : 613,5 GB (614,9 GB on disk)
>> original (most of large ones just compressed and left as such) 699,8 GB (701,1 GB on disk)

<snip>

>> Tnx for any advice to my "skip list"

> In the following example, DO NOT run this on large files, if you can help
> it. This is just a way to determine how much compression can be achieved,
> without using a compressor as such.
>
> $ sudo apt install ent
>
> $ ent sample.mp4
>
> Entropy = 7.998724 bits per byte. <=== almost incompressible, like /dev/random below
>
> Optimum compression would reduce the size
> of this 23730017 byte file by 0 percent.
>
> $ dd if=/dev/zero of=zero.bin bs=1024 count=1024
> $ ent zero.bin
>
> Entropy = 0.000000 bits per byte. <=== very very compressible, much redundancy
>
> Optimum compression would reduce the size
> of this 1048576 byte file by 100 percent. <=== there is always a little overhead...
>

I think ent is no doubt interesting for some purposes, but its output makes
some bold and incorrect claims.

For example:

$ yes blartifas | head -1000 > a
$ ent a
Entropy = 3.121928 bits per byte.

Optimum compression would reduce the size
of this 10000 byte file by 60 percent.

Chi square distribution for 10000 samples is 297200.00, and randomly
would exceed this value less than 0.01 percent of the times.

Arithmetic mean value of data bytes is 96.2000 (127.5 = random).
Monte Carlo value for Pi is 4.000000000 (error 27.32 percent).
Serial correlation coefficient is -0.129567 (totally uncorrelated = 0.0).

$ xz a
$ ls -ls a.xz
4 -rw-r--r-- 1 zsd users 120 Jun 11 19:07 a.xz

$ yes blartifas | head -1000 |wc
1000 1000 10000

So xz is able to reduce this file not down to 60% of its original size, but
rather 1.2% of its original size.

I am (wildly) guessing that 'ent's claim means "if you are using an entropy
compressor like Huffman or arithmetic coding, then ..." rather than what
someone reading "Optimum" could interpret as "the best possible
compressor".

Jim

On 2023-06-09 at 09:17 ADT, Dan Purgert <dan@djph.net> wrote:
> On 2023-06-09, MarioCPPP wrote:
>> [...]
>> So, in your opinion, which multimedia files, by extention
>> (the program is not smart as to look into files trying to
>> guess entropy, it considers just the extention alone),
>> deserves compression and which would be a lot faster to
>> store as such ?
>
> All of them. They're already compressed.

Not quite all of them. Someone might have raw files from a digital camera,
or uncompressed audio files (e.g., .wav files), and I've even see windoze
users happily email around .bmp files.

> It's probably easier talking about what is viable for compression -->
> text documents (*odf, *txt, sourcecode, etc.)

I avoid word processors whenever possible, but I created a .odt file with
libreoffice (there doesn't seem to be a .odf choice with my program) and
that file was apparently already compressed. Or, at least, xz didn't make
any significant improvement.

Jim

On 2023-06-11, Jim Diamond wrote:
> On 2023-06-09 at 09:17 ADT, Dan Purgert <dan@djph.net> wrote:
>> On 2023-06-09, MarioCPPP wrote:
>>> [...]
>>> So, in your opinion, which multimedia files, by extention
>>> (the program is not smart as to look into files trying to
>>> guess entropy, it considers just the extention alone),
>>> deserves compression and which would be a lot faster to
>>> store as such ?
>>
>> All of them. They're already compressed.
>
> Not quite all of them. Someone might have raw files from a digital
> camera, or uncompressed audio files (e.g., .wav files), and I've even
> see windoze users happily email around .bmp files.

True, but I was under the impression that the OP was working on
something for their own use, and dealing with standard "already
compressed" media types that are relatively ubiquitous.

>
>> It's probably easier talking about what is viable for compression -->
>> text documents (*odf, *txt, sourcecode, etc.)
>
> I avoid word processors whenever possible, but I created a .odt file with
> libreoffice (there doesn't seem to be a .odf choice with my program) and
> that file was apparently already compressed. Or, at least, xz didn't make
> any significant improvement.

Serves me right for posting from an ssh session without triple-checking
the file extensions :)

--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860

On 6/10/2023 3:38 AM, MarioCPPP wrote:
> On 09/06/23 13:45, Paul wrote:
>> Summary: If you consider disk drives expensive, than BZ2 is the answer.
>
> yes !
>
>>           If you consider disk drives cheap, you can try pigz instead.
>>           And yes, if you want, you can avoid compressing the .mp4 file.
>
> I am working on the exclusion list. This would really speed up a lot !
>
>>           Good idea. PDF files can be compressed a bit, but not much.
>>
>>           Make sure the CPU has a good cooler, for jobs like this, as the
>>           CPU is going to get warm. To compress all the data on a decent
>>           sized hard drive, costs about $1 in electricity. Released as heat.
>
> wow ... electricity prices here in shitaly is a nightmare :(

This is a picture to show the limits of good compression.
The compressor does not run at a consistent speed while doing this.
After the picture was taken, it slowed down.

No care was taken in selecting the sample. This run was a "first test"
to see if the cooler on the CPU was sufficient for the task or not.
And it seems to be OK. Part of the test involves sticking a finger
on the VCore heatsinks and checking for runaway temps. The previous
CPU was so low power, I wasn't even aware there was any automatic
control on the motherboard. This is 7Z ultra.

Input W1022H2.vhd 28,492,703,232 bytes
Output W1022H2.7z 10,314,287,993 bytes

Computer draws: 240W from mains power (ATX supply is not a high efficiency one)
CPU draws: 12V @ 12.2A VCore = 146W
CPU temp: 66C (not the best cooler) Fan speed was not constant during the run.

Compression rate (best case) 50MB/sec, with a quality similar to BZ2.
The compressor software does not allow more than 32 threads (to prevent commercial usage).

[Picture]

https://i.postimg.cc/FsCJbwnh/first-compression-test.gif

So what that shows, is with high quality compression, you cannot quite
keep up with the hard drive I/O rate.

If we compare that to BZ2 ultra (contained in the same program)...

Input W1022H2.vhd 28,492,703,232 bytes
Output W1022H2.7z 12,005,899,854 bytes

Computer draws: 212W from mains power
CPU draws: 12V @ 11A VCore = 132W
CPU temp: 60C CPU temperature inside

Compression rate (best case) 20MB/sec
The compressor does not allow more than 32 threads.
CPU graphs look the same as the other picture.

The problem needs a bigger-still processor. $7000
ought to fix it :-)

*******
On the same computer, W11 bash shell, Linux pigz run.
This shows the space/time tradeoff of GZIP compression as a method.

date ; pigz -c -9 -p 32 W1022H2.vhd > W1022H2.vhd.gz ; date

Mon Jun 12 11:26:53 EDT 2023 \___ 97 sec, 133.5MB/sec output
Mon Jun 12 11:28:30 EDT 2023 /

Input W1022H2.vhd 28,492,703,232 bytes
Output W1022H2.7z 12,950,040,959 bytes

Very short runtime. About the same CPU characteristic as BZ2
with a little higher clock (the motherboard and CPU automatically
adjust to conditions so that current flow limiter and temp spec
are not exceeded). Both the CPU and GPU have closed-loop control,
and the operating conditions (voltages and clocks) are adjusted
automatically, rather than statically set as in the old days.

And a pigz 3 for fun. The pigz 9 does not look so bad now.

date ; pigz -c -3 -p 32 W1022H2.vhd > W1022H2.vhd.gz ; date

Mon Jun 12 11:32:41 EDT 2023 \___ 78 sec (cores not all engaged... hmmm)
Mon Jun 12 11:33:59 EDT 2023 /

Input W1022H2.vhd 28,492,703,232 bytes
Output W1022H2.7z 13,363,488,173 bytes

I don't know why the tasking mis-behaved a bit.

So if you were thinking "some new hardware will fix this",
it helps a bit, but it's still not good enough. What we need
is better RAM, because there is no point the CPU running
as fast as it does, if it has to "wait" for 100 cycle intervals
for a memory lookup to come back. Some of the compressors
really appreciate RAM bandwidth.

When I ran Memory Test on the machine (you do that before connecting
your daily-driver OS disk), not only did the usual
things get hot, even the Southbridge heatsink got hot. Pretty funny.
It's not supposed to do that. The CPU right now (idle) is 29C. That
is the only test that made the Southbridge get hot.

Paul

On 2023-06-12 at 06:37 ADT, Dan Purgert <dan@djph.net> wrote:
> On 2023-06-11, Jim Diamond wrote:
>> On 2023-06-09 at 09:17 ADT, Dan Purgert <dan@djph.net> wrote:
>>> On 2023-06-09, MarioCPPP wrote:
>>>> [...]
>>>> So, in your opinion, which multimedia files, by extention
>>>> (the program is not smart as to look into files trying to
>>>> guess entropy, it considers just the extention alone),
>>>> deserves compression and which would be a lot faster to
>>>> store as such ?

>>> All of them. They're already compressed.

>> Not quite all of them. Someone might have raw files from a digital
>> camera, or uncompressed audio files (e.g., .wav files), and I've even
>> see windoze users happily email around .bmp files.

> True, but I was under the impression that the OP was working on
> something for their own use, and dealing with standard "already
> compressed" media types that are relatively ubiquitous.

I'm not sure that the OP necessarily knows the difference between
uncompressed media files and compressed ones (he might, but the basic level
of the question left me wondering). While RAW files are probably used by
only a small subset of people, and .bpm files should be outlawed, I think
it is quite possible he might have some big .wav files around. (But who
knows for sure?) Mind you, he isn't going to get much mileage out of
trying to compress audio files with xz/gzip/<insert favourite
general-purpose compressor here>.

>>> It's probably easier talking about what is viable for compression -->
>>> text documents (*odf, *txt, sourcecode, etc.)

>> I avoid word processors whenever possible, but I created a .odt file with
>> libreoffice (there doesn't seem to be a .odf choice with my program) and
>> that file was apparently already compressed. Or, at least, xz didn't make
>> any significant improvement.

> Serves me right for posting from an ssh session without triple-checking
> the file extensions :)

I thought maybe you had the next version with the latest and greatest
incompatible file format. :-)

Jim

On 2023-06-09 at 08:45 ADT, Paul <nospam@needed.invalid> wrote:

<Huge amounts of snippage>

> PDF files can be compressed a bit, but not much.

I've found that some PDF files can be compressed considerably with
$ pdftk input.pdf cat 1-END output output.pdf compress
and that pdfsizeopt can compress some PDF files down to 20% (or so) of
their original size.

Getting 80% generally (in my experience) indicates a really poorly created
PDF, but I find running pdfsizeopt on PDF files can save a considerable
amount of space overall.

But (in case the OP or anyone else) is still reading, note that both of
these operations only need to be done once, and they create PDFs that
doesn't need to be uncompressed to be used by your favourite PDF viewer.

Jim

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2023-06-12, Jim Diamond wrote:
> On 2023-06-12 at 06:37 ADT, Dan Purgert <dan@djph.net> wrote:
>> [...]
>> True, but I was under the impression that the OP was working on
>> something for their own use, and dealing with standard "already
>> compressed" media types that are relatively ubiquitous.
> [...]
> Mind you, he isn't going to get much mileage out of
> trying to compress audio files with xz/gzip/<insert favourite
> general-purpose compressor here>.

yeah, *mp3 way back in the days of dialup were my introduction into
"wait, why doesn't *zip make a difference??" (Note that I was also a
teenager at best)

>> [...]
>> Serves me right for posting from an ssh session without triple-checking
>> the file extensions :)
>
> I thought maybe you had the next version with the latest and greatest
> incompatible file format. :-)

No, I'm not using MS Office :)

Had it in my mind that it was *odf, thanks to it being the "Open
Document Format" (and then *odt was "Open Document Template").

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE3asj+xn6fYUcweBnbWVw5UznKGAFAmSHhG8ACgkQbWVw5Uzn
KGB9GhAAo9L6OAL/AKqIS1k1XBP/DMLGVtqvZZJp+/dHlwi+lmgZvGNCQy2A4aev
0k1AUcdOqqt2xONu3yaS4RPmHYg+d5/1AUIUTQ4apqvgoS3jIeRbSd8gIQpFmyy0
Pdvsg8AiDb79HwVFov2UU3ZtZrc+Z8tSH2Ub+B1M3u1ZuJHLvDjOzgTFrdS2+nnJ
mzwAudgl/TFuff/nEiBsxXn3CMX3XWJlzk2pjpSSP7iArLAtVvEF6k6PO7DTXsWC
WlEuruiLLne+J5K98rtRXGEFN3q2uD3CDYR21rou6OMDV7DBJ6h7o01MxbZPL5D0
tvS3HxF1y6Cqq/5SLZLaW85CLFD1liPMBYPO4ibMsHsqVgw5tmXr+QvQHDHP1V+W
5SYtTRPKhrSAXEJcdgdDKn/7q3P6TyTYKysm8rF4eowFvKPS/oWcDxToj1NSHV7X
JLGhzITGkoy3Q80BNS2fyWCy2am2rQ1lQegXotvhMjMHuwpUr0N+8wuDjaV/aVI3
ZJGVijuV9hWZRsBfpdonQvE9ZiVQcqaP6LU9OaBjJrh5RY+VUNmsBZdXt1Wc+yYw
MorytSc+VW1OW7JT5ksI8SDQ4n4qCJTl0YKPuoFnXjzld+1al+a4YcBF4eMn4GqJ
gmvJ12xTWRWGHkKUkyT3rkPRhvsQVQpz3kK5w8eHZxVOPuqfeaA=
=7Es/
-----END PGP SIGNATURE-----

--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860

Am 12.06.23 um 22:46 schrieb Dan Purgert:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512

Troll.

--
De gustibus non est disputandum

On 2023-06-12 22:46, Dan Purgert wrote:
> On 2023-06-12, Jim Diamond wrote:
>> On 2023-06-12 at 06:37 ADT, Dan Purgert <dan@djph.net> wrote:
>>> [...]
>>> True, but I was under the impression that the OP was working on
>>> something for their own use, and dealing with standard "already
>>> compressed" media types that are relatively ubiquitous.
>> [...]
>> Mind you, he isn't going to get much mileage out of
>> trying to compress audio files with xz/gzip/<insert favourite
>> general-purpose compressor here>.
>
> yeah, *mp3 way back in the days of dialup were my introduction into
> "wait, why doesn't *zip make a difference??" (Note that I was also a
> teenager at best)

Ah, because mp3 compresses much more than zip, at the cost of losing
some fine detail.

They studied what the human ear considers the same, and erase those
details the ear can not differentiate.

<https://en.wikipedia.org/wiki/MP3>

With regard to audio compression (the aspect of the standard most
apparent to end-users, and for which it is best known), MP3 uses lossy
data-compression to encode data using inexact approximations and the
partial discarding of data. This allows a large reduction in file sizes
when compared to uncompressed audio. The combination of small size and
acceptable fidelity led to a boom in the distribution of music over the
Internet in the mid- to late-1990s, with MP3 serving as an enabling
technology at a time when bandwidth and storage were still at a premium.
The MP3 format soon became associated with controversies surrounding
copyright infringement, music piracy, and the file ripping/sharing
services MP3.com and Napster, among others. With the advent of portable
media players, a product category also including smartphones, MP3
support remains near-universal.

MP3 compression works by reducing (or approximating) the accuracy of
certain components of sound that are considered (by psychoacoustic
analysis) to be beyond the hearing capabilities of most humans. This
method is commonly referred to as perceptual coding or as psychoacoustic
modeling.[13] The remaining audio information is then recorded in a
space-efficient manner, using MDCT and FFT algorithms. Compared to
CD-quality digital audio, MP3 compression can commonly achieve a 75 to
95% reduction in size. For example, an MP3 encoded at a constant bitrate
of 128 kbit/s would result in a file approximately 9% of the size of the
original CD audio.[14] In the early 2000s, compact disc players
increasingly adopted support for playback of MP3 files on data CDs.

--
Cheers, Carlos.

On 2023-06-13, Joerg Lorenz wrote:
> Am 12.06.23 um 22:46 schrieb Dan Purgert:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA512
>
> Troll.

Oh? how's a pgp sig make one a troll?

Please do tell.

--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860

On 2023-06-13, Carlos E.R. wrote:
> On 2023-06-12 22:46, Dan Purgert wrote:
>> On 2023-06-12, Jim Diamond wrote:
>>> On 2023-06-12 at 06:37 ADT, Dan Purgert <dan@djph.net> wrote:
>>>> [...]
>>>> True, but I was under the impression that the OP was working on
>>>> something for their own use, and dealing with standard "already
>>>> compressed" media types that are relatively ubiquitous.
>>> [...]
>>> Mind you, he isn't going to get much mileage out of
>>> trying to compress audio files with xz/gzip/<insert favourite
>>> general-purpose compressor here>.
>>
>> yeah, *mp3 way back in the days of dialup were my introduction into
>> "wait, why doesn't *zip make a difference??" (Note that I was also a
>> teenager at best)
>
> Ah, because mp3 compresses much more than zip, at the cost of losing
> some fine detail.
>[...]

More the generic "it is already compressed" (regardless of which
approach is better). Roughly the same idea as running a compressed
archive through your compression tool again.

--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860

On 12/06/23 20:43, Jim Diamond wrote:
> On 2023-06-12 at 06:37 ADT, Dan Purgert <dan@djph.net> wrote:
>> On 2023-06-11, Jim Diamond wrote:
>>> On 2023-06-09 at 09:17 ADT, Dan Purgert <dan@djph.net> wrote:
>>>> On 2023-06-09, MarioCPPP wrote:
>>>>> [...]
>>>>> So, in your opinion, which multimedia files, by extention
>>>>> (the program is not smart as to look into files trying to
>>>>> guess entropy, it considers just the extention alone),
>>>>> deserves compression and which would be a lot faster to
>>>>> store as such ?
>
>>>> All of them. They're already compressed.
>
>>> Not quite all of them. Someone might have raw files from a digital
>>> camera, or uncompressed audio files (e.g., .wav files), and I've even
>>> see windoze users happily email around .bmp files.
>
>> True, but I was under the impression that the OP was working on
>> something for their own use, and dealing with standard "already
>> compressed" media types that are relatively ubiquitous.
>
> I'm not sure that the OP necessarily knows the difference between
> uncompressed media files and compressed ones

the answer is neither NO nor yes, but "it depends". In a few
cases, I mentioned myself, I know (I happen to also know the
difference between lossless and lossy, and the pure idiocy
of trying a lossless compressor after a lossy one just cut
the most).
But I don't know most of FILES EXTENTIONS associated to the
general concept.

I mean, I know WAV, BMP / TIFF / PCX, maybe AVI, are raw.
But for most extentions I dont know.

my current list of DONT-COMPRESS includes :

..fsa .squashfs .squash .lzw .lz77 .ppm .mp3 .aac .ogg .ogx
..vorbis .gif .png .jpeg .jpg .webp .heif .mpeg .mpg .mp4
..m4v .hevc .webm .mkv .mk3d .avi .wmv .asf .DivX .mkv .mov
..qt .FLV .F4V .SWF .m2p .mp2t .ps .ts .tsv .m2ts .mts .vob
..evo .3gp .jhr .jr .jz .jahr .apk .msi .deb

I am unsure about the .deb and about Java compressed packages

> (he might, but the basic level
> of the question left me wondering). While RAW files are probably used by
> only a small subset of people, and .bpm files should be outlawed, I think
> it is quite possible he might have some big .wav files around.

I have a few hanging around, from recordings maybe.
Also, I should have mixed media produced with bad-matching
audio and video codecs (due to my poor knowledge of the best
couples) or with poor settings of the codecs (too high frame
ratio, or fixed, or alike).

I noticed lot of times that, using different recording
programs, I got out very different video sizes for
comparable duration (during the so called plandemics, I
recorded lots of lessons, of 1 or 2 hours, ending up in a
mix of compressed formats but of very different sizes).

I dunno well neither the better "containers" nor the codecs

> (But who
> knows for sure?) Mind you, he isn't going to get much mileage out of
> trying to compress audio files with xz/gzip/<insert favourite
> general-purpose compressor here>.

At the beginning I forgot the "media" at all, which was a
severe mistake (I just looked for lossless formats).
Now some audio / video are a lot precompressed and I should
exclude all too

as for "rich" TEXT formats, it matters (they are numerous)
but not that much : their total size is overall far less
heavy that media or archived backups, so compressing or not
would spare not much space or lose that much time. I prefer
trade time for space spared though.

There is often some graphics inlined in .odt and .pdf, and
even if the sources were compressed, I dunno actually the
internal format of storage in the .odt (and I give very
little care setting the "QUALITY" option, tending to simply
choose BEST quality .... and I see the sizes grow a lot !).

>
>>>> It's probably easier talking about what is viable for compression -->
>>>> text documents (*odf, *txt, sourcecode, etc.)
>
>>> I avoid word processors whenever possible, but I created a .odt file with
>>> libreoffice (there doesn't seem to be a .odf choice with my program) and
>>> that file was apparently already compressed. Or, at least, xz didn't make
>>> any significant improvement.

yes, PURE text .odt are well pre-compressed (also .docx,
which I avoid, not having M$ sw), but I often insert
graphics caring little the kind of sources, and tending to
save at top quality internally. So I think I'll keep
compressing such documents

>
>> Serves me right for posting from an ssh session without triple-checking
>> the file extensions :)
>
> I thought maybe you had the next version with the latest and greatest
> incompatible file format. :-)
>
> Jim

--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
MarioCPPP

On 2023-06-13, MarioCPPP wrote:
> [...[
> I am unsure about the .deb and about Java compressed packages

*deb files are ar(1) archives, that among other things, contain two
gzipped tarballs (although xz is being rolled out as of 2021 or 2022 or
thereabouts).

--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860

On 2023-06-13 12:13, MarioCPPP wrote:
> On 12/06/23 20:43, Jim Diamond wrote:
>> On 2023-06-12 at 06:37 ADT, Dan Purgert <dan@djph.net> wrote:
>>> On 2023-06-11, Jim Diamond wrote:

....

> my current list of DONT-COMPRESS includes :
>
> .fsa .squashfs .squash .lzw .lz77 .ppm .mp3 .aac .ogg .ogx .vorbis .gif
> .png .jpeg .jpg .webp .heif .mpeg .mpg .mp4 .m4v .hevc .webm .mkv .mk3d
> .avi .wmv .asf .DivX .mkv .mov .qt .FLV .F4V .SWF .m2p .mp2t .ps .ts
> .tsv .m2ts .mts .vob .evo .3gp .jhr .jr .jz .jahr .apk .msi .deb
>
> I am unsure about the .deb and about Java compressed packages

A good compressor should know all those and automatically not waste cpu
cycles on them.

....

>>>>> It's probably easier talking about what is viable for
>>>>> compression --> text documents (*odf, *txt, sourcecode,
>>>>> etc.)
>>
>>>> I avoid word processors whenever possible, but I created a .odt
>>>> file with libreoffice (there doesn't seem to be a .odf choice
>>>> with my program) and that file was apparently already
>>>> compressed. Or, at least, xz didn't make any significant
>>>> improvement.
>
> yes, PURE text .odt are well pre-compressed (also .docx, which I avoid,
> not having M$ sw), but I often insert graphics caring little the kind of
> sources, and tending to save at top quality internally. So I think I'll
> keep compressing such documents

LibreOffice files are in fact ZIP archives.

--
Cheers, Carlos.

On 2023-06-13, Dan Purgert <dan@djph.net> wrote:
> On 2023-06-13, MarioCPPP wrote:
>> [...[
>> I am unsure about the .deb and about Java compressed packages
>
> *deb files are ar(1) archives, that among other things, contain two
> gzipped tarballs (although xz is being rolled out as of 2021 or 2022 or
> thereabouts).

To answer the other half java .jar files are zip archives.

same with most office documents also zip files.

--
Jasen.
🇺🇦 Слава Україні

On 13/06/23 12:28, Carlos E.R. wrote:
> On 2023-06-13 12:13, MarioCPPP wrote:
>> On 12/06/23 20:43, Jim Diamond wrote:
>>> On 2023-06-12 at 06:37 ADT, Dan Purgert <dan@djph.net>
>>> wrote:
>>>> On 2023-06-11, Jim Diamond wrote:
>
> ...
>
>> my current list of DONT-COMPRESS includes :
>>
>> .fsa .squashfs .squash .lzw .lz77 .ppm .mp3 .aac .ogg .ogx
>> .vorbis .gif .png .jpeg .jpg .webp .heif .mpeg .mpg .mp4
>> .m4v .hevc .webm .mkv .mk3d .avi .wmv .asf .DivX .mkv .mov
>> .qt .FLV .F4V .SWF .m2p .mp2t .ps .ts .tsv .m2ts .mts .vob
>> .evo .3gp .jhr .jr .jz .jahr .apk .msi .deb
>>
>> I am unsure about the .deb and about Java compressed packages
>
> A good compressor should know all those and automatically
> not waste cpu cycles on them.
it is not a standalone extern program, it is a gambas
component (a library) with just 3 algo and some levels of
compression between min and max level. Bzip2 was the better
of them (but it must compress what you tell it to compress,
so the choice have to be done by myself ... which is what is
to be expected by a programming language : to let the
programmer decide what to do in a more deterministic way).

>
> ...
>
>>>>>> It's probably easier talking about what is viable for
>>>>>> compression --> text documents (*odf, *txt, sourcecode,
>>>>>> etc.)
>>>
>>>>> I avoid word processors whenever possible, but I
>>>>> created a .odt
>>>>> file with libreoffice (there doesn't seem to be a .odf
>>>>> choice
>>>>> with my program) and that file was apparently already
>>>>> compressed.  Or, at least, xz didn't make any significant
>>>>> improvement.
>>
>> yes, PURE text .odt are well pre-compressed (also .docx,
>> which I avoid, not having M$ sw), but I often insert
>> graphics caring little the kind of sources, and tending to
>> save at top quality internally. So I think I'll keep
>> compressing such documents
>
> LibreOffice files are in fact ZIP archives.
maybe not "monolithic", in that the text and formatting,
modules and other objects, are surely losslessly compressed,
but I suspect (from the "quality" parameter, also present in
exporting in PDF) that media are treated separately and
possibly lossy.
I have not inquiried a lot about it, expecially on audio and
video which I never add to documents, just a lot of graphics
in very heterogeneous original formats, and internally
managed dunno how, and normally I cannot care less :D :D)

>
>
--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
MarioCPPP

On 6/12/2023 2:49 PM, Jim Diamond wrote:
> On 2023-06-09 at 08:45 ADT, Paul <nospam@needed.invalid> wrote:
>
> <Huge amounts of snippage>
>
>> PDF files can be compressed a bit, but not much.
>
> I've found that some PDF files can be compressed considerably with
> $ pdftk input.pdf cat 1-END output output.pdf compress
> and that pdfsizeopt can compress some PDF files down to 20% (or so) of
> their original size.
>
> Getting 80% generally (in my experience) indicates a really poorly created
> PDF, but I find running pdfsizeopt on PDF files can save a considerable
> amount of space overall.
>
> But (in case the OP or anyone else) is still reading, note that both of
> these operations only need to be done once, and they create PDFs that
> doesn't need to be uncompressed to be used by your favourite PDF viewer.
>
> Jim

If processing files by their type, some file types (especially containers
of other things), will have a wide variation in their entropy. The worst
I have in hand, is the VMWare container which VMWare decided must have
mandatory encryption on it, which means it's not compressible at all.

PDF files can actually contain more than just original-flavor PDF code.
Some files are dual mode, and also contain source for editing purposes.
There are also some Adobe-variants that are not PDF (not part of the
PDF standard). You would expect to need some fine gradations from
the "file" utility and /etc/magic, to sort those. Some PDFs will contain
small quantities of Javascript, as well as multimedia blobs such as
movies. You can play a movie in a PDF.

It turns out the "ent utility" is ancient. It received an "upgrade"
from someone at around the year 2008. It's just possible it has not
kept up with advances in compressor design.

Looking at the code (I'm not a software guy), I don't know where
the concept of "serial correlation coefficient" comes from. Apparently
it is traceable to Knuth, but I don't have a copy of Knuth here. Someone
with a CS library likely has that covered. It's like a "thing" with a
chunk size of eight bits, and that worries me. Some compressors use
huge dictionaries, by comparison. And that could be why your repetitive
text lines file, shows the disparity. The ent does not look that deeply
for correlation.

The only reason I picked that utility out, is because someone
had intended it for the purpose, even if 30 years later it was
rather dated. Why is it even in the distro ? It implies someone
is using it. But for what ? Do they actually use that to test
crypto stuff ???

Paul

Am 13.06.23 um 11:49 schrieb Dan Purgert:
> On 2023-06-13, Joerg Lorenz wrote:
>> Am 12.06.23 um 22:46 schrieb Dan Purgert:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA512
>>
>> Troll.
>
> Oh? how's a pgp sig make one a troll?

OK: Bragging Troll ...

> Please do tell.

I use OpenPGP signing/encryption only in mails. It makes absolutely no
sense in the worldwide Usenet. It is just overhead.

--
Gutta cavat lapidem (Ovid)