"And how do they explain to their viewers that they can't see one of the most popular events of the year, because the affiliates are on strike? How much sympathy do you think they'll get?"
They don't want or require your sympathy. They would take a financial hit, true, but if they percieve their profits to be in jeopardy (e.g. because the studio might start treading "iPod" as a syndication market on-par with any of them), then it might be worth it.
Viewers are locked in, so their opinion is moot, and always has been.
Training on everything is probably a mistake. Catching all of the edge conditions where that fails is going to be a very laborious task. Do all of your users do the same, or do you force their auto-learning off and have them use your bayes tokens? That has its own problems (you're not training on their mail), but at least would not leave an inattentive user in the horrible situation where they are constantly training incorrectly. That quickly leads to a broken classifier.
"It has happened to me just a few times in ~15 years that I can't kill -9 a process in any Unix"
The theory:
Any process in an uninteruptable system call is effectively unkillable until it returns from said call.
The practice:
Mount an NFS filesystem with the following parameters: "timeo=30,retrans=1,soft". Then create a file, run a tail -f on that file, and shut off the NFS fileserver (or just add a local firewall rule to block traffic from the server).
The tail -f process will hang for 30 seconds and then exit with an error. No amount of SIGKILLs will cause it to exit previous to that 30 seconds.
On a side note: When I reboot, I do so to clear state (e.g. kernel upgrades). I don't want a state-preserving NVRAM preventing that. This seems like a standardized suspend rather than any kind of boot-time accelerator to me. It also sounds like a really juicy target for viruses and worms, since it allows such a program to preserve its state across reboots, even after it is "cleaned" from the rest of the system.
"Perl is better than most people give it credit for. It just lacks a S&M (Sales and Marketing) team."
Perl lacks far more than that:
Formal parameter lists
Types
A stable interpreter-free code generation capability
Any kind of formal object declaration
Thankfully, these are all features which Perl 6 provides in spades. If you wish to get involved in Perl 6 development, download and compile pugs today!
Most people won't understand why you put these items under "revolutionary", and in some cases, I don't either, but given as how I'm finally getting back in the saddle and working on S29 again, I suppose I should at least be able to clarify these:
an improved object system (revolutionary in its approach)
Well, this one is pretty much accurate. The combination of Java-style interfaces, C++-style MI, and Smalltalk/Ruby-style mix-ins in unified and elegant "Role" system is certainly nothing like what I've come across before.
Register-based VM
Foul. This is a Parrot feature, and has no real preference for Perl 6 in theory, and very little preference in practice.
junctions
Junctions are rarely used, but I'm not sure I'd call them revolutionary. For those who don't know, junctions are unresolved expressions which can have many values at once. The english equivalent would be "any one of Mary, Tom, or Fred," or, "all of the colors; red, blue, and green." In Perl 6, you would say "$Mary | $Tom | $Fred" or "$red & $blue & $green". These are first-class values which can be passed around to functions, added to lists and hashes and evaluated in logical conditions.
roles
Roles fall under the object system, and are most of what makes it revolutionary (though the delegation management is pretty interesting stuff too).
rules and grammars
Let's be clear: Rules and Grammars aren't terribly interesting on their own. The fact that they are even more deeply integrated into the language than regexps were in Perl 5 is radical to say the least. There will be a build-in Grammar called something like Perl6::Parser, and yes, you can alter it at compile-time or run-time. This is not a unique feature, but it's certainly rare outside of the LISP world.
continuations and coroutines (not widespread)
Not widespread outside of the LISP world, but LISP dialects as often have such features as not.
optional typing and type inferencing (other languages typically don't make this optional)
I'd take that one off the list. First off, Perl 6 typing isn't optional, you just get a default type (Scalar). Such typing games are not unheard of, especially in the LISP world.
interoperability with other languages including Perl 5 (because of how easy it is)
This is no more a Perl 6 feature than it is a Perl 5 feature. In fact, right now Perl 5 (Ponie) is much further along on this front. In reality, this is a Parrot feature, and all languages benefit.
hyperoperators
Many lisp variants have similar constructs, but I'm not aware of any procedural equivalents. To those unaware, this is where a single operator applies to a list. For example, "$sum = [+] @list;" That generalizes to any binary operator.
unification of blocks and closures
This is, of course, a baby-step on the way to S-expressions. Perl can hardly claim to be revolutionary here. Again, for those unaware, a closure is a code construct that captures its lexical scope and freezes it in time. In Perl 6, various grammatical hooks allow you to treat any block as a closure object, which is tremendously powerful.
Overall, Perl 6 is probably the closest that any procedural language will come for a long time to the power of S-expression-based functional languages. It also retains and enhances the power of the current state of the art in dynamic procedural languages such as Perl 5, Python, Ruby, etc. Perl 6 will certainly be a force to contend with.
enabling a few knobs that are generally useful (though I've had too many false positives with RCVD_IN_DSBL).
The only thing I would critisize is shutting off auto-learn. If you want to be conservative, just lower the ham threshold and raise the spam threshold a bit. I tried to manually train for a while, and what I found was that I was actually lying to SA. auto-learn means that a view of your mail gets sampled that has not been tainted by your perceptions. This generally vastly improves the quality of the data.
Beyond that, I would just suggest that you re-consider firing up a new copy of SA for every message. spamc/spamd work quite well, and vastly reduce the overhead of spam checking.
"The network affiliates can go suck lemons if they think people should adhere to an old model for the sake of tradition."
That's one option, true... another option would be to band together and announce that they will collectively refuse to show the Super Bowl this year. Your average sporting event gets so much higher ratings than a drama or comedy that they are literally measured on different scales. The Super Bowl is another order of magnitude.
If 25% of the broadcast markets refused to show the Super Bowl, they would cost the network so much in revenue that the network would do just about anything to prevent it. If the broadcasters cannot be calmed and persuaded that there is a silver lining in the Apple deal for them, the studios will be put into a spot where they would do just about anything including dumping Apple.
If you're going to go all free-market-dynamics on me, I can do the same right back.
No, I'm sorry. You said what I quoted, and I took it with a fair amount of context... If you intended something different, then that's fine.
I would agree that integration issues are what they are, and if you had clearly said "performance of a FreeBSD port of Reiser might not be what you would expect, and would have to be carefully tested," then I would have agreed.
I'm a long-time proponent of and rare contributor to SpamAssassin, and I'll continue to be, but fighting spam is much like fighting disease: you have to diversify your defenses. DSPAM is a nice package, and is very well designed. I've spoken to the author in the past, and he has an excellent understanding of the complexities of the issue (as opposed to the legions of people who seem to think that spam filtering should be easy, given the right algorithm).
As far as I'm concerned there are two tools for spam filtering: DSPAM and SpamAssassin. Try them both. See what fits your needs. My impression is that SpamAssassin provides more knobs and buttons and is more easily extended by the casual user, but DSPAM can be lighter weight. Both are highly accurate, with very low false positive rates.
"It has to be tested for compatibility, quality and performance. You can't be losing data, and if it doesn't offer a performance benefit over UFS or UFS2 then there's very little point in porting it."
Clearly you don't know about Reiser (no offense, it's just that that question shows a stark lack of understanding with regards to why Reiser is interesting in the first place).
Reiser solves one of the oldest problems facing the old Unix-style filesystem: the adoption of btree-order performance directory lookups (using Reiser's "dancing trees") without significant loss in other areas of filesystem performance, e.g. directory entry creation and deletion, etc. This is something which was long thought impossible.
This lead to further development, since the major reason to avoid creating thousands of temporary files has always been directory lookup times. So, now the question is: how far do you go with files? Reiser 4 answers that question by adding significant semantics to files which were not practical with slower filesystems (again, keep in mind that when I say "slower" I refer to the performance bottleneck surrounding large directories primarily).
The problem with Reiser is that it is Reiser, and none of the exisiting filesystems can match its performance in these areas. That means that if you write an application that relies on Reiser's performance, it really RELIES on Reiser, and cannot perform well under normal filesystems without significant engineering (e.g. writing special-case code for Reiser and non-Reiser filesystems). In some cases (e.g. databases) this might be worthwhile, but in the case of more mundane applications, having filesystem-specific code is not always viable.
"I wasn't aware of Card's essay on The Hypocrites of Homosexuality."
It's shocking just how many people are not. I responded pretty much just as you did to a mailing list when someone took a stand against Card, and they pointed me to the article... I was stunned.
"Regarding the Superman Essay, no, I didn't know it came out in '87. Ok, my whoops; but at any rate, it's only been in the last year or two that I've seen it used in these OSC arguments."
It's not a perfect essay, and I think it tends to fail the test of Occam's Razor on many points, but it's good. Sadly, there aren't any sources of it online that I know of. You're likely thinking of the guy (forget his name) who wrote ABOUT it, and about Card. He also seems to have an axe to grind, but also makes some OK points here or there.
"Your quote from the other article (presuming it's in context, which I have no reason to doubt)"
You can just search for the title on Google. There are several copies available from Mormon sources as well as in the GLBT community. However, I applaud your hesitency to simply buy into what some random person on Slashdot asserts. I wish more people questioned sources without just flaming, as you have.
"You also wanted me to clarify about my little "science has proven" comment. I was actually making a little dig at those people who claim that homosexuality can be somewhat demonstrated in a genetic sense, so therefore it is socially acceptable."
I think I pretty much got that, but wanted to confirm. Just one note: the argument as I've seen it stated is a bit more narrow:
Christians and some other religions assert that homosexuality is a sin. However, we are discovering (and the evidence IS getting pretty solid) that homosexuality is an attribute of a person's genetic makeup (at least in part) Thus, homosexuality is one of God's creations, and cannot be a sin.
Card's counter to this argument is:
God also created the temptations for many other types of sin, but that does not make the commission of those sins right. In essence, he is arguing that homosexuality is a test of one's ability to resist sin, and those who are ACTIVELY homosexual (as opposed to simply being pre-disposed) are thus sinners.
My counter to that is:
That's all very nice, but I'm neither a Mormon nor a Christian of any sort, and I couldn't care less. Keep your laws off my privates.
Aside from Card's rebuttal, another angle is:
Ok, well if it's genetic, then it's a genetic disease just like Down's Syndrom, and we should seek to cure it at a genetic level.
Of course, this runs aground immediately, especially in light of Kinsey's research which shows that there is a clear continuum of sexual orientation, and that extremes on either end are no more the norm than any single point on the line. It's not very workable to label something so prominent in the human species as a "disease", and seeking to "cure" homosexuality isn't as simple a prospect as you might think.
It's also not clear that you can reasonably refer to a social stigma as a "disease". There have certainly been cultures where being homosexual was not a disadvantage at all.
"Have I made any good arguments yet? No, I guess I've lost some ground."
Nope, I think I understand whered you're coming from.
"I will argue your point #4. I agree that it isn't unreasonable to change your opinion of something as you age, or as you encounter good arguments and new information. This is natural, and we hope that people can do it. What isn't logical is to assert that those who still hold their old beliefs (e.g., those who still like OSC after all these years), only do so for the sake of tradition in spite of what "facts" may have become available. If I believed that OSC was a raving sociopath, it might be more difficult for me to enjoy his work in light of that."
I don't think I disagree with any of that.
"Alas, my original post was sadly under-researched,"
I think you misunderstood my post. Please re-read it, and note the lack of the phrase, "conclusive evidence" as applied to DNA results.
What DNA testing tells you is several things: 1) is it a species that could reasonably have ended up in Australia; 2) is it a hybrid species (likely if the lineage is based on random releases from zoos, but not as likely if, say, from a poacher in South America); 3) it allows future samples to be compared, giving credibility if they are related; 4) if there are genetic records of cats that might have been in zoos, then that would be great, but unlikely.
Re:What I want to know: Can I paint circles in it?
on
First Look at GIMP 2.4
·
· Score: 1
No, not control. If you want concentric circles, you have to click on the center point, sweep to where you want the edge, then hold control and shift at the same time, release the mouse button. Simply holding control and sweeping will get you an ellipse (which might happen to be a circle if you get it just right) that will subtract from your current selection. That's right, for the circle tool control has two completely different and conflicting meanings, and you can get one both or the other depending on the sequence of keydown-buttondown-buttonrelease-keyrelease. Anyone who defends the Gimp UI as well-designed has clearly never used a well-designed UI. Mind you, I have developed for, and contiue to use the Gimp. I just have no illusions about the usability of the UI.
Bottom line (literally, the bottom line of the article):
"We don't dispute that there is a possibility they (big cats) are out there, but we are yet to see a photograph that proves it categorically," he said.
Mr Roswell said the DNA would ultimately determine the breed of the cat.
So it seems waiting for the results of the DNA test might be enlightening, but it's not unreasonable to assume that there are big cats in Australia.
"I have a p3 450mhz box running Tomcat/MySql. It serves my local applications fast enough. The server can render the page much more quickly than my browser (on a p4 1.5ghz box) can render it."
I just want to note that this is a horrible metric. What you care about is not that a single browser can be fed by your program, but how well it performs under the load of dozens of simultaneous page generations.
Single page generation metrics lead to very dissapointing real-world results.
"This sort of subjectivism regarding OSC became quite stylish about the time that a certain interview came out"
That is to say, around the time that he let loose with his The Hypocrites of Homosexuality rant which included, among other choice bits,
"Laws against homosexual behavior should remain on the books, not to be indiscriminately enforced against anyone who happens to be caught violating them, but to be used when necessary to send a clear message that those who flagrantly violate society's regulation of sexual behavior cannot be permitted to remain as acceptable, equal citizens within that society."
Yes, that's about the time that I started re-reading Card's work with an eye to the views that he was attempting to push into the mainstream. It's when I became aware of the comparisons of Ender's Game and Xenophile with this history of the Third Reich (which, I have to say, are weaker than simply saying that Card is detatched from any sense of right and wrong, and much more interested in relative "correctness").
"People who were once quite passive about Card, or even complimentary, suddenly became his worst critics. I know some who loved Ender's Game, and then found out that Card is Mormon.
I found out that Card was a mormon just after reading Ender's game, and just before I picked up The Tales of Alvin Maker, book one. I don't think it affected my thoughts about him. I grew up in a fundamentalist Christian / athiest family which allowed me to develop a healthy respect for both the religious and non-religious points of view, and I've since come to respect many religions. Mormonism isn't really one of those, but I give it the benefit of the doubt on most topics. Card is a dangerous sociopath, as best I can tell, and that has nothing to do with his choice in faiths.
"Several years ago, Slashdot's conversations about OSC were generally quite positive. Now you can guarantee that any OSC discussion will contain the following elements:
"1) Ender's Game is a Nazi-loving revenge saga. This is a recent argument based on a particular review from an OSC critic. Disciples of this "received" idea now push it as gospel truth."
Recent?! You do know that the original essay, "Ender's Game: Sympathy for the Superman" was published in 1987, don't you? You're also widely misrepresenting the point of the essay, but I presume you know that.
"2) OSC is a homophobe because he disagrees with the gay lifestyle and with gay marriage, even after science has proven that these things are perfectly normal."
Clarify. Do you mean that science has proven that homophobia is perfectly normal or that homosexuality is? Either way, Card is not considered a homophobe because he doesn't think same-sex-sex is a good idea. He's considered a homophobe because he passionately advocates the supression of homosexuality at a legal level.
"3) I hate OSC, but I still think his books are pretty good."
I can't say that I like Hemingway as a person either. Not to say that Card is any Hemingway in terms of writing, of course, but the hyperbolic example makes the point clearly, I think.
"4) I used to love Ender's Game, but now that I'm older and smarter, I find that I hate it because it's actually quite shallow. People who still like it are nostalgics."
And this is unreasonable, why?
Most of the rest of your points repeat the above points, so I'll just leave it at that.
POSIX, VESA and even ttys are all examples of specificatons that sought to unify existing practice. The practice came first, then the theory. If you want an example that goes the other way, you would have to look to something like IP, which was created as a specificaton along with the first implementations.
Linus is correct, though. Specs are rarely useful breasts up-front. Standardization of existing practice is often useful, but that's another beast.
That's not a bad system, but suffers from the problem that the passwords are all written down. In some environments this is fine, in some it's tragic. Granted, your scheme still has a secondary key, but given your primary key only (the cheat card), writing code to search every simple word as transformed by the matrix would be easy. Again, your system is better than most.
The real pain comes in when you need to generate passwords for people in advance and, for whatever reason, the "change it the first time you use it" suggestion isn't enforcable (e.g. they're using a system that can do so, but don't use that feature or the system is incapable of that feature).
When this happens, I use http://www.ajs.com/~ajs/mkpasswd. I also use it to generate my own passwords. You can use it to generate passwords that are impossible to crack other than by brute force (mkpasswd -r --strict, which is a random sequence, but filtered for dictionary words); a password that is a simple dictionary word (mkpasswd -p 'W8-12') and just about any level security/memorability trade-off in between. By default (mkpasswd -r -5 --max 12 --non-word) a set of pre-defined password patterns are consulted. After permutation of various parameters, there are about 270 patterns to choose from, each producing a fairly reasonable number of possible passwords, though some patterns are better than others. This is not the strength of the program, however.
The strength of the program lies in the fact that it is capable of parsing a pattern provided by the user which defines their desired password in whatever way they like. One such description might be "x3-5n2WJ4n1" which translates as: "a 3-5 letter pseudo-word (pronouncable random letters), a 2-digit number, a 4 character "join word" (two dictionary words that overlap, forming a 4 character result) and a single digit". If I were to hand out passwords to all of my users of this form, it would be a tragically weak scheme (the search space is very small), but if one of my users chooses this as the scheme for their current password, the result would be quite reasonable.
The program has some experimental features too, like the "--easy" flag which tells the program to find a password that alternates sides of the keyboard for each keystroke (QWERTY only). This currently only works for most of the pattern types, but as an example, it does a great job on mkpasswd -5 -p 'xT9-12' --easy
They already do this. That's the problem with this whole license foolishness is that everyone has somehow gotten the impression that MySQL isn't distributing GPLed code. What they are doing is pointing out the restrictions that the GPL places on users of library code (which the authors of the GPL were so strongly aware of that they created the "Library General Public License" with more permissive terms, but later decided that they didn't like that and re-named it the "Lesser General Public License"). What the FSF now encourages users of the GPL to do is exactly what MySQL is doing: distribute under the GPL.
The only difference is that MySQL adds in some loopholes to get around the GPL where it would hinder open source projects with GPL-incompatible (but still open source) licenses. If those projects use GPL-only (e.g. "downstream") copies of MySQL, then they are fully bound by its terms. If they use the version provided by MySQL, then they are granted these exceptions.
It is worth noting that this "highly restrictive license" that they are using is called the "GPL". What the linked page does is just to set some conditions under which you are free of the GPL's requirements for software that incorporates their code.
Of course, all of the usual provisos stand: the GPL is a license, not an EULA, so you don't have to agree to be bound by its terms to *use* the software (the GPL is quite clear on this).
All of these issues exist for ANY GPL-covered library code, and all MySQL is doing is playing by the rules of the GPL in exactly the way people like RMS have requested (this is why the LGPL is backronymed into meaning "LESSER Gernal Public License").
It should also be pointed out that in a language like, say Perl, where code is distributed as text, not as a pre-compiled representation, the claim of tainting can really only be applied to the AST, and not the text which generated it. Should that AST be used to generate stored code (e.g. compiled machine code or a bytecode representation) then that code might be tainted (that's deep laywer territory, so I'm not qualified to say one way or the other).
You are looking at this incorrectly. The problem is that, given file A, which has hash X, if it is possible to create file B which has hash X in a non-exaustive way, then the hash is weak. Most such techniques work well regardless of file B being a from-scratch random pile of data or a combination of well-formed data plus random data. So, for example, you might have an RPM with 3 files in it. Add a fourth file, and start permuting to find your similar hash.
Now, as you point out, we're not yet to the point that this is trivial with MD5 (it has always been possible, just not practical). So, the only valid thing to do is to move to something more secure as soon as possible so that when we finally do discover a trivial exploit for MD5, we no longer care as much about it. This also helps us by forcing software vendors and projects to re-consider how they use hashing, and to make it easier to modularly replace the hashing functions they use. You will note that all of the oldest such software has already had to do this, and thus the task will be easier for them.
I'm not a lawyer, and I don't know the impact that this will have. I've also been around Slashdot long enough to assume that I don't have all of the facts. However, insofar as I have read to date, I'm thrilled that Google is making this effort, and while I know they're a massive corporation with far more resources than I will ever have — if they make it possible — I will do more research into the topic and consider donating to their legal defense.
Copyright is a sticky issue, and I want to see authorship be a viable profession again (it almost is now, but it's damn hard to break in, and the pay still pretty much sucks unless you are very lucky or able to write in certain niches, e.g. as a "script doctor").
However, I'm also a reader, and I am deeply saddened that we have yet to come up with a viable model for publishing un-crippled novels on the Web. Histories, reference, news and other non-fiction have found their niche, but other than video, fiction seems to be a sticking point. This one area needs to be addressed, and Google may be the irresistable force that can make the publishing industry get creative enough to find the solution.
C'mon... if we can come up with the books we can, we must be creative enough to figure out a way to make re-distributable data have value.
Slashdot Mirror
"And how do they explain to their viewers that they can't see one of the most popular events of the year, because the affiliates are on strike? How much sympathy do you think they'll get?"
They don't want or require your sympathy. They would take a financial hit, true, but if they percieve their profits to be in jeopardy (e.g. because the studio might start treading "iPod" as a syndication market on-par with any of them), then it might be worth it.
Viewers are locked in, so their opinion is moot, and always has been.
Explain "broken". Works great for me.....
Training on everything is probably a mistake. Catching all of the edge conditions where that fails is going to be a very laborious task. Do all of your users do the same, or do you force their auto-learning off and have them use your bayes tokens? That has its own problems (you're not training on their mail), but at least would not leave an inattentive user in the horrible situation where they are constantly training incorrectly. That quickly leads to a broken classifier.
"It has happened to me just a few times in ~15 years that I can't kill -9 a process in any Unix"
The theory:
Any process in an uninteruptable system call is effectively unkillable until it returns from said call.
The practice:
Mount an NFS filesystem with the following parameters: "timeo=30,retrans=1,soft". Then create a file, run a tail -f on that file, and shut off the NFS fileserver (or just add a local firewall rule to block traffic from the server).
The tail -f process will hang for 30 seconds and then exit with an error. No amount of SIGKILLs will cause it to exit previous to that 30 seconds.
On a side note: When I reboot, I do so to clear state (e.g. kernel upgrades). I don't want a state-preserving NVRAM preventing that. This seems like a standardized suspend rather than any kind of boot-time accelerator to me. It also sounds like a really juicy target for viruses and worms, since it allows such a program to preserve its state across reboots, even after it is "cleaned" from the rest of the system.
Perl lacks far more than that:
- Formal parameter lists
- Types
- A stable interpreter-free code generation capability
- Any kind of formal object declaration
Thankfully, these are all features which Perl 6 provides in spades. If you wish to get involved in Perl 6 development, download and compile pugs today!Well, this one is pretty much accurate. The combination of Java-style interfaces, C++-style MI, and Smalltalk/Ruby-style mix-ins in unified and elegant "Role" system is certainly nothing like what I've come across before.
Foul. This is a Parrot feature, and has no real preference for Perl 6 in theory, and very little preference in practice.
Junctions are rarely used, but I'm not sure I'd call them revolutionary. For those who don't know, junctions are unresolved expressions which can have many values at once. The english equivalent would be "any one of Mary, Tom, or Fred," or, "all of the colors; red, blue, and green." In Perl 6, you would say "$Mary | $Tom | $Fred" or "$red & $blue & $green". These are first-class values which can be passed around to functions, added to lists and hashes and evaluated in logical conditions.
Roles fall under the object system, and are most of what makes it revolutionary (though the delegation management is pretty interesting stuff too).
Let's be clear: Rules and Grammars aren't terribly interesting on their own. The fact that they are even more deeply integrated into the language than regexps were in Perl 5 is radical to say the least. There will be a build-in Grammar called something like Perl6::Parser, and yes, you can alter it at compile-time or run-time. This is not a unique feature, but it's certainly rare outside of the LISP world.
Not widespread outside of the LISP world, but LISP dialects as often have such features as not.
I'd take that one off the list. First off, Perl 6 typing isn't optional, you just get a default type (Scalar). Such typing games are not unheard of, especially in the LISP world.
This is no more a Perl 6 feature than it is a Perl 5 feature. In fact, right now Perl 5 (Ponie) is much further along on this front. In reality, this is a Parrot feature, and all languages benefit.
Many lisp variants have similar constructs, but I'm not aware of any procedural equivalents. To those unaware, this is where a single operator applies to a list. For example, "$sum = [+] @list;" That generalizes to any binary operator.
This is, of course, a baby-step on the way to S-expressions. Perl can hardly claim to be revolutionary here. Again, for those unaware, a closure is a code construct that captures its lexical scope and freezes it in time. In Perl 6, various grammatical hooks allow you to treat any block as a closure object, which is tremendously powerful.
Overall, Perl 6 is probably the closest that any procedural language will come for a long time to the power of S-expression-based functional languages. It also retains and enhances the power of the current state of the art in dynamic procedural languages such as Perl 5, Python, Ruby, etc. Perl 6 will certainly be a force to contend with.
- Shutting off auto-learn (mistake, see below)
- Upping BAYES scores (good plan, I do too)
- enabling a few knobs that are generally useful (though I've had too many false positives with RCVD_IN_DSBL).
The only thing I would critisize is shutting off auto-learn. If you want to be conservative, just lower the ham threshold and raise the spam threshold a bit. I tried to manually train for a while, and what I found was that I was actually lying to SA. auto-learn means that a view of your mail gets sampled that has not been tainted by your perceptions. This generally vastly improves the quality of the data.Beyond that, I would just suggest that you re-consider firing up a new copy of SA for every message. spamc/spamd work quite well, and vastly reduce the overhead of spam checking.
"The network affiliates can go suck lemons if they think people should adhere to an old model for the sake of tradition."
That's one option, true... another option would be to band together and announce that they will collectively refuse to show the Super Bowl this year. Your average sporting event gets so much higher ratings than a drama or comedy that they are literally measured on different scales. The Super Bowl is another order of magnitude.
If 25% of the broadcast markets refused to show the Super Bowl, they would cost the network so much in revenue that the network would do just about anything to prevent it. If the broadcasters cannot be calmed and persuaded that there is a silver lining in the Apple deal for them, the studios will be put into a spot where they would do just about anything including dumping Apple.
If you're going to go all free-market-dynamics on me, I can do the same right back.
No, I'm sorry. You said what I quoted, and I took it with a fair amount of context... If you intended something different, then that's fine.
I would agree that integration issues are what they are, and if you had clearly said "performance of a FreeBSD port of Reiser might not be what you would expect, and would have to be carefully tested," then I would have agreed.
Thanks for following up, though.
I'm a long-time proponent of and rare contributor to SpamAssassin, and I'll continue to be, but fighting spam is much like fighting disease: you have to diversify your defenses. DSPAM is a nice package, and is very well designed. I've spoken to the author in the past, and he has an excellent understanding of the complexities of the issue (as opposed to the legions of people who seem to think that spam filtering should be easy, given the right algorithm).
As far as I'm concerned there are two tools for spam filtering: DSPAM and SpamAssassin. Try them both. See what fits your needs. My impression is that SpamAssassin provides more knobs and buttons and is more easily extended by the casual user, but DSPAM can be lighter weight. Both are highly accurate, with very low false positive rates.
"It has to be tested for compatibility, quality and performance. You can't be losing data, and if it doesn't offer a performance benefit over UFS or UFS2 then there's very little point in porting it."
Clearly you don't know about Reiser (no offense, it's just that that question shows a stark lack of understanding with regards to why Reiser is interesting in the first place).
Reiser solves one of the oldest problems facing the old Unix-style filesystem: the adoption of btree-order performance directory lookups (using Reiser's "dancing trees") without significant loss in other areas of filesystem performance, e.g. directory entry creation and deletion, etc. This is something which was long thought impossible.
This lead to further development, since the major reason to avoid creating thousands of temporary files has always been directory lookup times. So, now the question is: how far do you go with files? Reiser 4 answers that question by adding significant semantics to files which were not practical with slower filesystems (again, keep in mind that when I say "slower" I refer to the performance bottleneck surrounding large directories primarily).
The problem with Reiser is that it is Reiser, and none of the exisiting filesystems can match its performance in these areas. That means that if you write an application that relies on Reiser's performance, it really RELIES on Reiser, and cannot perform well under normal filesystems without significant engineering (e.g. writing special-case code for Reiser and non-Reiser filesystems). In some cases (e.g. databases) this might be worthwhile, but in the case of more mundane applications, having filesystem-specific code is not always viable.
For more information, see the Reiser4 site: http://www.namesys.com/v4/v4.html
"I wasn't aware of Card's essay on The Hypocrites of Homosexuality."
;)
It's shocking just how many people are not. I responded pretty much just as you did to a mailing list when someone took a stand against Card, and they pointed me to the article... I was stunned.
"Regarding the Superman Essay, no, I didn't know it came out in '87. Ok, my whoops; but at any rate, it's only been in the last year or two that I've seen it used in these OSC arguments."
It's not a perfect essay, and I think it tends to fail the test of Occam's Razor on many points, but it's good. Sadly, there aren't any sources of it online that I know of. You're likely thinking of the guy (forget his name) who wrote ABOUT it, and about Card. He also seems to have an axe to grind, but also makes some OK points here or there.
"Your quote from the other article (presuming it's in context, which I have no reason to doubt)"
You can just search for the title on Google. There are several copies available from Mormon sources as well as in the GLBT community. However, I applaud your hesitency to simply buy into what some random person on Slashdot asserts. I wish more people questioned sources without just flaming, as you have.
"You also wanted me to clarify about my little "science has proven" comment. I was actually making a little dig at those people who claim that homosexuality can be somewhat demonstrated in a genetic sense, so therefore it is socially acceptable."
I think I pretty much got that, but wanted to confirm. Just one note: the argument as I've seen it stated is a bit more narrow:
Christians and some other religions assert that homosexuality is a sin.
However, we are discovering (and the evidence IS getting pretty solid) that homosexuality is an attribute of a person's genetic makeup (at least in part)
Thus, homosexuality is one of God's creations, and cannot be a sin.
Card's counter to this argument is:
God also created the temptations for many other types of sin, but that does not make the commission of those sins right. In essence, he is arguing that homosexuality is a test of one's ability to resist sin, and those who are ACTIVELY homosexual (as opposed to simply being pre-disposed) are thus sinners.
My counter to that is:
That's all very nice, but I'm neither a Mormon nor a Christian of any sort, and I couldn't care less. Keep your laws off my privates.
Aside from Card's rebuttal, another angle is:
Ok, well if it's genetic, then it's a genetic disease just like Down's Syndrom, and we should seek to cure it at a genetic level.
Of course, this runs aground immediately, especially in light of Kinsey's research which shows that there is a clear continuum of sexual orientation, and that extremes on either end are no more the norm than any single point on the line. It's not very workable to label something so prominent in the human species as a "disease", and seeking to "cure" homosexuality isn't as simple a prospect as you might think.
It's also not clear that you can reasonably refer to a social stigma as a "disease". There have certainly been cultures where being homosexual was not a disadvantage at all.
"Have I made any good arguments yet? No, I guess I've lost some ground."
Nope, I think I understand whered you're coming from.
"I will argue your point #4. I agree that it isn't unreasonable to change your opinion of something as you age, or as you encounter good arguments and new information. This is natural, and we hope that people can do it. What isn't logical is to assert that those who still hold their old beliefs (e.g., those who still like OSC after all these years), only do so for the sake of tradition in spite of what "facts" may have become available. If I believed that OSC was a raving sociopath, it might be more difficult for me to enjoy his work in light of that."
I don't think I disagree with any of that.
"Alas, my original post was sadly under-researched,"
This is Slashdot. No one noticed, trust me
"Thanks for the response."
And you for yours!
I think you misunderstood my post. Please re-read it, and note the lack of the phrase, "conclusive evidence" as applied to DNA results.
What DNA testing tells you is several things: 1) is it a species that could reasonably have ended up in Australia; 2) is it a hybrid species (likely if the lineage is based on random releases from zoos, but not as likely if, say, from a poacher in South America); 3) it allows future samples to be compared, giving credibility if they are related; 4) if there are genetic records of cats that might have been in zoos, then that would be great, but unlikely.
No, not control. If you want concentric circles, you have to click on the center point, sweep to where you want the edge, then hold control and shift at the same time, release the mouse button. Simply holding control and sweeping will get you an ellipse (which might happen to be a circle if you get it just right) that will subtract from your current selection. That's right, for the circle tool control has two completely different and conflicting meanings, and you can get one both or the other depending on the sequence of keydown-buttondown-buttonrelease-keyrelease. Anyone who defends the Gimp UI as well-designed has clearly never used a well-designed UI. Mind you, I have developed for, and contiue to use the Gimp. I just have no illusions about the usability of the UI.
"I have a p3 450mhz box running Tomcat/MySql. It serves my local applications fast enough. The server can render the page much more quickly than my browser (on a p4 1.5ghz box) can render it."
I just want to note that this is a horrible metric. What you care about is not that a single browser can be fed by your program, but how well it performs under the load of dozens of simultaneous page generations.
Single page generation metrics lead to very dissapointing real-world results.
That is to say, around the time that he let loose with his The Hypocrites of Homosexuality rant which included, among other choice bits,Yes, that's about the time that I started re-reading Card's work with an eye to the views that he was attempting to push into the mainstream. It's when I became aware of the comparisons of Ender's Game and Xenophile with this history of the Third Reich (which, I have to say, are weaker than simply saying that Card is detatched from any sense of right and wrong, and much more interested in relative "correctness").
"People who were once quite passive about Card, or even complimentary, suddenly became his worst critics. I know some who loved Ender's Game, and then found out that Card is Mormon.
I found out that Card was a mormon just after reading Ender's game, and just before I picked up The Tales of Alvin Maker, book one. I don't think it affected my thoughts about him. I grew up in a fundamentalist Christian / athiest family which allowed me to develop a healthy respect for both the religious and non-religious points of view, and I've since come to respect many religions. Mormonism isn't really one of those, but I give it the benefit of the doubt on most topics. Card is a dangerous sociopath, as best I can tell, and that has nothing to do with his choice in faiths.
"Several years ago, Slashdot's conversations about OSC were generally quite positive. Now you can guarantee that any OSC discussion will contain the following elements:
"1) Ender's Game is a Nazi-loving revenge saga. This is a recent argument based on a particular review from an OSC critic. Disciples of this "received" idea now push it as gospel truth."
Recent?! You do know that the original essay, "Ender's Game: Sympathy for the Superman" was published in 1987, don't you? You're also widely misrepresenting the point of the essay, but I presume you know that.
"2) OSC is a homophobe because he disagrees with the gay lifestyle and with gay marriage, even after science has proven that these things are perfectly normal."
Clarify. Do you mean that science has proven that homophobia is perfectly normal or that homosexuality is? Either way, Card is not considered a homophobe because he doesn't think same-sex-sex is a good idea. He's considered a homophobe because he passionately advocates the supression of homosexuality at a legal level.
"3) I hate OSC, but I still think his books are pretty good."
I can't say that I like Hemingway as a person either. Not to say that Card is any Hemingway in terms of writing, of course, but the hyperbolic example makes the point clearly, I think.
"4) I used to love Ender's Game, but now that I'm older and smarter, I find that I hate it because it's actually quite shallow. People who still like it are nostalgics."
And this is unreasonable, why?
Most of the rest of your points repeat the above points, so I'll just leave it at that.
ahem... "beasts" not "breats" is what I meant... I had chicken on the brain that day....
POSIX, VESA and even ttys are all examples of specificatons that sought to unify existing practice. The practice came first, then the theory. If you want an example that goes the other way, you would have to look to something like IP, which was created as a specificaton along with the first implementations.
Linus is correct, though. Specs are rarely useful breasts up-front. Standardization of existing practice is often useful, but that's another beast.
That's not a bad system, but suffers from the problem that the passwords are all written down. In some environments this is fine, in some it's tragic. Granted, your scheme still has a secondary key, but given your primary key only (the cheat card), writing code to search every simple word as transformed by the matrix would be easy. Again, your system is better than most.
The real pain comes in when you need to generate passwords for people in advance and, for whatever reason, the "change it the first time you use it" suggestion isn't enforcable (e.g. they're using a system that can do so, but don't use that feature or the system is incapable of that feature).
When this happens, I use http://www.ajs.com/~ajs/mkpasswd. I also use it to generate my own passwords. You can use it to generate passwords that are impossible to crack other than by brute force (mkpasswd -r --strict, which is a random sequence, but filtered for dictionary words); a password that is a simple dictionary word (mkpasswd -p 'W8-12') and just about any level security/memorability trade-off in between. By default (mkpasswd -r -5 --max 12 --non-word) a set of pre-defined password patterns are consulted. After permutation of various parameters, there are about 270 patterns to choose from, each producing a fairly reasonable number of possible passwords, though some patterns are better than others. This is not the strength of the program, however.
The strength of the program lies in the fact that it is capable of parsing a pattern provided by the user which defines their desired password in whatever way they like. One such description might be "x3-5n2WJ4n1" which translates as: "a 3-5 letter pseudo-word (pronouncable random letters), a 2-digit number, a 4 character "join word" (two dictionary words that overlap, forming a 4 character result) and a single digit". If I were to hand out passwords to all of my users of this form, it would be a tragically weak scheme (the search space is very small), but if one of my users chooses this as the scheme for their current password, the result would be quite reasonable.
The program has some experimental features too, like the "--easy" flag which tells the program to find a password that alternates sides of the keyboard for each keystroke (QWERTY only). This currently only works for most of the pattern types, but as an example, it does a great job on mkpasswd -5 -p 'xT9-12' --easy
"So take their code, release it under GPL"
They already do this. That's the problem with this whole license foolishness is that everyone has somehow gotten the impression that MySQL isn't distributing GPLed code. What they are doing is pointing out the restrictions that the GPL places on users of library code (which the authors of the GPL were so strongly aware of that they created the "Library General Public License" with more permissive terms, but later decided that they didn't like that and re-named it the "Lesser General Public License"). What the FSF now encourages users of the GPL to do is exactly what MySQL is doing: distribute under the GPL.
The only difference is that MySQL adds in some loopholes to get around the GPL where it would hinder open source projects with GPL-incompatible (but still open source) licenses. If those projects use GPL-only (e.g. "downstream") copies of MySQL, then they are fully bound by its terms. If they use the version provided by MySQL, then they are granted these exceptions.
It is worth noting that this "highly restrictive license" that they are using is called the "GPL". What the linked page does is just to set some conditions under which you are free of the GPL's requirements for software that incorporates their code.
Of course, all of the usual provisos stand: the GPL is a license, not an EULA, so you don't have to agree to be bound by its terms to *use* the software (the GPL is quite clear on this).
All of these issues exist for ANY GPL-covered library code, and all MySQL is doing is playing by the rules of the GPL in exactly the way people like RMS have requested (this is why the LGPL is backronymed into meaning "LESSER Gernal Public License").
It should also be pointed out that in a language like, say Perl, where code is distributed as text, not as a pre-compiled representation, the claim of tainting can really only be applied to the AST, and not the text which generated it. Should that AST be used to generate stored code (e.g. compiled machine code or a bytecode representation) then that code might be tainted (that's deep laywer territory, so I'm not qualified to say one way or the other).
You are looking at this incorrectly. The problem is that, given file A, which has hash X, if it is possible to create file B which has hash X in a non-exaustive way, then the hash is weak. Most such techniques work well regardless of file B being a from-scratch random pile of data or a combination of well-formed data plus random data. So, for example, you might have an RPM with 3 files in it. Add a fourth file, and start permuting to find your similar hash.
Now, as you point out, we're not yet to the point that this is trivial with MD5 (it has always been possible, just not practical). So, the only valid thing to do is to move to something more secure as soon as possible so that when we finally do discover a trivial exploit for MD5, we no longer care as much about it. This also helps us by forcing software vendors and projects to re-consider how they use hashing, and to make it easier to modularly replace the hashing functions they use. You will note that all of the oldest such software has already had to do this, and thus the task will be easier for them.
I'm not a lawyer, and I don't know the impact that this will have. I've also been around Slashdot long enough to assume that I don't have all of the facts. However, insofar as I have read to date, I'm thrilled that Google is making this effort, and while I know they're a massive corporation with far more resources than I will ever have — if they make it possible — I will do more research into the topic and consider donating to their legal defense.
Copyright is a sticky issue, and I want to see authorship be a viable profession again (it almost is now, but it's damn hard to break in, and the pay still pretty much sucks unless you are very lucky or able to write in certain niches, e.g. as a "script doctor").
However, I'm also a reader, and I am deeply saddened that we have yet to come up with a viable model for publishing un-crippled novels on the Web. Histories, reference, news and other non-fiction have found their niche, but other than video, fiction seems to be a sticking point. This one area needs to be addressed, and Google may be the irresistable force that can make the publishing industry get creative enough to find the solution.
C'mon... if we can come up with the books we can, we must be creative enough to figure out a way to make re-distributable data have value.