So this also proves that, ultimately, this list of passwords was not properly hashed.

People jump up and down and scream that SHA1 and MD5 are broken, but if properly used, they still offer significant password security. One trick is to use salts when storing passwords in the database.

password: 'foo'
salt: '2010-11-16T08:39:05Z - some_random_string$#@!'
password-hash (md5): 14e80778512f578a5fe263abe4b58e9c

that increased the amount of time required to brute-force the password significantly. Also, the use of a database of hashes is largely worthless since each password in the list would have a completely unique hash. for the sake of brute-forcing the data, short passwords don't matter (on the other hand, brute-forcing login to the application is not affected). Having a different salt for each password makes the time spent on each other password completely worthless once the cracker gets to the next item in the list.

to improve that, we can say... hash the result 1000 times in a row. For someone trying to brute force the hash, they would spend 1000x the CPU resources creating the hash. It's mostly not a big deal to run that hash 1000 times when creating the information for the database or authenticating the user.

of course, SHA1 and MD5 are still broken when it comes to file integrity checking (when it comes to tampering) since there are documented collisions. For this case, cryptographic signatures are where it's at. You can guarantee that not only was the file not tampered with, but also that the person who supplied the signature was who they say they were. Gotta love public key encryption.

...you insensitive clod!

8 commands. period. no more, no less. Super maintainable, cross platform and...

bah, who am I kidding?

cars are lame.

friends from out of town don't understand my love affair with being carless. living in NYC, public transportation is spectacular... I just wish it was better outside of the city.

hooray for public transportation!

since moving to NYC in 04, I haven't had a car and it's AWESOME. no more insurance, worrying about people breaking in, parking, oil changes, cleaning it, gas, etc etc etc.

plus I walk like 10x more than I used to. it's great.

I'd get a bike, but I've been hit by a car on my bike in the past and I don't want to deal with that again. I value my safety too much.

The worst thing is that, when it comes to upgrading their browser, their assumption IS valid. They shouldn't HAVE to install a 3rd party browser. I'm not saying that there shouldn't BE 3rd party browsers, but the browser that comes with your OS should at least work properly.

One of my semi-techie friends saw those Chrome commercials and said to me "you told me that google was NOT a browser, but look, it is! You don't know what you're talking about!" I seriously think that it's a conspiracy to confuse consumers lately. Between confusing branding (Motorola Droid vs HTC Droid Incredible vs Android OS vs "Droid Does" and this whole 4G thing) and confusing metrics that are difficult (if not impossible) to explain to non-technical users (4MP vs 8MP camera, it's possible that the 4MP takes better pictures... and the difference between 4" and 5" display, when the 4" has higher pixel dimensions). And don't get me started on the difference between a fast internet connection, fast network connection, fast computer and fast browser.

So now you have uninformed users throwing terms around that they think they understand, you've got companies leveraging these misunderstandings to sell overpriced, sub-par electronics, and all these inexpensive electronics that you buy every year that are incompatible with each other (chargers, data cables, etc).

Keep consumers in the dark and confused so you can sell them whatever you want.

Although I still feel that way, I've been forced on several occasions to make things look and function in IE (8 or newer only, luckily). One customer hounded us to get their site working in 6, and after we spent a week building a system to detect the browser and output different HTML and were only 1/2 done, they changed their minds.

It's sometimes difficult for non-technical customers to understand that each version of IE is a different beast and requires you do do much of the front-end work over again for each version.

If it was up to me, I'd just say that we don't support IE, but a good chunk of windows users on the public internet have not installed an alternate browser. I just don't get it.

DRM-free, too. Although they won't play on the likes of the 360. Luckily I have my machine connected to my TV so I can watch Hulu/AdultSwim/Southpark/iTunes shit.

I think iTunes "rentals" are full of DRMs, but I don't see any value in that, especially since I have the netflix.

My old Nokia fell out of my pocket whilst riding the roller coaster (Medusa) at Six Flags. It fell about 30 feet onto the sidewalk and the only issue with it was that the casing kinda split a little and the bottom 4 rows of pixels on the screen stopped functioning. I stuck some tape on the thing and it kept chugging along for about another 6 months before finally failing.

I have a feeling that this part hype, part inept programmers who don't actually understand SQL, or database optimization.

This is part of the problem... similar to PHP, most people learn some examples that teach some bad habits right off the bat (sticking SQL in your view, etc) because it's so easy to get started, but you've gotta get a grasp on the tech before you can do anything big.

Also, I feel that one of the root causes of the hype is that SQL and RDBMSs in general don't solve all your problems and sometimes get in the way of your application design. Between rigid schema definitions and the SQL language that has a bit of a learning curve when you start dealing with nested queries and handling shards/partitions/etc, I think that's the reason we're starting to see more non-RDBMS databases.

At work, we had a project that we started building on MySQL, but was falling short because we were constantly making schema changes. We begun to build a system where we could have arbitrary attributes attached to arbitrary objects, but then our queries were getting REALLY nasty. We discovered MarkLogic which is an XML database server and uses XQuery to query the data. We were ingesting around 100MB of XML a day, and we needed to be able to handle just about any XML that went into the system. MarkLogic was a natural fit since we needed to put XML in and we wanted XML out most of the time.

We're still using MySQL for tracking the ingestions and managing the frontend to the system (which is built on Rails), but having XQuery at our fingertips has been a godsend.

There's a lot to be said about new technologies that solve needs and get around shortcomings of the more ubiquitous technologies, but, as with anything that people see as a solution, it's not a silver bullet. You've gotta be careful not to get trapped in "everything looks like a nail" syndrome.

It really depends what kind of service(s) you're launching on the cloud. If you're building generic infrastructure to cover some area of the market that AWS doesn't cover well or at all, then you may be in for a rude awakening in the future. This doesn't mean that such a service should not be built, it's just that one should realize what kind of risks are involved when developing something like that.

There are plenty of services that build on top of AWS that will probably be safe from competition well into the future. Those include services that are very specific such as Heroku's Rails app hosting, which will actually benefit from additions such as this MySQL instance type and the price cuts of EC2.

Also, when building apps that essentially turn you into a reseller of AWS services, although there may come a time when amazon starts competing directly with you, you've got your app built. If you built it properly, it should not be difficult to re-wire your backend to utilize some other service or build your own cloud infrastructure. If you're big enough and have the necessary capital, it may actually be a cost savings to do such a thing.