...and not just the titles. The HP one is talking about HP pushing for people to migrate off mainframes. Onto HP servers. Running Windows Server 2003.

vi and sqlplus

Same way you do when you disable enterprise manager because java is a memory hog.

...gets shot by those who don't!

Um, I want it to create the table with a NOT NULL constraint and no default value. That's perfectly legitimate SQL.

No, a proper db will create the table as instructed. There's nothing silly about creating a table that you don't want NULL values in, and saying that there's no sane default, so the user must specify a value on INSERT.

The former (reject INSERTS that don't specify a value for that column), which is what any decent database like Oracle, DB2, and hell probably even Microsoft SQL Server will do.

Basically, built-in multimaster replication (if you pay for the license, of course), and load-balanced clustering. If you don't need either of those, there's really no reason to pick Oracle over PG other than political.

PG is an awesome DB, and it just keeps getting better.

When was that? PostgreSQL has been using MVCC for as long as I can remember (as least since 6.0+, probably earlier), which is the same type of concurrency control used by Oracle. The implementation is a little different, but the effect is the same. Much more efficient than the locking method used by MySQL and MSSQL until fairly recently (SQL Server 2005 and InnoDB use MVCC).

The ext2 driver in FreeBSD isn't very actively maintained, tends to lag behind the rest of the kernel, and has been the cause of various problems like panics and VFS lockups in the past. It's not recommended for serious read-write use.

Really the only platform to have good ext2 support is Linux. Honestly a least-common-denominator UFS variant would probably be usable by more systems due to Mac OS X.

This has nothing to do with PGO, and I really wish people would stop pointing fingers at it when the performance difference is brought up on the mozilla lists.

This has been going on for far longer than PGO has been enabled on the Windows builds. PGO may have increased the gap a little, but not that much.

There was a time around when GTK2 was first released that Seamonkey could be compiled against either. The difference was especially obvious then. I'm sure GTK2 has been improved since then, but compare it to Qt-based browsers on the same hardware and see for yourself. Most of the perceived slowness comes from interacting with the UI components, not rendering speed.

Sarcasm aside, that's just a single example of the myriad of inefficiencies in GTK. Especially in light of compositing window managers.

Yes, more likely it's GTK that's using X inefficiently. Especially since almost any program that uses GTK feels "slow". The more complex the widget usage, the worse it is. Compare to say, Qt apps, on the same hardware.

Before someone says it's local, no, this isn't a configuration issue. I've noticed this across many different platforms (FreeBSD, various linux distributions, HP-UX, etc etc.) on a variety of hardware.

While hard numbers would be useful, it's painfully clear to anyone who's used it on both platforms that Firefox on windows is far faster than Firefox on linux. Try opening a bunch of tabs and see how sluggish it is on linux to switch between them or close one.

Personally, I blame GTK2's obsession with double buffering everything. I recall GTK1-based seamonkey builds being quite a bit faster than Firefox when they first switched FF over to GTK2. Of course you'd be mad to even install GTK1 these days, but the performance issues really need to be addressed. If I could get Konqueror without all the KDE baggage I would, for the brief time I used KDE it was always snappy and responsive.

Yes, but the question was: Does it prompt for a driver if you don't have one installed already?

In my experience, no, it doesn't.

No, it shows up as an unknown file system, and if you double click on the drive letter that it gets assigned, it "helpfully" offers to format it for you.

I've often thought it would be an interesting research project to modify an OS so that each application launches with its own security context that is a subset of the user's context. Sort of a derived userid that only has access to its own files (read access to program and write access to data).

The hardest part is not making it too painful for the user when they need to share data between applications. Ideally you'd have to explicitly give permission for this to happen, but it could get tiresome fast.