All evidence to the contrary. The number of "broken in latest Chrome" bug reports we've had coming out of QA recently is quite alarming. Things like certain tags not appearing in the layout at all, or massive layout gaps that don't appear in any other browser.

Personally, I think Chromium is moving too fast, and now Mozilla is following. Many of the bugs we've encountered were regressions, broken in Chome say 15, fixed in 17, and then broken again in 24.

The closest thing to case-insensitive collation is the citext data type. It works basically transparently as a case-insensitive replacement for varchar and text.

The major feature keeping $dayjob from using PostgreSQL over MSSQL in new development is the lack of an accent-insensitive collation. Making an index using a custom function marked IMMUTABLE that calls (lower(unaccent(text)), and then calling the same function in nearly every query, is simply too hackish to stomach.

Umm... we don't. That 1970s french/brit thingy crashed, and that was that. It just costs to damn much to fly an airliner past Mach-1. It's like commuting 30 miles to work every day in a Bugatti Veyron at 2 mpg.

also..
* the fucking Internet

you kids these days need to learn your history

Yes, Israel has been at war with its neighbors, but only because it has been repeatedly attacked by those neighbors. Not that Israel plays especially nice these days - in fact they act like total dicks. I probably would act a bit dickish too if 90 million of my neighbors had vowed to wipe my people from the face of the Earth, and repeatedly attacked me with tanks and artillery to prove that they weren't just talking.

You just gave away your inexperience there.

You really want to touch configuration files on hundreds/thousands of machines just because a server IP has changed? How do you migrate a server to new hardware without downtime?

There's this thing called a "DNS Resolver Cache", in every OS. And another thing called a "TTL" on a DNS record. They'll save you hours of scripting work the next time you need to do a service migration.

He can dig ditches, mow lawns, shuck corn, whatever. That's gainful employment. What he cannot do is expect to ever be put in a position of trust by his employer. That's the way it works for convicted felons - it ruins your life, even after you are out of prison. It's been that way since Greece ruled the Mediterranean, and will likely always be that way.

Really? You're suggesting the douchebag antics of Lulzsec and Anonymous are somehow patriotic? A form of righteous civil disobedience?

Or are you just being an asshole?

Nginx 1.0+ supports backend keepalives with a patch and module, but they are still not in official release. But this code comes from the principal nginx author, so it will make it into release soon.

That said, your back-ends are usually very close network-wise to nginx proxies, and connections can be established and torn down in less than 1 ms. Since the back-ends are usually thread-based, this is a good idea anyway (which is why everybody has to turn off HTTP keepalives in Apache when they start to scale). Disabling HTTP keepalives SUCKS for the client's experience, especially if they are on wireless/mobile connections or on another continent.

I manage a medium-sized SaaS application with about 0.7M users, and we front dozens of honking physical JBoss/Tomcat boxes with a single-core linux VM running nginx with 1 GB of RAM (with a hot standby of course). Nginx is only proxying to back-ends, not serving static files (except for a small 512MB set of really hot files using proxy_cache which stays in the filesystem cache). Nginx itself uses only about 100 MB with 8 worker processes. This isn't surprising: even the biggest $50K F5 load balancers have very wimpy specifications for CPU and RAM, but like nginx they use an event-driven model to keep RAM usage and context-switching to a minimum.

One problem running nginx on Linux is that asynchronous IO on Linux is horribly broken by design, and only works for databases that use direct uncached IO. So we are looking at moving nginx to FreeBSD so we can take advantage of asynchronous disk IO as well as the default asynchronous network IO.

The one-thread/process-per-connection model of Apache really just doesn't cut it for web-scale workloads. We were able to re-purpose our dedicated Apache front-end boxes as application servers instead because of the RAM savings. So nginx saves us about $2k per month in colo costs.

1991 just called, and they want their standard hard drive form factor back.

Since always. Throughput is always operations per second, or transactions per second. Bandiwdth is measred in Mbps or MBps.

The brick and mortars need to focus on providing a better overall value, and that includes their employees being able to enumerate exactly WHAT that better value is.

^^THIS^^

You do nobody any good by "buying local" just because or buying an inferior product because it is made-in-the-USA. It just keeps inefficient/low-value-add operations alive in zombie mode and provides no incentive for the necessary change that will actually improve the economy long-term.

For example, I did a huge chunk of my Christmas shopping at Nordstrom. I paid probably 25-30% more than I would online or elsewhere. But I did so because they let me sit in a comfy chair, and got me coffee. Then the helpful salesperson went and picked out items for my wife, sisters, mom, etc. that I simply had no chance of choosing well on my own. That's value-add.

Sure... this is the most comprehensive qualitative test I've seen, using a huge varietry of sources and metrics. See conclusions section on page 93, which shows WebM requiring >2x the bits of x264 for the same quality.

A rigorous subjective comparison can be found here, using the Double Stimulus Continuous Quality Scale methdololgy.

Note in both subjective and objective comparisons, WebM takes 2x or more bits to achieve the same quality at web bitrates of ~500 kbps.

At much higher bitrates, the quality differences narrow. But high bitrates aren't valuable for Internet use cases, and in any case at 2.5 Mbps and SD resolution, even inefficient codecs like MPEG-2 or WMV8 look good.

No, they really aren't. Every rigorous quantitative and rigorous qualitative (large sample sizes and double-blind) study has shown that the best available VP8 encoders require almost 2x the bitrate of the best H.264 high profile encoders.

VP8 is basically useless, as it is very likely encumbered by patents (12 different companies have made claims, and Google will not offer indemnification for a reason). So it isn't free, it is extremely slow, and it requires twice as many bits. I operate a commercial video site, and guess what? Our H.264 licenses cost less than the extra storage and bandwidth WebM would require. And the WebM tool chain sucks.

The root servers are already quite distributed, thank you. Are you suggesting the roots should contain differing data and somehow resolvers decide what to use by voting or reputation scoring or some shit like that? The PGP web of trust didn't take off. That model has been tried and doesn't work.