Re: SSD TBW

On 8/23/2026 12:36 PM, Scott Dorsey wrote:
> Don Y  <[email protected]> wrote:
>> On 8/23/2026 11:09 AM, Scott Dorsey wrote:
>>>> 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.
> 
> The same is the case for vipw.  It is a language-sensitive editor which
> does some rudimentary syntax checking.  I don't like these things.  Some
> people do.

Most "emacs modes" are effectively pretty-printers or syntax lookahead
hooks.  Tools that their cr3ators think "help you type".

vipw, at least, ensures all of the passwd-related files are updated
in sync ensuring they remain self-consistent.

You would likely hate DBMSs as they not only check syntax but
enforce constraints on values and relations.  Your efforts
simply being refused until you comply.

[The upside effect of this is mistakes don't get into the
dataset -- if you;ve designed your constraints properly.]

>>> 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?
> 
> Yes, and many systems are diverging very far from the traditional Unix
> philosophy.  That doesn't mean the traditional Unix philosophy is a bad
> one.

It is dated.  It originated out of the need for "a few" to get to work
writing applications, NOT designing An OS For The Ages.

Similarly, MS's products were created for other applications
(an OS without applications is just a room heater)

>> I.e., people seem to be highly selective in what they consider
>> The UNIX Way.
> 
> Oh, I don't think anyone has ever claimed systemd was the UNIX way.  They
> might claim a lot of benefits for them, but it is very divergent from
> the philosophy in Thompson and Richie.
> 
>>> 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")
> 
> Here is the thing about Unix.  It's a box of tools.  If you don't like this
> tool, use another one.  If you can't find something you like, write one...
> but you likely won't have to because tools are designed to be modular to
> allow you to change them.

It's a (relatively) *primitive* box of tools.  The analogy being a brace,
hand saw, carpenters hammer, etc.  We've moved on from those -- yet still
cling to UNIX's toolsets.

> If you like using a giant database instead, you can do that.  But I won't,
> and I explained why.  And that's what's nice about Unix, you can set your
> environment up however you want.
And it remains (largely) fixed in the past so folks who don't want to move
forward don't have to.

Yeah, it's nice that I can modify the kernel without needing a source
license from AT&T.  But, *having* to modify the kernel means it isn't
meeting my needs.

Or, add support for ethers() to dhcpd.

[And, how many people actually *have* modified it?  It is reminiscent of
"stereos"/hifi's in the 70's -- every9one wanted to tinker but not really
*do* anything, save comment on their particular collection of OTS components]

And, correct, no one else has to adopt my approach.  The flip side
of that is not to bother sharing those implementations.

As ldo (?) said, elsewhere in this thread, "if you want others to
participate in your project..." presupposes you *need* or want
that participation (help?).  And, if neither applies, then
what (and if) you share is entirely of your own choosing.  Usually,
someone conceiving of a "need" has thought about it far more than
any newcomers to the party.

If no one else has realized a particular need, then they aren't
"missing out".  And, if they *have*, what obligation or motivation
to assist them?

I find the database approach saves me a lot of time maintaining my
existing herd (a few dozen boxen) and is invaluable in maintaining
the hosts in my current project (a few hundred boxen).  Human
labor is costly.  And, likely to make errors if something isn't
looking over their shoulders.

Keeping a log of changes to the RDBMS (the functional equivalent of
a VCS) makes it relatively easy to see where/how something "broke".

[Local hospital has 2800 employees (not all of which have workstations)
and over 100 IT staff.  Suddenly, the cost of hardware and software is
insignificant when you think of the burden imposed!]