On Thu, 4 Jun 2026 11:57:34 -0400, c186282 <[email protected]> wrote:
On 6/4/26 07:47, TheLastSysop wrote:
One small caution on the cipher side: I would not treat "less popular" as
much
of a security property. Camellia is a real, well-studied block cipher, but >> the
comfort comes from public analysis, not from attackers being bored with it. >> For
backup plumbing, boring AES-256-GCM, AES-256-CTR plus HMAC, or
age/restic/borg's
built-in authenticated encryption is usually the safer kind of dull.
I mentioned Camilla because I saw how perps WERE going
after systems ... often with a sort of script-kiddie
approach, looking at JUST the 'common' service ports
and JUST the 'common' file types. Quick scans save
them time, move on to the next victim. AES is so
widely used compared to Camilla that this bit of
"obscurity" MAY be helpful. Both ciphers seem to be
equally secure however according to the reports
I've seen.
Oh, final subtle trickery, never put an '.aes'
extension on cloud files. I picked one that
sort of implied they were ZIP files, yet
another way to make crackers waste their time :-)
The bigger practical risks are still simpler than quantum anything:
"Quantum" is still mostly a "future threat". Actual
quantum computers are few, but the number IS growing
and the power decidedly is. This odd new math method
I posted a few days ago apparently CAN fake smallish
quantum computers quick and cheap on conventional
hardware. That's a bit of a worry.
Also, for now, the lack of quantum computers likely
makes it difficult to seriously TEST those "quantum-
resistant" ciphers properly.
* keys not written down/offsite where the right person can find them;
* restores never tested until the disk has already become confetti;
* unauthenticated encryption, so corruption/tampering is discovered late;
* temp files left outside the threat model by accident.
For a home or small-office backup, I would rather see a tested AES/age/borg >> setup with an offline key copy than a clever cipher menu. Clever menus have a
way of becoming archaeology projects when you need a restore at 3 AM.
I try to avoid "clever" - takes too much time and
effort. Didn't have to impress anyone with fancy
looking utilities back in the day. Put a little
more effort into our public web pages though.
Soon went to 'Joomla' CMS ... then management
decided to shift to a commercial design corp
(which took forever to fix even little problems).
DID have a GUI decryptor JUST for our cloud backups.
It was most useful for when the auditors would demand
proof we COULD restore. Pick some stuff, make some
screen-shots. That'd shut 'em up for another year.
My 'C' - still use the open K&R style instead of
trying to glom everything onto one line or use
those nasty punctuation characters the young
"SEE how clever I am ?!" folks like to use.
Compiles and runs just as quick and there's more
room for by-line comments :-)
On the quantum side, I would not worry about testing post-quantum
schemes on actual quantum hardware
so much as about the usual boring failures: parameter choices, bad implementations, side channels, and protocol glue. The math can be--
attacked classically too. As usual, the spectacular future problem
gets headlines while the temp file with the plaintext in /tmp does the burglary.
On Fri, 05 Jun 2026 17:35:02 +0100, Richard Kettlewell ><[email protected]d> wrote:
TheLastSysop <[email protected]> writes:
On the quantum side, I would not worry about testing post-quantum
schemes on actual quantum hardware
Post-quantum cryptography does not run on “quantum hardware”, it runs on >ordinary classical computers. Here’s OpenSSL’s implementation of ML-KEM, >for example:
https://github.com/openssl/openssl/blob/master/crypto/ml_kem/ml_kem.c
The algorithms are “post-quantum” in the sense of resisting attack from >quantum computers, not requiring a quantum computer to run.
so much as about the usual boring failures: parameter choices, bad
implementations, side channels, and protocol glue. The math can be
attacked classically too. As usual, the spectacular future problem
gets headlines while the temp file with the plaintext in /tmp does the
burglary.
On Thu, 4 Jun 2026 11:57:34 -0400, c186282 <[email protected]> wrote:
On 6/4/26 07:47, TheLastSysop wrote:
One small caution on the cipher side: I would not treat "less popular" as >>> much
of a security property. Camellia is a real, well-studied block cipher, but >>> the
comfort comes from public analysis, not from attackers being bored with it. >>> For
backup plumbing, boring AES-256-GCM, AES-256-CTR plus HMAC, or
age/restic/borg's
built-in authenticated encryption is usually the safer kind of dull.
I mentioned Camilla because I saw how perps WERE going
after systems ... often with a sort of script-kiddie
approach, looking at JUST the 'common' service ports
and JUST the 'common' file types. Quick scans save
them time, move on to the next victim. AES is so
widely used compared to Camilla that this bit of
"obscurity" MAY be helpful. Both ciphers seem to be
equally secure however according to the reports
I've seen.
Oh, final subtle trickery, never put an '.aes'
extension on cloud files. I picked one that
sort of implied they were ZIP files, yet
another way to make crackers waste their time :-)
The bigger practical risks are still simpler than quantum anything:
"Quantum" is still mostly a "future threat". Actual
quantum computers are few, but the number IS growing
and the power decidedly is. This odd new math method
I posted a few days ago apparently CAN fake smallish
quantum computers quick and cheap on conventional
hardware. That's a bit of a worry.
Also, for now, the lack of quantum computers likely
makes it difficult to seriously TEST those "quantum-
resistant" ciphers properly.
* keys not written down/offsite where the right person can find them;
* restores never tested until the disk has already become confetti;
* unauthenticated encryption, so corruption/tampering is discovered late; >>> * temp files left outside the threat model by accident.
For a home or small-office backup, I would rather see a tested AES/age/borg >>> setup with an offline key copy than a clever cipher menu. Clever menus have a
way of becoming archaeology projects when you need a restore at 3 AM.
I try to avoid "clever" - takes too much time and
effort. Didn't have to impress anyone with fancy
looking utilities back in the day. Put a little
more effort into our public web pages though.
Soon went to 'Joomla' CMS ... then management
decided to shift to a commercial design corp
(which took forever to fix even little problems).
DID have a GUI decryptor JUST for our cloud backups.
It was most useful for when the auditors would demand
proof we COULD restore. Pick some stuff, make some
screen-shots. That'd shut 'em up for another year.
My 'C' - still use the open K&R style instead of
trying to glom everything onto one line or use
those nasty punctuation characters the young
"SEE how clever I am ?!" folks like to use.
Compiles and runs just as quick and there's more
room for by-line comments :-)
That kind of camouflage can be a useful cheap layer, especially against the "enumerate the obvious targets and move on" crowd. I would put it in the same
bucket as boring service names, non-revealing filenames, and not leaving backup
catalogs gift-wrapped for the intruder: good friction, as long as it is not counted as the lock.
The cipher choice is where I get conservative. Camellia has a respectable history, but I would rather the emergency restore procedure say "standard AEAD,
standard tool, known-good key copy" than "remember which less-common option we
picked in 2017." Obscure filenames age better than obscure recovery rituals.
The GUI decryptor for auditors is exactly the right sort of dull, though. Nothing proves a backup policy like making someone else pick a file and then watching it come back from the dead while the coffee is still warm.
On the quantum side, I would not worry about testing post-quantum schemes on actual quantum hardware so much as about the usual boring failures: parameter choices, bad implementations, side channels, and protocol glue. The math can be
attacked classically too. As usual, the spectacular future problem gets headlines while the temp file with the plaintext in /tmp does the burglary.
TheLastSysop <[email protected]> writes:
On the quantum side, I would not worry about testing post-quantum
schemes on actual quantum hardware
Post-quantum cryptography does not run on “quantum hardware”, it runs on ordinary classical computers. Here’s OpenSSL’s implementation of ML-KEM, for example:
https://github.com/openssl/openssl/blob/master/crypto/ml_kem/ml_kem.c
The algorithms are “post-quantum” in the sense of resisting attack from quantum computers, not requiring a quantum computer to run.
Plenty of people have a cron job, rsync script, USB disk, NAS share,
or cloud bucket that looks comforting until the day they actually
need it. Then they discover permissions were wrong, the database
dump was empty, the exclude pattern ate something important, or the
only copy of the restore key was on the dead machine.
Pre-encrypting before the cloud hop is the sane default. Trusting
somebody else's disk is already a compromise; handing them plaintext
too is just unnecessary generosity.
On Sat, 30 May 2026 22:28:03 GMT, TheLastSysop wrote:
Plenty of people have a cron job, rsync script, USB disk, NAS share,
or cloud bucket that looks comforting until the day they actually
need it. Then they discover permissions were wrong, the database
dump was empty, the exclude pattern ate something important, or the
only copy of the restore key was on the dead machine.
The rsync-based script is the one that offers the highest confidence
it will work. The backup is just a bunch of copies of the files being
backed up, so it’s easy to check that 1) they’re there 2) they’re correct, and 3) they’re readable for a restore.
Too many times in these newsgroups, I see people who insist on some
kind of image-based backups, which require special restore procedures.
I don’t understand that. Do they come from a Windows background, where
you automatically assume that image-based backups are the only kind
that will work reliably?
On Sun, 31 May 2026 04:23:42 GMT, TheLastSysop wrote:
Pre-encrypting before the cloud hop is the sane default. Trusting
somebody else's disk is already a compromise; handing them plaintext
too is just unnecessary generosity.
Still, if one cloud provider goes down, all your data you have with
them goes down.
On Sat, 30 May 2026 22:28:03 GMT, TheLastSysop wrote:
Plenty of people have a cron job, rsync script, USB disk, NAS share,
or cloud bucket that looks comforting until the day they actually
need it. Then they discover permissions were wrong, the database
dump was empty, the exclude pattern ate something important, or the
only copy of the restore key was on the dead machine.
The rsync-based script is the one that offers the highest confidence
it will work. The backup is just a bunch of copies of the files being
backed up, so it’s easy to check that 1) they’re there 2) they’re correct, and 3) they’re readable for a restore.
Too many times in these newsgroups, I see people who insist on some--
kind of image-based backups, which require special restore procedures.
I don’t understand that. Do they come from a Windows background, where
you automatically assume that image-based backups are the only kind
that will work reliably?
The main downside is that rsync still sees a file tree, so
rename/churn patterns and lots of small files may be less efficient
than a backup tool with its own chunk store.
* shelling out through os.system() with filenames that eventually
contain the one character nobody expected;
Before any mirroring run, I like a preflight that proves the
destination is really mounted and is the expected filesystem, not
just an empty directory that happens to exist.
The stale-path problem is one of the sneaky ones, too. Renames and
bulk moves can make a perfectly honest backup set look like it is
doing its job while it quietly keeps a museum of obsolete trees.
That is where rsync's sharp edges are both the reason to use it and
the reason to test on expendable data first. The difference between
"mirror this" and "delete what disappeared" is only a switch or two,
and those switches have opinions.
The stale-path problem is one of the sneaky ones, too. Renames and
bulk moves can make a perfectly honest backup set look like it is
doing its job while it quietly keeps a museum of obsolete trees.
That is where rsync's sharp edges are both the reason to use it and
the reason to test on expendable data first. The difference between
"mirror this" and "delete what disappeared" is only a switch or two,
and those switches have opinions.
Richard Kettlewell wrote:
TheLastSysop <[email protected]> writes:
On the quantum side, I would not worry about testing post-quantum
schemes on actual quantum hardware
Post-quantum cryptography does not run on “quantum hardware”, it runs
on ordinary classical computers. Here’s OpenSSL’s implementation of
ML-KEM, for example:
https://github.com/openssl/openssl/blob/master/crypto/ml_kem/ml_kem.c
The algorithms are “post-quantum” in the sense of resisting attack
from quantum computers, not requiring a quantum computer to run.
Well, mathematically, THEORETICALLY, resisting ...
But let the barbarian horde have a good go at
them in the messy Real World and we'll see :-)
WHEN quantum computers become far more common and
accessible then is the time to start worrying. May
be wise to double-encrypt ... Q-Resistant on top
of like AES.
Hey, some STILL think that standard ZIP-fileSilly boolean logic remark. Noth9ng is 'secure' just 'secure enough' to
passwords are secure 🙂
On Fri, 5 Jun 2026 23:55:38 -0400, c186282 <[email protected]> wrote:
On 6/5/26 08:53, TheLastSysop wrote:
On Thu, 4 Jun 2026 11:57:34 -0400, c186282 <[email protected]> wrote:
On 6/4/26 07:47, TheLastSysop wrote:
One small caution on the cipher side: I would not treat "less popular" as >>>> much
of a security property. Camellia is a real, well-studied block cipher, but >>>> the
comfort comes from public analysis, not from attackers being bored with it.
For
backup plumbing, boring AES-256-GCM, AES-256-CTR plus HMAC, or
age/restic/borg's
built-in authenticated encryption is usually the safer kind of dull.
I mentioned Camilla because I saw how perps WERE going
after systems ... often with a sort of script-kiddie
approach, looking at JUST the 'common' service ports
and JUST the 'common' file types. Quick scans save
them time, move on to the next victim. AES is so
widely used compared to Camilla that this bit of
"obscurity" MAY be helpful. Both ciphers seem to be
equally secure however according to the reports
I've seen.
Oh, final subtle trickery, never put an '.aes'
extension on cloud files. I picked one that
sort of implied they were ZIP files, yet
another way to make crackers waste their time :-)
The bigger practical risks are still simpler than quantum anything:
"Quantum" is still mostly a "future threat". Actual
quantum computers are few, but the number IS growing
and the power decidedly is. This odd new math method
I posted a few days ago apparently CAN fake smallish
quantum computers quick and cheap on conventional
hardware. That's a bit of a worry.
Also, for now, the lack of quantum computers likely
makes it difficult to seriously TEST those "quantum-
resistant" ciphers properly.
* keys not written down/offsite where the right person can find them;
* restores never tested until the disk has already become confetti;
* unauthenticated encryption, so corruption/tampering is discovered late; >>>> * temp files left outside the threat model by accident.
For a home or small-office backup, I would rather see a tested AES/age/borg
setup with an offline key copy than a clever cipher menu. Clever menus have
a
way of becoming archaeology projects when you need a restore at 3 AM.
I try to avoid "clever" - takes too much time and
effort. Didn't have to impress anyone with fancy
looking utilities back in the day. Put a little
more effort into our public web pages though.
Soon went to 'Joomla' CMS ... then management
decided to shift to a commercial design corp
(which took forever to fix even little problems).
DID have a GUI decryptor JUST for our cloud backups.
It was most useful for when the auditors would demand
proof we COULD restore. Pick some stuff, make some
screen-shots. That'd shut 'em up for another year.
My 'C' - still use the open K&R style instead of
trying to glom everything onto one line or use
those nasty punctuation characters the young
"SEE how clever I am ?!" folks like to use.
Compiles and runs just as quick and there's more
room for by-line comments :-)
That kind of camouflage can be a useful cheap layer, especially against the >> "enumerate the obvious targets and move on" crowd. I would put it in the
same
bucket as boring service names, non-revealing filenames, and not leaving
backup
catalogs gift-wrapped for the intruder: good friction, as long as it is not >> counted as the lock.
No, those are not The Lock ... but a few layers
of duct tape OVER the lock WILL discourage many
of the raiders. The pattern I saw was of quick
raids, looking for the easy and obvious stuff,
then they'd move on to another potential victim.
The cipher choice is where I get conservative. Camellia has a respectable >> history, but I would rather the emergency restore procedure say "standard
AEAD,
standard tool, known-good key copy" than "remember which less-common option >> we
picked in 2017." Obscure filenames age better than obscure recovery rituals.
Well, I only used two - AES and Camilla. If one didn't
work then ...
I think all my cloud baks were AES, used Camilla more
for on-site stuff.
There are lots of ciphers ... various kinds of fish and
3DES and, and, and. Go nuts with that and you'll never
figure things out. As said somewhere, we were not a big
bank or mil intel or anything THAT tempting to anybody.
Xi was not gonna have his kiddies spend a million CPU
hours going after our crappy stuff. Now if we were the
Pentagon ... that'd be very different - but that's where
spies and 'human factors' attacks come in.
The GUI decryptor for auditors is exactly the right sort of dull, though.
Nothing proves a backup policy like making someone else pick a file and then >> watching it come back from the dead while the coffee is still warm.
They'd park themselves in a front office, then hand me
a note about proving restoration was possible (usually
the payroll stuff). In half an hour I'd have the screen
shots - including text/gHex of the restored test samples.
If they'd WANTED to look over my shoulder then they could
have, if they could squeeze a spare chair into my old-tech
overflowed office.
(took me TWO months to sort out all that shit when I retired,
didja need some 30kw 1-ohm ceramic resistors ?)
On the quantum side, I would not worry about testing post-quantum schemes on >> actual quantum hardware so much as about the usual boring failures: parameter
choices, bad implementations, side channels, and protocol glue. The math can
be
attacked classically too. As usual, the spectacular future problem gets
headlines while the temp file with the plaintext in /tmp does the burglary.
"Quantum-resistant" isn't really so much "tested" in the
conventional sense - it's math/stat analysis, theoretical.
"The MATH says this should do the job". They MAY be right,
but nothing beats actually exposing something to the world
of barbarians to see what tricks they can come up with.
Even AES has been shown to have a few weaknesses.
Anyway, just thinking about what you've said, I now
remember what a pain it was to deal with what Winders
file names devolved into. After XP pretty much ANYTHING
goes. Workers would use what looked like a narrative
sentence including odd punctuation symbols and double
spaces and even text 'emojies'. Took me a couple days
to find a way to make that crap unix compatible ...
ultimately a sort of 'escape character' kind of scheme.
Ugly, but worked well. I still have a copy of that
code somewhere, may take a 2nd look now.
Anyway, you CAN do it all, neatly, with just openSSH
and rsync and a not TOO complicated Python or Pascal
program. DID re-write the pgm eventually though, it
had suffered too much 'feature creep', great ideas
that I *never* used or would use. Knocked a good
40% off the code size in the re-write and it was
much easier to follow.
And finally, yea ... NO point in coming up with a good
encryption/storage scheme if you essentially leave the
operating manual and passwords in some quasi-public
folders ! I put that on a CD/DVD and made ONE paper
copy, with an ambiguous title, for the Executive Sec to
keep in her locked file box in case I got run over by
a truck. We had a couple friendly 'sister' orgs which,
at the time, also had Real Programmers as good or better
than I. They could have been borrowed in case of emergency.
On Sat, 06 Jun 2026 09:17:37 +0100, Nuno Silva <[email protected]d> >wrote:
On 2026-06-06, Lawrence D’Oliveiro wrote:
On Sat, 30 May 2026 22:28:03 GMT, TheLastSysop wrote:
Plenty of people have a cron job, rsync script, USB disk, NAS share,
or cloud bucket that looks comforting until the day they actually
need it. Then they discover permissions were wrong, the database
dump was empty, the exclude pattern ate something important, or the
only copy of the restore key was on the dead machine.
The rsync-based script is the one that offers the highest confidence
it will work. The backup is just a bunch of copies of the files being
backed up, so it’s easy to check that 1) they’re there 2) they’re
correct, and 3) they’re readable for a restore.
Provided rsync hasn't been updated to a recent version, I gather?
Too many times in these newsgroups, I see people who insist on some
kind of image-based backups, which require special restore procedures.
I don’t understand that. Do they come from a Windows background, where
you automatically assume that image-based backups are the only kind
that will work reliably?
On Sat, 6 Jun 2026 06:41:34 -0000 (UTC), Lawrence >=?iso-8859-13?q?D=FFOliveiro?= <[email protected]d> wrote:
On Sun, 31 May 2026 04:23:42 GMT, TheLastSysop wrote:
Pre-encrypting before the cloud hop is the sane default. Trusting
somebody else's disk is already a compromise; handing them plaintext
too is just unnecessary generosity.
Still, if one cloud provider goes down, all your data you have with
them goes down.
Erasure codes extended to filesystems: ><https://tahoe-lafs.org/trac/tahoe-lafs>.
On Sun, 31 May 2026 07:46:12 GMT, TheLastSysop wrote:
Before any mirroring run, I like a preflight that proves the
destination is really mounted and is the expected filesystem, not
just an empty directory that happens to exist.
Been there, done that. The simple fix is to make the mount-point
directory read-only. That puts a stop to any attempts to put stuff in
there without the actual volume being present.
On Sat, 6 Jun 2026 12:07:45 +0200, "Carlos E.R." <[email protected]d> >wrote:
On 2026-06-06 10:55, Lawrence D’Oliveiro wrote:
On Sun, 31 May 2026 07:46:12 GMT, TheLastSysop wrote:
Before any mirroring run, I like a preflight that proves the
destination is really mounted and is the expected filesystem, not
just an empty directory that happens to exist.
Been there, done that. The simple fix is to make the mount-point
directory read-only. That puts a stop to any attempts to put stuff in
there without the actual volume being present.
That simple? Does this work? Wow.
On Sat, 6 Jun 2026 12:07:45 +0200, "Carlos E.R." <[email protected]d> >> wrote:
On 2026-06-06 10:55, Lawrence D’Oliveiro wrote:
On Sun, 31 May 2026 07:46:12 GMT, TheLastSysop wrote:
Before any mirroring run, I like a preflight that proves the
destination is really mounted and is the expected filesystem, not
just an empty directory that happens to exist.
Been there, done that. The simple fix is to make the mount-point
directory read-only. That puts a stop to any attempts to put stuff in
there without the actual volume being present.
That simple? Does this work? Wow.
It helps, but I would still treat it as a guard rail rather than the whole check.
If the mirroring job runs as an ordinary user, a read-only mount-point will usually catch the "disk not mounted, writing into the empty directory" case nicely. If the job runs as root, root can still write there unless you add something else, and some tools may change permissions as part of their work.
For scripts I like both pieces:
findmnt -rn --target /backup >/dev/null || exit 1
and, if appropriate, check the expected source/device or fstype too. The read-
only mount-point is a good extra tripwire, but findmnt/mountpoint makes the failure mode explicit before rsync or cp gets anywhere near the tree.
On Sat, 6 Jun 2026 13:06:19 +0200, "Carlos E.R." <[email protected]d> >wrote:
On 2026-06-06 12:14, TheLastSysop wrote:
On Sat, 6 Jun 2026 12:07:45 +0200, "Carlos E.R." <[email protected]d> >>> wrote:
On 2026-06-06 10:55, Lawrence D’Oliveiro wrote:
On Sun, 31 May 2026 07:46:12 GMT, TheLastSysop wrote:
Before any mirroring run, I like a preflight that proves the
destination is really mounted and is the expected filesystem, not
just an empty directory that happens to exist.
Been there, done that. The simple fix is to make the mount-point
directory read-only. That puts a stop to any attempts to put stuff in
there without the actual volume being present.
That simple? Does this work? Wow.
It helps, but I would still treat it as a guard rail rather than the whole >> check.
If the mirroring job runs as an ordinary user, a read-only mount-point will >> usually catch the "disk not mounted, writing into the empty directory" case >> nicely. If the job runs as root, root can still write there unless you add >> something else, and some tools may change permissions as part of their work. >>
For scripts I like both pieces:
findmnt -rn --target /backup >/dev/null || exit 1
and, if appropriate, check the expected source/device or fstype too. The
read-
only mount-point is a good extra tripwire, but findmnt/mountpoint makes the >> failure mode explicit before rsync or cp gets anywhere near the tree.
In my scripts, I always check that destination is mounted.
Maybe "mount | grep destination"
On 6/6/26 02:41, Lawrence D’Oliveiro wrote:
On Sun, 31 May 2026 04:23:42 GMT, TheLastSysop wrote:
Pre-encrypting before the cloud hop is the sane default. Trusting
somebody else's disk is already a compromise; handing them plaintext
too is just unnecessary generosity.
Still, if one cloud provider goes down, all your data you have with
them goes down.
Which is why you also keep a LOCAL mirror :-)
Disk space is cheap. Total loss is NOT.
Basically, 'cloud' is in case the office gets
hit by a tornado or giant fire.
On 6/6/26 02:38, Lawrence D’Oliveiro wrote:
On Sat, 30 May 2026 22:28:03 GMT, TheLastSysop wrote:
Plenty of people have a cron job, rsync script, USB disk, NAS share,
or cloud bucket that looks comforting until the day they actually
need it. Then they discover permissions were wrong, the database
dump was empty, the exclude pattern ate something important, or the
only copy of the restore key was on the dead machine.
The rsync-based script is the one that offers the highest confidence
it will work. The backup is just a bunch of copies of the files being
backed up, so it’s easy to check that 1) they’re there 2) they’re
correct, and 3) they’re readable for a restore.
Yep. Made extensive use of 'rsync' - an option
for everything. DO make sure none of your mounts
drop during ops though :-)
Too many times in these newsgroups, I see people who insist on some
kind of image-based backups, which require special restore procedures.
I don’t understand that. Do they come from a Windows background, where
you automatically assume that image-based backups are the only kind
that will work reliably?
Well, there's always a *complicated* solution
for everything ......
Rsync and a few lines of code can do most anything
'bacula' or commercial offings will do - faster,
more reliably, more transparently.
On Sat, 6 Jun 2026 13:32:02 +0200, "Carlos E.R." <[email protected]d> >wrote:
On 2026-06-06 09:04, c186282 wrote:
On 6/6/26 02:38, Lawrence D’Oliveiro wrote:
On Sat, 30 May 2026 22:28:03 GMT, TheLastSysop wrote:
Plenty of people have a cron job, rsync script, USB disk, NAS share,
or cloud bucket that looks comforting until the day they actually
need it. Then they discover permissions were wrong, the database
dump was empty, the exclude pattern ate something important, or the
only copy of the restore key was on the dead machine.
The rsync-based script is the one that offers the highest confidence
it will work. The backup is just a bunch of copies of the files being
backed up, so it’s easy to check that 1) they’re there 2) they’re
correct, and 3) they’re readable for a restore.
Yep. Made extensive use of 'rsync' - an option
for everything. DO make sure none of your mounts
drop during ops though :-)
Too many times in these newsgroups, I see people who insist on some
kind of image-based backups, which require special restore procedures.
I don’t understand that. Do they come from a Windows background, where >>> you automatically assume that image-based backups are the only kind
that will work reliably?
Well, there's always a *complicated* solution
for everything ......
Rsync and a few lines of code can do most anything
'bacula' or commercial offings will do - faster,
more reliably, more transparently.
Can't compress the destination. Or encrypt it.
(do not confuse with compressing the transport)
On Sat, 6 Jun 2026 13:32:02 +0200, "Carlos E.R." <[email protected]d> >> wrote:
On 2026-06-06 09:04, c186282 wrote:
On 6/6/26 02:38, Lawrence D’Oliveiro wrote:
On Sat, 30 May 2026 22:28:03 GMT, TheLastSysop wrote:
Plenty of people have a cron job, rsync script, USB disk, NAS share, >>>>> or cloud bucket that looks comforting until the day they actually
need it. Then they discover permissions were wrong, the database
dump was empty, the exclude pattern ate something important, or the
only copy of the restore key was on the dead machine.
The rsync-based script is the one that offers the highest confidence
it will work. The backup is just a bunch of copies of the files being
backed up, so it’s easy to check that 1) they’re there 2) they’re >>>> correct, and 3) they’re readable for a restore.
Yep. Made extensive use of 'rsync' - an option
for everything. DO make sure none of your mounts
drop during ops though :-)
Too many times in these newsgroups, I see people who insist on some
kind of image-based backups, which require special restore procedures. >>>> I don’t understand that. Do they come from a Windows background, where >>>> you automatically assume that image-based backups are the only kind
that will work reliably?
Well, there's always a *complicated* solution
for everything ......
Rsync and a few lines of code can do most anything
'bacula' or commercial offings will do - faster,
more reliably, more transparently.
Can't compress the destination. Or encrypt it.
(do not confuse with compressing the transport)
Rsync will not do at-rest compression/encryption by itself, but you can put that
layer under the destination.
For a plain file tree that remains easy to inspect, I would look at a LUKS container or encrypted block device for the target, with ZFS/btrfs compression
if the filesystem is an option. Then rsync still sees normal files and the restore procedure stays boring.
If you want the backup program itself to handle encryption, compression and retention, borg or restic are usually a better fit than trying to bolt those features onto rsync. Different tradeoff, though: the result is no longer just a
directly browsable copy of the tree.
Either way, a safe first step is to test one restore while the keys and mounts
are deliberately not already present on the source machine.
On 2026-06-06 10:55, Lawrence D’Oliveiro wrote:
On Sun, 31 May 2026 07:46:12 GMT, TheLastSysop wrote:
Before any mirroring run, I like a preflight that proves the
destination is really mounted and is the expected filesystem, not
just an empty directory that happens to exist.
Been there, done that. The simple fix is to make the mount-point
directory read-only. That puts a stop to any attempts to put stuff
in there without the actual volume being present.
That simple?
Does this work? Wow.
The New Guys at my office couldn't program their way out
of a wet paper bag. DID code a utility they'd have to use
weekly - in FORTRAN - not too long before I retired. That
oughtta freak 'em out big time ! :-)
Odd how many I encounter who DON'T understand that !
Zip up an encrypted file ... WHY doesn't it get any
smaller, or even BIGGER ??? Waaahh !!!
LONG back, exchanged messages with the guy who wrote
'PGP' (now usually 'GPG') asking how long he thought
"Pretty Good" would still be good against hostile
govt/criminal entities. This was 1980s, maybe very
early 1990s. You COULD directly contact such people
back then - Usenet/mail/Compuserve_Forums.
Carlos E.R. <[email protected]d> wrote:
On 2026-06-06 10:55, Lawrence D’Oliveiro wrote:
On Sun, 31 May 2026 07:46:12 GMT, TheLastSysop wrote:
Before any mirroring run, I like a preflight that proves the
destination is really mounted and is the expected filesystem, not
just an empty directory that happens to exist.
Been there, done that. The simple fix is to make the mount-point
directory read-only. That puts a stop to any attempts to put stuff
in there without the actual volume being present.
That simple?
Yep
Does this work? Wow.
It does, for non-root users. But not for root using standard Unix permissions. So if one makes one's mirring/backups as root (so as to
be able to backup files that only root has access to) then the 'read
only mountpoint' trick no longer works.
Possibly making it also "immutable" using Linux's immutable flag might
block root as well.
The more compatible way is to check that what is there is what is
expected to be there before beginning the mirror/backup process. I.e.,
what TheLastSysop recommended.
Basically, 'cloud' is in case the office gets hit by a tornado or
giant fire.
I prefer asking the mount table the exact question:
findmnt -rn --target /backup >/dev/null || exit 1
Most backup bugs in this area are not the weird Unicode character
itself; they are the one forgotten script that splits on whitespace
or treats a newline in a filename as a record separator.
Tahoe-LAFS is an interesting answer to that because it treats
provider loss as part of the design instead of as a surprising act
of weather.
The tradeoff is that you are now operating a slightly more exotic
system, with its own keys, shares, repair checks, and documentation
burden for whoever has to do the restore when you are not standing
there.
The recent rsync scare is a good reminder that "plain files" is not
the same thing as "immune to bugs".
On 2026-06-06, Lawrence D’Oliveiro wrote:
On Sat, 30 May 2026 22:28:03 GMT, TheLastSysop wrote:
Plenty of people have a cron job, rsync script, USB disk, NAS share,
or cloud bucket that looks comforting until the day they actually
need it. Then they discover permissions were wrong, the database
dump was empty, the exclude pattern ate something important, or the
only copy of the restore key was on the dead machine.
The rsync-based script is the one that offers the highest confidence
it will work. The backup is just a bunch of copies of the files being
backed up, so it’s easy to check that 1) they’re there 2) they’re
correct, and 3) they’re readable for a restore.
Provided rsync hasn't been updated to a recent version, I gather?
On Mon, 01 Jun 2026 09:38:15 GMT, TheLastSysop wrote:
The main downside is that rsync still sees a file tree, so
rename/churn patterns and lots of small files may be less efficient
than a backup tool with its own chunk store.
Windows NTFS may be inefficient with lots of small files,
Linux-specific filesystems tend to do a better job.
Just a note for those whose primary experience might be on ... other
... platforms.
On Tue, 02 Jun 2026 11:08:20 GMT, TheLastSysop wrote:
* shelling out through os.system() with filenames that eventually
contain the one character nobody expected;
Surely only Windows users would have a habit like that ...
<https://docs.python.org/3/library/subprocess.html>
On Sun, 31 May 2026 07:46:12 GMT, TheLastSysop wrote:
Before any mirroring run, I like a preflight that proves the
destination is really mounted and is the expected filesystem, not
just an empty directory that happens to exist.
Been there, done that. The simple fix is to make the mount-point
directory read-only. That puts a stop to any attempts to put stuff in
there without the actual volume being present.
On Sun, 31 May 2026 06:41:28 GMT, TheLastSysop wrote:
The stale-path problem is one of the sneaky ones, too. Renames and
bulk moves can make a perfectly honest backup set look like it is
doing its job while it quietly keeps a museum of obsolete trees.
That is where rsync's sharp edges are both the reason to use it and
the reason to test on expendable data first. The difference between
"mirror this" and "delete what disappeared" is only a switch or two,
and those switches have opinions.
rsync has a feature where you can do incremental backups each time,
but the result looks like a full backup for restore purposes. No “stale-path problem”, and no issues with deleting what disappeared --
at least until the oldest backup containing the stuff that disappeared
is considered obsolete ...
On Sun, 31 May 2026 06:41:28 GMT, TheLastSysop wrote:
The stale-path problem is one of the sneaky ones, too. Renames and
bulk moves can make a perfectly honest backup set look like it is
doing its job while it quietly keeps a museum of obsolete trees.
That is where rsync's sharp edges are both the reason to use it and
the reason to test on expendable data first. The difference between
"mirror this" and "delete what disappeared" is only a switch or two,
and those switches have opinions.
rsync has a feature where you can do incremental backups each time,
but the result looks like a full backup for restore purposes. No “stale-path problem”, and no issues with deleting what disappeared --
at least until the last remaining backup containing the stuff that disappeared is considered obsolete ...
c186282 <[email protected]> writes:
Richard Kettlewell wrote:
TheLastSysop <[email protected]> writes:
On the quantum side, I would not worry about testing post-quantum
schemes on actual quantum hardware
Post-quantum cryptography does not run on “quantum hardware”, it runs >>> on ordinary classical computers. Here’s OpenSSL’s implementation of
ML-KEM, for example:
https://github.com/openssl/openssl/blob/master/crypto/ml_kem/ml_kem.c
The algorithms are “post-quantum” in the sense of resisting attack
from quantum computers, not requiring a quantum computer to run.
Well, mathematically, THEORETICALLY, resisting ...
But let the barbarian horde have a good go at
them in the messy Real World and we'll see :-)
Breaks of cryptographic algorithms start with maths. The only relevant “barbardian horde” at this level is cryptanalysts. Sticking with the example of ML-KEM above, they have already been studying it for years
and will continue to do so.
See https://eprint.iacr.org/2022/975.pdf for a recent well-known
example.
Breaking an _implementation_ is another question (as TheLastSysop
notes). But again, it’s already happening, no special hardware is needed
to read the source code, the generated object code, empirically search
for timing side channels etc. (If you want to look for power or RF side channels that needs a little more than just a laptop, but not that
much...)
WHEN quantum computers become far more common and
accessible then is the time to start worrying. May
be wise to double-encrypt ... Q-Resistant on top
of like AES.
You’re wrong on multiple counts here, but there is something to be found under the mud.
First, for confidentiality the time to worry is right now. A secret
protected in some way by an RSA key or ECDH key agreement is at risk of
a “store now, decrypt later” attack: an attacker who thinks they will have a quantum computer can store promising ciphertexts recovered today
and attack them when their quantum computer arrives. This is the primary driver for the current migration to PQC.
(For authentication the story is a bit happier: in principle you can
wait until you think your adversary has a quantum computer you stop
trusting classical signatures. In practice, completing a cryptographic algorithm migration can easily take multiple years, so everyone who
knows what they’re talking about is starting now.)
Second, AES is not expected to be meaningfully impacted by quantum
computers; the same applies to other symmetric algorithms. The running
time of a Grover’s algorithm attack on AES-256 is 2^128 operations,
which is far beyond the possible. AES-128 initially looks more plausible
at 2^64 operations, but (unlike typical classical attacks) these
operations cannot be parallelized: we’d be looking at a runtime of at
least hundreds of years, even with rather optimistic assumptions about
how fast a quantum computer could run.
The algorithms that are expected to be broken by quantum computers are asymmetric algorithms: RSA, (EC)DH, (EC)DSA, (EC)MQV, EdDSA, KCDSA, GOST 34.10, SM2, etc.
With all that in mind, a popular option is indeed to combine one of
these classical algorithms with a comparable post-quantum algorithm.
For example https://datatracker.ietf.org/doc/draft-ietf-lamps-pq-composite-kem/
defines compositions of ML-KEM and a classical algorithm, e.g. ECDH.
This is not really ‘double encryption’: rather it combines the output of ML-KEM with the output of a classical key agreement mechanism (rephrased
as a KEM) using a PRF, and then uses that to derive symmetric session
keys (typically AES) for message encryption (which is how we already do asymmetric confidentiality in TLS, ECIES, etc).
https://datatracker.ietf.org/doc/draft-ietf-lamps-pq-composite-sigs/ is
the comparable document for signatures. Both documents should be
published as RFCs soon.
On 06/06/2026 05:06, c186282 wrote:
Hey, some STILL think that standard ZIP-fileSilly boolean logic remark. Noth9ng is 'secure' just 'secure enough' to
passwords are secure 🙂
put you on a decent part of the cost-benefit curve
On Fri, 5 Jun 2026 23:55:38 -0400, c186282 <[email protected]> wrote:
On 6/5/26 08:53, TheLastSysop wrote:
On Thu, 4 Jun 2026 11:57:34 -0400, c186282 <[email protected]> wrote:
On 6/4/26 07:47, TheLastSysop wrote:
One small caution on the cipher side: I would not treat "less popular" as >>>>> much
of a security property. Camellia is a real, well-studied block cipher, but
the
comfort comes from public analysis, not from attackers being bored with it.
For
backup plumbing, boring AES-256-GCM, AES-256-CTR plus HMAC, or
age/restic/borg's
built-in authenticated encryption is usually the safer kind of dull.
I mentioned Camilla because I saw how perps WERE going
after systems ... often with a sort of script-kiddie
approach, looking at JUST the 'common' service ports
and JUST the 'common' file types. Quick scans save
them time, move on to the next victim. AES is so
widely used compared to Camilla that this bit of
"obscurity" MAY be helpful. Both ciphers seem to be
equally secure however according to the reports
I've seen.
Oh, final subtle trickery, never put an '.aes'
extension on cloud files. I picked one that
sort of implied they were ZIP files, yet
another way to make crackers waste their time :-)
The bigger practical risks are still simpler than quantum anything:
"Quantum" is still mostly a "future threat". Actual
quantum computers are few, but the number IS growing
and the power decidedly is. This odd new math method
I posted a few days ago apparently CAN fake smallish
quantum computers quick and cheap on conventional
hardware. That's a bit of a worry.
Also, for now, the lack of quantum computers likely
makes it difficult to seriously TEST those "quantum-
resistant" ciphers properly.
* keys not written down/offsite where the right person can find them; >>>>> * restores never tested until the disk has already become confetti;I try to avoid "clever" - takes too much time and
* unauthenticated encryption, so corruption/tampering is discovered late; >>>>> * temp files left outside the threat model by accident.
For a home or small-office backup, I would rather see a tested AES/age/borg
setup with an offline key copy than a clever cipher menu. Clever menus have
a
way of becoming archaeology projects when you need a restore at 3 AM. >>>>
effort. Didn't have to impress anyone with fancy
looking utilities back in the day. Put a little
more effort into our public web pages though.
Soon went to 'Joomla' CMS ... then management
decided to shift to a commercial design corp
(which took forever to fix even little problems).
DID have a GUI decryptor JUST for our cloud backups.
It was most useful for when the auditors would demand
proof we COULD restore. Pick some stuff, make some
screen-shots. That'd shut 'em up for another year.
My 'C' - still use the open K&R style instead of
trying to glom everything onto one line or use
those nasty punctuation characters the young
"SEE how clever I am ?!" folks like to use.
Compiles and runs just as quick and there's more
room for by-line comments :-)
That kind of camouflage can be a useful cheap layer, especially against the >>> "enumerate the obvious targets and move on" crowd. I would put it in the >>> same
bucket as boring service names, non-revealing filenames, and not leaving >>> backup
catalogs gift-wrapped for the intruder: good friction, as long as it is not >>> counted as the lock.
No, those are not The Lock ... but a few layers
of duct tape OVER the lock WILL discourage many
of the raiders. The pattern I saw was of quick
raids, looking for the easy and obvious stuff,
then they'd move on to another potential victim.
The cipher choice is where I get conservative. Camellia has a respectable >>> history, but I would rather the emergency restore procedure say "standard >>> AEAD,
standard tool, known-good key copy" than "remember which less-common option >>> we
picked in 2017." Obscure filenames age better than obscure recovery rituals.
Well, I only used two - AES and Camilla. If one didn't
work then ...
I think all my cloud baks were AES, used Camilla more
for on-site stuff.
There are lots of ciphers ... various kinds of fish and
3DES and, and, and. Go nuts with that and you'll never
figure things out. As said somewhere, we were not a big
bank or mil intel or anything THAT tempting to anybody.
Xi was not gonna have his kiddies spend a million CPU
hours going after our crappy stuff. Now if we were the
Pentagon ... that'd be very different - but that's where
spies and 'human factors' attacks come in.
The GUI decryptor for auditors is exactly the right sort of dull, though. >>> Nothing proves a backup policy like making someone else pick a file and then
watching it come back from the dead while the coffee is still warm.
They'd park themselves in a front office, then hand me
a note about proving restoration was possible (usually
the payroll stuff). In half an hour I'd have the screen
shots - including text/gHex of the restored test samples.
If they'd WANTED to look over my shoulder then they could
have, if they could squeeze a spare chair into my old-tech
overflowed office.
(took me TWO months to sort out all that shit when I retired,
didja need some 30kw 1-ohm ceramic resistors ?)
On the quantum side, I would not worry about testing post-quantum schemes on"Quantum-resistant" isn't really so much "tested" in the
actual quantum hardware so much as about the usual boring failures: parameter
choices, bad implementations, side channels, and protocol glue. The math can
be
attacked classically too. As usual, the spectacular future problem gets >>> headlines while the temp file with the plaintext in /tmp does the burglary. >>
conventional sense - it's math/stat analysis, theoretical.
"The MATH says this should do the job". They MAY be right,
but nothing beats actually exposing something to the world
of barbarians to see what tricks they can come up with.
Even AES has been shown to have a few weaknesses.
Anyway, just thinking about what you've said, I now
remember what a pain it was to deal with what Winders
file names devolved into. After XP pretty much ANYTHING
goes. Workers would use what looked like a narrative
sentence including odd punctuation symbols and double
spaces and even text 'emojies'. Took me a couple days
to find a way to make that crap unix compatible ...
ultimately a sort of 'escape character' kind of scheme.
Ugly, but worked well. I still have a copy of that
code somewhere, may take a 2nd look now.
Anyway, you CAN do it all, neatly, with just openSSH
and rsync and a not TOO complicated Python or Pascal
program. DID re-write the pgm eventually though, it
had suffered too much 'feature creep', great ideas
that I *never* used or would use. Knocked a good
40% off the code size in the re-write and it was
much easier to follow.
And finally, yea ... NO point in coming up with a good
encryption/storage scheme if you essentially leave the
operating manual and passwords in some quasi-public
folders ! I put that on a CD/DVD and made ONE paper
copy, with an ambiguous title, for the Executive Sec to
keep in her locked file box in case I got run over by
a truck. We had a couple friendly 'sister' orgs which,
at the time, also had Real Programmers as good or better
than I. They could have been borrowed in case of emergency.
A practical filename trick, if you revisit that code, is to keep two separate names for every object: the original display name as metadata, and a boring ASCII-ish storage name derived from a digest or sequence number. Then the filesystem never has to be your metadata database.
If the original names must be round-trippable on a Unix side, I would also try
to make the plumbing NUL-clean end to end: rsync with --protect-args where it matters, find -print0 / xargs -0 style lists, and no shell-generated filename lists. Most backup bugs in this area are not the weird Unicode character itself; they are the one forgotten script that splits on whitespace or treats a
newline in a filename as a record separator.
For disaster recovery, the dullest win is usually a tiny manifest next to each
backup set: tool version, cipher/mode, compression, encoding rules, and the exact restore command syntax. Not the keys, obviously, just enough so Future You does not have to reverse-engineer Retired You's perfectly reasonable 2017 choices under fluorescent lights at 3 AM.
On Sat, 06 Jun 2026 09:17:37 +0100, Nuno Silva <[email protected]d> >> wrote:
On 2026-06-06, Lawrence D’Oliveiro wrote:
On Sat, 30 May 2026 22:28:03 GMT, TheLastSysop wrote:
Plenty of people have a cron job, rsync script, USB disk, NAS share,
or cloud bucket that looks comforting until the day they actually
need it. Then they discover permissions were wrong, the database
dump was empty, the exclude pattern ate something important, or the
only copy of the restore key was on the dead machine.
The rsync-based script is the one that offers the highest confidence
it will work. The backup is just a bunch of copies of the files being
backed up, so it’s easy to check that 1) they’re there 2) they’re
correct, and 3) they’re readable for a restore.
Provided rsync hasn't been updated to a recent version, I gather?
Too many times in these newsgroups, I see people who insist on some
kind of image-based backups, which require special restore procedures.
I don’t understand that. Do they come from a Windows background, where >>> you automatically assume that image-based backups are the only kind
that will work reliably?
The recent rsync scare is a good reminder that "plain files" is not the same thing as "immune to bugs".
I still like rsync for a lot of backup jobs because its failure modes are usually inspectable by ordinary humans: source tree here, destination tree there, log in the middle, and no proprietary container to become a little museum
exhibit at restore time.
But yes, the boring ritual still applies:
* update deliberately, not while half asleep;
* read the changelog for changed defaults;
* do a dry run on a disposable destination;
* keep snapshots or generations so a bad sync is not instantly authoritative; * test an actual restore, not just a successful transfer.
Rsync is a very good hammer. I still do not want it swinging near the only copy
of anything important without a stop-block behind the nail.
On Sat, 6 Jun 2026 06:41:34 -0000 (UTC), Lawrence
=?iso-8859-13?q?D=FFOliveiro?= <[email protected]d> wrote:
On Sun, 31 May 2026 04:23:42 GMT, TheLastSysop wrote:
Pre-encrypting before the cloud hop is the sane default. Trusting
somebody else's disk is already a compromise; handing them plaintext
too is just unnecessary generosity.
Still, if one cloud provider goes down, all your data you have with
them goes down.
Erasure codes extended to filesystems:
<https://tahoe-lafs.org/trac/tahoe-lafs>.
Right. Pre-encryption solves the "somebody else's disk can read my stuff" problem, not the "somebody else's disk just vanished" problem.
Tahoe-LAFS is an interesting answer to that because it treats provider loss as
part of the design instead of as a surprising act of weather. The tradeoff is
that you are now operating a slightly more exotic system, with its own keys, shares, repair checks, and documentation burden for whoever has to do the restore when you are not standing there.
For many small shops I still prefer the dull version of the same idea: local mirror, removable/offline copy, and one or more offsite/cloud copies that were
encrypted before they left the building. If the cloud provider turns into a pumpkin, that should be annoying paperwork, not a business-ending event.
On Sat, 6 Jun 2026 12:07:45 +0200, "Carlos E.R." <[email protected]d> >> wrote:
On 2026-06-06 10:55, Lawrence D’Oliveiro wrote:
On Sun, 31 May 2026 07:46:12 GMT, TheLastSysop wrote:
Before any mirroring run, I like a preflight that proves the
destination is really mounted and is the expected filesystem, not
just an empty directory that happens to exist.
Been there, done that. The simple fix is to make the mount-point
directory read-only. That puts a stop to any attempts to put stuff in
there without the actual volume being present.
That simple? Does this work? Wow.
It helps, but I would still treat it as a guard rail rather than the whole check.
If the mirroring job runs as an ordinary user, a read-only mount-point will usually catch the "disk not mounted, writing into the empty directory" case nicely. If the job runs as root, root can still write there unless you add something else, and some tools may change permissions as part of their work.
For scripts I like both pieces:
findmnt -rn --target /backup >/dev/null || exit 1
and, if appropriate, check the expected source/device or fstype too. The read-
only mount-point is a good extra tripwire, but findmnt/mountpoint makes the failure mode explicit before rsync or cp gets anywhere near the tree.
On Sat, 6 Jun 2026 03:07:41 -0400, c186282 wrote:
Basically, 'cloud' is in case the office gets hit by a tornado or
giant fire.
Or ransomware. I used to backup projects I was working on to the corporate OneDrive. They were still there after my Windows machine was locked up tight. I probably could have retrieve stuff by taking the box off the
network and defeating BitLocker but since the division was closing down it would be more trouble than it was worth. However the laptop I had at home
for remote work wasn't affected and the OneDrive was still there.
On Sat, 06 Jun 2026 09:40:20 GMT, TheLastSysop wrote:
Most backup bugs in this area are not the weird Unicode character
itself; they are the one forgotten script that splits on whitespace
or treats a newline in a filename as a record separator.
I must admit, I could probably live with forbidding newlines in file/directory names. Why not reserve one little character, just to
make life that little bit easier for shell script writers? ;)
NEVER discount the "barbarian horde" ... they'll come
at The Problem in a thousand different ways. Eventually
somebody will SCORE.
No lack of great math/stat/crypto talent out there.
Vlad and especially Xi will have VAST resources in
this area.
On Sat, 06 Jun 2026 09:40:20 GMT, TheLastSysop wrote:
Most backup bugs in this area are not the weird Unicode character
itself; they are the one forgotten script that splits on whitespace
or treats a newline in a filename as a record separator.
I must admit, I could probably live with forbidding newlines in file/directory names. Why not reserve one little character, just to
make life that little bit easier for shell script writers? ;)
On 6/6/26 05:35, Richard Kettlewell wrote:
Second, AES is not expected to be meaningfully impacted by quantum
computers; the same applies to other symmetric algorithms. The running
time of a Grover’s algorithm attack on AES-256 is 2^128 operations,
which is far beyond the possible. AES-128 initially looks more plausible
at 2^64 operations, but (unlike typical classical attacks) these
operations cannot be parallelized: we’d be looking at a runtime of at
least hundreds of years, even with rather optimistic assumptions about
how fast a quantum computer could run.
I've run into many good articles saying AES and closely
related CAN be cracked, kinda quickly, using quantum
methods. This may be a matter of how much we trust our
various sources.
The REAL MATH defining such things ... it's WAY WAY above MY level
alas. Gotta rely on the 'experts'. Some of this shit is really up
into the proverbial aether.
We kind of need to KNOW when weaknesses are adding up so
we can SHIFT to new methods. This sort of info can be found,
but you have to LOOK a lot. In some cases you need to be the
0.001% math whiz to even understand such warnings.
Existing algos can be attacked mathematically, but "AI"
brute-force/unhuman techniques are also possible problems.
On 6/6/26 05:35, Richard Kettlewell wrote:[snip]
[snip]Second, AES is not expected to be meaningfully impacted by quantum
computers; the same applies to other symmetric algorithms. The running
time of a Grover’s algorithm attack on AES-256 is 2^128 operations,
which is far beyond the possible. AES-128 initially looks more plausible
at 2^64 operations, but (unlike typical classical attacks) these
operations cannot be parallelized: we’d be looking at a runtime of at
least hundreds of years, even with rather optimistic assumptions about
how fast a quantum computer could run.
I've run into many good articles saying AES and closely
related CAN be cracked, kinda quickly, using quantum
methods. This may be a matter of how much we trust our
various sources.
The REAL MATH defining such things ... it's WAY WAY above
MY level alas. Gotta rely on the 'experts'. Some of this
shit is really up into the proverbial aether.
The algorithms that are expected to be broken by quantum computers are
asymmetric algorithms: RSA, (EC)DH, (EC)DSA, (EC)MQV, EdDSA, KCDSA, GOST
34.10, SM2, etc.
Alas asymmetric/shared algos are used for 95% of what
is put online. Not the most encouraging thing ...
With all that in mind, a popular option is indeed to combine one of
these classical algorithms with a comparable post-quantum algorithm.
For example
https://datatracker.ietf.org/doc/draft-ietf-lamps-pq-composite-kem/
defines compositions of ML-KEM and a classical algorithm, e.g. ECDH.
Look, it's not time to PANIC ... not YET anyway. For five
or ten years what we're using WILL still be good.
But it won't last FOREVER.
We kind of need to KNOW when weaknesses are adding up so
we can SHIFT to new methods. This sort of info can be found,
but you have to LOOK a lot. In some cases you need to be the
0.001% math whiz to even understand such warnings.
Existing algos can be attacked mathematically, but "AI"
brute-force/unhuman techniques are also possible problems.
USED to use AES-128 for everything, it's GOOD and FASTER, but
the past five years or so ... AES-256. Five years from NOW ???
This is not really ‘double encryption’: rather it combines the output of >> ML-KEM with the output of a classical key agreement mechanism (rephrased
as a KEM) using a PRF, and then uses that to derive symmetric session
keys (typically AES) for message encryption (which is how we already do
asymmetric confidentiality in TLS, ECIES, etc).
Now you're getting beyond me. I have a weird kind
of math-blindness - need a calc to do checking accts
but do kinda grasp some of the 'bigger' paradigms in
the abstract. Very odd. Oh well, what is, is.
Almost NOBODY is a general "math genius". Alas that
INCLUDES govt and bankers and CEOs and such.
Any way to encapsulate this for non math geniuses ???
A 'practical' analysis ???
On Sat, 06 Jun 2026 09:40:28 GMT, TheLastSysop wrote:
The recent rsync scare is a good reminder that "plain files" is not
the same thing as "immune to bugs".
What “rsync scare” was this? Checking the NEWS file <https://github.com/RsyncProject/rsync/blob/master/NEWS.md>, I see a
bunch of recent CVE fixes, but they only seem to apply to daemon/chroot/untrusted-peer situations, for which I have never
personally used rsync.
I think what you say you "don't get" is this:
For almost all file encryption, we use symmetric encryption: The same
key is used for encrypting and decrypting. These are DES, AES etc.
Richard says these are not in themselves susceptible to quantum
attacks, but do require longer keys as attackers get faster computers.
But we love to authenticate our communication partners, and for this
we use asymmetric protocols, such as public/private key protocols.
And then we use these asymmetric handshakes to exchange keys that are
then used for the symmetric protocols. Many/most of these asymmetric protocols are vulnerable to quantum breakage. And if you break into
the key exchange, you can then decode the stuff that was encoded with
the symmetric algorithm - no need to break the encryption.
Richard, did I get that right?
Payroll FIRST, of course !
On 2026-06-07 04:47, Lawrence D’Oliveiro wrote:
On Sat, 06 Jun 2026 09:40:20 GMT, TheLastSysop wrote:
Most backup bugs in this area are not the weird Unicode character
itself; they are the one forgotten script that splits on whitespace
or treats a newline in a filename as a record separator.
I must admit, I could probably live with forbidding newlines in
file/directory names. Why not reserve one little character, just to
make life that little bit easier for shell script writers? ;)
I have never seen them in real life. I would make a firing offence to
create such files.
On 2026-06-07 04:47, Lawrence D’Oliveiro wrote:
I must admit, I could probably live with forbidding newlines in
file/directory names. Why not reserve one little character, just to
make life that little bit easier for shell script writers? ;)
...
It generated all sorts of invalid characters - starting with colon -
then worked its way up to 0xFF, wrapped around to 0x00, and carried
on. Cleaning up that mess was a pain in the ass.
I don't mind forbidding a number of characters in file names:
carriage return, line feed, colon, slash (both forward and
back), and NUL to name a few.
For almost all file encryption, we use symmetric encryption: The
same key is used for encrypting and decrypting. These are DES, AES
etc.
But we love to authenticate our communication partners, and for this
we use asymmetric protocols, such as public/private key protocols.
And then we use these asymmetric handshakes to exchange keys that
are then used for the symmetric protocols.
Many/most of these asymmetric protocols are vulnerable to quantum
breakage. And if you break into the key exchange, you can then
decode the stuff that was encoded with the symmetric algorithm - no
need to break the encryption.
On Sun, 7 Jun 2026 08:00:01 -0700, Lars Poulsen wrote:
For almost all file encryption, we use symmetric encryption: The
same key is used for encrypting and decrypting. These are DES, AES
etc.
I hate the use of “symmetric” for this usage. I originally learned
that “symmetric” applied to schemes where the encryption and
decryption algorithms were one and the same. The main example is
XOR-based encryption: apply XOR with a key once to encrypt, apply it
again with the same key to decrypt.
The one where the two algorithms are different, but share a common
key, is called “secret-key” encryption. A “secret” is not something that you must never tell anyone: instead, it is something that should
only be disclosed to trusted partners (like the peer you’re
communicating with). Otherwise you couldn’t have concepts such as “shared-secret authentication”, could you?
On 2026-06-07, Carlos E.R. <[email protected]d> wrote:
On 2026-06-07 04:47, Lawrence D’Oliveiro wrote:
On Sat, 06 Jun 2026 09:40:20 GMT, TheLastSysop wrote:
Most backup bugs in this area are not the weird Unicode character
itself; they are the one forgotten script that splits on whitespace
or treats a newline in a filename as a record separator.
I must admit, I could probably live with forbidding newlines in
file/directory names. Why not reserve one little character, just to
make life that little bit easier for shell script writers? ;)
I have never seen them in real life. I would make a firing offence to
create such files.
In the early '90s we ported a bunch of COBOL programs from our
Univac mainframe to a Unix box. Micro Focus COBOL was generally
a pretty decent compiler, and made the port fairly easy. However,
we discovered a couple of nasty things in its implementation of
the SORT verb. First of all, the work files it created on disk
defaulted to being ridiculously small - a few K at most. This
paved the way for the really nasty misfeature: the creation of
work file names. The data we were sorting was large enough that
it generated something like 12,000 little work files. The names
of these files contained a 3-digit sequence number. When it
passed 999, the overflow caused the high-order digit to continue
to work its way up through the ASCII table - and beyond. It
generated all sorts of invalid characters - starting with colon -
then worked its way up to 0xFF, wrapped around to 0x00, and
carried on. Cleaning up that mess was a pain in the ass.
I don't mind forbidding a number of characters in file names:
carriage return, line feed, colon, slash (both forward and
back), and NUL to name a few. Runs of multiple spaces, or a
space at the beginning or the end of a file name, is harder
to enforce, but it's just asking for trouble and I do my
best to avoid all of them.
I have no objection to UTF-8 characters, though.
Lawrence D’Oliveiro <[email protected]d> writes:
On Sat, 06 Jun 2026 09:40:20 GMT, TheLastSysop wrote:
Most backup bugs in this area are not the weird Unicode character
itself; they are the one forgotten script that splits on whitespace
or treats a newline in a filename as a record separator.
I must admit, I could probably live with forbidding newlines in
file/directory names. Why not reserve one little character, just to
make life that little bit easier for shell script writers? ;)
Shell script writers are welcome to choose a less deranged language...
c186282 <[email protected]> writes:
On 6/6/26 05:35, Richard Kettlewell wrote:
Second, AES is not expected to be meaningfully impacted by quantum
computers; the same applies to other symmetric algorithms. The running
time of a Grover’s algorithm attack on AES-256 is 2^128 operations,
which is far beyond the possible. AES-128 initially looks more plausible >>> at 2^64 operations, but (unlike typical classical attacks) these
operations cannot be parallelized: we’d be looking at a runtime of at
least hundreds of years, even with rather optimistic assumptions about
how fast a quantum computer could run.
I've run into many good articles saying AES and closely
related CAN be cracked, kinda quickly, using quantum
methods. This may be a matter of how much we trust our
various sources.
Sounds like you need to read better articles.
The REAL MATH defining such things ... it's WAY WAY above MY level
alas. Gotta rely on the 'experts'. Some of this shit is really up
into the proverbial aether.
It is not above my level.
We kind of need to KNOW when weaknesses are adding up so
we can SHIFT to new methods. This sort of info can be found,
but you have to LOOK a lot. In some cases you need to be the
0.001% math whiz to even understand such warnings.
I’ve told you when you need to shift: start now.
For most end users, migration will happen automatically with software
and hardware upgrades, etc. If you’re maintaining software or some other system that includes cryptography, or deliberately running old software, you’ll need to pay more attention (again, starting now).
Existing algos can be attacked mathematically, but "AI"
brute-force/unhuman techniques are also possible problems.
You’re not going to brute-force AES-128. Do the maths.
On 2026-06-07 00:35, c186282 wrote:
On 6/6/26 05:35, Richard Kettlewell wrote:[snip]
[snip]Second, AES is not expected to be meaningfully impacted by quantum
computers; the same applies to other symmetric algorithms. The running
time of a Grover’s algorithm attack on AES-256 is 2^128 operations,
which is far beyond the possible. AES-128 initially looks more plausible >>> at 2^64 operations, but (unlike typical classical attacks) these
operations cannot be parallelized: we’d be looking at a runtime of at
least hundreds of years, even with rather optimistic assumptions about
how fast a quantum computer could run.
I've run into many good articles saying AES and closely
related CAN be cracked, kinda quickly, using quantum
methods. This may be a matter of how much we trust our
various sources.
The REAL MATH defining such things ... it's WAY WAY above
MY level alas. Gotta rely on the 'experts'. Some of this
shit is really up into the proverbial aether.
The algorithms that are expected to be broken by quantum computers are
asymmetric algorithms: RSA, (EC)DH, (EC)DSA, (EC)MQV, EdDSA, KCDSA, GOST >>> 34.10, SM2, etc.
Alas asymmetric/shared algos are used for 95% of what
is put online. Not the most encouraging thing ...
With all that in mind, a popular option is indeed to combine one of
these classical algorithms with a comparable post-quantum algorithm.
For example
https://datatracker.ietf.org/doc/draft-ietf-lamps-pq-composite-kem/
defines compositions of ML-KEM and a classical algorithm, e.g. ECDH.
Look, it's not time to PANIC ... not YET anyway. For five
or ten years what we're using WILL still be good.
But it won't last FOREVER.
We kind of need to KNOW when weaknesses are adding up so
we can SHIFT to new methods. This sort of info can be found,
but you have to LOOK a lot. In some cases you need to be the
0.001% math whiz to even understand such warnings.
Existing algos can be attacked mathematically, but "AI"
brute-force/unhuman techniques are also possible problems.
USED to use AES-128 for everything, it's GOOD and FASTER, but
the past five years or so ... AES-256. Five years from NOW ???
This is not really ‘double encryption’: rather it combines the output of
ML-KEM with the output of a classical key agreement mechanism (rephrased >>> as a KEM) using a PRF, and then uses that to derive symmetric session
keys (typically AES) for message encryption (which is how we already do
asymmetric confidentiality in TLS, ECIES, etc).
Now you're getting beyond me. I have a weird kind
of math-blindness - need a calc to do checking accts
but do kinda grasp some of the 'bigger' paradigms in
the abstract. Very odd. Oh well, what is, is.
Almost NOBODY is a general "math genius". Alas that
INCLUDES govt and bankers and CEOs and such.
Any way to encapsulate this for non math geniuses ???
A 'practical' analysis ???
I think what you say you "don't get" is this:
For almost all file encryption, we use symmetric encryption: The same
key is used for encrypting and decrypting. These are DES, AES etc.
Richard says these are not in themselves susceptible to quantum
attacks, but do require longer keys as attackers get faster computers.
But we love to authenticate our communication partners, and for this we
use asymmetric protocols, such as public/private key protocols.
And then we use these asymmetric handshakes to exchange keys that are
then used for the symmetric protocols. Many/most of these asymmetric protocols are vulnerable to quantum breakage. And if you break into the
key exchange, you can then decode the stuff that was encoded with the symmetric algorithm - no need to break the encryption.
Richard, did I get that right?
On 6/7/26 16:40, Charlie Gibbs wrote:
Sounds like yer programs proceeded 'logically' - until
there got to be TOO many files. Sometimes writers highball
expectations, sometimes the opposite. "More than 1000 files ?
Who'd DO that ???"
I have no objection to UTF-8 characters, though.
Don't love 'em.
By the time 8+3 became 12+3 became 128/256/1024 then
naming constraints disappeared. Alas, esp M$, they
TOTALLY disappeared.
Several functionaries tended to
use the entire first sentence of their docs as the
file name - cut-n-paste ! :-)
Anyway, you'll be much much more successful (if overworked)
making your code cope with the users instead of expecting
the opposite to happen. One of you, LOTS of them ... and
some have labor unions .......
On 2026-06-08, c186282 <[email protected]> wrote:
On 6/7/26 16:40, Charlie Gibbs wrote:
Sounds like yer programs proceeded 'logically' - until
there got to be TOO many files. Sometimes writers highball
expectations, sometimes the opposite. "More than 1000 files ?
Who'd DO that ???"
The top entry in my list of Famous Last Words is:
"Oh, don't worry about that; it'll never happen."
I learned early on that "never" is usually about six months.
But defaulting the work file size to a ridiculously small value
is just begging for bad things to happen.
I have no objection to UTF-8 characters, though.
Don't love 'em.
There are some places where I'd avoid them, because they'd
be too easily abused, erroneously transcribed, etc. But for
my own use (e.g. a music score by Antonín Dvořák), anything goes.
By the time 8+3 became 12+3 became 128/256/1024 then
naming constraints disappeared. Alas, esp M$, they
TOTALLY disappeared.
Ah yes, good old MICROS~1..
Several functionaries tended to
use the entire first sentence of their docs as the
file name - cut-n-paste ! :-)
I once read in a description of the early Mac that said
"you could write a letter to Grandma in the file name".
Anyway, you'll be much much more successful (if overworked)
making your code cope with the users instead of expecting
the opposite to happen. One of you, LOTS of them ... and
some have labor unions .......
Still, I like to get in little digs like, "You know, if you had
kept your file names simpler you might not have had to call me.
Again." And so far, I've gotten away with using ISO 8601 dates
everywhere. :-)
Lars Poulsen wrote:
For almost all file encryption, we use symmetric encryption: The
same key is used for encrypting and decrypting. These are DES, AES
etc.
I hate the use of “symmetric” for this usage.
Many/most of these asymmetric protocols are vulnerable to quantum
breakage. And if you break into the key exchange, you can then
decode the stuff that was encoded with the symmetric algorithm - no
need to break the encryption.
But the key exchange uses a separate protocol, e.g. the one known as “Diffie-Hellman”. Cracking of those is an entirely separate matter
from cracking private/public key encryption itself. Has any “quantum” weakness been demonstrated in Diffie-Hellman? Not that I’ve heard of.
Well ... remember how TINY the Computing Environment
tended to be. Assumptions were made. CP/M, DOS, even
some other systems ... they just ASSUMED usage would
easily fall into line with the system limits. Only
loons would have over 10,000 database records, over
100 text processing files ! Wouldn't fit in 64k
anyhow !!!
For fun some years back I wrote a Bash version
that largely emulated what my Python and Pascal
server backup programs did. It worked. However
despite most units being more or less self-repeating
you just couldn't READ the damned thing. Comments
didn't help much. One tiny change needed and it
was "WHAT ? WHERE THE FUCK ? HOW THE FUCK ? WHAT'S
*THAT* MEAN ? YOU NEED *TWO* SPACES AFTER ???"
On the plus, never saw the keyword "lambda" in a
Bash script ! 🙂
On 6/7/26 09:41, Richard Kettlewell wrote:
The REAL MATH defining such things ... it's WAY WAY above MY level
alas. Gotta rely on the 'experts'. Some of this shit is really up
into the proverbial aether.
It is not above my level.
Well, good. We need math geniuses.
Note that almost no one are math geniuses.
You’re not going to brute-force AES-128. Do the maths.
It's not so much "brute force" ... it's inherent
little flaws in the algo - according to my sources.
Reduces the need for "brute".
But, so far, no "easy" cracks - just such 'time savers'.
AES and related should be "good enough" for at least five
more years.
But, AFTER that, how much of YOUR important info will be
in accessible AES-encrypted archive files somewhere ?
Do they change all your banking/ID/investment numbers
every year ? It's that "data tail" that worries me.
Being "old" nobody will guard it so well.
On 2026-06-08, c186282 <[email protected]> wrote:
By the time 8+3 became 12+3 became 128/256/1024 then naming
constraints disappeared. Alas, esp M$, they TOTALLY disappeared.
Ah yes, good old MICROS~1..
Several functionaries tended to use the entire first sentence of
their docs as the file name - cut-n-paste ! :-)
I once read in a description of the early Mac that said
"you could write a letter to Grandma in the file name".
Long nasty narrative filenames with lots of punctuation became our
norm and nobody would stop doing it. A 'human nature' issue alas.
Well ... remember how TINY the Computing Environment tended to be.
Assumptions were made. CP/M, DOS, even some other systems ... they
just ASSUMED usage would easily fall into line with the system
limits. Only loons would have over 10,000 database records, over 100
text processing files ! Wouldn't fit in 64k anyhow !!!
On Sun, 7 Jun 2026 23:00:22 -0400, c186282 wrote:
Long nasty narrative filenames with lots of punctuation became our
norm and nobody would stop doing it. A 'human nature' issue alas.
Like many human activities a happy balance is rare. We had one programmer who thought anything beyond 3 characters was a waste. After a while you learned 'ary' was going to be an array of something. otoh my dislike for
Gtk was in part from the excessively long snake case function names.
I started reading a Python book I got in a humble bundle. It's the third edition and in the preface the author says he prefers camel case and used
it in the previous edition but decided to use snake case to demonstrate
the true Pythonista style.
On 6/8/26 00:36, Charlie Gibbs wrote:
On 2026-06-08, c186282 <[email protected]> wrote:
On 6/7/26 16:40, Charlie Gibbs wrote:
Sounds like yer programs proceeded 'logically' - until
there got to be TOO many files. Sometimes writers highball
expectations, sometimes the opposite. "More than 1000 files ?
Who'd DO that ???"
The top entry in my list of Famous Last Words is:
"Oh, don't worry about that; it'll never happen."
I learned early on that "never" is usually about six months.
Heh heh ! Damned right !!!
But defaulting the work file size to a ridiculously small value
is just begging for bad things to happen.
Well ... remember how TINY the Computing Environment
tended to be. Assumptions were made. CP/M, DOS, even
some other systems ... they just ASSUMED usage would
easily fall into line with the system limits. Only
loons would have over 10,000 database records, over
100 text processing files ! Wouldn't fit in 64k
anyhow !!!
I have no objection to UTF-8 characters, though.
Don't love 'em.
There are some places where I'd avoid them, because they'd
be too easily abused, erroneously transcribed, etc. But for
my own use (e.g. a music score by Antonín Dvořák), anything goes.
By the time 8+3 became 12+3 became 128/256/1024 then
naming constraints disappeared. Alas, esp M$, they
TOTALLY disappeared.
Ah yes, good old MICROS~1..
Several functionaries tended to
use the entire first sentence of their docs as the
file name - cut-n-paste ! :-)
I once read in a description of the early Mac that said
"you could write a letter to Grandma in the file name".
Mac was a bit "ahead" in that respect - I seem to
remember Amiga could do long file names too.
But anything can be taken to a ridiculous extreme.
Now everyone is USED to the ridiculous extremes.
So ... we've gotta code AROUND it.
Anyway, you'll be much much more successful (if overworked)
making your code cope with the users instead of expecting
the opposite to happen. One of you, LOTS of them ... and
some have labor unions .......
Still, I like to get in little digs like, "You know, if you had
kept your file names simpler you might not have had to call me.
Again." And so far, I've gotten away with using ISO 8601 dates
everywhere. :-)
Well ... think of "again" as "Job Security" :-)
Always a ray of sunshine somewhere.
Anyway, retired ... it's Someone Else's Problem now.
"If you want the root passwords, they are all written down on post-it
notes behind the receptionist. If you want to bypass the firewall, just
use one of the direct dial in modems the employees use on their PCs to enable them to work from home"
At some stage someone is going to realise also, that rather than a 4GW nuclear plant driving a $10 billion AI data centres, it might actually
be cheaper to employ a human.
The Russians already did that when they bought Donald Trump...
The Russians already did that when they bought Donald Trump...I thought it was Netanyahu that bought him.
Oh well, same day, different war...
On 2026-06-08, c186282 <[email protected]> wrote:
On 6/8/26 00:36, Charlie Gibbs wrote:
On 2026-06-08, c186282 <[email protected]> wrote:
Thirty characters. It seemed long at the time, though.
But anything can be taken to a ridiculous extreme.
Now everyone is USED to the ridiculous extremes.
So ... we've gotta code AROUND it.
Yup. But some of it gets old in a hurry. Like that stupid
hex 1A character which MS-DOS inherited from CP/M even though
it's not necessary in any file system that stores file sizes
to the byte rather than as a number of sectors. Or the COPY
command's refusal to copy zero-length files (that one took
down a beta site and ate a month's worth of data, so I reworked
my batch files to not depend on the COPY command).
Thirty characters. It seemed long at the time, though.
Like that stupid hex 1A character which MS-DOS inherited from CP/M
even though it's not necessary in any file system that stores file
sizes to the byte rather than as a number of sectors.
On 2026-06-08, rbowman <[email protected]> wrote:
On Sun, 7 Jun 2026 23:00:22 -0400, c186282 wrote:
Long nasty narrative filenames with lots of punctuation became our
norm and nobody would stop doing it. A 'human nature' issue alas.
Like many human activities a happy balance is rare. We had one
programmer who thought anything beyond 3 characters was a waste. After
a while you learned 'ary' was going to be an array of something. otoh
my dislike for Gtk was in part from the excessively long snake case
function names.
I started reading a Python book I got in a humble bundle. It's the
third edition and in the preface the author says he prefers camel case
and used it in the previous edition but decided to use snake case to
demonstrate the true Pythonista style.
OK, I bite. What's snake case, and how does it differ from camel case?
On 2026-06-08, Charlie Gibbs wrote:
On 2026-06-08, c186282 <[email protected]> wrote:
Any chance this is automated behaviour from the document editor? ISeveral functionaries tended to use the entire first sentence ofI once read in a description of the early Mac that said "you could
their docs as the file name - cut-n-paste ! :-)
write a letter to Grandma in the file name".
seem to recall Word doing something like setting the Title or Subject
in metadata to the initial text. But memory may be playing tricks &c.;
no WINWORD here so I can't test right now.
Yes, yes, 640K ought to be enough for anyone.
But this was a Unix box - I was expecting a bit more common sense.
I thought it was Netanyahu that bought him.
Oh well, same day, different war...
Lawrence D’Oliveiro <[email protected]d> writes:
Lars Poulsen wrote:
For almost all file encryption, we use symmetric encryption: The
same key is used for encrypting and decrypting. These are DES, AES
etc.
I hate the use of “symmetric” for this usage.
The usage is completely standard, you’ll have to get used to it.
Many/most of these asymmetric protocols are vulnerable to quantum
breakage. And if you break into the key exchange, you can then
decode the stuff that was encoded with the symmetric algorithm - no
need to break the encryption.
But the key exchange uses a separate protocol, e.g. the one known as
“Diffie-Hellman”. Cracking of those is an entirely separate matter
from cracking private/public key encryption itself. Has any “quantum”
weakness been demonstrated in Diffie-Hellman? Not that I’ve heard of.
Yes, Diffie-Hellman is vulnerable to a quantum computer.
On 08/06/2026 07:30, c186282 wrote:
Well ... remember how TINY the Computing Environment
tended to be. Assumptions were made. CP/M, DOS, even
some other systems ... they just ASSUMED usage would
easily fall into line with the system limits. Only
loons would have over 10,000 database records, over
100 text processing files ! Wouldn't fit in 64k
anyhow !!!
The only assumption they made was that coders would not be stupid enough
to write code that exceeded their limits.
They anticipated writing tools for engineers, not abstractions for
computer scientists.
On 08/06/2026 04:38, c186282 wrote:
For fun some years back I wrote a Bash version
that largely emulated what my Python and Pascal
server backup programs did. It worked. However
despite most units being more or less self-repeating
you just couldn't READ the damned thing. Comments
didn't help much. One tiny change needed and it
was "WHAT ? WHERE THE FUCK ? HOW THE FUCK ? WHAT'S
*THAT* MEAN ? YOU NEED *TWO* SPACES AFTER ???"
On the plus, never saw the keyword "lambda" in a
Bash script ! 🙂
One of the most frustrating expediences I had was in writing my first
Z80 assembler.
I copied the demo code EXACTLY as it was printed in the user manual.
BIG mistake, It had been typeset indented by a space because it was 'code'
My impression was: imagine result of filename generation starting
from line consisting of 30 spaces and the word "APPROVED". At the
end.
On 08/06/2026 05:04, c186282 wrote:
On 6/7/26 09:41, Richard Kettlewell wrote:
But Richard in fact IS. And he has spent his life immersed in these concepts.
The REAL MATH defining such things ... it's WAY WAY above MY level >>>> alas. Gotta rely on the 'experts'. Some of this shit is really up >>>> into the proverbial aether.
It is not above my level.
Well, good. We need math geniuses.
Note that almost no one are math geniuses.
Well maybe. Arguably Enigma wasn't 'brute forced' either..You’re not going to brute-force AES-128. Do the maths.
It's not so much "brute force" ... it's inherent
little flaws in the algo - according to my sources.
Reduces the need for "brute".
But, so far, no "easy" cracks - just such 'time savers'.
AES and related should be "good enough" for at least five
more years.
But, AFTER that, how much of YOUR important info will be
in accessible AES-encrypted archive files somewhere ?
Do they change all your banking/ID/investment numbers
every year ? It's that "data tail" that worries me.
Being "old" nobody will guard it so well.
I cannot recall anyone ever 'cracking' any password or encryption I have used personally
Most hacks are way simpler.
"If you want the root passwords, they are all written down on post-it notes behind the receptionist. If you want to bypass the firewall, just
use one of the direct dial in modems the employees use on their PCs to enable them to work from home"
At some stage someone is going to realise also, that rather than a 4GW nuclear plant driving a $10 billion AI data centres, it might actually
be cheaper to employ a human.
The Russians already did that when they bought Donald Trump...
On 2026-06-08, Charlie Gibbs wrote:
On 2026-06-08, c186282 <[email protected]> wrote:
By the time 8+3 became 12+3 became 128/256/1024 then naming
constraints disappeared. Alas, esp M$, they TOTALLY disappeared.
Ah yes, good old MICROS~1..
I eagerly anticipate the day Microsoft is ordered to split up following
some antitrust ruling, if only because then one could propose the
split-up parts be named MICROS~1,MICROS~2,...,MICROS~N.
On Mon, 8 Jun 2026 02:30:35 -0400, c186282 wrote:
Well ... remember how TINY the Computing Environment tended to be.
Assumptions were made. CP/M, DOS, even some other systems ... they
just ASSUMED usage would easily fall into line with the system
limits. Only loons would have over 10,000 database records, over 100
text processing files ! Wouldn't fit in 64k anyhow !!!
The DB2 database had two tables for person and vehicle records that were meant to be used for looking up recent activity for Georgie Gangster and
so forth. In theory older records were irrelevant and would be purged, but there wasn't any mechanism to do so. When the client complained about the system being slow I found there were well over a million records and an
index had never been se up.
The whole mess was several gigabytes. This was around 2001 and I had a
hell of a time finding an AIX machine in house with that much free space
to restore it for testing.
Flash back to my first hard drive on an AT clone. I can't remember if it
was 5 or 10 MB but I had no idea why you would ever need that much
storage.
On 2026-06-08, The Natural Philosopher <[email protected]d> wrote:
"If you want the root passwords, they are all written down on post-it
notes behind the receptionist. If you want to bypass the firewall, just
use one of the direct dial in modems the employees use on their PCs to
enable them to work from home"
The movie "War Games" dealt with these things. Although it had
technical holes you could drive a truck through, the protagonist
pulling out a desk's writing leaf to reveal a sheet of passwords
was good for a laugh, and the most realistic part of the movie.
I wouldn't have minded having his 9600-bps acoustic coupler, though.
At some stage someone is going to realise also, that rather than a 4GW
nuclear plant driving a $10 billion AI data centres, it might actually
be cheaper to employ a human.
Yes, but not nearly as much fun. Besides, what would the little people
do with all that electricity? Cook meals?
The Russians already did that when they bought Donald Trump...
I thought it was Netanyahu that bought him.
Oh well, same day, different war...
On Mon, 08 Jun 2026 18:08:09 GMT, Charlie Gibbs wrote:
Yes, yes, 640K ought to be enough for anyone.
But this was a Unix box - I was expecting a bit more common sense.
Ah, the good old days when you linked VC++ with 5 different libraries depending, tiny, small, medium, large, frigging huge.
On Mon, 08 Jun 2026 18:08:10 GMT, Charlie Gibbs wrote:
I thought it was Netanyahu that bought him.
Oh well, same day, different war...
Bibi's shabbas goy is getting uppity these days and thinks he can tell
Bibi what to do. Interesting days ahead.
On Mon, 08 Jun 2026 21:46:55 +0000, Eric Pozharski wrote:
My impression was: imagine result of filename generation starting
from line consisting of 30 spaces and the word "APPROVED". At the
end.
Only 30?
Linux filesystems seem to have standardized on allowing 255 bytes in a file/directory name.
Whereas some Windows utilities restrict the entire pathname to that
length.
Eric Pozharski wrote:
My impression was: imagine result of filename generation starting
from line consisting of 30 spaces and the word "APPROVED". At the
end.
Only 30?
Linux filesystems seem to have standardized on allowing 255 bytes in a file/directory name.
On 6/8/26 04:34, The Natural Philosopher wrote:
On 08/06/2026 05:04, c186282 wrote:
On 6/7/26 09:41, Richard Kettlewell wrote:
At some stage someone is going to realise also, that rather than a 4GW
nuclear plant driving a $10 billion AI data centres, it might actually
be cheaper to employ a human.
True - but don't tell 'em that right NOW :-)
The Russians already did that when they bought Donald Trump...
Sorry, Vlad doesn't own Donald. Don't mistake 'diplomatic
language' for actual deception and such. Trump WILL flatter
Vlad, right up until some recruited agent sticks a knife in
Vlad's back. This is how it's DONE.
Ah, 'human factors' ... one of my favorite cases was when
a sec got an invoice for a large amount of concrete. We
DID use concrete - but got it from a dusty place a few
miles up the road. The bill was into five figures.
Fortunately our place was just small enough so one person
could shout down the hall "Do we remember buying a whole
bunch of concrete last month ???"
The alleged supplier was in AUSTRALIA - a legit mining-supply
company. We were USA. If you wanted giant drills and ore carts
on tracks, they were yer go-to.
Found the LINK was to a blank page on their web site that
just bounced you back to their main page so it'd look legit.
Evil people may have PUT it there, but it was probably just
a link they FOUND by poking around, a 'placeholder' page.
The actual dest for payment ... SEEMED to be eastern Europe,
likely Romania, as best I could tell. All this took me a
couple of HOURS.
Wrote it up as simple and concise as possible, mentioned
the 'clues'. The employee was happy she spotted this, good
psych reinforcement, got mentioned at the next weekly
dept meeting so other would become more wise.
SOME places PUNISH employees that screw up on things like
this. Sorry, 99.999% of the pop could NOT do the kind of
research I did - involving deep reading of HTML+ files
looking for Evil. Punish employees for stuff well above
their pay grade and they just WON'T REPORT such stuff
any more. Management/IT becomes The Enemy. Bounce them and
then you have to Start Over with a new, naive, worker.
No net improvement.
Of course management can ALWAYS blame it on that low-wage
worker .... that's how biz politics works. Disgusting !
"THEY did it ! We FIRED them ! We're clean now !!!".
Things started drifting more towards "disgusting" my last
year. Put in my notice. NOT unhappy about that.
On 6/8/26 21:44, rbowman wrote:
On Mon, 08 Jun 2026 18:08:09 GMT, Charlie Gibbs wrote:
Yes, yes, 640K ought to be enough for anyone.
But this was a Unix box - I was expecting a bit more common sense.
Ah, the good old days when you linked VC++ with 5 different libraries
depending, tiny, small, medium, large, frigging huge.
Heh ... we DID try the lower-end SCO UNIX on
our new 'AT's. Alas it was both Too Expensive
and Too Slow to really be useful. Not all that
much software either.
But it WAS interesting ... part of why I went
to Linux as soon as possible.
DOS, soon Win, had much nicer software.
On Mon, 08 Jun 2026 18:08:09 GMT, Charlie Gibbs wrote:
On 2026-06-08, rbowman <[email protected]> wrote:
What I do take exception to is Hungarian notation.
https://en.wikipedia.org/wiki/Hungarian_notation
Microsoft should have sent Simonyi back to Hungary in a box. Note: I've
liked the Hungarians I've worked with but not this particular one.
As said somewhere ... a number of workers just took to
copy/paste the first sentence - including 'invisible'
chars - from their word processor docs as the file name.
Too many of THEM, too few of ME ... had to just COPE.
On 6/8/26 21:46, rbowman wrote:
On Mon, 08 Jun 2026 18:08:10 GMT, Charlie Gibbs wrote:
I thought it was Netanyahu that bought him.
Oh well, same day, different war...
Bibi's shabbas goy is getting uppity these days and thinks he can tell
Bibi what to do. Interesting days ahead.
Wow ... TDS even here .........
On 2026-06-07 00:35, c186282 wrote:
On 6/6/26 05:35, Richard Kettlewell wrote:[snip]
[snip]Second, AES is not expected to be meaningfully impacted by quantum
computers; the same applies to other symmetric algorithms. The running
time of a Grover’s algorithm attack on AES-256 is 2^128 operations,
which is far beyond the possible. AES-128 initially looks more plausible >>> at 2^64 operations, but (unlike typical classical attacks) these
operations cannot be parallelized: we’d be looking at a runtime of at
least hundreds of years, even with rather optimistic assumptions about
how fast a quantum computer could run.
I've run into many good articles saying AES and closely
related CAN be cracked, kinda quickly, using quantum
methods. This may be a matter of how much we trust our
various sources.
The REAL MATH defining such things ... it's WAY WAY above
MY level alas. Gotta rely on the 'experts'. Some of this
shit is really up into the proverbial aether.
The algorithms that are expected to be broken by quantum computers are
asymmetric algorithms: RSA, (EC)DH, (EC)DSA, (EC)MQV, EdDSA, KCDSA, GOST >>> 34.10, SM2, etc.
Alas asymmetric/shared algos are used for 95% of what
is put online. Not the most encouraging thing ...
With all that in mind, a popular option is indeed to combine one of
these classical algorithms with a comparable post-quantum algorithm.
For example
https://datatracker.ietf.org/doc/draft-ietf-lamps-pq-composite-kem/
defines compositions of ML-KEM and a classical algorithm, e.g. ECDH.
Look, it's not time to PANIC ... not YET anyway. For five
or ten years what we're using WILL still be good.
But it won't last FOREVER.
We kind of need to KNOW when weaknesses are adding up so
we can SHIFT to new methods. This sort of info can be found,
but you have to LOOK a lot. In some cases you need to be the
0.001% math whiz to even understand such warnings.
Existing algos can be attacked mathematically, but "AI"
brute-force/unhuman techniques are also possible problems.
USED to use AES-128 for everything, it's GOOD and FASTER, but
the past five years or so ... AES-256. Five years from NOW ???
This is not really ‘double encryption’: rather it combines the output of
ML-KEM with the output of a classical key agreement mechanism (rephrased >>> as a KEM) using a PRF, and then uses that to derive symmetric session
keys (typically AES) for message encryption (which is how we already do
asymmetric confidentiality in TLS, ECIES, etc).
Now you're getting beyond me. I have a weird kind
of math-blindness - need a calc to do checking accts
but do kinda grasp some of the 'bigger' paradigms in
the abstract. Very odd. Oh well, what is, is.
Almost NOBODY is a general "math genius". Alas that
INCLUDES govt and bankers and CEOs and such.
Any way to encapsulate this for non math geniuses ???
A 'practical' analysis ???
I think what you say you "don't get" is this:
For almost all file encryption, we use symmetric encryption: The same
key is used for encrypting and decrypting. These are DES, AES etc.
Richard says these are not in themselves susceptible to quantum
attacks, but do require longer keys as attackers get faster computers.
But we love to authenticate our communication partners, and for this we
use asymmetric protocols, such as public/private key protocols.
And then we use these asymmetric handshakes to exchange keys that are
then used for the symmetric protocols. Many/most of these asymmetric protocols are vulnerable to quantum breakage. And if you break into the
key exchange, you can then decode the stuff that was encoded with the symmetric algorithm - no need to break the encryption.
Richard, did I get that right?
That DB2 was "ok", FOR IT'S TIME.
But again ... built initially for a 64k/floppy environment. Same with
all the spreadsheets and word processors and such.
On 6/8/26 21:46, rbowman wrote:
On Mon, 08 Jun 2026 18:08:10 GMT, Charlie Gibbs wrote:
I thought it was Netanyahu that bought him.
Oh well, same day, different war...
Bibi's shabbas goy is getting uppity these days and thinks he can tell
Bibi what to do. Interesting days ahead.
Wow ... TDS even here .........
The New Guys can't program their way out of a wet
paper bag ... so they just use/pay-for the wunnerful
M$ "solutions" and think that's a-OK. Can't really
trash them too much, that's Just How It's Done
these days. My gen was bits and bytes, theirs is
a different world (that WILL bite 'em bad eventually).
But they'll just blame it all on M$ ... butts saved.
That's how it works now.
Kinda tragic .......
WHEN Vlad/Xi/Kim and friends really GO for it ...
global DOOM.
They'll try to recruit us Old Guys but, well, just
TOO Old now ...... I'll "advise" a bit, for $500
an hour :-)
On Mon, 08 Jun 2026 18:08:09 GMT, Charlie Gibbs wrote:
OK, I bite. What's snake case, and how does it differ from camel case?
camelCase snake_case.
What I do take exception to is Hungarian notation.
https://en.wikipedia.org/wiki/Hungarian_notation
Microsoft should have sent Simonyi back to Hungary in a box. Note: I've liked the Hungarians I've worked with but not this particular one.
On Mon, 08 Jun 2026 18:08:09 GMT, Charlie Gibbs wrote:
Yes, yes, 640K ought to be enough for anyone.
But this was a Unix box - I was expecting a bit more common sense.
Ah, the good old days when you linked VC++ with 5 different libraries depending, tiny, small, medium, large, frigging huge.
On Sat, 6 Jun 2026 14:01:54 +0200, "Carlos E.R." <[email protected]d> >wrote:
On 2026-06-06 13:34, TheLastSysop wrote:
On Sat, 6 Jun 2026 13:32:02 +0200, "Carlos E.R." <[email protected]d> >>> wrote:
On 2026-06-06 09:04, c186282 wrote:
On 6/6/26 02:38, Lawrence D’Oliveiro wrote:
On Sat, 30 May 2026 22:28:03 GMT, TheLastSysop wrote:
Plenty of people have a cron job, rsync script, USB disk, NAS share, >>>>>> or cloud bucket that looks comforting until the day they actually
need it. Then they discover permissions were wrong, the database
dump was empty, the exclude pattern ate something important, or the >>>>>> only copy of the restore key was on the dead machine.
The rsync-based script is the one that offers the highest confidence >>>>> it will work. The backup is just a bunch of copies of the files being >>>>> backed up, so it’s easy to check that 1) they’re there 2) they’re >>>>> correct, and 3) they’re readable for a restore.
Yep. Made extensive use of 'rsync' - an option
for everything. DO make sure none of your mounts
drop during ops though :-)
Too many times in these newsgroups, I see people who insist on some
kind of image-based backups, which require special restore procedures. >>>>> I don’t understand that. Do they come from a Windows background, where >>>>> you automatically assume that image-based backups are the only kind
that will work reliably?
Well, there's always a *complicated* solution
for everything ......
Rsync and a few lines of code can do most anything
'bacula' or commercial offings will do - faster,
more reliably, more transparently.
Can't compress the destination. Or encrypt it.
(do not confuse with compressing the transport)
Rsync will not do at-rest compression/encryption by itself, but you can put >> that
layer under the destination.
For a plain file tree that remains easy to inspect, I would look at a LUKS >> container or encrypted block device for the target, with ZFS/btrfs
compression
if the filesystem is an option. Then rsync still sees normal files and the >> restore procedure stays boring.
I do that already.
Problem: I got btrfs corruption of one file, read error. I don't trust it.
I am at this moment reformatting my main backup destination to XFS.
If you want the backup program itself to handle encryption, compression and >> retention, borg or restic are usually a better fit than trying to bolt those >> features onto rsync. Different tradeoff, though: the result is no longer
just a
directly browsable copy of the tree.
Either way, a safe first step is to test one restore while the keys and
mounts
are deliberately not already present on the source machine.
On Sun, 7 Jun 2026 02:57:11 -0000 (UTC), Lawrence >=?iso-8859-13?q?D=FFOliveiro?= <[email protected]d> wrote:
On Sat, 06 Jun 2026 09:40:28 GMT, TheLastSysop wrote:
The recent rsync scare is a good reminder that "plain files" is not
the same thing as "immune to bugs".
What “rsync scare” was this? Checking the NEWS file ><https://github.com/RsyncProject/rsync/blob/master/NEWS.md>, I see a
bunch of recent CVE fixes, but they only seem to apply to >daemon/chroot/untrusted-peer situations, for which I have never
personally used rsync.
On Sat, 6 Jun 2026 14:01:54 +0200, "Carlos E.R." <[email protected]d> >> wrote:
On 2026-06-06 13:34, TheLastSysop wrote:
On Sat, 6 Jun 2026 13:32:02 +0200, "Carlos E.R." <[email protected]d> >>>> wrote:
On 2026-06-06 09:04, c186282 wrote:
On 6/6/26 02:38, Lawrence D’Oliveiro wrote:
On Sat, 30 May 2026 22:28:03 GMT, TheLastSysop wrote:
Plenty of people have a cron job, rsync script, USB disk, NAS share, >>>>>>> or cloud bucket that looks comforting until the day they actually >>>>>>> need it. Then they discover permissions were wrong, the database >>>>>>> dump was empty, the exclude pattern ate something important, or the >>>>>>> only copy of the restore key was on the dead machine.
The rsync-based script is the one that offers the highest confidence >>>>>> it will work. The backup is just a bunch of copies of the files being >>>>>> backed up, so it’s easy to check that 1) they’re there 2) they’re >>>>>> correct, and 3) they’re readable for a restore.
Yep. Made extensive use of 'rsync' - an option
for everything. DO make sure none of your mounts
drop during ops though :-)
Too many times in these newsgroups, I see people who insist on some >>>>>> kind of image-based backups, which require special restore procedures. >>>>>> I don’t understand that. Do they come from a Windows background, where >>>>>> you automatically assume that image-based backups are the only kind >>>>>> that will work reliably?
Well, there's always a *complicated* solution
for everything ......
Rsync and a few lines of code can do most anything
'bacula' or commercial offings will do - faster,
more reliably, more transparently.
Can't compress the destination. Or encrypt it.
(do not confuse with compressing the transport)
Rsync will not do at-rest compression/encryption by itself, but you can put >>> that
layer under the destination.
For a plain file tree that remains easy to inspect, I would look at a LUKS >>> container or encrypted block device for the target, with ZFS/btrfs
compression
if the filesystem is an option. Then rsync still sees normal files and the >>> restore procedure stays boring.
I do that already.
Problem: I got btrfs corruption of one file, read error. I don't trust it. >>
I am at this moment reformatting my main backup destination to XFS.
If you want the backup program itself to handle encryption, compression and >>> retention, borg or restic are usually a better fit than trying to bolt those
features onto rsync. Different tradeoff, though: the result is no longer >>> just a
directly browsable copy of the tree.
Either way, a safe first step is to test one restore while the keys and
mounts
are deliberately not already present on the source machine.
That read error is the bit I would chase before blaming btrfs alone. XFS is a perfectly reasonable backup target, but a new filesystem will not fix a marginal
disk, cable, USB bridge, SATA port, RAM problem, or power issue.
A safe first pass is to look at the boring evidence:
dmesg -T | egrep -i 'btrfs|i/o error|ata|usb|reset|medium error'
smartctl -x /dev/WHATEVER
smartctl -t long /dev/WHATEVER
If the old filesystem is still readable enough, `btrfs scrub status -d` can also
tell you whether this was a single bad extent or part of a larger pattern.
For a backup destination, I would also keep at least one other independent copy
until the replacement target has survived a full write, readback, and some time
powered on. The most annoying backup failure is the one that moves with the enclosure and then wears a different filesystem hat.
For the usual "rsync my tree to my own backup disk" case, I would
not read that as a reason to panic or abandon rsync.
On Wed, 10 Jun 2026 00:19:15 -0000 (UTC), Lawrence >=?iso-8859-13?q?D=FFOliveiro?= <[email protected]d> wrote:
On Tue, 09 Jun 2026 20:30:13 GMT, TheLastSysop wrote:
For the usual "rsync my tree to my own backup disk" case, I would
not read that as a reason to panic or abandon rsync.
But that’s what this entire thread was about, was it not? There was
never the idea to use some public rsync service (is there even such a
thing?) or anything like that.
On 2026-06-09 09:08, c186282 wrote:
On 6/8/26 21:44, rbowman wrote:
On Mon, 08 Jun 2026 18:08:09 GMT, Charlie Gibbs wrote:
Yes, yes, 640K ought to be enough for anyone.
But this was a Unix box - I was expecting a bit more common sense.
Ah, the good old days when you linked VC++ with 5 different libraries
depending, tiny, small, medium, large, frigging huge.
Heh ... we DID try the lower-end SCO UNIX on
our new 'AT's. Alas it was both Too Expensive
and Too Slow to really be useful. Not all that
much software either.
But it WAS interesting ... part of why I went
to Linux as soon as possible.
DOS, soon Win, had much nicer software.
I find dos software nicer than Linux software. Editors, for instance.
When I started on Linux, I was surprised that ctrl-arrow would not move
a word to the left/right, for example. Tons of MsDOS text software that
had menus and mouse support. Linux in 1998 felt old.
On 2026-06-09 07:48, c186282 wrote:
As said somewhere ... a number of workers just took to
copy/paste the first sentence - including 'invisible'
chars - from their word processor docs as the file name.
Too many of THEM, too few of ME ... had to just COPE.
I seem to recall Libre Office or Open Office doing that automatically,
as a suggestion. No special chars.
On 09/06/2026 08:09, c186282 wrote:
On 6/8/26 21:46, rbowman wrote:It's everywhere. Mostly in the White House.
On Mon, 08 Jun 2026 18:08:10 GMT, Charlie Gibbs wrote:
I thought it was Netanyahu that bought him.
Oh well, same day, different war...
Bibi's shabbas goy is getting uppity these days and thinks he can tell
Bibi what to do. Interesting days ahead.
Wow ... TDS even here .........
On Wed, 10 Jun 2026 01:32:36 -0400, c186282 <[email protected]> wrote:
On 6/9/26 05:11, Carlos E.R. wrote:
On 2026-06-09 07:48, c186282 wrote:
As said somewhere ... a number of workers just took to
copy/paste the first sentence - including 'invisible'
chars - from their word processor docs as the file name.
Too many of THEM, too few of ME ... had to just COPE.
I seem to recall Libre Office or Open Office doing that automatically,
as a suggestion. No special chars.
Hmm ... was using LibreOffice Writer just today - TRYING
to coerce it into doing proper mailing envelopes.
Limited success - and the docs were confusing.
However it didn't offer to use the first sentence as
the file name.
Writer knew what a #10 envelope is, my printer knows
what a #10 envelope is - but ........ had to do really
ridiculous tweaks to the template just to get the
addressee lines up into the right place. I think it
chose some OTHER kind of envelope by default even if
you TOLD it #10.
Wanted super-nice/clear address for the US Govt
Internal Revenue people. Never got good marks for
penmanship in school and that's never improved :-)
Bought a 'label machine' - found a mystery PPD file.
Haven't dared trying it yet. Not factory supported.
Nobody loves Linux ! :-(
And I *won't* install Winderz. Last one I kind-of
liked was Win2K. Don't think that'll even run on
modern hardware. Dealing with Win at work was just
torture - so much depth and breadth of complication
just to accomplish something kinda stupid.
DO have a Win-1.x install as a VM somewhere !
Also have the BYTE mag with a REVIEW of it :-)
Clue, better stuff for the C64/128 at the time ...
On Tue, 9 Jun 2026 02:28:13 -0400, c186282 wrote:
That DB2 was "ok", FOR IT'S TIME.
But again ... built initially for a 64k/floppy environment. Same with
all the spreadsheets and word processors and such.
Er, DB2 was developed and ran on IBM mainframes. It wasn't until the '90s that implementations were available for Windows, Linux and other lesser systems.
The database I referred to was on a RS6000 server running AIX.
DB2 != dBase.
Another early database was Raima's DB Vista that goes back to 1984. We use
it for archiving information for local access, usually 6 months worth. The data was also sent to the DB2 database but vista was a lot faster. We also used it for GIS vector data.
Esri used dBase when they created the shapefile format that still is the lingua franca today. The implementation was sort of a hack, with dBase
used to store pointers into a separate file where the vecttor information
was stored in variable length records. Vista had the concept of set
ownership and was a more graceful implementation but Esri is the 500 lb. gorilla in the field.
That early design choice stuck with Esri. Even as they move on to Access,
SQL Server, and their won FileGDB design the data was not normalized.
Every segment of Chestnut Street was a separate record that repeated the attributes of the street along with its geometry.
On 2026-06-09, c186282 <[email protected]> wrote:
The New Guys can't program their way out of a wet
paper bag ... so they just use/pay-for the wunnerful
M$ "solutions" and think that's a-OK. Can't really
trash them too much, that's Just How It's Done
these days. My gen was bits and bytes, theirs is
a different world (that WILL bite 'em bad eventually).
But they'll just blame it all on M$ ... butts saved.
That's how it works now.
And then M$ will offer a new "solution" which they'll
eagerly adopt. Lather, rinse, repeat...
Kinda tragic .......
Yup.
WHEN Vlad/Xi/Kim and friends really GO for it ...
global DOOM.
Don't forget friends like Elon/Mark/Tim...
They'll try to recruit us Old Guys but, well, just
TOO Old now ...... I'll "advise" a bit, for $500
an hour :-)
There you go, job security again. :-)
On 2026-06-09, rbowman <[email protected]> wrote:
On Mon, 08 Jun 2026 18:08:09 GMT, Charlie Gibbs wrote:
Yes, yes, 640K ought to be enough for anyone.
But this was a Unix box - I was expecting a bit more common sense.
Ah, the good old days when you linked VC++ with 5 different libraries
depending, tiny, small, medium, large, frigging huge.
And then there were the tricks you had to do when dealing
with arrays larger than 64K. I had a lot of ugly pointer
normalization and byte-by-byte copying code that I was
only too glad to rip out when we got past those models.
On Sat, 6 Jun 2026 14:01:54 +0200, "Carlos E.R." <[email protected]d> >> wrote:
On 2026-06-06 13:34, TheLastSysop wrote:
On Sat, 6 Jun 2026 13:32:02 +0200, "Carlos E.R." <[email protected]d> >>>> wrote:
On 2026-06-06 09:04, c186282 wrote:
On 6/6/26 02:38, Lawrence D’Oliveiro wrote:
On Sat, 30 May 2026 22:28:03 GMT, TheLastSysop wrote:
Plenty of people have a cron job, rsync script, USB disk, NAS share, >>>>>>> or cloud bucket that looks comforting until the day they actually >>>>>>> need it. Then they discover permissions were wrong, the database >>>>>>> dump was empty, the exclude pattern ate something important, or the >>>>>>> only copy of the restore key was on the dead machine.
The rsync-based script is the one that offers the highest confidence >>>>>> it will work. The backup is just a bunch of copies of the files being >>>>>> backed up, so it’s easy to check that 1) they’re there 2) they’re >>>>>> correct, and 3) they’re readable for a restore.
Yep. Made extensive use of 'rsync' - an option
for everything. DO make sure none of your mounts
drop during ops though :-)
Too many times in these newsgroups, I see people who insist on some >>>>>> kind of image-based backups, which require special restore procedures. >>>>>> I don’t understand that. Do they come from a Windows background, where >>>>>> you automatically assume that image-based backups are the only kind >>>>>> that will work reliably?
Well, there's always a *complicated* solution
for everything ......
Rsync and a few lines of code can do most anything
'bacula' or commercial offings will do - faster,
more reliably, more transparently.
Can't compress the destination. Or encrypt it.
(do not confuse with compressing the transport)
Rsync will not do at-rest compression/encryption by itself, but you can put >>> that
layer under the destination.
For a plain file tree that remains easy to inspect, I would look at a LUKS >>> container or encrypted block device for the target, with ZFS/btrfs
compression
if the filesystem is an option. Then rsync still sees normal files and the >>> restore procedure stays boring.
I do that already.
Problem: I got btrfs corruption of one file, read error. I don't trust it. >>
I am at this moment reformatting my main backup destination to XFS.
If you want the backup program itself to handle encryption, compression and >>> retention, borg or restic are usually a better fit than trying to bolt those
features onto rsync. Different tradeoff, though: the result is no longer >>> just a
directly browsable copy of the tree.
Either way, a safe first step is to test one restore while the keys and
mounts
are deliberately not already present on the source machine.
That read error is the bit I would chase before blaming btrfs alone. XFS is a perfectly reasonable backup target, but a new filesystem will not fix a marginal
disk, cable, USB bridge, SATA port, RAM problem, or power issue.
A safe first pass is to look at the boring evidence:
dmesg -T | egrep -i 'btrfs|i/o error|ata|usb|reset|medium error'
smartctl -x /dev/WHATEVER
smartctl -t long /dev/WHATEVER
If the old filesystem is still readable enough, `btrfs scrub status -d` can also
tell you whether this was a single bad extent or part of a larger pattern.
For a backup destination, I would also keep at least one other independent copy
until the replacement target has survived a full write, readback, and some time
powered on. The most annoying backup failure is the one that moves with the enclosure and then wears a different filesystem hat.
On 6/9/26 05:07, Carlos E.R. wrote:
On 2026-06-09 09:08, c186282 wrote:
On 6/8/26 21:44, rbowman wrote:
On Mon, 08 Jun 2026 18:08:09 GMT, Charlie Gibbs wrote:
Yes, yes, 640K ought to be enough for anyone.
But this was a Unix box - I was expecting a bit more common sense.
Ah, the good old days when you linked VC++ with 5 different libraries
depending, tiny, small, medium, large, frigging huge.
Heh ... we DID try the lower-end SCO UNIX on
our new 'AT's. Alas it was both Too Expensive
and Too Slow to really be useful. Not all that
much software either.
But it WAS interesting ... part of why I went
to Linux as soon as possible.
DOS, soon Win, had much nicer software.
I find dos software nicer than Linux software. Editors, for instance.
When I started on Linux, I was surprised that ctrl-arrow would not
move a word to the left/right, for example. Tons of MsDOS text
software that had menus and mouse support. Linux in 1998 felt old.
DOS 1.x ... I had to WRITE 'sensible' text editors.
Even did one in ASM for kicks (was younger then).
However I do kind of understand what you're talking
about. Too much UNIX/Linux stuff was oriented towards
'academics' and related. Weird, unfriendly to use,
non-intuitive. M$, for all its other faults, DID seem
to "get it". Hell, even some latter CP/M apps were a
lot more sensible than UNIX stuff.
"Just hit this meaningless four-key combo to go to
the next line ..." Sorry, NO !!! Wanna hit Down Arrow
and it's just DONE.
Still have SOME of that MASM editor code somewhere, but
not the entire product alas. It was kinda like "MousePad",
which still beat the hell out of "edlin". Yes, there ARE
still some here dedicated to those multi-combo-to-do-
anything editors. That's THEIR choice. As much as possible
I *disable* those so they won't come up even by accident.
Anyway, despite temptations, we did not switch to SCO.
Turned out to be a good thing. DID manage to avoid
getting hooked on Apple stuff - saved a fortune and a
life of servitude :-)
But, as said, some of the GOOD stuff about UNIX did get
me to buy Linux when it first appeared. Lots of floppies.
This was when in-house servers/networking were just
becoming viable for "regular" biz. Linux made that stuff
much better than DOS/Winders did and didn't try to bleed
you for cash.
On Wed, 10 Jun 2026 04:36:01 -0400, c186282 <[email protected]> wrote:
On 6/9/26 16:29, TheLastSysop wrote:
On Sat, 6 Jun 2026 14:01:54 +0200, "Carlos E.R." <[email protected]d> >>> wrote:
On 2026-06-06 13:34, TheLastSysop wrote:
On Sat, 6 Jun 2026 13:32:02 +0200, "Carlos E.R." <[email protected]d>
wrote:
On 2026-06-06 09:04, c186282 wrote:
On 6/6/26 02:38, Lawrence D’Oliveiro wrote:
On Sat, 30 May 2026 22:28:03 GMT, TheLastSysop wrote:
Plenty of people have a cron job, rsync script, USB disk, NAS share, >>>>>>>> or cloud bucket that looks comforting until the day they actually >>>>>>>> need it. Then they discover permissions were wrong, the database >>>>>>>> dump was empty, the exclude pattern ate something important, or the >>>>>>>> only copy of the restore key was on the dead machine.
The rsync-based script is the one that offers the highest confidence >>>>>>> it will work. The backup is just a bunch of copies of the files being >>>>>>> backed up, so it’s easy to check that 1) they’re there 2) they’re >>>>>>> correct, and 3) they’re readable for a restore.
Yep. Made extensive use of 'rsync' - an option
for everything. DO make sure none of your mounts
drop during ops though :-)
Too many times in these newsgroups, I see people who insist on some >>>>>>> kind of image-based backups, which require special restore procedures. >>>>>>> I don’t understand that. Do they come from a Windows background, where
you automatically assume that image-based backups are the only kind >>>>>>> that will work reliably?
Well, there's always a *complicated* solution
for everything ......
Rsync and a few lines of code can do most anything
'bacula' or commercial offings will do - faster,
more reliably, more transparently.
Can't compress the destination. Or encrypt it.
(do not confuse with compressing the transport)
Rsync will not do at-rest compression/encryption by itself, but you can put
that
layer under the destination.
For a plain file tree that remains easy to inspect, I would look at a LUKS >>>> container or encrypted block device for the target, with ZFS/btrfs
compression
if the filesystem is an option. Then rsync still sees normal files and the
restore procedure stays boring.
I do that already.
Problem: I got btrfs corruption of one file, read error. I don't trust it. >>>
I am at this moment reformatting my main backup destination to XFS.
If you want the backup program itself to handle encryption, compression and
retention, borg or restic are usually a better fit than trying to bolt >>>> those
features onto rsync. Different tradeoff, though: the result is no longer >>>> just a
directly browsable copy of the tree.
Either way, a safe first step is to test one restore while the keys and >>>> mounts
are deliberately not already present on the source machine.
That read error is the bit I would chase before blaming btrfs alone. XFS is a
perfectly reasonable backup target, but a new filesystem will not fix a
marginal
disk, cable, USB bridge, SATA port, RAM problem, or power issue.
A safe first pass is to look at the boring evidence:
dmesg -T | egrep -i 'btrfs|i/o error|ata|usb|reset|medium error'
smartctl -x /dev/WHATEVER
smartctl -t long /dev/WHATEVER
If the old filesystem is still readable enough, `btrfs scrub status -d` can >> also
tell you whether this was a single bad extent or part of a larger pattern. >>
For a backup destination, I would also keep at least one other independent >> copy
until the replacement target has survived a full write, readback, and some >> time
powered on. The most annoying backup failure is the one that moves with the >> enclosure and then wears a different filesystem hat.
If using USB drives there are many little ways
things can go wrong. It's MORE often the actual
drive, not the particular file system used.
BTRFS/XFS ... have really had no issues with them.
XFS is still good for large backup drives. BTRFS
seems like over-kill. TREND towards EXT4 on
everything though - most tools.
Anyway, most ALL current Linux filesystems are Very
Good. Bizarre probs - look to the hardware.
I made a little home NAS ... all USB drives in
a 4-unit enclosure. It's pretty damned good.
FAN died, replaced with a bigger/noisier one,
but all in all can't complain. DID find a bit
of obscure code for resetting the entire USB
bus - as if everything was newly plugged in.
Run THAT just after boot. Settles things.
Smartctl ... used to use that a lot with mag drives,
automated scripts + email reports. Sometimes FOUND
stuff too. However mag drives are not as common
anymore, all SSDs. However, BIG, it's still mags.
IF in your budget, DO look into the Sinology
dedicated NAS units.
On 6/9/26 05:11, Carlos E.R. wrote:
On 2026-06-09 07:48, c186282 wrote:
As said somewhere ... a number of workers just took to
copy/paste the first sentence - including 'invisible'
chars - from their word processor docs as the file name.
Too many of THEM, too few of ME ... had to just COPE.
I seem to recall Libre Office or Open Office doing that automatically,
as a suggestion. No special chars.
Hmm ... was using LibreOffice Writer just today - TRYING
to coerce it into doing proper mailing envelopes.
Limited success - and the docs were confusing.
However it didn't offer to use the first sentence as
the file name.
Writer knew what a #10 envelope is, my printer knows
what a #10 envelope is - but ........ had to do really
ridiculous tweaks to the template just to get the
addressee lines up into the right place. I think it
chose some OTHER kind of envelope by default even if
you TOLD it #10.
Wanted super-nice/clear address for the US Govt
Internal Revenue people. Never got good marks for
penmanship in school and that's never improved :-)
Bought a 'label machine' - found a mystery PPD file.
Haven't dared trying it yet. Not factory supported.
Nobody loves Linux ! :-(
And I *won't* install Winderz. Last one I kind-of
liked was Win2K. Don't think that'll even run on
modern hardware. Dealing with Win at work was just
torture - so much depth and breadth of complication
just to accomplish something kinda stupid.
DO have a Win-1.x install as a VM somewhere !
Also have the BYTE mag with a REVIEW of it :-)
Clue, better stuff for the C64/128 at the time ...
On 2026-06-10 07:03, c186282 wrote:
On 6/9/26 05:07, Carlos E.R. wrote:
On 2026-06-09 09:08, c186282 wrote:
On 6/8/26 21:44, rbowman wrote:
On Mon, 08 Jun 2026 18:08:09 GMT, Charlie Gibbs wrote:
So PC it was, in the Amstrad shape.
But, as said, some of the GOOD stuff about UNIX did get
me to buy Linux when it first appeared. Lots of floppies.
This was when in-house servers/networking were just
becoming viable for "regular" biz. Linux made that stuff
much better than DOS/Winders did and didn't try to bleed
you for cash.
What I found dismal was the compilers. Coming from the world of Borland IDEs, programming in C or Pascal was like going back twenty years. So I
did not...
On 6/9/26 06:17, The Natural Philosopher wrote:
On 09/06/2026 08:09, c186282 wrote:
On 6/8/26 21:46, rbowman wrote:It's everywhere. Mostly in the White House.
On Mon, 08 Jun 2026 18:08:10 GMT, Charlie Gibbs wrote:
I thought it was Netanyahu that bought him.
Oh well, same day, different war...
Bibi's shabbas goy is getting uppity these days and thinks he can tell >>>> Bibi what to do. Interesting days ahead.
Wow ... TDS even here .........
Tisk !
And I *won't* install Winderz. Last one I kind-of
liked was Win2K. Don't think that'll even run on
modern hardware. Dealing with Win at work was just
torture - so much depth and breadth of complication
just to accomplish something kinda stupid.
On 10/06/2026 06:33, c186282 wrote:
On 6/9/26 06:17, The Natural Philosopher wrote:From afar, it seems that the whole American nation have gone batshit
On 09/06/2026 08:09, c186282 wrote:
On 6/8/26 21:46, rbowman wrote:It's everywhere. Mostly in the White House.
On Mon, 08 Jun 2026 18:08:10 GMT, Charlie Gibbs wrote:
I thought it was Netanyahu that bought him.
Oh well, same day, different war...
Bibi's shabbas goy is getting uppity these days and thinks he can tell >>>>> Bibi what to do. Interesting days ahead.
Wow ... TDS even here .........
Tisk !
crazy, from the Librals prophesying complete societal collapse from
Trump, sonofabitch, to those believing in the second coming of Trump,
son of God.
He's just a very naughty boy.
Yea, but the REGULAR PEOPLE didn't use the mainframe version. It was
an x86 version with sub-megabyte orientation.
On 6/9/26 06:17, The Natural Philosopher wrote:
On 09/06/2026 08:09, c186282 wrote:
On 6/8/26 21:46, rbowman wrote:It's everywhere. Mostly in the White House.
On Mon, 08 Jun 2026 18:08:10 GMT, Charlie Gibbs wrote:
I thought it was Netanyahu that bought him.
Oh well, same day, different war...
Bibi's shabbas goy is getting uppity these days and thinks he can
tell Bibi what to do. Interesting days ahead.
Wow ... TDS even here .........
Tisk !
From afar, it seems that the whole American nation have gone batshit
crazy, from the Librals prophesying complete societal collapse from
Trump, sonofabitch, to those believing in the second coming of Trump,
son of God.
He's just a very naughty boy.
Read a stat today, only 1 in 10 Europeans think the Americans are friends.
On Wed, 10 Jun 2026 01:33:52 -0400, c186282 wrote:
On 6/9/26 06:17, The Natural Philosopher wrote:
On 09/06/2026 08:09, c186282 wrote:
On 6/8/26 21:46, rbowman wrote:It's everywhere. Mostly in the White House.
On Mon, 08 Jun 2026 18:08:10 GMT, Charlie Gibbs wrote:
I thought it was Netanyahu that bought him.
Oh well, same day, different war...
Bibi's shabbas goy is getting uppity these days and thinks he can
tell Bibi what to do. Interesting days ahead.
Wow ... TDS even here .........
Tisk !
https://www.cnbc.com/2026/06/10/trump-inflation-cpi-iran-oil.html
"Trump says ‘I love the inflation’ after consumer price index hits 3-year high"
In my job I have to write stuff that runs under Windows (I prefer to
say it runs _despite_ it), but I just do back-end stuff (file
handling, TCP/IP, etc.), not fancy GUI stuff. So I get by just fine
using XP under VirtualBox on a Linux machine.
On 10/06/2026 17:52, Carlos E.R. wrote:
From afar, it seems that the whole American nation have gone batshit
crazy, from the Librals prophesying complete societal collapse from
Trump, sonofabitch, to those believing in the second coming of Trump,
son of God.
He's just a very naughty boy.
Read a stat today, only 1 in 10 Europeans think the Americans are
friends.
Well the US state, anyway,
Fundamentally the US would at least work towards its long term interest. Europe was a market as big as the USA and was worth protecting.
On Wed, 10 Jun 2026 11:08:45 GMT, Charlie Gibbs wrote:
In my job I have to write stuff that runs under Windows (I prefer to
say it runs _despite_ it), but I just do back-end stuff (file
handling, TCP/IP, etc.), not fancy GUI stuff. So I get by just fine
using XP under VirtualBox on a Linux machine.
Why not make WSL2 a requirement? Then you can deliver your code
running natively on Linux.
On 2026-06-10 07:03, c186282 wrote:
On 6/9/26 05:07, Carlos E.R. wrote:
On 2026-06-09 09:08, c186282 wrote:
On 6/8/26 21:44, rbowman wrote:
On Mon, 08 Jun 2026 18:08:09 GMT, Charlie Gibbs wrote:
Yes, yes, 640K ought to be enough for anyone.
But this was a Unix box - I was expecting a bit more common sense.
Ah, the good old days when you linked VC++ with 5 different libraries >>>>> depending, tiny, small, medium, large, frigging huge.
Heh ... we DID try the lower-end SCO UNIX on
our new 'AT's. Alas it was both Too Expensive
and Too Slow to really be useful. Not all that
much software either.
But it WAS interesting ... part of why I went
to Linux as soon as possible.
DOS, soon Win, had much nicer software.
I find dos software nicer than Linux software. Editors, for instance.
When I started on Linux, I was surprised that ctrl-arrow would not
move a word to the left/right, for example. Tons of MsDOS text
software that had menus and mouse support. Linux in 1998 felt old.
DOS 1.x ... I had to WRITE 'sensible' text editors.
Even did one in ASM for kicks (was younger then).
However I do kind of understand what you're talking
about. Too much UNIX/Linux stuff was oriented towards
'academics' and related. Weird, unfriendly to use,
non-intuitive. M$, for all its other faults, DID seem
to "get it". Hell, even some latter CP/M apps were a
lot more sensible than UNIX stuff.
"Just hit this meaningless four-key combo to go to
the next line ..." Sorry, NO !!! Wanna hit Down Arrow
and it's just DONE.
MsDOS editors would apply meanings to ctrl-down or alt-down. Like go
down a paragraph.
Still have SOME of that MASM editor code somewhere, but
not the entire product alas. It was kinda like "MousePad",
which still beat the hell out of "edlin". Yes, there ARE
still some here dedicated to those multi-combo-to-do-
anything editors. That's THEIR choice. As much as possible
I *disable* those so they won't come up even by accident.
Anyway, despite temptations, we did not switch to SCO.
Turned out to be a good thing. DID manage to avoid
getting hooked on Apple stuff - saved a fortune and a
life of servitude :-)
I rejected Apple stuff very early.
The student association at the uni made some deal with Amstrad, and we
could get an Amstrad PC with two flopies at a reasonable price. I asked
them what to choose, a PC or an Apple, and they said that with a PC they could help me to get software used at uni (meaning pirated copies), and
that I could easily share stuff.
So PC it was, in the Amstrad shape.
But, as said, some of the GOOD stuff about UNIX did get
me to buy Linux when it first appeared. Lots of floppies.
This was when in-house servers/networking were just
becoming viable for "regular" biz. Linux made that stuff
much better than DOS/Winders did and didn't try to bleed
you for cash.
What I found dismal was the compilers. Coming from the world of Borland IDEs, programming in C or Pascal was like going back twenty years. So I
did not...
Our customers are bigger than we are, so we can't tell them to go
pound sand if they don't like what we have to offer.
On Wed, 10 Jun 2026 02:40:51 -0400, c186282 wrote:
Yea, but the REGULAR PEOPLE didn't use the mainframe version. It was
an x86 version with sub-megabyte orientation.
I think you can expand that to regular people on Windows don't use DB2. FoxPro, derived from dBase, and Access pretty much cornered the Microsoft market.
On Wed, 10 Jun 2026 01:33:52 -0400, c186282 wrote:
On 6/9/26 06:17, The Natural Philosopher wrote:
On 09/06/2026 08:09, c186282 wrote:
On 6/8/26 21:46, rbowman wrote:It's everywhere. Mostly in the White House.
On Mon, 08 Jun 2026 18:08:10 GMT, Charlie Gibbs wrote:
I thought it was Netanyahu that bought him.
Oh well, same day, different war...
Bibi's shabbas goy is getting uppity these days and thinks he can
tell Bibi what to do. Interesting days ahead.
Wow ... TDS even here .........
Tisk !
https://www.cnbc.com/2026/06/10/trump-inflation-cpi-iran-oil.html
"Trump says ‘I love the inflation’ after consumer price index hits 3-year high"
On 10/06/2026 17:52, Carlos E.R. wrote:
From afar, it seems that the whole American nation have gone batshit
crazy, from the Librals prophesying complete societal collapse from
Trump, sonofabitch, to those believing in the second coming of
Trump, son of God.
He's just a very naughty boy.
Read a stat today, only 1 in 10 Europeans think the Americans are
friends.
Well the US state, anyway,
Fundamentally the US would at least work towards its long term interest. Europe was a market as big as the USA and was worth protecting.
Trump is simply too stupid to understand that. If he cant make a profit right now, he isn't interested.
On Wed, 10 Jun 2026 21:47:27 +0100, The Natural Philosopher wrote:
On 10/06/2026 17:52, Carlos E.R. wrote:
From afar, it seems that the whole American nation have gone batshit
crazy, from the Librals prophesying complete societal collapse from
Trump, sonofabitch, to those believing in the second coming of Trump, >>>> son of God.
He's just a very naughty boy.
Read a stat today, only 1 in 10 Europeans think the Americans are
friends.
Well the US state, anyway,
Fundamentally the US would at least work towards its long term interest.
Europe was a market as big as the USA and was worth protecting.
https://ustr.gov/countries-regions/europe-middle-east/europe/european-
union
https://www.consilium.europa.eu/en/infographics/eu-us-trade/
If you have a $200 billion trade deficit is it worth pursuing the market?
The sectors that do export to the EU would say yes; the sectors hurt by EU imports might not be as enthusiastic. It's clear why the US is so intent
on exporting LNG to the EU, particularly Germany. It's not so clear why Germany chose that alternative to cheaper Russian gas.
Turbo Pascal changed everything. Vastly more efficient and fun !
Showed how it COULD be. Have it in a DOS VM still - but it is kind of
constrained to the 8/16 world.
DB2 ... it was expensive and hogged resources, REALLY
meant for a mainframe rent-a-byte environment.
Never used Oracle though. Dunno why.
Hey, he's a SALESMAN !
Mostly we don't buy it, of course ... but at the same time we DO want
Iran reduced to 4th world.
Note those Euros got to think of the USA as "Uncle Money-Bags" for a
LONG time.
On Thu, 11 Jun 2026 00:33:40 -0400, c186282 wrote:
Turbo Pascal changed everything. Vastly more efficient and fun !
Showed how it COULD be. Have it in a DOS VM still - but it is kind of
constrained to the 8/16 world.
I was impressed by Turbo Pascal on CP/M -- the system, not the language itself. I also liked Borland's OWL and IDE for C++ Windows programming. C+
+ Builder was a change in direction. Their dBase adventure didn't go well either.
The Natural Philosopher wrote:
On 10/06/2026 17:52, Carlos E.R. wrote:
Read a stat today, only 1 in 10 Europeans think the Americans are
friends.
Well the US state, anyway,
Fundamentally the US would at least work towards its long term
interest. Europe was a market as big as the USA and was worth
protecting.
https://ustr.gov/countries-regions/europe-middle-east/europe/european-
union
https://www.consilium.europa.eu/en/infographics/eu-us-trade/
If you have a $200 billion trade deficit is it worth pursuing the
market?
The sectors that do export to the EU would say yes; the sectors hurt
by EU imports might not be as enthusiastic. It's clear why the US is
so intent on exporting LNG to the EU, particularly Germany. It's not
so clear why Germany chose that alternative to cheaper Russian gas.
On Thu, 11 Jun 2026 03:31:00 GMT, Charlie Gibbs wrote:
Our customers are bigger than we are, so we can't tell them to go
pound sand if they don't like what we have to offer.
Sounds like your vendor-lock-in is not as strong as it should be ...
I thought *all* proprietary software vendors had figured that out ...
On 2026-06-10 12:53, The Natural Philosopher wrote:
On 10/06/2026 06:33, c186282 wrote:
On 6/9/26 06:17, The Natural Philosopher wrote:From afar, it seems that the whole American nation have gone
On 09/06/2026 08:09, c186282 wrote:
On 6/8/26 21:46, rbowman wrote:It's everywhere. Mostly in the White House.
On Mon, 08 Jun 2026 18:08:10 GMT, Charlie Gibbs wrote:
I thought it was Netanyahu that bought him.
Oh well, same day, different war...
Bibi's shabbas goy is getting uppity these days and thinks he can tell >>>>>> Bibi what to do. Interesting days ahead.
Wow ... TDS even here .........
Tisk !
batshit crazy, from the Librals prophesying complete societal
collapse from Trump, sonofabitch, to those believing in the second
coming of Trump, son of God.
He's just a very naughty boy.
Read a stat today, only 1 in 10 Europeans think the Americans are friends.
On 6/10/26 04:43, Carlos E.R. wrote:
On 2026-06-10 07:03, c186282 wrote:
On 6/9/26 05:07, Carlos E.R. wrote:
On 2026-06-09 09:08, c186282 wrote:
On 6/8/26 21:44, rbowman wrote:
On Mon, 08 Jun 2026 18:08:09 GMT, Charlie Gibbs wrote:
I rejected Apple stuff very early.
The student association at the uni made some deal with Amstrad, and we
could get an Amstrad PC with two flopies at a reasonable price. I
asked them what to choose, a PC or an Apple, and they said that with a
PC they could help me to get software used at uni (meaning pirated
copies), and that I could easily share stuff.
So PC it was, in the Amstrad shape.
'Politics' (and Cheapness) ! :-)
MAC and PC diverged - and never liked the Mac vibe.
The PC world (and usually Linux) just seems to 'think'
like I believe computers should think. Guess I'm "square".
But, as said, some of the GOOD stuff about UNIX did get
me to buy Linux when it first appeared. Lots of floppies.
This was when in-house servers/networking were just
becoming viable for "regular" biz. Linux made that stuff
much better than DOS/Winders did and didn't try to bleed
you for cash.
What I found dismal was the compilers. Coming from the world of
Borland IDEs, programming in C or Pascal was like going back twenty
years. So I did not...
Turbo Pascal changed everything. Vastly more efficient
and fun ! Showed how it COULD be. Have it in a DOS VM
still - but it is kind of constrained to the 8/16 world.
We need a "To_32/64" cross-compiler ! :-)
Modern is the Lazarus/FPC environment - IF you can score
sub-sub-versions of the various parts that will work
together. BEST bet is their site, not current repos. Have
had less success of late however. However I still write
some stuff in Lazarus - quickest route to a decent working
GUI app - and you can also just use it to make non-GUI FPC
apps as well.
If I have a good Python script that could use more tightening-up
and speed ... I re-do it in Pascal. I like Pascal, seems "elegant"
to me, 'speaks to the soul' perhaps. Will keep using it. Dr. Nick
came up with something GOOD.
ALSO have the old M$ Pascal and 'C' multi-pass compilers
in that VM. Yes, they DO work and every once in awhile I
write some little thing using them. But compared to a
good development IDE they're terribly clunky.
Have been TRYING to find a Modula-3 compiler - IDE or not -
that will actually WORK in Linux. Two or three oft-
mentioned ones but have NEVER been able to get them to
do even a "Hello World" without a zillion weird errors.
The Quebec one is most recommended, but still ...
There's GNU M2 ... also odd ... but M3 was "better"
and I still pref 'native compilers' over the GNU tricks.
DID find a COBOL IDE ... gotta re-install it. Don't
totally, or barely, love COBOL, but it doesn't hurt to
keep yer hand in. "OpenCobolIDE" - last revision 10
years ago alas. Not too bad.
For FORTRAN and 'D' and some others ... install CodeBlocks.
Works most easily if you install the compilers first. Rather
extensive IDE, almost TOO, that reminds of 'Visual' and
the JetBrains products. Always use CodeBlocks when doing 'C'.
Ah, try 'TCC' ... small, fast, suprisingly good and TIGHT.
Of course there are still plenty of 'old' compilers, including
'B' - hey, it's ALMOST 'C' - and even its predecessors. Fun
sometimes.
'Modern' like Rust ... mostly seem to be just less-readable
versions of 'C' without any major advantages for my level
of application. I'll do 'C'.
MOST often do Python these days however, it's become very
All-Purpose and has good string stuff. But it's not always
"best" for EVERYTHING.
Anyway, clearly we remember how clunky it COULD be - and how
a few geniuses made that MUCH better. 2nd and 3rd-gen IDEs,
you could get a lot of good stuff done FAST.
Oh well, I've gone on too long .........
On 6/10/26 16:47, The Natural Philosopher wrote:
On 10/06/2026 17:52, Carlos E.R. wrote:
From afar, it seems that the whole American nation have gone batshit
crazy, from the Librals prophesying complete societal collapse from
Trump, sonofabitch, to those believing in the second coming of
Trump, son of God.
He's just a very naughty boy.
Read a stat today, only 1 in 10 Europeans think the Americans are
friends.
Well the US state, anyway,
Fundamentally the US would at least work towards its long term
interest. Europe was a market as big as the USA and was worth protecting.
Trump is simply too stupid to understand that. If he cant make a
profit right now, he isn't interested.
Note those Euros got to think of the USA as
"Uncle Money-Bags" for a LONG time.
No wonder they're upset.
On Thu, 11 Jun 2026 01:16:32 -0400, c186282 wrote:
Note those Euros got to think of the USA as "Uncle Money-Bags" for a
LONG time.
The US wanted to be the big dog after WWII; the bill is coming due.
The USA can supply JUST enough petrochemicals to
keep the EU alive. Not 'healthy', but alive.
At least to an extent, Germany chose non-Russian gas because Ukraine
blew up the undersea pipeline... they’ve mostly got their heads turned back round to realizing that Russia is a threat again by now though.
On 2026-06-10, Carlos E.R. wrote:
On 2026-06-10 12:53, The Natural Philosopher wrote:
On 10/06/2026 06:33, c186282 wrote:
On 6/9/26 06:17, The Natural Philosopher wrote:From afar, it seems that the whole American nation have gone
On 09/06/2026 08:09, c186282 wrote:
On 6/8/26 21:46, rbowman wrote:It's everywhere. Mostly in the White House.
On Mon, 08 Jun 2026 18:08:10 GMT, Charlie Gibbs wrote:
I thought it was Netanyahu that bought him.
Oh well, same day, different war...
Bibi's shabbas goy is getting uppity these days and thinks he can tell >>>>>>> Bibi what to do. Interesting days ahead.
Wow ... TDS even here .........
Tisk !
batshit crazy, from the Librals prophesying complete societal
collapse from Trump, sonofabitch, to those believing in the second
coming of Trump, son of God.
He's just a very naughty boy.
Read a stat today, only 1 in 10 Europeans think the Americans are friends.
If one takes "American" to mean "from the USA", it's not hard to imagine that.
Besides what was already a not so stellar reputation, we now have that
nation repeatedly threatening to invade and annex parts of Denmark.
And, at the same time the USA takes strategic advantage of Washington
Treaty allied military installations in Europe for their middle east
warfare - at the very least they've been using FAP Air Base no. 4 - they claim their allies "aren't helping" in the war. (But what war, you may
ask, given that reportedly there is no war going on, according to a US citizen called [reads notes] Donald John Trump.)
This besides [gestures] everything else the US administration has been
doing.
Of course it isn't fair to extend judgement of the US administration to
all the US residents and citizens. Just like it wouldn't be fair to
extend any dissatisfaction with Japan to anybody of japanese heritage in
the USA after Pearl Harbor.
On 11/06/2026 07:28, rbowman wrote:
On Thu, 11 Jun 2026 01:16:32 -0400, c186282 wrote:
Note those Euros got to think of the USA as "Uncle Money-Bags" for
a LONG time.
The US wanted to be the big dog after WWII; the bill is coming due.
Indeed it is. Galloping inflation, exports crashing, unemployment on the rise.
Crippling healthcare costs. No broadband.
On 11/06/2026 07:52, Richard Kettlewell wrote:
At least to an extent, Germany chose non-Russian gas because Ukraine
blew up the undersea pipeline... they’ve mostly got their heads turned
back round to realizing that Russia is a threat again by now though.
Russia bribed and blackmailed better than The USA.
Russian gas was cheap and it allowed Germany to pretend that solar
panels and windmills actually worked.
Now Germany will start building nuclear power again.
Also the EU is not famous for being cheap as a place to do business, if
the US is running a goods trade deficit with it then that seems like a
skill issue. What are you guys playing at?! Hire some competent
managers.
And Ukraine has blown up more than one Russian pipeline. There is no
fuel in Western Russia to be had at all.
On 11/06/2026 06:36, c186282 wrote:and-exports.php
The USA can supply JUST enough petrochemicals to
keep the EU alive. Not 'healthy', but alive.
The USA cant supply itself alone.
"The United States remained a net crude oil importer in 2022, importing
about 6.28 million b/d of crude oil and exporting about 3.58 million
b/d."
https://www.eia.gov/energyexplained/oil-and-petroleum-products/imports-
Hows that cheap pump gas doing pal?
CodeBlocks and related can provide a good IDE for C/C++ development
that IS compatible. Not AS easy as the Borland product, but Good
Enough.
You can't have isolationism and then compare yourself with the rest of a world you just said you don't care about. And have cut yourself off
from.
Besides what was already a not so stellar reputation, we now have that
nation repeatedly threatening to invade and annex parts of Denmark.
I had to laugh. US welshed on its commitment to Ukraine, attacked Iran
and then expected NATO to help it wipe its bottom after shitting all
over Hormuz.
Payback for Suez.
On 2026-06-11, Lawrence D’Oliveiro wrote:
On Thu, 11 Jun 2026 03:31:00 GMT, Charlie Gibbs wrote:
Our customers are bigger than we are, so we can't tell them to go
pound sand if they don't like what we have to offer.
Sounds like your vendor-lock-in is not as strong as it should be ...
I thought *all* proprietary software vendors had figured that out ...
In order for vendor lock-in to be usable, you have to have a big share
of the market in place already, at least a near-monopoly. Microsoft can
pull this in some customer segments, but your average software vendor
can't.
(Besides being likely illegal in a lot of places, of course.)
On Thu, 11 Jun 2026 12:03:41 +0100, The Natural Philosopher wrote:
I had to laugh. US welshed on its commitment to Ukraine, attacked Iran
and then expected NATO to help it wipe its bottom after shitting all
over Hormuz.
Payback for Suez.
Are you still hurting over when Eisenhower told Britain, France, and
Israel to back off? That's the last time the US had a harsh word for
Israel.
On 2026-06-11 06:33, c186282 wrote:
On 6/10/26 04:43, Carlos E.R. wrote:
On 2026-06-10 07:03, c186282 wrote:
On 6/9/26 05:07, Carlos E.R. wrote:
On 2026-06-09 09:08, c186282 wrote:
On 6/8/26 21:44, rbowman wrote:
On Mon, 08 Jun 2026 18:08:09 GMT, Charlie Gibbs wrote:
I rejected Apple stuff very early.
The student association at the uni made some deal with Amstrad, and
we could get an Amstrad PC with two flopies at a reasonable price. I
asked them what to choose, a PC or an Apple, and they said that with
a PC they could help me to get software used at uni (meaning pirated
copies), and that I could easily share stuff.
So PC it was, in the Amstrad shape.
'Politics' (and Cheapness) ! :-)
MAC and PC diverged - and never liked the Mac vibe.
The PC world (and usually Linux) just seems to 'think'
like I believe computers should think. Guess I'm "square".
But, as said, some of the GOOD stuff about UNIX did get
me to buy Linux when it first appeared. Lots of floppies.
This was when in-house servers/networking were just
becoming viable for "regular" biz. Linux made that stuff
much better than DOS/Winders did and didn't try to bleed
you for cash.
What I found dismal was the compilers. Coming from the world of
Borland IDEs, programming in C or Pascal was like going back twenty
years. So I did not...
Turbo Pascal changed everything. Vastly more efficient
and fun ! Showed how it COULD be. Have it in a DOS VM
still - but it is kind of constrained to the 8/16 world.
We need a "To_32/64" cross-compiler ! :-)
Modern is the Lazarus/FPC environment - IF you can score
But it took almost two decades to come to the level Borland had by 1997.
And no C IDE.
sub-sub-versions of the various parts that will work
together. BEST bet is their site, not current repos. Have
had less success of late however. However I still write
some stuff in Lazarus - quickest route to a decent working
GUI app - and you can also just use it to make non-GUI FPC
apps as well.
If I have a good Python script that could use more tightening-up
and speed ... I re-do it in Pascal. I like Pascal, seems "elegant"
to me, 'speaks to the soul' perhaps. Will keep using it. Dr. Nick
came up with something GOOD.
ALSO have the old M$ Pascal and 'C' multi-pass compilers
in that VM. Yes, they DO work and every once in awhile I
write some little thing using them. But compared to a
good development IDE they're terribly clunky.
Have been TRYING to find a Modula-3 compiler - IDE or not -
that will actually WORK in Linux. Two or three oft-
mentioned ones but have NEVER been able to get them to
do even a "Hello World" without a zillion weird errors.
The Quebec one is most recommended, but still ...
There's GNU M2 ... also odd ... but M3 was "better"
and I still pref 'native compilers' over the GNU tricks.
DID find a COBOL IDE ... gotta re-install it. Don't
totally, or barely, love COBOL, but it doesn't hurt to
keep yer hand in. "OpenCobolIDE" - last revision 10
years ago alas. Not too bad.
For FORTRAN and 'D' and some others ... install CodeBlocks.
Works most easily if you install the compilers first. Rather
extensive IDE, almost TOO, that reminds of 'Visual' and
the JetBrains products. Always use CodeBlocks when doing 'C'.
Ah, try 'TCC' ... small, fast, suprisingly good and TIGHT.
Of course there are still plenty of 'old' compilers, including
'B' - hey, it's ALMOST 'C' - and even its predecessors. Fun
sometimes.
'Modern' like Rust ... mostly seem to be just less-readable
versions of 'C' without any major advantages for my level
of application. I'll do 'C'.
MOST often do Python these days however, it's become very
All-Purpose and has good string stuff. But it's not always
"best" for EVERYTHING.
Anyway, clearly we remember how clunky it COULD be - and how
a few geniuses made that MUCH better. 2nd and 3rd-gen IDEs,
you could get a lot of good stuff done FAST.
Oh well, I've gone on too long .........
:-)
On 11/06/2026 06:16, c186282 wrote:
On 6/10/26 16:47, The Natural Philosopher wrote:I think you are profoundly mistaken
On 10/06/2026 17:52, Carlos E.R. wrote:
From afar, it seems that the whole American nation have gone
batshit crazy, from the Librals prophesying complete societal
collapse from Trump, sonofabitch, to those believing in the second >>>>> coming of Trump, son of God.
He's just a very naughty boy.
Read a stat today, only 1 in 10 Europeans think the Americans are
friends.
Well the US state, anyway,
Fundamentally the US would at least work towards its long term
interest. Europe was a market as big as the USA and was worth
protecting.
Trump is simply too stupid to understand that. If he cant make a
profit right now, he isn't interested.
Note those Euros got to think of the USA as
"Uncle Money-Bags" for a LONG time.
No wonder they're upset.
Europe sells more to the US than the US sells to Europe. That's not
'money bags' that's a supplier not making what his customers want. See
John Deere etc.
And then when you find that the imports can't be used without US
permission, when you need then, you tend to dump the whole product
lines. See F35.
The USA simply thinks its more important than it is.
It is welcome to boycott European products and welsh on its commitments
to Europe, but it can't expect to maintain its exports or 'frendship'
under such conditions.
Trump still hasn't got past the basic 'you fuck with me once, I won't do business with you again' style of business.
The rest of the world is discovering how little they actually *need* the
USA at all.
Dump Microsoft. Install Linux.
Dump Apple, buy Samsung.
Dump John Deere, Buy Claas
Dump Lockheed, buy Saab
Dump US missiles, buy Ukrainian drones.
Dump Intel, buy Arm.
Dump Boeing, buy Airbus or Embraer.
Europe bought American because it was ok and cheap and the bribes were
good.
Now its none of the above.
I mean even MAGA doesn't make sense. Make America Great Again.
Great, compared with what? North Korea?
You can't have isolationism and then compare yourself with the rest of a world you just said you don't care about. And have cut yourself off from.
United capitalist corporate republic of America. Behind a firewall.
*shrug*. No one cares any more..
On Thu, 11 Jun 2026 11:40:13 +0100, The Natural Philosopher wrote:
You can't have isolationism and then compare yourself with the rest of a
world you just said you don't care about. And have cut yourself off
from.
The US could have been an autarky and maintained neutral relations with
the rest of the world, trading for coffee, tea, and other goods that
aren't feasible. We even have plenty of rare earths, but it was cheaper to buy from Alibaba.
The Constitution was written by wealthy merchants and lawyers and that's
the class that has always ruled. That is crystal clear when that idiot dismissed all concerns by saying 'but the Dow broke 10,000' and the other idiot said 'I love inflation'.
Sadly the alternative is a bunch of woke assholes.
The Natural Philosopher <[email protected]d> wrote:
On 11/06/2026 07:52, Richard Kettlewell wrote:
At least to an extent, Germany chose non-Russian gas because Ukraine
blew up the undersea pipeline... they’ve mostly got their heads turned >>> back round to realizing that Russia is a threat again by now though.
Russia bribed and blackmailed better than The USA.
Russian gas was cheap and it allowed Germany to pretend that solar
panels and windmills actually worked.
Solar panels and "Windmills" DO actually work.
Now Germany will start building nuclear power again.
No, we won't. The problem ist that we need power networks first and additional energy second, both of them _right_ _now_. Our politicians
are lying at us when they pretend that new nuclear power will be there
before 2045 which is 20 years to late to solve current problems.
There is no nuclear technology that will be only quickly enough.
On Thu, 11 Jun 2026 11:52:21 +0100, The Natural Philosopher wrote:
And Ukraine has blown up more than one Russian pipeline. There is no
fuel in Western Russia to be had at all.
Going back to well before Euromaidan there was a strange effect with pipelines that transited the Ukraine. Fuel seemed to evaporate. At least
the Ukrainians were more sophisticated than the Africans who tend to
create large craters when they try to steal fuel.
Have you considered that this final sentence may be something forced
onto you by the others mentioned above, and not actual reality? I think
that, if you think a bit about it, you'll understand that it would
really serve their interests to have you thinking precisely that.
On Thu, 11 Jun 2026 09:06:55 +0100, Nuno Silva wrote:
Besides what was already a not so stellar reputation, we now have that
nation repeatedly threatening to invade and annex parts of Denmark.
While I fully understand Danish pride passing off their problem child
island to someone else wouldn't be all that bad.
On Thu, 11 Jun 2026 12:03:41 +0100, The Natural Philosopher wrote:
I had to laugh. US welshed on its commitment to Ukraine, attacked Iran
and then expected NATO to help it wipe its bottom after shitting all
over Hormuz.
Payback for Suez.
Are you still hurting over when Eisenhower told Britain, France, and
Israel to back off? That's the last time the US had a harsh word for
Israel.
EU ... how much DOES it make anymore ? Seems like
China has taken over.
Anyway, in many ways, the USA had been carrying
Europe on it's back since 1945.
No more.--
are searching desperately for a political class that cares about
them, is competent, and honest.
The Natural Philosopher <[email protected]d> wrote:
are searching desperately for a political class that cares about
them, is competent, and honest.
Does *any* such thing exist?
In must every quarter of the world, the "political class" most often
seems to only care about "the political class", they fein interest in
the average joe sufficient to keep "average joe" voting for them, and
they all seem to be habitual liars.
Now mostly use "CodeBlocks", on Linux. M$ ... not sure WHAT they have
now, "Visual" something ? These are, alas, more complicated than they
NEED to be.
The nations that comprise it are the real power houses,
Europe is a bit light on oil and gas, and the coal has mostly run out,
but its very big on smarts.
The Russians simply stole it themselves and swore blind they had put it
in the pipeline Like Islam, Russia is founded on institutional lying to
the rest of the world, and in the case of Russia, to itself.
Well as the average joe gets smarter, things necessarily change.
Americans are politically almost as dumb as Russians.
On 11/06/2026 18:40, rbowman wrote:
On Thu, 11 Jun 2026 09:06:55 +0100, Nuno Silva wrote:
Besides what was already a not so stellar reputation, we now have that
nation repeatedly threatening to invade and annex parts of Denmark.
While I fully understand Danish pride passing off their problem child
island to someone else wouldn't be all that bad.
What problem is it to Denmark?
On 11/06/2026 18:40, rbowman wrote:
On Thu, 11 Jun 2026 09:06:55 +0100, Nuno Silva wrote:
Besides what was already a not so stellar reputation, we now have that
nation repeatedly threatening to invade and annex parts of Denmark.
While I fully understand Danish pride passing off their problem child
island to someone else wouldn't be all that bad.
What problem is it to Denmark?
On 11/06/2026 18:44, rbowman wrote:
On Thu, 11 Jun 2026 12:03:41 +0100, The Natural Philosopher wrote:
I had to laugh. US welshed on its commitment to Ukraine, attacked Iran
and then expected NATO to help it wipe its bottom after shitting all
over Hormuz.
Payback for Suez.
Are you still hurting over when Eisenhower told Britain, France, and
Israel to back off? That's the last time the US had a harsh word for
Israel.
No, but we remember the US never gives anything out of principle, it
only makes decisions that make it money.
Now it has an idiot in charge who th
to save pennies now and forgoing dollars later, is a clever thing to do,
we realise there is no point in dealing with a completely untrustworthy
USA at all.
Business is built on trust.
No trust. No business
On 12/06/2026 07:52, c186282 wrote:
EU ... how much DOES it make anymore ? Seems likeThe EU makes nothing, It is just a bunch of ten thousand bureaucrats who bribed national leaders to enslave its populations.
China has taken over.
The nations that comprise it are the real power houses,
Europe is a bit light on oil and gas, and the coal has mostly run out,
but its very big on smarts.
It grows food all the way down to Africa and African nations are now
farming at higher efficiencies than ever before.
It produces a range of consumer goods. And farming equipment that works
in Europe's smaller field sizes.
It works with the far east to jointly produce goods that have global
appeal.
It has never been an insular place. It has always been cosmopolitan and
a world trading power. That's what its armies and Navies were for. To protect trade. Unlike the USA.
Anyway, in many ways, the USA had been carryingEurope is still carrying America on its back.
Europe on it's back since 1945.
Trump saw that happening with the USA ... and then aggressively moved
to COUNTER that. Made In USA is incredibly important. USA still had
enough leverage,
so he leveraged that before it was Too Late.
Doesn't fit the vegan hippie-dippy minus-gonads model ? Tough. Not
sure even 'gonads' are required -
ever see how even kindergarten kids organize a threat/dominance
hierarchy - boys AND girls ?
On Fri, 12 Jun 2026 02:37:52 -0400, c186282 wrote:
Now mostly use "CodeBlocks", on Linux. M$ ... not sure WHAT they have
now, "Visual" something ? These are, alas, more complicated than they
NEED to be.
That's one I never heard of. It gets decent reviews, particularly for beginners.
https://www.softwareadvice.com/app-development/code-blocks-profile/
reviews/
Popularity contests are always suspect but VS Code gets a lot of
attention.
https://medium.com/adl-blog/what-makes-visual-studio-code-so- popular-54206c386503
There are extensions for almost anything you can think of. Codium and OSS Code are derived from the open source without the MS telemetry.
The downside is they do not use the Microsoft repository. I was able to install a CircuitPython extension by editing what amounts to the repo
list. It mostly worked but autocompletion and syntax highlighting didn't.
It works fine in VS Code.
On Fri, 12 Jun 2026 12:20:46 +0100, The Natural Philosopher wrote:
The nations that comprise it are the real power houses,
Europe is a bit light on oil and gas, and the coal has mostly run out,
but its very big on smarts.
Well, one nation was the powerhouse but it seems to be running out of
power.
On Sat, 13 Jun 2026 01:46:01 -0400, c186282 wrote:
Trump saw that happening with the USA ... and then aggressively moved
to COUNTER that. Made In USA is incredibly important. USA still had
enough leverage,
so he leveraged that before it was Too Late.
It's unfortunate he is so easily distracted and controlled by the
Zionists. What we need is someone that is consistent and a GOP that
doesn't kneecap him at every turn. Getting rid of the activist judges is necessary. None of that is going to happen with the current system.
On Sat, 13 Jun 2026 01:27:44 -0400, c186282 wrote:
Doesn't fit the vegan hippie-dippy minus-gonads model ? Tough. Not
sure even 'gonads' are required -
ever see how even kindergarten kids organize a threat/dominance
hierarchy - boys AND girls ?
I missed kindergarten so I'm inadequately socialize. They built their hierarchies and I ignored them.
On Fri, 12 Jun 2026 12:20:46 +0100, The Natural Philosopher wrote:A fundamental difference between Europe and the USA is that despite
The nations that comprise it are the real power houses,
Europe is a bit light on oil and gas, and the coal has mostly run out,
but its very big on smarts.
Well, one nation was the powerhouse but it seems to be running out of
power.
On 6/12/26 14:16, rbowman wrote:
On Fri, 12 Jun 2026 12:20:46 +0100, The Natural Philosopher wrote:
The nations that comprise it are the real power houses,
Europe is a bit light on oil and gas, and the coal has mostly run out,
but its very big on smarts.
Well, one nation was the powerhouse but it seems to be running out of
power.
The USA is gaining "power", rapidly, in many
ways.
You can hate Trump, but he DOES seem to
have the Better Paradigm down pretty well.
Better the USA than most anyone else out there.
Think about it.
Think Vlad or Xi or Kim or the ayatollahs will
make it all 'better' for you and all ??? They
are all Dark Ages conquerors - blood and horror
and constant terror.
On Fri, 12 Jun 2026 12:02:32 +0100, The Natural Philosopher wrote:
The Russians simply stole it themselves and swore blind they had put it
in the pipeline Like Islam, Russia is founded on institutional lying to
the rest of the world, and in the case of Russia, to itself.
https://archive.is/6q9Gp
"HOW BRITAIN BECAME AS POOR AS MISSISSIPPI"
Perhaps you should shovel out your own stable. Has Starmer resigned yet?
Not a good sign when his buddy quit since there is no money for his war
toys. It's reminiscent of the '30s when Chamberlain and Halifax were
trying to figure out how to wage war when the toy cupboard was bare. They managed to pull it off. Can the current administration?
On Fri, 12 Jun 2026 16:46:58 +0100, The Natural Philosopher wrote:
Well as the average joe gets smarter, things necessarily change.
Americans are politically almost as dumb as Russians.
Says someone from a country that fucked itself out of an empire.
On Fri, 12 Jun 2026 12:07:51 +0100, The Natural Philosopher wrote:
On 11/06/2026 18:40, rbowman wrote:
On Thu, 11 Jun 2026 09:06:55 +0100, Nuno Silva wrote:
Besides what was already a not so stellar reputation, we now have that >>>> nation repeatedly threatening to invade and annex parts of Denmark.
While I fully understand Danish pride passing off their problem child
island to someone else wouldn't be all that bad.
What problem is it to Denmark?
https://en.wikipedia.org/wiki/Economy_of_Greenland
Unless someone finds worthwhile mineral resources and finds a way to
exploit them it's a massive drain on the economy.
There is also grumbling
among the natives about independence although I have no idea how they
would make a go of it.
There's a reason the Norse packed up their boats and left. Denmark is
touchy since they've lost territory since Kalamr and there isn't much
left.
On 6/13/26 02:20, rbowman wrote:
On Sat, 13 Jun 2026 01:46:01 -0400, c186282 wrote:
Trump saw that happening with the USA ... and then aggressively
moved
to COUNTER that. Made In USA is incredibly important. USA still had >>> enough leverage,
so he leveraged that before it was Too Late.
It's unfortunate he is so easily distracted and controlled by the
Zionists. What we need is someone that is consistent and a GOP that
doesn't kneecap him at every turn. Getting rid of the activist judges is
necessary. None of that is going to happen with the current system.
WHAT Marxo-Commie shit ARE you reading ???
Trump is anything but a 'zionist slave'.
EXPAND your reading list.
On 6/13/26 02:20, rbowman wrote:
On Sat, 13 Jun 2026 01:46:01 -0400, c186282 wrote:
Trump saw that happening with the USA ... and then aggressively
moved to COUNTER that. Made In USA is incredibly important. USA
still had enough leverage,
so he leveraged that before it was Too Late.
It's unfortunate he is so easily distracted and controlled by the
Zionists. What we need is someone that is consistent and a GOP that
doesn't kneecap him at every turn. Getting rid of the activist judges
is necessary. None of that is going to happen with the current system.
WHAT Marxo-Commie shit ARE you reading ???
The short answer to who broke Britain is of course Tony Blair, the EU
and the Russians.
On Sat, 13 Jun 2026 13:58:06 +0100, The Natural Philosopher wrote:Yup. Agree with that.
The short answer to who broke Britain is of course Tony Blair, the EU
and the Russians.
Blair, Clinton, and W were all carved from the same neoliberal turd. Bush
II was another case of who do you vote for when the other choice is that
fat, hypocritical, windbag, Gore.
Which was the smartest thing to do.
Unlike other nations, the UK never wanted and empire for the power.
It was simply a way to ensure global trade.
On 12/06/2026 20:17, rbowman wrote:
Unless someone finds worthwhile mineral resources and finds a way to
exploit them it's a massive drain on the economy.
It's less than $1bn 0.2% of Denmarks GDP
There's a reason the Norse packed up their boats and left. Denmark isRight, who told you that?
touchy since they've lost territory since Kalamr and there isn't much
left.
More Trumpian propaganda?
Eu fears britain. Emperor's new clothes etc. Destroying UK and making
it EU vassal state is the agenda.
On Sat, 13 Jun 2026 20:36:51 +0100, The Natural Philosopher wrote:
Eu fears britain. Emperor's new clothes etc. Destroying UK and making
it EU vassal state is the agenda.
Deutschland uber alles. It took a while but Germans are patient.
On 6/13/26 02:20, rbowman wrote:
On Sat, 13 Jun 2026 01:46:01 -0400, c186282 wrote:
Trump saw that happening with the USA ... and then aggressively
moved
to COUNTER that. Made In USA is incredibly important. USA still had >>> enough leverage,
so he leveraged that before it was Too Late.
It's unfortunate he is so easily distracted and controlled by the
Zionists. What we need is someone that is consistent and a GOP that
doesn't kneecap him at every turn. Getting rid of the activist judges is
necessary. None of that is going to happen with the current system.
WHAT Marxo-Commie shit ARE you reading ???
Trump is anything but a 'zionist slave'.
EXPAND your reading list.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,123 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 34:42:24 |
| Calls: | 14,371 |
| Files: | 186,380 |
| D/L today: |
1,067 files (304M bytes) |
| Messages: | 2,540,617 |