This needs to be funded as one of the faith based initiatives that the last two presidents have pushed.

Rosetta (the craft carrying Philae) took ten years to get there, and required a flyby of Mars and Lutetia to get its vectors and speed right.

And is so small that it's like a fly landing on a townhouse. What's the fly supposed to do? Ask the townhouse to move over?

I'd think it likely wouldn't be enough, because a NEO won't have the mass of Mars which we'd use to brake the craft once there. Unless we were sending an impact missile, it might take a lot of time and planning to get there. Rosetta took 10 years and a flyby of Mars in order to match up with a comet.

I meant all the various giant members of what's commonly/historically known as reptilia, including (but not limited to) archosaurs like dinosaurs, pterosaurs and many of the larger/landbound members of crocodilia and aves (birds).

If you're huge, at least somewhat ectothermic, and can't easily migrate, climate change won't be your friend, and evolution will eventually tally the score as "extinct".
Hm... I wonder whether that applies to Americans too...

Your great-grandchildren probably won't care about your roads and bridges either, other than the cost of repairing them. These days, they're not built like Roman roads and bridges, and don't last for generations.

Not necessarily. We could find a way to jump some of us aside, or heat up one side of it with lasers from afar, or burrow until the crisis is over, or have congress declare it a non-problem, or have religious people pray for a miracle.

I think the simplest solution is the better one. Let them hit. Evolution will take care of the aftermath. It already has weeded out large landbound reptiles that can't take the heat (or the cold) due to meteor strikes. If the Yucatan big boy hadn't hit, there might have been scaly beings in charge now. Other than lawyers, I mean.

I don't think you're aware of just how power frugal the PIII is. The TDP is 27.9W, which is far less than most laptop CPUs burn these days. And given that the average load is in the 0.01 range, it uses far less. It has run fanless since 2003. Energy is not the issue here.

But a point is the reliability of larger die fabs. Can a Raspberry Pi be reasonably expected to run for 10+ years?
Also, the Pi comes with a single 10/100 Ethernet port, running on a CPU-bottlenecked USB 2.0 bus. Just dealing with a normal amount of packets puts a considerable load on the SoC CPU. And no running backups or NFS mounts at GbE speeds.

Don't get me wrong, the Pi was a fabulous little board, but it was never designed for 24/7 network related operations.
And it's certainly not a replacement for a system that doesn't need replacement.

I dunno either, but my main home server is a PIII, running primary dns, dhcp, smtp and a few other services, and average load in the 0.01 range. It's been running pretty much non-stop since 2003.

There's really no need to upgrade just to upgrade, if the box can do its job without breaking a sweat and can be kept patched up to date.

If PIII machines were available and could run the software, why not?

Pluto is a planet. In fact it is more of a planet than Mercury or Venus are, because unlike them it has its own satellite that orbits it (Sharon).

Your language betrays you, Galilee.
It's Charon, which is pronounced with a hard k. The alternative spelling for the ferryman of Hades is Kharon.

I thought it was a button that changed the SSID to "Pregnant Women".

*sigh* This is wrong on so many levels.

1: The DHCP protocol mandates that every packet contains the hardware address (for ethernet, the MAC address) in the chaddr field.

2: It's the client's call to DHCP servers that discloses the client's MAC address. What replies do is irrelevant.

3: Even if that weren't the case, all packets including replies still contains the client's hardware address in the chaddr field. Without it, bootp dhcp relays would not work, as they do not parse the data segment of the dhcp packages and would not know what the client identifier key is set to.

4: Even if that weren't the case, the DHCPOFFER, DHCPACK and DHCPNAK packets from the server to the client are almost always unicast. No dhcp client in use today will set the broadcast flag on its DHCPDISCOVER or DHCPREQUEST messages - the RFC is pretty clear that only clients that cannot receive unicast replies should set the broadcast bit, all others should clear it. You may find an old Sun box from the 1990s with a bootp client that needs to use broadcasts exclusively before its network stack comes up, but that corner case is so small that it can be ignored for this purpose. And even then, the client must fill in the chaddr field, and the server leave it as is in replies.

But to sum it up, yes, you tell the DHCP server your MAC address.

And modern DHCP servers use that information too, not just the client uid. For one thing, combined with turning off broadcast replies, it allows for restrictions on how many IP addresses can be given to any client (a fairly common attack back when was to keep on requesting and accepting addresses, exhausting the pool).

That's semantics. Whether the client app inserts it or the network stack adds it does not matter in this context - the DHCP server receives it, and needs it for all directed communication until after the client has received an IP address.

If a client does not send a client ID, the MAC is also normally used to generate a unique but repeatable client ID. Gleaned from the network packets, where it assuredly is present, no matter how you define "you".

You have no idea how DHCP works? When you ask the DHCP server for an IP, you do not have an IP address. In order for you to get the reply back from the DHCP server, it needs your MAC address.

Steve Jobs died because he delayed treatment for his cancer while he tried an alternative therapy with no backing by research.

You're invoking magic in the form of clairvoyance here, and as a result, you are no better than the homeopaths. The problem is the word "because". You don't know whether he would have lived.
Of course, choosing homeopathic "cures", if he did that, was extraordinarily stupid, but claiming to know what would have happened is even more stupid.

Not to forget languages like Swedish, where à is a letter in its own right, and neither an umlaut nor a dieresis.
That means that technically, when written in a language that uses diereses, the dots can be stacked. A Swedish word like "nÃÃ" (nah-ah) rendered in a language with diereses would be written with two extra dots on the second letter to show that the second à should also be pronounced.
That's where Unicode fails - instead of having the diereses as a separate marker only, it has allowed for characters like "a with diereses", but not for varieties of letters that look like they already have them. What letters look like should not be any concern of Unicode. An à with both umlaut and dieresis added should be perfectly acceptable to Unicode, and how the presenter wants to present it none of Unicode's concern. Whether it shows up with two, four or six dots above it, or a colon before it, or any other visual representation.