As CentOS is a repackage of RHEL, you should have at least one RHEL license if you are doing anything close to mission critical. If you get a problem on one of your CentOS servers, you can recreate it on your RHEL server, and get support from RedHat. Subsequently when the bug gets fixed, also get the fix for your CentOS servers.

For anything mission critical it's insane not to do that, otherwise you are gambling that not only some random RedHat customer get the same problem as you, but also that they report it so it has a chance to get fixed.

And in case you get a problem on CentOS that do not exist on RHEL, I'm betting the CentOS developers are quick to help fix the issues.

For simulation, you can get Spice versions for all platforms.

For the CAD part, there is the EAGLE Light Edition from CadSoft http://www.cadsoftusa.com/freeware.htm It runs on Linux, Windows and Mac.

What about the PyGTK and GTK websites. According to the download links the latest stable and updated PyGTK are for GTK 2.14, and GTK 2.16 has been out since the middle of March. For PyQt you don't find many minor releases of Qt that has not been followed by a updated PyQt release inside a week or two, for the last 5 years or so.

As for being comprehensive, the Qt bindings(at least PyQt) has a close to full coverage of the Qt classes. Last I checked PyGTK did not offer the same. And since Qt are not only a GUI library, the difference gets even larger as the bindings provide so much more.

My main issue is that Qt is pretty strongly tied to C++ This is repeated over and over again and even if people believe it, it' still not true. That is pure FUD. Whereas GTK in C may be horrible, but the bindings to Python, Ruby and C# are all excellent Fact is, the Qt bindings for those languages are more comprehensive and more up to date than the GTK counterparts. The Qt bindings all have powerful automatic tools for generating bindings for those languages, making it easy to keep up to date.

that's why its no longer the official kde media player.

Basicly your whole commnet is utter nonsens, reaching a high point by this part of the comment. Amarok have never been the official KDE media player. In KDE2 and 3 the official mediaplayer was Noatun(In later releases you also got the choice of JuK for audio).

For KDE 4 users, JuK is the default media player for audio media. While Dragon Player is the default for video. Both are great applications, preforming their task well. Interrestingly many of the load complainers against Amaroks design, describe the way JuK works. Go figure.

This would be no problem. Fact is, Google already does exactly this for other products.

??? What are you talking about? Companies sell, eg transfer, software developed with Qt all the time, it's what is made for after all. Obviously the license allow it.

No need for GPL, you can freely use Qt with a wide range of open source licenses like Apache/BSD/etc. Please check your facts. http://doc.trolltech.com/4.4/license-gpl-exceptions.html

Good luck writing up that letter to your ISP to complain about their outages then, guess that would be as useful as using their web based fault reporting tool or sending a e-mail to support.

Native KOffice for Windows and Mac are already exist, they are in beta just as the native X11 variant.

And NI are absolutely writing kernel-level drivers, since they in addition to software for measurement and automation they offers a huge number of different hardware. So to support all their measurement, dataloging and automation hardware, they have to write drivers for PXI (PCI eXtensions for Instrumentation), VXI, PXI- and PCI-based modular instruments and GPIB bus controllers. Their Linux offering have been rapidly growing for years, so obviously their userbase already have a strong interest in Linux.
Even if I disagree in that NI's hardware are considerably less complex than the hardware of NVidia and AT. For some I think actually the opposite are true, but it does not matter. What makes it hard for NI are simply the huge amount of different hardware they have to support, most likely many more than any other hardware vendor doing Linux support. Combined with the fact that their userbase expect support for far longer time than you can expect from the likes of nVidia or ATI. And very few, if any, of the regular kernel developers have or use any of their rather specialized hardware, makes it rather inconvenient and expensive when the kernel API changes. IMHO, the only strong reason for a stable kernel API are vendors like NI making specailzed, non-mainstream hardware.