Re: SSD TBW

On 8/23/2026 11:09 AM, Scott Dorsey wrote:
> Don Y  <[email protected]> wrote:
>> On 8/23/2026 9:08 AM, Scott Dorsey wrote:
>>>
>>> There's no reason you couldn't have a jpeg-comparing function these days.
>>> That's the marvel of the Unix philosophy... modularity.
>>
>> Yet you don't see a "-jpeg" option to diff...
> 
> No.  Read the man page, diff calls itself a tool for comparing text files.

Exactly, because the developers were only concerned about text files.

> If you want to compare jpeg files you use odiff.  And you can call odiff
> from your source code control system if it's modular.

But you have to have that ported to your system.  because the developers
were only concerned about text files.

>>> Well, yes, because in the Unix world most useful files can be treated that
>>> way.  Remember that "version control" started out initially as "source code
>>> control."
>>
>> "Text" does nothing for you -- except let you use a text editor to
>> maintain it.
> 
> And it makes it much easier for human beings to maintain.  If you'd like,
> you can dispose of the compiler and assembler and just create executables
> with cat > a.out but you're not going to do that because you are a human
> being and human beings work well with text.

Text makes *some* things easier to maintain.  So, use a tool that
manages text to manage things that are inherently text.

Text is a piss poor match for graphic entities and other abstractions.

But, "the developers" weren't concerned with those issues.

[See the pattern?]

>> Note that vipw(8) adds value -- it ensures all of the passwd-associated
>> files remain in a consistent format.  BECAUSE IT IS AWARE OF THAT FORMAT,
>> even though the files still identify as "text" (no magic numbers, etc.)
> 
> Yes, and emacs has context-sensitive modes for C and for English.  If you
> like format-specific editors you can use them.  Personally they drive me
> up the wall and I don't like them, but it's your call as a user.

Different issue.  That's (almost) entirely one of presentation.
If emacs was continuously checking your code for BUGS, automatically
checking out the file from whichever VCS tracks it, etc. that would be
more comparable.

Note that vipw doesn't enforce passwd strength rules.  Or, other
"best practices".  Yet, it ensures all of the "databases" are
updated in sync and locks them so another "administrator" can't
compete with your actions -- which is moreso than, e.g., editing
login.conf.

>> [I have all of the configuration details for my machines in a series
>> of relational databases.  I had initially thought of backporting
>> this into the BSD distros that I use but realized that effort
>> would likely offend "historical purists".  So, instead, I have
>> scripts that query the RDBMS and know how to "write" the appropriate
>> files that are then copied into each host.  My *current* project
>> doesn't rely on such a kludge and tools directly access the records
>> in the appropriate tables.  Constrraints on the tables ensure that
>> the tools need not validate their input -- the RDBMS won't accept
>> bad data and is "guaranteed" to maintain the integrity of the data
>> given to it.  My, what a novel idea...]
> 
> This is very much contrary to the Unix philosophy.

cf. systemd?  rc.d?  inetd.conf?  Have you seen how init has evolved
over the years in different "flavors" of UNIX?

I.e., people seem to be highly selective in what they consider
The UNIX Way.

> If you like it, that
> is fine but it's not Unixlike.  But I am not sure why you are taking this
> thread so far afield.
It is all related to facilitating your maintenance of <whatever> -- sources,
text (flat) "databases", configuration files, bitmapped fonts, etc.  Tools
should make those activities simpler, quicker and more robust.  E.g., if your
VCS tells me two (source) files differ (but the binaries end up identical)
then it has not helped me; the differences are not related to whatever issue
has prompted me to look at them.  ("move along; nothing here")

My use of an RDBMS ensures all of the data embedded within it complies
with the constraints placed on them (e.g., MACs have to be unique,
must be expressed in a certain form, etc.) removing that responsibility
from the individual who is creating those data.  And, ensuring the
system remains in a consistent state.

[If this runs *in* the managed system, then changes to those data
can initiate upcalls to the consumers having interest in them to ensure
they update their internal copies of those data]

My *not* backporting it INTO those systems is an acknowledgement of
the effort to create Slowaris, NetBSD, FreeBSD, etc. ports of the
same tool/mechanism, despite how kludgey composing files offline and
pasting them into their respective hosts.  And the likely "resistance"
to such changes.