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.

The status is not quo.

The world is a mess, and I just need to... rule it.

Yeah, but it changes them to DOS format when you save, with no option to keep the UNIX line endings :(

Good thing vim has a windows version.

While SQLite3 doesn't support true concurrency, it's generally good enough for things like MythTV. The locking is only slightly more clunky than MyISAM's.

Why is ignoring FOREIGN KEYs okay? A constraint is a constraint, IMO.

Last I checked FKs worked, if you're using InnoDB, and then only kinda (no deferred checking, which is the SQL standard default).

Although, the primary deployment for MySQL seems to be running on the same machine as the web server. In a direct comparison of that case, you don't even need to change pg_hba.conf.

The default config isn't secure if you have untrusted users on the machine (i.e. hosting service), unless you used "initdb -A md5" or something similar, but it's easy to change.

My favorite auth method for server-in-a-box is "ident sameuser" over UNIX sockets. In that case it seamlessly integrates with the OS's underlying security model, so all I have to do is "CREATE USER webapp;", and the user 'webapp' can connect as itself (and only as itself) with no password.

That's because you know MySQL, so of course something that works differently is going to be more work for you to figure out.

I've used PostgreSQL for years, when I had to set up a MySQL database for some php app it took much more than 15 minutes to figure it out and get it running. The primary problem was MySQL's obtuse user management system.

With PostgreSQL I know that it's secure by default -- the default user has no password, so even if you enable password authentication it won't work (because it has no password!). You log in locally with trusted authentication, and issue the very logical CREATE USER. Edit the self-documented config file to allow remote hosts to access the database using your preferred authenticaion method, and you're done.

With MySQL, new users are automagically created by the GRANT command?! Huh? On top of that, passwords are apparently specific to a certain host string. Bizarre. Do I need to use localhost for the actual machine name for local users? What about remote machine without a reverse DNS entry? What's the order of precedence for '%' vs a more specific name?

Oh, the default 'root' account has no password ...and allows access over the network. Wonderful. Okay, so to change that do I use root@% or root@computer? How do I know I changed the right one and there isn't still some root@something entry? SHOW TABLES is easy enough, how about SHOW USERS? Nope, that's not it.

Time to check the startup guides. Well, one just has a single password change, another has 3 or 4 lines of 'delete from user...'. The reference for GRANT just has a bunch of caveats and warnings, and the "User Account Management" section goes on and on and somehow doesn't manage to tell me what I want to know.

To this day I'm not 100% sure if the MySQL install is secure. I decided my time would be better spent eliminating the MySQL-isms from the app in question so that it can run on Postgres like everything else on the server. There are some very strange queries in there - a lot of GROUP BY expressions that make no sense and aren't valid SQL. Some of it I'm not sure how it ever worked.