I've mentioned this before... but times have changed. For better or for worse, BitCoin is the currency that people have latched onto, similar to how Facebook is the social network of choice these days.

Even though there are details that the currency is fraught with, it is becoming stable and accepted by the mainstream, where it is becoming trusted enough for people to actually not just use it for a means of exchange (quickly changing from their preferred unit of stored value to BTC, then the seller quickly changing from BTC to their favorite unit), but as a means of holding wealth, since it is a deflationary currency.

Satoshi has dropped out of sight long enough that statute of limitations laws are going to come into play soon, especially once the seven year mark hits. The only two things that are able to be used in the US are murder or failing to file a tax return, and an anonymous entity has no requirement to file a tax return.

Even if taxes are involved, it would be similar to capital gains. Satoshi would not have to pay taxes until those coins are sold or exchanged. If kept "under the mattress", they can legally stay out of play indefinitely.

A local place (Solid Concepts) made a 1911 out of DMLS sintered Iconel. All parts including the barrel, sear, trigger mechanism... everything but the grips. It didn't blow up or have any issues after 1000 rounds ran through it.

Mitsubishi has a DMLS machine that does both the sintering and machining (both additive and subtractive), which not just would allow a 1911 to be made, but the parts coming out just needing final assembly.

Of course, there are other uses than firearms.

I remember it called stereolithography, but that was mainly a type of 3D printing that used a laser and either a photosensitive liquid or powder which fused together, combined with a tray that slowly moved.

These days, I'd just go with a DMLS setup, since if I use a decent Iconel alloy, the finishing/grinding/polishing needed iis minimal.

Even with programs that can import Word/Excel/etc. documents, they do a good job, about 99% well. However, that one percent that is missed can do quite a number on a document.

The answer for a document format... depends.

For a document format that keeps formatting exactly, and isn't intended to be edited, PDF/A is the best thing going, since barring a major world-ending disaster, we will still have utilities that can read PDFs, and PDF/A ensures that the fonts and such are present and readable.

For a document that is edited... there are a number of different standards. As stated elsewhere, it might be best to have a tarball or ZIP file that has multiple document formats in it, where there is a .txt and .PDF file available for quick viewing, then SGML/HTML/XML/nroff/TeX/LaTeX version included for editing.

With all the UI churn of not just Gmail, but every other provider, I've thrown in the towel, and just use a decent MUA (Thunderbird for E-mail, Outlook for calenders/meetings/tasks/contacts.)

A MUA is a lot more resistant against attack than a Web browser, and gives more options when it comes to rulesets (I can move vital E-mails that hit Yahoo to my hosted Exchange server which I actually look at.) Plus, I can use features like PGP or S/MIME quite easily with it.

If it has as good structural strength as TFA states, this would be very useful for automobile or RV applications:

1: Rodents are not going to chew through it, which can make it useful for walls.

2: If it is good at handling deformation resistance, it might be able to be used in car doors for better safety in T-bone wrecks.

3: If it is resistant to tools, it might be useful to slow down the meth-heads who like using a long screwdriver as a master key in RV storage lots.

This technology has a lot of promise... maybe even in aerospace applications.

I'm curious about its properties as an insulation. It might be useful as both an insulator and as a load bearing material, either alone, or perhaps as a composite.

When cleaning PCs of malware, almost all of them have either perfectly functioning AV programs, or appear to do so. AV is useful on a legal eagle standpoint [1].

As a usable tool of defense, I'd say that adblocking, blocking by IP address, using a hosts file, virtualization, and putting the web browser in a container/sandbox/VM will go far further in keeping malware at bay than any AV program. That, and not running randomly downloaded executables.

We have had oddball places to store code since early on. In the early 1990s, System 6 and 7 would rely on a stub of code coming from a SCSI device as a driver, unless the code was furnished via an extension. One could easily hide code in there, which would be one of the first things loaded on an internal SCSI drive, and couldn't be bypassed. Just plugging the drive into another Mac would get the hard disk driver to load and run that code on the second Mac. That combined with WDEF or CDEF made for a nasty infection vector... just insert a floppy, and the machine was pwned. Thankfully nobody made a virus that infected the Mac hard disk driver (at best, there was code that would check if a program was running and hide the drive from the system, as with Highware's FileGuard, Kent-Marsh's NightWatch, or Kent-Marsh's Folderbolt.)

[1]: Even on AIX LPARs, having McAfee run from two cron tasks... one to fetch definitions, the second to scan the filesystem, is good enough to check that "all computers have AV installed on them" box.

You may notice that, as well as most Slashdotters... but how many users actually know anything about performance baselines or know/care about that?

Most users will just complain that their laptop's battery life is shorter and that their laptop runs hotter, maybe blaming the PC maker on the topic.

You can't really hide GPU usage, but most users or AV software are not going to be looking at that subsystem. Think Life of Bryan and the Roman legions searching one house multiple times. They won't check what is holding up the lampshade.

It wouldn't be nice, but it wouldn't be the end of the world. The US has a ton of fabs, most of it ASIC work. If the fabs overseas were destroyed, it might take a year or so to build the latest and greatest on US soil, but it is doable.

Even without the latest generation, there is a point where general purpose CPUs are "good enough", so even a 1-2 generation back fab would still be useful.

ARM is even easier.

The big worry is the fabs for SSDs, RAM and storage. CPUs are something that has some give.

"Suit wearing chatter monkey" describes so many of those out there out there, especially "security consultants" which are sprouting up left and right. I have cleaned up the messes that those types leave behind, especially after they "do" a job for six months, and the fundamental issues are still present. Usually they may be familiar with one tool, and because they have that hammer, everything is a nail.

I can see the NIH mentality of embedded programmers, since those are the types who usually are proud of the fact that their code is as close to mathematically perfect as one can get. A probable compromise is to hand them the libraries, then demand that their code match the testsuite given to ensure their stuff encodes/decodes correctly. It may not be perfect, but at least it will pass muster in that respect. The ideal is to use a known, tested, certified library, but rigorous testing of a reinvented wheel is better than nothing.

Homegrown crypto has been a constant menace since the 1990s when people sold numerous encryption programs, usually sporting their own encryption algorithm and DES.

A few I've seen were running 1-2 rounds of DES at most (FWB Hammer's hard disk drivers for Macs did this, but at the time, it was the best encryption one could get due to the relatively slow CPUs like 68000s at the time.) Others were seeding random() with a CRC of the password and XORing the output with the plaintext.

However, back then, there were no government entities standardizing functions like is done now with AES, RSA, and other algos, so people had to write their own, and if it jumbled and unjumbled stuff, it was good enough, since not much in the way of ciphertext was really being attacked.

Times are different now.

These days, with most ARM, AMD, SPARC, POWER, and Intel CPUs having hardware AES acceleration, why would one want to roll their own algorithm?

If one thinks AES is backdoored, cascade it with another known good algorithm like SERPENT, Threefish, heck, maybe even an older one like IDEA, 3DES, or even 3-Skipjack. There are other less known algorithms which have withstood testing as well. Cascading isn't intended to expand the bit width, but to have protection should one algorithm get broken. TrueCrypt offers/offered this functionality.

Same with public key algorithms. Worried about RSA? Have two signatures, one RSA, and one with ECC or a lattice based algorithm that is resistant to TWIRL and quantum factoring, and validate both sigs.

As for crypto implementations, if a user needs to encrypt a file, OpenPGP is a known standard. For communicating across the wire, SSH and SSL are known standards that are decently robust. For encrypting stuff in RAM, almost all modern operating systems have a facility like KeyChain to keep sensitive data from being swapped out, or if it is, have it encrypted.

With almost every programming language offering hooks for AES and RSA, there isn't a need to roll crypto, even for obfuscation reasons. If one just needs obfuscation, use an AES() function with all zeroes as the key.

At the time, it was OK to publish source code in a printed book... but stored online as a computer document and exported, it was an ITAR violation. So, one encryption company (think ViaCrypt) printed out the source code of PGP and made a book out of it, which was freely and legally exported. Then it was scanned in and OCR-ed for the source code.

This is one reason why that law eventually just got pulled, and export limited to the few countries on the blacklist.