Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.misc > #87295 > unrolled thread

The boring Linux habit that saves machines

Back to article view | Back to comp.os.linux.misc

Contents

  The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-05-30 22:28 +0000
    Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-05-30 23:51 -0400
      Re: The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-05-31 04:23 +0000
        Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-05-31 02:26 -0400
          Re: The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-05-31 06:41 +0000
            Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-05-31 03:37 -0400
              Re: The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-05-31 07:46 +0000
                Re: The boring Linux habit that saves machines Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-06 08:55 +0000
                  Re: The boring Linux habit that saves machines "Carlos E.R." <robin_listas@es.invalid> - 2026-06-06 12:07 +0200
                    Re: The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-06-06 10:14 +0000
                      Re: The boring Linux habit that saves machines "Carlos E.R." <robin_listas@es.invalid> - 2026-06-06 13:06 +0200
                        Re: The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-06-06 11:12 +0000
                          Re: The boring Linux habit that saves machines Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-07 02:45 +0000
                      Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-07 05:13 -0400
                    Re: The boring Linux habit that saves machines Rich <rich@example.invalid> - 2026-06-06 18:30 +0000
                      Re: The boring Linux habit that saves machines "Carlos E.R." <robin_listas@es.invalid> - 2026-06-06 20:49 +0200
                  Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-07 02:00 -0400
            Re: The boring Linux habit that saves machines Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-06 09:07 +0000
              Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-07 02:11 -0400
            Re: The boring Linux habit that saves machines Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-06 09:10 +0000
              Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-07 02:15 -0400
        Re: The boring Linux habit that saves machines Anssi Saari <anssi.saari@usenet.mail.kapsi.fi> - 2026-06-01 12:20 +0300
          Re: The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-06-01 09:38 +0000
            Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-02 02:20 -0400
              Re: The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-06-02 11:08 +0000
                Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-02 23:58 -0400
                  Re: The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-06-04 11:47 +0000
                    Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-04 11:57 -0400
                      Re: The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-06-05 12:53 +0000
                        Re: The boring Linux habit that saves machines Richard Kettlewell <invalid@invalid.invalid> - 2026-06-05 17:35 +0100
                          Re: The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-06-05 16:42 +0000
                          Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-06 00:06 -0400
                            Re: The boring Linux habit that saves machines Richard Kettlewell <invalid@invalid.invalid> - 2026-06-06 10:35 +0100
                              Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-07 03:35 -0400
                                Re: The boring Linux habit that saves machines The Natural Philosopher <tnp@invalid.invalid> - 2026-06-07 13:39 +0100
                                Re: The boring Linux habit that saves machines Richard Kettlewell <invalid@invalid.invalid> - 2026-06-07 14:41 +0100
                                  Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-08 00:04 -0400
                                    Re: The boring Linux habit that saves machines The Natural Philosopher <tnp@invalid.invalid> - 2026-06-08 09:34 +0100
                                Re: The boring Linux habit that saves machines Lars Poulsen <lars@beagle-ears.com> - 2026-06-07 08:00 -0700
                                  Re: The boring Linux habit that saves machines Richard Kettlewell <invalid@invalid.invalid> - 2026-06-07 16:35 +0100
                                  Re: The boring Linux habit that saves machines Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-07 23:48 +0000
                                    Re: The boring Linux habit that saves machines Nuno Silva <nunojsilva@invalid.invalid> - 2026-06-08 00:53 +0100
                                    Re: The boring Linux habit that saves machines Richard Kettlewell <invalid@invalid.invalid> - 2026-06-08 08:26 +0100
                                  Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-08 00:11 -0400
                            Re: The boring Linux habit that saves machines The Natural Philosopher <tnp@invalid.invalid> - 2026-06-06 10:39 +0100
                              Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-07 03:44 -0400
                        Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-05 23:55 -0400
                          Re: The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-06-06 09:40 +0000
                            Re: The boring Linux habit that saves machines Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-07 02:47 +0000
                              Re: The boring Linux habit that saves machines "Carlos E.R." <robin_listas@es.invalid> - 2026-06-07 13:58 +0200
                                Re: The boring Linux habit that saves machines Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-06-07 20:40 +0000
                                  Re: The boring Linux habit that saves machines Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-07 23:39 +0000
                                  Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-07 23:00 -0400
                                    Re: The boring Linux habit that saves machines Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-06-08 04:36 +0000
                                      Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-08 02:30 -0400
                                        Re: The boring Linux habit that saves machines The Natural Philosopher <tnp@invalid.invalid> - 2026-06-08 09:19 +0100
                                        Re: The boring Linux habit that saves machines rbowman <bowman@montana.com> - 2026-06-08 14:23 +0000
                                      Re: The boring Linux habit that saves machines Nuno Silva <nunojsilva@invalid.invalid> - 2026-06-08 09:54 +0100
                                    Re: The boring Linux habit that saves machines rbowman <bowman@montana.com> - 2026-06-08 14:12 +0000
                              Re: The boring Linux habit that saves machines Richard Kettlewell <invalid@invalid.invalid> - 2026-06-07 14:30 +0100
                                Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-07 23:38 -0400
                                  Re: The boring Linux habit that saves machines The Natural Philosopher <tnp@invalid.invalid> - 2026-06-08 09:22 +0100
                            Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-07 04:03 -0400
                  Re: The boring Linux habit that saves machines Rich <rich@example.invalid> - 2026-06-06 18:42 +0000
                Re: The boring Linux habit that saves machines Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-06 08:53 +0000
                  Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-07 01:53 -0400
            Re: The boring Linux habit that saves machines Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-06 08:52 +0000
              Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-07 01:41 -0400
        Re: The boring Linux habit that saves machines Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-06 06:41 +0000
          Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-06 03:07 -0400
            Re: The boring Linux habit that saves machines "Carlos E.R." <robin_listas@es.invalid> - 2026-06-06 13:28 +0200
            Re: The boring Linux habit that saves machines rbowman <bowman@montana.com> - 2026-06-06 19:16 +0000
              Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-07 05:18 -0400
                Re: The boring Linux habit that saves machines rbowman <bowman@montana.com> - 2026-06-07 18:59 +0000
          Re: The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-06-06 09:40 +0000
            Re: The boring Linux habit that saves machines Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-07 02:51 +0000
            Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-07 04:56 -0400
    Re: The boring Linux habit that saves machines "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2026-05-31 16:43 +0800
      Re: The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-05-31 08:48 +0000
      Re: The boring Linux habit that saves machines Stéphane CARPENTIER <sc@fiat-linux.fr> - 2026-05-31 10:16 +0000
        Re: The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-05-31 10:22 +0000
    Re: The boring Linux habit that saves machines Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-06 06:38 +0000
      Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-06 03:04 -0400
        Re: The boring Linux habit that saves machines "Carlos E.R." <robin_listas@es.invalid> - 2026-06-06 13:32 +0200
          Re: The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-06-06 11:34 +0000
            Re: The boring Linux habit that saves machines "Carlos E.R." <robin_listas@es.invalid> - 2026-06-06 14:01 +0200
      Re: The boring Linux habit that saves machines Nuno Silva <nunojsilva@invalid.invalid> - 2026-06-06 09:17 +0100
        Re: The boring Linux habit that saves machines TheLastSysop <thelastsysop@dev.null> - 2026-06-06 09:40 +0000
          Re: The boring Linux habit that saves machines Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-07 02:57 +0000
            Re: The boring Linux habit that saves machines Nuno Silva <nunojsilva@invalid.invalid> - 2026-06-07 16:11 +0100
          Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-07 04:18 -0400
        Re: The boring Linux habit that saves machines c186282 <c186282@nnada.net> - 2026-06-07 01:33 -0400

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

#87664

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?

> 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.

You know why? Why not use the public/private key protocols directly,
for the entire communication?

It’s because they’re about a thousand times slower than secret-key
protocols, that’s why. Just not practical for high-volume use.

> 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.

[toc] | [prev] | [next] | [standalone]

#87665

On 2026-06-08, Lawrence D’Oliveiro wrote:

> 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?

This really goes counter what I've learned, symmetric and asymmetric
applying to whether the secret is shared or not.

If I'm understanding correctly, by your definition, RSA would be
symmetric?


-- 
Nuno Silva

[toc] | [prev] | [next] | [standalone]

#87686

Lawrence D’Oliveiro <ldo@nz.invalid> 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.

-- 
https://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#87678

On 6/7/26 11:00, Lars Poulsen wrote:
> On 2026-06-07 00:35, c186282 wrote:
>> On 6/6/26 05:35, Richard Kettlewell wrote:
> [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 ???
> [snip]
> 
> I think what you say you "don't get" is this:

   SHAME on me !!!

   However I can read what those to DO "get" crypto
   have to say.

   Past couple of years they're starting to say
   "be cautious".

> 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?

   Hmm ... saved all my cloud backups as symmetric.

   But banking/biz web work is asymmetric.

   Won't be much biz after Xi disappears all our money.

[toc] | [prev] | [next] | [standalone]

#87595

On 06/06/2026 05:06, c186282 wrote:
> Hey, some STILL think that standard ZIP-file
>    passwords are secure 🙂
Silly boolean logic remark. Noth9ng is 'secure' just 'secure enough' to 
put you on a decent part of the cost-benefit curve

-- 
"Anyone who believes that the laws of physics are mere social 
conventions is invited to try transgressing those conventions from the 
windows of my apartment. (I live on the twenty-first floor.) "

Alan Sokal

[toc] | [prev] | [next] | [standalone]

#87634

On 6/6/26 05:39, The Natural Philosopher wrote:
> On 06/06/2026 05:06, c186282 wrote:
>> Hey, some STILL think that standard ZIP-file
>>    passwords are secure 🙂
> Silly boolean logic remark. Noth9ng is 'secure' just 'secure enough' to 
> put you on a decent part of the cost-benefit curve

   Yea yea, you're So Superior ........  :-)

   In SOME situations, even crappy ZIP passwords
   CAN serve well.

   In others, you need AES-256 or equiv.

   There's NO one-size-fits-all ... it all
   Just Depends on your exposure/relevance.

   Such is the world.

[toc] | [prev] | [next] | [standalone]

#87565

On 6/5/26 08:53, TheLastSysop wrote:
>> On Thu, 4 Jun 2026 11:57:34 -0400, c186282 <c186282@nnada.net> 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.

[toc] | [prev] | [next] | [standalone]

#87596

>On Fri, 5 Jun 2026 23:55:38 -0400, c186282 <c186282@nnada.net> wrote:
>On 6/5/26 08:53, TheLastSysop wrote:
>>> On Thu, 4 Jun 2026 11:57:34 -0400, c186282 <c186282@nnada.net> 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.

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.

-- 
TheLastSysop <thelastsysop@dev.null>
"I survived the great rm -rf / rehearsal and all I got was this .signature."

[toc] | [prev] | [next] | [standalone]

#87621

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? ;)

[toc] | [prev] | [next] | [standalone]

#87645

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.

-- 
Cheers, Carlos.
ES🇪🇸, EU🇪🇺;

[toc] | [prev] | [next] | [standalone]

#87662

On 2026-06-07, Carlos E.R. <robin_listas@es.invalid> 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.

-- 
/~\  Charlie Gibbs                  |  No artificial
\ /  <cgibbs@kltpzyxm.invalid>      |  intelligence was
 X   I'm really at ac.dekanfrus     |  used in the creation
/ \  if you read it the right way.  |  of this post.

[toc] | [prev] | [next] | [standalone]

#87663

On Sun, 07 Jun 2026 20:40:08 GMT, Charlie Gibbs wrote:

> 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.

Now, you see, I wouldn’t go that far. On a POSIX system, those
characters would not be technically “invalid”, because then the OS
would have failed the filesystem operation with an error instead of
permitting the creation of such filenames.

And if they’re valid filenames, it *is* possible to deal with them in
a POSIX shell. I wouldn’t call it “a pain in the ass”, it just takes
some careful programming.

> 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.

Whenever I need a “/” in a file/directory name, I substitute the
Unicode lookalike ”∕” instead. Works just as well visually, but causes
no problems with the OS or scripts. ;)

[toc] | [prev] | [next] | [standalone]

#87673

On 6/7/26 16:40, Charlie Gibbs wrote:
> On 2026-06-07, Carlos E.R. <robin_listas@es.invalid> 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.

   Biz doesn't work without employees  :-)

   Long nasty narrative filenames with lots of
   punctuation became our norm and nobody would
   stop doing it. A 'human nature' issue alas.

   Yes, 8+3 ALL CAPS is indeed easy to deal with, but
   at this point, just forget it. Got to adapt yer code
   to the humans.

> 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.

   DID briefly work with Micro Focus ... also translating
   a number of old apps to more 'modern' langs.

   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 ???"

   Want fun - try moving dozens of old FORTRAN stat apps
   to GWBASIC ... and HAND-CODING the math-coprocessor
   instructions as DATA statements. Ah, the Good Old Days ! :-)

   No, they couldn't afford a good FORTRAN compiler at
   the time .....

> 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.

   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 !  :-)

   Yes, that sometimes included mystery "invisible" characters
   from the word processor.

   UTF ... ever tried to FIND those neat old angle/block/etc
   char sets that came with the old IBM-PCs, ASCII 129+ ? Made
   for NICE terminal forms really easy.

   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 .......

[toc] | [prev] | [next] | [standalone]

#87680

On 2026-06-08, c186282 <c186282@nnada.net> 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.  :-)

-- 
/~\  Charlie Gibbs                  |  No artificial
\ /  <cgibbs@kltpzyxm.invalid>      |  intelligence was
 X   I'm really at ac.dekanfrus     |  used in the creation
/ \  if you read it the right way.  |  of this post.

[toc] | [prev] | [next] | [standalone]

#87684

On 6/8/26 00:36, Charlie Gibbs wrote:
> On 2026-06-08, c186282 <c186282@nnada.net> 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.

[toc] | [prev] | [next] | [standalone]

#87688

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.


-- 
The New Left are the people they warned you about.

[toc] | [prev] | [next] | [standalone]

#87695

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.

[toc] | [prev] | [next] | [standalone]

#87692

On 2026-06-08, Charlie Gibbs wrote:

> On 2026-06-08, c186282 <c186282@nnada.net> 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.

>> 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".

Any chance this is automated behaviour from the document editor? I 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.


-- 
Nuno Silva

[toc] | [prev] | [next] | [standalone]

#87694

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.

[toc] | [prev] | [next] | [standalone]

#87649

Lawrence D’Oliveiro <ldo@nz.invalid> 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...

-- 
https://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

Back to top | Article view | comp.os.linux.misc

csiph-web