While some particularly "sensitive" content might be technically in violation of Chinese law (the law might be wrong even then, but that's a different matter), the majority of the GFW'd content are not illegal, even in China, and very often they would not even be considered sensitive in any way. On the other hand, we do have computer security laws, and disrupting the public Internet via passive and active attacks, as the so-called GFW does, is probably as illegal as they are in developed countries, and I am not aware of any law that grants special permission to such behavior, as it has little to do with either law enforcement or national security.

We still have many "old-thinkers" in high positions that do not realize the importance of network security or even rule of law, let alone free speech. It would be extremely attractive for companies to exploit the naivete of such people for their own profit; in other words, it is protectionism, and a rather corrupt form at that. While I don't know who is actually doing this, I find it rather unlikely that nobody has thought of this.

The problem is that they are sending reset packets to both sides, and if Google's servers honor these reset packets, it doesn't matter whether my computer does.

There was indeed a project, named after a fairly well-known story in Chinese literature ("west chambers" or something), that finds a way to work around this problem. IIRC it sends special packets to make these reset packets ineffective on the other side due to timing issues. However, since this only helps with TCP resets and cannot deal with IP blocking (which is also common), and the scheme itself a bit of a hack that might slow down network access sometimes, I used it only for a few weeks. I don't know if it still works now.

Disclaimer: I'm a native Chinese living in Shanghai. Somehow access to /. isn't disrupted, but I wouldn't be surprised if it is in the future. Simple complaints about the GFW, online or otherwise, is too common to be considered sensitive here AFAIK. Buying a VPN is probably so as well; I have been too lazy to get one myself, but considering the amount of lost productivity, maybe I should.

That said, Google is borderline unusable here. When I search for anything technical, 30% of the time the connection gets reset and google becomes inaccessible for several minutes, and if the search results are shown, about half of the sites are inaccessible, including most foreign blog sites and many of the mailing list archives. It is so frustrating that I'd wish for the evil bit to be implemented, or bang the keyboard refreshing the page in a vain attempt to DoS the machine sending out these bogus TCP reset packets.

I consider the GFW a kind of malicious DoS attack on our network infrastructure. We do have laws against such attacks, and I think those responsible for it may well deserve a few years in prison.

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.

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.