The last word from the US Supreme Court is that software is not patentable. For software patents to be truly defeated, all you need is for a case to make it to the supreme court so they can smack down the lower-court Alappat decision that contradicted them. Unfortunately, they're asked to hear 10x as many cases as they can actually hear, so we'll see.
Read the Diamond v. Diehr decision yourself if you don't believe me.
If you validate and/or escape your inputs, there's no security issue with having SQL right there in your web front end. The problem is that most languages people use for web front ends do not make it convenient to do this. See my map demo for a one-page SQL app with a view source link. The same idea that makes it secure can make a large app secure.
Where's the post calling this a big conspiracy? A research firm finding results that its sponsor will like is not a big conspiracy. Where's the article where nobody criticizes an IBM or RedHat study as biased?
Thus, if a computer program is used to interact with a system or as part of a process, ie. electronically controlled sawmill machinery, then the software could be patented. Which raises the question on how the LZW algorithm was granted a patent in Canada (patent 1223965) as it clearly is nothing more than an algorithm.
That's not what it says. A process that includes software may be patented, if and only if the system as a whole is patentable. The software itself is not patentable.
This is the same as what the US Supreme Court said in Diamond v. Diehr. The opinion reaffirmed previous rulings that held software not patentable, and had a whole section devoted to pointing out that people couldn't make software patentable by re-drafting their application to make it look like a system. Many people have mis-read Diamond v. Diehr the same way you mis-read the six points you listed.
The same question you asked about LZW could be asked about all American software patents. The answer is USPTO policy changes followed by a lower-court ruling that contradicted Diamond v. Diehr.
The US Supreme Court has clearly ruled software unpatentable. If the USPTO won't listen to the Supreme Court, what makes you think they'll listen to you?
The reason people did not bother with software patents in the 1970s was that the US patent office would not grant them, because they were illegal. They are still illegal, but now they are being granted left and right.
How long do you think its going to be before we start seeing patents on basic mechanical devices?
It could happen any time. The US Supreme Court ruling of Diamond v. Diehr reiterated previous rulings that software is not patentable material. However, it asserted that a non-patentable element of a patentable system did not make the entire system unpatentable.
That ruling got misinterpreted as making software patentable. The exact same misinterpretation could be used to say that since having a lever in a system does not make the system unpatentable, then a lever must be patentable.
You know someone whose parents named him or her Grammar Nazi? If not, you should have said the Grammar Nazi if referring to someone in particular, otherwise any Grammar Nazi.
P.S. I might question the capitalization on Grammar Nazi, but I don't want to pick nits.
They talk about how expensive it is to create an exception, and caution against it. Beware undue aversion to exceptions! For example, java.io.File.getLastModified(), if called on a file that doesn't exist, will return 0. An exception really ought to be thrown, but who's going to change the API now?
People emphasize performance too much. Look how successful PHP has been despite its slowness. Deal with functionality first, and only worry about performance if and when it's a problem.
The other nice thing about coalesce() is that it takes an arbitrary number of arguments, and returns the first non-null, so you can do coalesce(a, b, c, d) rather than isnull(a, isnull(b, isnull(c, d))).
If you read Oracle's docs, they'll tell you to use NVL(). If you read MSFT's docs, they'll tell you to use ISNULL(). Both databases support the standard SQL function COALESCE() that does the same thing and is portable. There are other similar examples. Only use the docs that came with your database if your database is PostgreSQL. Except for backslashes within string literals, they pretty much respect the standard.
Password-protected directories wouldn't need to be in robots.txt. Using robots.txt + security by obscurity is for things like family photos, where I don't want to maintain usernames and passwords for my entire extended family, but it isn't absolutely critical that no unauthorized person ever see them. I doubt I could trust my entire extended family to keep passwords secure anyway.
Yeah, cheap shared hosting is largely insecure. I wonder how tough it would be to set up shared hosting using squid as an http accelerator, and let users run web servers under their own UID on different ports, while squid forwards from port 80.
Things with software patents will get better in time as more implementations are publicly documented. Until then, you should be yelling at the courts to change the current system, because they are the ones that caused the current mess.
I disagree. SCOTUS clearly spelled out that software was not patentable in a handful of cases, which they reaffirmed in the 1981 Diamond v. Diehr ruling. It's the USPTO that then started granting software patents left and right because they couldn't be bothered to actually read the court decision. The Federal Circuit's In re. Allapat decision did contribute significantly to the problem, but only after the USPTO for years created an environment that would encourage judges to think that way. You can't really blame SCOTUS for not taking any cases since then; they're asked to hear about 10x as many cases as they can take, and many issues harm society more than software patents do. Until SCOTUS gets some spare time, onus is on the legislature to clarify things, and they work slowly too.
They should mention that disallowing a URI in robots.txt tells crackers which URIs on your site have sensitive information. What I do is create a top-level/unpub/ URI, and everything sensitive goes underneath it with hard-to-guess names. In robots.txt I disallow/unpub only.
The only reason C can compile and then just run with "operating system libraries" is that your operating system always has C libraries. If your OS always came with PLT Scheme libraries by default, you could just distribute PLT executables, etc.
Ok, now that you're getting more concrete it sounds like you do understand how all this works. However, I don't think you've proven that a Bayesian filter can't keep up with spammers. In Better Bayesian Filtering, Paul Graham talks about degeneration, where if a token isn't found in the corpus, you fall back on a simpler version of it, e.g. fewer exclamation points. Add a couple simple degeneration techniques and you'll catch PcarEcatNcabIcanS and pppppeeeeennnniiisssxyqhh.
Basically, there are two directions a spammer can go to bypass the Bayesian filter's favorite keywords. Either they break words up so that the filter sees shorter tokens, or they do something else that makes the filter see longer tokens. Shorter non-word tokens will just end up being learned as spam markers. Longer tokens can be handled via n-tuplets plus a few degeneration techniques. I think the number of different ways you can obfuscate words but still keep them recognizable to humans is limited.
Since neither you nor the moderators who modded you up could be bothered to actually read Paul Graham's article, I'll quote it for you here:
In a sense, though, my filters do themselves embody a kind of whitelist (and blacklist) because they are based on entire messages, including the headers. So to that extent they "know" the email addresses of trusted senders and even the routes by which mail gets from them to me. And they know the same about spam, including the server names, mailer versions, and protocols.
Along with the rest of the world, after I read Paul Graham's Plan for Spam, I implemented it myself
Is this some subtle sarcasm? Obviously a lot of people haven't read, or at least understood, Paul's essay. E.g. you're replying in a thread that started with someone saying "use IP addresses", who didn't read the part of the essay saying how the info in the headers is often as damning as the body of the message. You're replying directly to a posting that doesn't understand how fragmented words make the Bayesian filter's work easier, until you get down to one-letter fragments.
Anyway, your n-tuplets post is interesting. That technique would defeat the "No Whitespace No Cry" technique, which is the only technique in the article that could get past a Bayesian filter, and then only on the condition that it randomize the separators a lot. It would be good for a Bayesian filter that finds a lot of very long tokens to revert to the n-tuplets method.
A Bayesian filter would learn that "iaga" is a sign of spam. Any spam-hiding technique that fragments words is going to run into this same problem. Basically they'd have to resort to one or two-letter fragments, making their messages even easier to distinguish from legitimate mail.
Slashdot Mirror
The last word from the US Supreme Court is that software is not patentable. For software patents to be truly defeated, all you need is for a case to make it to the supreme court so they can smack down the lower-court Alappat decision that contradicted them. Unfortunately, they're asked to hear 10x as many cases as they can actually hear, so we'll see.
Read the Diamond v. Diehr decision yourself if you don't believe me.
If you validate and/or escape your inputs, there's no security issue with having SQL right there in your web front end. The problem is that most languages people use for web front ends do not make it convenient to do this. See my map demo for a one-page SQL app with a view source link. The same idea that makes it secure can make a large app secure.
Bias. Big conspiracy. There's a big difference.
Where's the post calling this a big conspiracy? A research firm finding results that its sponsor will like is not a big conspiracy. Where's the article where nobody criticizes an IBM or RedHat study as biased?
Insightful my foot. Imaginative, maybe.
That's not what it says. A process that includes software may be patented, if and only if the system as a whole is patentable. The software itself is not patentable.
This is the same as what the US Supreme Court said in Diamond v. Diehr. The opinion reaffirmed previous rulings that held software not patentable, and had a whole section devoted to pointing out that people couldn't make software patentable by re-drafting their application to make it look like a system. Many people have mis-read Diamond v. Diehr the same way you mis-read the six points you listed.
The same question you asked about LZW could be asked about all American software patents. The answer is USPTO policy changes followed by a lower-court ruling that contradicted Diamond v. Diehr.
The US Supreme Court has clearly ruled software unpatentable. If the USPTO won't listen to the Supreme Court, what makes you think they'll listen to you?
The reason people did not bother with software patents in the 1970s was that the US patent office would not grant them, because they were illegal. They are still illegal, but now they are being granted left and right.
It could happen any time. The US Supreme Court ruling of Diamond v. Diehr reiterated previous rulings that software is not patentable material. However, it asserted that a non-patentable element of a patentable system did not make the entire system unpatentable.
That ruling got misinterpreted as making software patentable. The exact same misinterpretation could be used to say that since having a lever in a system does not make the system unpatentable, then a lever must be patentable.
Not all languages have some sort of include(). BRL has (paste ...) which does not pollute any namespace.
You know someone whose parents named him or her Grammar Nazi? If not, you should have said the Grammar Nazi if referring to someone in particular, otherwise any Grammar Nazi.
P.S. I might question the capitalization on Grammar Nazi, but I don't want to pick nits.
If you own a legal copy of a program, you don't need a license to run or use it, according to US copyright law.
I am not a lawyer. If I were, I'd be able to tell you whether extortion or fraud was the right word for what SCO is doing.
They talk about how expensive it is to create an exception, and caution against it. Beware undue aversion to exceptions! For example, java.io.File.getLastModified(), if called on a file that doesn't exist, will return 0. An exception really ought to be thrown, but who's going to change the API now?
People emphasize performance too much. Look how successful PHP has been despite its slowness. Deal with functionality first, and only worry about performance if and when it's a problem.
The other nice thing about coalesce() is that it takes an arbitrary number of arguments, and returns the first non-null, so you can do coalesce(a, b, c, d) rather than isnull(a, isnull(b, isnull(c, d))).
How about we respect the opinions of the US Supreme Court for a change, and not allow software patents at all?
If you read Oracle's docs, they'll tell you to use NVL(). If you read MSFT's docs, they'll tell you to use ISNULL(). Both databases support the standard SQL function COALESCE() that does the same thing and is portable. There are other similar examples. Only use the docs that came with your database if your database is PostgreSQL. Except for backslashes within string literals, they pretty much respect the standard.
Password-protected directories wouldn't need to be in robots.txt. Using robots.txt + security by obscurity is for things like family photos, where I don't want to maintain usernames and passwords for my entire extended family, but it isn't absolutely critical that no unauthorized person ever see them. I doubt I could trust my entire extended family to keep passwords secure anyway.
Yeah, cheap shared hosting is largely insecure. I wonder how tough it would be to set up shared hosting using squid as an http accelerator, and let users run web servers under their own UID on different ports, while squid forwards from port 80.
They should mention that disallowing a URI in robots.txt tells crackers which URIs on your site have sensitive information. What I do is create a top-level /unpub/ URI, and everything sensitive goes underneath it with hard-to-guess names. In robots.txt I disallow /unpub only.
The only reason C can compile and then just run with "operating system libraries" is that your operating system always has C libraries. If your OS always came with PLT Scheme libraries by default, you could just distribute PLT executables, etc.
Basically, there are two directions a spammer can go to bypass the Bayesian filter's favorite keywords. Either they break words up so that the filter sees shorter tokens, or they do something else that makes the filter see longer tokens. Shorter non-word tokens will just end up being learned as spam markers. Longer tokens can be handled via n-tuplets plus a few degeneration techniques. I think the number of different ways you can obfuscate words but still keep them recognizable to humans is limited.
Is this some subtle sarcasm? Obviously a lot of people haven't read, or at least understood, Paul's essay. E.g. you're replying in a thread that started with someone saying "use IP addresses", who didn't read the part of the essay saying how the info in the headers is often as damning as the body of the message. You're replying directly to a posting that doesn't understand how fragmented words make the Bayesian filter's work easier, until you get down to one-letter fragments.
Anyway, your n-tuplets post is interesting. That technique would defeat the "No Whitespace No Cry" technique, which is the only technique in the article that could get past a Bayesian filter, and then only on the condition that it randomize the separators a lot. It would be good for a Bayesian filter that finds a lot of very long tokens to revert to the n-tuplets method.
A Bayesian filter would learn that "iaga" is a sign of spam. Any spam-hiding technique that fragments words is going to run into this same problem. Basically they'd have to resort to one or two-letter fragments, making their messages even easier to distinguish from legitimate mail.
Hate to nit-pick words, but I think you should pay attention to the difference between "criminal" and "suspect".