From Newsgroup: comp.misc

I found out that a common measure of the projected life of an SSD is
being given in units of rCLterabytes writtenrCY (TBW). This will typically
be much larger than the capacity of the drive itself, because it
includes the sum total of all write operations on the drive, including
deletion of data.

For example, a 1-terabyte drive could have an expected figure of
merit, by this measure, of 1000TBW -- that means it should be able to
endure a total of a petabyte (1000 terabytes) written to it before
showing signs of failure.

But it seems to me, a 2-terabyte drive made of parts with the same
quality, meaning each storage cell has the same expected endurance as
before, should have a proportionately greater figure of merit, namely
2000TBW.

But the bigger drive will likely not last longer than the smaller one
-- unless you donrCOt actually make use of the extra space.

So why not divide the TBW by the actual capacity of the drive? Then
you end up with a ratio of how much can be written in total, to the
drive capacity -- call it, say, the rCLcumulative write ratiorCY. Both
those drives would have a cumulative write ratio of 1000.

That number, it seems to me, correlates better to the overall quality
of the unit than TBW does. E.g. if you see a bigger drive with a
smaller cumulative write ratio, you can suspect that they are cutting
corners somewhere to keep the cost down.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On Thu, 20 Aug 2026 16:55:09 +0100, mm0fmf wrote:

On 20/08/2026 05:42, Lawrence DrCOOliveiro wrote:

So why not divide the TBW by the actual capacity of the drive? Then
you end up with a ratio of how much can be written in total, to the
drive capacity -- call it, say, the rCLcumulative write ratiorCY.

That number, it seems to me, correlates better to the overall quality
of the unit than TBW does.

When I compare my NVME drive endurance for a 2TB device, it is quoted as being 1200TBW and the 1TB version is quoted as 600TBW.

There you go -- both drives have a cumulative write ratio of 600.

I was a little concerned whether 1200TBW would be enough considering
how much "chatter" there was on the drive. After 1 year of use, the
drive has seen 4TBW meaning it will last me 299 more years. I think
that will be enough.

Trouble is, we donrCOt know what the shape of the failure curve is like.
To take an extreme case, if the shape is skewed enough so that 99% of
drives fail with a write ratio within, say, 10 (i.e. your drive fails
within 5 years), while 1% last as long as 60000 rewrites, the
arithmetic mean would still stay the same, but you would be rather
more likely to suffer data loss ...
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On 21/08/2026 00:22, Lawrence DrCOOliveiro wrote:

On Thu, 20 Aug 2026 16:55:09 +0100, mm0fmf wrote:

On 20/08/2026 05:42, Lawrence DrCOOliveiro wrote:

So why not divide the TBW by the actual capacity of the drive? Then
you end up with a ratio of how much can be written in total, to the
drive capacity -- call it, say, the rCLcumulative write ratiorCY.

That number, it seems to me, correlates better to the overall quality
of the unit than TBW does.

When I compare my NVME drive endurance for a 2TB device, it is quoted as
being 1200TBW and the 1TB version is quoted as 600TBW.

There you go -- both drives have a cumulative write ratio of 600.

I was a little concerned whether 1200TBW would be enough considering
how much "chatter" there was on the drive. After 1 year of use, the
drive has seen 4TBW meaning it will last me 299 more years. I think
that will be enough.

Trouble is, we donrCOt know what the shape of the failure curve is like.
To take an extreme case, if the shape is skewed enough so that 99% of
drives fail with a write ratio within, say, 10 (i.e. your drive fails
within 5 years), while 1% last as long as 60000 rewrites, the
arithmetic mean would still stay the same, but you would be rather
more likely to suffer data loss ...

It's warranted for 5 years. I think it will outlast the warranty period
and I'd be probably be considering a replacement by then.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Lawrence DrCOOliveiro <ldo@NZ.invalid> wrote: |----------------------------------------------------------------------|
|"I found out that a common measure of the projected life of an SSD is |
|being given in units of rCLterabytes writtenrCY (TBW). This will typically| |be much larger than the capacity of the drive itself, because it | |includes the sum total of all write operations on the drive, including| |deletion of data. |
| |
|For example, a 1-terabyte drive could have an expected figure of | |merit, by this measure, of 1000TBW -- that means it should be able to | |endure a total of a petabyte (1000 terabytes) written to it before | |showing signs of failure. |
| |
|But it seems to me, a 2-terabyte drive made of parts with the same | |quality, meaning each storage cell has the same expected endurance as | |before, should have a proportionately greater figure of merit, namely | |2000TBW. |
| |
|But the bigger drive will likely not last longer than the smaller one |
|-- unless you donrCOt actually make use of the extra space. |
| |
|So why not divide the TBW by the actual capacity of the drive? Then |
|you end up with a ratio of how much can be written in total, to the |
|drive capacity -- call it, say, the rCLcumulative write ratiorCY. Both | |those drives would have a cumulative write ratio of 1000. |
| |
|That number, it seems to me, correlates better to the overall quality |
|of the unit than TBW does. E.g. if you see a bigger drive with a | |smaller cumulative write ratio, you can suspect that they are cutting | |corners somewhere to keep the cost down." | |----------------------------------------------------------------------|

I do not yet have a first-hand experience of an SSD failure. Don Y
complains in news:sci.electronics.design that an SSD suddenly
completely failed, instead of gradual partial degradations of a hard
disk. What does Lawrence DrCOOliveiro mean by
"before
showing signs of failure."?
This quotation gave me the impression that Lawrence DrCOOliveiro does
not expect the dramatic all-or-nothing scenario that Don Y reported.

This is a crosspost to news:sci.electronics.design
(S. HTTP://Gloucester.Insomnia247.NL/ fuer Kontaktdaten!)
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

=?UTF-8?B?IEdsb3N0w6lpcg==?= <thanks-to@Taf.com> wrote:

I do not yet have a first-hand experience of an SSD failure. Don Y
complains in news:sci.electronics.design that an SSD suddenly
completely failed, instead of gradual partial degradations of a hard
disk. What does Lawrence DrCOOliveiro mean by
"before
showing signs of failure."?

With a conventional hard drive, first you might see some error numbers creeping up on your SMART tool, as individual blocks start failing. There
is a bad block replacement process that is transparent to the OS so all you
see are bad numbers on SMART. Then you start getting media errors and
then it's all over.

This quotation gave me the impression that Lawrence DrCOOliveiro does
not expect the dramatic all-or-nothing scenario that Don Y reported.

You can also have dramatic all-at-once errors when the interface fails. I have seen many USB SSDs where the SSD memory remained fine but the USB interface could
not get to it.

I have seen lots of ways that SSDs fail. There are likely lots more than I haven't seen yet.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On 8/21/2026 12:32 PM, Scott Dorsey wrote:

=?UTF-8?B?IEdsb3N0w6lpcg==?= <thanks-to@Taf.com> wrote:

I do not yet have a first-hand experience of an SSD failure. Don Y
complains in news:sci.electronics.design that an SSD suddenly
completely failed, instead of gradual partial degradations of a hard
disk. What does Lawrence DrCOOliveiro mean by
"before
showing signs of failure."?

With a conventional hard drive, first you might see some error numbers creeping up on your SMART tool, as individual blocks start failing. There
is a bad block replacement process that is transparent to the OS so all you see are bad numbers on SMART. Then you start getting media errors and
then it's all over.

The firmware in spinning rust controllers has matured over decades.
This is not the case with SSDs (especially early entrants to the market).

Note that the media fails in different ways and the controller has
to understand these and adequately address them, in the wild.

Many "Thumb drives" have had problematic firmware (some Phison and
Hynix controllers). The fix requires a firmware upgrade -- WHILE
the drive is still willing to talk to its host.

This quotation gave me the impression that Lawrence DrCOOliveiro does
not expect the dramatic all-or-nothing scenario that Don Y reported.

You can also have dramatic all-at-once errors when the interface fails. I have
seen many USB SSDs where the SSD memory remained fine but the USB interface could
not get to it.

Or, it suddenly becomes R/O -- better than inaccessible but only if
you're not in the process of trying to write to it!

I have seen lots of ways that SSDs fail. There are likely lots more than I haven't seen yet.

You can likely run a magnetic disk for many years (I have drives with 80K PoH) that still haven't encountered a remapped sector. But, you can exhaust the TBW limit for an SSD in a short time -- if you are ignorant of this limitation.
At 200+MB/s, you can scribble 12GB in a minute -- almost a TB in an hour!
The type of FLASH used, extent of overprovisioning, level of smarts in
the controller, etc. all have a big impact on real-world numbers.

In the early days of WAROM (e.g., ER3400), naive implementations that had previously used BBSRAM for that nonvolatile function would wear out in
minutes ("No, you DON'T want to write the changed settings back to the
store each time an individual setting is changed! Keep a shadow copy in
RAM and use an "impending power fail" signal to quickly stash them to the medium *IFF* (!) SOMETHING HAS CHANGED. It doesn't take long to go through 10^4 erase/write cycles!
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On Fri, 21 Aug 2026 12:56:40 -0700, Don Y wrote:

The firmware in spinning rust controllers has matured over decades.
This is not the case with SSDs (especially early entrants to the
market).

First of all, rust isnrCOt magnetic.

Secondly, flash-storage firmware is indeed very complex -- most of
that complexity seems to go into making the device behave like a
magnetic disk drive. Details are proprietary, but certain filesystem
experts have voiced the opinion that the firmware implements something resembling a log-structured filesystem.

(You know how filesystems nowadays commonly have journals? The journal
is usually treated as a temporary holding place, to store transactions
in progress, to allow clean recovery from crashes. But once you have a
journal, you can consider the regular part of the filesystem to be
redundant; what if the filesystem itself was all journal? ThatrCOs a rCLlog-structured filesystemrCY.)

You could do away with most of this complexity just by using an
OS-level filesystem that has wear-levelling built into its allocation algorithms. Several of these exist for the Linux kernel, and I think
are deployed in embedded applications. Unfortunately I donrCOt think you
can get regular consumer products designed for such usage, since the
lowest common denominator, namely Microsoft Windows, has no capability
to take advantage of them.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

In comp.misc Don Y <blockedofcourse@foo.invalid> wrote:

On 8/21/2026 12:32 PM, Scott Dorsey wrote:

=?UTF-8?B?IEdsb3N0w6lpcg==?= <thanks-to@Taf.com> wrote:

I do not yet have a first-hand experience of an SSD failure. Don Y
complains in news:sci.electronics.design that an SSD suddenly
completely failed, instead of gradual partial degradations of a hard
disk. What does Lawrence D'Oliveiro mean by
"before
showing signs of failure."?

With a conventional hard drive, first you might see some error numbers
creeping up on your SMART tool, as individual blocks start failing. There >> is a bad block replacement process that is transparent to the OS so all you >> see are bad numbers on SMART. Then you start getting media errors and
then it's all over.

The firmware in spinning rust controllers has matured over decades.
This is not the case with SSDs (especially early entrants to the market).

Note that the media fails in different ways and the controller has
to understand these and adequately address them, in the wild.

The non-standard SSD card in my EeePC 701 was repeatedly getting
corrupted data, a common problem with these I believe. So I
repartitioned it using just the upper half of the drive instead of
all the space for the system partition, and no more corruption.
Obviously the wear leveling done by that SSD controller isn't very sophisticated and had worn out the flash used for the starting
sectors of the drive. I thought modern SSDs for use in PCs must
have improved from that to some extent. But it's a case of gradual
failure more like a HDD (though I've certainly seen sudden death
with HDDs too).

Many "Thumb drives" have had problematic firmware (some Phison and
Hynix controllers). The fix requires a firmware upgrade -- WHILE
the drive is still willing to talk to its host.

I didn't realise firmware upgrades were available for USB drives.
Is there any way to apply them from Linux?
--
__ __
#_ < |\| |< _#
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On 8/21/2026 4:01 PM, Computer Nerd Kev wrote:

In comp.misc Don Y <blockedofcourse@foo.invalid> wrote:

On 8/21/2026 12:32 PM, Scott Dorsey wrote:

=?UTF-8?B?IEdsb3N0w6lpcg==?= <thanks-to@Taf.com> wrote:

I do not yet have a first-hand experience of an SSD failure. Don Y
complains in news:sci.electronics.design that an SSD suddenly
completely failed, instead of gradual partial degradations of a hard
disk. What does Lawrence D'Oliveiro mean by
"before
showing signs of failure."?

With a conventional hard drive, first you might see some error numbers
creeping up on your SMART tool, as individual blocks start failing. There >>> is a bad block replacement process that is transparent to the OS so all you >>> see are bad numbers on SMART. Then you start getting media errors and
then it's all over.

The firmware in spinning rust controllers has matured over decades.
This is not the case with SSDs (especially early entrants to the market).

Note that the media fails in different ways and the controller has
to understand these and adequately address them, in the wild.

The non-standard SSD card in my EeePC 701 was repeatedly getting
corrupted data, a common problem with these I believe. So I

I had an EeePC with *two* "drives" -- a tiny one and a slightly larger one.
I set the tiny one to boot a BSD kernel which then mounted the rest of
the filesystem (e.g., /usr) that resided on the "larger" one.

For a while, I used this to DL the most recent "distfiles" archive
(see pkgsrc) as I could attach an external magnetic disk and then
note the differences (additions) present on the public web site vs.
what I had accumulated to date. And, store the EeePC in a desk drawer!

[Often, older sources would disappear so rsync(1) was a bad choice]

But, the small size and the fact that it had a built-in TINY
display and keyboard eventually grew tiresome. So, I replaced
it with a full-size laptop -- where I could install a larger
magnetic disk and not be bothered with mounting the (necessary!)
filesystem present on the secondary drive. Now it resides on a shelf
in the closet instead of inside the desk...

repartitioned it using just the upper half of the drive instead of
all the space for the system partition, and no more corruption.
Obviously the wear leveling done by that SSD controller isn't very sophisticated and had worn out the flash used for the starting

I think EeePCs aren't intended for much more than email, etc.
And, running a UNIX on it (BSD in my case) still does writes to
the / partition (think /var/log). Perhaps retooling the system
might cut down on that (mount /var as a tmpfs?)

I presently use small (16G) thumb drives as the "boot disk" in
several of my appliances -- so I can keep the drive bays free
and "pure" for regular media. I've not had any problems, yet,
but have played the tmpfs trick to reduce the risk.

sectors of the drive. I thought modern SSDs for use in PCs must
have improved from that to some extent. But it's a case of gradual
failure more like a HDD (though I've certainly seen sudden death
with HDDs too).

HDDs tend to either have a problem spinning up or a problem with
the head actuator assembly, when they "die dramatically".
Before that time, they just accrete bad sectors on the GDL.

[I've not explored whether this can be "reset" like on a SCSI
drive -- though suspect that would be A Bad Idea]

Many "Thumb drives" have had problematic firmware (some Phison and
Hynix controllers). The fix requires a firmware upgrade -- WHILE
the drive is still willing to talk to its host.

I didn't realise firmware upgrades were available for USB drives.
Is there any way to apply them from Linux?

Dunno as I don't run Linux. Maybe start here:
<https://www.usbdev.ru/files/smi/smimptool/>

I rescue "recovery media" for Windows machines (typically 8GB
thumb drives that have been factory marked as R/O). These
tools let me convert them to usable 8G drives -- a nice size
to emulate a DVD-DL. Especially as optical drives are becoming
scarce in machines (or, physically incompatible with the sizes
of those machines -- e.g., NUCs)
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On 8/21/2026 3:48 PM, Lawrence DrCOOliveiro wrote:

On Fri, 21 Aug 2026 12:56:40 -0700, Don Y wrote:

The firmware in spinning rust controllers has matured over decades.
This is not the case with SSDs (especially early entrants to the
market).

First of all, rust isnrCOt magnetic.

Did you forget the smiley face?

Secondly, flash-storage firmware is indeed very complex -- most of
that complexity seems to go into making the device behave like a
magnetic disk drive. Details are proprietary, but certain filesystem
experts have voiced the opinion that the firmware implements something resembling a log-structured filesystem.

There are also significant differences between consumer, commercial and enterprise grade devices. The technology used in the FLASH (SLC, MLC,
TLC, etc.), amount of over-provisioning, size of SRAM buffer, interface speed/family, etc. (E.g., I've not yet encountered a SAS or SCA SSD,
not to say that anything -- besides market demand -- precludes their offerings). Picking a "sweet spot" that fits a perceived market
demand then becomes the challenge.

(You know how filesystems nowadays commonly have journals? The journal
is usually treated as a temporary holding place, to store transactions
in progress, to allow clean recovery from crashes. But once you have a journal, you can consider the regular part of the filesystem to be
redundant; what if the filesystem itself was all journal? ThatrCOs a rCLlog-structured filesystemrCY.)

You could do away with most of this complexity just by using an
OS-level filesystem that has wear-levelling built into its allocation algorithms. Several of these exist for the Linux kernel, and I think
are deployed in embedded applications. Unfortunately I donrCOt think you
can get regular consumer products designed for such usage, since the
lowest common denominator, namely Microsoft Windows, has no capability
to take advantage of them.

It would require a different kind of drive as the role of its controller
would be much different. Similar to installing FLASH media ("chips")
in a device and taking on the task of managing that memory -- which might
often be "write once" (or write rarely)

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

In article <116akj1$m98h$3@dont-email.me>,
Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> wrote:

On Fri, 21 Aug 2026 12:56:40 -0700, Don Y wrote:

The firmware in spinning rust controllers has matured over decades.
This is not the case with SSDs (especially early entrants to the
market).

First of all, rust isnrCOt magnetic.

Yes it is. What you want is gamma ferric oxide. It's very fancy rust. (Admittedly rotating disks today all use plated media and not the ferric
oxide of the 1970s).
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On Fri, 21 Aug 2026 16:20:30 -0700, Don Y wrote:

[Often, older sources would disappear so rsync(1) was a bad choice]

ThererCOs a way around that: you can use the rCL--link-destrCY option to
create multigenerational backups, with deduping of unchanged files.
Or, if the files are too small to bother with deduping, just do the
rsync to a new destination directory each time.

But, the small size and the fact that it had a built-in TINY
display and keyboard eventually grew tiresome.

Would you believe, it was small enough to fit in a pants pocket -- at
least on one pair of pants I had at the time ;).

I remember using it heavily at a clientrCOs place, to SSH into the
Asterisk server to watch its logs while debugging the integration of a predictive dialler with my call-management system and coordinating
with the operator making the test calls.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On 8/21/2026 6:30 PM, Lawrence DrCOOliveiro wrote:

On Fri, 21 Aug 2026 16:20:30 -0700, Don Y wrote:

[Often, older sources would disappear so rsync(1) was a bad choice]

ThererCOs a way around that: you can use the rCL--link-destrCY option to create multigenerational backups, with deduping of unchanged files.
Or, if the files are too small to bother with deduping, just do the
rsync to a new destination directory each time.

I usually use BeyondCompare to compare/DL source and target
directories. It lets me see both and get a feel for how much
work needs to be done.

Also highlights differences (size/timestamp) between the two
in those cases when both have a file but they obviously differ
I have lots of cases of foo being renamed foo.old on my copy
so the remote foo doesn't overwrite it; then foo.older, foo.oldest,
etc. -- a place where versioning could be of benefit (but, some
other repo might have a different notion of foo that I will
have to reconcile with my instances.

But, the small size and the fact that it had a built-in TINY
display and keyboard eventually grew tiresome.

Would you believe, it was small enough to fit in a pants pocket -- at
least on one pair of pants I had at the time ;).

You're either a "big person" or where HUGE pants! :>
A checkbook is about the largest item that I can put into
a pants pocket. Phone sticks out (need a smaller phone!)

I remember using it heavily at a clientrCOs place, to SSH into the
Asterisk server to watch its logs while debugging the integration of a predictive dialler with my call-management system and coordinating
with the operator making the test calls.

I inherited this one when a buddy's wife died. He asked me to
remove all of her email and personal information and then
recycle it (I do volunteer work at a place that recycles
various types of kit).

Once wiped, I figured it would make a nice LITTLE "self-contained"
machine to save me the hassle of dragging out a monitor, "CPU"
and keyboard. And, it did that job well (doesn't take much horsepower
to connect to an FTP service and transfer files to an external drive).

But, I had *seven* laptops -- 17 inch displays, etc. -- just collecting
dust in the closet. (did I mention that I volunteer at a place that
recycles kit??) "So, do I discard the EeePC, or one of the laptops,
especially given that the laptops are more capable (and usable!) machines?"

Now, if I don't want to drag out the laptop, I've configured a
NUC with the same software and use the TV in the living room as
the monitor.

[This windows machine would be a bad choice to perform the
mirror as differences in filesystem support would eat my
lunch]
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On Fri, 21 Aug 2026 19:11:09 -0700, Don Y wrote:

Also highlights differences (size/timestamp) between the two in
those cases when both have a file but they obviously differ I have
lots of cases of foo being renamed foo.old on my copy so the remote
foo doesn't overwrite it; then foo.older, foo.oldest, etc. -- a
place where versioning could be of benefit (but, some other repo
might have a different notion of foo that I will have to reconcile
with my instances.

If these are text files, then that is the reason why software
developers invented version control. Git is the premier VCS these
days; its particular strength is reconciling different versions of a
file that have forked off from a common ancestor, which sounds like
your use case.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On 8/21/2026 9:54 PM, Lawrence DrCOOliveiro wrote:

On Fri, 21 Aug 2026 19:11:09 -0700, Don Y wrote:

Also highlights differences (size/timestamp) between the two in
those cases when both have a file but they obviously differ I have
lots of cases of foo being renamed foo.old on my copy so the remote
foo doesn't overwrite it; then foo.older, foo.oldest, etc. -- a
place where versioning could be of benefit (but, some other repo
might have a different notion of foo that I will have to reconcile
with my instances.

If these are text files, then that is the reason why software
developers invented version control.

You can use it with binary files, too, if you are careful.
P4 is my goto tool to control executables and other binaries.

Git is the premier VCS these
days; its particular strength is reconciling different versions of a
file that have forked off from a common ancestor, which sounds like
your use case.

Yes, I use CVS. I have "imported" many legacy codebases that were
built with that as the VCS (some even use RCS or SCCS!). So, it's
easier to recover the history as well as reconstitute different
branches directly. (moving to git, svn, p4, etc. would mean I would
lose the ability to easily move back through the revision history
to reconstitute particular historical branches as that new VCS would
not have "seen" those versions as they existed at that time.)

The fact that their authors had opted to reuse the same filename
(in this case) for different versions was something I was stuck with.

Giving them ".old", ".older", etc. let me see which "version"
*this* repository considered to be authoritative ("Ah, foo has
the same size as my foo.oldest so no need to download it, even
though it obviously differs from *my* foo")

Add to this the fact that pkgsrc will try to verify the size and hash
of ONE of those foo's that *it* thinks to be authoritative -- though
you don't know which the current version of pkgsrc thinks is the real
one until you try to build whatever references it.

[IIRC, there are tens of thousands of files in the repository and
I don't build everything so no idea when/if I will ever try to resolve
the "foo ambiguity"]

<shrug> You can control YOUR system but can't do much about
how someone else wants to control theirs.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On Fri, 21 Aug 2026 19:11:09 -0700
Don Y <blockedofcourse@foo.invalid> wrote:

[]

Once wiped, I figured it would make a nice LITTLE "self-contained"
machine to save me the hassle of dragging out a monitor, "CPU"
and keyboard. And, it did that job well (doesn't take much horsepower
to connect to an FTP service and transfer files to an external drive).

Ironicall the one I use the keyboard has failed and I prefer a "proper"
mouse; so I do have to lug the extras - a proper keyboard is so much nicer
to use.

But, I had *seven* laptops -- 17 inch displays, etc. -- just collecting
dust in the closet. (did I mention that I volunteer at a place that
recycles kit??) "So, do I discard the EeePC, or one of the laptops, especially given that the laptops are more capable (and usable!) machines?"

Now, if I don't want to drag out the laptop, I've configured a
NUC with the same software and use the TV in the living room as
the monitor.

[This windows machine would be a bad choice to perform the
mirror as differences in filesystem support would eat my
lunch]

--
Bah, and indeed Humbug.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Lawrence DrCOOliveiro wrote:

On Thu, 20 Aug 2026 16:55:09 +0100, mm0fmf wrote:

On 20/08/2026 05:42, Lawrence DrCOOliveiro wrote:

So why not divide the TBW by the actual capacity of the drive? Then
you end up with a ratio of how much can be written in total, to the
drive capacity -- call it, say, the rCLcumulative write ratiorCY.

That number, it seems to me, correlates better to the overall quality
of the unit than TBW does.

When I compare my NVME drive endurance for a 2TB device, it is quoted as
being 1200TBW and the 1TB version is quoted as 600TBW.

There you go -- both drives have a cumulative write ratio of 600.

That says it all. I don't think much of your new measure, I'm afraid.
What does more memory have anything to do with more TBW? The "standard"
is fine as it is. Are you saying that users with larger hard drives are
more thorough & use their drives more often? That sounds fairly
unlikely. The only consideration here, I guess I'll give you that, is if
the sector size increases somewhat proportionally to the disk size,
which is not the case in general.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On 8/22/2026 1:21 AM, Kerr-Mudd, John wrote:

On Fri, 21 Aug 2026 19:11:09 -0700
Don Y <blockedofcourse@foo.invalid> wrote:

[]

Once wiped, I figured it would make a nice LITTLE "self-contained"
machine to save me the hassle of dragging out a monitor, "CPU"
and keyboard. And, it did that job well (doesn't take much horsepower
to connect to an FTP service and transfer files to an external drive).

Ironicall the one I use the keyboard has failed and I prefer a "proper" mouse; so I do have to lug the extras - a proper keyboard is so much nicer
to use.

I had several "docking stations" -- that I never used (so, why keep them?).
I put a docking station, it's *huge* "brick" power supply, a laptop that
mates with the docking station, mouse and 7' network cable into a
carrying case that was conveniently of the correct size.

This lets me keep all of the "related" items together (excepting the
external disk on which I store the distfile mirror).

More importantly, it lets me rationalize discarding the other docking
stations and a couple of laptops -- as I have one "set" preserved.

I only drag out that laptop two or three times annually to update
my mirror (I don't update packages very often so there is little
need to capture the latest source repository).

I still have a few oversized laptops that don't have carrying cases
so will have to make a decision on them, soon. I am slow to discard
them as the larger laptops have much larger keyboards (big hands).

But, there's only so many for which one can rationalize a distinct use...
(I already have a solution for traveling)
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On 8/21/26 20:13, C||il|!n Niocl|is|!n Glost|-ir wrote:

Lawrence DrCOOliveiro <ldo@NZ.invalid> wrote: |----------------------------------------------------------------------|
|"I found out that a common measure of the projected life of an SSD is | |being given in units of rCLterabytes writtenrCY (TBW). This will typically| |be much larger than the capacity of the drive itself, because it | |includes the sum total of all write operations on the drive, including| |deletion of data. |
| |
|For example, a 1-terabyte drive could have an expected figure of | |merit, by this measure, of 1000TBW -- that means it should be able to | |endure a total of a petabyte (1000 terabytes) written to it before | |showing signs of failure. |
| |
|But it seems to me, a 2-terabyte drive made of parts with the same | |quality, meaning each storage cell has the same expected endurance as | |before, should have a proportionately greater figure of merit, namely | |2000TBW. |
| |
|But the bigger drive will likely not last longer than the smaller one |
|-- unless you donrCOt actually make use of the extra space. |
| |
|So why not divide the TBW by the actual capacity of the drive? Then |
|you end up with a ratio of how much can be written in total, to the | |drive capacity -- call it, say, the rCLcumulative write ratiorCY. Both | |those drives would have a cumulative write ratio of 1000. |
| | |That number, it seems to me, correlates better to the overall quality |
|of the unit than TBW does. E.g. if you see a bigger drive with a | |smaller cumulative write ratio, you can suspect that they are cutting | |corners somewhere to keep the cost down." | |----------------------------------------------------------------------|

I do not yet have a first-hand experience of an SSD failure. Don Y

Bit late to this thread, but as ssd started to become more
affordable, started replacing all the mech drives with ssd.
Had a couple of failures, but never buy new. Run zfs file
system, which allows recovery from one or even two single
disk failures, depending on initial setup. For root drives,
run zfs mirrored root, which is an install option with
FreeBSD. Much faster than spinning drives, lower power
consumption, and worth it, just for those reasons alone.

Some systems here have been upgraded with sas interface
controllers. That allows the use of ex corporate ssds,
which tend to have a much better spec than some of the
consumer quality drives. Some of the Samsung sas drives,
for example, guarantee a full disk write and read every
day for five years or more, without failure. That's
effectively 100% reliable, under the lightly loaded
conditions here.

Ebay is a great source, and purchases here include a
batch of 17 sas 3840 Gb drives, marked as end of life,
but smartcontrol shows 9% wear, which is irrelevant here.
Several in a zfs pool for a few years, without a single
failure. Another was a disk array with 24 x 800Gb Samsumg
ssd. 520 byte sector size, but trivial to reformat to
512. 120 ukp delivered. More storage than i'll ever need,
most likely.

Sata drives not too bad either, a couple of failures
over the years,, but nothing serious. The real problem
is when such drives use a sata to usb converter, where
all bets are off worst case, and can even end up
completely bricking the drive. Still, they get cheaper
all the time.

The worst culprits are ssd memory sticks, some of
which wont even take a large file, ~5Gb write in
one go, without failure.

Chris

complains in news:sci.electronics.design that an SSD suddenly
completely failed, instead of gradual partial degradations of a hard
disk. What does Lawrence DrCOOliveiro mean by
"before
showing signs of failure."?
This quotation gave me the impression that Lawrence DrCOOliveiro does
not expect the dramatic all-or-nothing scenario that Don Y reported.

This is a crosspost to news:sci.electronics.design
(S. HTTP://Gloucester.Insomnia247.NL/ fuer Kontaktdaten!)

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

ChrisQ <syseng@GfSys.co.UK> wrote: |-------------------------------------------------------|
|"Bit late to this thread[. . .] |
|[. . .] |
| |
|[. . .]" | |-------------------------------------------------------|

Dear ChrisQ,

Welcome anyway and thanks for those many good data! I often follow up
after many years.

|-------------------------------------------------------|
|"[. . .] |
|Several in a zfs pool for a few years, without a single|
|failure. [. . .] |
|[. . .] | |-------------------------------------------------------|

OpenSolaris with ZFS on a hard disk failed on me.

|-------------------------------------------------------|
|"Sata drives not too bad either, a couple of failures |
|over the years,, but nothing serious. The real problem |
|is when such drives use a sata to usb converter, where |
|all bets are off worst case, and can even end up |
|completely bricking the drive. [. . .] |
|[. . .] |
| |
|The worst culprits are ssd memory sticks[. . .] |
|[. . .]" | |-------------------------------------------------------|

USB hard disks and USB flash sticks are bad.

|-------------------------------------------------------|
|"Still, they get cheaper |
|all the time." | |-------------------------------------------------------|

Cheap crap continues to be crap.
(S. HTTP://Gloucester.Insomnia247.NL/ fuer Kontaktdaten!)
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On Sat, 22 Aug 2026 04:23:16 -0600, Lane W wrote:

Lawrence DrCOOliveiro wrote:

On Thu, 20 Aug 2026 16:55:09 +0100, mm0fmf wrote:

On 20/08/2026 05:42, Lawrence DrCOOliveiro wrote:

So why not divide the TBW by the actual capacity of the drive?
Then you end up with a ratio of how much can be written in total,
to the drive capacity -- call it, say, the rCLcumulative write
ratiorCY.

That number, it seems to me, correlates better to the overall
quality of the unit than TBW does.

When I compare my NVME drive endurance for a 2TB device, it is
quoted as being 1200TBW and the 1TB version is quoted as 600TBW.

There you go -- both drives have a cumulative write ratio of 600.

What does more memory have anything to do with more TBW?

Precisely my point. Why should it mean anything, that the more
capacious device get a higher TBW rating? My rating factors that out.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On Fri, 21 Aug 2026 23:07:48 -0700, Don Y wrote:

On 8/21/2026 9:54 PM, Lawrence DrCOOliveiro wrote:

On Fri, 21 Aug 2026 19:11:09 -0700, Don Y wrote:

Also highlights differences (size/timestamp) between the two in
those cases when both have a file but they obviously differ I have
lots of cases of foo being renamed foo.old on my copy so the remote
foo doesn't overwrite it; then foo.older, foo.oldest, etc. -- a
place where versioning could be of benefit (but, some other repo
might have a different notion of foo that I will have to reconcile
with my instances.

If these are text files, then that is the reason why software
developers invented version control.

You can use it with binary files, too, if you are careful.

ItrCOs not about being rCLcarefulrCY, itrCOs about the usefulness of applying version control to such files.

With text files, you can use the rCLdiffrCY command to narrow down exactly
the parts that have changed. And the output of rCLdiffrCY can be passed to rCLpatchrCY to apply those changes to another copy of the original file.

And hererCOs the fun part: you can use rCLpatchrCY to apply *diffs from multiple sources to the same file*. Yes, there are occasions when this
will lead to conflicts where different patches affect the same text
lines, but the rest of the time, it works fine. This is the key to
open-source collaborative development, being able to merge change
submissions from multiple contributors.

With binary files, none of this really works.

... I use CVS. I have "imported" many legacy codebases that were
built with that as the VCS (some even use RCS or SCCS!). So, it's
easier to recover the history as well as reconstitute different
branches directly. (moving to git, svn, p4, etc. would mean I would
lose the ability to easily move back through the revision history to reconstitute particular historical branches as that new VCS would
not have "seen" those versions as they existed at that time.)

The PostgreSQL folks went through exactly this issue. That didnrCOt stop
them migrating to Git <https://lwn.net/Articles/409635/>. ItrCOs all a
matter of planning.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

In comp.misc Don Y <blockedofcourse@foo.invalid> wrote:

On 8/21/2026 4:01 PM, Computer Nerd Kev wrote:

repartitioned it using just the upper half of the drive instead of
all the space for the system partition, and no more corruption.
Obviously the wear leveling done by that SSD controller isn't very
sophisticated and had worn out the flash used for the starting

I think EeePCs aren't intended for much more than email, etc.
And, running a UNIX on it (BSD in my case) still does writes to
the / partition (think /var/log). Perhaps retooling the system
might cut down on that (mount /var as a tmpfs?)

Yes my Linux install runs in a tmpfs in RAM. The start of the SSD
had been worn out by the time I got the EeePC second-hand, probably
running the factory WinXP install. User files are saved of course,
but excluding things like the Firefox disk cache, so writes are
mainly for OS upgrades, which hopefully won't be enough to wear
the rest of the SSD out too soon.

Dunno as I don't run Linux. Maybe start here:
<https://www.usbdev.ru/files/smi/smimptool/>

I rescue "recovery media" for Windows machines (typically 8GB
thumb drives that have been factory marked as R/O). These
tools let me convert them to usable 8G drives -- a nice size
to emulate a DVD-DL. Especially as optical drives are becoming
scarce in machines (or, physically incompatible with the sizes
of those machines -- e.g., NUCs)

I keep a USB CD/DVD drive for machines like the EeePC that don't
come with one - the BIOSs all seem to support them fine. I guess
the firmware upgrades aren't worth digging into for me - most of
my dead USB drives are just dead. There's only one that started
getting filesystem corruption, but didn't go r/o.
--
__ __
#_ < |\| |< _#
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On 8/22/2026 4:34 PM, Lawrence DrCOOliveiro wrote:

Also highlights differences (size/timestamp) between the two in
those cases when both have a file but they obviously differ I have
lots of cases of foo being renamed foo.old on my copy so the remote
foo doesn't overwrite it; then foo.older, foo.oldest, etc. -- a
place where versioning could be of benefit (but, some other repo
might have a different notion of foo that I will have to reconcile
with my instances.

If these are text files, then that is the reason why software
developers invented version control.

You can use it with binary files, too, if you are careful.

ItrCOs not about being rCLcarefulrCY, itrCOs about the usefulness of applying version control to such files.

The value of version control is to be able to recreate a particular point-in-time of <whatever> you are controlling.

With text files, you can use the rCLdiffrCY command to narrow down exactly the parts that have changed. And the output of rCLdiffrCY can be passed to rCLpatchrCY to apply those changes to another copy of the original file.

You don't always have the ability to "create from source" (or from a human-readable form) an item that you want to snapshot. E.g., a PURCHASED
tool or component that you are using.

I commit typefaces, executables, images, etc. to the repository so I can retrieve them in the state they existed when I was using them in a version-controlled product.

And hererCOs the fun part: you can use rCLpatchrCY to apply *diffs from multiple sources to the same file*. Yes, there are occasions when this
will lead to conflicts where different patches affect the same text
lines, but the rest of the time, it works fine. This is the key to open-source collaborative development, being able to merge change
submissions from multiple contributors.

With binary files, none of this really works.

Exactly. But NOT being able to snapshot their state at a point in
time is even worse. Or, having to invent another mechanism to
track their state "in parallel" with the other components
("Do I have the right versions of the non-text components
here to be able to restore the conditions in effect at said
point in time/history?")

E.g., I have hand-drawn the icons for the "HiFi replacement"
I'm making for my other half. Should I export those bitmaps
as text files just to be able to preserve them AS text,
instead of bitmaps? Or, just make a note that it doesn't
make sense to "diff" bitmaps (though I have tools that
will do that)?

Sadly, UNIX assumes file type is completely indicated by
a suffix on a filename -- said suffix being under the control
of the person who selected the filename.

... I use CVS. I have "imported" many legacy codebases that were
built with that as the VCS (some even use RCS or SCCS!). So, it's
easier to recover the history as well as reconstitute different
branches directly. (moving to git, svn, p4, etc. would mean I would
lose the ability to easily move back through the revision history to
reconstitute particular historical branches as that new VCS would
not have "seen" those versions as they existed at that time.)

The PostgreSQL folks went through exactly this issue. That didnrCOt stop
them migrating to Git <https://lwn.net/Articles/409635/>. ItrCOs all a
matter of planning.

It's a matter of human resources. Do I want to replace one VCS with
another (at some amount of time, effort and risk), just to say I did so?
Will I be THAT much "better off" after having made the switch than
if I had continued using the system that had been in place when those
things were created?

Or, would I rather spend that time working on the project at hand?

My "project-based solution" is to simply snapshot the complete
system and save that as a VMDK. Then, if I want to recreate the
state of the development effort at some future date, just copy
the appropriate VMDK to another "working" VMDK (so the preserved
VMDK is not altered by your new efforts) and move forward from
that point.

It is expensive in terms of disk space, but disk space is cheap.

[I've got 64T on my ESXi server and another few hundred TB
on the SAN if I am willing to access the store over the wire]
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On 8/22/2026 5:37 PM, Computer Nerd Kev wrote:

In comp.misc Don Y <blockedofcourse@foo.invalid> wrote:

On 8/21/2026 4:01 PM, Computer Nerd Kev wrote:

repartitioned it using just the upper half of the drive instead of
all the space for the system partition, and no more corruption.
Obviously the wear leveling done by that SSD controller isn't very
sophisticated and had worn out the flash used for the starting

I think EeePCs aren't intended for much more than email, etc.
And, running a UNIX on it (BSD in my case) still does writes to
the / partition (think /var/log). Perhaps retooling the system
might cut down on that (mount /var as a tmpfs?)

Yes my Linux install runs in a tmpfs in RAM. The start of the SSD
had been worn out by the time I got the EeePC second-hand, probably
running the factory WinXP install. User files are saved of course,
but excluding things like the Firefox disk cache, so writes are
mainly for OS upgrades, which hopefully won't be enough to wear
the rest of the SSD out too soon.

I built a lab for homeless kids to access the web, do their
homework, etc. Windows would boot into a jail, allow them
to access and store THEIR (personal) files on external
media. Then, the jail would be discarded when they logged off
(so, any changes they had made to the system were discarded)

The machines that boot from USB (thumb) drives, here, have
such small systems (e.g., they easily fit on a 16G thumb drive)
that I imagine anything that is pulled in off the USB drive
eventually sits in the disk cache (machines have more than
100MB of RAM) so it effectively acts like a "demand loaded"
tmpfs -- instead of explicitly building an MFS at boot.

Dunno as I don't run Linux. Maybe start here:
<https://www.usbdev.ru/files/smi/smimptool/>

I rescue "recovery media" for Windows machines (typically 8GB
thumb drives that have been factory marked as R/O). These
tools let me convert them to usable 8G drives -- a nice size
to emulate a DVD-DL. Especially as optical drives are becoming
scarce in machines (or, physically incompatible with the sizes
of those machines -- e.g., NUCs)

I keep a USB CD/DVD drive for machines like the EeePC that don't
come with one - the BIOSs all seem to support them fine. I guess
the firmware upgrades aren't worth digging into for me - most of
my dead USB drives are just dead. There's only one that started
getting filesystem corruption, but didn't go r/o.

I use the tools on the referenced site to convert R/O media
into R/W media. No idea what version Y does that version X
didn't -- I just want the drive wiped and made R/W.

Most of my "workstations/servers" have room for one or two
optical drives. But, I am finding keeping optical media around
is annoying -- they seem to end up scattered around instead of
finding their way back to their "storage place".

Using 8G thumb drives, I can keep 50 of them in a coffee mug
and just sort through them as needed -- tossing them back into
the mug, when done.

[E.g., I am preparing to image a disk with CZ -- locate the thumb
drive, boot, image, replace thumb drive. By contrast, there are
probably half a dozen optical media on my desk -- few of them MARKED
with their contents (burned from ISOs, as needed, then discarded).]

I'll likely be removing the second optical drive from my
machines and replacing with a SATA/SAS dock -- so I can plug in
a bare drive and not have to deal with a USB dock. I am trying
to get rid of "little boxes" -- like USB docks -- as they end
up looking like clutter (and, having to put them "away" when
not in use is just an inconvenience).
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On Sat, 22 Aug 2026 18:04:48 -0700, Don Y wrote:

The value of version control is to be able to recreate a particular point-in-time of <whatever> you are controlling.

Any backup/restore system can do that, surely.

The specific value add of version control is being able to keep track
of what has changed. And more than that, to be able to pursue multiple
parallel lines of development, and be able to reconcile them later.
This is particularly important for collaborative development, which is
how a lot of open-source projects operate these days.

Why would you need to keep track of what has changed? Imagine getting
a report of a bug that has appeared in a new release, that wasnrCOt
noticed during development; there is a command called git-bisect, that
comes with Git, that helps you track down the precise commit that
introduced the bug.

E.g., I have hand-drawn the icons for the "HiFi replacement" I'm
making for my other half. Should I export those bitmaps as text
files just to be able to preserve them AS text, instead of bitmaps?

You should have drawn them as SVG. That gives you
resolution-independent scaling, and itrCOs also a text-based format
(actually XML).

Sadly, UNIX assumes file type is completely indicated by a suffix on
a filename -- said suffix being under the control of the person who
selected the filename.

Not quite how it works <https://www.darwinsys.com/file/>.

It's a matter of human resources. Do I want to replace one VCS with
another (at some amount of time, effort and risk), just to say I did
so? Will I be THAT much "better off" after having made the switch
than if I had continued using the system that had been in place when
those things were created?

If you want to encourage others to contribute to your project, then
Git is the way to go.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On 8/22/2026 6:19 PM, Lawrence DrCOOliveiro wrote:

On Sat, 22 Aug 2026 18:04:48 -0700, Don Y wrote:

The value of version control is to be able to recreate a particular
point-in-time of <whatever> you are controlling.

Any backup/restore system can do that, surely.

That is time based. You want to declare a "version" -- branch -- of
the development and capture THAT.

Do you happen to recall what DATE version 27.3.1204 was in effect?
VCS lets you deal with "time" as a history of a product/component
instead of as a mark on a calendar.

It also lets you address *pieces* of the product/component
instead of having to move everything to that point in "time".

E.g., I had to revise a PCB layout for a client -- who had
upgraded the layout tool (newer is better, right?). Only
to discover that the new version couldn't read files that
the previous one had produced.

Should he uninstall the new version, find the previous version and
reinstall that? Or, just retrieve it from the VCS (along with
required support files)?

The advantage of saving entire development system states is
you don't have to wonder what OTHER things affect the operation
of the tool that you need to access, again.

And, as they are so easy to call up -- and discard -- the
impact on your *current* system's state is minimalized;
once done with this retro activity, you can return to whatever you
were doing before that need arose.

The specific value add of version control is being able to keep track
of what has changed. And more than that, to be able to pursue multiple parallel lines of development, and be able to reconcile them later.
This is particularly important for collaborative development, which is
how a lot of open-source projects operate these days.

Why would you need to keep track of what has changed? Imagine getting
a report of a bug that has appeared in a new release, that wasnrCOt
noticed during development; there is a command called git-bisect, that
comes with Git, that helps you track down the precise commit that
introduced the bug.

Here's a photo of my back yard. Here's another. What has changed
(please indicate that in a human-friendly form).

Not everything is "source code". Not every commit can be traced
back to specific actions: first I took the photo. then I enhanced the contrast by 23%. then I applied a filter that made all green tints
a bit darker. then I cropped it to the final size.

Far easier to show before and after especially as there is no
guarantee that the "user" can determine which of these steps
needs to be changed -- all except the cropping are subjective.

E.g., I have hand-drawn the icons for the "HiFi replacement" I'm
making for my other half. Should I export those bitmaps as text
files just to be able to preserve them AS text, instead of bitmaps?

You should have drawn them as SVG. That gives you
resolution-independent scaling, and itrCOs also a text-based format
(actually XML).

I'm dealing with a *small* bitmapped display. So, glyphs are on-the-order
of 5x7 arrays. I don't want some tool to decide how to map the antialiased pels to on/off states (which is all I can get from the display). *I* want
to look at how each presents so I can evaluate the quality of the display instead of leaving that to some tool to decide.

Sadly, UNIX assumes file type is completely indicated by a suffix on
a filename -- said suffix being under the control of the person who
selected the filename.

Not quite how it works <https://www.darwinsys.com/file/>.

file(1) is almost WORSE than using file extensions. As with a Mac,
I (or an application) should be definitively declaring the form
and content of a file, instead of leaving that to something else to
deduce or declare (possibly incorrectly)

It's a matter of human resources. Do I want to replace one VCS with
another (at some amount of time, effort and risk), just to say I did
so? Will I be THAT much "better off" after having made the switch
than if I had continued using the system that had been in place when
those things were created?

If you want to encourage others to contribute to your project, then
Git is the way to go.

The people having access to my sources (contributing) have no qualms
using the tools (compilers, preprocessors, VCS, etc.) that I've
put in place. "It all works". They are free to import the portions
of the codebase of interest to them, personally, and manage it with
whatever tools *they* choose. I.e., ADOPT the codebase as their own.
They don't have to accept the constraints that I've put on the runtime,
can recode the algorithms in CLU, rewrite the comments in Esperanto,
etc. It's THEIRS to do with as they want.

OTOH, if they want to keep abreast of MY efforts, then they have to
adapt to the tools that *I* choose. No one is holding a gun to their heads. --- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

In comp.misc Don Y <blockedofcourse@foo.invalid> wrote:

Sadly, UNIX assumes file type is completely indicated by
a suffix on a filename -- said suffix being under the control
of the person who selected the filename.

Nope. You are mixing up ms windows (where the file extension is
believed to always be right and descriptive of the contents) with Unix
(which actually looks at the files contents and pays no attention to
any part of the name).
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On 8/22/2026 8:51 PM, Rich wrote:

In comp.misc Don Y <blockedofcourse@foo.invalid> wrote:

Sadly, UNIX assumes file type is completely indicated by
a suffix on a filename -- said suffix being under the control
of the person who selected the filename.

Nope. You are mixing up ms windows (where the file extension is
believed to always be right and descriptive of the contents) with Unix
(which actually looks at the files contents and pays no attention to
any part of the name).

One configures applications (CVS in this case) to use the extension
of the file as an indication of how it should be treated.

The contents still don't tell you what the file is or how it is intended
to be used. Because no OS can infer the purpose of a "stream of bytes"
without having been previously informed of that.

When a file (or, the metadata for the file) claims it is a
"FIGGLEBOB", then the OS can throw up its hands and claim
not to know how to handle it -- even if it looks like a shell
script, text file, TIFF, etc. Because the explicit type declaration
has told it that it is none of those things, despite the resemblance.

Is a .AI file a "text" file -- because the contents APPEAR to be
text -- even though they aren't really? Is myprogram.q source
code in C, just because peeking inside LOOKS like that's the case?

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On Sat, 22 Aug 2026 20:57:30 -0700, Don Y wrote:

When a file (or, the metadata for the file) claims it is a
"FIGGLEBOB", then the OS can throw up its hands and claim not to
know how to handle it -- even if it looks like a shell script, text
file, TIFF, etc.

No *nix-type system works that way.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On 8/22/2026 9:30 PM, Lawrence DrCOOliveiro wrote:

On Sat, 22 Aug 2026 20:57:30 -0700, Don Y wrote:

When a file (or, the metadata for the file) claims it is a
"FIGGLEBOB", then the OS can throw up its hands and claim not to
know how to handle it -- even if it looks like a shell script, text
file, TIFF, etc.

No *nix-type system works that way.

Correct. It's a shortcoming of UNIX.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On 8/22/26 20:57, Don Y wrote:

On 8/22/2026 8:51 PM, Rich wrote:

In comp.misc Don Y <blockedofcourse@foo.invalid> wrote:

Sadly, UNIX assumes file type is completely indicated by
a suffix on a filename -- said suffix being under the control
of the person who selected the filename.

Nope.-a You are mixing up ms windows (where the file extension is
believed to always be right and descriptive of the contents) with Unix
(which actually looks at the files contents and pays no attention to
any part of the name).

One configures applications (CVS in this case) to use the extension
of the file as an indication of how it should be treated.

The contents still don't tell you what the file is or how it is intended
to be used.-a Because no OS can infer the purpose of a "stream of bytes" without having been previously informed of that.

When a file (or, the metadata for the file) claims it is a
"FIGGLEBOB", then the OS can throw up its hands and claim
not to know how to handle it -- even if it looks like a shell
script, text file, TIFF, etc.-a Because the explicit type declaration
has told it that it is none of those things, despite the resemblance.

Is a .AI file a "text" file -- because the contents APPEAR to be
text -- even though they aren't really?-a Is myprogram.q source
code in C, just because peeking inside LOOKS like that's the case?

Search "magic numbers"

I looked at a few hits, this page is better than most, the first
paragraph should be enough.

<https://www.networkworld.com/article/931352/unix-under-the-spell-of-magic-numbers.html>


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On Sat, 22 Aug 2026 19:15:19 -0700, Don Y wrote:

On 8/22/2026 6:19 PM, Lawrence DrCOOliveiro wrote:

On Sat, 22 Aug 2026 18:04:48 -0700, Don Y wrote:

The value of version control is to be able to recreate a
particular point-in-time of <whatever> you are controlling.

Any backup/restore system can do that, surely.

That is time based. You want to declare a "version" -- branch -- of
the development and capture THAT.

Fine. Store that info as part of the metadata for the backup snapshot.

The advantage of saving entire development system states is you
don't have to wonder what OTHER things affect the operation of the
tool that you need to access, again.

Yes, but again, thatrCOs what backup snapshots are for. VCSes serve a
somewhat different purpose.

Here's a photo of my back yard. Here's another. What has changed
(please indicate that in a human-friendly form).

HererCOs a photo of someone elserCOs back yard. It started out similar to yours, but has undergone its own renovations. You like some of what
theyrCOve done, and would like to selectively apply those changes to
your own back yard, which has in its turn evolved somewhat in the
meantime. How would you do that?

Not everything is "source code".

VCSes are best precisely at dealing with textual source code, and with
anything that can be represented as that.

file(1) is almost WORSE than using file extensions. As with a Mac, I
(or an application) should be definitively declaring the form and
content of a file, instead of leaving that to something else to
deduce or declare (possibly incorrectly)

Apple had the old rCLFourCCrCY or rCLOSTyperCY type/creator system decades
ago, but abandoned all that in favour of file extensions.

These days, we have MIME types. And common Linux filesystems allow
those to be attached to files in a similar way to those type/creator
codes on the old Apple Mac systems. Except MIME types are a somewhat
more extensible system, using more descriptive strings instead of
cryptic four-byte codes.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On 8/23/2026 12:01 AM, Old Macdonald wrote:

On 8/22/26 20:57, Don Y wrote:

On 8/22/2026 8:51 PM, Rich wrote:

In comp.misc Don Y <blockedofcourse@foo.invalid> wrote:

Sadly, UNIX assumes file type is completely indicated by
a suffix on a filename -- said suffix being under the control
of the person who selected the filename.

Nope.-a You are mixing up ms windows (where the file extension is
believed to always be right and descriptive of the contents) with Unix
(which actually looks at the files contents and pays no attention to
any part of the name).

One configures applications (CVS in this case) to use the extension
of the file as an indication of how it should be treated.

The contents still don't tell you what the file is or how it is intended
to be used.-a Because no OS can infer the purpose of a "stream of bytes"
without having been previously informed of that.

When a file (or, the metadata for the file) claims it is a
"FIGGLEBOB", then the OS can throw up its hands and claim
not to know how to handle it -- even if it looks like a shell
script, text file, TIFF, etc.-a Because the explicit type declaration
has told it that it is none of those things, despite the resemblance.

Is a .AI file a "text" file -- because the contents APPEAR to be
text -- even though they aren't really?-a Is myprogram.q source
code in C, just because peeking inside LOOKS like that's the case?

Search "magic numbers"

I looked at a few hits, this page is better than most, the first paragraph should be enough.

<https://www.networkworld.com/article/931352/unix-under-the-spell-of-magic- numbers.html>

Again, it only works if you tell the OS about your particular file type and every other machine that will ever see files of that type. That's what
Apple did, ages ago.

In UNIX, you only have the file name to rely on -- there is no other metadata available to an application/system that wants to ascertain the nature
of the file/object that it is being asked to process.

In CVS, "wrappers" lets you associate "file types" with specific handling options. So, I can (effectively) say:

* assume binary, as default
*.c C sources
*.h C headers
*.BMP bitmaps
*.bz BZIP archive
*.ppt PowerPoint presentation
*.o object, ELF
*.xwd xwd(1) screen capture
etc.

Then, indicate how each "type" should be handled. E.g., to check if a
"bitmap" coincides with another, do a binary comparison. To show the differences between them, create a two-valued map where one value
represents "agree" and another represents "differ". For C sources,
create a context diff. For powerpoint presentations...

If the creator of the files (e.g., a developer) is consistent in
his naming conventions, then creating such rules is (relatively) easy
and ensures the file isn't manglede by the VCS (e.g., replacing CRLFs
with LFs, keyword substitutions that weren't intended, etc.)

You can *manually* tag individual files -- but, then you may be faced
with thousands of such tagging operations (especially when importing
someone else's sources)

For example, I have bitmap called M.A.C.C. -- how should it be treated?

And, "ReadMe" matches the "default" wildcard so should I treat its
contents as "binary"? Or, add rules:

ReadMe special notes
Makefile make(1) rules
makefile make(1) rules

This mess because UNIX doesn't let an application (that created a
particular file!) *tag* that file with a specific "type".
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On 8/23/2026 12:42 AM, Lawrence DrCOOliveiro wrote:

On Sat, 22 Aug 2026 19:15:19 -0700, Don Y wrote:

On 8/22/2026 6:19 PM, Lawrence DrCOOliveiro wrote:

On Sat, 22 Aug 2026 18:04:48 -0700, Don Y wrote:

The value of version control is to be able to recreate a
particular point-in-time of <whatever> you are controlling.

Any backup/restore system can do that, surely.

That is time based. You want to declare a "version" -- branch -- of
the development and capture THAT.

Fine. Store that info as part of the metadata for the backup snapshot.

Another "bolt on solution" instead of addressing the real issue.

Your VCS can't handle anything but text -- so, pretend anything that is
NOT text doesn't count.

Sounds like software developers deciding what the world should be like
instead of adapting to the world that exists. And, using "what is"
in place of "what should be".

The advantage of saving entire development system states is you
don't have to wonder what OTHER things affect the operation of the
tool that you need to access, again.

Yes, but again, thatrCOs what backup snapshots are for. VCSes serve a somewhat different purpose.

No. You're just limiting them to that.

P4 seems to be able to address these issues.
<https://www.perforce.com/blog/vcs/version-control-for-binary-files>
"Ah, but that's PAID software; we're too cheap to use such things!"

Here's a photo of my back yard. Here's another. What has changed
(please indicate that in a human-friendly form).

HererCOs a photo of someone elserCOs back yard. It started out similar to yours, but has undergone its own renovations. You like some of what
theyrCOve done, and would like to selectively apply those changes to
your own back yard, which has in its turn evolved somewhat in the
meantime. How would you do that?

Can he even DESCRIBE what he did? Ask Da Vinci how you could paint
a Mona Lisa. I'm sure his explanation would all be textual, right?
And, sufficient to enable you to reproduce a Mona Barbara...

Not everything is "source code".

VCSes are best precisely at dealing with textual source code, and with anything that can be represented as that.

No. Just the VCSs that you've used and just with the limitations
you've set upon your work style.

file(1) is almost WORSE than using file extensions. As with a Mac, I
(or an application) should be definitively declaring the form and
content of a file, instead of leaving that to something else to
deduce or declare (possibly incorrectly)

Apple had the old rCLFourCCrCY or rCLOSTyperCY type/creator system decades ago, but abandoned all that in favour of file extensions.

Because the rest of THEIR world went to file view extensions
as having significance. That doesn't mean it's the right answer.

Why does "foo.c" have to be a C source file? Why can't "foo"
serve to name that thing? If you insist on knowing what sort
of thing "foo" represents, then have something augment its
name with that information. You don't hesitate to augment
its name with its size, owner, access permissions -- who decided
that THOSE were the most important bits of metadata??

Just because they are convenient to access doesn't make them
important. If a file type was important and convenient
to access (by design), you'd display it, too, right?

These days, we have MIME types. And common Linux filesystems allow
those to be attached to files in a similar way to those type/creator
codes on the old Apple Mac systems. Except MIME types are a somewhat
more extensible system, using more descriptive strings instead of
cryptic four-byte codes.

The limitation of 4 byte codes is unrealistic. 4 billion different
*types* of files? That's not enough so we have to resort to mime
types expressed as text (so humans can glance at them and understand their meanings?).

Do we have 4 billion mime types? How did mime solve THAT limitation??

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Don Y <blockedofcourse@foo.invalid> wrote: |----------------------------------------------------------------------------| |"Again, it only works if you tell the OS about your particular file type and| |every other machine that will ever see files of that type. That's what | |Apple did, ages ago." | |----------------------------------------------------------------------------|

Commodore-Amiga owners used to similarly promote the original
operating system for Commodore Amigas when they used to belittle
Microsoft DOS.
(S. HTTP://Gloucester.Insomnia247.NL/ fuer Kontaktdaten!)
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On 8/23/2026 2:09 AM, C||il|!n Niocl|is|!n Glost|-ir wrote:

Don Y <blockedofcourse@foo.invalid> wrote: |----------------------------------------------------------------------------|
|"Again, it only works if you tell the OS about your particular file type and|
|every other machine that will ever see files of that type. That's what |
|Apple did, ages ago." |
|----------------------------------------------------------------------------|

Commodore-Amiga owners used to similarly promote the original
operating system for Commodore Amigas when they used to belittle
Microsoft DOS.

Treating everything as TEXT or NOT_TEXT is arrogant and self-serving.

/etc/ethers, /etc/bootptab, /etc/hosts and scads of other files
would be assessed as "text files".

Yet, if I took the *contents* of those files and randomly reassigned
them to the 'wrong" names, they would all fail spectacularly in their
intended function.

Because they are text *representation* of radically different THINGS.

Worse, you wouldn't KNOW they were "corrupted" until they were referenced.
So, you'd have a latent bug in your system, because there is nothing
ensuring that /etc/ethers complies with the definition of an
"ethers(5) file", etc.

And, because they are text files, one would assume they could be
manipulated by a text editor (!). Thus allowing anyone to
(un)intentionally corrupt them with the same delayed realization
AB:CD:EF:GH:IJ:KL is not a valid MAC
*(&^jsdf no such host
etc.

With *typed* objects, you can create tools that preserve and enforce
those type constraints -- in addition to MEANINGFULLY showing you the difference between arbitrary versions thereof.

So,
X = 2
and
#define TWO (2)
X = TWO
and
X=1+1
are identical programs. They are just EXPRESSED differently.

You can ignore differences in whitespace -- because you
rationalize that it has no meaning (unless quoted). So,
why can't you ignore differences in expression -- of identical
concepts?

If I globally replace "identifier1" with "identifier2", how many silly
hits are you going to come up with to highlight a difference that doesn't exist?

diff -picknits A B

How does (*ptr).member differ from ptr->member, other than lexical form?
If I systematically went through my sources and made that change,
you'd show me (possibly) hundreds of differences -- that aren't REALLY differences. Simply because you fixate on ASCII symbols and their corresponding glyphs.

I.e., your tool is crippled by "cheap" assumptions -- likely put
in place in case someone wants to drag out a PDP-11 with 16K of core
to run the tool!

But, let's keep our feet firmly tied in the past so when we have
graphical programming languages, everyone will insist on some way of representing them as unambiguous text with precise 1:1 mappings
(so the spatial relationships are preserved, etc.). Anyone wanting to
use things other than text can reinvent the wheel -- likely with
backwards support for text for those folks still tied to that
representation.

The great thing about "evolution" is it takes forever to make
real progress!
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Don Y <blockedofcourse@foo.invalid> wrote:

The value of version control is to be able to recreate a particular >point-in-time of <whatever> you are controlling.

That is one of the many values of version control.

Another interesting thing is that if I make a change to a file and at the
same time you make a change to a file, we should be able to consolidate both changes when the files are checked in. (Not all CS do this, and there are
some disadvantages, but it can be better when you have coarse granularity because there's a lot of stuff in a file.)
--scott

"The current build is failing, I get syntax errors in function X."
-- programmer

"Oh, don't use function X, I haven't finished writing it."
-- so-called project director
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Don Y <blockedofcourse@foo.invalid> wrote:

On 8/22/2026 8:51 PM, Rich wrote:

In comp.misc Don Y <blockedofcourse@foo.invalid> wrote:

Sadly, UNIX assumes file type is completely indicated by
a suffix on a filename -- said suffix being under the control
of the person who selected the filename.

Nope. You are mixing up ms windows (where the file extension is
believed to always be right and descriptive of the contents) with Unix
(which actually looks at the files contents and pays no attention to
any part of the name).

One configures applications (CVS in this case) to use the extension
of the file as an indication of how it should be treated.

You can do this, but you can also let it use the magic numbers instead.
Which is appropriate depends on your environment.

The contents still don't tell you what the file is or how it is intended
to be used. Because no OS can infer the purpose of a "stream of bytes" >without having been previously informed of that.

That's why we have magic numbers. Not every file has a valid magic number
but if it doesn't, it will default to "data" type which is the default
"I don't know." Use the "file" command on the command line and see how effective it is.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Computer Nerd Kev wrote:

In comp.misc Don Y <blockedofcourse@foo.invalid> wrote:

On 8/21/2026 12:32 PM, Scott Dorsey wrote:

=?UTF-8?B?IEdsb3N0w6lpcg==?= <thanks-to@Taf.com> wrote:

I do not yet have a first-hand experience of an SSD failure. Don Y
complains in news:sci.electronics.design that an SSD suddenly
completely failed, instead of gradual partial degradations of a hard
disk. What does Lawrence D'Oliveiro mean by
"before
showing signs of failure."?

With a conventional hard drive, first you might see some error numbers
creeping up on your SMART tool, as individual blocks start failing. There >>> is a bad block replacement process that is transparent to the OS so all you >>> see are bad numbers on SMART. Then you start getting media errors and
then it's all over.

Here's something to add to your dossier, since I know you are computer
guys without girlfriends:

Fed up with a girl I was working on, I basically told her to fuck off, something I had never quite said to her before. She gave a short quip
chiding me, and later I returned from an errand at AT&T to find standing
water on my keyboard.

There were three categorical alerts raised, one of which was a hard
drive fail.

The good news is that, even though I'd heard of such, everything came
back to normal, but it surprised me because the timeline was much longer
than I'd expected.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On 8/23/2026 5:53 AM, Scott Dorsey wrote:

Don Y <blockedofcourse@foo.invalid> wrote:

On 8/22/2026 8:51 PM, Rich wrote:

In comp.misc Don Y <blockedofcourse@foo.invalid> wrote:

Sadly, UNIX assumes file type is completely indicated by
a suffix on a filename -- said suffix being under the control
of the person who selected the filename.

Nope. You are mixing up ms windows (where the file extension is
believed to always be right and descriptive of the contents) with Unix
(which actually looks at the files contents and pays no attention to
any part of the name).

One configures applications (CVS in this case) to use the extension
of the file as an indication of how it should be treated.

You can do this, but you can also let it use the magic numbers instead.
Which is appropriate depends on your environment.

And, its going to magically be able to compare JPGs, executables,
.so's, etc?

Play with something like Beyond Compare (Windows) and see how helpful
file comparison can be.

The contents still don't tell you what the file is or how it is intended
to be used. Because no OS can infer the purpose of a "stream of bytes"
without having been previously informed of that.

That's why we have magic numbers. Not every file has a valid magic number but if it doesn't, it will default to "data" type which is the default
"I don't know." Use the "file" command on the command line and see how effective it is.

See my post regarding file equivalence and how "text" -- so common in
UNIX systems (esp for configuration "databases") -- means so little.
Yet, folks want to bias the VCS towards supporting that over all
other "file types".
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On 8/23/2026 5:49 AM, Scott Dorsey wrote:

Don Y <blockedofcourse@foo.invalid> wrote:

The value of version control is to be able to recreate a particular
point-in-time of <whatever> you are controlling.

That is one of the many values of version control.

Another interesting thing is that if I make a change to a file and at the same time you make a change to a file, we should be able to consolidate both changes when the files are checked in. (Not all CS do this, and there are some disadvantages, but it can be better when you have coarse granularity because there's a lot of stuff in a file.)

So diff and merge become even more important.

"But, lets limit them to just text files... and someone else can
create a tool that performs the same functionality for NON-test
files (?)"

--scott

"The current build is failing, I get syntax errors in function X."
-- programmer

"Oh, don't use function X, I haven't finished writing it."
-- so-called project director

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Lane W <cactus_DAC@yahoo.com> wrote:

Fed up with a girl I was working on, I basically told her to fuck off, >something I had never quite said to her before. She gave a short quip >chiding me, and later I returned from an errand at AT&T to find standing >water on my keyboard.

There were three categorical alerts raised, one of which was a hard
drive fail.

The good news is that, even though I'd heard of such, everything came
back to normal, but it surprised me because the timeline was much longer >than I'd expected.

She should have used coca-cola. I worked years ago at a hospital where
someone had spilled cola into an HP2626 terminal and left it over the
weekend. There were large sections of the board where the traces were completely dissolved.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Don Y <blockedofcourse@foo.invalid> wrote:

One configures applications (CVS in this case) to use the extension
of the file as an indication of how it should be treated.

You can do this, but you can also let it use the magic numbers instead.
Which is appropriate depends on your environment.

And, its going to magically be able to compare JPGs, executables,
.so's, etc?

No, but it (at least SCCS) will know to treat different kinds of file differently.

There's no reason you couldn't have a jpeg-comparing function these days. That's the marvel of the Unix philosophy... modularity.

Play with something like Beyond Compare (Windows) and see how helpful
file comparison can be.

See my post regarding file equivalence and how "text" -- so common in
UNIX systems (esp for configuration "databases") -- means so little.
Yet, folks want to bias the VCS towards supporting that over all
other "file types".

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."
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On 8/23/2026 9:08 AM, Scott Dorsey wrote:

Don Y <blockedofcourse@foo.invalid> wrote:

One configures applications (CVS in this case) to use the extension
of the file as an indication of how it should be treated.

You can do this, but you can also let it use the magic numbers instead.
Which is appropriate depends on your environment.

And, its going to magically be able to compare JPGs, executables,
.so's, etc?

No, but it (at least SCCS) will know to treat different kinds of file differently.

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

Play with something like Beyond Compare (Windows) and see how helpful
file comparison can be.

See my post regarding file equivalence and how "text" -- so common in
UNIX systems (esp for configuration "databases") -- means so little.
Yet, folks want to bias the VCS towards supporting that over all
other "file types".

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.

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

Tools should augment your abilities, enhance your productivity, etc.
Not constrain it or coerce it into a specific form to suit THEIR
limitations.

There's no reason for the absence of a viethers tool. Or, vihosts. Or, viboottab. And just imagine all of the tools you could create to keep
X configured properly!! The existence of such tools would free the implementation to use a form other than "text files".

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

Instead, you have to "manually" enforce the rules for these with discipline
and awareness *or* deliberately invoke soomething else that will check
them for you.

"Use leading spaces instead of tabs"
"Ensure file is terminated with a newline"

Because that's the way it has always been (yet we can freely make sweeping changes to OTHER things that are more consequential). But, we want to keep these things for just the use of The Elite, right? <rolls eyes>
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On 8/23/2026 9:05 AM, Scott Dorsey wrote:

Lane W <cactus_DAC@yahoo.com> wrote:

Fed up with a girl I was working on, I basically told her to fuck off,
something I had never quite said to her before. She gave a short quip
chiding me, and later I returned from an errand at AT&T to find standing
water on my keyboard.

There were three categorical alerts raised, one of which was a hard
drive fail.

The good news is that, even though I'd heard of such, everything came
back to normal, but it surprised me because the timeline was much longer
than I'd expected.

She should have used coca-cola. I worked years ago at a hospital where someone had spilled cola into an HP2626 terminal and left it over the weekend. There were large sections of the board where the traces were completely dissolved.

As a kid, we used to use coke to clean the rust off our bicycles.
Imagine what it was doing to our *teeth*!

[Apparently, kids, nowadays, have their teeth "sealed" and don't
experience the sort of "repairs" of ages past.]

Regarding water...

I volunteer at a place that recycles various types of kit
(electronic, medical, etc.). One of the guys brings batches of
keyboards home and cleans them in his swimming pool (!).

I've rescued kit that has been left outdoors (at that facility)
during rainstorms and have been surprised as to how much of it still works. Conceptually, rain water should be pure -- but, in reality, it
picks up lots of crap as it passes through the atmosphere, changing
its "content" and pH.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Don Y <blockedofcourse@foo.invalid> 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
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On 8/23/26 19:09, Scott Dorsey wrote:

Don Y <blockedofcourse@foo.invalid> 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






--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

In sci.electronics.design Scott Dorsey <kludge@panix.com> wrote:

Don Y <blockedofcourse@foo.invalid> wrote:

[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

You are noticing a common Don Y trolling method. Jump over to sci.electronics.design and read through a sample of threads started by
Don Y and a sample of Don Y replies. You'll quickly notice several
very common patterns that are repeated over and over again.

For threads begun by Don Y, there will be some initial vague question
asking help or suggestions about something. As you read through
replies to the tread, the pattern that will emerge is that, without
fail, every time a group member suggests another solution to the Don Y question, Don Y will shoot down that suggestion with a new requirement
that was never stated before, either in the initial post, nor in any
reply in the thread to that point. And they will often be what appear
to be "out of left field" requirements, such as "no, that won't work,
because the user performing the device swap must be able to insert the
cable by feel as they cannot see the rear of the enclosure and must
reach around to install cable X" or "no, this device must be capable of
being operated by individual with learning disabilities and so it can't
use 'GUI pattern style Z' for its interface". So it is not possible to
guess the unstated requirements because they are esoteric enough that
no one would rightly think that requirement exists from the starting
vague post.

Second, for any reply by Don Y, there will be about 35-40% of the post
devoted to responding to the prior post, with the remaining 60-65% of
the post devoted to seemingly irrelevant asides or vaguely tangential
points. You have recognized one of those here. You'll also note a
pattern here from Don Y's posts. If the text provided by Don Y is
enclosed in square brackets, then it is very often (90+% chance) that
it is one of those irrelevant asides or vaguely tangential points.

Third, no matter how many unspoken requirements are slowly extracted
from Don Y by numerous different responders to his threads, no offered
solution will ever be sufficient. There will always be some response
to indicate why the last post was not feasible. This pattern implies
that the Don Y nick is one of those personality types that must always
have the last word, and must have the last word in such a way as to
appear in their own mind to be right, regardless of actual correctness.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On 8/23/2026 12:07 PM, Bertrand Sindri wrote:

Third, no matter how many unspoken requirements are slowly extracted
from Don Y by numerous different responders to his threads, no offered solution will ever be sufficient. There will always be some response
to indicate why the last post was not feasible. This pattern implies
that the Don Y nick is one of those personality types that must always
have the last word, and must have the last word in such a way as to
appear in their own mind to be right, regardless of actual correctness.

Notice how the nick Bertrand Sindri objects so vociferously -- yet seems unable to look away! Hint: most news clients have the concept of a kill file
yet, despite his apparent displeasure with my posts, he hasn't managed to
sort out how to use HIS!

Gotta wonder... he must see value, there!

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Don Y <blockedofcourse@foo.invalid> 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.

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.

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.

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.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

In comp.misc, Scott Dorsey <kludge@panix.com> wrote:

She should have used coca-cola. I worked years ago at a hospital where someone had spilled cola into an HP2626 terminal and left it over the weekend. There were large sections of the board where the traces were completely dissolved.

I was just reading about someone who lost a circuit board to Monster
Energy today. I gather it destroyed the board itself, not just the
traces.

Apparently it was left all weekend in the footwell of a car with the
spilt beverage. Possibly there was other stuff in the soup.

Elijah
------
"mmmm, mmmm" says the Campbell's kid
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On 8/23/2026 8:20 PM, Eli the Bearded wrote:

In comp.misc, Scott Dorsey <kludge@panix.com> wrote:

She should have used coca-cola. I worked years ago at a hospital where
someone had spilled cola into an HP2626 terminal and left it over the
weekend. There were large sections of the board where the traces were
completely dissolved.

I was just reading about someone who lost a circuit board to Monster
Energy today. I gather it destroyed the board itself, not just the
traces.

Apparently it was left all weekend in the footwell of a car with the
spilt beverage. Possibly there was other stuff in the soup.

Carbonated beverages often contain phosphoric acid:

Phosphoric acid (HreaPOrea) is a clear, odorless inorganic acid most commonly used
to make fertilizers, add a sour or tangy taste to sodas and foods, and remove rust from metals. Pure phosphoric acid is a solid, but it is usually sold as an
85% liquid
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On Sun, 23 Aug 2026 08:47:27 -0700, Don Y wrote:

And, its going to magically be able to compare JPGs, executables,
.so's, etc?

Play with something like Beyond Compare (Windows) and see how
helpful file comparison can be.

Does Beyond Compare do comparisons on arbitrary binary files?

On Linux, for example, we can do something like

diff -u <(xxd file1) <(xxd file2) | less -iX

to compare hex dumps.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On Sun, 23 Aug 2026 00:37:07 -0700, Don Y wrote:

In UNIX, you only have the file name to rely on -- there is no other
metadata available to an application/system that wants to ascertain
the nature of the file/object that it is being asked to process.

This is why you have rCLmagic numbersrCY -- clues in the initial part of
the file.

In CVS, "wrappers" lets you associate "file types" with specific
handling options.

This is a CVS thing, not a Unix thing. Git has something probably more
advanced <https://git-scm.com/docs/gitattributes>.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On 8/23/2026 8:47 PM, Lawrence DrCOOliveiro wrote:

On Sun, 23 Aug 2026 08:47:27 -0700, Don Y wrote:

And, its going to magically be able to compare JPGs, executables,
.so's, etc?

Play with something like Beyond Compare (Windows) and see how
helpful file comparison can be.

Does Beyond Compare do comparisons on arbitrary binary files?

Yes. If, for example, you have inserted a byte in one, it
will display a "hole" in that location in the other to
show the balance in agreement, though offset, in much the same
way you would compare text that had an inserted line.

If you compare two images, it will show the difference
visually.

It tries to understand the forms of various file types
and tailor its comparison to that type. It's aware of many
different formats (excel, word, pdf, etc.) and tries
to add value to each presentation -- instead of just
saying "they are different" (or "binary same")

<https://www.scootersoftware.com/home/gallery> <https://www.scootersoftware.com/home/multifaceted>

Additionally, the sources and destinations can be on remote machines,
accessed via SMB shares, FTP, etc. So, I can compare the contents of
one FTP server to another on a different host and note the differences
as well as synchronize them.

And, it isn't plagued with the path length problem that Explorer has,
so you can use *it* to drill down deeper than Explorer would otherwise
allow. This is handy when one of the targets is a UNIX machine
and the other windows.

On Linux, for example, we can do something like

diff -u <(xxd file1) <(xxd file2) | less -iX

to compare hex dumps.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On 8/23/2026 9:04 PM, Lawrence DrCOOliveiro wrote:

On Sun, 23 Aug 2026 00:37:07 -0700, Don Y wrote:

In UNIX, you only have the file name to rely on -- there is no other
metadata available to an application/system that wants to ascertain
the nature of the file/object that it is being asked to process.

This is why you have rCLmagic numbersrCY -- clues in the initial part of
the file.

They are only present in some filetypes. E.g., others get lumped in
a broad category: data, ASCII text, etc.

In CVS, "wrappers" lets you associate "file types" with specific
handling options.

This is a CVS thing, not a Unix thing. Git has something probably more advanced <https://git-scm.com/docs/gitattributes>.

"wrappers" exists as a convenience to avoid having to individually
tag each version controlled file with information about how they
should be handled. E.g., newline conversion, keyword expansion,
which bit of code to use to perform the comparison, how merge
should be handled, etc.

If careful, you can let *it* do the work instead of having to manually
tag potentially thousands of files in a "module".

If UNIX had "file type" metadata, then you could just map that to
the tagging (and processing) requirements instead of relying on consistency
in file naming as a hack.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On Sun, 23 Aug 2026 11:44:45 -0700, Don Y wrote:

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

Maybe it isnrCOt. I already pointed out how you should be using resolution-independent SVG for your master graphics.

Take apart a document from common present-day office suites and what
do you find at the core? XML!
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On Sun, 23 Aug 2026 08:49:38 -0700, Don Y wrote:

So diff and merge become even more important.

"But, lets limit them to just text files... and someone else can
create a tool that performs the same functionality for NON-test
files (?)"

Nobody seems able to. This is why text formats remain so important.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On Sun, 23 Aug 2026 21:58:32 -0700, Don Y wrote:

On 8/23/2026 8:47 PM, Lawrence DrCOOliveiro wrote:

On Sun, 23 Aug 2026 08:47:27 -0700, Don Y wrote:

And, its going to magically be able to compare JPGs, executables,
.so's, etc?

Play with something like Beyond Compare (Windows) and see how
helpful file comparison can be.

Does Beyond Compare do comparisons on arbitrary binary files?

On Linux, for example, we can do something like

diff -u <(xxd file1) <(xxd file2) | less -iX

to compare hex dumps.

Yes. If, for example, you have inserted a byte in one, it will
display a "hole" in that location in the other to show the balance
in agreement, though offset, in much the same way you would compare
text that had an inserted line.

It tries to understand the forms of various file types and tailor
its comparison to that type. It's aware of many different formats
(excel, word, pdf, etc.) and tries to add value to each presentation
-- instead of just saying "they are different" (or "binary same")

Additionally, the sources and destinations can be on remote
machines, accessed via SMB shares, FTP, etc. So, I can compare the
contents of one FTP server to another on a different host and note
the differences as well as synchronize them.

And, it isn't plagued with the path length problem that Explorer
has, so you can use *it* to drill down deeper than Explorer would
otherwise allow. This is handy when one of the targets is a UNIX
machine and the other windows.

So really, what yourCOve got there is one giant bloated executable that
has to subsume the functions of what, in the Linux/*nix world, would
be a dozen separate tools -- including the format-guessing functions
of libmagic plus its own custom file explorer, it would seem. Only in
a less flexible, more monolithic form.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On 8/23/2026 9:59 PM, Lawrence DrCOOliveiro wrote:

On Sun, 23 Aug 2026 11:44:45 -0700, Don Y wrote:

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

Maybe it isnrCOt. I already pointed out how you should be using resolution-independent SVG for your master graphics.

And I already pointed out that vector/line art doesn't work when
rasterized at very low resolutions. You have to hand-draw glyphs
and other symbols at those sizes -- especially when your choices
for each pel are ON and OFF.

Put a serif on a glyph and the serif looks disproportionately large.
Dot an I and the dot is 1/3 the size of the i!

We used to spend considerable amount of time hand-drawing fonts for
dot-matrix printers (teleprinters, etc.) You end up with glyphs
that deviate significantly from the "ideal" simply because you don't
have room to express any detail.

Consider an uppercase A. The apex will likely be in the 3rd (of 5 across)
pel in the first row. The feet will anchor in the 1st and 5th pels of
the bottom (of 7 high) row. Now, you have to get from each foot to
the apex -- knowing that there is only *one* column between your start
and end points. Your vector art would cross that column in 5 different
places along its way; you get to pick *one*.

By hand, you would likely draw vertical uprights from each foot (deviating
from what your vector art suggests) and bridge the column to the apex
very close to that point -- so a single dot IMPLIES the sloping legs.

Imagine how you would draw an @. Or, &. Get out some quadrille paper
and a soft pencil/crayon. It's fun! (perhaps your printer shouldn't be
able to print these glyphs? Prohibit people from using them in correspondence?)

Take apart a document from common present-day office suites and what
do you find at the core? XML!

Really? Have a look at the files created by these mainstream tools:
<https://mega.nz/folder/oiJlVAAQ#RD9jjzpEQz0Muskjn2L3jA>

Now, suppose I had a tool that told you that the 47th byte (of any file)
was changed to a 0x22. What use is that information to you, beyond "this
file doesn't agree with this OTHER file!"

If, for example, I changed the default typefaces loaded in the FrameMaker
file, that would show up as a difference (the typefaces names are in ASCII). But, not one that made a REAL difference in the rendered document -- if I
never referenced the typefaces elided! How would you know that, looking at
the diffs?

Even for tools that have the ability to generate XML, there is usually so much cruft that you can't tell what the effective difference is, examining the text.

Remember, the goal is to UNDERSTAND the differences, not just note that
they exist -- as they may be inconsequential.

[E.g., a common RCS practice was to include commit messages IN the
affected documents. This clutters up the document. Many folks opted
to remove them from HEAD, going forward. But, there seem to be a
lot of differences between the version prior to their removal and
after -- despite the fact that all are effectively commentary.]

Would you look for a bug or anomalous behavior in a source file that
had lots of differences -- but, none that actually cause different
CODE to be generated?

#define TWO (2)
...
X = TWO

vs.

X = 2

Two different lines yet no difference in the resulting binary.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On 8/23/2026 11:44 PM, Lawrence DrCOOliveiro wrote:

On Sun, 23 Aug 2026 21:58:32 -0700, Don Y wrote:

On 8/23/2026 8:47 PM, Lawrence DrCOOliveiro wrote:

On Sun, 23 Aug 2026 08:47:27 -0700, Don Y wrote:

And, its going to magically be able to compare JPGs, executables,
.so's, etc?

Play with something like Beyond Compare (Windows) and see how
helpful file comparison can be.

Does Beyond Compare do comparisons on arbitrary binary files?

On Linux, for example, we can do something like

diff -u <(xxd file1) <(xxd file2) | less -iX

to compare hex dumps.

Yes. If, for example, you have inserted a byte in one, it will
display a "hole" in that location in the other to show the balance
in agreement, though offset, in much the same way you would compare
text that had an inserted line.

It tries to understand the forms of various file types and tailor
its comparison to that type. It's aware of many different formats
(excel, word, pdf, etc.) and tries to add value to each presentation
-- instead of just saying "they are different" (or "binary same")

Additionally, the sources and destinations can be on remote
machines, accessed via SMB shares, FTP, etc. So, I can compare the
contents of one FTP server to another on a different host and note
the differences as well as synchronize them.

And, it isn't plagued with the path length problem that Explorer
has, so you can use *it* to drill down deeper than Explorer would
otherwise allow. This is handy when one of the targets is a UNIX
machine and the other windows.

So really, what yourCOve got there is one giant bloated executable that
has to subsume the functions of what, in the Linux/*nix world, would
be a dozen separate tools -- including the format-guessing functions
of libmagic plus its own custom file explorer, it would seem. Only in
a less flexible, more monolithic form.

It is extensible. Ditto for CVS's handling of diff and merge.

What you (don't yet!) have in your UNIX approach is many executables
scattered around the file system, possibly not installed, and something
that tries to invoke each based on some criteria.

"Oh, gee, the pdfcompare program hasn't been installed on this machine.
Let me download a TRUSTED binary from a repo and try this operation
again."

"Hmmm, can't compare xwds on this box. Maybe I can compare them as binary files and try to guess the differences."

"Crap! This version of XLScompare is buggy!"

How is that any better?
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On Mon, 24 Aug 2026 00:45:55 -0700, Don Y wrote:

On 8/23/2026 11:44 PM, Lawrence DrCOOliveiro wrote:

So really, what yourCOve got there is one giant bloated executable
that has to subsume the functions of what, in the Linux/*nix world,
would be a dozen separate tools -- including the format-guessing
functions of libmagic plus its own custom file explorer, it would
seem. Only in a less flexible, more monolithic form.

It is extensible. Ditto for CVS's handling of diff and merge.

What you (don't yet!) have in your UNIX approach is many executables scattered around the file system, possibly not installed, and
something that tries to invoke each based on some criteria.

The same applies to plugins for your rCLextensiblerCY app. Only the Unix
tools offer a somewhat broader range of functionality in a more
versatile form. And we have package managers nowadays to manage
installation in a more tidy and scalable way.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On Mon, 24 Aug 2026 00:33:38 -0700, Don Y wrote:

Put a serif on a glyph and the serif looks disproportionately large.
Dot an I and the dot is 1/3 the size of the i!

<https://en.wikipedia.org/wiki/Font_hinting>

On 8/23/2026 9:59 PM, Lawrence DrCOOliveiro wrote:

Take apart a document from common present-day office suites and what
do you find at the core? XML!

Really? Have a look at the files created by these mainstream tools:
<https://mega.nz/folder/oiJlVAAQ#RD9jjzpEQz0Muskjn2L3jA>

CanrCOt see anything rCLmainstreamrCY there, IrCOm afraid. Except the epub
one.

Now, suppose I had a tool that told you that the 47th byte (of any
file) was changed to a 0x22. What use is that information to you,
beyond "this file doesn't agree with this OTHER file!"

Precisely the point why binary formats are so hard to deal with.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On 8/24/2026 4:44 PM, Lawrence DrCOOliveiro wrote:

On Mon, 24 Aug 2026 00:45:55 -0700, Don Y wrote:

On 8/23/2026 11:44 PM, Lawrence DrCOOliveiro wrote:

So really, what yourCOve got there is one giant bloated executable
that has to subsume the functions of what, in the Linux/*nix world,
would be a dozen separate tools -- including the format-guessing
functions of libmagic plus its own custom file explorer, it would
seem. Only in a less flexible, more monolithic form.

It is extensible. Ditto for CVS's handling of diff and merge.

What you (don't yet!) have in your UNIX approach is many executables
scattered around the file system, possibly not installed, and
something that tries to invoke each based on some criteria.

The same applies to plugins for your rCLextensiblerCY app.

The "plugins" will likely be in a subfolder of the tool's installation
folder. Not littered around bin, sbin, usr/sbin, usr/bin, etc. You
will open the folder and *see* what you have in place -- instead of
wandering the filesystem looking for "components".

Only the Unix
tools offer a somewhat broader range of functionality in a more
versatile form. And we have package managers nowadays to manage
installation in a more tidy and scalable way.

And you can require your machine to be online to take advantage
of those things!

Is diff multithreaded? Can I run 20 compares simultaneously?
Or, do I have to build a shell script to spawn 20 compares and
feed the rest of the files to it as each compare completes?

I can already *do* these things. Your argument is I *shouldn't*!
(because text is king!)

C'mon, I grew up with MULTICS so UNIX was just like an in-law.
And, have been running a BSD since 1993 (when you had to DL
240K files and cram 5 on a 5" floppy and 6 on a 3.5" to do
the install). I don't need a lecture on the "merits" of
any particular approach -- or their costs/consequences!

Yet, I sorely limit the tools that I use *under* UNIX because it
just doesn't support the state of the art in most tool domains.
I'm willing to embrace binary, proprietary file formats for
the power they give me and the range of tools I can use. I've
not even touched on CAD/EDA tools or multimedia authoring, etc.

[Of course, "programmers" don't deal with such things!]

You seem to want to prevent yourself from taking advantage
of those options solely because of the constraints your
(chosen!) VCS imposes!
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On 8/24/2026 4:47 PM, Lawrence DrCOOliveiro wrote:

On Mon, 24 Aug 2026 00:33:38 -0700, Don Y wrote:

Put a serif on a glyph and the serif looks disproportionately large.
Dot an I and the dot is 1/3 the size of the i!

<https://en.wikipedia.org/wiki/Font_hinting>

Doesn't matter if you are constrained by what can be *presented*.

On 8/23/2026 9:59 PM, Lawrence DrCOOliveiro wrote:

Take apart a document from common present-day office suites and what
do you find at the core? XML!

Really? Have a look at the files created by these mainstream tools:
<https://mega.nz/folder/oiJlVAAQ#RD9jjzpEQz0Muskjn2L3jA>

CanrCOt see anything rCLmainstreamrCY there, IrCOm afraid. Except the epub one.

You're experiences are likely those of a programmer so probably have little experience in professional document preparation.

QuarkXpress, FrameMaker, Ventura: <https://en.wikipedia.org/wiki/List_of_desktop_publishing_software> <https://www.guideflow.com/blog/desktop-publishing-software>

<https://www.datainsightsmarket.com/reports/font-design-software-1981044>

Fruity Loops (FL Studio), Forte, Sibelius: <https://worldmetrics.org/best/composition-music-software/> <https://www.musicianwave.com/best-music-notation-software/>

Photoshop, Lightroom, PhotoPaint: <https://www.pcmag.com/picks/the-best-photo-editing-software>

And every desktop has *icons*.

And, before you claim there are FOSS / text based products for all of
these, please indicate WHEN they became available and how they compared
to their competing paid tools 5, 10, 20 and more years ago as the paid
tools have been "producing products" for all those years that those
others have been "just dreams".

Now, suppose I had a tool that told you that the 47th byte (of any
file) was changed to a 0x22. What use is that information to you,
beyond "this file doesn't agree with this OTHER file!"

Precisely the point why binary formats are so hard to deal with.

They are hard because you haven't got the tools to deal with them
and your VCS wants to pretend they don't exist. I have no problem
tracking revisions in P4 -- but, it doesn't LIMIT itself to text!

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On Sun, 23 Aug 2026 21:58:39 -0700, Don Y wrote:

If UNIX had "file type" metadata, then you could just map that to
the tagging (and processing) requirements instead of relying on
consistency in file naming as a hack.

Linux does <https://manpages.debian.org/xattr(7)>.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On 8/25/2026 7:16 PM, Lawrence DrCOOliveiro wrote:

On Sun, 23 Aug 2026 21:58:39 -0700, Don Y wrote:

If UNIX had "file type" metadata, then you could just map that to
the tagging (and processing) requirements instead of relying on
consistency in file naming as a hack.

Linux does <https://manpages.debian.org/xattr(7)>.

Yet another bolt-on acknowledgement of something that was missing in UNIX.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On 2026-08-26, Don Y wrote:

On 8/25/2026 7:16 PM, Lawrence DrCOOliveiro wrote:

On Sun, 23 Aug 2026 21:58:39 -0700, Don Y wrote:

If UNIX had "file type" metadata, then you could just map that to
the tagging (and processing) requirements instead of relying on
consistency in file naming as a hack.

Linux does <https://manpages.debian.org/xattr(7)>.

Yet another bolt-on acknowledgement of something that was missing in UNIX.

... how do you think most features and utilities specified in IEEE
1003.1 came to be?
--
Nuno Silva
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Don Y <blockedofcourse@foo.invalid> wrote:

C'mon, I grew up with MULTICS so UNIX was just like an in-law.
And, have been running a BSD since 1993 (when you had to DL
240K files and cram 5 on a 5" floppy and 6 on a 3.5" to do
the install). I don't need a lecture on the "merits" of
any particular approach -- or their costs/consequences!

And clearly you dislike the Software Tools approach and insist on
discussing it in a completely irrelevant thread like this one.

Have you seen the AS/400? You might like the general approach, where everything is a database. Everything. I see the appeal for commercial
data processing but it's kind of hard to extend.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On 8/26/2026 1:24 PM, Scott Dorsey wrote:

Don Y <blockedofcourse@foo.invalid> wrote:

C'mon, I grew up with MULTICS so UNIX was just like an in-law.
And, have been running a BSD since 1993 (when you had to DL
240K files and cram 5 on a 5" floppy and 6 on a 3.5" to do
the install). I don't need a lecture on the "merits" of
any particular approach -- or their costs/consequences!

And clearly you dislike the Software Tools approach and insist on
discussing it in a completely irrelevant thread like this one.

This is USENET. There are no rules as to relevancy controlling where the thread goes. If you object to a particular direction, then you can
stop participating or stop reading. That's entirely under YOUR control,
not one of a moderator. If you want things to stay strictly on-topic,
find a suitable (user-moderated) forum.

I have no problem with tools, *building* tools to add specific
functionality, extending tools, chaining tools, etc. I have no problem
PAYING for tools, either (unlike some who see FOSS tools as a cheap
way out)

Requiring a user (or administrator) to carry around information about particular system objects is just silly; machines track information
far better than humans, for all but trivial things. The fact that a
Makefile has a different internal structure than a hosts(5) or
networks(5) file relies on managing such details.

Have you seen the AS/400? You might like the general approach, where everything is a database. Everything. I see the appeal for commercial
data processing but it's kind of hard to extend.

That depends on how you want to extend it and if there is a *need* to do so.

I have no filesystem in my current project. The persistent store
is implemented in an RDBMS. Because all of the persistent objects
have specific structures and the RDBMS can enforce and protect
those. Regardless of the sizes and datatypes of the individual
components.

If you want to store a text file -- or, an executable -- it's likely a
LARGE, monolithic object (BLOB), possibly augmented with other meta data associated with that "record".

And, other than access control and persistence, there's nothing the RDBMS
can add in terms of value. Just like a filesystem.

But, I don't have a need to store text files.

Most of a *system* consists of structured data encapsulated in objects of differing types -- whether active or passive objects. There, the RDBMS can
add value by ensuring that each of those component parts adhere to the
rules for their presence, values, relationships with other entities, etc.
"No, this object is not valid for use as an executable image for a
particular service; but THESE are..."

"That's not a valid MAC address (not enough octets)."

"That's an invalid hostname (you'll discover that when you try to use it)"

So, every bit of code that wants to interact with a particular object
doesn't need to be able to *parse* the object AND verify its type and
integrity (as well as its permission to access said object and
perform specific actions on them).
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

In comp.misc, Scott Dorsey <kludge@panix.com> wrote:

Have you seen the AS/400? You might like the general approach, where everything is a database. Everything. I see the appeal for commercial
data processing but it's kind of hard to extend.

There's a different approach to "everything is a database" I recently
came across.

https://fzakaria.com/2026/08/23/your-executable-is-a-sqlite-database

It starts with using sqlite in place of ELF, then it goes much, much further:

I pointed self closure at every ELF binary on this system's PATH: 723
executables, which pull in 400 distinct shared libraries. 1,123
objects, 346,386 symbols, 3,808 dependency edges, all as one SQLite
file.

Turns out when you do that, the database is much smaller than you
would expect.

Elijah
------
"strip" is new a couple of "DELETE" statements, and other tricks
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On 8/26/2026 5:46 PM, Eli the Bearded wrote:

In comp.misc, Scott Dorsey <kludge@panix.com> wrote:

Have you seen the AS/400? You might like the general approach, where
everything is a database. Everything. I see the appeal for commercial
data processing but it's kind of hard to extend.

There's a different approach to "everything is a database" I recently
came across.

https://fzakaria.com/2026/08/23/your-executable-is-a-sqlite-database

It starts with using sqlite in place of ELF, then it goes much, much further:

And SQLite is just one exemplar of a DBMS. The issue is one of assigning structure to the "collections of bits" that tend to be scattered around
a store that we call a filesystem.

I pointed self closure at every ELF binary on this system's PATH: 723
executables, which pull in 400 distinct shared libraries. 1,123
objects, 346,386 symbols, 3,808 dependency edges, all as one SQLite
file.

Turns out when you do that, the database is much smaller than you
would expect.

Because you don't need the arbitrary structure of the filesystem and
the metadata that *it* considers important. Bind a unique identifier
to each object/entry point and there is no need for filenames and
other human-centric identifiers (you can preserve those OFFLINE in
your build environment but there's no need to carry them into the
deployed product, beyond inertia: "That's the way we've 'always'
(for some small value of 'always') done it!"

You can include versioning in such a database so that a binding can
know which version of an object to access ("dereference").

And, if you delay binding, that decision can happen each time you
re-bind!

Furthermore, if you place objects in isolated containers, you can
re-bind WHILE objects are in use instead of having to restart
or (gag!) reBOOT!

But, as the author quietly laments:
"I explored the idea during my PhD thesis but found feedback from
others unmotivating. Radical ideas are hard to sell, as you are
working against the inertia of the established solution."
The Masses are rarely known to create new ideas (or facilitate their
creation).

Elijah
------
"strip" is new a couple of "DELETE" statements, and other tricks

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On Tue, 25 Aug 2026 19:54:41 -0700, Don Y wrote:

On 8/25/2026 7:16 PM, Lawrence DrCOOliveiro wrote:

On Sun, 23 Aug 2026 21:58:39 -0700, Don Y wrote:

If UNIX had "file type" metadata, then you could just map that to
the tagging (and processing) requirements instead of relying on
consistency in file naming as a hack.

Linux does <https://manpages.debian.org/xattr(7)>.

Yet another bolt-on acknowledgement of something that was missing in
UNIX.

ItrCOs an extensible scheme, fit for creating a UNIX for the 21st
century.

How does Apple do it? The old OSType mechanism was 4 bytes each for type/creator, and that was it.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Lawrence DrCOOliveiro wrote:

On Tue, 25 Aug 2026 19:54:41 -0700, Don Y wrote:

On 8/25/2026 7:16 PM, Lawrence DrCOOliveiro wrote:

On Sun, 23 Aug 2026 21:58:39 -0700, Don Y wrote:

If UNIX had "file type" metadata, then you could just map that to
the tagging (and processing) requirements instead of relying on
consistency in file naming as a hack.

Linux does <https://manpages.debian.org/xattr(7)>.

Yet another bolt-on acknowledgement of something that was missing in
UNIX.

ItrCOs an extensible scheme, fit for creating a UNIX for the 21st
century.

How does Apple do it? The old OSType mechanism was 4 bytes each for type/creator, and that was it.

Didn't Apple have a forked file system? Seems to me that Apple could
preserve OS/2's extended attributes (xttr's) over the LAN.
As an aside, OS/2 started supporting extended attributes with the
release of the HPFS file system in 1988 (also supported in FAT) and used
them a lot in OS/2 v2+.
Dave
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On 23/08/2026 20:07, Bertrand Sindri wrote:

In sci.electronics.design Scott Dorsey<kludge@panix.com> wrote:

Don Y<blockedofcourse@foo.invalid> wrote:

[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

You are noticing a common Don Y trolling method. Jump over to sci.electronics.design and read through a sample of threads started by
Don Y and a sample of Don Y replies. You'll quickly notice several
very common patterns that are repeated over and over again.

I was quite impressed by the quality of his trolling. I've seen similar
styles by 1 or 2 others, "rudy meisner" springs to mind. I'd not been following the thread for a while and was impressed to see the scale of activity when I looked today. He's in the virtual *plink*-list at the
moment but yet to migrate to fully *plinked*.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On Thu, 27 Aug 2026 00:46:22 -0000 (UTC), Eli the Bearded wrote:

There's a different approach to "everything is a database" I recently
came across.

https://fzakaria.com/2026/08/23/your-executable-is-a-sqlite-database

Microsoft did try to go further. Back in the 1990s, I think, they had
something called rCLproject CairorCY, which turned the entire filesystem
into a database. This later morphed into rCLWinFSrCY, which was one of
three major deliverables promised for Windows Vista.

None of the three made it to shipping.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Dave Yeo <dave.r.yeo@gmail.com> wrote:

Didn't Apple have a forked file system? Seems to me that Apple could >preserve OS/2's extended attributes (xttr's) over the LAN.

Yes. Apple had two forks, resource and data, so metadata was kept
separately.

When OS X came out, they started out using a "named fork" mechanism under
HFS+ but then later they moved to multiple different ways that atttributes
were stored and it all became messy and confusing because there were multiple legacy methods all being used.

As an aside, OS/2 started supporting extended attributes with the
release of the HPFS file system in 1988 (also supported in FAT) and used >them a lot in OS/2 v2+.

The more I work with stuff like this, the more I like the Unix world where everything is flat. VMS had a lot of very fancy filesystem features that
were great in a commercial data processing environment but were nothing but frustrating in a scientific computing environment.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On Sat, 29 Aug 2026 19:53:43 -0700, Dave Yeo wrote:

Didn't Apple have a forked file system?

The old MacOS did, not sure about the current one.

Seems to me that Apple could preserve OS/2's extended attributes
(xttr's) over the LAN.

ThererCOs no standard for such things across different OSes, though.

As an aside, OS/2 started supporting extended attributes with the
release of the HPFS file system in 1988 (also supported in FAT) and
used them a lot in OS/2 v2+.

I gather that NTFS in Windows NT generalizes ApplerCOs original two-fork concept to allow for multiple forks (called rCLstreamsrCY, I think). Not
much software actually makes use of this, though.

On the Linux side, the Reiser4 filesystem was going to generalize this
concept even further, by unifying the concepts of files and
directories into one. So every filesystem item could be treated as a conventional file containing bytes of data with no predetermined
structure, and also as a directory containing further filesystem
items, which could be in their turn be accessed as both files and
directories, and so on.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

In sci.electronics.design mm0fmf <none@invalid.com> wrote:

On 23/08/2026 20:07, Bertrand Sindri wrote:

In sci.electronics.design Scott Dorsey<kludge@panix.com> wrote:

Don Y<blockedofcourse@foo.invalid> wrote:

[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

You are noticing a common Don Y trolling method. Jump over to
sci.electronics.design and read through a sample of threads started
by Don Y and a sample of Don Y replies. You'll quickly notice
several very common patterns that are repeated over and over again.

I was quite impressed by the quality of his trolling.

It is subtle and skillfully done. Subtle enough that a great many on sci.electronics.design fall for it again and again, like moths to a
flame. They keep the troll fully fed, so it keeps returning for more.

I've seen similar styles by 1 or 2 others, "rudy meisner" springs to
mind. I'd not been following the thread for a while and was
impressed to see the scale of activity when I looked today. He's in
the virtual *plink*-list at the moment but yet to migrate to fully
*plinked*.

I've had the troll fully plonked for a while. Sadly, when the others
who fall for its trolling respond to its rants, then I still end up
having to wade through some of its trolling output in the quotes in
their replies.

--- Synchronet 3.22a-Linux NewsLink 1.2