We need to learn to better respect the blue collar jobs. Without people doing those jobs our world doesn't work, yet people are taught from a young age that doing blue-collar work is something you should work to avoid.

Just throwing a relevant article recommendation, based on a book which is also a good read: Matthew Crawford's The Case for Working With Your Hands, based on the book Shop Class as Soulcraft. There is a puzzling bias against any blue-collar work in this country, regardless of how challenging or well-paying it may be. Ever look at the hourly rate your plumber charges? Or how much fun it might be to, say, work on cars or motorcycles for a living as compared to banging out TPS Reports?

Speak to your government about the enormous taxes they pile on top of that price.

I don't see why it' so terrible to pay gasoline taxes. We are dumping pollutants into the air with our cars, using the roads which our government funds, causing obnoxious noise and traffic jams...

I was just in Cuenca, Ecuador, where gas is $1.50 / gallon. The pollution from cars and buses in the city is unbearable: you can barely stand to walk around the city. Of course, hardly anyone walks anywhere, since a taxi anywhere within the city is a flat $2. The pollution is a real shame, since the city is situated in a picturesque valley tucked in the Andes mountains.

Yup. Look up SELECT ... FOR UPDATE for your database for the answer to your question, though again the real solution is just to use the appropriate sequence type provided by your RDBMS and let it do the work for you.

Not true, if you set things up properly. Look up STONITH -- it's quite easy to quickly turn a slave into the new master if your master dies (so long as you are sure the master is dead, and you can decide which slave to promote!).

Yup, that's the idea behind "asynchronous replication", and that's exactly how it's billed. If that's a deal-killer for you (for a large number of read-only queries it won't be.. think web applications where an eventually consistent state is perfectly fine) just wait until Postgres 9.1, when we should have more knobs for controlling master-slave replication. Then you should have the option to force the master to wait until a slave has received its WAL file update, and even fsync'ed it to disk, before your COMMIT returns, giving you the synchronous replication behavior you want.

The tradeoff with synchronous replication is increased latency on the master of course, since you're hanging around waiting for the slave to fsync (or just receive the data, depending on how you turn the knob). There have even been some proposals floating around for a "quorum commit" model whereby you would tell the master that you want your COMMIT; to go through when n out of m slaves have received the data.

Eh? When was multi-master replication ever promised in core? You're probably thinking about hot standby -- the Streaming Replication/Hot Standby code which is the "killer feature" of 9.0 was originally slated for 8.4, but didn't make it in time. I'm really surprised there aren't more comments about SR/HS, as it's an awesome feature which lets Postgres compete with the big boys like Oracle.

Imagine having your expensive database server be dedicated *only* to writes, and having all your read-only queries spread across one or more slave(s) which are also your backup servers. Pretty cool, huh?

Definitely not true. There's a lot of support to implement the MERGE command from the SQL standard. It's been proposed a few times, but it's more difficult than it sounds to implement. From here:

And work on MERGE support is itself blocked behind the fact that PostgreSQL doesn't have a good way to lock access to a key value that doesn't exist yet--what other databases call key range locking. See the notes for "Add SQL-standard MERGE/REPLACE/UPSERT command" at http://wiki.postgresql.org/wiki/Todo for more information.

Your gripe about CREATE ... IF NOT EXISTS might hold water, depending on what exactly you're complaining about (CREATE TABLE? Or for indexes/constraints?). There does seem to be some resistance to CINE, though from what I can tell it's mostly because people would rather have CREATE OR REPLACE, but COR is much harder to implement (what do you do when the object already exists, but is slightly different than the one you're trying to create)?

You're basically describing the SQL language itself (PostgreSQL does a good job of implementing most of the various SQL standards up to SQL-92 and even SQL-99). Of course, add-on procedural languages like Oracle's PL/SQL aren't going to be supported as-is anytime soon on PostgreSQL, or anywhere else. And of course, each database vendor has their own extensions to the SQL language itself, which other vendors aren't always keen to copy (think MySQL's INSERT ... ON DUPLICATE KEY UPDATE, or PostgreSQL's CLUSTER).

If you're designing a database application which you want to be easily portable across various SQL databases, just try to keep any non-standard-SQL use to a minimum and use of procedural languages simple and only when necessary. Books by Joe Celko stress this ideology, though my take is that it's just about impossible to really get the most out of your database unless you really make use of its extensions, which are there for a reason. For example, Celko discourages the use of auto-increment columns (serial type in Postgres, auto-increment primary key in MySQL), in favor of manually incrementing your sequence using MAX(pkey_column) or similar, which strikes me as absurd and non-scalable.

Pah. Who needs Windows machines for a botnet? Look, I can start my own botnet right here with a few lines of Python:

Dear Slashdot readers on *nix machines. Please fire up vi, copy and paste the following text:

#!/usr/bin/python
import socket
import botnet
botnet.connect()
botnet.identify(socket.gethostname())
botnet.accept_control_commands()

Now, save the file you just created as "/tmp/botnet.py". Run "chmod a+x /tmp/botnet.py", and then run "sudo /tmp/botnet.py". Oh, and you'll have to install the "botnet" Python module first.. you should be able to find it in the Cheeseshop, or if you're on Debian/Ubuntu, just run "sudo apt-get install python-botnet". Thanks for doing your part to make MS Windows obsolete!

From taking a 10-second look at the :

• Make the link to the "demo" front and center. Forget about "screenshots" -- it's a web application, who wants to see screenshots when you can click a link and see the web app in action!
• Let people using Enano send in a link (or edit a wiki page of links) linking to their homepage. This will give end-users with tiny sites an incentive to try your package, because it will drive traffic to them. Long ago, I used a CMS called Serendipity that had exactly this marketing tactic, and it worked well.
• Uh.. you really need themes available. Think of myspace, etc. People like to customize their sites.

Interesting snippet from that article:

I've often wondered how Google gets away with free meals every day and other generous perks for employees, and not making the employees declare the free food as "income" to the IRS and pay taxes on it.