Yeah. Like I'd ever be caught DEAD or ALIVE in Arizona. Life is too short for that.

Can anyone here name three products which are legal in the USA and do _not_ "[compete] or is intended to compete with any product or service sold, offered, or otherwise provided by Amazon (or intended to be sold, offered, or otherwise provided by Amazon in the future)"?

Can anyone identify a product or service that Amazon doesn't sell or provide?

Job prospects are going to be few and far between if you leave Amazon.

That would explain the quality of some comments...

There are some owner operators as described, but most are beholden.

The problem with swapping drivers has to do with hours of service requirements. A bit too much detail to get into right now, unfortunately.

I should actually correct myself slightly: Wal-Mart (and others) have some in house drivers and some outsourced.

BTW, in discussions of the transport industry, don't get distracted/lied to by the companies. Some drivers think they are owner operators, when in practice, they aren't. They will lease/buy a truck from (as an example, all of the bigs do this) Schneider. As part of the lease terms, they can only accept loads from Schneider. It should be obvious that the 'owner' is an employee who has assumed much of the risk that the company would usually take on.

ShanghaiBill has a decent reply, but he misses a point: if the automated truck is cheaper, the big companies will drive that change in a heartbeat. The trick is that someone has to be convinced that they will be cheaper. They are unlikely to automatically accept that an automated truck is safer, faster, etc. One area where they are likely to be impressed is the possibility of 24 hour operations, rather than the 10 hour per day (rough) limits of human operated trucks. In addition to (possibly) being cheaper, this will allow faster shipments for more mundane goods (there are already plenty of ways to have fast shipping, but it is cost prohibitive to do for everything) which would offer them a competitive advantage. I suspect this last point will be the thin edge of the wedge.

The different flow of execution triggered by an overflow trap should almost always be a simple call to "abort()". At this point, your program has already failed and should be stopped.

I disagree with your premise. Garbage input values should be checked and rejected in software before the overflow ever occurs. The hardware overflow check should be a last resort to enforce this at every instruction step, and in the worst case it converts privilege exploits into less serious DOS attacks.

Allowing "garbage output" as you propose just creates more opportunities for attacks when that output gets consumed somewhere.

Most large companies outsource their transport to JB Hunt, Schneider, etc. Sure, the big letters say 'WalMart', but in smaller, DOT minimum sized font, it often has another name.

On an X86, "V".

Not that checking it after every add instruction is really that practical. It would be better to have trapping and non-trapping versions of integer arithmetic, and to have languages with semantics which expose that choice to the programmer.

It save data so your Chrome browsing can be analyzed.