not OT : fear...

[Les Cargill]

rbowman wrote:

On 07/30/2022 04:09 PM, Klaus Vestergaard Kragelund wrote:
On 27/07/2022 04.10, bitrex wrote:
On 7/26/2022 10:06 PM, Rich S wrote:
On Tuesday, July 26, 2022 at 6:38:36 PM UTC, John Larkin wrote:
On Tue, 26 Jul 2022 14:11:00 -0400, bitrex <us...@example.net> wrote:

On 7/26/2022 1:43 PM, John Larkin wrote:

https://www.studyfinds.org/fear-for-safety-every-day/

What\'s wrong with kids these days? Most have been super-protected
children but are afraid of life.

Engineers have to THINK, blow things up, take calculated risks. Fear
warps prudent judgement.

I\'ve had interns that were afraid to touch a board powered from 5
volts, or handle a 12 volt battery. And wanted eye protection and
masks for everything. And who wouldn\'t crank up a power supply to
see
how much an electrolytic cap would leak past abs max voltage rating.

I guess you get what you pay for
Interns are cheap and most don\'t last long.

Maybe during the interview, you ask them to
\"taste\" the top of an 9V battery. If they refuse,
or they do but get really upset  then don\'t hire
  them. :0)

I think getting shocked, blowing fuses, etc,
were a rite of passage for young experimenter.
Getting of visceral sense of energy, feel what is electricity.
But in today\'s highly safety-conscious society we mustn\'t
say such things  :-X


Pretty sure I recall people here complaining more kids were going into
software than hardware these days.

Might have something to do with that nobody asks you to suck on a 9
volt to get your first job in that field. And that first job usually
pays way better, too.


The engineers graduating predominately in software engineering, and
Hardware is becoming extinct:

Engineers on the brink of extinction threaten entire tech ecosystems:

https://www.theregister.com/2022/07/18/electrical_engineers_extinction/

I think the article has a valid point. I\'ve got hopes for the maker
culture but I don\'t know how many participate. Our new library has a
nicely equipped makerspace with several printers, scanners, laser
cutters and so forth. I should snoop around and see how much it is being
used. I\'ll confess that with ebooks I don\'t physically visit the library
often.

Cars have the same problem. If a budding hotrodder gets his hands on a
10 year old Civic, there isn\'t much he can do.

They do ever so much, though. Check out the Regular Cars channel on
YouTube. People will add boost, redo the suspension, lots of stuff. Even
replace the ECM or \"tune\" them. It\'s no longer \"add a Cherry Bomb and
spoilers.\"

If you get a chance, find current prices for 1994 Toyota Supra MK IV.
Because of the association with a film franchise, they run to stupendous
amounts of money.

CAI, cat-back, overdrive
pulley, and other minor stuff.

--
Les Cargill

 

[Les Cargill]

Don Y wrote:

On 8/1/2022 9:35 AM, rbowman wrote:
On 08/01/2022 07:30 AM, jlarkin@highlandsniptechnology.com wrote:
Computer Science seems to have little to do with computers.

Nor does it have much to do with practical coding in its pure form.

CS *now* likely has very little to do with engineering.

\"CS\" CS is math. Computer engineering is different. It\'s
library science plus EE plus computation theory. Throw in
project management.

That\'s why we have \"programmers\" and \"coders\" -- instead of
\"software engineers\".

We have those, too. But the call of the Web means not many
will be all that interested.

  Business wants to dumb down their
needs (why so many COTS \"hardware modules\"?  what\'s so hard
about those designs/fabs that you need to rely on someone
else to design them -- plus the support firmware -- instead
of rolling your own?)

Lots of reasons. These days it\'s harder to find people who
can spin boards for one. Never mind you can do it by mail.

It\'s also why productivity varies so much between application
level, system level, OS level and RT -- because of the relative
lacks of specific skills to address those ever demanding
\"markets\".

I think more is made of this than there really should be. It\'s
all one big thing. But there\'s money to be made in C# and those
guys aren\'t gonna be comfortable writing drivers after a while.

But people like things they can see, even if that\'s an illusion.
The best computer is the one you don\'t even know is there until it
stops working.

And, why so many folks sit down and write code without having any formal
documents to describe WHAT the code must do and the criteria against
which it will be tested/qualified!  <rolls eyes

If you start with the test harness you get more done. Once you have the
prototype up, then write the documents. You\'ll simply know more that
way.

I\'d enjoy watching a \"programmer\" design a VMM system with
what he likely DOESN\'T know about the machine hardware.  Or,
tell him he has to treat all of his RT requirements as SRT
(unless he can claim \"it can\'t be done\" -- and substantiate
that!)

Wanna bet few even consider the value of cache wrt
the design of their data structures and code layout?

[I spend a shitload of time thinking about how to design
these to maximize cache and TLB hits -- otherwise, why
*pay* for that hardware?]

These days? It all comes out in the wash. I haven\'t been compute bound
in a couple decades.

--
Les Cargill

 

[Les Cargill]

jlarkin@highlandsniptechnology.com wrote:
<snip>

Transistors, then ICs, then uPs, were game changers. What\'s the next
one?

Way too much compute power is now way too cheap. You can do realtime
nonlinear simulation in the audio range with just about any PC. The
software costs are minimal. Not much is out of range in terms of
capability.

It\'s to the point now that the UI is the point of differentiation.

Programmable analog chips keep getting invented and keep dying. That\'s
interesting.

They get themselves cornered and end up on the price decline curve.
Besides, who really knows what they\'re used for these days? If it
goes in a phone, it lasts as long as that phone. Otherwise it\'s
customer by customer.

I know of one guy who used a digital pot and a micro to make a
software-driven audio compressor ( the FMR 1175 ) and SFAIK, he\'s sold
that out and retired.

He did the marketing very well.

--
Les Cargill

 

[Don Y]

On 8/12/2022 5:52 PM, Les Cargill wrote:

Don Y wrote:
On 8/1/2022 9:35 AM, rbowman wrote:
On 08/01/2022 07:30 AM, jlarkin@highlandsniptechnology.com wrote:
Computer Science seems to have little to do with computers.

Nor does it have much to do with practical coding in its pure form.

CS *now* likely has very little to do with engineering.

\"CS\" CS is math. Computer engineering is different. It\'s
library science plus EE plus computation theory. Throw in
project management.

When I went to school, an EE(CS) was expected to be able to design
a computer (\"CPU\"), design a language, write a compiler for the
language and design/implement an OS using some or all of the above.

Each *class* had its own home-grown computer system, OS, etc.
That\'s why you have grad students! :>

The folks I\'ve seen/interviewed in the decades since seem only
to know how to write code in the /langue du jour/. The underlying
hardware, the translation of their statements into instruction
sequences, etc. are just some ephemeral concepts to them.

That\'s why we have \"programmers\" and \"coders\" -- instead of
\"software engineers\".

We have those, too. But the call of the Web means not many
will be all that interested.

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.

Business wants to dumb down their
needs (why so many COTS \"hardware modules\"? what\'s so hard
about those designs/fabs that you need to rely on someone
else to design them -- plus the support firmware -- instead
of rolling your own?)

Lots of reasons. These days it\'s harder to find people who
can spin boards for one. Never mind you can do it by mail.

But, they will likely have to develop (design, layout, fabricate, test)
a daughter-board of some sort to bridge the gap between COTS module and
their particular needs. Or, piece (kludge) together a bunch of modules
in the hope that they can get close to what they need.

It\'s also why productivity varies so much between application
level, system level, OS level and RT -- because of the relative
lacks of specific skills to address those ever demanding
\"markets\".

I think more is made of this than there really should be. It\'s
all one big thing. But there\'s money to be made in C# and those
guys aren\'t gonna be comfortable writing drivers after a while.

There\'s a huge difference between writing an application, an OS,
drivers, etc. Real-time constraints act as a *multiplier* on that.
And, safety/reliability a further multiplier.

When you look at big projects, productivity falls dramatically
as the complexity increases (app->driver->os, etc.)

But people like things they can see, even if that\'s an illusion.
The best computer is the one you don\'t even know is there until it
stops working.

And, why so many folks sit down and write code without having any formal
documents to describe WHAT the code must do and the criteria against
which it will be tested/qualified! <rolls eyes

If you start with the test harness you get more done. Once you have the
prototype up, then write the documents. You\'ll simply know more that
way.

I approach it from the top, down. Figure out what the *requirements*
are (how can you design a test harness if you don\'t know what you\'ll be
testing or the criteria that will be important?).

Once you know the requirements, a \"programmer\" can do the implementation
(all of the design is codified in the requirements document).

If you write an actual *manual* as your requirements document, then you
already know all of the operating conditions, error conditions, messages,
etc. There\'s no significant thinking required thereafter.

I allocate ~40% of my time for requirements, 20% for coding and 40% for
testing/verification. I may not write a line of code for many months at
a time! But, when I start, I know exactly what the code will do and
how it will do it, the hazards that it will have to navigate, etc.

So, I don\'t end up \"discovering\" that some early implementation decision
has left me with a foundation for a summer cottage while I\'m trying to
erect a 35 room mansion atop it!

I\'d enjoy watching a \"programmer\" design a VMM system with
what he likely DOESN\'T know about the machine hardware. Or,
tell him he has to treat all of his RT requirements as SRT
(unless he can claim \"it can\'t be done\" -- and substantiate
that!)

Wanna bet few even consider the value of cache wrt
the design of their data structures and code layout?

[I spend a shitload of time thinking about how to design
these to maximize cache and TLB hits -- otherwise, why
*pay* for that hardware?]

These days? It all comes out in the wash. I haven\'t been compute bound in a
couple decades.

You\'ve been blessed. My career has consisted of designing hardware
that can just barely meet the needs of the product and having to
squeeze every bit of performance from it. (because we\'re trying to
keep product cost/complexity to a minimum)

I had an argument with an employer years ago because I put a dozen
16bit counters in my design when *he* thought I could just implement
the high-order byte (for 8 of them) in software (IRQ, highbyte++, RETI).

Because that\'s what would be the norm in the markets in which we operated.

Without batting an eyelash, I told him that it would require 15% of
real-time just to process those IRQ\'s. CONTINUOUSLY (as the counters
had to be running in order to detect events of interest based on
changes in frequencies) 15% of the product \"spent\" to save eight 8-bit
counters.

[of *course* I had already done the math, that\'s called engineering!
a \"programmer\" would have just written the code and wondered why
the system couldn\'t meet it\'s performance goals]

The final product often ran at 100% of real-time as it had to react to the
actions of the user; you can\'t limit how quickly a user drags a barcode
label across a photodiode (no, you can\'t put a \"barcode reader\" in the
design as that costs recurring dollars!)

In my first commercial product, we counted the number of discrete subroutine
invocations (CALL <foo>) and sorted by target address. Then, replaced the
*8* (magic!) most frequent ones with one byte opcodes that redirected through
a set of 8 specific locations in memory. This added a small delay to each
of those subroutine invocations. But, saved 2 bytes for each \"CALL\". This
let us reduce the size of the binary enough to remove a 2Kx8 EPROM from the
BoM (at the time, 2716\'s were on allocation AND selling for $50/each).

My present project has gobs of resources. And I am generously consuming them
to make the operating environment more robust and reliable. Approaching the
issue from the other side: how much can I \"waste\" to make the *application*
better without significantly impacting performance?

At the same time, supporting dynamic system reconfiguration that allows
hardware to be shed to conserve power, etc. (how do you adjust the workload
when you\'re reducing the resources available?) Or, defering jobs to times when
there is less demand for resources (\"after hours\").

 

[Don Y]

On 8/12/2022 6:02 PM, Les Cargill wrote:

[specialty chips]

They get themselves cornered and end up on the price decline curve.
Besides, who really knows what they\'re used for these days? If it
goes in a phone, it lasts as long as that phone. Otherwise it\'s
customer by customer.

With a few exceptions, general purpose solutions end up winning out.

\"If you can\'t make a 2X increase in performance/price, just sit on
your hands for a year and get it for free\"

Ages ago, I designed a vector processor that had an opcode that
would apply independent scale factors to dX and dY, divide each
of these into a MaxX, MaxY *respectively*, select the smaller of
these two quotients and scale the *scaled* dX, dY by that amount.
It took ~2us to do this. And, was busy fetching/decoding the next
opcode(s) at the same time!

Now, I can probably write a little subroutine to do it in the
same amount of real time. Using a COTS CPU! Why design custom
chips when you can \"emulate\" them and save all the risk/expense?
(how many should you commit to purchasing? will you be able to
use them for anything *else*??)

I know of one guy who used a digital pot and a micro to make a
software-driven audio compressor ( the FMR 1175 ) and SFAIK, he\'s sold that out
and retired.

He did the marketing very well.

 

[rbowman]

On 08/12/2022 06:40 PM, Les Cargill wrote:

rbowman wrote:
On 07/30/2022 04:09 PM, Klaus Vestergaard Kragelund wrote:
On 27/07/2022 04.10, bitrex wrote:
On 7/26/2022 10:06 PM, Rich S wrote:
On Tuesday, July 26, 2022 at 6:38:36 PM UTC, John Larkin wrote:
On Tue, 26 Jul 2022 14:11:00 -0400, bitrex <us...@example.net> wrote:

On 7/26/2022 1:43 PM, John Larkin wrote:

https://www.studyfinds.org/fear-for-safety-every-day/

What\'s wrong with kids these days? Most have been super-protected
children but are afraid of life.

Engineers have to THINK, blow things up, take calculated risks.
Fear
warps prudent judgement.

I\'ve had interns that were afraid to touch a board powered from 5
volts, or handle a 12 volt battery. And wanted eye protection and
masks for everything. And who wouldn\'t crank up a power supply
to see
how much an electrolytic cap would leak past abs max voltage
rating.

I guess you get what you pay for
Interns are cheap and most don\'t last long.

Maybe during the interview, you ask them to
\"taste\" the top of an 9V battery. If they refuse,
or they do but get really upset then don\'t hire
them. :0)

I think getting shocked, blowing fuses, etc,
were a rite of passage for young experimenter.
Getting of visceral sense of energy, feel what is electricity.
But in today\'s highly safety-conscious society we mustn\'t
say such things :-X


Pretty sure I recall people here complaining more kids were going into
software than hardware these days.

Might have something to do with that nobody asks you to suck on a 9
volt to get your first job in that field. And that first job usually
pays way better, too.


The engineers graduating predominately in software engineering, and
Hardware is becoming extinct:

Engineers on the brink of extinction threaten entire tech ecosystems:

https://www.theregister.com/2022/07/18/electrical_engineers_extinction/

I think the article has a valid point. I\'ve got hopes for the maker
culture but I don\'t know how many participate. Our new library has a
nicely equipped makerspace with several printers, scanners, laser
cutters and so forth. I should snoop around and see how much it is
being used. I\'ll confess that with ebooks I don\'t physically visit the
library often.

Cars have the same problem. If a budding hotrodder gets his hands on a
10 year old Civic, there isn\'t much he can do.

They do ever so much, though. Check out the Regular Cars channel on
YouTube. People will add boost, redo the suspension, lots of stuff. Even
replace the ECM or \"tune\" them. It\'s no longer \"add a Cherry Bomb and
spoilers.\"

Coilovers and remapping or a new chip are common. Adding a blower and/or
nitrous , changing cams, flowing the heads and so forth may be a little
past \'budding\'. A blower means you\'d better do something about fuel
delivery too.

A wise man once said \'The only substitute for cubic inches is cubic
money\'. Apparently some people have cubic money. I forget what the
donor vehicle was but it started life as a FWD and was converted to RWD
since drifting a FWD isn\'t too impressive.

I was surprised to find TRD has some nice Yaris goodies. Turns out the
Yaris (Vitz) is very popular for club racing in Japan.

 

[rbowman]

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.

Actually it\'s TS (TypeScript). Once you get out of the sandbox of
contoso* samples it gets complex.

* contoso is a fictional corporate entity Microsoft used for tutorials
and examples. It goes back to 1998 or so. There is a contoso.com domain
and it\'s grown into a multinational (fictional) corporate entity.

https://docs.microsoft.com/en-us/microsoft-365/enterprise/contoso-overview?view=o365-worldwide

 

[Don Y]

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

Actually it\'s TS (TypeScript). Once you get out of the sandbox of contoso*
samples it gets complex.

* contoso is a fictional corporate entity Microsoft used for tutorials and
examples. It goes back to 1998 or so. There is a contoso.com domain and it\'s
grown into a multinational (fictional) corporate entity.

https://docs.microsoft.com/en-us/microsoft-365/enterprise/contoso-overview?view=o365-worldwide

 

[Don Y]

On 8/12/2022 8:04 PM, rbowman wrote:

On 08/12/2022 06:40 PM, Les Cargill wrote:
rbowman wrote:

Cars have the same problem. If a budding hotrodder gets his hands on a
10 year old Civic, there isn\'t much he can do.

They do ever so much, though. Check out the Regular Cars channel on
YouTube. People will add boost, redo the suspension, lots of stuff. Even
replace the ECM or \"tune\" them. It\'s no longer \"add a Cherry Bomb and
spoilers.\"

Coilovers and remapping or a new chip are common. Adding a blower and/or
nitrous , changing cams, flowing the heads and so forth may be a little past
\'budding\'. A blower means you\'d better do something about fuel delivery too.

A wise man once said \'The only substitute for cubic inches is cubic money\'.
Apparently some people have cubic money. I forget what the donor vehicle was
but it started life as a FWD and was converted to RWD since drifting a FWD
isn\'t too impressive.

*Lots* of people have money -- but little/no skill/desire to get their hands
dirty.

Lots of people have skill -- but no money! :>

[This is true in many fields]

The trick is finding the sweet-spot where you have *enough* money and
*sufficient* skill to do something, impressive, yourself!

A friend was in that (racing) industry, some years back. I tagged along
to visit one of his customers, one day. The customer offered a service
of \"tuning\" stock engines to optimize performance. This by tweeks to
the factory firmware as well as adding and subtracting metal to improve
airflow through the manifolds, etc.

[Of course, there can be no visible sign that any of this has been done! :> ]

It was a delightfully enlightening experience! It gets you thinking
(esp in light of how folks like VW scammed the system) about how you can
skirt the legal requirements (emissions, etc.) and still come out with a
*performance* \"road vehicle\". Something that *really* looks \"stock\"...

I was surprised to find TRD has some nice Yaris goodies. Turns out the Yaris
(Vitz) is very popular for club racing in Japan.

 

[rbowman]

On 08/12/2022 06:52 PM, Les Cargill wrote:

\"CS\" CS is math. Computer engineering is different. It\'s
library science plus EE plus computation theory. Throw in
project management.

That has amused me at times. I\'m not particularly good at math but like
to think I have passable programming skills. I should say logic skills.
I\'ve worked with relay logic, fluidics, TTL/CMOS, and processors. The
logic stays the same. I know about Boolean algebra, DeMorgan\'s theorems,
and so forth but I\'ve seldom made use of formal logic. It\'s intuitive.

 

[rbowman]

On 08/12/2022 09:47 PM, Don Y wrote:

On 8/12/2022 8:04 PM, rbowman wrote:
On 08/12/2022 06:40 PM, Les Cargill wrote:
rbowman wrote:

Cars have the same problem. If a budding hotrodder gets his hands on a
10 year old Civic, there isn\'t much he can do.

They do ever so much, though. Check out the Regular Cars channel on
YouTube. People will add boost, redo the suspension, lots of stuff. Even
replace the ECM or \"tune\" them. It\'s no longer \"add a Cherry Bomb and
spoilers.\"

Coilovers and remapping or a new chip are common. Adding a blower
and/or nitrous , changing cams, flowing the heads and so forth may be
a little past \'budding\'. A blower means you\'d better do something
about fuel delivery too.

A wise man once said \'The only substitute for cubic inches is cubic
money\'. Apparently some people have cubic money. I forget what the
donor vehicle was but it started life as a FWD and was converted to
RWD since drifting a FWD isn\'t too impressive.

*Lots* of people have money -- but little/no skill/desire to get their
hands
dirty.

Lots of people have skill -- but no money! :

That\'s the story of my teenage years. Big ideas, empty pockets. It did
lead to some interesting projects. I had a \'60 Plymouth with an ailing
TorqueFlite, so I replaced it with a manual. Of course that meant
fabbing a hydraulic clutch and a new drive shaft. That accomplished life
was good until a state trooper asked me to demonstrate how well the
parking brake worked. The TorqueFlite had a drum brake on the tailshaft
for a parking brake and that was long gone. Next project, hunt up a rear
axle with a parking brake, slip that in, and fab an actuator.

 

[rbowman]

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.

 

[Don Y]

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.

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.

You might look into Limbo to see how flexible it is in meeting your
goals and how easily you can port the VM to a browser (there was a
port some years back). It\'s a relatively small, well-defined machine
(I host my applets with a bastardized version to more seemlessly
support distributed processing)

[A huge advantage is that the platform is open so you\'re not tied
to a vendor\'s whims as to how they want to redirect its focus]

 

[Don Y]

On 8/13/2022 8:25 AM, rbowman wrote:

On 08/12/2022 09:47 PM, Don Y wrote:
On 8/12/2022 8:04 PM, rbowman wrote:
On 08/12/2022 06:40 PM, Les Cargill wrote:
rbowman wrote:

Cars have the same problem. If a budding hotrodder gets his hands on a
10 year old Civic, there isn\'t much he can do.

They do ever so much, though. Check out the Regular Cars channel on
YouTube. People will add boost, redo the suspension, lots of stuff. Even
replace the ECM or \"tune\" them. It\'s no longer \"add a Cherry Bomb and
spoilers.\"

Coilovers and remapping or a new chip are common. Adding a blower
and/or nitrous , changing cams, flowing the heads and so forth may be
a little past \'budding\'. A blower means you\'d better do something
about fuel delivery too.

A wise man once said \'The only substitute for cubic inches is cubic
money\'. Apparently some people have cubic money. I forget what the
donor vehicle was but it started life as a FWD and was converted to
RWD since drifting a FWD isn\'t too impressive.

*Lots* of people have money -- but little/no skill/desire to get their
hands
dirty.

Lots of people have skill -- but no money! :

That\'s the story of my teenage years. Big ideas, empty pockets.

True of many people, even later in life. By the time you get to the
point where you have money and \"spare time\", you start wondering if you
have *enough* time (left) to make it worthwhile! :<

It did lead to
some interesting projects. I had a \'60 Plymouth with an ailing TorqueFlite, so
I replaced it with a manual. Of course that meant fabbing a hydraulic clutch
and a new drive shaft. That accomplished life was good until a state trooper
asked me to demonstrate how well the parking brake worked. The TorqueFlite had
a drum brake on the tailshaft for a parking brake and that was long gone. Next
project, hunt up a rear axle with a parking brake, slip that in, and fab an
actuator.

I wasn\'t interested in cars as a teenager. I was away from home, living in
a city, when I achieved driving age. So, no opportunities for a vehicle.
Nor a place to store/work on one (living in dorms/apartments).

I built a CDI for my family\'s vehicle but, other than testing it, dad wasn\'t
keen on having something between the points and coil that he didn\'t grok.
(a shame as it was really well executed and packaged in a EMI/RFI-sealed
box).

It\'s only later in life that I\'ve taken an interest in the combustion process
and what you could do (electronics and algorithms) to play with that to
suit your particular needs. And, as it\'s a black box, no one (gummit) would
be the wiser to any changes you\'d made that might not quite be kosher (cuz
you surely aren\'t going to put a big switch on the dash that says
\"street legal\" vs. \"performance optimized\" :> )

It\'s particularly interesting when you see the folks with money just
*buying* solutions; how original/innovative is that?? Why not just
compare bank statements and skip all the extra effort?!

 

[Don Y]

On 8/13/2022 11:05 AM, Don Y wrote:

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.

You might look into Limbo to see how flexible it is in meeting your
goals and how easily you can port the VM to a browser (there was a
port some years back). It\'s a relatively small, well-defined machine
(I host my applets with a bastardized version to more seemlessly
support distributed processing)

[A huge advantage is that the platform is open so you\'re not tied
to a vendor\'s whims as to how they want to redirect its focus]

<https://www.vitanuova.com/inferno/>

Apologies, Limbo is the (a) programming language supported by the
Inferno OS.

Note the IE plugin referenced (though this is really OLD, now)

 

[Les Cargill]

rbowman wrote:

On 08/12/2022 06:40 PM, Les Cargill wrote:
rbowman wrote:
On 07/30/2022 04:09 PM, Klaus Vestergaard Kragelund wrote:
On 27/07/2022 04.10, bitrex wrote:
On 7/26/2022 10:06 PM, Rich S wrote:
On Tuesday, July 26, 2022 at 6:38:36 PM UTC, John Larkin wrote:
On Tue, 26 Jul 2022 14:11:00 -0400, bitrex <us...@example.net
wrote:

On 7/26/2022 1:43 PM, John Larkin wrote:

https://www.studyfinds.org/fear-for-safety-every-day/

What\'s wrong with kids these days? Most have been super-protected
children but are afraid of life.

Engineers have to THINK, blow things up, take calculated risks.
Fear
warps prudent judgement.

I\'ve had interns that were afraid to touch a board powered from 5
volts, or handle a 12 volt battery. And wanted eye protection and
masks for everything. And who wouldn\'t crank up a power supply
to see
how much an electrolytic cap would leak past abs max voltage
rating.

I guess you get what you pay for
Interns are cheap and most don\'t last long.

Maybe during the interview, you ask them to
\"taste\" the top of an 9V battery. If they refuse,
or they do but get really upset  then don\'t hire
  them. :0)

I think getting shocked, blowing fuses, etc,
were a rite of passage for young experimenter.
Getting of visceral sense of energy, feel what is electricity.
But in today\'s highly safety-conscious society we mustn\'t
say such things  :-X


Pretty sure I recall people here complaining more kids were going into
software than hardware these days.

Might have something to do with that nobody asks you to suck on a 9
volt to get your first job in that field. And that first job usually
pays way better, too.


The engineers graduating predominately in software engineering, and
Hardware is becoming extinct:

Engineers on the brink of extinction threaten entire tech ecosystems:

https://www.theregister.com/2022/07/18/electrical_engineers_extinction/

I think the article has a valid point. I\'ve got hopes for the maker
culture but I don\'t know how many participate. Our new library has a
nicely equipped makerspace with several printers, scanners, laser
cutters and so forth. I should snoop around and see how much it is
being used. I\'ll confess that with ebooks I don\'t physically visit the
library often.

Cars have the same problem. If a budding hotrodder gets his hands on a
10 year old Civic, there isn\'t much he can do.

They do ever so much, though. Check out the Regular Cars channel on
YouTube. People will add boost, redo the suspension, lots of stuff. Even
replace the ECM or \"tune\" them. It\'s no longer \"add a Cherry Bomb and
spoilers.\"

Coilovers and remapping or a new chip are common. Adding a blower and/or
nitrous , changing cams, flowing the heads and so forth may be a little
past \'budding\'.

Just a little

A blower means you\'d better do something about fuel
delivery too.

That doesn\'t get mentioned much but yeah.

A wise man once said \'The only substitute for cubic inches is cubic
money\'.

Although there are actually cheap versions of most of these things.

> Apparently some people have cubic money.

Apparently.

I forget what the
donor vehicle was but it started life as a FWD and was converted to RWD
since drifting a FWD isn\'t too impressive.

I was surprised to find TRD has some nice Yaris goodies. Turns out the
Yaris (Vitz) is very popular for club racing in Japan.

--
Les Cargill

 

[Les Cargill]

Don Y wrote:

On 8/12/2022 5:52 PM, Les Cargill wrote:
Don Y wrote:
snip
Lots of reasons. These days it\'s harder to find people who
can spin boards for one. Never mind you can do it by mail.

But, they will likely have to develop (design, layout, fabricate, test)
a daughter-board of some sort to bridge the gap between COTS module and
their particular needs.  Or, piece (kludge) together a bunch of modules
in the hope that they can get close to what they need.

That\'s not as true as it once was. Depends.

It\'s also why productivity varies so much between application
level, system level, OS level and RT -- because of the relative
lacks of specific skills to address those ever demanding
\"markets\".

I think more is made of this than there really should be. It\'s
all one big thing. But there\'s money to be made in C# and those
guys aren\'t gonna be comfortable writing drivers after a while.

There\'s a huge difference between writing an application, an OS,
drivers, etc.  Real-time constraints act as a *multiplier* on that.
And, safety/reliability a further multiplier.

I don\'t see it as all that different because that\'s my bias. An
application is constructing some big ole data structure then writing an
interpreter for said data structure. Kernels are much the same.

When you look at big projects, productivity falls dramatically
as the complexity increases (app->driver->os, etc.)

But that\'s because human communication only goes so far.

But people like things they can see, even if that\'s an illusion.
The best computer is the one you don\'t even know is there until it
stops working.

And, why so many folks sit down and write code without having any formal
documents to describe WHAT the code must do and the criteria against
which it will be tested/qualified!  <rolls eyes

If you start with the test harness you get more done. Once you have
the prototype up, then write the documents. You\'ll simply know more that
way.

I approach it from the top, down.  Figure out what the *requirements*
are (how can you design a test harness if you don\'t know what you\'ll be
testing or the criteria that will be important?).

\"I\'m making an <x>. It uses interfaces <y,z...>.\" That\'s how you know.

You get a prototype up to basically working, then you pretty much know
the requirements.

Then you go to lunch. Because it didn\'t take long... there will
still be a lot of details.

Once you know the requirements, a \"programmer\" can do the implementation
(all of the design is codified in the requirements document).

If you write an actual *manual* as your requirements document, then you
already know all of the operating conditions, error conditions, messages,
etc.  There\'s no significant thinking required thereafter.

Another great approach.
<snip>

These days? It all comes out in the wash. I haven\'t been compute bound
in a couple decades.

You\'ve been blessed.  My career has consisted of designing hardware
that can just barely meet the needs of the product and having to
squeeze every bit of performance from it.  (because we\'re trying to
keep product cost/complexity to a minimum)

That\'s a dangerous place.

I had an argument with an employer years ago because I put a dozen
16bit counters in my design when *he* thought I could just implement
the high-order byte (for 8 of them) in software (IRQ, highbyte++, RETI).

Because that\'s what would be the norm in the markets in which we operated.

Without batting an eyelash, I told him that it would require 15% of
real-time just to process those IRQ\'s.  CONTINUOUSLY (as the counters
had to be running in order to detect events of interest based on
changes in frequencies)  15% of the product \"spent\" to save eight 8-bit
counters.

Nicely put - at least you could quantify the costs.

[of *course* I had already done the math, that\'s called engineering!
a \"programmer\" would have just written the code and wondered why
the system couldn\'t meet it\'s performance goals]

The final product often ran at 100% of real-time as it had to react to the
actions of the user; you can\'t limit how quickly a user drags a barcode
label across a photodiode (no, you can\'t put a \"barcode reader\" in the
design as that costs recurring dollars!)

I\'m familiar.

<snip>

--
Les Cargill

 

[Les Cargill]

rbowman wrote:

On 08/12/2022 06:52 PM, Les Cargill wrote:
\"CS\" CS is math. Computer engineering is different. It\'s
library science plus EE plus computation theory. Throw in
project management.

That has amused me at times. I\'m not particularly good at math but like
to think I have passable programming skills. I should say logic skills.
I\'ve worked with relay logic, fluidics, TTL/CMOS, and processors. The
logic stays the same. I know about Boolean algebra, DeMorgan\'s theorems,
and so forth but I\'ve seldom made use of formal logic. It\'s intuitive.

CS math isn\'t particularly \"math\" math. It\'s a few theorems and
then complexity analysis ( big O ).

It\'s all but disjoint from programming, which is really mainly
avoiding the nasty sharp edges.

--
Les Cargill

 

[Don Y]

On 8/13/2022 4:32 PM, Les Cargill wrote:

Don Y wrote:
On 8/12/2022 5:52 PM, Les Cargill wrote:
Don Y wrote:
snip
Lots of reasons. These days it\'s harder to find people who
can spin boards for one. Never mind you can do it by mail.

But, they will likely have to develop (design, layout, fabricate, test)
a daughter-board of some sort to bridge the gap between COTS module and
their particular needs. Or, piece (kludge) together a bunch of modules
in the hope that they can get close to what they need.

That\'s not as true as it once was. Depends.

If you get into the \"let\'s add a module for...\" mode, then your
costs goes up pretty quick. Only makes sense for small
quantities. And, you are now dependant on lots of other
vendors (with well-chosen *components*, you can find alternates
with drop-in replacements; not so as you add value -- firmware -- in
those components)

It\'s also why productivity varies so much between application
level, system level, OS level and RT -- because of the relative
lacks of specific skills to address those ever demanding
\"markets\".

I think more is made of this than there really should be. It\'s
all one big thing. But there\'s money to be made in C# and those
guys aren\'t gonna be comfortable writing drivers after a while.

There\'s a huge difference between writing an application, an OS,
drivers, etc. Real-time constraints act as a *multiplier* on that.
And, safety/reliability a further multiplier.

I don\'t see it as all that different because that\'s my bias. An
application is constructing some big ole data structure then writing an
interpreter for said data structure. Kernels are much the same.

Performance of a kernel affects every job running on the machine.
You write a sloppy app? <shrug> YOUR app sucks -- but no one
else\'s.

If you have a simple kernel, then it need not be efficient as it
doesn\'t \"do much\". But, the more you do, the more your implementation
affects overall performance. If faulting in a page is expensive,
then apps won\'t want to incur that cost and will try to wire-down
everything at the start. Of course, not possible for everyone to
do so without running out of resources. And, the poor folks who
either didn\'t know they *could* do that (or, felt responsible enough
NOT to impose their greed on others) end up taking the bigger hits.

When you look at big projects, productivity falls dramatically
as the complexity increases (app->driver->os, etc.)

But that\'s because human communication only goes so far.

Communication also happens *in* the \"system\". What happens if THIS
ftn invocation doesn\'t happen (client/server is offline, crashed,
busy, etc.)? How do we handle that case locally? Is there a way
to recover? Or, do we just abend?

But people like things they can see, even if that\'s an illusion.
The best computer is the one you don\'t even know is there until it
stops working.

And, why so many folks sit down and write code without having any formal
documents to describe WHAT the code must do and the criteria against
which it will be tested/qualified! <rolls eyes

If you start with the test harness you get more done. Once you have the
prototype up, then write the documents. You\'ll simply know more that
way.

I approach it from the top, down. Figure out what the *requirements*
are (how can you design a test harness if you don\'t know what you\'ll be
testing or the criteria that will be important?).

\"I\'m making an <x>. It uses interfaces <y,z...>.\" That\'s how you know.

How do you know it will use those i/fs? What if there are no existing
APIs to draw upon (you\'re making a motor controller and have never made one
before; you\'re measuring positions of an LVDT instrumented actuator; you\'re...)

When you\'r3e making *things*, you are often dealing with sensors and mechanisms
that are novel to a particular application...

You get a prototype up to basically working, then you pretty much know the
requirements.

Then you go to lunch. Because it didn\'t take long... there will
still be a lot of details.

Once you know the requirements, a \"programmer\" can do the implementation
(all of the design is codified in the requirements document).

If you write an actual *manual* as your requirements document, then you
already know all of the operating conditions, error conditions, messages,
etc. There\'s no significant thinking required thereafter.

Another great approach.
snip

These days? It all comes out in the wash. I haven\'t been compute bound in a
couple decades.

You\'ve been blessed. My career has consisted of designing hardware
that can just barely meet the needs of the product and having to
squeeze every bit of performance from it. (because we\'re trying to
keep product cost/complexity to a minimum)

That\'s a dangerous place.

It\'s a THRILLING place! It forces you to really put forth your best effort.
And, causes you to think of what you *really* want to do -- instead of just
hammering out a schematic and a bunch of code.

I suspect most \"programmers\" can\'t tell you how much stack is allocated
for their code. And, if multi-threaded, how much for EACH thread? And,
is there any reason why it\'s the same for each??

I, OTOH, can tell you the exact circumstances that will cause each thread to
reach it\'s peak stack penetration -- why allocate a byte more than that?!

In older designs, it was not uncommon to share the memory used by individual
\"variables\". I.e., if two \"consumers\" will never execute simultaneously,
then the memory/variables that each uses to be reused by the other.

Or, make hackish optimizations (24b floats).

I had an argument with an employer years ago because I put a dozen
16bit counters in my design when *he* thought I could just implement
the high-order byte (for 8 of them) in software (IRQ, highbyte++, RETI).

Because that\'s what would be the norm in the markets in which we operated.

Without batting an eyelash, I told him that it would require 15% of
real-time just to process those IRQ\'s. CONTINUOUSLY (as the counters
had to be running in order to detect events of interest based on
changes in frequencies) 15% of the product \"spent\" to save eight 8-bit
counters.

Nicely put - at least you could quantify the costs.

Don\'t you quantify the load you\'re going to put on a power supply before
you design the power supply? It\'s called *design* not \"hacking\".

[of *course* I had already done the math, that\'s called engineering!
a \"programmer\" would have just written the code and wondered why
the system couldn\'t meet it\'s performance goals]

The final product often ran at 100% of real-time as it had to react to the
actions of the user; you can\'t limit how quickly a user drags a barcode
label across a photodiode (no, you can\'t put a \"barcode reader\" in the
design as that costs recurring dollars!)

I\'m familiar.

It got to be a favorite exercise to see how quickly and *continuously* you
could swipe a barcode label across the sensor to see if the code would crash,
misread, etc. The specification was for 100 inches per second (which really
isn\'t that fast if you are deliberately trying to *be* fast) which would
generate edges/events at ~15KHz. When an opcode fetch takes O(1us), you
quickly run out of instructions between events!

[Of course, everything ground to a halt during such abuse -- but, picked up
where it left off as soon as your arm got tired! :> ]

 

[Don Y]

On 8/12/2022 8:49 PM, rbowman wrote:

On 08/12/2022 06:52 PM, Les Cargill wrote:
\"CS\" CS is math. Computer engineering is different. It\'s
library science plus EE plus computation theory. Throw in
project management.

That has amused me at times. I\'m not particularly good at math but like to
think I have passable programming skills. I should say logic skills. I\'ve
worked with relay logic, fluidics, TTL/CMOS, and processors. The logic stays
the same. I know about Boolean algebra, DeMorgan\'s theorems, and so forth but
I\'ve seldom made use of formal logic. It\'s intuitive.

People are easily confused by faulty logic. Exercises like nonsense
syllogisms are a great way to refine how you see logical deduction
without the \"assumptions\" that you may have baked into certain
\"truths\".

Likewise, understanding how you can \"mechanically\" transform between
implication, converse, inverse, contrapositive, etc. and what those
transforms do to the logic represented.

If you are pregnant, then you are a female. (implication)
If you are a female, then you are pregnant. (converse)
If you are not pregnant, then you are not a female. (inverse)
If you are not female, then you are not pregnant. (contrapositive)

Clearly, the contrapositive and implication are logically equivalent.
Knowing this can help you express ideas in better forms.

[One of my TA\'s was working on \"smart DB queries\"; rewriting them
in ways that exploited knowledge that the data embodied but that the
querant hadn\'t leveraged (e.g., if looking for pregnant people in
the data, then don\'t bother looking at the non-females!)]

When you teach software engineering alongside a traditionally hardware
curriculum (\"classic EE\"), it\'s a lot easier to see the parallels
(duality) between the two. And, understand their root causes, etc.

E.g., implication tables need not be the sole use of hardware design.
Ditto Karnaugh maps, DFA, etc. Hazards, deadlock, metastability, etc.
all have software equivalents. The same design techniques can be
applied in each application domain.

[VHDL/Verilog make this painfully obvious!]

Once you start seeing things in this way, a lot of the things that
happen \"under the hood\" become intuitive. E.g., write a logical
expression in the form that is most easy for a human to understand;
don\'t try to \"optimize\" it -- because a compiler can apply the above
techniques to MECHANICALLY and RELIABLY optimize it for you! Why
are you wasting your time HOPING to do it \"better\" and obscuring the
intent in the process?

You wouldn\'t ALWAYS draw a NAND gate as an AND with inverted output,
would you?