I definitely second that.

As an aside, you can generally expect a router to support things it does properly, at least you should be able to. Haven't seen too many routers certified as IPv6-ready (there's a comprehensive test suite out there by TAHI, it's not like it would be hard to verify) or even IPv6-capable, although a good number are both. So you can't trust the advertised capabilities as being either complete or correct.

There may also be hardware weirdness that means a feature won't work as expected whether with the regular firmware or a replacement.

Getting just the brand and revision is great, if you only want basic stuff. Which is most people. For freaks and geeks, we could use knowing if there's any really big, ugly omissions.

(I've done compatibility testing between network cards. It is unbelievable - or, at least, it should be unbelievable - how many network chipsets are defective. It's mostly obscure stuff, but bad silicon is expensive to fix, so you'd expect halfway decent testing. It just means all routers will do weird shit, so it's handy to know if it's weird shit that's likely to be a problem.)

Comcast failed to implement the duck switch. They do support rat, pig and ferret, though.

You might want to check out NIST's page on authenticating+encrypting modes.

You might want to look at Diffe-Hellman key exchange, where nothing is provided that cannot be entrusted to a wiretapper.

You might want to look at the Byzantine class of problems and their use in encryption.

You might want to look at the reasons for and against random oracles.

I see very, very little in cryptography that has to do with trust. Almost everything is dedicated to assuming that nothing can be trusted. People are encouraged to compress data before encrypting it because even the maths isn't trusted.

Android is not Java. Android is Linux with a JVM set up as an "other binary format" engine.

Most of what you're complaining about is in the standard library, not the core language. The standard library is semi-open, you can alter the code, rip out what you don't want. Only the core language is Java, the rest is just a programming aid.

As for what COBOL has, Admiral Hopper was running software on a non-networked sequential architecture. This is rather different from operating in a multicore SMP-architectured server farm. There is nothing complicated about parallelism, but naivety and self-blinding are two great ways to make every mistake in the book - and then some.

Stability, predictability and reliability could be done with Erlang, Occam, Eiffel, Smalltalk or Ada.

Business could have build "enterprise" applications with any of these. Most existed before Java or, indeed, the web. Servlets could have churned out WAIS or Gopher data for businesses. Graphics, via SGI's VRML, Apple's Postscript or the ancient GKS standard, could have given you everything that Swing delivered. Not that businesses use Swing, as a rule.

Portable applications in the form of Tcl/Tk packages could have provided everything Java applets did. Not that anyone uses applets either.

It should be self-evident that absolutely bugger all of the usual explanations hold water. If the explanations were valid, the role would already have been filled and Java would have never taken off.

Businesses flocked to Java and not to any other technology. Even technologies pushed by very large corporations. Businesses liked, and like, Java. That is obvious. "Why" is not obvious, Java does nothing that couldn't be done better in other ways. It isn't done in other ways, it's done in Java. There will be a sound reason for this, but it won't involve stability, reliability or predictability.

Oak was originally designed for household appliances.

D looks intriguing, certainly superior in theory to C++ or C#, but I'm seeing nothing substantial in it so far.

For other C derivatives, there's Aspect C and related attempts at adding high-level abstraction. On the other end of the spectrum, you've Silk and UPC - efforts to make parallelism simpler, safer and usable. Again, though, how many here have even got these compilers, never mind written anything in them?

For highly protected work, Occam-Pi is unbeatable. And almost unusable. Extraordinarily powerful, but extraordinarily formal. You could easily write an OS or virtual machine using it that could exploit multicore, SMP and clustering transparently. You just couldn't easily get it to do anything else, like hot-swap resources, add memory, access the busses, support RDMA, exploit hardware...

That's the rub. Most of what is needed in an OS is inherently unsafe. It's why there's so much interest in splitting operating systems into unsafe parts (which often need to be fast and low-level) and safe parts (the stuff that does all the managing and abstraction). So long as the unsafe parts are well-behaved with valid data AND the safe bits provably give only valid data (though it doesn't have to be provably correct), then the system is guaranteed to be stable.

You ideally want to split these up further. The safe bit should access an independent security kernel that handles all the access control, for example. The security kernel should be provably correct, which is a very different constraint than that imposed on other safe sections. Some sections of code should be able to self-replicate or migrate, to take advantage of resources rather than create bottlenecks. That would require greater emphasis on abstraction and adaptability, rather than validity or correctness.

No single language can handle this level of versatility. All languages obtain specific characteristics through constraints and freedoms. This means you need superior linkage between languages and optimization that takes into account that different paradigms are used to solve different problems and that there is insufficient data to optimize at compile time, that it has to be done at link time.

I've been pointing out the risks of router poisoning for, what, 17 years now.

Ever since the NSA started demonstrating router poisoning, it was only a matter of time before even the script kiddies figured it out.

I've been pointing out that the current rash of cryptocurrencies have excessive reliance on trust for the past year.

This sort of attack was inevitable. Bitcoin can plead semi-innocence because strong authentication is counter to strong anonymity. However, no router on the Internet should accept rogue announcements - even from three letter agencies - or accept unauthorized changes to the running configuration or active router tables.

MITM attacks are exceptionally dangerous and the hazards can only get worse.

IE is supported? When did this happen?

Last I heard, they reluctantly release updates when other parts of the OS beat them on bugs per kg of code. (They stopped measuring lines when someone googled the term.)

I wouldn't worry too much about Fukushima, per se.

It's the fact that the State Secret law passed days after the abandonment of the pacifist sections of the Constitution, at a time Japan desperately needs to get rid of masses of deadly radioactive material, that you need to concern yourself with.

The union of the two sets is not equal to the universal set of all nuclear power options.

Your argument is therefore irrelevant. Please meme and try again.

I can accept that, but with reservations.

A lack of timely information lies at the heart of all nuclear accidents, large and small. It would seem to follow that to improve safety, you'd want to improve on sensors - the number, resilience and backups.

They were using helicopters, IIRC, which raises the question of what cameras and other sensors could have been used on those helicopters to fill in the gaps in their knowledge.

Did they try firing simple rockets into the reactor core? Something capable of carrying a rad-hardened instrument package and a transmitter capable of being received by a helicopter. A camera, a spectrometer, a thermometer even. Something that would extend their knowledge of the problem.

If they failed to make any real effort to prepare an adequate sensor grid in advance and failed to take basic steps to minimize uncertainty, then blunders from a lack of knowledge can't be blamed simply on that lack of knowledge. It stops being one of those things and starts looking like a massive failure and disastrous incompetence.

Back when the accident happened, a significant number of Slashdotters were saying that no meltdown had occurred, that there was no significant structural damage, that no radioactive material would reach the sea, that the incident was overblown and that the plant would be largely still operational.

At this point, the discussion is not about how thoroughly the facility has been totalled but in what way.

I don't care that there was limited data available at the start, drawing conclusions from data you don't have (aka making things up) is not an excuse. If you don't know, don't pretend you do. It is because TEPCO pretended that they knew that the world lacks much-needed nuclear power. It is because TEPCO made things up rather than obtained data that an accident was possible. Don't be a TEPCO.

For those who defended the company, who downplayed the crisis as a nothing, who ignored any available information that didn't suit their preferred outcome, I am still awaiting an apology.

An apology for deliberate pollution of the debate
An apology for every post by every sceptical slashdotter modded to oblivion for the purpose of stifling debate
An apology to Slashdot itself for so abusing the moderating system
An apology for depriving the community of your own thought processes
An apology for not once, in all subsequent Slashdot debates, conceding that honest debate is superior to dishonest control

Maybe, by 2024, pride and conceit will be at levels where this is possible.

Assume they cracked the NSA backdoor default password and can now access everything on every computer not running a hardened operating system. In other words, everything, whether you change your passwords or not. Further, assume they have remote access via UEFI to every motherboard built in the past year.

You might as well, that level of access has been built into modern technology, if this group hasn't figured it out, someone will. Or maybe already has.

We live in an age where technology is insecure by design. You can either abandon all hope (my preferred option) or you can adjust your approach to not depend on external security.