Subj : Re: Old computer
To   : TALIADON
From : boraxman
Date : Fri Jul 01 2022 23:26:09

 TA> Standards & adherence is indeed a cooperative rather than pre-emptive
 TA> relationship, but standards are the only way to reliably factor scale
 TA> into multi-domain projects. Back in the day when layouts/designs started
 TA> to employ IC units smaller than our lithographic wavelength, we often
 TA> employed Unix/Solaris boxes in order to develop bespoke OPC/Phase-Shift
 TA> geometry processors - it was near impossible to do this manually once
 TA> the geometry had been separated out for masking. As we were never quite
 TA> sure where this processing would need to take place - some designs would
 TA> require post-process input from various disciplines - it had to be
 TA> designed in such a way that it was portable across the entire
 TA> organisation. As the operating environment was already standardised via
 TA> x11, a language (POSIX C) & toolkit (Motif) standard were enough to get
 TA> the job done successfully. But these were simpler times, when all of the
 TA> program logic/data was designed from scratch and complex
 TA> OS/inter-application transactions were not an end-user expectation.
 TA> Today, desktop functionality has become synonymous with the end-user
 TA> experience, where components and features are expected to interact
 TA> seamlessly and without fuss. In turn, even bespoke applications are now
 TA> built using standardised paradigms, and commercial developers expect
 TA> their target OS/Framework/APIs to handle these standards as par for the co
 TA> 
 TA> Sadly, as of today, desktop Linux is far from being able to provide the
 TA> cohesive GUI/Core integration that developers have come to expect from
 TA> the likes of Apple, Google, and M$ - even Qt struggles to traverse the
 TA> minefield that is the Linux desktop (Gnome, KDE, Cinnamon, Xfce;
 TA> Wayland, x11, etc). Ironically, Unix/Linux encompasses many standards
 TA> under the hood, but for some unknown reason the GUI fraternity decided
 TA> to take an entirely different path altogether - each providing the
 TA> developer with more headaches than solutions. It's not all bad news,
 TA> however, as many Linux developers have now begun standardising their
 TA> apps around the Ubuntu core/desktop, with a "mileage may vary" caveat
 TA> for all other platforms. IMHO, herein lays the salvation of the Linux
 TA> desktop: if developers pick a side, then both standards and users will
 TA> eventually follow, not to mention the closed-source developers who
 TA> abandoned Linux when 20+ years of desktop development failed to
 TA> establish any semblance of synergy. Of course, if the Linux community
 TA> wants to remain an open-source arena where hobby projects can be
 TA> recompiled against the user's chosen distro, then I'm happy for it to
 TA> remain so, but it must also resign itself to a perpetual existence of
 TA> "alternatives" and workarounds.
 TA> 
 TA> Imagine a world where mathematics hadn't been standardised through
 TA> number, algebra, geometry, and calculus - a world where every generation
 TA> must stagnate whilst they reinvent the concept of quantity and magnitude
 TA> all over again. IMHO, this is where the Linux desktop finds itself today.
 TA> 

Standards go beyond those ratified by documents, such as ISO standards or RFC, but also incorporate social expectations and practices.  The value of a standards is interoperability.  A standard language in mathematics exists to allow one to communicate with another.  The standards for e-mail operation are not necessarily for e-mail, as Google could create their own protocol, proprietary and hidden, but they allow people to implement their own serves and clients, and for all these to inter-operate.

If you step back, the key here is inter-operability.  Having data stored in known formats, known standards, allows programs to share data between them.  The standards though should exist to serve the user as much as the developer. While we may make things easier for developers of graphical environments, developers seem quite self-centered in thinking their own needs trump all.  For me, the problem is, how can a user use data they've stored in a spreadsheet, and have it available from another application, or script?  The data we have tabulated in Excel, how can we insert that into a formatted document?
 TA> I think this is more a GUI vs CLI issue than a M$ or Windows thing per
 TA> se. Generally speaking, most tasks are better suited to either one or
 TA> the other; I can't really blame Screwfix if I chose to purchase a
 TA> Phillips screwdriver to tighten a flathead screw.
 TA> 

My point was more that a lot of importance is placed on standardised GUI appearance, especially for Linux, but it doesn't exist, not even in Windows.  It is perhaps not as important as people thing.  The fact that one program may look different to another is not a big deal.  The fact they can't readily stitch them together is.

 TA> Perhaps I'm reading this wrong, but this comes across as more of a
 TA> broader world view than any specific criticism of Ford. I suppose it
 TA> depends upon which world we feel more comfortable in: one where a
 TA> replacement alternator can be purchased off the shelf, or one where we
 TA> have to go in search of like-minded people who happened to design their
 TA> charabanc around a compatible specification. TBH, this really is the
 TA> same paradigm, but at disparate scales.

You are correct, but it is not about repairs but how we solve problems.  Ford solved a problem by producing a product that can be purchased, but the product was not the best solution to all the problems for which it was applied.  Cars are not the best solution for transit in a city, but because that is what was on offer (and pushed heavily), cities changes to accomodate the car, and were designed around that.  Likewise, we use hardware to store and compute and manage data, and what was put on offer to do this, was discreet software packages, designed as suites, self-contained solutions.  Just like how the car was a solution in and of itself, independent, each software package was the same.  A total solution in and of itself which had no relationship to the computing ecosystem it was installed in.

Car manufacturers are not going to think about urban design which is based on some other paradigm which doesn't involve selling their product, just as software companies don't think about solving computing problems based on other paradigms which don't involve selling their product.  The Free Software model, because of its different mode of production, leverages existing tools more than proprietary software does.  Software is created more in mind of it being part of a large ecosystem it cooperates with, rather than a be-all solution against competitors.  

 TA> Perhaps we're back to the Screwfix analogy I used earlier: is M$ the real
 TA> problem here, or the choices made by those who employ their
 TA> products/services? M$, Apple, and Linux, all have back-end automation
 TA> tools capable of solving this task.
 TA> 

Unix is built upon tools which are the building blocks for larger more complex solutions.  Automation exists in Windows, though far limited, and in the Apple world, the only one worth a damn, is the BSD base.  Microsoft were doing what you would expect a company to do, but because they dominated the PC world, everyone was used to buying a computer which couldn't be made to do anything unless you purchased other packaged software.

 TA> Agreed. This is a trend that should concern many people, but it also
 TA> represents the only way software companies can truly protect their
 TA> investment in the 21st century. In direct response to the threat created
 TA> by the warez/piracy scene, these companies have finally found a way to
 TA> get users to pay for their product time and time again. TBH, the lease
 TA> paradigm is nothing new in the corporate arena, but it looks like many
 TA> developers are now adopting this approach across the board. Adobe is one
 TA> that springs immediately to mind. 
This is a fundamental problem of "for profit" software development, and why computing is held back when software development is done just "for profit".  The user doesn't have this problem, how a company can make money, but is hobbled because of someone elses need.

Now think of how things could be, if people could share not just software and scripts, but techniques, "how to's", formula's, etc.  IT professionals working for companies wouldn't just be figuring out what software to install, but how to apply these techniques, using base tools, to create workflows and working environments.  People would understand how things work, for instance, how the documents generated are saved in the filesystem, how the parsing of CSV data works, etc, etc.
 TA> Again, M$, Apple, and Linux, all have generalised back-end technologies
 TA> for solving specific problems, and all are ultimately destined to become
 TA> the constituent part of a solution or "app". Linux itself, or the
 TA> functionality that most people associate with Linux, is in and of itself
 TA> a collection of apps moderated by the Linux kernel.
 TA> 
 TA> Unfortunately, you find yourself in the unenviable situation where your
 TA> employer has given you a wrench in lieu of a hammer.
 TA> 

Unix is a little different in that it contains user tools for managing and processing data, which can be composed to create more complex solutions.  MS is just a blank slate that can't do anything.  I'm not saying that Unix is the best example, but it does something important, give the owner of the computer immediate means to construct solutions.  Basic functionality is exposed to the user (think of the OS as an API, cut, sed, awk, tr being functions), which can interface with a CLI, or even a GUI window.  This doesn't replace all applications obviously, but can fill the gaps inbetween, the gap between say, generating a .DOCX and a PDF version, or pulling data from a CSV and generating a report or document, or a simple database query, or to add data to an existing file, etc.

The way things work now, you open an application to edit data, then close the application.  If you want to add a row of data, you open the application responsible, add the line, save, close.  To get data, again, open the app, use that apps functionality to get the data.  To put that data elsewhere, that is your responsibility.  But for corporate use, the OS's desktop itself should be able to offer this common functionality.  A widget or shortcut which brings up a dialog which shortcuts straight to the task being performed.  A quick form which takes input and adds it correctly formatted to whatever file stores that data.  Meta programs/widgets which use different apps and programs in concert to go all the way from initial input to the final output. Not having the user have to manually process the data all the way through.

--- Mystic BBS v1.12 A47 2021/12/24 (Linux/64)
 * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

.