Um, no. All of the standard hashing algorithms return a fixed-length value. Collisions are certainly possible, but because the algorithms are strong, the chance of a collision for anything that's likely to be used as a password has an extremely low probability.

Except that they do have the passwords, because of tools like HashCat that allow ridiculously-fast brute-force attacks on hashes, combined with statistical analysis of previously-stolen and -decrypted credentials to figure out the patterns that people use to create passwords (e.g. dictionary word + three digits + punctuation). Using salted hashes is great, but it only slows down the retrieval of passwords - it doesn't prevent it.

Yeah, and the first time that any one of those passwords is cracked by someone using e.g. HashCat, they will add your logic to the list of methods that are commonly used by people when creating a password, and now all of the other historical hashes that have been stolen from accounts you set up are now compromised as well.

This is actually pretty terrible advice these days, because if something requires a separately-stored password (IE it is not integrated with your central auth system), there is a good chance it is transmitting or storing the password insecurely. Now your users have compromised their main account as well.

That password would fall to an offline hash attack in minutes or seconds. And since it's procedurally-generated, again, now whoever cracked it can add your logic to the list of commonly-used methods, and crack all of your past and future passwords even faster.

We do that because the assumption has to be that given enough time, your password will be compromised. The longer you have to wait to change it, the longer the window of exposure when that happens.

There have been digital cameras built with CMY-array sensors, but they didn't do well enough in the market to become commonplace.

To nitpick, that's actually not cyan. Cyan is a combination of green and blue light. The wavelength you're describing stimulates the green and blue receptors in our eyes in a way that looks (to us) identical to cyan, but it's not the same thing. Sort of like how violet (in the sense of being around 400nm) light stimulates the red and blue receptors in our eyes, similar to (but distinct from) certain shades of purple.

This becomes important when discussing things like optical filters. A cyan filter passes green and blue light. In other words, it is a red-blocking filter. This is very different from a filter with a bandpass of 490-520nm, which would also block most green and blue light.

Actually, that is one of the things that it was heavily-promoted as providing. The reason is that in a conventional Bayer-design sensor, you only get accurate green levels for every other pixel, and accurate red and blue levels for every fourth pixel, and everything else is interpolated. With the Foveon design, you get all three at every pixel.

I think it's more the case that Sigma have kept it proprietary. As a smaller company, they don't have the funds to build a truly groundbreaking camera with it, or to continue improving the sensor design to e.g. keep pace with the megapixel count of other manufacturers. I would love to try a camera with a Foveon sensor, but Sigma's lackluster bodies mean it's probably not going to happen. It was only about two years ago that they finally introduced a model with LiveView, and that was some ridiculously-overpriced model targeted at professionals, but without most of the other features that professionals would want.

In systems with URLs that contain some sort of object identifier, using a non-predictable identifier is a great way to add another layer of security. It doesn't replace actual authentication or authorization checks, it just complements them.

For example, if I have a REST URL like this:

http://someserver/users/ID

If I use sequential numbers, or actual usernames as the identifier, it becomes trivial for someone to enumerate all of them by iterating through numbers, or a dictionary. However, if the ID is a 128-bit (or longer) random UUID, then that is no longer possible, because it would take millions of years. So even if I (as the developer) make a mistake that allows someone to view or change data that I shouldn't have access to, that attacker may not even get to the point of being able to exploit it, because they may not have any other valid UUIDs to work off of.

This is why Microsoft moved towards using random/non-sequential identifiers for things like IIS website IDs and so forth in the early 2000s. It's one of the few choices of theirs I really agree with.

Not sure if this is the same type of game generation that the article is discussing or if it would be considered a different "class", but Electronic Arts' Adventure Construction Set (1984/1985) could automatically build an entire game-world, including thematic elements, character names, and so on. The user could also start to design a game manually, then have the software finish it for them if they didn't feel like doing so themselves.

I imagine it was more procedural than AI - the equivalent of Minecraft or River Raid - but I still thought it was pretty neat at the time.

I think that's what The Register used to be. I stopped reading it years ago when it became impossible to tell if they were reporting actual news in a comical way, or completely fabricating a particular story.

Have you ever actually fired those two weapons? I was sure I'd prefer the AK (due to high reliability) until I actually tried one and compared it with an M-4. The AK was almost embarrassingly inaccurate, and jumped around like a madman. The M-4 was extremely-accurate, and very stable while firing. It may take more careful maintenance, but there's no question which of the two I'd want to depend on as a weapon.

Exactly. It's as if MS' management are deliberately trying to prevent anyone from actually having an all-star team. They're also completely failing to understand that psychologically, for most people rewarding top performers will produce better results than punishing low performers, even though if you look at it as a math equation, they can be identical.

This stupid way of managing people is one of the main reasons I would never in a million years work at Microsoft, or other companies that use similar methods (Amazon, etc.).

Hey, Sergey Brin: maybe you should take this as a reminder that it sure would be nice if Android devices actually took leap-seconds into account instead of setting themselves to GPS time. My phone now thinks it's 16 seconds in the future compared to every sane electronic system. Sooner or later, that's going to cause problems for certain types of encryption.

I was really skeptical of Metro until I heard a particular use case described: you have a tablet, and as a tablet you interact with it using Metro. When you're at your desk, you dock it into a station with a keyboard, mouse, and multiple full-size monitors. The monitors display the traditional Windows desktop (which you use for "serious" desktop/workstation apps), while the tablet display stays in Metro mode. So you have one system that functions both ways, which is an idea I think is pretty clever, and the complete opposite of the "multiple devices (desktop and mobile) that try to use the same interface (Metro)" model that I was envisioning previously.

Metro actually seems like a pretty good UI for mobile devices. My big complaint about it was always that Microsoft were trying to shoehorn it in where it didn't belong (desktop/workstation systems, the Xbox, etc.). It's great for touch interfaces, and IMO pretty terrible for everything else.

That having been said, this revised appearance is awful. It looks like some refugee from the ghetto of 80s/90s X Window systems. When Google showed off "Chrome OS", I thought "Wow. That looks like a third-rate, terrible copy of Windows 7", and I'm baffled that MS have decided to copy their copy. At least let me turn Aero Glass back on!

How do you dispose of the used etchant? Do you have a fume hood for using it, or do you do it outside? Would you trust a child to use your etching method?

This technique isn't supposed to replace DIY PCB etching or soldering. It's another way of doing things that for some people will probably be a lot less of a headache and more fun. It's somewhere in-between DIY PCBs and one of those old "1000-in-1" electronics kits with the spring connectors.

Think of non-technical people who just want to make something like a guitar pedal or a panel of flashing LEDs. With this method, they can do that without having to worry about fumes or disposing of material that's considered hazardous waste in most areas.

It's the Lego Mindstorm or Technics of DIY electronics, and that's a great thing considering how few people consider that field accessible today.

No matter how well you understand how a piece of software is implemented, it shouldn't expose any sort of vulnerability. If VMWare legitimately has cause for concern, they were doing it wrong from the start.

Meanwhile, in the real world, every piece of software has flaws, and now VMWare's are likely to be discovered very quickly.