Re: SSD TBW

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.

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!

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.

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.

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.

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

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

Carbonated beverages often contain phosphoric acid:

Phosphoric acid (H₃PO₄) 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

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.

This is why you have “magic numbers” -- clues in the initial part of the file.

This is a CVS thing, not a Unix thing. Git has something probably more advanced

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

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.

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

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

Maybe it isn’t. 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!

Nobody seems able to. This is why text formats remain so important.

So really, what you’ve 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.

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

Really? Have a look at the files created by these mainstream tools:

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.

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.

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?

The same applies to plugins for your “extensible” 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.

Can’t see anything “mainstream” there, I’m afraid. Except the epub one.

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

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

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

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.

You seem to want to prevent yourself from taking advantage of those options solely because of the constraints your (chosen!) VCS imposes!

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

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

QuarkXpress, FrameMaker, Ventura:

Fruity Loops (FL Studio), Forte, Sibelius:

Photoshop, Lightroom, PhotoPaint:

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

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!

Linux does