Code analysis from the Toyota sudden acceleration case: http://www.viva64.com/en/a/0083/ If the code is as horrible as described in the article, and can bug out during normal operation, it is not too far of a stretch to assume that feeding it noise on the CAN bus will induce unwanted behavior.
Also, with dynamic brake control where brake pressure is individually adjusted to maximise grip during cornering/braking (trail braking), a poorly designed brake controller may also have issues and decrease brake pressure in unwanted ways when it is being fed crap CAN frames.
Note that a CAN frame only has 15 bits of CRC, making it feasible to get a false positive on the CRC check on a 500Kbit bus with lots of traffic, thus having random data frames enter the controller code.
Those are my arguments. If you do not agree, I think we would all appreciate if you provide more counter arguments than "nope. Try again.".
So the RF interference takes out the CAN bus, which runs communications between the various control units in the vehicle. This is a common problem in electrical vehicles, where the high power/current lines must be routed separately from the CAN bus wires.
There are two problems with this solution
1. Older vehicles are unaffected Old cars, especially those with carburetors, are unaffected since they don't have any data buses that can pickup the interference.
2. The CAN bus carries safety critical information. Corrupted data packets, such as by-wire throttle position information, can cause brake failures and/or uncontrolled acceleration when the ECU/TCU bombs out due to noise on the bus. Airbags may also deploy, although that is a bit more far-fetched.
Worth every one of the $800 I plunked down on it.
In the beginning I didn't know what to do with all the real estate, but these days I cannot live without the massive scrreen area.
More specifically, it is up to the judicial branch of the Swedish government to decide. The cabinet and parliament has very little say in how the authorities carry out the law.
The few times they have tried, the Swedish press goes berserk and accuses them of minister ruling (ministerstyre), which is forbidden.
For the last year, I've participated/headed our company's effort in replacing our existing python code hell with a transactional framework (in C++ with services in any language) that provides fault tolerance, easy deployment, secured event collection (because they provide billing info), load balancing, speed and scalability.
It is well documented, has example code and test cases, and it received good feedback from the rest of the devs.
I've starting to push it internally for an open source release since I thought that a framework that focuses on fault tolerance, transactional routing and scalability and other ops-oriented problems would be a good thing for the world.
Ironically enough, one of the main reasons for developing our own framework was that clobbering together ACE + X + Y + whatever would yield a framework hybrid that seemed to messy for us to rely on. We would not know the code base, be (initially) dependent on community provided bug fixes and we would still have to write a ton of glue to get everything off the ground. So after a bit of soul searching regarding Not Invented Here, we decided to strike out on our own.
However, after reading TFA, I realise that I may actually be Satan himself planning to release a new and improved rider of the apocalypse on the world.
Why is this wrong? The company is bogged down by a crappy framework with huge performance issues and unclear API boundaries. Our new framework is 20-1000 times faster, provides a clearly defined API, and is asked for by other dev teams.
Rolling our own framework gave us a single integrated (but not monolithic) codebase where the developer can log, store events, send transactions, do threads, manage signals, access DB backends and read configuration data using one API.
The framework does take ownership of the main loop, and you do need to write plugins for your services. You can, however, register your own descriptors with the poll dispatcher in order to get a callback whenever traffic happens on it. We provide a basic worker thread model, but you are free to launch as many additional threads as you want.
Letting 'what' take priority over the 'how' saves you development money for exactly one release.
You will be in deep, deep yoghurt when you start planning on 2.0 of the 'what' project and realise that the previous project team just clobbered together whatever they could find in order to pass the test suite, resulting in the opposite of reusable code.
The life cycle does not end with the initial release.
This seems to be an MMS going out to the handset with a link to a web/wap site embedded in the message. Clicking this link will setup a GPRS connection to the site, which will flash the message and delete it.
This is stock 3GPP usage with no protocol updates necessary.
Please note, however, that it is not a text message. The sender does not use SMPP to push out a SMS message (max 160 byte) through the SMSC. This will cost both the message sender and receiver a lot more traffic than a regular SMS./M
Basically, companies such as RH rely on their branding to give them an edge in the sell vs. gratis decision.
How does your client feel that the code is GPLed?
Do they consider the risk of you letting their competitors download the code for free from your website? In effect, your client's competitors will have their development paid for by your client.
Just trying to sync(2) up the commercial world with the open source one.
Stallman explicitly states that he things that open source should be sold for money.
What would stop me from purchasing a copy of the software for sale, change a byte or two, call it derivate work, and sell it for a lower price?
Sorry forr n00bness here, but I've never seen a good answer for this one.
Slashdot Mirror
Since you seem a bit combative about this.
Code analysis from the Toyota sudden acceleration case: http://www.viva64.com/en/a/0083/
If the code is as horrible as described in the article, and can bug out during normal operation, it is not too far of a stretch to assume that feeding it noise on the CAN bus will induce unwanted behavior.
Also, with dynamic brake control where brake pressure is individually adjusted to maximise grip during cornering/braking (trail braking), a poorly designed brake controller may also have issues and decrease brake pressure in unwanted ways when it is being fed crap CAN frames.
Note that a CAN frame only has 15 bits of CRC, making it feasible to get a false positive on the CRC check on a 500Kbit bus with lots of traffic, thus having random data frames enter the controller code.
Those are my arguments. If you do not agree, I think we would all appreciate if you provide more counter arguments than "nope. Try again.".
So the RF interference takes out the CAN bus, which runs communications between the various control units in the vehicle. This is a common problem in electrical vehicles, where the high power/current lines must be routed separately from the CAN bus wires.
There are two problems with this solution
1. Older vehicles are unaffected
Old cars, especially those with carburetors, are unaffected since they don't have any data buses that can pickup the interference.
2. The CAN bus carries safety critical information.
Corrupted data packets, such as by-wire throttle position information, can cause brake failures and/or uncontrolled acceleration when the ECU/TCU bombs out due to noise on the bus. Airbags may also deploy, although that is a bit more far-fetched.
Worth every one of the $800 I plunked down on it. In the beginning I didn't know what to do with all the real estate, but these days I cannot live without the massive scrreen area.
More specifically, it is up to the judicial branch of the Swedish government to decide. The cabinet and parliament has very little say in how the authorities carry out the law. The few times they have tried, the Swedish press goes berserk and accuses them of minister ruling (ministerstyre), which is forbidden.
For the last year, I've participated/headed our company's effort in replacing our existing python code hell with a transactional framework (in C++ with services in any language) that provides fault tolerance, easy deployment, secured event collection (because they provide billing info), load balancing, speed and scalability.
It is well documented, has example code and test cases, and it received good feedback from the rest of the devs.
I've starting to push it internally for an open source release since I thought that a framework that focuses on fault tolerance, transactional routing and scalability and other ops-oriented problems would be a good thing for the world.
Ironically enough, one of the main reasons for developing our own framework was that clobbering together ACE + X + Y + whatever would yield a framework hybrid that seemed to messy for us to rely on. We would not know the code base, be (initially) dependent on community provided bug fixes and we would still have to write a ton of glue to get everything off the ground. So after a bit of soul searching regarding Not Invented Here, we decided to strike out on our own.
However, after reading TFA, I realise that I may actually be Satan himself planning to release a new and improved rider of the apocalypse on the world.
Why is this wrong? The company is bogged down by a crappy framework with huge performance issues and unclear API boundaries. Our new framework is 20-1000 times faster, provides a clearly defined API, and is asked for by other dev teams.
Rolling our own framework gave us a single integrated (but not monolithic) codebase where the developer can log, store events, send transactions, do threads, manage signals, access DB backends and read configuration data using one API.
The framework does take ownership of the main loop, and you do need to write plugins for your services. You can, however, register your own descriptors with the poll dispatcher in order to get a callback whenever traffic happens on it. We provide a basic worker thread model, but you are free to launch as many additional threads as you want.
What did I do wrong? Should I be shot?
Letting 'what' take priority over the 'how' saves you development money for exactly one release. You will be in deep, deep yoghurt when you start planning on 2.0 of the 'what' project and realise that the previous project team just clobbered together whatever they could find in order to pass the test suite, resulting in the opposite of reusable code. The life cycle does not end with the initial release.
I have the following sticker on top of my display: "Make it work before you make it fast!" Saved me many hours of work.
This seems to be an MMS going out to the handset with a link to a web/wap site embedded in the message. Clicking this link will setup a GPRS connection to the site, which will flash the message and delete it. This is stock 3GPP usage with no protocol updates necessary. Please note, however, that it is not a text message. The sender does not use SMPP to push out a SMS message (max 160 byte) through the SMSC. This will cost both the message sender and receiver a lot more traffic than a regular SMS. /M
Ah. Tnx.
Basically, companies such as RH rely on their branding to give them an edge in the sell vs. gratis decision.
How does your client feel that the code is GPLed?
Do they consider the risk of you letting their competitors download the code for free from your website? In effect, your client's competitors will have their development paid for by your client.
Just trying to sync(2) up the commercial world with the open source one.
So where is the incentive for anyone to sell an open source product at all in order to recoup development costs?
It seems like you will sell very few copies before the (minimal) derivate work shows up for free.
Stallman explicitly states that he things that open source should be sold for money. What would stop me from purchasing a copy of the software for sale, change a byte or two, call it derivate work, and sell it for a lower price? Sorry forr n00bness here, but I've never seen a good answer for this one.