You forgot the stage light effect. Mysteriously Apple give a free fix/service program for the 13" models but not the 15" models. Kind of sucks if you had a 15" model that started to go bad.
At this point that's more noise than signal. Not ideal for you but I can see the problem. For whatever reason you met the bar for requiring more validation. If they had let you in then another N'000 fake accounts would have also passed the automated system. Someone else would be posting here, Reddit or Twitter explaining how Facebook had let in some bot and was posting fake and untruthful stories, on the internet no less.
True, and I think Quarterdeck (and Pharlap, Rational, etc.) developed the VCPI specification that allowed those DOS extenders to work cooperatively. Some of the early DOS extenders took over the entire machine and did not allow that.
Around that time DOS programs were still being written to fit within 640KB of memory. However PC's were starting to be shipped with 2, 4 or even 8MB of RAM - memory really was a solution in search of a problem at that point. Windows 3.1 was the primary application for all that memory. But what if you didn't want, or need, to run Windows 3.1? Well that's where DESQview fit in. You could task switch between DOS programs instead using all that sweet memory (but not really, because DOS doesn't multitask, so 4 switchable ttys of DOS programs is a better description)
Vaguely related: there's Firecracker which boots in 125ms on x86 but that's as a VM, so it's an apples to oranges comparison. From what I recall Firecracker powers AWS Lambda so it's an interesting project in that respect too.
Not the OP and I wouldn't say I'm a fan but I've made some peace with it by putting a membrane cover over the top and so far: (a) not one dust related casualty in the past 18 months and (b) it subdues the clackety-clack of the keys into something that's actually quite pleasant.
I expect they correlated logs from several sources, maybe the guy connected via ssh to Apple's servers at the same time his mac accessed software update or something. If he sent all traffic down the VPN it'd show the same IP address at Apple.
Don't do this to the space bar! I used the same trick as the video to fix/clean several keys out and had a pretty good feel for what I was doing.
However the stress/weak points on the spacebar are quite different and you're more likely, as I did, to lift the entire butterfly mechanism out. You will not get this back in again. It's $700 to get the thing fixed at Apple but you can buy replacement keys for $100 per shot online.
Yes, instrumentation adds overhead. The absolute numbers cannot be used to determine peak performance but that's never the intention when profiling code.
Instrumentation rarely modifies the execution profile to the point that the numbers are 'worthless' or 'random'. My rule of thumb is that self times near the leaves of the callgraph are more accurate than self times further up the graph but having some indication of timing is important.
Furthermore with something like the call chart in AS3 you are often looking for outliers that you can't see when looking at an aggregated view of the profile. A function that has an average of 1000us might be running alternately at 500us and 1500us and you want to see that. It may indicate an unknown performance bottleneck, maybe a call to OpenGL is causing a GPU sync for some reason. It's rare that the instrumentation overhead would dominate major effects like that. Having a number available is important for this as you may be comparing invocations/looking at different parts of the graph at different zoom levels etc. Having a number available is the only solution.
Furthermore, where do you think the instrumented profiler is getting numbers from in the aggregated views? Answer: exactly the same place that the callchart gets it's numbers from. In essence you are saying all instrumented profilers are inaccurate and reporting bogus numbers, demonstrably untrue.
Only played with it a bit so far but it seems to me that the call and flame charts are now missing any timing information. Unless I've overlooked it you can't actually see how long a function takes to execute - defeats the purpose of instrumented profiling surely!