On 4/28/2022 7:27 AM, rbowman wrote:

>> So, you're using the browser to give you the functionality of an "X
>> Terminal"?
>> But, you're still letting that build on a COTS OS (e.g., windows)? Does
>> the
>> user *need* the "generic PC" to be present IN ADDITION to the browser?
>> I.e.,
>> why not replace the OS and browser and make a dedicated appliance (with
>> deliberately limited functionality)?''
>
> Yes, you need a generic something with a browser. Windows XX, Chromebook, Apple
> Tablet, Android Tablet, Linux box, whatever else you can find... Particularly
> with Apple if they have the tablet, they're good to go. We did an app a few
> years ago. Android, sideload the apk. Apple, go through the whole Apple Store
> vetting hoops even for a proprietary app that couldn't even be used by the
> general public.

But, then you're also opening the door for <whatever> to coexist with "you"
on the device (?). How much grief does that cause your support staff as
they end up having to troubleshoot "unrelated" problems caused by some
crud Joe User opted to install on his box?

We're developing a STEM program for local schools. Part of it is to
provide a "development platform" to the students enrolled. The obvious
solution is just to give them a laptop.

But, then you're stuck dealing with all the cruft that will inevitably get
ADDED to the laptop as the student (or, someone else in the household
eyeing the laptop as something THEY could make use of) leverages your
"gift". Likewise, when they want to go online (malware).

So, we're locking down the BIOS so it won't run COTS OS's, just our own.
I.e., it becomes a dedicated "teaching appliance" instead of a ubiquitous
laptop. (as we're operating under a grant, we can't afford a big support
staff like you might in a general educational setting; we want the grant
monies to go towards "buying" extra seats, not extra *staff*!)

[There are some tools -- free and otherwise -- that will let you lock down
a box against persistent changes. But, that still lets the box be used
for other purposes, if only transiently (if they are willing to not reboot
for days/weeks, then the change is effectively permanent... and now a
support problem!)]

> A dedicated appliance would be a tough sell. They understand 'buy a Panasonic
> Toughbook'. It's the old 'nobody ever got fired for buying IBM'. Well, they
> may have. Historically our desktop suite ran on RS6000 boxes with AIX. Then the
> bean counters noticed you could but Windows boxes a lot cheaper so we ported
> everything to Windows.

But, can you have a list of "qualified" machines? Or, does that cut down
your value-added? Perhaps even preparing a set of install images that
you just dd(1) onto "select" machines (turn-key install)?

>> If "local", then the trip to the server isn't as costly. So, why not move
>> everything into the server (eliminating script altogether)? Or, does that
>> solution not scale adequately (i.e., you're relying on the clients to
>> effectively share some of the computational load)?
>
> It wouldn't scale too well. We went that route a long time ago and it had
> issues. Connectivity is also a factor for mobile users. It isn't great but you
> have some usability if the network goes down or if the user goes out of cell
> coverage.

I've been addressing server-side scale with support to seamlessly add
processors. As everything is inherently distributed, talking to another
server-side processor is just as cheap as if talking to another "smart
client" (the "smart" part residing server-side).

Wireless bandwidth is my shortcoming (as users will typically not be
sited at wired devices)

>>> If you've looked in a police car, fire truck, or ambulance lately they
>>> are fully wired. Have to physically update a couple of hundred mobile
>>> laptops is a problem. Even updating desktops in the dispatch center
>>> can be tricky. You try to pick a quiet time to take stations offline
>>> one by one and hope there isn't a mass casualty incident.
>>
>> But you're NOT updating those things, right? That's the whole point of
>> pushing script into the clients "on demand"...
>
> Right. That's the incentive to go browser based rather than our legacy software.

How do you address the Principle of Least Surprise when the possibility
exists that a user may encounter a radically different "application",
next time he "logs on"? Have you codified the types of changes that
you will allow yourself to make/deploy to avoid this?

[I'm sure everyone has dealt with a site that has "suddenly" -- from their
personal perspective -- changed in ways that make using it, NOW, difficult
(even if it is a long-term improvement)]

This is the number one complain I see with push updates. (Imagine your CAR
behaving differently, today, than it did, yesterday! Surely you wouldn't
allow such changes to an airframe! Safety is important, there -- not so
much with cars, eh? :> )

>> Instead of something truly minimalist (like a Sun Ray), you're relying
>> on the browser to give you "advanced primitives" that you can invoke,
>> via script?
>
> Yes, although we're working at a higher level of abstraction. With Angular
> you're creating the UI with the assumption something will make it happen.

OK. That's similar to my UI; apps indicate what the UI should be and the
actual *device* figures out how to "render" that to the user. E.g., a
blind user wouldn't benefit from a graphic presentation; nor would a deaf
user benefit from an audible commentary!

[And the last thing you want to do is force the app to decide on the
presentation as they'll just concentrate on the modalities with which
they are most familiar, at the expense of users who can't effectively
use them!]

>> But, by doing so, you are now at the mercy of the browser(s) that you
>> want (?) to support.
>
> Yes. We test on most of the popular browsers but, as this thread started, we do
> find bugs that need to be addressed because Browser X has quirks. In our
> experience X == Firefox. Because of the inclusion of tablets etc, there are
> further problems for rendering and layout.

But the tablet/form-factor issue is unrelated to the browser. You'd still
have to accommodate that size/formfactor regardless of browser.

Or, disallow those platforms.

>>>> Is this just another repeat of the centralized/distributed cycle
>>>> (mainframe->workstations->server/clients-> ...)
>>>
>>> Most certainly. IBM's revenge. Money is always an issue and with a
>>> thin client you don't have to go overboard on the computer and can put
>>> the money into big 4K monitors.
>>
>> Yeah, I fully embraced the thin client ideology many years ago. It made
>> maintenance SO much easier! (By contrast, my workstations incur LOTS of
>> maintenance). My current project relies completely on a bare bones
>> client -- more like the Sun Rays than a browser or even an X Terminal
>> (so, NEVER a need to update the client!)
>
> Left to my own devices we'd still be using ADM-3A's... My first exposure to
> Windows was 'this is going to suck sooner or later'

I think any bit of code on which the UI relies has that "problem".
How often do you recall firmware updates for glass TTYs?

This is the thinking behind my "minimalist" i/f; so I can make those
devices dirt cheap (the most commonly used one will retail for < $10)
so you don't care if they "walk off". And, so a user can afford to
buy many "spares" to address battery charge (if battery dies after
12 hours of use, place on charger and pick up another FRESH unit
for the next 12 hours!)

>>> Not our system but scroll down a little and that's a typical dispatch
>>> center. Those people love their monitors. The more the merrier.
>>
>> Yeah, it's addictive. I run 5-6Kx2K on my workstations. The limit
>> being how
>> much I can take in with my eyes WITHOUT moving my head (the "tennis match"
>> syndrome gets old, quick!)
>
> I'm old school. I run multiple virtual desktops on one monitor. Our IT guy
> keeps asking if I want another monitor and I take a pass. I was a very happy
> camper when MS finally figured out how to do desktops.

I have two workspaces (desktops) on each workstation. But, you (I) still need
real estate.

If I'm laying out a PCB, then I want to see the layout, the schematic, possibly
a datasheet (or two) AND some notes. Stacking windows is a PITA -- as is
swapping desktops.

If I'm building a 3D model, then I'll want to see the wireframe AND the
rendered model. And, maybe watch an animation built on it.

Etc.

I use the second desktop for consoles to other devices -- "System Management".
E.g., if I have to mount a volume on a NAS, I'll open a console/webpage into
that device on the "Alternate" desktop to interact with it, then flip back to
the "Primary" desktop to continue whatever I was originally doing. It's
a convenient distinction to keep in mind... instead of having to remember
which *app* is where.

Single monitor machines (e.g., my AiO's) tend to have specific roles... more
like appliances than general workstations.

[I think back to the 14", 16 color monitor I started with and shudder! :>
Amusing to see how easily we can be "corrupted"! ]