You confuse "GPS time" with GPS as a source for precision time. The difference between GPS time and UTC is broadcast every 12 minutes in the data stream, and includes the accumulated whole second difference, as well as drift value to correct for sub-microsecond. GPS receivers have access to this information and generally output UTC as soon as they read the offset value. Since the offset does not change often, it can be stored and used on subsequent startups, though this is a vendor specific decision. Though I've heard that they exist, every receiver and time source I've used outputs UTC by default by the time it downloads the full almanac and starts reporting position.

buffer bloat

isn't s/ usually used when you're substituting something that's DIFFERENT? *ducks and runs*

I think the same can be said of ITER... look where it got them!

I second your experience. The "More robust" micro connector might be rated for more cycles, but in reality seems to fail more often.

ADAT Lightpipe uses the same fiber and physical connectors as S/PDIF TOSLINK. It handles 8 channels of uncompressed PCM audio at 24 bit, 48kHz, for a totally unimpressive but sufficient bitrate of 9.2MBit. A slightly better quality ADC is needed on the receiving end of the signal due to the higher bandwidth, but is mostly the same.

SATA CAN be hotpluggable, but is not required to be. That said, most hosts support it, though only in AHCI mode, not emulation mode. From the systems I've seen in the field, about half are using IDE emulation mode, either because the OS doesn't natively support it and the installer did not spend time looking for drivers, or because it is a "fleet" computer where the BIOS was configured in a "safe" mode.

Tunneling accelerometers are mainstream. They are basically a STM without the scanning ability, with the "pinhead" on a MEMs arm. These are in tiny chips. Combining these with perhaps thermal expansion "heater" actuators, and you have a crude yet tiny STM, with very limited storage capacity (limited by X * Y travel / bit spacing.

Bonus if it can boil an egg at 30 paces, whether you want it to or not.

Babylonians, I bid you welcome to your new home!

Y93D1 Activity, knitting and crocheting
T1500XA Foreign body in cornea, unspecified eye, initial encounter

The rub in 2 and 4 comes when you STILL have to click the checkbox to make the software run. Nothing that they send back in paper form will get you past a hardcoded EULA/TOS agreement. By clicking OK even when you have the paper document in hand, you are explicitly accepting the original agreement and the company laughs at you.

..100Base-T. Albeit not over incredibly long distances.

Conversely on that broadband cable line already coming to your house, each 6MHz channel can support a downstream rate of 42.88Mb/sec using QAM256 (with some of this as overhead). Devoting that entirely to "Internets", the usable frequency range of that cable (typically) is from ~54MHz to 750MHz which represents 116 channels. 116*42.88 = 4974Mb/sec, or ~5Gb/sec of useful data in one direction. Cut that in half, and allowing for upstream inefficiencies (QAM64 instead of QAM256), you could theoretically get ~2.5Gb/sec down, ~1.75Gb/sec up over that one cable using current tech.

Of course you'd need multiple cable modems on the receiving side (or a killer DOCSIS 3 device supporting 58 down, 58 up channels) and the corresponding hardware at the head end. This is not unfeasable, just impractical.

And with Comcast you'd reach your bandwidth cap in just under 7 minutes...

The point is that the claimed level of performance of DSL can be trumped by a single entry level DOCSIS 3 cable modem (152Mb/sec down, 123Mb/sec up) using just 4 channels each way.

BIG badaboom!

I hear the guys are having great success speeding up this process with funroll-loops and -O51
*ducks*

goodbye karma...