Surely this is just proof of gravity and relativity. The more persons in a queue with full trolleys the slower time moves for them due to the gravitational distortion of the trolleys and shopping mass?

"see the light" - you are making the assumption of it being something that casts light; I suspect Linus Torvalds judges on presented evidence and so far apparently judges the argument hasn't been carried.

Surely he sues them for breach of copyright as they clearly had no right to distribute his copyright work. He can after all show loss directly consequent of the copyright material being distributed.

But both should exist if the lines that mark interfaces are drawn in the right place.

Faster hardware tends to be the source of the problem. It makes people lazy because they don't have to attend to the details.

So it's about the worst cure that could be taken.

You presume that a month or twenty down the line the original author can still maintain it. Most crappy code that doesn't holds as true.

I agree from a different view that goes like this. Good programmers/software engineers are expensive so companies like to pay cheaper people. To enable use of cheaper people tools and processes are introduced.

One such tool is languages that have buckets of libraries or core tools that the new people merely have to extend or tweak.

Knuth is lucky that most things he needed didn't exist then so using libraries wasn't an option. If everything he needed already existed he'd have picked a different area to work in.

The code base I work on would be improved by a rewrite. But in doing so it would actually be a matter of putting more effort into using the libraries (they do too much manual string manipulation for example that could be done using existing library calls; it's Qt based stuff).

At the same time it would cut lines of application code and make seeing the algorithm easier. I've just swapped 2500 lines for 850 lines whilst increasing functionality.

Cost benefit wise it's impossible to say in advance was it worth it.

The real irritation in Britain with similar convictions (speed wise not video evidence wise) is bikers go to prison for sometimes a year to 18 months. But company directors who are responsible for those people who work for the company often get caught doing similar speeds in big cars but just get a fine and short ban.

Despite the simple math showing that the killing force and actual likelihood of incident in the first place (due to cross section and time in that zone) being way lower for the bike than car.

I'm not grumbling about the convictions (caught breaking the law and proven so equals conviction) merely the imbalance in consequence. I often think shouldn't the director go to prison longer as he wasn't only risking the physical result of his action but the livelihoods of all his employees (subverting their own defence lawyers arguments.)

The Bluetooth members meet 4 times (I think) per year at week long unplug fests where they all try their current and coming components against all other attendees to make sure they work together. They rotate through short time slots (almost like bluetooth channel hopping:-) to try and make sure every device meets every other.

They spend a lot of time often sending 5 or 6 teams with different items each to test. So if a claimed bluetooth device has problems the maker probably bought the cheap poor chip rather than marginally better component.

Price I think you'll find. It is only the last two years that the price on the bluetooth chip has been low enough for it to begin proliferation into low end (price wise) consumables.

Unless the mechanical flaw has it wedge open like the terrified owner of motorbike I once encountered who had survived the down hill of a Welsh mountain road with the throttle locked partially open.

Where as the multiple sensors for throttle position make it more reliable as two of the typically three can fail and it still operate correctly.

The cleanliness of electronic control can actually help and reduce risks in these kinds of places because the results of time and poor maintenance are more predictable.

I used to work for a automotive software company that does work for the likes of Ford, Mazda, Volvo and thy do pretty much test safety critical parts of the system as much as aviation.

The big element in the gap is aviation using formal methods for verification of the design.

And most of the good players have testing sufficiently automated and systems of design, change, test with reviews at every stage.

Testing typically covers functional unit testing, module testing, system testing. In several ways, on a simulator, on the real hardware being amongst them. Plus the code is usually subject to strict coding standards that would make most programmers weep about being able to express their individual creativity and other crap.

Then there is the extensive use of static analysis and code coverage to make sure that every line of code has been exercised with the tests and if not that review has signed off that it really really is an unreachable piece of code.

You don't move tool chains because by the time you have finally released you know the bugs and have worked around them.

Safety with software in cars amongst 5 car companies I've seen inside of is taken very very seriously. Remember too most of these people drive their own dog food and that includes taking their families in them. So if you trust your quality of work enough to trust your families lives to it good on you.

So I would certainly be taking the updates. That said I like that my motorbike runs on carb's and no ECUs.

Comments are good if they explain why a piece of none obvious code is there (relates to your need to meet performance). But primarily they are to me a way to highlight choices in the design/implementation of that code. You say "ignored this option because impossible". They are also useful for showing the way for which parts fulfil which requirements (provided you have such other documentation) or as requirements covering a portion of code in the absence of good separate requirements and design.

I'd agree with the go where the interest is, my thoughts were how I programmed at a younger age than that in a bit of machine code and then assembler and basic. But that was fine because it was my interest driving me (and trying to show off to my dad to whom it was all just as new that I could do it better).

Put simply you will never get them learning if they aren't doing things that interest them.

Once you have the subject you can choose a language appropriately (assembler, C, Java, Python and on and on). Best using the ones you know best really and just highlighting they have many choices out there to discover for themselves later.