This is absolutely false. You can say bad things about former employees.
Many people don't because they don't want to run the risk of the former
employee finding out and suing for defamation. If you are confident that
what you say is true and that you can defend it if necessary, or are confident
that the ex-employee won't find out, you can say negative things. Its a matter of how much risk there is of a suit for defamation.
Got any statistics from a less self-interested source? That seems awfully high, and given the history of false child molestation cases created by unqualified "therapists", I'm reluctant to credit such a source.
Lawsuits in which there is no real dispute and the plaintiff and defendant collaborate
for the purpose of obtaining what is in effect a declaratory judgement are prohibited at Common Law. There is a term for them but I'm having an elder's moment and can't remember it.
If the court figures it out, you'll be in trouble.
I don't think I've ever seen a movie recorded by a camcorder in a movie theatre, but I would think that the quality would be awful. If so, who would want to watch them? Maybe the small percentage of people desperate to see something as soon as it comes out, but aren't those the same people who are going to want a quality version and buy the DVD when they can? Is there evidence that the movie companies lose ANY money this way?
What you're missing is that someone who is paid by Microsoft but who makes decisions independent of Microsoft and is not biased in advance,
is not an agent of Microsoft. Pay often creates a conflict of interest either because the person paid is subject to the direction of the employer, but there is not a necessary connection between being paid and lacking independence.
A good example of the distinction is a special prosecutor when appointed due to a conflict of interest
I'm no fan of Microsoft, but I don't think that just because they pay someone
that makes it FUD. The is not who pays but who decides what edits to make. If they pay someone who decides on his own what to do, he is an independent agent.
And in this case, since the edits will be public and reversible if other people find them incorrect, I don't see a problem.
Everything must be in neutral POV for it to be acceptable, however sometimes an objective POV is better.
If by "objective POV" you mean that, for example, the article on the shape of the earth could come down on the side of "spherical" rather than "float", I think that the NPOV policy allows that. The intended interpretation of the policy against POV is, as I understand it, that where there is an issue all sides should be presented fairly. That means that one mentions that there are people who believe that the earth is flat, and to the extent that they have rational reasons for their belief, presents them accurately, but that one can still say that the scientific consensus is that they are wrong.
The idea that the NPOV policy means that an article "can't take sides" is, unfortunately, a common misconception among people who edit Wikipedia articles. I have seen, for example, people object to including crank "archaeologist" Barry Fell's work in the pseudoscience category on the grounds that this is POV. This is actually a fairly serious problem with Wikipedia since it means that proponents of silly ideas (usually crank science or nationalistic pseudohistory) get far too much leeway. In sum, at least as I understand the intention of the policy, you're wrong, but in practice, you're right.
Wrong. This is not the "if there were no laws there would be no crime argument." Read and think more carefully. Rather, I'm distinguishing between child molestation, which is harmful, and viewing child porn, which is not.
The real point that I take away from this is that laws against child pornography ARE the problem. The solution is to legalize it. These laws create enormous problems. They provide a basis for invasions of privacy that would otherwise not take place, and they result in ordeals like this one for far too many innocent people. In addition to the problem that innocent people can easily end up with child porn on their computers inadvertently, there is also the problem that child porn is ill-defined. People have been prosecuted for taking pictures of their kids naked at the beach or in the back yard.
The evidence that viewing child porn encourages child molestation is weak at best. However repulsive it may seem to most of us, the policy reasons for banning child pornography are minimal. The harm that these laws do is far greater.
This isn't to say that child molestation is acceptable. People who molest children, and that includes those who make child pornography involving real children (yes, people have been prosecuted for "child porn" consisting of purely imaginary drawings) should prosecuted, but the laws against child porn should be repealed.
Right. And following another tradition, the various versions of Fortress will be called:
Graphite, Gypsum, Apatite, Quartz, and Diamond or something like that.
I have some sympathy for the cop, but at the same time, for the same reasons that I like the GPL, I understand the State's desire to have the source. Who should benefit from commercial sale is another issue, but if I were the head of the State Police and officers were using this software, I would want to have the source so that it could be adapted to changing equipment and so that bugs could be fixed.
Re:Genuine question about perl vs ruby
on
Lisp and Ruby
·
· Score: 1
You've shifted to a different question. Sure, if you're only dealing with Japanese, since the Japanese encodings handle Japanese just fine, there is indeed no incentive to shift to Unicode, but that is different from it being impossible or even all that difficult to use Unicode. On the other hand, if you need to handle lots of different writing systems there is incentive to use Unicode since the Japanese encodings are not comprehensive the way Unicode is (except maybe TRON, which is said to be huge but for which I've never seen the actual list of characters).
The fact that the Japanese government is no longer unified on the joyokanzi and no longer
enforces the list rigorously does not change the fact that any limitation on obscure name characters is due to the Japanese government, not Unicode. The Unicode Consortium couldn't care less about how Japanese names are written - that's a purely Japanese issue - and can easily add new characters if there is reason to do so. Unicode has no policy of restricting encoding to characters currently in use or approved by a government. Can you provide an example of a character used for names that has been proposed to the Unicode Consortium for inclusion in Unicode and rejected?
He may have expressed irritation, but he still asked a perfectly valid question.
He's entitled to know if Apple agrees that there is a driver bug or thinks that
something else is going on, and if it is a driver bug, are they working on it and
when can the fix be expected.
Re:Genuine question about perl vs ruby
on
Lisp and Ruby
·
· Score: 1
The fact that "bone" looks different in Chinese and Japanese is something that can be handled by font choice, as I said before. Personally I'd prefer separate encoding, but as I said, there is no evidence that this is such a big problem. If you really think that it is, explain why rather than just repeating this.
I don't understand why you think that Unicode can't deal with the need to add
characters. There is plenty of space for adding characters and they have already done
so. The omission of obscure characters used only for names has nothing to do with Unicode. That is a Japanese government policy. It first came up when the writing system was reformed in the 1950s. At that time the rekisiteki kanazukai "historical kana usage" was abolished, simplified versions of many characters were made official, and the number of characters officially recognized was limited. The official list of characters omitted quite a few obscure characters used in names. This was important because the government will not register a name that contains characters not on the Ministry of Education list, so no Japanese citizen could have such a name as his or her legal name. This created an outcry, so the Ministry eventually relented and added 50 such characters to the list. This issue comes up from time to time with regard to other names. Of course, outside of official documents people can and do use characters not on the official list, and most Japanese characters not on the official list are in use in Chinese or Korean, so even if Unicode restricted itself to the Japanese government's official list most of these characters would be included. Anyhow, Unicode can perfectly well accomodate numerous additional characters if there is reason to do so and is no way responsible for the Japanese government's limitations on which characters can appear in names.
Re:Genuine question about perl vs ruby
on
Lisp and Ruby
·
· Score: 1
So Ruby is the output of a plan to take a syntax-less language and make it a bit more like a language with, IMO, one of the shittiest syntaxes around?
Very well put. (I already posted in this discussion so can't mod you up.) If you want a language like Lisp but with more syntactic sugar, try Tcl for a nice, simple scripting language or Haskell for a
sophisticated compiled functional language. Perl is not the model to emulate.
Re:Genuine question about perl vs ruby
on
Lisp and Ruby
·
· Score: 1
I basically agree with the above, but in the case of Unicode as opposed to Shift-JIS,
I think that the Japanese attitude is largely a case of not-invented-here. The Unicode
people included people who were quite knowledgable about Chinese characters and well aware of the glyph variants. It just isn't true that only East Asians know about this stuff.
Furthermore, the Unicode solution, of making glyph variation a matter of font selection,
actually works quite well for almost all applications. I haven't seen anything to indicate that there is a real practical problem here. Ironically, the people for whom it would be desirable to encode the variant glyphs are a small minority of typographers and linguists like myself who want to be able to select glyph variants easily so as to write about them in the same piece of text. The great majority of users have no interest in contrasting variants of same character. So, in spite of the fact that I don't really like Han Unification myself I am not persuaded that the Japanese rejection of Unicode has much to do with practical problems caused by it.
Re:Why do you have to stick to scripting?
on
Lisp and Ruby
·
· Score: 1
I'm always surprised to see how much attention is focussed on a small set of languages, mostly Perl, Python, and Ruby. As the parent says, Pike is very fast with a syntax familiar to C programmers but with the typical virtues of a scripting language. It's a mystery to me why it seems to get so little use outside of the Scandinavian countries and Germany.
Another neglected language is Tcl. It isn't a speed champion, but on the shootout it comes in ahead of PHP and Ruby, not far behind Perl and Python. (It probably should rank higher. It gets no credit for the chamaneos benchmark simply because that benchmark requires the threads package which was not installed on the machine on which the benchmark was run. That is hardly a defect of Tcl.) It has good, native support for Unicode and is easily extendable in C (it was originally designed as an embedded language). There are quite a few libraries and extensions available, including several object-oriented extensions, and of course it is the native language of the Tk windowing and graphics tookit. It is actually quite Lisp-like, with arguably just the right amount of syntactic sugar. This unusually simple syntax (in comparison with just about everything other than LISP) is a great advantage over Perl with its complex syntax and numerous special cases and tricks, and over Ruby, to the extent that Ruby emulates Perl's icky syntax.
What went wrong there wasn't simply due to use of two systems of units. If the measurements had been accompanied by the units, as they should have been, such an error would have been much less likely. If you're NASA and expect a measurement with dimensions of dynes per square centimeter and a contractor sends you something like "3 pounds per square inch", unless you're an idiot you aren't simply going to decide that this means "3 dynes per square centimeter" and stick it into your metric equations. So I suspect that there was some sloppy engineering involved here that allowed the disparity in units to become problematic.
To add to your point, what about the input format? Are they going to come from text files or user input in the form of strings? Can you assume ASCII decimal standard format? What about scientific notation? Can they be in hex, octal, or binary? What about numbers in Chinese or Gurmukhi or Thai?
I recently bought a laptop with Ubuntu pre-installed from The Linux Store, which is in Ontario. I've been perfectly satisfied aside from the minor point that they only offer the choice of Ubuntu and Fedora Core when I would have preferred Debian.
Slashdot Mirror
This is absolutely false. You can say bad things about former employees. Many people don't because they don't want to run the risk of the former employee finding out and suing for defamation. If you are confident that what you say is true and that you can defend it if necessary, or are confident that the ex-employee won't find out, you can say negative things. Its a matter of how much risk there is of a suit for defamation.
Just out of curiosity, what is involved in maintaining a little used tdl? I mean, they don't rust, do they?
Got any statistics from a less self-interested source? That seems awfully high, and given the history of false child molestation cases created by unqualified "therapists", I'm reluctant to credit such a source.
Lawsuits in which there is no real dispute and the plaintiff and defendant collaborate for the purpose of obtaining what is in effect a declaratory judgement are prohibited at Common Law. There is a term for them but I'm having an elder's moment and can't remember it. If the court figures it out, you'll be in trouble.
But, if you turn this around, it provides another argument that Parliament will like: it promotes Canadian TV and movie producers.
I don't think I've ever seen a movie recorded by a camcorder in a movie theatre, but I would think that the quality would be awful. If so, who would want to watch them? Maybe the small percentage of people desperate to see something as soon as it comes out, but aren't those the same people who are going to want a quality version and buy the DVD when they can? Is there evidence that the movie companies lose ANY money this way?
What you're missing is that someone who is paid by Microsoft but who makes decisions independent of Microsoft and is not biased in advance, is not an agent of Microsoft. Pay often creates a conflict of interest either because the person paid is subject to the direction of the employer, but there is not a necessary connection between being paid and lacking independence.
A good example of the distinction is a special prosecutor when appointed due to a conflict of interest
I'm no fan of Microsoft, but I don't think that just because they pay someone that makes it FUD. The is not who pays but who decides what edits to make. If they pay someone who decides on his own what to do, he is an independent agent. And in this case, since the edits will be public and reversible if other people find them incorrect, I don't see a problem.
If by "objective POV" you mean that, for example, the article on the shape of the earth could come down on the side of "spherical" rather than "float", I think that the NPOV policy allows that. The intended interpretation of the policy against POV is, as I understand it, that where there is an issue all sides should be presented fairly. That means that one mentions that there are people who believe that the earth is flat, and to the extent that they have rational reasons for their belief, presents them accurately, but that one can still say that the scientific consensus is that they are wrong.
The idea that the NPOV policy means that an article "can't take sides" is, unfortunately, a common misconception among people who edit Wikipedia articles. I have seen, for example, people object to including crank "archaeologist" Barry Fell's work in the pseudoscience category on the grounds that this is POV. This is actually a fairly serious problem with Wikipedia since it means that proponents of silly ideas (usually crank science or nationalistic pseudohistory) get far too much leeway. In sum, at least as I understand the intention of the policy, you're wrong, but in practice, you're right.
Wrong. This is not the "if there were no laws there would be no crime argument." Read and think more carefully. Rather, I'm distinguishing between child molestation, which is harmful, and viewing child porn, which is not.
The real point that I take away from this is that laws against child pornography ARE the problem. The solution is to legalize it. These laws create enormous problems. They provide a basis for invasions of privacy that would otherwise not take place, and they result in ordeals like this one for far too many innocent people. In addition to the problem that innocent people can easily end up with child porn on their computers inadvertently, there is also the problem that child porn is ill-defined. People have been prosecuted for taking pictures of their kids naked at the beach or in the back yard.
The evidence that viewing child porn encourages child molestation is weak at best. However repulsive it may seem to most of us, the policy reasons for banning child pornography are minimal. The harm that these laws do is far greater. This isn't to say that child molestation is acceptable. People who molest children, and that includes those who make child pornography involving real children (yes, people have been prosecuted for "child porn" consisting of purely imaginary drawings) should prosecuted, but the laws against child porn should be repealed.
Right. And following another tradition, the various versions of Fortress will be called: Graphite, Gypsum, Apatite, Quartz, and Diamond or something like that.
I have some sympathy for the cop, but at the same time, for the same reasons that I like the GPL, I understand the State's desire to have the source. Who should benefit from commercial sale is another issue, but if I were the head of the State Police and officers were using this software, I would want to have the source so that it could be adapted to changing equipment and so that bugs could be fixed.
You've shifted to a different question. Sure, if you're only dealing with Japanese, since the Japanese encodings handle Japanese just fine, there is indeed no incentive to shift to Unicode, but that is different from it being impossible or even all that difficult to use Unicode. On the other hand, if you need to handle lots of different writing systems there is incentive to use Unicode since the Japanese encodings are not comprehensive the way Unicode is (except maybe TRON, which is said to be huge but for which I've never seen the actual list of characters).
The fact that the Japanese government is no longer unified on the joyokanzi and no longer enforces the list rigorously does not change the fact that any limitation on obscure name characters is due to the Japanese government, not Unicode. The Unicode Consortium couldn't care less about how Japanese names are written - that's a purely Japanese issue - and can easily add new characters if there is reason to do so. Unicode has no policy of restricting encoding to characters currently in use or approved by a government. Can you provide an example of a character used for names that has been proposed to the Unicode Consortium for inclusion in Unicode and rejected?
He may have expressed irritation, but he still asked a perfectly valid question. He's entitled to know if Apple agrees that there is a driver bug or thinks that something else is going on, and if it is a driver bug, are they working on it and when can the fix be expected.
The fact that "bone" looks different in Chinese and Japanese is something that can be handled by font choice, as I said before. Personally I'd prefer separate encoding, but as I said, there is no evidence that this is such a big problem. If you really think that it is, explain why rather than just repeating this.
I don't understand why you think that Unicode can't deal with the need to add characters. There is plenty of space for adding characters and they have already done so. The omission of obscure characters used only for names has nothing to do with Unicode. That is a Japanese government policy. It first came up when the writing system was reformed in the 1950s. At that time the rekisiteki kanazukai "historical kana usage" was abolished, simplified versions of many characters were made official, and the number of characters officially recognized was limited. The official list of characters omitted quite a few obscure characters used in names. This was important because the government will not register a name that contains characters not on the Ministry of Education list, so no Japanese citizen could have such a name as his or her legal name. This created an outcry, so the Ministry eventually relented and added 50 such characters to the list. This issue comes up from time to time with regard to other names. Of course, outside of official documents people can and do use characters not on the official list, and most Japanese characters not on the official list are in use in Chinese or Korean, so even if Unicode restricted itself to the Japanese government's official list most of these characters would be included. Anyhow, Unicode can perfectly well accomodate numerous additional characters if there is reason to do so and is no way responsible for the Japanese government's limitations on which characters can appear in names.
Very well put. (I already posted in this discussion so can't mod you up.) If you want a language like Lisp but with more syntactic sugar, try Tcl for a nice, simple scripting language or Haskell for a sophisticated compiled functional language. Perl is not the model to emulate.
I basically agree with the above, but in the case of Unicode as opposed to Shift-JIS, I think that the Japanese attitude is largely a case of not-invented-here. The Unicode people included people who were quite knowledgable about Chinese characters and well aware of the glyph variants. It just isn't true that only East Asians know about this stuff. Furthermore, the Unicode solution, of making glyph variation a matter of font selection, actually works quite well for almost all applications. I haven't seen anything to indicate that there is a real practical problem here. Ironically, the people for whom it would be desirable to encode the variant glyphs are a small minority of typographers and linguists like myself who want to be able to select glyph variants easily so as to write about them in the same piece of text. The great majority of users have no interest in contrasting variants of same character. So, in spite of the fact that I don't really like Han Unification myself I am not persuaded that the Japanese rejection of Unicode has much to do with practical problems caused by it.
I'm always surprised to see how much attention is focussed on a small set of languages, mostly Perl, Python, and Ruby. As the parent says, Pike is very fast with a syntax familiar to C programmers but with the typical virtues of a scripting language. It's a mystery to me why it seems to get so little use outside of the Scandinavian countries and Germany.
Another neglected language is Tcl. It isn't a speed champion, but on the shootout it comes in ahead of PHP and Ruby, not far behind Perl and Python. (It probably should rank higher. It gets no credit for the chamaneos benchmark simply because that benchmark requires the threads package which was not installed on the machine on which the benchmark was run. That is hardly a defect of Tcl.) It has good, native support for Unicode and is easily extendable in C (it was originally designed as an embedded language). There are quite a few libraries and extensions available, including several object-oriented extensions, and of course it is the native language of the Tk windowing and graphics tookit. It is actually quite Lisp-like, with arguably just the right amount of syntactic sugar. This unusually simple syntax (in comparison with just about everything other than LISP) is a great advantage over Perl with its complex syntax and numerous special cases and tricks, and over Ruby, to the extent that Ruby emulates Perl's icky syntax.
A small point, but there are 1760 yards in a mile.
What went wrong there wasn't simply due to use of two systems of units. If the measurements had been accompanied by the units, as they should have been, such an error would have been much less likely. If you're NASA and expect a measurement with dimensions of dynes per square centimeter and a contractor sends you something like "3 pounds per square inch", unless you're an idiot you aren't simply going to decide that this means "3 dynes per square centimeter" and stick it into your metric equations. So I suspect that there was some sloppy engineering involved here that allowed the disparity in units to become problematic.
To add to your point, what about the input format? Are they going to come from text files or user input in the form of strings? Can you assume ASCII decimal standard format? What about scientific notation? Can they be in hex, octal, or binary? What about numbers in Chinese or Gurmukhi or Thai?
They may not be complete solutions, but a few practices avoid a lot of problems:
I recently bought a laptop with Ubuntu pre-installed from The Linux Store, which is in Ontario. I've been perfectly satisfied aside from the minor point that they only offer the choice of Ubuntu and Fedora Core when I would have preferred Debian.
That's good. The Daily Kos story said that he was shut down because he couldn't afford a lawyer. I guess he found out about counter-notification.