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.
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.
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.
Wouldn't it be akin to having biological children with your own identical twin, with a high likelihood of birth defects, since your two sets of chromosomes are being remixed, possibly making your child getting two "bad" copies of some gene? It won't be like a clone at all.
IIRC the procedure is still far too expensive to be used commercially on ordinary farm animals. Wait until we genetically reprogram the animals so that they can give birth to their own clones without manual intervention.
Sometimes you want to do some experimental work that is complicated enough to be version-controlled, but not stable enough for other developers to see yet.
In SVN you have to use a branch, and SVN branches are not that convenient to use. Otherwise, when another developer checks out the tree or commits his own changes, he will see the unstable changes you have committed.
In Git you can simply commit your experimental changes and push them (or let others pull them) when they are ready.
And if you frequently want to push immediately after commit, just make such a shortcut.
From what I have looked at, I would not call many of these "legitimate" in terms of whether enforcing them (if even possible) would do the world any good. But then, IMHO hardly any patents in my field, applied in any country or by companies from any country, are what I would call legitimate. Patent trolling is so ethically reprehensible that anyone deciding to join the game might as well commit plagiarism/fraud/bribery/etc. as long as they don't get caught. It's a fair game like spying in a war.
There are a few sensitive files in my home directory, such as my private key in ~/.ssh and a few configuration files that contains passwords in clear text. I really don't want these files to be shared inadvertently, yet they are currently treated as ordinary files by the SELinux on my Fedora 10 system, so any process running under my account can access these files. Of course I can still relabel the files and change my SELinux policy, but this is beyond the ability of most people. It is a shame that SELinux, with its huge potential, is so hard to use that it still provides very little security for an ordinary user.
Truetype fonts generally contain some information for hinting purposes, i.e. they tell the font renderer (Freetype) the best way to render the character at small pixel sizes. The "bytecode interpreter" that makes use of such information is available in Freetype, but the method is patented (IIRC by Apple) in the U.S., so most distributions turn it off by default. Without such information, Freetype has to decide the small-size rendering method all by itself ("autohinting"), and some people may find the result blurry.
If you are not in the U.S. or don't care for software patents, there are plenty of information on the Internet about how to turn on the bytecode interpreter in Freetype. For example, in Fedora you can simply download Freetype's source RPM and recompile it with rpmbuild using some --with options.
Slashdot Mirror
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.
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.
Wouldn't it be akin to having biological children with your own identical twin, with a high likelihood of birth defects, since your two sets of chromosomes are being remixed, possibly making your child getting two "bad" copies of some gene? It won't be like a clone at all.
IIRC the procedure is still far too expensive to be used commercially on ordinary farm animals. Wait until we genetically reprogram the animals so that they can give birth to their own clones without manual intervention.
Sometimes you want to do some experimental work that is complicated enough to be version-controlled, but not stable enough for other developers to see yet.
In SVN you have to use a branch, and SVN branches are not that convenient to use. Otherwise, when another developer checks out the tree or commits his own changes, he will see the unstable changes you have committed.
In Git you can simply commit your experimental changes and push them (or let others pull them) when they are ready.
And if you frequently want to push immediately after commit, just make such a shortcut.
From what I have looked at, I would not call many of these "legitimate" in terms of whether enforcing them (if even possible) would do the world any good. But then, IMHO hardly any patents in my field, applied in any country or by companies from any country, are what I would call legitimate. Patent trolling is so ethically reprehensible that anyone deciding to join the game might as well commit plagiarism/fraud/bribery/etc. as long as they don't get caught. It's a fair game like spying in a war.
There are a few sensitive files in my home directory, such as my private key in ~/.ssh and a few configuration files that contains passwords in clear text. I really don't want these files to be shared inadvertently, yet they are currently treated as ordinary files by the SELinux on my Fedora 10 system, so any process running under my account can access these files. Of course I can still relabel the files and change my SELinux policy, but this is beyond the ability of most people. It is a shame that SELinux, with its huge potential, is so hard to use that it still provides very little security for an ordinary user.
Truetype fonts generally contain some information for hinting purposes, i.e. they tell the font renderer (Freetype) the best way to render the character at small pixel sizes. The "bytecode interpreter" that makes use of such information is available in Freetype, but the method is patented (IIRC by Apple) in the U.S., so most distributions turn it off by default. Without such information, Freetype has to decide the small-size rendering method all by itself ("autohinting"), and some people may find the result blurry.
If you are not in the U.S. or don't care for software patents, there are plenty of information on the Internet about how to turn on the bytecode interpreter in Freetype. For example, in Fedora you can simply download Freetype's source RPM and recompile it with rpmbuild using some --with options.
I listen to quite a lot of MIDI/XM/MOD stuff already, and some are actually very decent.