Apparently very few people here were actually around in the early days of the PC, never played with the ISA bus, etc. You're correct, Ctrl-Alt-Del does NOT generate an NMI... An NMI on early PCs just crashed the computer. It was usually only triggered on a parity error on most machines. It seems to me it was hooked to the back right pin on the ISA bus, so you could crash your machine by triggering it. If you did that accidentally while playing with the bus (we used to hook all sorts of things directly up to the bus using jumper wires shoved outside the fingers in the slots) or moving your home-made card around or something, you'd just ground the second from the back on the left side of the slot and that triggers a reset... IIRC, anyway... It's been some time since I built an ISA card... :-) Still have my original "soundcard" that was a basically just a DAC hooked to the bus at 0x300h that I built many many years ago around here somewhere... and my 16-port GPI/O card I built to hook up to a lightshow controller built from a whole swack of 7400 series logic... Oh, those were the days! :-)

What's with all the fluff articles lately? I read a detailed article many years ago about Woz' phone phreaking adventures an his love of jokes and pranks is well known. I'd love to read a modern article on some of the (presumably hilarious) details, but this is certainly not it. :-)

ARGH!

Ok, I know sometimes a type-o or two can get through even the most closely proofread post, English isn't necessarily a given poster's primary language and I was raised in a family with multiple English teachers. However, lately this one drives me absolutely bonkers on a daily basis, seemingly on every thread, here on /.

http://grammarist.com/usage/than-then/

Thank you!

I stand corrected.

Mod that link up.

They basically just banned adding "on a computer", etc. to a patent automatically becoming a new patentable "invention".

A friend of mine uses "BACKOFF get your own wifi"

Only because people keep saying there are only two options until people believe it. As soon as people actually bother to vote for another option, there will actually BE another option!

If it is broadcast in your local area anyway, why should it be wrong to download a copy that someone else used their antenna and capture card to record instead of recording it yourself? If you have a cable/sat/etc subscription to a channel, why should it be wrong to download a copy of something you've already paid to be able to watch but someone else actually recorded? etc.

Yeah, for a TI-99/4a with it's 256 bytes of actual CPU 'scratchpad' RAM on the TMS9900's 16-bit system bus vs today's 16GBs is, what, about 67 million? What's wrong with these poll writers lately? :-) I guess if you counted the video memory also it would be closer to 1 million but I'm reading the poll as meaning system RAM for the main CPU, so that's 128 x 16 bits.

Depends on the drive. Most ignore the error correction bits however some better (and usually older) ones will actually read the error correction bits and correct (any correctable errors) on the fly and you'll always get either the exact same data or a read error.

No, there actually are error correction bits but most players/drives ignore them when playing/reading audio. Good drives like Plextors will do bit-perfect DAE. Even some of my older Sony, Yamaha and Pioneer SCSI drives do it by themselves. I still use my old drives for my DAE needs. Most cheap new drives don't bother but you can read multiple times and make it pretty close with software. Something like grip works well.

http://en.wikipedia.org/wiki/Red_Book_(audio_CD_standard)

Hmm, replying to my own post with a correction I noticed when I re-read after posting, before some uber-network-guru calls me an idiot... :-) The multiple responses on the same hop number aren't additional routers not incrementing the hopcount (would have three times each) they were the three indivitual ICMP echo requests being responded to by the different (parallel) routers that happened to be the one passing the packet and responding the request.

Your maximum speed has nothing to do with latency, which is what the ping time is measuring. Most protocols adjust for increased latency, so even on a satellite connection with a 1s ping time due to physical distance, you can still get many Mbps on a large transfer. Response time for anything interactive is a completely different story.

All of the physical distance is probably on savvis' network then... Why does that make them suck?

I tested three different connections at the same location here in Calgary since I have all three available here in the mini-NOC for troubleshooting when parts of the internet melt, a 25 Mbps business-class Shaw cable, a 6 Mbps Telus ADSL2+ and one on our own in-house DSL equipment running at 3 Mbps backhauled via fiber that eventually peers upstream with both Telus and Shaw... Local IPs have been hidden...

These were each tested directly from a FreeBSD router to the appropriate modem.

*** SHAW
As I expected, despite having the fastest rated "speed", the Shaw connection's LATENCY (which is what we're measuring) was the worst (don't read too much into hop count on today's backbones, ie. here we happen see many of the hops inside level3, including several which did not increment the hopcount, but many backbones will not show (m)any depending on their transport, design, etc.):

Ping times vary, usually 90-100ms but as usual on cable, sometimes they spike WAY up, even on this "business class" network version:

PING slashdot.org (216.34.181.45): 56 data bytes ...
319 packets transmitted, 286 packets received, 10.3% packet loss
round-trip min/avg/max/stddev = 88.485/93.094/106.992/3.029 ms

Here, I happened to catch some suckiness for a few seconds (ie. why cable generally is bad):

PING slashdot.org (216.34.181.45): 56 data bytes
64 bytes from 216.34.181.45: icmp_seq=0 ttl=241 time=92.786 ms
64 bytes from 216.34.181.45: icmp_seq=1 ttl=241 time=95.201 ms
64 bytes from 216.34.181.45: icmp_seq=2 ttl=241 time=571.284 ms
64 bytes from 216.34.181.45: icmp_seq=3 ttl=241 time=554.097 ms
64 bytes from 216.34.181.45: icmp_seq=4 ttl=241 time=553.406 ms
64 bytes from 216.34.181.45: icmp_seq=5 ttl=241 time=333.319 ms
64 bytes from 216.34.181.45: icmp_seq=6 ttl=241 time=551.926 ms
64 bytes from 216.34.181.45: icmp_seq=7 ttl=241 time=567.186 ms
64 bytes from 216.34.181.45: icmp_seq=8 ttl=241 time=208.858 ms
64 bytes from 216.34.181.45: icmp_seq=9 ttl=241 time=89.081 ms
64 bytes from 216.34.181.45: icmp_seq=10 ttl=241 time=93.182 ms ...
11 packets transmitted, 11 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 89.081/337.302/571.284/213.942 ms

traceroute to slashdot.org (216.34.181.45), 64 hops max, 52 byte packets
  1 64.x.x.x (shaw) 13.378 ms 14.725 ms 12.000 ms
  2 66.x.x.x (shaw) 29.474 ms 34.974 ms 24.177 ms
  3 66.x.x.x (shaw) 29.671 ms 39.214 ms 31.993 ms
  4 xe-8-3-1.edge1.Seattle3.Level3.net (4.59.232.37) 25.604 ms 30.470 ms 28.631 ms
  5 ae-31-51.ebr1.Seattle1.Level3.net (4.69.147.150) 56.912 ms 45.714 ms 46.577 ms
  6 ae-7-7.ebr2.SanJose1.Level3.net (4.69.132.49) 48.333 ms 48.885 ms 54.355 ms
  7 ae-92-92.csw4.SanJose1.Level3.net (4.69.153.30) 46.860 ms
        ae-62-62.csw1.SanJose1.Level3.net (4.69.153.18) 44.887 ms
        ae-72-72.csw2.SanJose1.Level3.net (4.69.153.22) 50.558 ms
  8 ae-3-80.edge1.SanJose3.Level3.net (4.69.152.144) 47.736 ms
        ae-4-90.edge1.SanJose3.Level3.net (4.69.152.208) 57.435 ms
        ae-2-70.edge1.SanJose3.Level3.net (4.69.152.80) 50.952 ms
9 Savvis-Level3.Dallas3.Level3.net (4.68.62.106) 45.752 ms 46.598 ms 110.005 ms
10 cr2-tenge-0-5-0-2.sanfrancisco.savvis.net (204.70.200.198) 49.200 ms 46.154 ms
        cr2-tengig0-7-3-0.sanfrancisco.savvis.net (204.70.206.57) 46.903 ms
11 cr1-ten-0-4-0-1.chd.savvis.net (204.70.192.134) 90.065 ms 90.816 ms 90.150 ms
12 hr1-te-12-0-1.elkgrovech3.savvis.net (204.70.198.73) 96.279 ms 90.123 ms 89.796 ms
13 das6-v3034.ch3.savvis.net (64.37.207.166) 93.088 ms 91.937 ms 90.050 ms
14 64.27.160.198 (64.27.160.198) 104.232 ms 107.131 ms 90.055 ms
15 slashdot.org (216.34.181.45) 89.878 ms 90.898 ms 91.700 ms

(Actually at least 20 hops on visible, responding routers , though it shows only 15)

*** TELUS
The Telus was second and has the shortest number of SHOWN hops, but there are many pieces of equipment between here and slashdot, they just don't show up:

PING slashdot.org (216.34.181.45): 56 data bytes ...
422 packets transmitted, 409 packets received, 3% packet loss
round-trip min/avg/max/stddev = 51.477/52.423/55.586/0.583 ms

traceroute to slashdot.org (216.34.181.45), 64 hops max, 40 byte packets
  1 telus (199.x.x.x) 12.157 ms 12.164 ms 11.399 ms
  2 telus (173.x.x.x) 11.637 ms 13.749 ms 11.600 ms
  3 telus (75.154.223.178) 40.949 ms 40.419 ms 40.927 ms
  4 savvis (216.91.69.45) 40.962 ms 40.460 ms 40.901 ms
  5 hr1-te-9-0-0.elkgrovech3.savvis.net (204.70.196.14) 41.965 ms 42.152 ms 41.620 ms
  6 das5-v3032.ch3.savvis.net (64.37.207.158) 51.590 ms 51.634 ms 51.969 ms
  7 64.27.160.194 (64.27.160.194) 50.586 ms 41.884 ms 49.791 ms
  8 slashdot.org (216.34.181.45) 51.784 ms 53.937 ms 52.490 ms

***SATURN
Our network adds a couple extra hops and the test link is 3 Mbps vs 6 for the Telus but since it ends up routing these packets through the Telus backbone upstream, performance is similar but ends up being a TINY bit faster despite the extra latency on the DSL line because our internal network is less loaded and very carefully controlled:

PING slashdot.org (216.34.181.45): 56 data bytes ...
347 packets transmitted, 347 packets received, 0% packet loss
round-trip min/avg/max/stddev = 47.759/48.731/50.917/0.592 ms

traceroute to slashdot.org (216.34.181.45), 64 hops max, 44 byte packets
  1 66.x.x.x (internal) 6.926 ms 7.586 ms 6.661 ms
  2 66.x.x.x (internal) 6.279 ms 5.862 ms 7.596 ms
  3 208.x.x.x (telus) 10.341 ms 7.386 ms 7.621 ms
  4 154.x.x.x (telus) 7.306 ms 7.756 ms 7.623 ms
  5 205.x.x.x (telus) 16.328 ms 22.365 ms 10.594 ms
  6 75.154.223.178 (telus) 56.833 ms 57.388 ms 56.590 ms
  7 216.91.69.45 (savvis) 56.336 ms 57.315 ms 56.449 ms
  8 hr1-te-9-0-0.elkgrovech3.savvis.net (204.70.196.14) 57.320 ms 57.742 ms 58.591 ms
  9 das5-v3032.ch3.savvis.net (64.37.207.158) 48.837 ms 47.399 ms 48.580 ms
10 64.27.160.194 (64.27.160.194) 48.328 ms 54.349 ms 53.628 ms
11 slashdot.org (216.34.181.45) 48.329 ms 47.359 ms 49.541 ms

YMMV