Forgot your password?
typodupeerror

Comment: Re:I hope Toyota doesn't write the software (Score 1) 51

by kybred (#47875095) Attached to: Toyota and Tesla May Work Together Again

The EE Times article is from 2013. Barr analyzed the source code and found numerous problems:

Having spent more than 18 months going in and out of the secure room to study Toyota's code, Michael Barr, CTO of the Barr Group, put together an 800-page report analyzing the 2005 Camry L4's software. On the witness stand, he walked a jury step by step through what the experts discovered in their source-code review. According to Barr's testimony, that review revealed:

        Software bugs that specifically can cause memory corruption

        Unmaintainable code complexity in Toyota's software

        A multifunction kitchen-sink Task X designed to execute everything from throttle control to cruise control and many of the fail-safes

        That all Task X functions, including fail-safes, are designed to run on the main CPU in the Camry's electronic control module

        That the brake override that is supposed to save the day when there is an unintended acceleration is also in Task X

        The use of an operating system in which there is no protection against hardware or software faults

        A number of other problems

Single bit flips can also be caused by memory corruption, not to mention tasks crashing.

Comment: Re:I hope Toyota doesn't write the software (Score 2) 51

by kybred (#47868837) Attached to: Toyota and Tesla May Work Together Again

Pretty sure those runaways were caused by morons who put their floormats over the accelerator, not software.

Pretty sure they weren't (at least, not all of them).

Having spent more than 18 months going in and out of the secure room to study Toyota's code, Michael Barr, CTO of the Barr Group, put together an 800-page report analyzing the 2005 Camry L4's software. On the witness stand, he walked a jury step by step through what the experts discovered in their source-code review.

...

Barr testified that the source-code review indicated "both that task could die by the memory corruption, and that also that one of side effects of that would be that this -- for example, that task died, that many of fail safes would be disabled." But is it possible to prove that the experts' discoveries in that cloak-and-dagger source-code room would manifest themselves in a moving vehicle? How do we know how a car might react to malfunctions or an outright failure in Task X?

...

However, we have confirmed in other vehicle testing that I'll talk about later, that if the incident begins with the peddle, [sic] brake peddle [sic] pressed at all, even lightly then the unintended acceleration will continue, potentially, forever unless the driver tries the risky thing of letting go of the brake while the car is driving away with him.

Comment: Not all states failed (Score 5, Interesting) 212

by kybred (#47737351) Attached to: Oregon Sues Oracle For "Abysmal" Healthcare Website

Here's a success story about Kentucky's Kynect Exchange.

They need not have worried. Over the past year, Kentucky’s health care website has proved to be a huge success. More than a half-million Kentucky residents have signed up for the Bluegrass State’s version of Obamacare. A majority of Kentuckians approve of it. That this has happened in a deeply red state is unexpected but hardly an accident.

Comment: Re:harmful constructs (Score 1) 159

by kybred (#45420179) Attached to: Red Hat Releases Ceylon Language 1.0.0

For some reason, I always hate it when people choose an explicit

if (boolean == true)

rather than just

if (boolean)

I'm glad those people have to hunt for extra bugs ;)

Absolutely! If you give the boolean variable a good name it makes the code read logically:

if (thing_is_valid)
{
        do_stuff();
}

Time sharing: The use of many people by the computer.

Working...