Subj : Old computer To : boraxman From : TALIADON Date : Sat Jul 02 2022 14:39:38 bo> Standards go beyond those ratified by documents, such as ISO standards or bo> RFC, but also incorporate social expectations and practices. Unfortunately, this simply isn't the case in the 21st century. Standards and "accepted/subjective practices" are diametrically opposed in almost every way imaginable; the days of corporate developers picking their preferred tools and "doing it their way" are long gone. This is precisely the way it was back in my day - engineers often made themselves "indispensable" by using techniques/methods that only they were familiar with - and corporations are unlikely to make the same mistake again. From a corporate perspective, employees are no different from any other kind of asset, and thus should be transparently replaceable once they become a liability. Of course, rather than playing the "irresistible force" to their "immovable object", creating your own business/product is a sure way of avoiding this scenario altogether. bo> The value of a standards is interoperability. You'll find no argument from me :) bo> A standard language in mathematics exists to allow one to communicate bo> with another. Agreed, but it's much more than that. Standard methodology allows us to employ proofs without the need for persistent verification. Once an engineer has satisfied themselves with a particular proof, it may be subsequently employed in a natural, almost casual, fashion - variables may be shuffled about in an agreed manner, safe in the knowledge that it can be relied upon today, tomorrow, or the next time it's pertinent to do so. Standards, or empirical correctness in this particular case, permits the engineer to learn once, use many, and focus their concerns on more immediate tasks - engineers and physicists are not mathematicians per se, and standards allow us to leverage knowledge from disciplines that are often opaque in nature. To put it another way, standards allow disparate fields to work together more effectively - I always viewed algebra & calculus as the API that allowed me to interface with the mathematicians and physicists who also played a crucial role in my industry. Nonetheless, as you say, it's essentially a means of efficient communication. bo> The standards for e-mail operation are not necessarily for e-mail, as bo> Google could create their own protocol, proprietary and hidden, but they bo> allow people to implement their own serves and clients, and for all these bo> to inter-operate. Sure, user-centric companies like Google also appreciate the value of standards. bo> If you step back, the key here is inter-operability. Having data stored bo> in known formats, known standards, allows programs to share data between bo> them. The standards though should exist to serve the user as much as the bo> developer. While we may make things easier for developers of graphical bo> environments, developers seem quite self-centered in thinking their own bo> needs trump all. I can't really comment as to the selfishness of programmers today, but software development is certainly a more complex arena than it was in my day: we already used Verilog/VHDL for chip layout, and microcode/asm for chip/firmware, so a procedural language like C presented itself as a natural choice for tool development. TBH, if I was starting out as a software developer today, I really wouldn't know where to start, but one thing's for sure, whichever road you travel you're going to be lumbered with abstract data types, object models, and a ton of third-party code/libraries you didn't write yourself. If ever there was a paradigm that lends itself to over-engineering it's OOP; OOP programmers spend more time making their code programmer-proof than user-proof these days. For sure, it's a quagmire out there, and I have the utmost respect for anyone who dares venture across it. bo> For me, the problem is, how can a user use data they've stored in a bo> spreadsheet, and have it available from another application, or script? bo> The data we have tabulated in Excel, how can we insert that into a bo> formatted document? If we're talking about Excel or M$ products specifically, then all I can say is that M$ has one of the most integrated server/development/deployment stacks I've ever seen: cross-application scripting for user automation, and full multi-language Visual Studio integration for the in-house development team. That said, however, if all you have is a basic windows/office deployment and little or no in-house development, then you're never going to see the magic M$ developers can pull off in a couple of hours - things that would have taken months back in my day. bo> My point was more that a lot of importance is placed on standardised GUI bo> appearance, especially for Linux, but it doesn't exist, not even in bo> Windows. It is perhaps not as important as people thing. The fact that bo> one program may look different to another is not a big deal. The fact bo> they can't readily stitch them together is. As you stipulated earlier, the user's needs should always take precedence over those of the programmer - this used to be the job of an "analyst" back in my day - and the desktop experience really does matter to a large majority of users. If this wasn't the case, then Linux itself wouldn't have such a diverse offering. IMO, standards, or lack thereof, across the Linux desktop is more of a functional issue than an aesthetic inconvenience: commercial developers are simply not willing to rewrite large portions of their code every time Gnome/KDE reinvent the concept of the desktop. Many closed-source developers left the Linux scene when Gnome 2 disappeared as the de facto desktop model, and most are unlikely to return en masse until there's some kind of synergy. To push the point a little further, the majority of x11 apps, many written decades ago, can still be compiled/run on Linux without modification. x11 was standardised a long time ago, and these standards can still be relied upon today. Even Win32 apps written two decades ago - a binary standard M$ maintains to this day - can still be run on the current Windows desktop without any recompilation at all. As you say, they look a little different to the newer ..net apps (as do x11 apps on Linux), but they still work nonetheless. I have no problem with the Linux desktop as it is - I'm currently writing this on a Ubuntu machine - but there would certainly be some advantages to enticing a few of the closed-source developers back into the fold. bo> You are correct, but it is not about repairs but how we solve problems. bo> Ford solved a problem by producing a product that can be purchased, but bo> the product was not the best solution to all the problems for which it bo> was applied. Cars are not the best solution for transit in a city, but bo> because that is what was on offer (and pushed heavily), cities changes to bo> accomodate the car, and were designed around that. Likewise, we use bo> hardware to store and compute and manage data, and what was put on offer bo> to do this, was discreet software packages, designed as suites, bo> self-contained solutions. Just like how the car was a solution in and of bo> itself, independent, each software package was the same. A total solution bo> in and of itself which had no relationship to the computing ecosystem it bo> was installed in. bo> Car manufacturers are not going to think about urban design which is bo> based on some other paradigm which doesn't involve selling their product, bo> just as software companies don't think about solving computing problems bo> based on other paradigms which don't involve selling their product. The bo> Free Software model, because of its different mode of production, bo> leverages existing tools more than proprietary software does. Software bo> is created more in mind of it being part of a large ecosystem it bo> cooperates with, rather than a be-all solution against competitors. Agreed. There is no single solution that encompasses every problem, but that's why Ford produce cars/vans/trucks/etc, and why M$ sell both off-the-shelf packages and integrated server/client/development solutions. Again, if your only experience of M$ is a basic windows/office deployment and no in-house development, then a lot of the magic is going to be lost. If we're talking about passing data between M$ systems specifically, then the M$ developer stack is always going to be the quickest/best option, IMHO. Don't get me wrong: if I needed to develop a quick app, then I'd probably choose Linux and POSIX C - not because it's the best tool for the job, but because it's what I know. bo> Unix is built upon tools which are the building blocks for larger more bo> complex solutions. Automation exists in Windows, though far limited, and bo> in the Apple world, the only one worth a damn, is the BSD base. bo> Microsoft were doing what you would expect a company to do, but because bo> they dominated the PC world, everyone was used to buying a computer which bo> couldn't be made to do anything unless you purchased other packaged bo> software. This is a fundamental problem of "for profit" software bo> development, and why computing is held back when software development is bo> done just "for profit". The user doesn't have this problem, how a company bo> can make money, but is hobbled because of someone elses need. bo> Now think of how things could be, if people could share not just software bo> and scripts, but techniques, "how to's", formula's, etc. IT bo> professionals working for companies wouldn't just be figuring out what bo> software to install, but how to apply these techniques, using base tools, bo> to create workflows and working environments. People would understand bo> how things work, for instance, how the documents generated are saved in bo> the filesystem, how the parsing of CSV data works, etc, etc. bo> Unix is a little different in that it contains user tools for managing bo> and processing data, which can be composed to create more complex bo> solutions. MS is just a blank slate that can't do anything. I'm not bo> saying that Unix is the best example, but it does something important, bo> give the owner of the computer immediate means to construct solutions. bo> Basic functionality is exposed to the user (think of the OS as an API, bo> cut, sed, awk, tr being functions), which can interface with a CLI, or bo> even a GUI window. This doesn't replace all applications obviously, but bo> can fill the gaps inbetween, the gap between say, generating a .DOCX and bo> a PDF version, or pulling data from a CSV and generating a report or bo> document, or a simple database query, or to add data to an existing file, bo> etc. bo> The way things work now, you open an application to edit data, then close bo> the application. If you want to add a row of data, you open the bo> application responsible, add the line, save, close. To get data, again, bo> open the app, use that apps functionality to get the data. To put that bo> data elsewhere, that is your responsibility. But for corporate use, the bo> OS's desktop itself should be able to offer this common functionality. A bo> widget or shortcut which brings up a dialog which shortcuts straight to bo> the task being performed. A quick form which takes input and adds it bo> correctly formatted to whatever file stores that data. Meta bo> programs/widgets which use different apps and programs in concert to go bo> all the way from initial input to the final output. Not having the user bo> have to manually process the data all the way through. As far as Apple are concerned, I stand by my previous statement: Apple took BSD and turned it into the only commercially viable "Linux" desktop available today. It has the solid back-end we've come to expect from Linux, and so it's capable of much the same thing. As for M$, I think you have to see the full stack in action to truly appreciate how good their technology is - if you're encumbered with the basic packages then other avenues are likely to present themselves as more amenable solutions. TBH chap, I don't really think our opinions are as disparate as they may at first appear. Without real investment (staff and appliances), M$ will always struggle to provide the versatility many companies require - money and investment is the M$ business model after all. Linux, on the other hand, is a free and proven technology that provides a solid back-end that's accessible to users, tinkerers, and developers alike. As I'm sure you're aware by now, my only real gripe is the Linux desktop model :) ================================================================== TALIADON (Lee Westlake) | TALIADON BBS (taliadon.ddns.net:23) FidoNet: 2:250/6 | fsxNet: 21:3/138 | Email: taliadon-bbs@mail.com ================================================================== --- Mystic BBS v1.12 A47 2021/12/24 (Linux/64) * Origin: TALIADON BBS (21:3/138) .