Okay this is last month's news and not a joke, but anything that reads like "BigName Telco Admits They Were Evil" has me waiting for someone to say "April Fools".

Take all work you've written and entrust it with someone who will publish it a few years after you die and after your estate is settled or a few years after the last company that would have any claim to it ceases to exist, or after any copyrights or patents other than yours that apply can reasonably be presumed to have expired (probably 95 years after you wrote the code), whichever comes later.

Some code is small enough that it's feasible to prove that the code is correct, assuming that the underlying hardware, libraries, operating system, etc.. don't fail. For example, in most languages you really don't need to put error-checking in code as trivial as this pseudo-code:

boolean isGreater(int a, int b)
{return (a>b);}

Sometimes, particularly when running in "small/tight" or real-time environments or when security is more important than debuggability, you may want a failure to be nothing more than something basic like "return -1" or "turn on aralm and halt the CPU" or even "flush caches, destoy security keys, and power off."

But you are corrent, in most cases good souce code will have good, clear, easy-understand debugging code.

Not encumbered by patents, NDAs, or licensing restictions the keep me from making good use of it.

Tell your real estate agent to include a contingency stating that any deal is contingent on acceptable Internet service.

I'll leave the details of what "acceptable" up to you, but it should be something that's widely available in the neighborhood in which you are looking to buy. The intent is to let the seller know to not waste their time or yours if the KNOW their house doesn't qualify and to put them on notice that any offer is void if it turns out that you can't get Internet service similar to the those living in the same general area at a similar price.

You do have a small risk of "losing out" on a suitable home if the seller is summarily rejecting bids with "novel/unfamiliar/non-standard" contingencies, but you are much more likely to avoid wasting time and money on homes you wouldn't want anyway.

The results were poisoned by the presence of various caches affecting disk I/O and for that matter memory I/O. On some modern systems, either the disk lies to the computer or the OS lies to the application and the application thinks the data is actually stored on the bare metal before it is really stored (the data may or may not be stored in a "safe" place like a non-volatile cache - the point is that a small write operation returns "success" very quickly, much faster than if it had to wait for the bits to be written to the platter).

The only thing they can really say is "on this hardware, using this operating system, under this workload, these are the results of our experiments."

I'm not saying their results aren't useful - they are. Instead of presenting this as "memory writes are faster than disk writes" they should say "in some or many modern systems, under some circumstances, it may be more efficient for programs or operating systems to write to external storage devices in small bits rather than going to extra work to minimize the number of writes to such devices. Don't assume that what was true about the performance of an application calling an operating system to perform a disk-write operation or of an operating system asking a hard drive to perform a disk-write operation is the same now as it was a decade or two ago."

Just don't call them "disk writes." Call them what they are - "requests by the application or the OS to the OS or hardware to perform a disk write."

In security terms, "air gap" should be taken to mean "direct communications gap".

If two machines an "talk" to each other without involving a human or a third-party computer* to do your dirty work for you.

--
*If the third-party computer is being used "in real time" it doesn't count as a "direct communications gap." However, if the computer hijacks the local router in the stand-alone network so that the next time it is hooked to an external network, it does bad things on behalf of the evil computer, that would be an example of "jumping the direct communications gap".

Don't assume your typical non-military-grade-hardened phone is secure unless it's so-dumb-that-its-unhackable* or the phone resides on an isolated network over which you and only people you trust can see.

Even if nobody knows how to compromise it today, you shouldn't assume someone won't figure out how to compromise it "tomorrow".

* think "analog phone on a cross-bar switch" - but even that is subject to hacking, but few people have the skills to do more than a simple wiretap.

Many years ago we had a system admin who used sexual innuendo in root passwords on our non-production research equipment. Thankfully, only a handful of people ever used these machines and they were all in our department.

Within months of my arrival, he was laid off. His skills weren't great but they were good enough to keep him above the "layoff bubble." I have a strong hunch that his sexist style made it easy for his boss to decide to get rid of him.

The new passwords didn't have any sexual innuendo.

At the time, we were a small branch of a research arm of a large corporation. Personally, I found his willingness to use such innuendo on the job distasteful and I found having to type them in on a routine basis uncomfortable but not so much that it was enough to complain about. Now that I am many years wiser and aware of the larger effects that tolerating such behavior has on the workplace, recruitment, and retention, I would probably either ask him to change the passwords or raise the issue with his/our boss.

For non-citizens and others without an automatic right to entry, the penalty for disobeying directives from customs agents for those violating "border-only" rules (i.e. not rules that apply inside the country such as assaulting a government official) should be denial of entry.

For citizens and others with an automatic right to entry, the person should be given a choice: Voluntarily go back and come back another time when they are willing to obey the rules, or be arrested/cited for violating whatever law they broke.

I wonder if anyone has made a hardened version of the original "www" browser.

Being text-only and lacking support for just about everything, it should be relatively easy to make almost bulletproof.

If it's THAT sensitive, either have the customer pick it up from a Cisco-controlled location or have a Cisco employee hand-deliver it to the customer.

Use tamper-evident seals and use something like a "warrant canary"-like system so the delivery person can effectively tell the customer that to the best of his and Cisco's knowledge the shipment was not tampered with en route: The absence of a followup message from Cisco guaranteeing that the shipment and delivery were not intercepted would be treated as a message that it might have been intercepted.

Speaking of "canaries" I wouldn't be surprised to see specialty shipping companies or specialty-arms of big-name shipping companies use "canaries" to guarantee that their shipments were delivered to an authorized person and not tampered with en route.

I don't have a problem with EUFI or BIOS being flashable. But you need a non-changeable way of recovering your system to prevent "permanent" p0wnership or brickage.

A non-flashable "pre-EUFI" firmware that did nothing but check if a certain jumper pin was set and either proceed to boot to EUFI or boot to a non-flashable "EUFI re-flash loader" utility is a must for any computer that doesn't need to be "locked down" at the factory. This utility would look in a standard location - perhaps USB port 1 - for a signed executable that would be the real "re-flash" utility. Whether motherboard vendors chose to supply signed re-flash utilities that only re-flashed signed EUFI binaries or if they catered to hobbyists who might want to load arbitrary/unsigned EUFI binaries would be up to the motherboard manufacturer.

Bonus points if the immutable "EUFI re-flash loader" utility calculated and displayed a cryptographic hash of both the current EUFI and that of the real "re-flash" utility the user is trying to use PRIOR to executing it the so the user could verify that they are what he thinks they are.

For computers running in specific environments that need to be "locked down" at the factory, re-flashing the BIOS would probably not be allowed at all - EUFI changes would probably require chip- or motherboard-level surgery.

Color-stable archival film with color-stable archival prints in case the film isn't as color-stable as you hope. If you can do a second film conversion using a different type of film that would be good also. If this was for more than 100 years I would also suggest color-separations done on archival black-and-white film.

For audio, do on-film audio, a phonograph record on archival materials, and an analog magnetic tape using a recording mode that was in common use for decades, on archival materials.

In addition, I would supply DVDs on archival material, a rugged DVD player likely to still be playable in 100 years, a printed copy of the manual and a printed copy of the DVD specification, all on archival paper. If space precludes the use of printed manuals, a micfofilm copy is fine, just put it on archival materials.

Answer: Because the government dragged their feet 2-3 decades.