Github's public repositories can of course be used for illegal file sharing, and some infringing material probably exists right now, because it is impractical for the site operator to monitor all uploaded data. However, without such functionality, participating in (or even just forking) an open source project will be much more cumbersome.

Well, an hour spent writing open-source (or other) software is an hour not consuming MAFIAA's stuff, so maybe this is what they actually want...

I can modify the Javascript in gnome-shell and then restart it with Alt+F2 r. Other applications on the desktop just keep running. So it is really much easier to fork than OpenOffice or the kernel.

git is really a godsend for those who want to modify the source. I do wish that Fedora make it easier to prepare a git tree from a .src.rpm though. Currently I have to clone from upstream, find the exact version that the .src.rpm is based on, then apply the patches in the rpm, which is definitely not very user-friendly.

I'm using gnome3 in Fedora 15 in almost the same way I used gnome2 a month ago or WindowMaker 10 years ago. Quite a bit of configuration and a few small patches are needed though; in particular, dynamic workspaces is unbearable when I'm used to being able to switch to another workspace with a single keystroke, although disabling it only involves removing a few lines of Javascript.

I think "don't optimize prematurely" implies that the code should have reasonable efficiency in the first place, and "optimization" work that sacrifices clarity for further efficiency should not be done prematurely. Some people write code that is very ugly and slow, and such code needs more optimization that tends to make it even uglier.

Linus is actually a pretty good UI designer for kernel developers like him. For example, even though git has a fairly steep learning curve, it has a number of really helpful convenience features as well.

I wrote the parent comment, so I reply here so that I can find it later...

Of course the applicants should pay the examination costs. If it amounts to millions of dollars per patent, so be it. The patents held by "little guys", at least, do not seem to be doing much good to society these days anyways.

This is what matters for me. I want my program to have acceptable speed just by writing it in the most straightforward way. Squeezing out the last bit of performance isn't usually necessary, but 10x slower is also unacceptable. Many people defend slow languages by saying that premature optimization is the root of all evil, but in C/C++, you simply don't need to do ugly premature optimization in most cases, since the program often runs fast enough as long as all best practices are followed.

C++ seems to be useful in most cases as long as all developers know it well (using correct data structures, not copying large objects around unnecessarily, etc.), including important libraries in STL and Boost.

C is also good with the right libraries such as glib. It is more verbose than C++ and manually freeing all the memory can take a bit of developer time, but it is also easier to learn.

Fortran 90 is even easier, but is only suitable for numerical programs without complicated data structures. Java is also easier and fast enough, and may be a good choice for non-numerical work (numerical programming is still a bit awkward).

Scripting languages are, for the most part, still too slow for non-scripting work. Sure, a program in these languages can be made faster by writing some speed-critical parts in C, or by writing the program carefully so that my particular implementation can optimize it well, but this will usually take more effort and make the program harder to maintain.

I think support for Intel 8xx graphics has been rather poor since the change nearly two years ago to use the GEM infrastructure. My i845 locked up about once an hour in Fedora 12 unless I revert to the non-accelerating vesa driver. This turns out to be a GPU bug which happens to be triggered very rarely with the old drivers. A few patches have been found to work around this problem, but I haven't tried them. AFAIK comprehensive GPU documentation from Intel is only available for i810 and i965, so for everything in between, it is rather difficult to have bugs fixed, and Intel doesn't seem to have much interest in having their old hardware continuing to work, either.

If you just want a usable desktop (not accelerated graphics), use the vesa driver. If you want it to be fixed, report it to freedesktop.org and expect to spend some time compiling kernels.

AFAIK the r600 driver for Radeon cards does support shaders, at least well enough to implement the OpenGL fixed-function pipeline.