I was always under the impression with wifi that retransmissions were done at the link level. When you do a ping packets are often delayed for 100s of ms. indicating retransmits. I was also under the impression that wifi was all algibra being developed by the csiro to effectivly turn almost noise into some sort of coherent siginal. surely this packet level correction can be done with more buffering at an in between layer. Alternatively a transparent proxy at the ap. You wouldn't want it at the server as it would be sending redundent data over links that don't need it.

Is this possible? In the universe for FTL does all matter fly apart? Maybe we are going backwards and just think we are going forwards? How would we know?

This seems like the equivalent of taking someone to court to take your number out of the phone book when I they should have just asked for a silent number. You can't efficiently index something without taking a copy of it.

I'd say for me maybe 500k and less than 1M. from age 15 - 40 commercially, yeah the 30000 line monster Cobol projects written in a couple of months and debugged for much longer with a limit of 64k memory. I used to be able to keep that much in my head 20 years ago. Obviously IDE written code doesn't count. If it did then I'd count programs I've written that create code. An example is report programs I've written that generate pl/sql coded packages depending upon the selections used and other variables. Now my users are writing programs, scheduled daily and they don't even know how to code. Yeah, probably a million lines in a year. More and more every night without even lifting a finger.

I generally think in programming it's the exceptions that cause the problems. I usually only look at averages and maximums, however it must be said many performance problems are caused by a exponential increase in execution time with a linear increase in load/dataset size. I don't really know stats but it's pretty easy to see when this is the case. There are many things that stats will never predict, i.e. when you are going to hit a wall without an underlying knowledge of where the walls are and how close you are to them and what/how you move towards them. It's all pipes and data in the end. You should know what's going to break it (exceptions to your assumptions) and where your bottlenecks are, and what path is going to get followed in what situations. That can get tricky in database queries, say oracle, with stats determining your execution plan. How often does the full table scan in a loop seem to cause a query to never return? Google oracle stats execution plan. I guess it keeps DBAs in a job.

Isn't there a basic right to remain silent. He shouldn't have to tell anyone the password.