SearchYC.com

1) It's lighter and smaller and thus easier on your hands to hold it. My hands begin to hurt after holding the iPad for more than two hours. Reading is something I can do for hours without interruption.

2) I thought that an advantage of the ipad would be that I can read with the lights already out. I was wrong - staring at the illuminated screen quickly hurts my eyes in an otherwise dark room. Interesting: Watching videos is no problem, but reading apparently is something I use my eyes differently than watching a movie.

3) The distraction factor is huge if reading your mail, hacker news or google reader is just a small home button press away. I can't. get. any. serious. reading. done.

For me, reading a book is an activity I'm doing for hours at a time if I finally find time. Then, being distracted, having to carry a heavy device or hurting my eyes all are not optimal solutions.

right. And the Finder - a piece of Software central to OSX was using Carbon until... when exactly? At most 6 months prior to when CS5 came out.

iTunes - a corner stone of the iPhone software world? Still on Carbon.

If I hate one thing, it's hypocrisy.

But when I moved to Apple hardware, I basically was stuck with the trackpads, but this time around, it was different. The bigger size meant less finger movement and with the advent of multi touch, it suddenly felt like a more "natural" way to control the machine.

With the newer Macbook pros came this "the trackpad is the button" functionality and while it took me a day or so of getting used to, I absolutely cannot work with the dedicated button pads any more. Seing how quickly this became muscle memory, I assume that they did something (no idea what) right when they moved to that design.

This is how I went from "I hate trackpads" to "trackpads are the only really natural way to control the machine".

Ever since 7.1, I'm a near-fanatic PostgreSQL-user, if not to say fanboi.

I love, love, love PostgreSQL for its performance, its features, its awesome community and just for the fact that it's getting better and better every year.

Congratulations to the PostgreSQL team.

I've said it before and I'll probably say it many more times: You guys rule.

But a revision control system failing to not corrupt or crash depending on the data you put into it is, frankly, no revision control system.

Thank you, everyone behind the development of PostgreSQL. I wouldn't be in my life where I am now if it wasn't for the work you are constantly putting into this wonderful project.

And when one thinks "now. this is it. it can't get any better now", you come out with another high-quality release.

If by accident you put Latin 1 (or any other non-utf-8-data) into a database that is configured as UTF8, MySQL will go ahead and cut off your data at the first byte with the 8th bit set. No error. No warning. The data is just gone. The only way to find out this happened is by reading back after every write - something I don't want to have to do.

Or allowing to

    alter table whatever add somecolumn text not null;

Or inserting strings longer than allowed by the datatype which MySQL doesn't complain about but just truncates them - another case of having to read and compare the data just stored.

And don't get me started about corrupt on disk data, leading to unreadable tables. But worse - mysqldump at least once exited with an exit code of 0 even though it failed to read one of these corrupt tables. What's worse: It stopped the dumping process and didn't dump any tables and even databases following the corrupt table - yeah. I thought I backed up, but in fact I didn't.

Stuff like this must not happen with a database.

Stuff like this never happened to me with PostgreSQL.

It might be harder to set up. It might feel a bit foreign at first. It might provide features you think you don't need. But at least it doesn't destroy data I entrusted it with.

Postgres usually does its thing and does it well. You usually don't get weirdness that requires you to even hire a specialist. And if you do, the consultants around are great and actually understand the problem.

As other people here have said: If you find someone listing PostgreSQL experience on their resume, you know they have the experience. If you find somebody listing MySQL, you'd have to check whether they are just listing it because they have heard of it or whether they really understand the problem domain.

So. DB specialists are settled. What about developers? PostgreSQL and MySQL are close enough in what SQL constructs they support (no wonder - MySQL provides a subset of SQL anyways), so coming from MySQL to PostgreSQL usually is trivial and the few things that are unsupported unix_timestamp() for example, you can write wrappers for if you really need them.

Of course, developers will at first find it strange that they can't, for example insert a 200 characters string into a varchar(10) column, but even the most braindead developer sooner or later will understand that silently truncating data usually is a bad thing.

No. The arguments listed in that article are just fear of the unknown and total non-issues (in german, there's this saying: "Was der Bauer nicht kennt, das frisst er nicht" - ever so true).

I'm glad I can work with PostgreSQL day-in, day-out. I'm glad I migrated that huge application from MySQL to Postgres back in 2000. I'm glad I did not touch MySQL for serious stuff ever since then.

I understand if you need to use MySQL if you want to run some software that runs only on MySQL. But if you are writing your own application, there's just no reason not to got with the real RDBMS.