Assume the server has a database of hashed passwords, using one of the now vulnerable hashing algorithms. What the client is sending is for example a https encrypted password, not a hashed password? if you are the man in the middle, you are dealing with encryption not hashing? The https request is decrypted on the server, the plaintext client password is then hashed and compared to the hash in the database. I don't see how a man in the middle is related to hashes? (Then again I'm not a security guy in any shape way or form). As far as I know hash vulnerabilities are mainly a concern when the password (hash) datbase is compromised, which happens sooner or later.

Thus not only proving they didn't read the article, they didn't even properly read the title. "restore GAINS of moores law". Which is perfectly correct.

This research doesn't change that. What parallel programming is about, is currently three steps 1) find parts of code that can execute in parallel (reasonably simple), 2) make sure there is no shared mutable state (hard), 3) make correct threading implementation (tedious

The problem with todays (OO/imperative) languages and tools is that it is exceedingly hard to make sure that state isn't shared. It is also very hard to test for, and find bugs related to shared state. This research helps with step 2. You still have to figure out where these boundaries are, but you can make sure it is correct, by letting a compiler check this for you. It can also help you with step 3, but if your assumptions are correct that isn't hard in current tools, just tedious. Things like TPL and PLink have greatly simplified step 3), but what I assume MS have found out is that with such power to parallelize, developers are spending more and more time in step 2, thus gaining very little.

Maybe read the article? Maybe just the title? "Help restore the GAINS of Moores law.". That is, since these days the extra transistors we put on cpu:s just go to more cores and not faster cores, we don't gain as much as we used to until 2004. These days to actually GAIN from Moore's Law, we need code that actually use these transistors, i.e. parallel code.

Shorter article:

Installing huge enterprisey things SAP and Oracle software is harder than using a package manager to install Apache.

Funny the article/link/source didn't show up now that you mentioned it, either.

For a long while I thought Mitt's official twitter account was a parody account.

Quite a few things, for example less sword rattling in the Iran/Israel region (A war would reduce US purchasing power and affect global economy just like Iraq did). Less of a "trade war" with China (calling them a "currency manipulator on day one" certainly doesn't help trade & relations.

Apart from these things that actually may affect me, I'd enjoy seeing that the greatest power in the world can hold an election that can't be bought or stolen by special interests. Would also be refreshing to see that the greatest democracy in the world have policies on reproduction/abortion/education/science that can't be mistaken for Taliban policies. That, and watching Fox News pundits heads explode for a week.

Let's just say that however flawless the language, you will still make countless simple mistakes in *logic* that will be an order of magnitude quicker to diagnose and fix with an integrated debugger than with any non interactive means (logging, exception stack traces, command line debuggers).

I would argue the opposite. If you execute code it will invariably do things you didn't expect, regardless of language. You either debug or guess. I saw no argument as to why guessing is preferable to interactive debugging? I agree that "null" is a language smell, but there are concepts like code contracts that lets you have non-null enforced etc. There are a million other things you can debug regardless of language.

Most bizarre conclusion I have ever seen. Of course you can have highlighting and other editing tricks (autocomplete, etc.) in a text editor. But once you add things like unit test integration, deployment, and most importantly an interactive debugger where you can step through your code, you have a proper development environment. Running tests can be done at a shell prompt, but debugging not so much. And if your text editor ticks all these boxes, including interactive debugging (I'm sure emacs can for example), then your text editor IS A FREAKING IDE ALREADY. I'd like to make the inverse conclusion of TFA: since we have proper IDE:s we can now allow the code in modern languages to be structured an way we want. A good IDE should never have you worrying about files, just code.

The use of modern tech does not imply better code, but it certainly helps your work environment. A company that is quick to adopt new technology (e.g. Update to new language versions) has a better possibility than a company that doesn't. Make sure you talk to the guys involved with the technology. Interviews and screenings with recruiters are quick affairs, save your questions until you meet real developers. If the company doesn't have the actual developers and team leaders doing interviews, that is not a good sign. Third, make sure you find out how fast the crew is being replaced. A team of ten should have at least a few that have been there virtually forever, and you don't want to join that team if it has recruited 20 developers over the last 5 years. This is the most important thing: you want the same as every other developer out there. So a company where people work 1-2 years either has a technology problem or a serious pay/environment/cultural problem. Either way, you don't want it. Ask how many have left the last few years, and try to find out why. If you can't get this information, leave.

Regulating idle power draw would actually be good, and a lot more clever than regulating the power ceiling. Saying that desktop computers can't use more than 10W in idle, and no component sold discretely can use more than 5W idle would make a huge difference. In reality, those of us running these 300W graphics cards only run them for a fraction of the day, and if they were 150W instead would make much difference, whereas a difference between 20W and 10W for the idle power would make a bigger difference over a week or a year.

This is a usual complaint with regulations such as this. The other obvious example is the light bulb ban. The problem with your approach is that adding a tax on electricity that is big enough to give an impact on peoples' shopping behavior when it comes to light bulbs, would mean industry would pay through the nose for electricity that actually creates jobs, and electricity that does work that can't be done more efficiently. The difference between that electricity and a light bulb is that at low power bulb can light a room with much less power than an old style 60W bulb. If we increase electricity taxes and don't wan't to lose competitive power in our industry, then we have to have a VERY complex system of energy subsidies to industry. A simple ban on a few consumer products is way simpler to implement and regulate, even though it might seem like micromanagement.

Probably more common in developed countries where VAT and customs would actually amount to something. UK and Sweden have been mentioned already. Ordering something from the US to sweden usually means the price will be about equal to swedish street prices (Add 25% VAT and a bit of customs as well as freight cost).