I don't know of any FBI-specific issues with DNA work; but various crime labs have had issues with atrociously sloppy practices that tend to go unchallenged, or overtly hidden, for some years. The big FBI story is definitely the "yeah, we basically didn't do a single hair analysis right for two decades; also hair analysis in general is probably bullshit" issue.

In general, DNA-based techniques have the advantage that they are actually 'science', as originally developed by scientists looking for useful research tools and facing some possibility of falsification, embarassing retractions, etc. It requires some skill, and considerable attention to good standards of cleanliness, bench technique, etc.(especially if PCR is involved; that technique is practically black magic it's so good at picking up otherwise impossible to detect DNA; but it is equally good at amplifying your accidental contamination of the sample by a few orders of magnitude)

Much of the rest of forensic 'science', is little better than polygraphs and phrenology. 'Bite mark analysis', in particular, is a tragicomedy.

The consumer version bears a disconcerting resemblance to a coffin for a particularly obese child; but I'm liking the looks of the rack-based unit.

This might have something to do with a recent spate of obnoxious fights with some of our APC UPSes and their surprisingly touchy and death-prone lead acid battery modules. Even when the UPSes themselves arent' dropping dead, swapping out SLA modules every 2-3 years, at best, gets real old, real fast.

This isn't even a good troll. If you don't know one actor-model programming language and one pure functional programming language, then you have no business describing yourself as a programmer. You certainly don't get to use your ignorance as the benchmark for others.

Various ML dialects had that before Python. The thing Python brought was a poor performance implementation of a language from the C++ school of language design: keep adding features without regard to how they interact and expect programmers to know all of them (if they ever work with anyone else) but only use a subset if they don't want totally unmaintainable code.

Understanding monads is very helpful if you're writing code that wants to do speculative execution or is highly concurrent, even if you end up implementing the code using something purely imperative.

Not everyone can learn to win Olympic races, but most people can learn to run moderately competently. Not everyone can learn to be a great manager, but most people can learn not to be an incompetent one.

He is probably the most effective example in reasonably contemporary history. Which isn't terribly impressive given that most people couldn't actually tell you what he was for or against, his activities had no visible effect on any federal activity he was against, and he ended up getting executed, and his main assistant sent to ADX Florence to rot more or less without controversy.

Also (like most people who want to get some asymmetric warfare done) he didn't bother with the abject futility of a gun battle against superior forces, and opted for explosives and stealth instead.

Definitely the best example available; but not...exactly...a striking demonstration of effectiveness.

People do enjoy saying that; but that doesn't seem to change the more or less total absence of any repressive measures, activities, or persons being literally shot down. Maybe whoever pinged a few rounds off the NSA's windows deserves some credit for effort; but he's pretty lonely. Hell, the last person to even unnerve the DC area was probably the beltway sniper, and he was some shithead gunning for his ex wife or something. Seriously guys, let's see some blood of patriots and tyrants, or the admission that guns are a fun hobby; but spare us the empty chest-beating nonsense.

I just can't believe that an agency that (voluntarily, no less) works out of a headquarters named in J Edgar Hoober's 'honor' would have some ideas about encryption that are anything other than technologically cutting edge and fourth amendment compliant. They should probably just stick to doing their...special...brand of forensic science and leave policy to people who don't goose-step to the short bus every morning.

For the branch instructions with the reused opcodes, this means that you need to do it up front. This means that things like JVMs and anything else with a JIT requires rewriting. This is where a big part of the cost of the software ecosystem comes from. It also means that disassemblers and debuggers (which are another big investment) also need significant rewriting, rather than just adopting.

Trap and emulate and trap and patch will only work if your MISPr6 processors have a special mode that will trap on any instructions that have had their opcodes reused. In such a mode, trap-and-patch usually won't work, because the compact branch instructions that are intended for use in the patching are in this set.

The new ISA is a lot nicer than classic MIPS, but it's almost as much effort to support in software as RISC V or ARMv8. This is part of the reason why we (with my FreeBSD hat on) have been working closely with Cavium on ARMv8 recently. Existing customers for Cavium's MIPS parts (certain storage and networking vendors) have looked at MIPSr6 and seen that the cost of migrating their code from MIPS III or MIPS64r1 to MIPSr6 is about the same as the cost of migrating to ARMv8. They've also seen the lack of serious investment in LLVM (until very recently, and even then it's far smaller than ARM alone - Apple, Google and ARM are investing an order of magnitude more effort than the MIPS ecosystem) and decided that it's worth working out the cost of an ARMv8 migration.

I mentioned this to Daniel over a year ago, but apparently ImagTec decided that keeping their customers' customers on MIPS wasn't a priority.

The real problem here is that IT is regarded as something like a janitorial service, rather than an integral business function. That's a recipe for a slow burn into the ground. There is plenty of cog work to be done, sure. But if you don't use IT to actually change how you do business, you're not doing IT.

I'm not surprised then that Disney is only making money by buying IP, and riding old IP. They're organizationally prohibited of producing something new.

You're in the Bay Area and out of work? Fuck, they're hiring here like it's 1999. If you don't have a job right now, it's your own problem.

This is exactly my problem with Apple and many other product designers. Phone screens that don't work with gloves. Phones that aren't waterproof. Phones that can't have the storage upgraded or battery replaced. Self driving cars that can't handle rain and snow. There's a lot of products out there that only work in very specific conditions and that fail when used outside the very narrow range in which they were tested.

I don't think I've known anyone to use an iPhone for 5+ years. I'm not saying it doesn't happen, but it's probably very uncommon. Most of the people using old iPhones constantly complain about how the updates to the OS slow it down. Updates are great for security, but when they ruin the user experience by slowing down the device,

There are two problems with this idea. The first is that EMPs, like other EM phenomena, disperse via an inverse square law. Anything high enough to be line-of-site to the ground in most of the USA would need to have an enormous explosive yield (even by nuclear weapon standards). There are some designs that try to channel more energy into the EMP than normal, but they're very complex to build (a good 10-20 years more R&D beyond the Fat Man / Little Boy style bombs).

The second problem is the delivery. Iran does not have a significant ballistic missile capability. Getting something into space above the USA would require launching something in a suborbital trajectory. A very high suborbital trajectory if it were intended to explode that high up. The size of such a rocket would be such that it would be pretty hard to miss on satellite observation. The time in the air would give the US a very long time to formulate a response and destroying it would be relatively easy (remember, the problem with strategic defence shields in the cold war was not shooting down a missile, it was shooting down the large number of real and decoy rockets that the Soviet Union was capable of launching).