OpenCL is highly specific in application. Likewise, RDMA and Ethernet Offloading are highly specific for networking, SCSI is highly specific for disks, and so on.

But it's all utterly absurd. As soon as you stop thinking in terms of hierarchies and start thinking in terms of heterogeneous networks of specialized nodes, you soon realize that each node probably wants a highly specialized environment tailored to what it does best, but that for the rest, it's just message passing. You don't need masters, you don't need slaves. You need bus switches with a bit more oomph (they'd need to be bidirectional, support windowing and handle multipath routing where shortest route may be congested).

Above all, you need message passing that is wholly target-independent since you've no friggin' clue what the target will actually be in a heterogeneous environment.

Hemp turns out to make a superb battery. Far better than graphene and Li-Ion. I see no problem with developing batteries capable of supporting sub-zero computing needs.

Besides, why shouldn't public transport support mains? There's plenty of space outside for solar panels, plenty of interior room to tap off power from the engine. It's very... antiquarian... to assume something the size of a bus or train couldn't handle 240V at 13 amps (the levels required in civilized countries).

Very true, but without it, we're doomed to reinventing wheels, redoing research and coming up with suboptimal solutions that are harder to program, harder to maintain and bloated with helper functions that would have come as standard otherwise.

Such a table can be written once then updated every 5 years. Reading it simply amounts to feeding into a parametric search routine what you know you will need to be able to do. You will then get a shortlist of languages ideal for the task.

Now, it comes down to two simple questions: are your requirements ever stable enough or clear enough for such a shortlist to be useful? Do you risk overoptimizing on a set of criteria that may have no resemblance to the reality of the problem or the reality of any solution the customer will sign off on?

If the answers are "yes"and "no" respectively, I'll start the list today.

You need single isotope silicon. Silicon-28 seems best. That will reduce the number of defects, thus increasing the chip size you can use, thus eliminating chip-to-chip communication, which is always a bugbear. That gives you effective performance increase.

You need better interconnects. Copper is way down on the list of conducting metals for conductivity. Gold and silver are definitely to be preferred. The quantities are insignificant, so price isn't an issue. Gold is already used to connect the chip to outlying pins, so metal softness isn't an issue either. Silver is trickier, but probably solvable.

People still talk about silicon-on-insulator and stressed silicon as new techniques. After ten bloody years? Get the F on with it! These are the people who are breaking Moore's Law, not physics. Drop 'em in the ocean for a Shark Week special or something. Whatever it takes to get people to do some work!

SoI, since insulators don't conduct heat either, can be made back-to-back, with interconnects running through the insulator. This would give you the ability to shorten distances to compute elements and thus effectively increase density.

More can be done off-cpu. There are plenty of OS functions that can b e shifted to silicon, but where the specialist chips have barely changed in years, if not decades. If you halve the number of transistors required on the CPU for a given task, you have doubled the effective number of transistors from the perspective of the old approach.

Finally, if we dump the cpu-centric view of computers that became obsolete the day the 8087 arrived (if not before), we can restructure the entire PC architecture to something rational. That will redistribute demand for capacity, to the point where we can actually beat Moore's Law on aggregate for maybe another 20 years.

By then, hemp capacitors and remsistors will be more widely available.

(Heat is only a problem for those still running computers above zero Celsius.)

So does ./ have some kind of promotional relationship with startswithabang? If so you should disclose it.

The blog does have interesting material, and its appropriate for /., so its not like its bad that every article on there is making the /. front page. But its kind of odd that every article on there is making the ./ front page.

They did, at one point. They bought the rights to StrongARM and sold it for some time, then abandoned it completely.

Power is governed by change of states per second. It varies by the voltage, but by the square of the current. There's only so much saving from reducing voltage, too, as you run into thermal issues and electron tunnelling errors.

You are much, much better off by saying "bugger that for a lark", exploiting tunnelling to the limit, switching to a lower resistance interconnect, cooling the silicon below 0'C and ramping up clock speeds. And switching to 128-bit logic and implementing BLAS and FFT in silicon.

True, your tablet will now look like a cross between Chernobyl, a fridge-freezer, and the entire of engineering on the NCC-1701D Enterprise, but it will now actually have the power to play those 4K movies without lag, freeze or loss of resolution.

Modern programming languages are a fusion of older programming languages, with chunks taken out. Often, it's the useful chunks.

There is no table, that I know of, that lists all the features ("significant" depends on the problem and who cares about solved problems?) versus all the paradigms versus all the languages. (Almost nothing is pure in terms of paradigm, so you need a 3D spreadsheet.)

Without that, you cannot know to what extent the programming language has affected things, although it will have done.

Nor is there anything similar for programming methodology, core skills, operating systems or computer hardware.

Without these tables, all conclusions are idle guesses. There's no data to work with, nothing substantial to base a conclusion on, nothing to derive a hypothesis or experiments from.

However, I can give you my worthless judgement on this matter:

1) Modern methodologies, with the exception of tandem/test first, are crap.
2) Weakly-typed languages are crap.
3) Programmers who can't do maths or basic research (or, indeed, program) are crap.
4) Managers who fire the rest of the staff then hire their girlfriends are... ethically subnormal.
5) Managers who fire hardware engineers for engineering hardware are crap.
6) Managers who sabotage projects that might expose incompetence are normal but still crap.
7) If you can't write it in assembly, you don't understand the problem.
8) An ounce of comprehension has greater value than a tonne of program listing.
9) Never trust an engineer who violates contracts they don't like.

http://arxiv.org/abs/1210.1847">No.

Please stop assuming you're intelligent, you're just embarrassing everyone else.

Not clear if Case is claiming Blackberry's were never of interest to hackers or are just of no interest lately.

Blackberrys were until recent years very high value targets, they were the phone of choice on Wall Street, for politicians and reporters.

It wasn't that long ago repressive regimes like Saudi Arabia were telling Blackberry to back door their phones/servers or get locked out of their market which tends to suggest they must have been pretty good at something.

There is probably something to be said for phones without a third party app market if security is job one. Android in particular is a pretty juicy target for malware.

Given that physicists are seriously studying whether the universe is a computer simulation, that joke might not be too far from the truth. You have been warned.

These theories have their own problems. As noted on Slashdot previously, neither exist around dwarf globular clusters or in the local region of the Milky Way. It is not altogether impossible that our models of gravity are flawed at supermassive scales at relativistic velocities, that there's corrections needed that would produce the same effect as currently theorized for this new kind of matter and energy.

Remembering that one should never multiply entities unnecessarily, one correction factor seems preferable to two exotic phenomena that cannot be directly observed by definition.

But only if such a correction factor is theoretically justified AND explains all related observations AND is actually simpler.

There is just as much evidence these criteria are true as there is for dark stuff - currently none.

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.