Subj : Re: Windows vs Linux To : tenser From : boraxman Date : Mon Apr 25 2022 12:50:52 te> And yet that "one system, out-of-the-box, [that] is te> designed around this paradigm" is useless for this te> kind of work. The other that is "adding a better te> shell language" (nevermind that PowerShell is 15 years te> old) can do it. te> te> Something I had to come to terms with 15 or so years te> ago is that the Unix pipeline model _has limitations_. te> te> But a couple of shell scripts and some awk will do better? te> te> I've heard this many times, and implemented it a few times te> myself. The thing that happens time and time again is that te> it seems simple at first, but systems grow to accommodate te> special cases and you start to realize that those "rigid" te> packages actually have real value. te> te> Again, computers are _tools_. Use them to do real work; for te> most people, they are not the end in and of themselves. te> The problem can be solved with the use of scripts, PGP, absolutely. The problem is mainly storage of documentation, procedures. We want procedures which we can export to different formats (PDF for printing, webpage for online browsing), but also have the documentation segemented, so we can mix and match sections. Some documentation will take data from a database, so that product information, specifications can extract it from a "True source of data". When someone updates the "true source of data", we can update the specs, documentation which extracts that data without having to actually open it up, manually LOOK at a scanned document, type it in, send it, get someone to check you've typed it in right, send it back, etc etc. This is typical, and it is not acceptable practice. MS Word "Mail Merge" would be better, but separating out the procedure from the document management would be better. I outlined a model, and even gave a demonstration (with the limited capabilities I have on my machine), but going further wasn't possible, I didn't have the tools. Management couldn't get over their prejudices that this type of solution means you buy an entire, close ecosystem package. Specs, SOPS would be automatically generated, always correct. The solution being given, is suboptimal (and don't you dare say the people implementing it know better, they barely know anything outside of MS Office and had no real knowledge of digital signatures). We have problems with fake "digital signatures", which lead to compliance issues. (a typed name is not a signature). There is no way to link one document to use data from another which isn't fragile. In fact, the site I'm working as is glad we're not implementing it, because we see that it's going to be an expensive cumbersome boondoggle. They usually are. These individual problems are not that difficult, but the desktop computing paradigm we have is to have a system which lacks the ability to compose our own solutions. --- Mystic BBS v1.12 A47 2021/12/24 (Linux/64) * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101) .