In my experience, the defense asked specific questions related to this exact topic and sought out jurors who agreed that police testimony is not guaranteed to be factual. I have to assume this is common. They had no problem filling the juror box with jurors approved by both sides.
I feel that many of the uber/lyft drivers are in this position. They squeeze some money out of the asset that they have, but in the long run I don't see how they come out ahead.
That being said, it would make sense to drive for Uber in some small subset of the population: if you enjoy driving and would otherwise just be out joyriding, might as well get paid. Or if you are a student with varying classwork loads or bored people who would rather be doing something than watching TV.
Slight tangent here, but this is intriguing to me - the concept of devs ignoring known bugs until they are found by testers. Do other devs struggle with this? Are there certain working conditions that foster this behavior?
Dropping a trailer vs waiting for it to be unloaded? I dunno. I agree with what your saying. Just moving stuff is obviously faster than waiting around for loading and unloading. At what point does the idle electric truck start to cost less than a simple trailer.
There's an "easy" solution to that too, you make it a flat bed electric self-driving trailer which takes a container similar to sea shipping containers on top.
Then you don't:
- have the unnecessary truck cab in front
- cost of the trailer being unused while loading / unloading
- potentially drastically change shipping containers received from over seas.
Agree. As a QNX user and later QNX employee, I really missed the messaging system when I had to go back to Linux. In fact, I spent time writing a QNX-like messaging library now used extensively in our application (at my current job). Although not optimal from a performance perspective, most of the messaging we have is small packets and infrequent sends. I feel that it has really accelerated our app development, and forced a similar design pattern for each thread or "service" within the application. The same result could be had with a library such as Nanomsg.
I spent a few years working on embedded keypad products. Often there is a hardware keypad scanner that takes care of much of the details, not allowing the programmer this level of control. Your driver configures the rows and columns (inputs and outputs), the scan rate, debounce time, etc, and the hardware will monitor for edge transitions, then perform a scan, capture the result in a register and assert an interrupt. It will likely have a double (or more) buffer mechanism to prevent dropped events due to software latency.
In low power/mobile situations this allows the host CPU to sleep as much as possible and even the scanner, which walks the rows (or cols) need not be running all the time.
While many SOCs have a integrated keypad interface, there are also keypad controller ICs (some GPIO expanders have the ability to double as keypad controllers) that free the programmer from having to manually implement the scanner logic. I suspect these types of chips would be found in a typical USB keyboard. Software may still have to deal with additional debouncing and ghost keys depending on the complexity of the IC.
Edit: I suppose one could configure the keypad controller to apply no debouncing and then perform a software debounce the way you describe.
Computer keyboards typically contain only one chip which has a combined USB-PS/2 port, scanner and a 8051 to glue things together. DIY keyboards normally just use any microcontroller with a built-in USB controller.
