You can provide evidence (and predictions) for or against specific historical theories.
Of course. Yet you cannot use empiricism to determine whether a historical event happened. That doesn't mean there's anything wrong with empiricism. It merely means that empiricism is inappropriate for answering that question.
There is absolutely no evidence supporting any of the supernatural claims in any of the genesis myths of any of the worlds' religions. None.
Is the assertion "Life arose from non-life around three billion years ago on the prehistoric earth" falsifiable without resorting to some form of the anthropic principle?
I do not know what exactly is although I believe it is related with the equivalence of the colors in the screen with the colors actually printed and without CMYK the equivalence is not accurate.
At a very basic level, your monitor produces colors with an additive scheme (where the base color is black and you add light to produce colors) and print uses a subtractive scheme (where the base color is white and you add colors to prevent reflection of various other colors). There are colors which one gamut can produce that the other cannot.
I certainly hope that people evaluate my comments for technical accuracy, but I do appreciate your elaboration and will try to draw clearer lines between fact and opinion. Thank you.
English has a perfectly good word which means "distribute". That word is "distribute". Using the word "use" when you mean "distribute" is unnecessary and confusing. There are plenty of people on Slashdot who apparently believe that merely using GPLd code means that you have to make modifications available to the entire world. It would be nice to reduce that confusion by being precise in language.
(Yes, I'm aware of the irony of conflating the words "free" and "libre".)
Shall I stifle my opinions because I happen to have some expertise in a subject area? Would you feel better if I had also said that Perl's support for tailcall optimization is less than ideal because it requires syntax and that syntax is ugly and that Ruby's blocks have the limitation that you only get one per function (at least without going through some gyrations)?
Feel free to address any technical criticisms of what I posted.
The syntax for getting working closures in Python is most certainly not easy to read; you have to close over an aggregate and then write to an element of that aggregate. Don't get me started on how useless lambda is in Python.
The original poster didn't mean "use" as in "using the gpl'd software as a user" but "using the code" in the sense of taking portions of code form a gpl program and "use" (or copy) it in derivative work.
The GPL allows that too. It's only redistribution that requires the release of source code, modified or not, under the same terms.
... (that is, it's NOT mail with "a high level of spamminess") but is from an unknown sender.
That was not at all clear to me from your previous posts (I understood "last step in the filter" to mean the complete opposite), but in that case your approach sounds much more reasonable. I apologize for the misunderstanding.
Your choices are either throwing away legitimate mail without notifying the sender, or notifying some senders inappropriately. Neither of these are "OK".
I do believe that's a false dilemma, but if this mail reaches the last part of your filter chain, why is it someone else's responsibility to filter your mail for you, especially if that person is only involved because your filter decided to believe that a message with a high level of spamminess really did come from him or her? To my knowledge, no SMTP-related RFC has ever promised perfectly reliable delivery. What good is it to hold the entire system up to that expectation when the consequences actually decrease the reliability of the system?
... I pointed out that this was the last step in the filter chain, and that nobody ever gets more than one bounce? Anyone who's getting mail from me is already getting a hundred times as much from initial conversation bounces.
What kind of a justification is "People are already getting spam, so the miniscule amount by which I voluntarily and knowingly increase that level spam isn't so bad after all"? The death of e-mail is indeed death by a thousand cuts. There's no need to make it worse.
This is a threat to open source, since Novell may just add duhbious terms to the drivers' licenses. Or purpotedly add MS code to them so they are the only ones able to legally distribute them.
I won't speak to Moonlight, but you'll have to do a lot of work to convince anyone who knows Greg K-H that he'd put up with that in the kernel.
Is there a clause in the GPLv3 that makes the "or later" mandatory?
No, nor the GPL v2. The FSF recommended including that clause, but it's silly to release your code under a license you haven't seen.
Still, I wonder about the legality of enforcing a license that doesn't exist or didn't exist when you first got the source.
That's obviously impossible. How could anyone agree to a license that doesn't exist? Anyone releasing software with the "or later" clause believes sufficiently that any new version of the GPL released by the FSF will be in the same spirit as the existing versions. More power to them. That doesn't mean that if they distribute software to you right now that you have to agree to the GPL v4. (Nor do you have to agree to the license to use the software, per the wording of the license itself.)
Of course. I'm sure you could implement memory pools in assembly language, but I'm not sure that the natural and idiomatic way to write assembly code lends itself to the best representation of certain algorithms and optimizations. (It is interesting to consider that both assembly and very high level languages, at least 3GLs, both support eval natively.)
You can, in fact, write any piece of software in assembler. The obvious advantage is that it would be much smaller and faster than any other solution.
Really? A program written in assembly is always faster and smaller than one written in a higher-level language? I can think of a couple of algorithmic improvements that aren't readily feasible in assembly language, especially related to memory management.
I tested out parrot and PIR is even slower than [Perl 5]. OK so it's a work in progress, but on some coin counting recursion benchmark the latest parrot appears to be much slower than one some versions back (both being slower than [Perl 5] - which itself is slower than python).
I'd like to see those benchmarks, if you have time. My e-mail address should be obvious from my URL. Thanks!
The purpose of the clause in Apache 2 is to create a patent pool. We all hang together, or we shall all hang separately. If the best reason to collect a batch of patents is as a deterrent (or to make cross-licensing more appealing), and a lot of companies believe that it is, A2 does the same thing in a F/OSS fashion by making it painful to file a patent suit related to patents licensed for use in the product.
My complaint with Microsoft's license is that if I were to contribute code to a project licensed under the MS-PL and someone were to file suit against me for patent infringement, I'd have no contributory protection from any other patents that actual patent holders had licensed by way of their contribution to the project. I appreciate that the MS-PL contains a patent grant, but it doesn't do much to build a wall around contributors related to patents other than that. The playing field is lopsided in favor of large patent collections, where they already have plenty of patent-related deterrents.
Of course. Yet you cannot use empiricism to determine whether a historical event happened. That doesn't mean there's anything wrong with empiricism. It merely means that empiricism is inappropriate for answering that question.
That was precisely my point.
Is the assertion "Life arose from non-life around three billion years ago on the prehistoric earth" falsifiable without resorting to some form of the anthropic principle?
At a very basic level, your monitor produces colors with an additive scheme (where the base color is black and you add light to produce colors) and print uses a subtractive scheme (where the base color is white and you add colors to prevent reflection of various other colors). There are colors which one gamut can produce that the other cannot.
Do you use either one regularly on Mac OS X?
This will only work until spammers figure out how to spoof the From address.
I certainly hope that people evaluate my comments for technical accuracy, but I do appreciate your elaboration and will try to draw clearer lines between fact and opinion. Thank you.
Pianos are much more difficult to tune than guitars. Plus you need really long arms to strum entire chords!
There's already Mono, of course, but from the article:
The practical utility of this code for F/OSS efforts is, at best, zero.
English has a perfectly good word which means "distribute". That word is "distribute". Using the word "use" when you mean "distribute" is unnecessary and confusing. There are plenty of people on Slashdot who apparently believe that merely using GPLd code means that you have to make modifications available to the entire world. It would be nice to reduce that confusion by being precise in language.
(Yes, I'm aware of the irony of conflating the words "free" and "libre".)
Shall I stifle my opinions because I happen to have some expertise in a subject area? Would you feel better if I had also said that Perl's support for tailcall optimization is less than ideal because it requires syntax and that syntax is ugly and that Ruby's blocks have the limitation that you only get one per function (at least without going through some gyrations)?
Feel free to address any technical criticisms of what I posted.
The syntax for getting working closures in Python is most certainly not easy to read; you have to close over an aggregate and then write to an element of that aggregate. Don't get me started on how useless lambda is in Python.
Citations, please.
The GPL allows that too. It's only redistribution that requires the release of source code, modified or not, under the same terms.
The GPL only covers redistribution, not use.
That was not at all clear to me from your previous posts (I understood "last step in the filter" to mean the complete opposite), but in that case your approach sounds much more reasonable. I apologize for the misunderstanding.
I do believe that's a false dilemma, but if this mail reaches the last part of your filter chain, why is it someone else's responsibility to filter your mail for you, especially if that person is only involved because your filter decided to believe that a message with a high level of spamminess really did come from him or her? To my knowledge, no SMTP-related RFC has ever promised perfectly reliable delivery. What good is it to hold the entire system up to that expectation when the consequences actually decrease the reliability of the system?
What kind of a justification is "People are already getting spam, so the miniscule amount by which I voluntarily and knowingly increase that level spam isn't so bad after all"? The death of e-mail is indeed death by a thousand cuts. There's no need to make it worse.
That doesn't make it okay, especially because you know you're spamming innocent addresses.
I won't speak to Moonlight, but you'll have to do a lot of work to convince anyone who knows Greg K-H that he'd put up with that in the kernel.
People who use Linux don't pay for hardware? TomTom make GPS navigation devices.
No, nor the GPL v2. The FSF recommended including that clause, but it's silly to release your code under a license you haven't seen.
That's obviously impossible. How could anyone agree to a license that doesn't exist? Anyone releasing software with the "or later" clause believes sufficiently that any new version of the GPL released by the FSF will be in the same spirit as the existing versions. More power to them. That doesn't mean that if they distribute software to you right now that you have to agree to the GPL v4. (Nor do you have to agree to the license to use the software, per the wording of the license itself.)
Of course. I'm sure you could implement memory pools in assembly language, but I'm not sure that the natural and idiomatic way to write assembly code lends itself to the best representation of certain algorithms and optimizations. (It is interesting to consider that both assembly and very high level languages, at least 3GLs, both support eval natively.)
Really? A program written in assembly is always faster and smaller than one written in a higher-level language? I can think of a couple of algorithmic improvements that aren't readily feasible in assembly language, especially related to memory management.
I'd like to see those benchmarks, if you have time. My e-mail address should be obvious from my URL. Thanks!
The purpose of the clause in Apache 2 is to create a patent pool. We all hang together, or we shall all hang separately. If the best reason to collect a batch of patents is as a deterrent (or to make cross-licensing more appealing), and a lot of companies believe that it is, A2 does the same thing in a F/OSS fashion by making it painful to file a patent suit related to patents licensed for use in the product.
My complaint with Microsoft's license is that if I were to contribute code to a project licensed under the MS-PL and someone were to file suit against me for patent infringement, I'd have no contributory protection from any other patents that actual patent holders had licensed by way of their contribution to the project. I appreciate that the MS-PL contains a patent grant, but it doesn't do much to build a wall around contributors related to patents other than that. The playing field is lopsided in favor of large patent collections, where they already have plenty of patent-related deterrents.