On Sunday, August 28, 2022 at 11:25:41 PM UTC+10, none albert wrote:
> In article <4e05ee3b-9e69-4f3d...@googlegroups.com>, 
> Anthony William Sloman <bill....@ieee.org> wrote: 
> >On Monday, August 1, 2022 at 5:58:34 AM UTC+10, Ralph Mowery wrote: 
> >> In article <jko0b1...@mid.individual.net>, bow...@montana.com 
> >> says... 
> >> > 
> >> > Different era but when I was a IEEE member most of the interesting stuff 
> >> > happened in the Boston chapter. My home chapter in New Hampshire was 
> >> > almost all classic electrical engineers working for Public Service, the 
> >> > power company. They basically knew nothing about computers except they 
> >> > were afraid of them. 
> >> > 
> >> It is amazing to me how about 10 years can make a difference. I am 72 
> >> and a friend is 82. He was an electronics engineer with a 4 year degree 
> >> and worked in the Bell Labs and Western Electric. He is stuck in the 
> >> vacuum tube era. Does not like to use a computer and fills out his tax 
> >> by hand. I just went to a 2 year tech school for electronic 
> >> engineering. A few years after school the home computers came out. My 
> >> first was a TRS80 model 3. While I may not be great with computers now 
> >> I do use them all the time. About 2 years go I got into the Arduino 
> >> world and taught myself how to get around with one. 
> > 
> >The problem isn't the age difference, but the attitude difference. I'm 79, and I happily use my computer to fill out my 
> >tax information. 
> > 
> >My father wouldn't have a computer in the house, but as soon as he died, I got my mother to buy one. It took her a while 
> >to get to use it. For about a year my nephews - her grandchildren - pulled my e-mails off her computer every week and 
> >typed in her responses, but she watched them do and could eventually do it for herself and compose her own replies, and we 
> >swapped e-mails every day for about a decade until senile dementia hit her. 
> 
> This was before the IBM pc. In the Netherlands they gave presents at December 
> 5th accompanied with a poem of sorts. (The original St. Nicolas). 

I know about it, but my wife did all our poem writing - she was much better at it than I was.

> A niece caught me writing these poems on the CPM machine (Osborne). 
> This was the first time she saw text processing in the flesh. 
> Boy, was she upset! Blasphemy. 

Bizzare. But the ancient Greeks used to think that writing down poems was equally dubious - you were supposed to memorise them.

-- 
Bill Sloman, Sydney

In article <4e05ee3b-9e69-4f3d-8fa6-371be61fcf7bn@googlegroups.com>,
Anthony William Sloman  <bill.sloman@ieee.org> wrote:
>On Monday, August 1, 2022 at 5:58:34 AM UTC+10, Ralph Mowery wrote:
>> In article <jko0b1...@mid.individual.net>, bow...@montana.com
>> says...
>> >
>> > Different era but when I was a IEEE member most of the interesting stuff
>> > happened in the Boston chapter. My home chapter in New Hampshire was
>> > almost all classic electrical engineers working for Public Service, the
>> > power company. They basically knew nothing about computers except they
>> > were afraid of them.
>> >
>> >
>> >
>> It is amazing to me how about 10 years can make a difference. I am 72
>> and a friend is 82. He was an electronics engineer with a 4 year degree
>> and worked in the Bell Labs and Western Electric. He is stuck in the
>> vacuum tube era. Does not like to use a computer and fills out his tax
>> by hand. I just went to a 2 year tech school for electronic
>> engineering. A few years after school the home computers came out. My
>> first was a TRS80 model 3. While I may not be great with computers now
>> I do use them all the time. About 2 years go I got into the Arduino
>> world and taught myself how to get around with one.
>
>The problem isn't the age difference, but the attitude difference. I'm 79, and I happily use my computer to fill out my
>tax information.
>
>My father wouldn't have a computer in the house, but as soon as he died, I got my mother to buy one. It took her a while
>to get to use it. For about a year my nephews - her grandchildren - pulled my e-mails off her computer every week and
>typed in her responses, but she watched them do and could eventually do it for herself and compose her own replies, and we
>swapped e-mails every day for about a decade until senile dementia hit her.

This was before the IBM pc. In the Netherlands they gave presents at December
5th accompanied with a poem of sorts. (The original St. Nicolas).
A niece caught me writing these poems on the CPM machine (Osborne).
This was the first time she saw text processing in the flesh.
Boy, was she upset! Blasphemy.

>Bill Sloman, Sydney

Groetjes Albert
-- 
"in our communism country Viet Nam, people are forced to be
alive and in the western country like US, people are free to
die from Covid 19 lol" duc ha
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

On 8/16/2022 10:58 AM, whit3rd wrote:
> On Tuesday, August 16, 2022 at 10:28:26 AM UTC-7, Don Y wrote:
> 
>> [To be truly amusing, imagine opening two different browsers on the same
>> machine. Should they *ever* be permitted to "co-operate"?]
> 
> No need to imagine, I'm doing it.   The main cooperation required, is just that
> I can drag an address from the browser that mangles  the page, to the
> icon in the dock of the other browser, and see if that helps.   Often, it does.
> 
> Latest issue: light-grey font on white.   Gotta cut-and-paste into a text editor
> to see it, multiple browsers don't help.  I certainly DO miss the old 'show source'
> feature, which allowed some disentanglements in the past.

No, I mean having two "tabs" of the same browser-based *application* running
in different browsers.

E.g., An application that automates preparation of a tax return.  Tab 1 shows
my 1040 and tab 2 shows my schedule A.  Changes to schedule A in tab 2 are
automatically reflected on the 1040 in tab 1.

Now, have tab 1 be in an Edge browser and tab 2 be in Firefox.

This is contrary to the security model the browser is supposed to
provide; tab 1 shouldn't be able to interact with tab 2 (except
via client-side storage/cookies).  Being able to bridge the
protection domain that a different application imposes should
(presumably) be "impossible" -- except for super cookies?

On Tuesday, August 16, 2022 at 10:28:26 AM UTC-7, Don Y wrote:

> [To be truly amusing, imagine opening two different browsers on the same 
> machine. Should they *ever* be permitted to "co-operate"?]

No need to imagine, I'm doing it.   The main cooperation required, is just that
I can drag an address from the browser that mangles  the page, to the
icon in the dock of the other browser, and see if that helps.   Often, it does.

Latest issue: light-grey font on white.   Gotta cut-and-paste into a text editor
to see it, multiple browsers don't help.  I certainly DO miss the old 'show source'
feature, which allowed some disentanglements in the past.

On 8/16/2022 9:57 AM, rbowman wrote:
> On 08/16/2022 04:27 AM, Jasen Betts wrote:
>> So far as I know, if you read the standards and exploit them in as
>> much at they are consistently implemented by browser suppliers you
>> end up with high reliability scripts. if you go chasing latest browser
>> features not so much.
> 
> Counter examples are browsers removing NPAPI or Flash support for security 
> reasons. 20 years ago a Java applet was a reasonable approach to developing a 
> responsive web page.

It's not just pushing client side processing to increase responsiveness.
How would you, for example, run a virtual machine of your own design (e.g.,
to host an application) *in* a browser?  Each "tab" is an independent
(isolated) VM.

So, to build a tabbed interface, you'd have to do it *within* a single
session -- *or*, require server-side coordination of those multiple
sessions.  Anything that "tab #1" needed to know about "tab #2" would
require a round-trip to the server, each time tab #2 dicked with something.

[To be truly amusing, imagine opening two different browsers on the same
machine.  Should they *ever* be permitted to "co-operate"?]

On 8/16/2022 3:27 AM, Jasen Betts wrote:
> On 2022-08-13, Don Y <blockedofcourse@foo.invalid> wrote:
>> On 8/13/2022 8:39 AM, rbowman wrote:
>>> On 08/12/2022 09:39 PM, Don Y wrote:
>>>> On 8/12/2022 8:34 PM, rbowman wrote:
>>>>> On 08/12/2022 08:24 PM, Don Y wrote:
>>>>>> I've never written a JS applet but can't imagine it would be
>>>>>> much more than an afternoon excercise (for most "pages").  Esp
>>>>>> given the highly developed frameworks that make it a cut and
>>>>>> paste sort of ordeal.
>>>>>
>>>>> mmm-hmmm.  The covid gap has messed up my time sense but I think we're
>>>>> close to 3 years into developing what amounts to an Angular SPA.
>>>>> That's 3 to 4 1/2 full time programmers and 3 to 4 testers. I count
>>>>> myself as 1/2 since most of what I've done is integrating the ESRI
>>>>> 4.20 Javascript API into one of the panels and other odd tasks while
>>>>> doing enhancements and fixes in the legacy code.
>>>>
>>>> That's not an "appLET".  You're developing a real application suite/system
>>>> *under* a Java framework.  I'd wager most JS "coders" are busy knocking
>>>> out what could reasonably be called cookie-cutter "web sites".  Not much
>>>> "engineering", there!  (hence the use of *coders*)
>>>
>>> NOT Java!!! That was a very unfortunate naming. This is a replacement for a
>>> legacy Java app that was the original attempt at a cross platform solution.
>>> That became an albatross when the browsers dropped support for Java applets
>>> (and ActiveX) because of the security holes.
>>>
>>> It is a challenge to replace a suite of legacy programs with a browser based
>>> application but many of the RFP's have been specifying zero footprint. It
>>> certainly makes updates a lot easier, particularly for mobile resources.
>>
>> I don't believe you can write a portable, browser-based application with
>> any guarantee of long-term (10 years?) support.  Browsers are continually
>> evolving; in three years we may be on *U*HTML 37.
> 
> https://www.elizium.nu/scripts/lemmings/
> 
> Possibly no guarantee.... but that's 16 years.
> that would run on IE4 and whatever version Netscape was back then.
> (and still works)
> 
>> Were I charged with such a task, I'd define a virtual middleware to host
>> the app.  Then, have a second team responsible for keeping that middleware
>> supported on newer browsers.  This eliminates the problem of having the
>> application developers constantly trying to adjust to shifting sand.
> 
> So far as I know, if you read the standards and exploit them in as
> much at they are consistently implemented by browser suppliers you
> end up with high reliability scripts. if you go chasing latest browser
> features not so much.

If it "still works" then it has deliberately kept it's implementation tied
to the past.  Browsers evolve because of perceived needs.  Deliberately
avoiding new features limits what you can do in an application to whatever
was possible "in ages gone by".

Once you drink the kool-aid, you're forever stuck with the possibility
of customer A running NewBrowser while customer B clings to OldBrowser.

My current design has to accommodate hardware and software "additions"
incrementally added to an installation (deployment) WITHOUT requiring
all existing hardware/software to be "upgraded" (to the latest release).
It does this by supporting multiple interface versions for each piece
of software.  So, an application/device can (late-) bind to whatever
version of an interface it needs.

On 08/16/2022 04:27 AM, Jasen Betts wrote:
> So far as I know, if you read the standards and exploit them in as
> much at they are consistently implemented by browser suppliers you
> end up with high reliability scripts. if you go chasing latest browser
> features not so much.

Counter examples are browsers removing NPAPI or Flash support for 
security reasons. 20 years ago a Java applet was a reasonable approach 
to developing a responsive web page.

On 2022-08-13, Don Y <blockedofcourse@foo.invalid> wrote:
> On 8/13/2022 8:39 AM, rbowman wrote:
>> On 08/12/2022 09:39 PM, Don Y wrote:
>>> On 8/12/2022 8:34 PM, rbowman wrote:
>>>> On 08/12/2022 08:24 PM, Don Y wrote:
>>>>> I've never written a JS applet but can't imagine it would be
>>>>> much more than an afternoon excercise (for most "pages").  Esp
>>>>> given the highly developed frameworks that make it a cut and
>>>>> paste sort of ordeal.
>>>>
>>>> mmm-hmmm.  The covid gap has messed up my time sense but I think we're
>>>> close to 3 years into developing what amounts to an Angular SPA.
>>>> That's 3 to 4 1/2 full time programmers and 3 to 4 testers. I count
>>>> myself as 1/2 since most of what I've done is integrating the ESRI
>>>> 4.20 Javascript API into one of the panels and other odd tasks while
>>>> doing enhancements and fixes in the legacy code.
>>>
>>> That's not an "appLET".  You're developing a real application suite/system
>>> *under* a Java framework.  I'd wager most JS "coders" are busy knocking
>>> out what could reasonably be called cookie-cutter "web sites".  Not much
>>> "engineering", there!  (hence the use of *coders*)
>> 
>> NOT Java!!! That was a very unfortunate naming. This is a replacement for a 
>> legacy Java app that was the original attempt at a cross platform solution. 
>> That became an albatross when the browsers dropped support for Java applets 
>> (and ActiveX) because of the security holes.
>> 
>> It is a challenge to replace a suite of legacy programs with a browser based 
>> application but many of the RFP's have been specifying zero footprint. It 
>> certainly makes updates a lot easier, particularly for mobile resources.
>
> I don't believe you can write a portable, browser-based application with
> any guarantee of long-term (10 years?) support.  Browsers are continually
> evolving; in three years we may be on *U*HTML 37.

https://www.elizium.nu/scripts/lemmings/

Possibly no guarantee.... but that's 16 years.
that would run on IE4 and whatever version Netscape was back then.
(and still works)

> Were I charged with such a task, I'd define a virtual middleware to host
> the app.  Then, have a second team responsible for keeping that middleware
> supported on newer browsers.  This eliminates the problem of having the
> application developers constantly trying to adjust to shifting sand.

So far as I know, if you read the standards and exploit them in as 
much at they are consistently implemented by browser suppliers you 
end up with high reliability scripts. if you go chasing latest browser
features not so much.


-- 
  Jasen.

On 8/14/2022 9:32 PM, rbowman wrote:
> Modern operating systems are Hardware Abstraction Layers.

That's *one* aspect.  But, they often provide mechanisms that have no direct
bearing on the underlying hardware.  E.g., my RTOS is an object-based
capability driven system.  Ideally, support for protection domains lets
me ensure the security of the capabilities but one could design similar
with less robust guarantees in the absence of protection domains.

> 40 years ago I was 
> familiar with the nuances of the WD1793.  Today I don't have a clue how data 
> winds up on a M.2 SSD or if the box even has a M.2 for that matter.

Designing deeply embedded devices means I'm often "down in the weeds" trying
to make sense of some bit of hardware -- in *or* out of the processor.

Processors, nowadays, are far more complex than even the most complex
peripherals/support chips from years past.   1000+ pp datasheets are
not uncommon.

Plus, a lot of devices aren't quite as "esoterically" designed as they would
have been in the past; it's more like an "80% solution" to most problems
(counters/timers are a prime example) where the i's aren't always dotted
nor t's crossed.

And, if you're designing a non-toy OS (anything more than a simple "task
switcher"), you need to survey the range of potential devices before settling
on the abstractions that you want to implement, lest you make choices that
aren't particularly portable.

OTOH, what you can get for a few dollars is amazing!  Definitely worth any
hassles or blemishes in implementation!

On 08/14/2022 01:06 PM, Don Y wrote:
> But you can adopt a design approach that isolates much of your effort
> from changes to that platform.  And, gives you increased "portability"
> (platform independence).
>
> Of course, the rub is that you have to invest to create a portable
> platform on
> which to build (like a Hardware Abstraction Layer).

Yes, 20 years ago we could have invested in a portable platform to solve 
a problem that never happened. The code base already contains some 
unnecessarily complex code that anticipated needs that were never 
needed. As Don Schlitz wrote:

"You got to know when to hold 'em,
Know when to fold 'em,
Know when to walk away,
And know when to run."

Modern operating systems are Hardware Abstraction Layers. 40 years ago I 
was familiar with the nuances of the WD1793.  Today I don't have a clue 
how data winds up on a M.2 SSD or if the box even has a M.2 for that 
matter.