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.)

Yes, please! I've got a shovel, where should I dig the trench on my property?

If that's impractical--which it is--I'll settle for at least regulator recognition of the massive conflict-of-interest created by an Internet provider who also owns content companies.

As someone who lives in Toronto new the sewage treatment plant...

The waste water does go back into the lake. They take some stuff out of it, but that's... uh... the stuff that makes it sewage. Heat sunk into the water by the chillers is allowed to remain.

Ten years ago you could count on maybe 42 MB/s from that 7200 RPM hard disk--top of the line, premium device. Would have been, what, in the $250 for 80GB range?

Today, you can easily get 145 MB/s from a 7200 RPM hard drive--near bottom of the range, commodity price. But--prior to the floods--it would run you $120 for 2TB. (Heck, I just run the 5900 RPM units, they're plenty fast enough.)

High RPM drives don't actually give you much higher sustained read speeds--there's less data per rotation. Their random access performance may be better--but I find this year's 7200 RPM drive beats last year's 15,000 RPM drive easily.

And I can buy a whole, whole, whole lot of 7200 RPM units, plus RAM for cache, save a bunch on power, and wind up with more storage for the department compared to the 15,000s. And spares are easier to source.

But we do love our new SAS SSDs. They do random I/O like it was going out of style. Sustained rates in the 450 MB/s range.

So, most of us use 7200 RPM drives because we need to store lots of stuff. Then we can add SSDs to handle highly random workloads.

I've never found the "microwaves make the water molecules jiggle" explanation.

As an Electrical Engineer, I've found "plane wave propagating in a lossy medium results in heating within that medium" to be a much more compelling explanation.

And, of course, as the thermal energy of water--or any matter--increases, the motion of the molecules increases. So "microwaves make the water molecules jiggle" sure, but they do it by raising the water's temperature--not the jiggling causing the raised temperature.

And as soon as you even suggest "soft" mounts, the people who have been to Sun Brainwash Camp start freaking out. "No," they scream, "soft mounts cause data corruption!"

Apparently, in their world, no program ever checks the return code from a system call. And, also in their world, NFS servers reboot often and without notice--hard mounts don't protect data that the client hasn't sent, after all, they only protect against server reboots (but not failures).

If we have an NFS server go down, I want stuff to crash. We have to validate all the files that were in-flight at the time of the crash anyway. I've seen enough files grow runs of all-zero blocks after an NFS server crash with hard mounts to know that isn't guaranteed safety.

(Oh, BTW, the Sun people love "sync" mounts, too: you can't even disable it in the Sun server daemons. But it has a massively negative effect on performance. There are people that just insist on optimizing for the rare events. And yet, it's nearly impossible to fault out to a new server with NFS hard mounts.)

Almost all thermal plants, regardless of heat source, use a closed steam loop. Otherwise, you have to continually de-mineralize the feedwater, and deal with precipitate in the boiler.

How the steam is condensed varies; if you're near enough water, you can just use that. If you're near enough to a town, you can sink your waste heat into the district heating system. If you're out of all other options, you can build one of those hyperboloid cooling towers people associate with nuclear plants. (They're actually used with all sorts of thermal plants, including coal and oil.)

So, even the little 550 MW combined-cycle gas-fired plant in my neighbourhood recycles steam. (Combined-cycle means the waste heat from gas turbines boils water to run a steam turbine.)

Right, and there's prior art using soundwaves as memory: mercury delay-lines.

Just don't close the loop and, instead, you have a point-to-point sound transmission system.

In the Real World, that nasty place that makes all our math hard, you'd have to deal with reflections and "impedance mismatches" (where pipes of two different sizes meet). How it would work if you went with an Aloha-net style multiple transceivers on a shared medium I'm not sure, but... I could see a decent RFC coming out of this for the day after March.

Not so much; this is more danger approaching from the side. Generally in situations where the pedestrian has right-of-way--like his example of crossing the street and someone making a left turn.

If you can hear the car coming, you can get out of the way--even when it's the car driver who should be yielding. You're still hurt even when you're not at fault.

We could ask for drivers to be held to the actual traffic law, but history is against us, here.

To further clarify the mlts' response, you hook up ONLY transmit lines on the transmitter's side. You leave out all of the handshake lines going the other way, so no RTS/CTS handshake; definitely no XON/XOFF.

If the transmitter is too fast for the receiver, the receiver will buffer-overrun and corrupt the data it sees; the UART hardware SHOULD set a status flag when it overruns. But there MUST NOT be any way for the receiver to tell the transmitter to slow down.

It is acceptable to have lines from the transmitter that tell the receiver it is "online", like hooking DTR to DSR. But it can't be done the other way; the transmitter just sends blind.

The usual way of dealing with errors in this sort of situation is to send the data multiple times. That means each message needs a sequence number. (And don't forget to include the sequence number in the checksum; so you drop the whole message if the checksum fails.)

The first step in reducing the error rate, though, is reducing the speed. RS-232 (and -422 and -423) are well-understood and quite robust--in part because they don't use really high speeds, and their data clock is much slower than their sampling clock--a nature of the asynchronous beast.

If you were really going to do this, say for modern boxes with USB, you can even get USB-to-RS-232 cables that end in pigtails or sockets and use TTL voltages; you don't need to bother with the +/-12V level conversion. Just wire RX to TX, GND to GND, and you're ready. (Bonus points for hooking DTR to DCD or something like that for detecting "remote live, no transmission".)

And if I was doing this "for real", I'd use optoisolators so the two boxes really aren't electrically connected: they don't even need to share a ground. Like the way MIDI serial works; it's an electrical current-loop like RS-232, but the receiver is an optoisolator so you don't get ground loops between your instruments and sequencer. (Once you get past that, it's basically RS-232 with an unusual clock oscillator; you can interface to it with standard UART ASICs.)

Errr. So basically what I'd do is use a communication system that is exactly like MIDI electrically (PHY, layer 1) but put my on protocol on it.

Right, where's another wheel I can reinvent?