Re: SSD TBW

On 8/23/26 19:09, 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.
> 
> 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.
> 
>>> 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.
> 
>> 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.
> 
>> [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.  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.
> --scott
> 

Quite. One tool to solve one problem, well, with the
ability to chain several to get the desired result.

 From an efficiency pov, makes sense that all data is
stored transparently as a sequence of bytes. It's the
responsibility of sw layers above, to give meaning to
that stream.

The shear elegance of unix does seem to be missed by
many.

Chris