Re: New IEEE Language Popularity Ratings

["G.B." <bauhaus@futureapps.invalid>]

On 10.08.16 17:50, Paul Rubin wrote:
>  Admittedly there's some low level
> realtime stuff in the devices too (RF protocols etc), but that part is
> usually done by the hardware manufacturer or some other specialized
> niche programmers.

Still the low level stuff's structure and dynamics had better be
understood by the glue coders building it into this electric kettle?

With the new fondness of collecting "big" data for statistical
analysis---reshaping legal ideas of privacy on the way---if a car's
embedded data collection system will be capable of transferring
real-time data (to the insurance company, to the traffic surveillance
organization, to some customer research agency, or to Central
Services, I'm not familiar with the specifics), then the more the
better. And it turns out that some encryption might be in
order(*). The question then becomes one of cost: comparing N powerful
embedded computers for scripting per car to adding M programming
effort to the production of some |sensors-collector-sender|.
I'm reminded of The Market's effect on clean Diesel in non-vans:
can we use a single core 16 bit µController, not a quad-core ARM,
please?

Anyway, a nice example of a real, real, real-time system,
showing when you cannot afford any non-predictable behavior
in time:

https://www.youtube.com/watch?v=Oym7B7YidKs

__
(*) Some LED light bulbs can be made to send bits coded above 60 Hz,
apparently when the buyer selects the low security profile.