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
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.
As a GNOME 2 user who grew up with WindowMaker, I like to open 10 workspaces with hotkeys to switch between them, and each workspace hosts a kind of application. Minimization is thus never useful to me; the number of windows on each workspace is usually small enough that Alt+Tab works acceptably. (Although last week I did end up having 30 xpdf and oowriter windows in one workspace plus a terminal window running screen with 26 sub-windows...)
I don't know how well GNOME 3 will support this habit; I once tried Compiz, but did not find an easy way to set all the necessary hotkeys, so I switched back to Metacity.
Command-line tools usually have very well-documented configuration files, and even when they break, debugging is relatively easy.
Now we often have configuration files (e.g. font configuration and internal stuff used by many GUI applications) spread over many poorly-documented locations. If the GUI is not enough or is buggy, which is often the case, it is quite hard to diagnose the issue even for an experienced user like me.
After all, it usually takes much more work to design and program an acceptable GUI than a CLI with similar usability, at least for frequently-used software and users who can either type fast or do simple scripting. Developer time is scarce, so GUI tools are bound to lag behind in features, stability, usability, etc., and the world is complicated enough that a lot of effort is still needed to make things work at all.
Yes, the LLVM version would be quite similar to a JIT compiler, but it is more efficient than most of the JIT compilers currently available. Unlike e.g. the Java VM, there is no need to do much bounds checking and type checking; for example, on x86-64 the code can have all kinds of buffer overflow problems, but the compiled code is generated in a way that makes it possible to verify before running that all stores can only end up in a 4GB slice of the address space, so other code running in the same process remain unaffected. As a result, it is possible to compile the large body of existing C code to run on the NaCl virtual machine, and have it run at about 90-95% the speed of ordinary C code. This is not possible on the JVM.
Moreover, there remains the possibility of processor-specific optimization using e.g. SIMD instructions. For example, if we want to make the JVM support AVX instructions, we need quite a bit of additional code in the JIT compiler, and usually some kind of API must be introduced so that the application can use these instructions manually (compilers are not yet so smart). On NaCl it is only necessary to modify the verifier so that only valid uses of these instructions are allowed; actual generation of the instructions is left to the ahead-of-time compiler, which hardly has to be changed if the new instructions do not make verification difficult.
I suppose the fee for filing a patent can be increased to a million dollars or so, so that we can pay for a sufficient number of real experts with enough time to show how a given patent is actually obvious.
But money only works up to a point. Examining patents is much less interesting than actually developing new stuff, and the real experts are probably paid well enough for developing stuff. If you tell them that examining patents is a citizen's duty to protect the country from patent trolls, maybe they will more likely listen, but I still doubt it.
As a native Chinese speaker fairly fluent in English, I can type about 80wpm in English, while my Chinese typing speed is about 60-80 characters per minute depending on the input method, equivalent to about 40-50 English wpm. While English is faster to type, it takes a bit more time to form the correct sentence, so overall there isn't much difference in e.g. IM.
A morsel of genuine history is a thing so rare as to be always valuable. -- Thomas Jefferson
