Yah, I think they meant to say that he is the "de jure" head of state--by law, not the "de facto" head of state--by fact.

Gee, I love the idea of the solar cells being "above the track". Wild animals from lizards on up are smart enough to seek out the shade, as are vagrant livestock. So, with the tracks in the shade for a good part of the day, I expect we could have a chain of Momma's Train-Killt Bar-B-Q stands all the way from Tucson to Phoenix (Cook them in solar ovens, come to think of it.) Or maybe DARPA could fund a next-generation cow catcher on the front of the engine, one that works at 200mph...

I wonder if you are thinking about sheep ("hooved locusts"?)

There are lots of places in the Bay Area that do this. It's much more than a sop to carbon neutrality: the goats can "mow" slopes that are far too steep and uneven to wrestle a mower across. They also make short work of areas that are filled with rocks, brush and stumps and have no objection to a dessert course of poison oak (that's a good reason not to pat them on the head, though).

I used to watch them arrive at the Lawrence Hall of Science up in the Berkeley hills. Trailers pull up; the goat wranglers set out a low fence and then unload the goats and a few working dogs. Over the next few days the wranglers move the fenced area across the slope and the goats eat and fertilize their way across the landscape. A few days after they arrive the brush is gone and some very nasty terrain has become a fire break, with roots still in place to prevent land slides. What's not to love?

A $30 switch and a patch cable will take down your spanning-tree enabled infrastructure very effectively. Loop the cable on your cheap switch: voila, a broadcast-storm generator. Plug it into the wall; plug your laptop into the switch and let it DHCP Discover, which is a broadcast. Your cheap switch now generates a stream of broadcasts as fast as it can, injecting them into the network. Your Spanning-Tree Enabled switches now repeat the broadcast faithfully. Network crashes*. STP prevents your switches from creating loops, NOT from propagating broadcast storms...

*unless you are throttling the ports based on broadcast traffic, which you now know is NOT a feature of Spanning Tree

Actually, Bandwidth In Mirror Will Be Larger Than It Appears (BIMWBLTIA)! And, when it gets right down to it, you don't care about bandwidth anyway; you only think you do.
1. Why do companies spend $500 a month for a 1.544Mbps T-1 when a 1.5Mbps DSL connection is only $29? BECAUSE YOU DON'T CARE ABOUT BANDWIDTH (you only think you do. more below.)
2. Why does your 64Kbps codec consume more than that when you actually look at it? BECAUSE OVERHEAD COULD DRIVE THROUGHPUT AS HIGH AS 3,500Kbps! (actually that's just a theoretical, non-real world extreme, _as is 64Kbps_, more below.)

Regarding #1. Bandwidth, schmandwidth. It's all about LATENCY. Which is better for voice, a 50Mbps pipe or a 56Kbps pipe? Answer: Cannot tell from info provided in question. If, in the 60th second of a minute-long call, I deliver 3000Mb of voice data, I've given you the promised 50Mbps bandwidth. Unfortunately, there were 59 seconds of silence followed by an auctioneer's delightful squirt of one minute's words delivered in one second! Far better if they had been delivered less dramatically, but spaced evenly, over that minute. VOICE IS DIFFERENT FROM DATA IN THIS WAY. Had that been a big file, it wouldn't have made any difference. For file-type data, you pay your provider for the bandwidth. For voice-type data, you need to find a provider who can guarantee you evenly-spaced, regular delivery: that is, low latency and jitter. A T-1 has low latency, jitter and pkt loss; a DSL pipe may have identical _bandwidth_ but comes with no guarantee as to what is really important for voice, latency-jitter-loss.
That 56Kbps pipe? If it were a plain old $20-a-month land line from the phone company, that skimpy bandwidth would be delivering your voice with an end-to-end delay (latency) of less than 150ms; compare that to the VOIP standard (again, nominal) of 450ms. Your land line is still the Gold Standard for voice quality. (And yes, I have experienced better-sounding voice over Skype; Pure Friendly Magic! Great proof that VOIP can exceed even Carrier Grade. Someday, Vladimir, someday all the workers will have Carrier Grade VOIP.)

Regarding #2. I know that XorNand mentions overhead and is obviously aware of the following, but let's be explicit: overhead is more than trivial. You will never, never, never, never deliver voice at 64Kbps with a 64Kbps codec. That is a fake number, the limit that VOIP might approach asymptotically. Worst case? Your voice, encoded at 64Kbps, consumes about 3.5Mbps of bandwidth. (Also a fake number; we make a deal with the Devil, i.e. Delay, to keep the bandwidth down.)
The phone company standard codec, G-711, samples your voice 8000 times per second and represents the volume of your voice in that sample as an 8-bit number: 8bits*8,000 samples --> 64,000bps. The phone company then drops your voice onto the wire (on say a T-1 line) 8 bits at a time; each sample drops as soon as it's encoded, eight thousand times a second. Because this wire goes straight to the Central Office (say), the Telco does not need to add an IP address: there's only one place for it to go, the other end of the wire. Because the wire has a clocking device at both ends (the CSU that terminates a T-1) the Telco does not need to attach an RTP Timestamp to your voice: the T-1 circuit does that too. Because the voice samples can't leapfrog eachother in the wire, or get lost, the Telco does not need to attach a TCP sequence number or acknowledgement; the CSUs know whether a sample is to be used as voice or data, and handle multiplexing, so there is no need for a TCP/UDP port number.
You can see where this is going, right? VOIP takes the same sample, and to deliver it attaches an RTP header for timing/sequencing/codec info, a UDP header for port number, an IP header for end-to-end addressing, and an Ethernet header to get you across your LAN. That 1-byte sample is now dozens of bytes long. It's as if to carry 8000 commuters to work you sent out 8000 trains, each with a string of locomotives to pull a single commuter down the rails. We don't do that; we wait until we accumulate a "reasonable" number of commuters on the platform, then have one string of locomotives pull many of them down the rails at once. Yes, the commuters experience delay, and Yes, delay is evil, but the alternative would be to use a ridiculous amount of bandwidth on the rail network to deliver them all.
Most VOIP systems impose a MINIMUM delay of 10ms at the beginning of the delivery process, the time it takes to collect 80 voice samples. They drop voice on the wire 100 times a second, not 8000 like a Telco T-1. At that rate, a call actually needs around 100Kbps bandwidth to carry the 64Kbps of voice you encoded with G-711. If you wait five times as long, collect 400 samples and drop them on the wire in one ethernet frame, you'll drop 20 frames per second and your bandwidth needs fall to about 75Kbps. But you increase the delay! Tradeoff: bandwidth versus delay.

In the end, voice is entirely unlike other types of data carried over IP. Files require 100% of the bits to reach the other end and can tolerate delay. Voice is fine with a reasonable number of lost bits but cannot tolerate delay. Guess which the Internet was designed to favor? When you spec "bandwidth" for a VOIP connection, it's at best a proxy for delay-- high bandwidth pipes tend to have less delay. Bandwidth is less important than delay, and Service Level Agreements for VOIP need to explicitly spell out requirements for jitter and loss.