You say SATA drives don't have bent pin issues....

But I handed a box to UPS this morning that contained a NewEgg RMA ticket for exactly that issue. I'd never seen it before, in handing close to 200 SATA and SAS drives. The plastic in the power part of the connector was actually out of place, and the little metal fingers had not been laminated to it correctly.

So, it's possible. But, compared to always having a pair of needle-nose pliers around for unbending IDE connector pins (and 50-pin SCSI), wow is it rare.

Mind you, this was on a brand-new-out-of-the-anti-static drive, so I didn't even have a chance to even run the SMART extended offline test....

If you're going to do that, see if you can make sure that when the guy doing it still sees the original image--it's all his site visitors that get the shock pic. I mean alternate pic. Implementation left as an exercise and all that.

If you run shifts, you can do this with local labour. And if you combine it with work-from-home or "hot desking", you don't need multiple buildings, either. Having to pay premium rate for shift workers could be made up in the facilities budget.

And how old is old? I know several people still using the black & white Garmin StreetPilot... you can't get map updates for it, it's that old--circa 1998.

My Zumo is pushing 5 years old; it does all I want, and updates are still available... though now I have to pick and choose what regions to load. So I'm not replacing it.

Serial loggers might be even older, as they have no processing except the satellite receiver, so there's no rush to update them. Any chartplotting is done by the computer they're attached to.

It's possible for managed switches to lock a port to a particular MAC (or a list of them). That's done at the Ethernet layer.

Layer 3 switches can look at the IP address ('cause they're layer 3) and make sure that Approved IP Addresses are associated with Approved MAC Addresses only.

Which is still useless for all but the casual wrong-plug fault, because anyone actually breaking your network security can emit any MAC address they want. So they just need to intercept a couple of frames before switching to their gear.

You'd actually need Ethernet-level encryption or something to stop that. Or all your real connections are in VPN tunnels, and the regular LAN fabric doesn't route to anything except the tunnel server.

In other words, there are almost no networks set up that would prevent this from happening.

Right; I'm thinking of spending the extra $100 for the 3D model (Panasonic TCP50ST30 instead of TCP50S30); it has slightly better black and faster phosphors, which improve the moving resolution in 2D.

I have no intention of ever watching a 3D program on it.

Of course, I'll probably put off deciding until it's time to grouse about no-one wanting 4D....

I've done it by hand, but air-dry, so it's much the same thing.

They don't hold enough water to retain gunk; the two rinse phases (typical machine) are enough to sluice enough water through the upside down ones so you're left with clean water.

I just shook them around several times as they dried to rearrange which ones were upside down. If you're not in a big rush, that's good enough.

(I do the same thing with stuff that tips over in the dishwasher; maybe a quick rinse with hot water in case there's some detergent left, then just stick it in the drying rack with the hand washed stuff.)

Commodore wasn't above crippling the I/O on the C64 to avoid cutting in to the business market for the PET and CBM machines. (Those IEEE-488 parallel bus drives were FAST... most of them had two CPUs and 4-8K of RAM. The 1541 had only one CPU.)

There was a synchronous serial shifter on the C64's CIA chips (precursor to multi-IO chips). But there was something wrong with the hardware, so they had to bit-bang the serial I/O in software instead. Of course, it was their own hardware with the flaw: They'd bought MOS Technologies by then (which lives on as an EPA Superfund site, I believe).

Something similar was dumb on the Amiga. They finally had a true asynchronous UART for the RS-232 interface. But, the hardware handshake lines were done by software... which really fell apart above 19,200 bps.

If you limited yourself to the ROM KERNAL[sic] calls common to the PET, CBM and C64, you could actually write machine code that would run on all 3 series. BASIC code was, if you stuck with the C64 and PET 2001's 2.0 version, even easier to port.

So, one of the great things about Commodore was, we learned how to cope with mistakes....

The current expiry is listed in the WHOIS data for a zone. There should be a set of 3 dates: created, updated, and expires.

As for downtime and bouncing: you need to have your new nameservice in operation before the registration is changed. If you are not using GoDaddy, then this is easy, your nameservice doesn't need to change at all.

Otherwise, you should be able to set up the zone data at the new provider before the registration is transferred to it. Even if you do it in a single transaction, the registration transfer will usually take longer than it takes to populate the new nameserver with your data. (The former requires communication with GoDaddy and the global root servers, the latter is done entirely on the provider's equipment.)

The problem with using "bandwidth", which is the instantaneous use of spectrum (so, like a speed: Mb/s), to mean "data transfer" (Mb) is that it confuses the issue.

We don't want infinite bandwidth. We expect to pay tiered prices based on the bandwidth we purchase: 1 Mb/s really cheap, 5 Mb/s cheap, 10 Mb/s reasonable, 25 Mb/s pricey, and 50 Mb/s spendy.

Once we're done buying bandwidth, we don't expect to have limited data transfer. (DSL lines are always modulated, even when no data is transmitted, so the power argument is pointless--except as a function of bandwidth, not transfer.)

Especially if that limiting is not tied in to congestion management. Congestion management would be bandwidth-limiting and not transfer limit, anyway: we don't have enough backhaul for everyone to use their 50 Mb/s service at 8 PM, so you get effectively 10 Mb/s. But at 10 PM, the speed comes back.

Transfer limits will make sure everyone only uses the 'net when they really need/want it--which will mean peak times. They won't defer to off-peak, this isn't the dishwasher or something that can run at 4 AM. If you want to watch YouTube, you don't want to wait overnight while it downloads, then watch after dinner the next night. (I remember having to do that with a 1200 bps modem. And that was for pictures, not video.)