During about the time Mrs. Clinton was in office, I worked for a U.S. corporation supporting a U.S. government system where organizations interested in being government contractors were allowed to register. A notable fraction (don't remember exactly how many) of the contact e-mail addresses were "@aol.com", "@yahoo.com", etc.; and probably a few were "@retainedlawfirm.com", "@jointventure.com", "@parentsothersubsidiary.com", etc. I've seen the same pattern in WHOIS records for presumably legit organizations and in contact addresses on public-school websites.

As for me, from time to time I've had an "@outsourcingcompany.com" address as well as an "@clientcompany.com" address, and it's not always trivial to decide which address to use as the source for certain information, nor which of a similarly situated colleague's addresses to send it to (or to both for completeness).

It's Java, but made worse by the Android ecosystem. Specifically, Android uses Serialization to pass data between mutually non-trusting applications (where the more common case is to pass objects between instances of the same desktop application, or between client/server both written by the same author). Also, the vulnerability arises where serialized objects have fields containing native pointers that aren't marked "transient" or otherwise sanity-checked. Java doesn't have a "native pointer type", but on all current Java platforms a native pointer will fit in a long, so some JNI code does that.

Possibly, although the researchers didn't focus on that, and Google has already distributed a patch for the sub-vulnerability that might have allowed it. The system_server can change SELinux policy and insert kernel modules, and I'm sure someone could write a kernel module to make an arbitrary process root.

Now there's an odd half-hour difference with both land neighbours. On the other hand, now DPRK will have an integer-hours difference between its times and those in India, Iran and Afghanistan.

On a Lenovo T430, the three keys at top-right are "End", "Insert", "Delete". "PrtSc" is between right "Alt" and right "Ctrl", and RHEL6 with Gnome brings up a nice "Save Screenshot" dialog when I click it.

On an HP ProBook 6450b, the three kets at top-right are "pause"/"break", "insert"/"prt sc", "delete"/"sys rq" (where the second function requires simultaneously holding boxed "fn", between "ctrl" and the Windows logo key)

There are OSes and application programs that allow using Caps Lock as a more-general IM switcher, although I don't think I've ever set that up.

Android 4.0.4 on a Sprint device has "System Settings" "Wireless & Networks" "Data usage". It lets you set a "warning", a "limit", shows a graph of cumulative usage over the past month, and also breaks down traffic by app.

1. Cost of putting up signs directing drivers not to use the road
2. Cost of actually tearing up the road
3. Cost of having police patrol the road (on foot, because it's now impassible to cars) to make sure no one has put up a meth lab in the middle
4. Additional travel-time for drivers, truckers, and emergency vehicles who can no longer go through on that road
5. Time and legal fees spent defending against lawsuits from people who complain that one of the above steps was done, not done, or wrongly done.

I can't see that detail in the article or the ARIN announcement. It's a bigger deal if no one can get a /22, but then again if the request was for a /9 that might be a much bigger group of people about to go behind Carrier-Grade NAT.

And that MSDN page says exactly that the "master switch" must be turned on except in certain countries where it must be turned off. It doesn't say that the "share with my contacts" checkbox has to be checked by default. I have a coworker who owned a Windows phone (recently switched to Android), he notes "For XfiniityWifi, it would not work as it would require more credentials (i.e. Comcast Account Information)."

And the comments on that answer say that the "LATEST/RELEASE features" are deprecated or no longer supported, although the links they give to back that statement up are broken.

Fyodor's original message to the "Nmap Development" list includes the following claim:

The old Nmap project page is now blank:

http://sourceforge.net/projects/nmap/

It's true that if you go to the "files" tab you won't see any files. However, the SF blog posting says that Fyodor never put anything in the File Release System, so "now blank" is literally accurate but misleading. It implies that SF deleted something, which they didn't.

The "nmap" project really is just a "placeholder". The FRS part is completely empty. If Fyodor doesn't want to put the current release there because of staleness concerns, fine, but it would be polite to at least put a "README.txt" there with a link to the real distribution-site and an explanation of why he chooses not to host the files on SourceForge.

And I'm not happy about all the recent changes (dropping OpenID authentication, for example), but other changes in the last year or so have been positive, SF is still a reasonable place to host a project, and it's good to not have all eggs in the one basket of GitHub. The field of core-technology-agnostic open-source hosting is shrinking, note last week's termination of CodeHaus and the in-process termination of Google Code (which offers a migrate-to-GitHub service, but also provides a link to SF's migrate-from-Google-Code service).

You can't. In particular,

• "Has the project released files? If not, we will honor the removal request."
• "Projects which have moved to another hosting provider are typically retained at SourceForge.net (though you can make a note on the project web site and project summary page directing users to the new home) for sake of retaining materials of historical value."
• "Projects that are moving to closed source do not qualify for removal."

That would prevent sites from using a cacheable common location, such as the CDNs that host YUI, for assets that are reused across sites.

(plus as already mentioned, .local is for mDNS)

".test" and ".invalid" are reserved, but for special purposes hence not for general private naming (see RFC 6761).

".home", ".corp", and ".mail" are not quite "guaranteed", but ICANN currently intends to "defer delegating [them] indefinitely". See section 5 of the "NAME COLLISION OCCURRENCE MANAGEMENT" document.