I believe this post refers to the old Google+ Hangouts, which was the multi-party video conferencing service that launched with Google+.

• "Jabber" is a trademark owned by Cisco, inc. The generic term is "XMPP" and should be used throughout the article.
• A good third-party article about the problem has been posted here: http://windowspbx.blogspot.com/2013/05/hangouts-wont-hangout-with-other.html.
• It is also worth mentioning that there is no native desktop client—only a Chrome app which won't work for Firefox users.
• Google made no attempt to warn users that they would lose all communication with their federated contacts.

I recently built a decoder for EAS/SAME messages. You can read about the protocol it uses at the National Weather Service. Forget about cryptographic signatures; SAME has absolutely no concept of message integrity. There is no CRC or checksum—not even a lowly parity bit.

Of course, it's difficult to use a checksum when you can't figure out when the message ends. Most systems use some kind of flag byte to tell the decoder where the end of the frame is, but SAME doesn't even have that. The decoder has to figure out where the end of the message is by parsing it and lopping off the garbage from the end. Messages are "redundant" in that they are repeated three times, but this doesn't improve redundancy very much. SAME also depends on a voice message to convey the content of the alert, which is hardly ideal in today's environment.

But SAME does have one thing going for it: You can actually get the messages. Its heir-apparent, IPAWS, seems more heavily focused on making sure people can't get the alerts. There are no public distribution hubs—you have to have a certificate from FEMA to get any data. Even with a certificate, there is, reportedly, no data to be had. I hope they make a SAME 2.0, even if it's only for end delivery to the general public via weather radios.

I've built the EAS decoder into a new version of multimon, which is available here. It can't generate messages; it only decodes them. From the YouTube video, here is what the zombie apocalypse man had to say:

ZCZC-CIV-LAE-030077-030007-030043-030049-030059+0015-0422133-KRTV -

Please don't spoof EAS messages. The system is fragile enough without you messing with it.

While exercising your right to protest is admirable, there are other more effective methods to consider. While the VIPR teams may be authorized and financed by the federal government, they are not law enforcement. As such, they require the active cooperation of your transit police, your municipal police, and your state police to carry out their warrant-less searches. (The FBI and federal marshals have better things to do, really.) Without the authority to stand around in a fake badge and remove naysayers from the premises, just how effective can VIPR be?

So talk to your city council representative. Be polite, presentable, and logical. If you're lucky, you might be able to make a presentation or get a sponsor on some legislation. If you can get even a small group of people together, your chances of success will improve. Your state or city may give you some additional tools with which to affect change: Initiative and Recall. Use them.

While the 4th amendment is nice, in principle, that's not what is going to get the attention of your city government. Focus on the fiscal impact of the TSA's presence. How much time does the MBTA police spend assisting the VIPR teams? Does the city need to hire any staff to support them? If just one staffer has to spend ten minutes of their day dealing with this stuff, the TSA's presence is not revenue-neutral. Even if you can't get these numbers, bring it up. It will get them thinking, if nothing else.

Focus also on the impact on commerce. Does the TSA delay trains, or make people late for work? Does the TSA significantly reduce the number of riders on the subway and put them on already-congested roads? Point out the potential for theft and harassment—there have been a number of news articles about this very topic. Once that is finished, all you need to do is prove that the TSA does not actually increase security. Bring in expert testimony, if you can get it.

Once you have proved that VIPR is unpopular, decreases city revenue, negatively impacts commercial interests, and is disruptive to the public order (i.e., "don't grope me"), you will have lots of momentum behind a city ordinance. The goal of the ordinance should be to (1) prevent any municipal law enforcement from cooperating with these searches, and (2) actively remove anyone conducting such searches from the transit system. In the absence of any overriding law, city ordinance prevails and—good news—it's an election year.

VIPR will, having been removed from the city, need to spend time, effort, and money passing overriding legislation. If you're lucky, they'll just go away and find someone else to tyrannize. Even if they don't go quietly, the REAL ID Act is a great example of what states can do to a federal program if they refuse to support it. So go ahead, take back your city.

Sure, but how many Wikipedia users—not editors or regular contributors, but users—actually check the revision logs or old versions of the page? Even writers who are using Wikipedia as a primary source don't do that much fact checking. Users don't always have the greatest attention span in the world, and burying stuff on another page is a sure-fire way to get people to ignore it. If you put revision information three or more clicks away, or sequester it in a registration-required (or paywall-required) page, how many people will follow it? News-gathering organizations have a reputation to maintain, and they have every incentive not to admit that they are (or ever were) wrong.

I think that wikis should have a visualization tool for paragraphs, highlighting text like a spell-checker in a word processor or a syntax-checker in an IDE. The visualization tool should represent how new, and how frequently-revised, a particular section of text is. This will allow casual readers to easily spot points of contention and text that may require further validation.

I seem to recall another civilization where news stories were subject to constant, behind-the-scenes revisions. I read about it in a book. One must always take care to interpret the past correctly, through the darkly-tinted lenses of our current social and political mindset. After all, it would simply be unsettling if there were anything at all in our history that happened to be politically insensitive or inconvenient for our current religious, economic, or secular leadership. Simply revising or "reinterpreting" key facts and events go a long way towards removing all of that troubling cognitive dissonance; such dissonance could cause people to question the way things are right now. Sadly, I can't really remember any more details about this civilization, because my e-books retailer erased every copy of it.

News via Wiki? I don't think so.

I have tried faxing via Google Voice over a POTS connection. I can connect to the remote fax machine, but it fails to send even one page. GV states in its FAQs that it cannot be used as a fax number. Either they are explicitly blocking it or (more likely) they are using an LPC/model-based speech codec like speex that simply eats the analog modulation for lunch. With the death of Gizmo5, it is now impossible to connect via SIP except via services that give you a PSTN connection and a phone number—and at that point, why use GV at all, since you're already paying someone else for a phone number? sipgate claims the ability to send faxes, but this is a function of sipgate and not Google, and I have not tried them at all.

Have you actually gotten fax over Google Voice to work?

I am profoundly disappointed by Google's profound lack of commitment to open standards (i.e. SIP).

Fax may never die, but its current implementation is tied to a piece of technology that people keep claiming will be on the chopping block before long: the analog dial-up line. At my university, VoIP phones are the norm—and are relatively trivial for IT to hand out—but getting an analog line provisioned is difficult and expensive. Have you ever tried to send a fax from Google Voice or a similar IP-based telephony network? I have, and it doesn't work: the codecs are specifically designed for speech, and the channel does not have enough effective bandwidth to support even a 14.4kbps fax. There are stopgap solutions, of course; Analog Telephone Adapters (ATAs) and/or centralized fax servers save the day. But what about the future, when companies decide to forsake their ISDN/T1-type phone lines altogether and go "all-internet" for their phone connections?

Fax is, for businesses, currently an irreplaceable service. No other service gives them the same traceability, accountability, and legal protections as fax does. Digital signatures do exist, but defending said signatures in court later could get expensive, and I'm not certain if they have ever been interpreted as legally binding. (Anyone, please feel free to refute this.) Trusted timestamps also exist, but the market for them is abysmal. Authentidate, which is marketed by the USPS as an "electronic postmark," costs more than postage and charges for each validation. So, what will happen to fax as the phone network depreciates?

I predict that soon, organizations will be outsourcing their faxing capabilities to third-party providers, which will provide them with an email (or other internet) gateway for faxes. Maybe they'll even connect a printer to keep that same-old fax feel. Eventually, the fax gateways will become popular and numerous enough that they will all realize just how much they're paying for PSTN lines and long distance charges. Then, they'll start peering with one another over encrypted internet links, forsaking the entire phone network and the associated analog transmission protocols altogether. The end result: companies will pay good money to emulate an old, low-resolution raster image transmission protocol, the purpose of which—to squeeze images down a phone line with simplistic compression—having been entirely forgotten.

These are just my totally-uneducated musings, and you should not take them for investment advice. As an interesting side-note, fax (or fax-like protocols) are also used to send weather charts to ships at sea, and these radiofaxes could possibly outlast their phone counterparts.

We use MineOS, but it is not something I'd recommend. It is based on a thumb drive/CD-R linux distro, and as such getting it to save system changes to the hard drive is like pulling teeth. It has RAM disk functionality for the world files, but we're not using it—that is most certainly asking for trouble. If it were my box (I just admin it), I would have installed a real, actively-maintained OS like Debian or Ubuntu Server long ago.

They theoretically have a new version, MineOS CRUX, that is less full of fail, but I haven't tried it.

I really do enjoy Minecraft, but my enjoyment of the game is tempered somewhat by the hair-pulling, teeth-gnashing, life-sucking hassle of administering an SMP server. When I first installed it, the server was so unreliable that I needed to write a bunch of custom "glue" just to keep it online. The server would crash constantly, so I wrote a shell script to restart it if it exited. But this proved insufficient, as sometimes it would simply hang unresponsively, so I wrote a more sophisticated watchdog timer for it. These crashes were the least of my problems, however.

The world files, which are a monument to our thousands of man-hours of lost productivity, are precious, precious data, but the server treats them with less care than the contents of /dev/random. In just six months, I have had to restore from backups three times due to irrecoverable server faults. There is no write-ahead-logging, so any power failures can corrupt the world. The all-important level.dat file has been destroyed at least twice, changing the random seed—and all of the world's climate—in the process. After fixing the seed, I had to use a level editor to melt all the ice. Saves are also not atomic, so crashes will usually result in lost items and inconsistent states. I must have spent hours just giving people back lost items. If Notch would just use an ACID-compliant DBMS, none of this would happen. I back up the world four times a day, and I sometimes question whether this is often enough.

The server chews up a truly ludicrous amount of bandwidth—just having four or five people connected at once will saturate a typical residential connection—but there is no reason for this. The world doesn't really change much over time, since players can only affect little bits of it at once, so why not have clients cache the world and pull only versioned updates over the network? If it's good enough for Mozilla, it should be good enough for Mojang. Surely, with the well-known "chunk error" problems, this couldn't possibly make the data transfers any less reliable.

While there have been numerous fixes for gameplay-related issues, or things Notch believes are gameplay issues, no attempt has been made to address the architectural deficiencies which make administering an SMP server a complete pain in the posterior. But that's okay, because it's supposed to be "fun," right?

While true, amateur radio connections cannot even begin to replace existing internet infrastructure, even in a low-bandwidth, emergency context. You could conceivably link a bunch of wireless hot spots together over 2 meter/VHF, and since VHF has a maximum propagation distance of about 100 miles, everything would work perfectly, right?

Except it wouldn't.

Since VHF is (more or less) line-of-sight, you'll need lots of power and/or a highly directional antenna on a tower. The former will splatter RF energy everywhere, making those frequencies unavailable to everyone else nearby, and the latter requires big, obvious infrastructure on both ends. Infrastructure, as you have pointed out, puts someone in control—even if it is just "that guy who runs the local digipeater." If he doesn't like you, he might not let you connect his VHF radio tower to yours.

There is also the problem of access control: not who can transmit on the 'net, but when. If everyone transmits at the same time, the end result is just unintelligible static. Ad-hoc wireless networks work for small networks, with nodes that are all "within earshot" of one another, but the hidden node problem quickly takes over as the range increases. If you gave everyone in the city of New York a VHF transmitter, and just told them to use it whenever, the interference they'd produce while trying to use it would probably rival military jamming technology. Cellular networks achieve efficient communications by precisely interleaving the signal from each and every phone, in either the space, frequency, time, or code domains. This requires planning, and engineering expertise, which again puts someone in control.

There is a reason why the Amateur Radio Service is intended as a secondary communications system, for use only when no other link will suffice. It is the best way to communicate when all the other networks are inoperative, but it simply cannot scale to a project of this magnitude.