forkqueue
Hamilton in Spa 2008 and Alonso in Monza 2006 are examples which come to mind.
Given the awesome performance of Varnish, I am surprised more applications haven't taken this approach.
-webkit-text-size-adjust: none; /* Stops the iPhone scalling type up */
which has the unfortunate side-effect of preventing text resize in webkit browsers.
I use this as my primary machine, plugged into a 24" 1920x1200 monitor and a USB keyboard/mouse on my desk. It's easily fast enough for what I need.
All systems were running RHEL or CentOS, so perhaps Red Hat have fixed the problem.
Not users. What would the ability to run IE9 add to the Linux or Mac desktop? Another web browser? Do we really need one?
Not Microsoft, who would have to invest massive amounts of effort into porting it, and large parts of the Windows codebase too.
Honestly, I wonder if the author of this article was deliberately trying to think of something to criticise about IE9, and this was the best he could do.
For non-web developers who use non-Windows operating systems, IE9 is an irrelevance. For web developers who use any operating system, IE9 has to be a good thing, because it means more browsers out there that are closer to the standards.
I very much doubt it would be possible to resolve the problem without actually logging onto the server and looking at what's happening.
Of course, the money not actually appearing is a different matter.
Some of the problems we've had with tenderapp:
* Customer's emails getting flagged as spam even though spam checking was supposed to be disabled
* Customer's email just 'vanishing' (I've been unable to verify this one, on account of there being no traces of the emails whatsoever)
* Attachments not working
* Attachments taking forever to be acceessible when they are working
I think a per support staff user charge is a good idea - it's simple and straightforward.* FreeBSD has better performance than Linux? This is, as you almost concede, no longer true.
* Lack of kernel modules an advantage? Hardly. Linux loadable kernel modules produce no extra performance overhead, but make life a lot simpler for everyone. The only extra 'bloat' is having ~100MB of drivers of which you probably only need 10% or so. If this an issue for you (ie, you're running an embedded system) you can of course cut down the modules to only those required, or even compile into the kernel just as with FreeBSD.
* The GCC compiler and toolchain aren't optimal, and I fully expect a major Linux distribution to switch to Clang/LLVM in the not too distant future. If this is a success (and I expect it to be), I wouldn't be at all surprised to see most/all Linux distros switch. This isn't a Linux vs FreeBSD issue, this is GCC vs Clang/LLVM - a battle I believe Clang/LLVM will win.
* As far as I'm aware TrustedBSD offers no more features than SELinux, and the Linux ACL system, but maybe I'm showing my lack of BSD knowledge here.
* Xen and VMWare virtualization is there but not 100% in FreeBSD. They're rock solid on Linux, which also has KVM, a very viable alternative to the two.
* The development branch/stable kernel approach is irrelevant - people don't use Linux, they use a Linux distribution (OK, OK, a GNU/Linux disitribution :)). In most distributions point releases are binary and API compatible with .0 releases (RHEL 5.5 binaries are guaranteed to run on RHEL 5.0).
In conclusion, is FreeBSD good? Undoubtedly. Is it better than Linux? It's hard to make a case for that. It has less device support, less software support and a massively smaller user base.
FreeBSD is nice to tinker with, but it doesn't offer enough benefits to justify putting production software on it. It's great to learn about the old school UNIX way of doing things, but that's not what I want to be doing on a live server.
These numbers show that Red Hat did the right thing too - they're a highly profitable company, and they're bringing massive value to the community. I really don't understand why you seem so aggrieved at a company which contributes so much.