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 Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-06-08 18:08 +0000
                                        Re: The boring Linux habit that saves machines The Natural Philosopher <tnp@invalid.invalid> - 2026-06-08 21:24 +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 Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-06-08 18:08 +0000
                                          Re: The boring Linux habit that saves machines "Carlos E.R." <robin_listas@es.invalid> - 2026-06-08 22:42 +0200
                                      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 Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-06-08 18:08 +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 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

#87703

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

It had its uses.

For example create a data file, which starts with some descriptive text, 
including the name of the program to open the file with, and the <EOF>, 
followed by the actual data.

The user would simply "type data.dat" and the instructions would print 
nicely on the screen.



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

[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]

#87699

On 2026-06-08, rbowman <bowman@montana.com> 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?

-- 
/~\  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]

#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]

#87676

On 6/7/26 09:30, Richard Kettlewell wrote:
> 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...

   Oooh ! Nasty !  :-)

   Not that I totally disagree.

   They kept expanding shells to do more and more
   odd things - and the syntax became bizarre and
   not even REMOTELY "self documenting".

   Shell scripts DO still have a useful place - IF
   you keep 'em simple.

   Anything beyond that, script in Python.

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

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

#87689

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'

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

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

#87635

On 6/6/26 05:40, TheLastSysop wrote:
>> 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.

   DID look into that ... a kinda 'meta-data' file sent
   along with the original which showed its TRUE, nasty,
   Winders name and such.

   But it was more complexity than I was willing to indulge.
   Just created a cheap and dirty work-around. Creating TWO
   files for every ONE ... just didn't like it.

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

   HAVE had a few 3AM sessions  :-)

   Where I worked there WAS "The Mission" idea, so we'd
   put in the extra time as required without complaint.
   Latter bosses kind of destroyed that alas. Fuck 'em.
   I had over 40 years ... and LEFT.

   Anyway, latter Winders file-names ... a nightmare -
   and not ONLY for -ix.

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

#87610

c186282 <c186282@nnada.net> wrote:
> 
>   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 !  :-)

It won't.  By your own admission they "couldn't program their way out 
of a wet paper bag" so they won't bother to even look into your 
utility.

So long as it continues to work, they will use it.  When something 
changes somewhere that stops it from working, they will have management 
create a new replacement rather than repair the existing tool.

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

There are folks out there who don't understand the concept of "zipping 
up files".  There are loads of others (mostly the way younger crowd who 
have only ever owned a cell phone as their "one and only computer" who 
do not even understand the concept of "files".

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

Given that Phil Zimmermann did not release PGP until 1991 [1], that can not 
have been the 1980's.

Granted, 1991 is close enough for 35 year old memories to get fuzzy.



[1] https://en.wikipedia.org/wiki/Pretty_Good_Privacy

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

#87590

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>

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

#87629

On 6/6/26 04:53, Lawrence D’Oliveiro wrote:
> 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>


   Hah Hah Hah Hah !!!  :-)

   Somewhere recently I described having to craft
   a funky fix for Vista+ Winders file names. Just
   EVIL !  :-)

   Took me a few days, even when I was young and hot.

   Winders sub-microscopic PERMISSIONS ... what a HORROR !!!
   Dropped 95% of that BS on Linux shares.

   Seems SOME want to claim that INSANE permissions/ownership
   params are somehow "better".

   Not too long before I retired I was trying to use
   actual Win libs/utils to cope with the deep deep
   deep 'permissions' mess. NOT entirely successful.
   What an incredible MESS !!!

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

#87589

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.

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

#87628

On 6/6/26 04:52, Lawrence D’Oliveiro wrote:
> 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.

   Well ... "better" ........

> Just a note for those whose primary experience might be on ... other
> ... platforms.

   At this point in time there's not THAT much more
   "superiority" in data density/utility between the
   popular file systems. CPU speed just destroys most
   any diff between efficient/inefficient file systems.

   Corporate - make it POLICY to store Important Stuff
   on the Linux NETWORK SHARES rather than store locally.
   Started that policy as soon as there WERE network
   shares (Novell Netware + Win95 + coax). HELPED
   a lot. Linux came along a bit later ... but the
   paradigm was ready.

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

#87583

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

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

#87587

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.

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

#87605

On 2026-06-06 09:07, c186282 wrote:
> 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.

No, disk space is no longer cheap. Price has doubled.

> 
>    Basically, 'cloud' is in case the office gets
>    hit by a tornado or giant fire.
> 


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

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

#87614

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.

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

#87641

On 6/6/26 15:16, rbowman wrote:
> 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.

   You've got it ! .

   DID have one ransomware event - SOMEBODY (think I know who)
   clicked on one of those "Click Me To Save" pop-ups.

   Had to completely re-do several Win boxes though, just to
   be sure.

   Anyway, the hard-2-get-at Linux backup files WERE the
   salvation. Took all day, but I did get everything back.

   Payroll FIRST, of course !  :-)

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

#87655

On Sun, 7 Jun 2026 05:18:42 -0400, c186282 wrote:

>    Payroll FIRST, of course !

In this case the company had moved that to Insperity. PEOs are a little 
strange. 

https://en.wikipedia.org/wiki/Professional_employer_organization

Along with them being the employer of record we got the HR slop of 
mandatory sensitivity and cybersecurity training videos the onsite HR 
people never had. 

Showing class they emailed me that I was fired on Christmas Day. Not 
unexpected since the division had shutdown the previous year and I agreed 
to stick around for a year to handle any loose ends with clients as they 
looked for new vendors but the timing and the tone of the email telling me 
how to apply for unemployment smelled like the work of Claude.

No gold watch either :)

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

#87598

>On Sat, 6 Jun 2026 06:41:34 -0000 (UTC), Lawrence
>=?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> 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.

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

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

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

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

csiph-web