Forget all my rants about SeaMonkey. I just deleted it.

I found I have another email client that handles HTML. It is Opera Mail V1.0
and is on another VirtualBox operating system. It works very well and is easy
to use.

I love VirtualBox. I simply could not survive without it.

--
MRM

On a sunny day (Wed, 27 Apr 2022 05:03:40 -0000 (UTC)) it happened Mike Monett
<spamme@not.com> wrote in <XnsAE86ACBC856Didtokenpost@144.76.35.252>:

>Seamonkey may share some source with Thunderbird, but the browser wrecks
>Canadian Tire in a completely different way.
>
>It also does not seem to be able to use Firefox extensions, such as
>AdBlock Plus

FYI
I have been running adblock plus for 10 years or more on seamonkey
its a great browser, but no raspi version yet I know about.

Audio Equalizer,

Wrote my own audio equalizer:
http://panteltje.com/panteltje/xpequ/index.html
standalone no need for browsers

I Don't Care About Cookies, and Javascript
>Toggle On And Off. The last one is especially useful to block logon
>requirements on many web pages. You just click on a small icon in the
>upper righ corner of the screen. The Seamonkey version is extremely
>cumbersome:
>
>"Edit -> Preferences -> Advanced -> Scripts & Plug-ins -> Enable
>JavaScript for -> Navigator"
>
>However, it may be blocked by NoScript
>
>SeaMonkey might as well be a completely different browser.
>
>I actually never use SeaMonkey for browsing. I only need it when receiving
>an email that I must respond to that uses HTML. My regular email client is
>Pimmy 3.5, which is plain ASCII text only. It does not understand HTML,
>and is immune to <IFRAME> attacks.

fetchmail here to get email, been using it since 1998
together with pine to read it.

>It also handles an unlimited number of email addresses, which I use to
>eliminate spam. If a site begins sending me spam, I merely delete it from
>my list of email addresses. You can generate your own list at
>
>http://www.e4ward.com/
>
>I rarely get spam anymore. I once wrote my own spam filtering program
>using Bayesian filtering, but it was simply too much work to keep up with
>changes in spam messages and new techniques. The combination of Pimmy and
>e4ward is much simpler and permanent.

I like 'spam' or rather advertizing, shows my system is still working
I have near unlimited email addresses...
I assign every company its own, so if 'spam' comes in I know who it was
and either unlist or warn them they have been hacked.

It is good in tracking the bad guys too as recently shown.

All my editing and coding is done with 'joe' text editor.

An this is posted with NewsFleX ported to and running on a Raspberry4 8 GB.
Written the code so full control :-)
http://panteltje.com/panteltje/xpequ/index.html
Do any of you guys ever publish any code>?

Chromium works OK on this very small computah too.

On a sunny day (Tue, 26 Apr 2022 14:09:25 -0700) it happened Don Y
<blockedofcourse@foo.invalid> wrote in <t49n2e$9p3$1@dont-email.me>:

>The bigger "threat" is the recognition that more folks consume content
>using phones (tiny screens, piss poor user entry). It won't be long
>before we find pages that really only make sense in a phone's aspect
>ratio! (there is some skill required to build pages that can be equally
>accessible in a wide range of form factors, etc.)

I dunno, I prefer the phone format as info in text form is mostly all you need.
examples:
https://www.ard-text.de/mobil/101
for the news in (German)
or
https://www.tvguide.co.uk/mobile/channellisting.asp?ch=1243#582517827
for Smithsonian program listing for TV

You can always use ctlr + or ctrl - or ctrl 0 in your browser to enlarge it etc
a decent browser will remember the enlargement settings for each site/.

No ads.
Basic HTML.
I build my own website with basic HTML:
panteltje.com
No advertising and no java.

That stuff is not normally needed, one can always make a youtube video
if more info is needed.
Interactive? Download and compile my code :-)

Have a local copy of the site running on Apache server,
I test new entries locally first, then it goes to the site.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Jan Panteltje wrote:
> [...]
> Do any of you guys ever publish any code>?

Every once in a while, when I write something that someone might find
useful (or fun...). Granted I've been moving away from github to a
self-hosted gitlab in the last year or two ...

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE3asj+xn6fYUcweBnbWVw5UznKGAFAmJpEIAACgkQbWVw5Uzn
KGAH1A/+OcidBwxRvOZf7HnNwn6iUEbijSKCK5igaxI4XIex/K+8UZJzHOHxM9bO
LkSujMIw1oeZVXvypDD/N2LvGCk4szRu9NHn10NuhPKOR2kZq4me12H91gBH3VKg
Y9h1oTvE2uzCPnB4O0vkfxiLGJhFBj28baVGHTfhWXSdk8B7J6zAecd+csigygqG
nQ/6l3J//HANqtCQPVqxYLal9altplMoj8z1LHUqG+GXmY6gGFR6a7aLar0pM2Of
zihVBfjYDEgzfPJ+VH0EQwKEEAtLQ6MekxV196jPyVzNSscC5hsMzHAE2ykwgilK
TvZpcmicrZLcLm4Y0cEMGbDz3wJWxjkH70aweB07acmmcxrUASn9Q/g3JtgbBm5w
CYeFUpa3vrYPbeFPD+8SxA/KIgvn6d2/o7Wi2/T75/YKzco0z4nQM9sJkJBDzx2g
mz9Pyqemrk2sq0MFk/rdvZIyTbe4mgGpgIbckFtie5tocR8HaV+IiQdIRwoM1UnP
9bp8VRlItTsZqFb4KcktEtzSleewVSlJokk88tEP6ExXSEXRs1I2LUUV3sqEML4h
gq82OvabLh4TEbY6shvQ9nF/8A6aUjDa7Hb9WWZXVwhD5JjDL1E4ex+kbDoaN6q9
yzUjJNaLNfE/YiTz4izD/oAmhO8sUghNYbQxwzU9/qlD+p5efe4=
=KJU6
-----END PGP SIGNATURE-----

--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860

On 04/26/2022 11:03 PM, Mike Monett wrote:
> Seamonkey may share some source with Thunderbird, but the browser wrecks
> Canadian Tire in a completely different way.

There's always room for creativity. Dealing with browsers is like
playing whack-a-mole. A long discussion during our
Monday meeting concerned cut'n'paste and the relationship between the
browser and the Windows clipboard. FF is different to the chromium based
browsers, so how to fix a FF bug without creating a further cascade of
bugs? It's never the big things just ongoing annoyances.

We're developing a product that has to be presentable. Canadian Tire is
selling tools and tires, not a web application so they can be a little
more cavalier. Their customers grumble a little and use another browser.
Ours grumble a lot and refuse to switch. In one case it was because
another application didn't work except with xxxxx browser.

On 04/26/2022 09:59 PM, Don Y wrote:
> n 4/26/2022 8:05 PM, rbowman wrote:
>> On 04/26/2022 03:09 PM, Don Y wrote:
>>> The bigger "threat" is the recognition that more folks consume content
>>> using phones (tiny screens, piss poor user entry). It won't be long
>>> before we find pages that really only make sense in a phone's aspect
>>> ratio! (there is some skill required to build pages that can be equally
>>> accessible in a wide range of form factors, etc.)
>>
>> Even 7" tablets are a challenge.
>
> Long ago, I made the decision that I wanted control over presentation
> instead of flexibility in presentation. This imposes on the viewer/user
> to have a suitable "presentation device". But, makes MY job *so* much
> easier. I can concentrate on what I want to say/show instead of having
> to anticipate how many different "compromises" will be imposed in the
> rendering.

I can only dream about being able to do that.

On 2022-04-27 16:23, rbowman wrote:
> On 04/26/2022 11:03 PM, Mike Monett wrote:
>> Seamonkey may share some source with Thunderbird, but the browser
>> wrecks Canadian Tire in a completely different way.
>
> There's always room for creativity. Dealing with browsers is like
> playing whack-a-mole. [...]

Come on, it isn't that hard to make something that works in any
browser. Of course, you have to avoid using all these snazzy
features that web development package writers are so fond of.
That shouldn't really be a problem, because most of those features
are irritating anyway. We don't need animations, we don't want
complete remakes of the user interface, we don't want JavaScript
where straight HTML will do. Simple is best.

Jeroen (I hate spinners) Belleman

On 4/27/2022 7:49 AM, Jeroen Belleman wrote:
> On 2022-04-27 16:23, rbowman wrote:
>> On 04/26/2022 11:03 PM, Mike Monett wrote:
>>> Seamonkey may share some source with Thunderbird, but the browser
>>> wrecks Canadian Tire in a completely different way.
>>
>> There's always room for creativity. Dealing with browsers is like
>> playing whack-a-mole. [...]
>
> Come on, it isn't that hard to make something that works in any
> browser. Of course, you have to avoid using all these snazzy
> features that web development package writers are so fond of.
> That shouldn't really be a problem, because most of those features
> are irritating anyway. We don't need animations, we don't want
> complete remakes of the user interface, we don't want JavaScript
> where straight HTML will do. Simple is best.

"Everything should be made as simple as possible, but not simpler."

The problem is when "simplest" exceeds the capabilities of "straight HTML".

You don't want to have to take a round-trip to the server each time a user
changes a field/control on a page/form. So, you push that logic to the
client side -- script. It's nice to be able to do an INTERACTIVE
search on Digikey's site -- instead of having to make selections and
take another trip to the server to see how those selections affect your
NEW choices. (I suspect you'd quickly tire of having to RESUBMIT each time
you were unhappy with the choices left to you from some previous choice made)

The problem is that applications are trying to use the browser FOR the UI.
And, in order to get the responsiveness that users expect/demand/require,
that means doing local, client-side processing.

Sadly, the automatic code generators seem to create lots of cruft just
to get some "basic functionality" in place. (and, you wouldn't want to
pay someone to hand-craft these sorts of VERY VISIBLE interfaces)

On 4/27/2022 7:26 AM, rbowman wrote:
> On 04/26/2022 09:59 PM, Don Y wrote:
>> n 4/26/2022 8:05 PM, rbowman wrote:
>>> On 04/26/2022 03:09 PM, Don Y wrote:
>>>> The bigger "threat" is the recognition that more folks consume content
>>>> using phones (tiny screens, piss poor user entry). It won't be long
>>>> before we find pages that really only make sense in a phone's aspect
>>>> ratio! (there is some skill required to build pages that can be equally
>>>> accessible in a wide range of form factors, etc.)
>>>
>>> Even 7" tablets are a challenge.
>>
>> Long ago, I made the decision that I wanted control over presentation
>> instead of flexibility in presentation. This imposes on the viewer/user
>> to have a suitable "presentation device". But, makes MY job *so* much
>> easier. I can concentrate on what I want to say/show instead of having
>> to anticipate how many different "compromises" will be imposed in the
>> rendering.
>
> I can only dream about being able to do that.

Your current dream is likely a nightmare! :>

My goal is to convey information to the reader/viewer. As much information
as possible in as expressive a form as possible. Note that I'm creating
references, not transient "interactions".

I figure the reader should be willing to make an effort to *consume* that
information. If he wants to be lazy and opt for some ineffective mechanism,
then HE should bear the cost of that poor choice.

Good luck reading that schematic on your iPhone! Or, perusing that long,
multicolumn table. :>

On 04/27/2022 08:49 AM, Jeroen Belleman wrote:
> On 2022-04-27 16:23, rbowman wrote:
>> On 04/26/2022 11:03 PM, Mike Monett wrote:
>>> Seamonkey may share some source with Thunderbird, but the browser
>>> wrecks Canadian Tire in a completely different way.
>>
>> There's always room for creativity. Dealing with browsers is like
>> playing whack-a-mole. [...]
>
> Come on, it isn't that hard to make something that works in any
> browser. Of course, you have to avoid using all these snazzy
> features that web development package writers are so fond of.
> That shouldn't really be a problem, because most of those features
> are irritating anyway. We don't need animations, we don't want
> complete remakes of the user interface, we don't want JavaScript
> where straight HTML will do. Simple is best.
>
> Jeroen (I hate spinners) Belleman
>

All depends on what you're doing. If you're building a browser based
highly interactive computer aided dispatch system to parallel a legacy
desktop suite of applications you're not going to get there with static
html pages.

On 4/27/2022 8:10 PM, rbowman wrote:
> All depends on what you're doing. If you're building a browser based highly
> interactive computer aided dispatch system to parallel a legacy desktop suite
> of applications you're not going to get there with static html pages.

But what's the motivation for a browser-based solution?
Are you trying to have a "no install" application (which
makes it immediately available to EVERY seat)?
Or, streamline maintenance (server-side updates)?
Or...?

Is this just another repeat of the centralized/distributed cycle
(mainframe->workstations->server/clients-> ...)

On 04/27/2022 09:48 PM, Don Y wrote:
> On 4/27/2022 8:10 PM, rbowman wrote:
>> All depends on what you're doing. If you're building a browser based
>> highly interactive computer aided dispatch system to parallel a legacy
>> desktop suite of applications you're not going to get there with
>> static html pages.
>
> But what's the motivation for a browser-based solution?
> Are you trying to have a "no install" application (which
> makes it immediately available to EVERY seat)?
> Or, streamline maintenance (server-side updates)?
> Or...?'

All of the above... In the last few years I've been seeing a lot of
RFP's calling for zero footprint solutions. Some of that is justified
paranoia about hacking. They don't advertise but an embarrassing number
of sites have been pwned. Zero footprint means you can lock the
workstations down tight and not let the users wander off to watch cat
videos or whatever.

They've backed off the cloud based fad. AWS has dumped often enough to
take the shine off that. Losing Twitter for a couple of hours, no big
deal. Losing your emergency response dispatch system is something else.
Technically you're building a private cloud on premises and assuming the
costs of buying and maintaining HA servers. That is the selling point of
Azure/AWS etc -- let us worry about all that -- which is fine until it
isn't. The other problem with the cloud is sensitive information. There
are providers that offer secure installations with fully vetted
personnel but that adds cost.

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.

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

https://www.motorolasolutions.com/en_us/products/command-center-software/voice-and-computer-aided-dispatch.html

Not our system but scroll down a little and that's a typical dispatch
center. Those people love their monitors. The more the merrier.

Who knows what the next iteration will bring?

rbowman <bowman@montana.com> wrote:

> On 04/27/2022 08:49 AM, Jeroen Belleman wrote:
>> On 2022-04-27 16:23, rbowman wrote:
>>> On 04/26/2022 11:03 PM, Mike Monett wrote:
>>>> Seamonkey may share some source with Thunderbird, but the browser
>>>> wrecks Canadian Tire in a completely different way.
>>>
>>> There's always room for creativity. Dealing with browsers is like
>>> playing whack-a-mole. [...]
>>
>> Come on, it isn't that hard to make something that works in any
>> browser. Of course, you have to avoid using all these snazzy
>> features that web development package writers are so fond of.
>> That shouldn't really be a problem, because most of those features
>> are irritating anyway. We don't need animations, we don't want
>> complete remakes of the user interface, we don't want JavaScript
>> where straight HTML will do. Simple is best.
>>
>> Jeroen (I hate spinners) Belleman
>>
>
> All depends on what you're doing. If you're building a browser based
> highly interactive computer aided dispatch system to parallel a legacy
> desktop suite of applications you're not going to get there with static
> html pages.

What has that got to do with a simple parts ordering page?

RockAuto handles millions of parts with ordinary browsers:

https://www.rockauto.com/

Amazon handles millions of parts with ordinary browsers:

https://www.amazon.com

Instacart handles lots of items with ordinary browsers:

https://www.instacart.com

Youtube handles billions of videos with ordinary browsers:

https://www.youtube.com/

A huge part of business runs with ordinary browsers.

Why does Canadian Tire require one specific browser?

MRM

On 4/27/2022 10:28 PM, rbowman wrote:
> On 04/27/2022 09:48 PM, Don Y wrote:
>> On 4/27/2022 8:10 PM, rbowman wrote:
>
>> But what's the motivation for a browser-based solution?
>> Are you trying to have a "no install" application (which
>> makes it immediately available to EVERY seat)?
>> Or, streamline maintenance (server-side updates)?
>> Or...?'
>
> All of the above... In the last few years I've been seeing a lot of RFP's
> calling for zero footprint solutions. Some of that is justified paranoia about
> hacking. They don't advertise but an embarrassing number of sites have been
> pwned. Zero footprint means you can lock the workstations down tight and not
> let the users wander off to watch cat videos or whatever.

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

Or, do you want MS to deal with the "multiple vendor support" issues (so YOU
don't have to develop network and video drivers for an unlimited number of
potential hardware configurations)?

> They've backed off the cloud based fad. AWS has dumped often enough to take the

Hmmmm... that's an interesting observation (the whole "cloud" idea struck me
as seriously flawed)

> shine off that. Losing Twitter for a couple of hours, no big deal. Losing your
> emergency response dispatch system is something else. Technically you're
> building a private cloud on premises and assuming the costs of buying and
> maintaining HA servers.

So, do you deploy the server-side code on commodity hardware? Or, "certified"
(commodity) hardware -- so you have some control over that performance?

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

> That is the selling point of Azure/AWS etc -- let us
> worry about all that -- which is fine until it isn't. The other problem with
> the cloud is sensitive information. There are providers that offer secure
> installations with fully vetted personnel but that adds cost.

I assume you aren't deploying personnel to each site but, rather, doing remote
administration? Presumably, you've got that locked down tight so *you* aren't
the attack vector? (all traffic in an encrypted tunnel?)

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

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?

But, by doing so, you are now at the mercy of the browser(s) that you
want (?) to support.

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

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

> Who knows what the next iteration will bring?

Someone will invariably lament that the latency is too great for games (or
some other ENTERTAINMENT-related activity) and push to put more "programmable
features" in the UI.

Until that bloats to the point of a real workstation -- which will restart the
cycle....

Enough is never enough -- esp if you can rationalize someone ELSE paying for
it!

On 04/27/2022 11:32 PM, Mike Monett wrote:
> Why does Canadian Tire require one specific browser?

Simply put, because they don't care or the website was developed by
someone's cousin's kid. Looking at their page source they're not doing
anything fancy.

There might be a clue with the various references to apple. It may work
like a charm with Safari.

On Mon, 25 Apr 2022 23:24:50 -0600, rbowman <bowman@montana.com>
wrote:

>On 04/25/2022 11:01 PM, Mike Monett wrote:
>> Firefox is far superior to Chrome, Opera, SeaMonkey, or any other browser.
>> I have tried them all.
>
>Your experience differs from mine, at least for the last several years.
>I'm running Firefox 99.0.1 on my Linux box. At least it no longer locks
>the machine up but it crashes on a couple of websites I visit and at
>other odd times.
>
>It's been losing market share for several years. Mozilla made several
>bad decisions and hasn't been keeping up. Your problem with Canadian
>Tire is one symptom.
>
>It is better than Safari though. Even if you put FF on an Apple device
>it uses webkit.

Firefox, which started out as the web-browser component of
Mozilla's Seamonkey, has been updated regularly. Seamonkey
has released it's first revision in some time, only lately.
This wasn't so much an update as a re-install.

There was also an update of Java released lately, so there
could be issues/bugs associated with that.

Operating system, browser and java rev all affect the
ability to negotiate some newer web-sites, so alternate
browser availability is sometimes prudent and useful.

My preference is to avoid browsers that are tied to data
collectors/vendors and don't allow users to restrict
specific java functions/operations.

RL

On 4/28/2022 6:52 AM, legg wrote:
> On Mon, 25 Apr 2022 23:24:50 -0600, rbowman <bowman@montana.com>
> wrote:
>
>> On 04/25/2022 11:01 PM, Mike Monett wrote:
>>> Firefox is far superior to Chrome, Opera, SeaMonkey, or any other browser.
>>> I have tried them all.
>>
>> Your experience differs from mine, at least for the last several years.
>> I'm running Firefox 99.0.1 on my Linux box. At least it no longer locks
>> the machine up but it crashes on a couple of websites I visit and at
>> other odd times.

I've not seen a FF crash/lockup. But, it has nasty, persistent
memory leaks. Plan on restarting it periodically. Especially
on the consumer "8GB" machines.

>> It's been losing market share for several years. Mozilla made several
>> bad decisions and hasn't been keeping up. Your problem with Canadian
>> Tire is one symptom.
>>
>> It is better than Safari though. Even if you put FF on an Apple device
>> it uses webkit.
>
> Firefox, which started out as the web-browser component of
> Mozilla's Seamonkey, has been updated regularly. Seamonkey
> has released it's first revision in some time, only lately.
> This wasn't so much an update as a re-install.
>
> There was also an update of Java released lately, so there
> could be issues/bugs associated with that.
>
> Operating system, browser and java rev all affect the
> ability to negotiate some newer web-sites, so alternate
> browser availability is sometimes prudent and useful.
>
> My preference is to avoid browsers that are tied to data
> collectors/vendors and don't allow users to restrict
> specific java functions/operations.

+42

I run with damn near all script disabled. Then, selectively
TEMPORARILY reenable domains -- avoiding those that are likely
there just to facilitate tracking and ad pushes.

If I can't get the site to function with a reasonable set of *enabled*
domains, then I abandon the page (there are very few such sites that
I would "miss" if I couldn't access them!)

When done, I "disable all temporaries" to return to the set of
domains that I'm comfortable leaving "on" at all times.

I'm waiting for NoScript to *remember* the domains enabled for a specific
page/webdomain so I don't have to repeat this exercise each time I
visit a particular site.

By far, my biggest peeve is with ecommerce sites with stupid search engines.
E.g., searching for something very specific (lots of terms) ends up as a
very GENERAL search -- as if each term was conjoined with the others with
an "OR" operator.

["Yes, I'm sure you would like to get me to buy SOMETHING, hence all
of the possibilities you're offering me. But, have you noticed that
I don't even bother to scroll down past the first item -- as it
clearly ISN'T the SPECIFIC item I was seeking? Let's see what
your competitor shows for that search..."]

On 04/28/2022 01:43 AM, Don Y wrote:
> On 4/27/2022 10:28 PM, rbowman wrote:
>> On 04/27/2022 09:48 PM, Don Y wrote:
>>> On 4/27/2022 8:10 PM, rbowman wrote:
>>
>>> But what's the motivation for a browser-based solution?
>>> Are you trying to have a "no install" application (which
>>> makes it immediately available to EVERY seat)?
>>> Or, streamline maintenance (server-side updates)?
>>> Or...?'
>>
>> All of the above... In the last few years I've been seeing a lot of
>> RFP's calling for zero footprint solutions. Some of that is justified
>> paranoia about hacking. They don't advertise but an embarrassing
>> number of sites have been pwned. Zero footprint means you can lock the
>> workstations down tight and not let the users wander off to watch cat
>> videos or whatever.
>
> 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.

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.

> Or, do you want MS to deal with the "multiple vendor support" issues (so
> YOU
> don't have to develop network and video drivers for an unlimited number of
> potential hardware configurations)?

There is that too. The less we deal with hardware, the better.
>
>> They've backed off the cloud based fad. AWS has dumped often enough to
>> take the
>
> Hmmmm... that's an interesting observation (the whole "cloud" idea
> struck me
> as seriously flawed)

It has issues.

> So, do you deploy the server-side code on commodity hardware? Or,
> "certified"
> (commodity) hardware -- so you have some control over that performance?

Yes. Typically very healthy servers with a Stratus everRun HA setup.

> 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 assume you aren't deploying personnel to each site but, rather, doing
> remote
> administration? Presumably, you've got that locked down tight so *you*
> aren't
> the attack vector? (all traffic in an encrypted tunnel?)

There are site visits during the initial deployment to set up the system
and train the personnel but day to day is remote. It used to be casual
but now access to the system is locked down tight, two factor auth, the
whole nine yards.
>
>> 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.

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

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

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.

On Tue, 26 Apr 2022 09:07:17 -0700, jlarkin@highlandsniptechnology.com
wrote:

>On Tue, 26 Apr 2022 10:15:22 -0400, Phil Hobbs
><pcdhSpamMeSenseless@electrooptical.net> wrote:
>
>>rbowman wrote:
>>> On 04/25/2022 05:04 AM, Dan Purgert wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA512
>>>>
>>>> Jeroen Belleman wrote:
>>>>> On 2022-04-25 11:19, Jan Panteltje wrote:
>>>> ?? [...]
>>>>>> Face it, internet is dead, back to posting pigeons. [...]
>>>>>
>>>>> It's getting worse by the day, indeed. I've seen sites that
>>>>> are *only* JavaScript, several Mbytes of it, which then load
>>>>> the equivalent of a mere kbyte or two of real content, and
>>>>> even that only if you have the very latest browser.
>>>>
>>>> It's like a resurgence of the flash-sites of the late '90s / early '00s
>>>> all over again.
>>>
>>> This one may be here to stay. Angular, React, Vue, etc. Users have come
>>> to expect single page applications and they take JavaScript -- a lot of
>>> it. We're developing an Angular app and I don't even want to think about
>>> how much JS.
>>
>>I run every browser instance in its own disposable Qubes VM, so whatever
>>cruft they leave behind goes away when I close the browser (which shuts
>>down the VM). Good Medicine.
>>
>>Cheers
>>
>>Phil Hobbs
>
>
>I keep my bookmarks in a Dropbox folder, all sorted. Firefox lets me
>drag/drop links from the address bar into my bookmarks folder.
>
>The browser can die and I still have the bookmarks.

I save my bookmarks to a file once in a while.

For cookie and tracking mitigation, Privacy Badger takes care of that.

I used to use FF and Noscript but it got kind of annoying to unblock
things after a while.

boB

rbowman <bowman@montana.com> wrote:

> On 04/27/2022 11:32 PM, Mike Monett wrote:
>> Why does Canadian Tire require one specific browser?
>
> Simply put, because they don't care or the website was developed by
> someone's cousin's kid. Looking at their page source they're not doing
> anything fancy.

Youtube settings now requires Chrome. Firefox 96.0.2 no longer works.

It looks like more companies are going the way of Android. They think
everyone has a cellphone. Forget about desktops. They don't count.

I wonder if posting a suggestion to Mozilla would do any good.

First, I'll try the latest and greatest version of Firefox.

Unfortunately, that means I have to bypass the update restriction I have in
the registry.

It also means I would be stuck with the update, even if it destroys other
features that I need.

Fortunately, I am running on VirtualBox, which means I can restore any
previous version simply by reloading the .VDI file.

Everyone should be on VirtualBox!

--
MRM

On 29.4.22 11.15, Mike Monett wrote:
> rbowman <bowman@montana.com> wrote:
>
>> On 04/27/2022 11:32 PM, Mike Monett wrote:
>>> Why does Canadian Tire require one specific browser?
>>
>> Simply put, because they don't care or the website was developed by
>> someone's cousin's kid. Looking at their page source they're not doing
>> anything fancy.
>
> Youtube settings now requires Chrome. Firefox 96.0.2 no longer works.
>
> It looks like more companies are going the way of Android. They think
> everyone has a cellphone. Forget about desktops. They don't count.
>
> I wonder if posting a suggestion to Mozilla would do any good.
>
> First, I'll try the latest and greatest version of Firefox.
>
> Unfortunately, that means I have to bypass the update restriction I have in
> the registry.
>
> It also means I would be stuck with the update, even if it destroys other
> features that I need.
>
> Fortunately, I am running on VirtualBox, which means I can restore any
> previous version simply by reloading the .VDI file.
>
> Everyone should be on VirtualBox!

Your Firefox may be obsolete, the settings work fine on 99.0.1.

--

-TV

On 2022-04-29 10:15, Mike Monett wrote:
> rbowman <bowman@montana.com> wrote:
>
>> On 04/27/2022 11:32 PM, Mike Monett wrote:
>>> Why does Canadian Tire require one specific browser?
>>
>> Simply put, because they don't care or the website was developed by
>> someone's cousin's kid. Looking at their page source they're not doing
>> anything fancy.
>
> Youtube settings now requires Chrome. [...]
>
> [...]

Of course it does. There's a ferocious battle for web dominance going
on. Every clan continually invents new tricks to render the opposition's
software inoperative, influencing people to switch to /their/ version.
They will then abuse that to pry private information out of you, and
spray you with propaganda to manipulate you to commercial and political
ends. With billions of subjects, the stakes are staggering and the
tiniest details can have huge effects.

Jeroen Belleman

On 04/29/2022 02:24 AM, Tauno Voipio wrote:
> On 29.4.22 11.15, Mike Monett wrote:
>> rbowman <bowman@montana.com> wrote:
>>
>>> On 04/27/2022 11:32 PM, Mike Monett wrote:
>>>> Why does Canadian Tire require one specific browser?
>>>
>>> Simply put, because they don't care or the website was developed by
>>> someone's cousin's kid. Looking at their page source they're not doing
>>> anything fancy.
>>
>> Youtube settings now requires Chrome. Firefox 96.0.2 no longer works.
>>
>> It looks like more companies are going the way of Android. They think
>> everyone has a cellphone. Forget about desktops. They don't count.
>>
>> I wonder if posting a suggestion to Mozilla would do any good.
>>
>> First, I'll try the latest and greatest version of Firefox.
>>
>> Unfortunately, that means I have to bypass the update restriction I
>> have in
>> the registry.
>>
>> It also means I would be stuck with the update, even if it destroys other
>> features that I need.
>>
>> Fortunately, I am running on VirtualBox, which means I can restore any
>> previous version simply by reloading the .VDI file.
>>
>> Everyone should be on VirtualBox!
>
>
> Your Firefox may be obsolete, the settings work fine on 99.0.1.
>

No problem here with 99.0.1 on OpenSUSE either. The only problem I've
had lately is Amazon Prime video not working with Brave so I used Edge.
I think that may be Brave's privacy enhancements and I could have worked
around somehow.

Jeroen Belleman wrote:
> On 2022-04-29 10:15, Mike Monett wrote:
>> rbowman <bowman@montana.com> wrote:
>>
>>> On 04/27/2022 11:32 PM, Mike Monett wrote:
>>>> Why does Canadian Tire require one specific browser?
>>>
>>> Simply put, because they don't care or the website was developed by
>>> someone's cousin's kid.  Looking at their page source they're not doing
>>> anything fancy.
>>
>> Youtube settings now requires Chrome. [...]
>>
>> [...]
>
> Of course it does. There's a ferocious battle for web dominance going
> on. Every clan continually invents new tricks to render the opposition's
> software inoperative, influencing people to switch to /their/ version.
> They will then abuse that to pry private information out of you, and
> spray you with propaganda to manipulate you to commercial and political
> ends. With billions of subjects, the stakes are staggering and the
> tiniest details can have huge effects.
>
> Jeroen Belleman

"DOS isn't done till Lotus won't run."

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC / Hobbs ElectroOptics
Optics, Electro-optics, Photonics, Analog Electronics
Briarcliff Manor NY 10510

http://electrooptical.net
http://hobbs-eo.com