Well, It would seem reasonable to argue that if the car is driving itself in fully autonomous mode
There is the rub. So far every automated vehicle such as Google's has to have a driver ready to take over when the vehicle AI can not deal with a situation. While the vehicle can handle most situations on a well scanned road there are many that it can not handle. The question is when will we get to fully autonomous cars. The current state of the art can not even recognize a traffic signal without having information on exactly where to look. Google does this by pre-scanning the road and having a human mark all the traffic lights and what they are associated with.
Be great for DUIs as well,
Not for a while, as currently, there has to be a diver in charge of the vehicle and ready to take over. Whether or not the driver did take over is irrelevant to the law. Someone still has to have responsibility for the vehicle and one can not be drunk while doing it.
Lane following in good weather on well marked restricted entry freeways is pretty simple these days. Please note all the qualifications in that statement.
If you pull the plug on a whole product line just because a few developers made a silly message, then you are probably doing it wrong.
I never said any such thing. If an entire product fails due to budget overruns caused by programmers writing a Easter Egg game instead of the product the programmers have a problem.
If you're sloppy in one you're likely sloppy elsewhere.
It is not about being sloppy. It is about being imperfect. No single programmer is perfect all the time. Which is why there are things like testing and code reviews. Code that has not been reviewed or tested is suspect.
The "many eyes" concept has repeatedly been proven wrong as people tend not to go looking for problems until one appears.
'Many eyes" fails due to the law of diminishing returns. It is much better for two different people to look at code than for only one person to do it. The problem is that ten people looking at the code is not much better than two. The issue is the same as in writing. The writer reads what he thought he wrote and not what he actually wrote.
You miss the point. If the Easter Egg code is poorly programmed it could cause problems. Since the Easter egg code is neither tested or reviewed by anyone other than the programmer it is quite possible it is poorly writen.
Lane following is one of the simplest things for vehicle technology to do. All it does is follows the lane lines and keeps a speed/ or minimum distance from the vehicle in front. I bet every time they had to change highways the driver took over. Also notice it was not raining heavily, snowing or recently snowed in the trip. Current technology has problems in those cases. Comparing lane following to autonomous driving is like comparing algebra to calculus.
like in VLC every Christmas time the cone gets a Santa hat
Then when a subsequent maintainer comes along finds the Santa hat graphic, and since it is not in the specs, removes it causing the software to crash the next Xmas there is a problem.
It could also be an indication of self centered attitude in that he would rather get his "mark" embedded in the system and leave the work to the other programmers. It could speak of an lower effort across the system if he expends all his energy on Easter eggs that he is interested in than the system that he is not interested in.
Put yourself in a project manager's shoes. What would you say if one of your programmers was working on a cool Easter Egg instead of being productive and working on the actual product? I wouldn't want to be the project manager who had to tell higher management that the product will be late but have some cool Easter Eggs.
So what if I could kill someone by editing the code in my xB? I could kill someone by working on my Tercel too.
The difference being that when you incorrectly modify the Tercel there is physical evidence of the tampering. With software changes it is quite possible that the code is unrecoverable and there may be no way to show tampering. The car maker then get left liable for the accident when it was actually caused by hacked code.
It is still just a bar code reader. What you do with the code after you get it is up to you. Most QR codes are scanned by smart phones that can also do things completely unrelated to QR codes like make phone calls. QR codes are useful because you probably already have the device to read them. Carrying a separate device to read QR codes would not be as popular.
Why use the button? Are you too lazy to use a smartphone app? Why use a smartphone app? Are you too lazy to use a website on a desktop? Why use a website? Are you too lazy to pick up a phone and call? Why pick up a phone and call? Are you too lazy to write an order and mail it? Why write and order and mail it? Are you too lazy to go out to a store and get it yourself? Why go to a store? Are you too lazy to make it yourself?
What one person calls lazy is what another person calls efficient. Everyone is not like you. Stop judging other people based on your own experiences. Their's have been different.
Slashdot Mirror
Well, It would seem reasonable to argue that if the car is driving itself in fully autonomous mode
There is the rub. So far every automated vehicle such as Google's has to have a driver ready to take over when the vehicle AI can not deal with a situation. While the vehicle can handle most situations on a well scanned road there are many that it can not handle. The question is when will we get to fully autonomous cars. The current state of the art can not even recognize a traffic signal without having information on exactly where to look. Google does this by pre-scanning the road and having a human mark all the traffic lights and what they are associated with.
Be great for DUIs as well,
Not for a while, as currently, there has to be a diver in charge of the vehicle and ready to take over. Whether or not the driver did take over is irrelevant to the law. Someone still has to have responsibility for the vehicle and one can not be drunk while doing it.
I live in a city and none of my commuter driving is like this.
Lane following in good weather on well marked restricted entry freeways is pretty simple these days. Please note all the qualifications in that statement.
If you pull the plug on a whole product line just because a few developers made a silly message, then you are probably doing it wrong.
I never said any such thing. If an entire product fails due to budget overruns caused by programmers writing a Easter Egg game instead of the product the programmers have a problem.
Which would increase the cost of roads and not work in construction areas.
If you're sloppy in one you're likely sloppy elsewhere.
It is not about being sloppy. It is about being imperfect. No single programmer is perfect all the time. Which is why there are things like testing and code reviews. Code that has not been reviewed or tested is suspect.
The "many eyes" concept has repeatedly been proven wrong as people tend not to go looking for problems until one appears.
'Many eyes" fails due to the law of diminishing returns. It is much better for two different people to look at code than for only one person to do it. The problem is that ten people looking at the code is not much better than two. The issue is the same as in writing. The writer reads what he thought he wrote and not what he actually wrote.
Your premise that everything in the code is somehow in a spec somewhere is ridiculous.
I guess you have never written mission critical software. Specs are very strict and all inclusive.
It breaks the definition of an Easter Egg if it is documented.
You miss the point. If the Easter Egg code is poorly programmed it could cause problems. Since the Easter egg code is neither tested or reviewed by anyone other than the programmer it is quite possible it is poorly writen.
Lane following is one of the simplest things for vehicle technology to do. All it does is follows the lane lines and keeps a speed/ or minimum distance from the vehicle in front. I bet every time they had to change highways the driver took over. Also notice it was not raining heavily, snowing or recently snowed in the trip. Current technology has problems in those cases. Comparing lane following to autonomous driving is like comparing algebra to calculus.
like in VLC every Christmas time the cone gets a Santa hat
Then when a subsequent maintainer comes along finds the Santa hat graphic, and since it is not in the specs, removes it causing the software to crash the next Xmas there is a problem.
Another is that the software that's full of "fun things" tends to be higher quality than the software that's "serious business".
Do you have any reference to back this up?
It could also be an indication of self centered attitude in that he would rather get his "mark" embedded in the system and leave the work to the other programmers. It could speak of an lower effort across the system if he expends all his energy on Easter eggs that he is interested in than the system that he is not interested in.
Put yourself in a project manager's shoes. What would you say if one of your programmers was working on a cool Easter Egg instead of being productive and working on the actual product? I wouldn't want to be the project manager who had to tell higher management that the product will be late but have some cool Easter Eggs.
If there is a fire involved and the memory chip melted there might be issues.
Try to recover code from a lump of melted plastic. Heat also effects memory cells.
So what if I could kill someone by editing the code in my xB? I could kill someone by working on my Tercel too.
The difference being that when you incorrectly modify the Tercel there is physical evidence of the tampering. With software changes it is quite possible that the code is unrecoverable and there may be no way to show tampering. The car maker then get left liable for the accident when it was actually caused by hacked code.
is a waste of the world's resources and generates extra CO2.
Now you are judging someone based on your definition of efficient.
I know you could do it by train, but that is less fun and probably more expensive.
Or you could take an aircraft and be there in under an hour.
Any remark about price difference is just guessing as there have been no prices set for travel by the airship.
It is still just a bar code reader. What you do with the code after you get it is up to you. Most QR codes are scanned by smart phones that can also do things completely unrelated to QR codes like make phone calls. QR codes are useful because you probably already have the device to read them. Carrying a separate device to read QR codes would not be as popular.
Microsoft has caved many times. Remember the browser wars and unbundling IE?
I guess you don't write real-time applications where garbage collection at the wrong time can be very bad.
Why use the button? Are you too lazy to use a smartphone app?
Why use a smartphone app? Are you too lazy to use a website on a desktop?
Why use a website? Are you too lazy to pick up a phone and call?
Why pick up a phone and call? Are you too lazy to write an order and mail it?
Why write and order and mail it? Are you too lazy to go out to a store and get it yourself?
Why go to a store? Are you too lazy to make it yourself?
What one person calls lazy is what another person calls efficient. Everyone is not like you. Stop judging other people based on your own experiences. Their's have been different.
As many have said, multiple button pushes will have no effect as a new order is placed only after the current order has been received.
Except that QR codes are read by a device that can to other thing as well. The CueCat was a one function device.