There is no reason for the OOXML specification to use date formats based on the old .xls format. The issue about keeping bug for bug compatibility is about in-memory representation, the standard specifies on-disk representation. They do not have to be the same you know...

Microsoft have specified a new on-disk representation which continues to have a madness just to simplify their load/save implementation. The fact that it is due to compatibility with an ancient bug from a competitor is completely irrelevant. They could have specified the OOXML standard to be clean and dealt with any issues in their save/load code, or elsewhere in excel.

The different impedance is sometime enough to trip the collision detection circuitry. Also the drivers are actually low impedance as they deliberately drive current into the cable , and have high impedance detectors.

It's all about the collision detecttion..., I have seen it work though - but you've got to be careful or lucky.

Except that doesn't account for having a method (destructor) which will be called when your variable goes out of scope.

Then you have generic's on top of that.

And in c++0x, auto, lambda and rvalue refs. There a whole lot more to c++ than objects.

[Note: I program in both. & python & perl &......]

What did you investigate? What samba tuning parameters did you try?

Last year I had a very similiar problem, which actullay turned out to be network card driver issue. I upgraded from the stock debian stable kernel to one from testing and the problem went away.

My point is a single example without actually knowing what was investigated - is just a worthless anecdote.