Patents are in some ways similar to nuclear weapons in that you can often (but not always) get Assured Mutual Destruction with them, therefore avoiding many lawsuits.
I feel just a bit concerned that a big country, such as the US, has nukes, but I would feel very concerned if some potentially unresponsible small country, such as North Korea, has nukes. Same for patents.
I support reunification, and so do most people around me. In my relatively mild opinion, since we have always believed that Taiwan is a part of China ever since 1945, and even now this is widely recognized by big players of the world (including the U.S. government), it would be utterly embarrassing if the current government lost it, and I will not even think about the possible practical issues that can result, for Taiwan is an island with much military importance. As for which side is morally "right", if the evidence is not entirely for us, at least it is not totally against us, so the issue is worth some debate. Though some people here support a war with Taiwan if they declare independence (I don't know how many; this is the official opinion, and most people on mainland BBSs and online forums support wars, but they do not necessarily represent the typical Chinese opinion), I personally hate to have a war on this, for I do find Taiwanese people quite nice and friendly (though my parents generally regard them as evil capitalists, because some Taiwanese companies in the mainland do not treat their workers too well), and I don't want to see deaths of our people and Taiwanese people and possible economic collapse. Letting Taiwan declare independence in peace is not an option either, at least until most people significantly change their ways of thinking, because of the embarrassment factor etc. as mentioned above, and if the Communist Party does not do anything about it, it will probably get overthrown. Maybe we can just use money and influence and threat to prevent influential nations to recognize the Taiwan if it did claim independence, but if that does not work, the government probably will decide to go to war. Thankfully I don't have to make such a dreadful decision.
As for the Communist Party, personally I don't really think it is communist any more. Communism may or may not work, I don't know, but the government is no longer going to experiment with it anyway, instead they want to make a more conventional captialistic society, and so be it. I support the Party for the most part yet disagree with them in some respects, for some of their propaganda is truly disgusting, but what they do is mostly reasonable. I don't want to comment on the Tiananmenn square incident, for I haven't investigated the issue yet.
Speaking as a Chinese in China... (so slashdot isn't blocked yet)
I have read about the first point on many semi-official sites, although the estimates of the number of deaths there is 10~40M, which is still staggering. Government officials do not seem to mind these articles much, and maybe it is published on something official.
As for the rest, since no one around me know the fact, I find it safer not to firmly believe anyone's opinion.
Authors can make money off their works during a short copyright term, then they can give the money to their kids. The kids themselves probably won't be able to make much more money anyway (unless the work is never published), since most best-sellers are mostly forgotten after 10 or 20 years.
In my opinion (that is, what I hope the law to be), if the author had stopped distributing some work, he should not have the right to sue over unauthorized copying during that unavailability, though the right can resume when the work is made publically available again, as long as the copyright term lasts. In other words, it is fair to make money off your works, but if you don't want to make that money, you should not restrict what we can do.
If the author wants to stop distribution while retaining exclusive rights of copying because he wants to create some scarcity, more elaborate measures, such as contracts with buyers, or at least registration, should be required. If the author/publisher stops distribution just because it is no longer profitable to make it available, it is against nobody's interest to allow the public to copy it without authorization. If the author decides not to distribute something until later, then the public are allowed to but cannot do any copying before the first publication (because no one else has a copy), while after publication the author do have exclusive rights over copying.
Your post refers to the current law, which IMHO is not very fair to the public.
The problem is that clueless coders will make an O(n) algorithm O(n^2) without knowing it, just by calling library subroutines, ignorant of their costs. They might also use expensive floating-point operations, such as division, more often than actually necessary. Because of floating-point issues, many compilers (notably newer Java VMs and gcc without -ffast-math) will only do a very limited range of floating-point optimizations, since the result might otherwise be different.
By knowing assembly and what the compiler can and cannot do, when writing programs that need some performance, one just give the compiler a few hints on what it can't do fully automatically (such as the algorithmic and floating-point issues above), and leave things that the compiler does well, such as register allocation, to the compiler. Readability usually is not hurt in this way; on the contrary, the program often appear cleaner.
Once upon a time I had a flaky IDE cable connecting to my hard drive. When the cable failed, I hardly noticed it until a minute later when a program locked up when I tried to start it, and Ctrl-C did not work. The system looked normal, except that any disk access will lock up the corresponding process, so not much can actually be done. I decided to exit X, but that also locked up before X exited, so I Ctrl-Alt-F1'd and saw tons of DMA errors. The only way to shutdown the machine normally was via Alt-SysRq-S(ync),U(nmount),B(oot), except that since the disk had stopped working, unmounting won't really help to prevent data loss.
If there is not enough user-visible registers, memory operands are used instead. However, these probably fits in the L1 cache anyway, and L1 cache is very fast (IIRC it is just one clock cycle on some CPUs). Also, the CPU can see that a later load depends on a preceding store, and the load can get the result from the preceding store directly. IIRC current processors already do this. So more user-visible general-purpose registers just reduces the number of load operations for the CPU to process, and since such operations do not cause much latency anyway (for they are working on the L1 cache, not the slow main memory), the performance increase would just be due to the load/store unit being less clobbered up, so that other load/store operations will not be delayed by them.
64-bit operations (addition and multiplication) are much faster on a 64-bit CPU such as Athlon 64, for on a 32-bit CPU they have to be emulated in software using multiple instructions, which is slower than the "hardware-accelerated" way in 64-bit CPUs.
I mean that current applications on current synchronous chips use external clock chips for the most part, but the CPU's own 3GHz clock is also used occasionally. Since it is not used all that often (definitely not needed for preemptive multitasking), applications that really need to use them currently can still use a high-frequency external clock chip instead when they are ported to these async CPUs.
As far as I know, Linux and many other operation systems already use an external chip (the 8254 on the PC) for most timing tasks, including preemptive multitasking. For ultra-high precision timing, the CPU clock (the time stamp counter on an IA32 cpu) is used, but they are not all that essential. Last time I heard, since CPU frequencies can change by power management functions on some P4s, they are a bit tricky to use correctly for timing, so they are not used when not absolutely needed.
As for the power problem, all parts of the CPU is powered, except that gates that aren't switching consume less power (mostly leakage, which seems to be quite significant now). In synchronous circuits, at least the gates connected directly to the clock signal switch all the time, while in asynchronous circuits unused parts of the CPU can avoid switching altogether, so some power may be saved, but I don't know how much it will be.
Here someone compiled kernel 2.5.7 on a 32-way Power4 1.1GHz within 7.52 seconds, in 2002.
Now suppose TCC is 10 times as fast as GCC (which is true based on my experience), the 32-way machine is 20 time as fast as than a single Power4 (the kerneltrap site said "2246% CPU usage"), and the 2.4GHz Pentium4 is as fast as a 1.1GHz Power4, then building the kernel just takes 15 seconds. Of course, it is a rough estimate, and I suspect the P4 should be faster than a 2002-ish Power4 for cpu-intensive job such as compilation.
The theorem is: let {a_n} be a series of independent and identically distributed random variables with variance sigma^2, S_n be its partial sum (in other words, S_n=a_1+a_2+...+a_n), then
lim sup_{n->infinity} abs(S_n)/(sigma*sqrt(2*n*log(log(n))))=1, almost surely.
To put it more plainly, suppose you do a random walk, starting from origin, and every second you goes one step right or left with equal probability and independent from your earlier steps. Intuitively, as time goes by, you will reach places farther and farther from the origin. Indeed, after n seconds and for very large n, according to the central limit algorithm (which is taught in most elementary probability classes) your position will almost follow the Gaussian distribution with a standard deviation of sqrt(n) steps. In other words, after n seconds, you will have about 5% chance to be more than 1.96*sqrt(n) steps from the origin, a 0.1% chance to be more than 3.29*sqrt(n) steps from the origin, etc. However, it is always possible that you be as far as 10*sqrt(n) or 100*sqrt(n) from the origin (of course no farther than n steps), though the probability is very small. This theorem in a sense puts a limit on this variation of your distance from the origin. It basically means that almost every time you do such a random walk ("almost surely" means "with probability one", so it can fail to happen in principle but not in real life), you are going to get farther than sqrt(n), or 10*sqrt(n), 100*sqrt(n), etc., at some (possible very large) time n; indeed you will get as far as sqrt(1.999*log(log(n)))*sqrt(n) for infinitely many times; however, if you happen to get as far as sqrt(2.001*log(log(n)))*sqrt(n), take care to record that splendid event, for it will happen only for a finite number of times, after which you will never get this far (relative to n) during this random walk! Sounds a little complex, but simpler propositions such as "you will never get farther than 5*sqrt(n) before time n" are obviously wrong.
It is fascinating because stuff like log(log(x)) does not occur very often in fundamental mathematics (except maybe in the complexity analysis of algorithms), but it occurs here as a very strong and important result concerning a problem often met in everyday life.
If Nvidia had offered open-source drivers, it and AMD would have got my money when I bought my last computer. As it is, I just bought an Intel-based machine with integrated graphics, which isn't a good 3D accelerator, but at least it works and is very well supported, even in bleeding-edge kernels.
Closed-source drivers may be good enough for ordinary users, but for a hobbyist doing much low-level development work, a piece of mysterious code (especially in the kernel) can become a significant hurdle. It also means that I can't have my kernel too different from a Nvidia-tested one (their current wrappers can accommodate ), which is sometimes needed for some advanced bleeding-edge feature. Sure, they kept up with the 2.6 release relatively well, but who knows about future releases? Or what if I used a patch from IBM to have some feature not normally needed by gamers? With source at least I can do something, which is a warm fuzzy feeling even if I may not have the time for it.
Non-final non-private methods generally cannot be inlined by GCJ because they may be overridden by subclasses, but with a JIT compiler such methods can be inlined if the class they are in has no subclasses loaded (which is among the majority of cases).
Also gcj-compiled programs may have worse garbage collection. AFAIK a simple conservative GC is used.
I don't think commonly-used Java JIT compilers do much more than this.
Besides the lack of struct types (which I find painful to use, but they at least are there when I need them), Java also makes every non-private-non-final method virtual, which AFAIK means less opportunity for inlining.
Also, the lack of unsigned types in Java can sometimes be painful.
The grandparent did not deny the existence of such tools. The problem of these tools is that they are very clumsy to deal with anything but the simplest cases. Drag-n-drop is just slower than typing, and you also have to arrange the placement of the boxes besides connecting them correctly. I have not used BizTalk, but I think my experience with Simulink and LabView qualifies me to say that such tools are mostly only useful for the highest level architecture, while lower-level logic are still better expressed in code currently.
Many GNU programs are very well documented, such as Emacs/XEmacs, gcc, glibc, gmp (a multi-precision computing library), gsl (GNU Scientific library). Just read the info page, or if you want something prettier, grab the TeXinfo files in the source package and make a PDF version.
It depends on the popularity... if a library becomes very widely used, its documentation will improve by itself. GTK documentation had been almost nonexistent during the 1.x days (just a tutorial), but now it is mostly acceptable, albeit still not very complete, thanks to so many people needing it.
Speech coding techniques used in VoIP are well tuned to human speech, for which it may still have poorer quality than ordinary phone lines in terms of signal-to-noise ratio, but sounds about the same quality to the human ear. When a modulated signal is fed into a speech coder, you get way poorer SNR than a telephone line, so the transfer rate you can achieve is generally much lower than the 33.6kbps achievable on a phone line, and definitely much less than the size of all these VoIP packets generated, so there is no point anyway.
Exceptions...
on
Java 1.5 vs C#
·
· Score: 2, Interesting
In C++ the decision whether or not to make use of exceptions is hard to make. If you don't use exceptions, the results of many function calls have to be checks, which is considerably more of a hassle than Java. If exceptions are used, writing exception-safe code is really quite limiting (It often means significantly more little objects when "new" can't be used freely, and much of the existing code have to be rewritten, and I hate comments like "func() can't throw, so this is safe"). Seems that an garbage-collecting language like Java/C# is very helpful if one want to use exceptions.
I think a delay after the books become out-of-print is not really necessary. On the other hand, we don't immediately make the work public-domain when it becomes unavailable, we just make it legal to copy and distribute such works in any way during the unavailable period, and if the copyright holder decide to make the world available again (within the copyright term), other distributors should stop upon notice.
In this way a website can be set up to disseminate digital copies of out-of-print works, and taking down the thing should not cost much in case the thing become in-print again (a dead-tree version of this may be risky, since printing has some considerable up-front cost, but this has at least become legal, while it is probably illegal under current law), and much much fewer valuable works will get lost. As for the "authorized" publisher, if the sales have fallen so low that it has become unprofitable to keep the printer running, they should have got most of the profit they can ever gain anyway, and even if the work happens to become popular again they can still restart printing and gain most of the profit from the exclusive copyright.
Slashdot Mirror
I feel just a bit concerned that a big country, such as the US, has nukes, but I would feel very concerned if some potentially unresponsible small country, such as North Korea, has nukes. Same for patents.
I support reunification, and so do most people around me. In my relatively mild opinion, since we have always believed that Taiwan is a part of China ever since 1945, and even now this is widely recognized by big players of the world (including the U.S. government), it would be utterly embarrassing if the current government lost it, and I will not even think about the possible practical issues that can result, for Taiwan is an island with much military importance. As for which side is morally "right", if the evidence is not entirely for us, at least it is not totally against us, so the issue is worth some debate. Though some people here support a war with Taiwan if they declare independence (I don't know how many; this is the official opinion, and most people on mainland BBSs and online forums support wars, but they do not necessarily represent the typical Chinese opinion), I personally hate to have a war on this, for I do find Taiwanese people quite nice and friendly (though my parents generally regard them as evil capitalists, because some Taiwanese companies in the mainland do not treat their workers too well), and I don't want to see deaths of our people and Taiwanese people and possible economic collapse. Letting Taiwan declare independence in peace is not an option either, at least until most people significantly change their ways of thinking, because of the embarrassment factor etc. as mentioned above, and if the Communist Party does not do anything about it, it will probably get overthrown. Maybe we can just use money and influence and threat to prevent influential nations to recognize the Taiwan if it did claim independence, but if that does not work, the government probably will decide to go to war. Thankfully I don't have to make such a dreadful decision.
As for the Communist Party, personally I don't really think it is communist any more. Communism may or may not work, I don't know, but the government is no longer going to experiment with it anyway, instead they want to make a more conventional captialistic society, and so be it. I support the Party for the most part yet disagree with them in some respects, for some of their propaganda is truly disgusting, but what they do is mostly reasonable. I don't want to comment on the Tiananmenn square incident, for I haven't investigated the issue yet.
Lenovo makes pretty good computers, based on my only experience with them, the very computer I'm using now.
I have read about the first point on many semi-official sites, although the estimates of the number of deaths there is 10~40M, which is still staggering. Government officials do not seem to mind these articles much, and maybe it is published on something official.
As for the rest, since no one around me know the fact, I find it safer not to firmly believe anyone's opinion.
Authors can make money off their works during a short copyright term, then they can give the money to their kids. The kids themselves probably won't be able to make much more money anyway (unless the work is never published), since most best-sellers are mostly forgotten after 10 or 20 years.
If the author wants to stop distribution while retaining exclusive rights of copying because he wants to create some scarcity, more elaborate measures, such as contracts with buyers, or at least registration, should be required. If the author/publisher stops distribution just because it is no longer profitable to make it available, it is against nobody's interest to allow the public to copy it without authorization. If the author decides not to distribute something until later, then the public are allowed to but cannot do any copying before the first publication (because no one else has a copy), while after publication the author do have exclusive rights over copying.
Your post refers to the current law, which IMHO is not very fair to the public.
By knowing assembly and what the compiler can and cannot do, when writing programs that need some performance, one just give the compiler a few hints on what it can't do fully automatically (such as the algorithmic and floating-point issues above), and leave things that the compiler does well, such as register allocation, to the compiler. Readability usually is not hurt in this way; on the contrary, the program often appear cleaner.
The quote was made in 1956, while the period of free speech and the subsequent crackdown was in 1957.
Once upon a time I had a flaky IDE cable connecting to my hard drive. When the cable failed, I hardly noticed it until a minute later when a program locked up when I tried to start it, and Ctrl-C did not work. The system looked normal, except that any disk access will lock up the corresponding process, so not much can actually be done. I decided to exit X, but that also locked up before X exited, so I Ctrl-Alt-F1'd and saw tons of DMA errors. The only way to shutdown the machine normally was via Alt-SysRq-S(ync),U(nmount),B(oot), except that since the disk had stopped working, unmounting won't really help to prevent data loss.
If there is not enough user-visible registers, memory operands are used instead. However, these probably fits in the L1 cache anyway, and L1 cache is very fast (IIRC it is just one clock cycle on some CPUs). Also, the CPU can see that a later load depends on a preceding store, and the load can get the result from the preceding store directly. IIRC current processors already do this. So more user-visible general-purpose registers just reduces the number of load operations for the CPU to process, and since such operations do not cause much latency anyway (for they are working on the L1 cache, not the slow main memory), the performance increase would just be due to the load/store unit being less clobbered up, so that other load/store operations will not be delayed by them.
64-bit operations (addition and multiplication) are much faster on a 64-bit CPU such as Athlon 64, for on a 32-bit CPU they have to be emulated in software using multiple instructions, which is slower than the "hardware-accelerated" way in 64-bit CPUs.
I mean that current applications on current synchronous chips use external clock chips for the most part, but the CPU's own 3GHz clock is also used occasionally. Since it is not used all that often (definitely not needed for preemptive multitasking), applications that really need to use them currently can still use a high-frequency external clock chip instead when they are ported to these async CPUs.
As for the power problem, all parts of the CPU is powered, except that gates that aren't switching consume less power (mostly leakage, which seems to be quite significant now). In synchronous circuits, at least the gates connected directly to the clock signal switch all the time, while in asynchronous circuits unused parts of the CPU can avoid switching altogether, so some power may be saved, but I don't know how much it will be.
Neither the kernel proper nor kernel modules are commonly called "userspace".
Now suppose TCC is 10 times as fast as GCC (which is true based on my experience), the 32-way machine is 20 time as fast as than a single Power4 (the kerneltrap site said "2246% CPU usage"), and the 2.4GHz Pentium4 is as fast as a 1.1GHz Power4, then building the kernel just takes 15 seconds. Of course, it is a rough estimate, and I suspect the P4 should be faster than a 2002-ish Power4 for cpu-intensive job such as compilation.
The theorem is: let {a_n} be a series of independent and identically distributed random variables with variance sigma^2, S_n be its partial sum (in other words, S_n=a_1+a_2+...+a_n), then
lim sup_{n->infinity} abs(S_n)/(sigma*sqrt(2*n*log(log(n))))=1, almost surely.
To put it more plainly, suppose you do a random walk, starting from origin, and every second you goes one step right or left with equal probability and independent from your earlier steps. Intuitively, as time goes by, you will reach places farther and farther from the origin. Indeed, after n seconds and for very large n, according to the central limit algorithm (which is taught in most elementary probability classes) your position will almost follow the Gaussian distribution with a standard deviation of sqrt(n) steps. In other words, after n seconds, you will have about 5% chance to be more than 1.96*sqrt(n) steps from the origin, a 0.1% chance to be more than 3.29*sqrt(n) steps from the origin, etc. However, it is always possible that you be as far as 10*sqrt(n) or 100*sqrt(n) from the origin (of course no farther than n steps), though the probability is very small. This theorem in a sense puts a limit on this variation of your distance from the origin. It basically means that almost every time you do such a random walk ("almost surely" means "with probability one", so it can fail to happen in principle but not in real life), you are going to get farther than sqrt(n), or 10*sqrt(n), 100*sqrt(n), etc., at some (possible very large) time n; indeed you will get as far as sqrt(1.999*log(log(n)))*sqrt(n) for infinitely many times; however, if you happen to get as far as sqrt(2.001*log(log(n)))*sqrt(n), take care to record that splendid event, for it will happen only for a finite number of times, after which you will never get this far (relative to n) during this random walk! Sounds a little complex, but simpler propositions such as "you will never get farther than 5*sqrt(n) before time n" are obviously wrong.
It is fascinating because stuff like log(log(x)) does not occur very often in fundamental mathematics (except maybe in the complexity analysis of algorithms), but it occurs here as a very strong and important result concerning a problem often met in everyday life.
Closed-source drivers may be good enough for ordinary users, but for a hobbyist doing much low-level development work, a piece of mysterious code (especially in the kernel) can become a significant hurdle. It also means that I can't have my kernel too different from a Nvidia-tested one (their current wrappers can accommodate ), which is sometimes needed for some advanced bleeding-edge feature. Sure, they kept up with the 2.6 release relatively well, but who knows about future releases? Or what if I used a patch from IBM to have some feature not normally needed by gamers? With source at least I can do something, which is a warm fuzzy feeling even if I may not have the time for it.
Also gcj-compiled programs may have worse garbage collection. AFAIK a simple conservative GC is used.
I don't think commonly-used Java JIT compilers do much more than this.
Also, the lack of unsigned types in Java can sometimes be painful.
I wonder why there has not been any "In Japan" jokes here!
The grandparent did not deny the existence of such tools. The problem of these tools is that they are very clumsy to deal with anything but the simplest cases. Drag-n-drop is just slower than typing, and you also have to arrange the placement of the boxes besides connecting them correctly. I have not used BizTalk, but I think my experience with Simulink and LabView qualifies me to say that such tools are mostly only useful for the highest level architecture, while lower-level logic are still better expressed in code currently.
It depends on the popularity... if a library becomes very widely used, its documentation will improve by itself. GTK documentation had been almost nonexistent during the 1.x days (just a tutorial), but now it is mostly acceptable, albeit still not very complete, thanks to so many people needing it.
Speech coding techniques used in VoIP are well tuned to human speech, for which it may still have poorer quality than ordinary phone lines in terms of signal-to-noise ratio, but sounds about the same quality to the human ear. When a modulated signal is fed into a speech coder, you get way poorer SNR than a telephone line, so the transfer rate you can achieve is generally much lower than the 33.6kbps achievable on a phone line, and definitely much less than the size of all these VoIP packets generated, so there is no point anyway.
In C++ the decision whether or not to make use of exceptions is hard to make. If you don't use exceptions, the results of many function calls have to be checks, which is considerably more of a hassle than Java. If exceptions are used, writing exception-safe code is really quite limiting (It often means significantly more little objects when "new" can't be used freely, and much of the existing code have to be rewritten, and I hate comments like "func() can't throw, so this is safe"). Seems that an garbage-collecting language like Java/C# is very helpful if one want to use exceptions.
In this way a website can be set up to disseminate digital copies of out-of-print works, and taking down the thing should not cost much in case the thing become in-print again (a dead-tree version of this may be risky, since printing has some considerable up-front cost, but this has at least become legal, while it is probably illegal under current law), and much much fewer valuable works will get lost. As for the "authorized" publisher, if the sales have fallen so low that it has become unprofitable to keep the printer running, they should have got most of the profit they can ever gain anyway, and even if the work happens to become popular again they can still restart printing and gain most of the profit from the exclusive copyright.