From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: "G.B." Newsgroups: comp.lang.ada Subject: Re: New IEEE Language Popularity Ratings Date: Thu, 11 Aug 2016 01:06:47 +0200 Organization: A noiseless patient Spider Message-ID: References: <31c22983-150c-4dab-abba-588e15f75914@googlegroups.com> <87y44514hl.fsf@jester.gateway.pace.com> <87twes1v4l.fsf@jester.gateway.pace.com> Reply-To: nonlegitur@futureapps.de Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Wed, 10 Aug 2016 23:06:48 -0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="efd71fd2928388fd9cdb67e851e8a993"; logging-data="16894"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/m+33/DC5/Ob+iMJ9DEOt6Hr0p/LW+PVE=" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 In-Reply-To: <87twes1v4l.fsf@jester.gateway.pace.com> X-Mozilla-News-Host: news://news.arcor.de Cancel-Lock: sha1:Ppavhm7SESs2AgpfR2/e2RFJUMo= Xref: news.eternal-september.org comp.lang.ada:31373 Date: 2016-08-11T01:06:47+02:00 List-Id: 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.