A state-wide study conducted in the first four years after the introduction of the law showed a 42% reduction in hospital admissions for cycling sustained head injuries.
http://www.general.monash.edu.au/muarc/rptsum/es76.htm
Unfortunately, others claim that this is mainly attributable to a decrease in cycling:
http://www.cyclehelmets.org/papers/c2001.pdf
It is illegal to ride a bike without a helmet.
That depends on where you live, of course. Where I live it isn't illegal, at least not for adults.
2) Something to keep the rain and road dirt from putting a big skunk stripe up our backs when riding in wet climates. There are fenders, but they don't work well.
If you haven't already, try fooling around with different fenders. For some reason, most of them seem to be much too short; you want something that covers as much of the wheel as possible. Don't settle for something that doesn't work well; good fenders really do make a big difference. Some people even tack on a little extra themselves (do a google search for "bicycle" and "mudflaps").
4) Brakes that work in the rain.
My old 80's 10-speeds had brakes that were almost totally useless in the rain. With a new bike (low-end road bike, bought just last year), braking is awesome in any weather. I'm sorry, I don't know what the technical difference is. But I do know now that there exist brakes that work in the rain, so there is hope.
They are selling this camera at below wholesale cost so they can make their money on the back end, in the prints. As I understand it from when I first read about these cameras (this may have changed), they even give you a CD-r with your pictures on it when you get the camera "developed", so you can even print more copies without going through them. I think their approach is the most consumer-friendly yet
No doubt you also think it's consumer-friendly to advertise a printer based on its low initial cost in the hopes that the consumer won't realize till later that the cost of the printer itself will be insignificant compared to the cost of keeping it fed with ink.
The rest of us don't see it that way. To the rest of us it looks an awful lot like what they're trying to do, in both cases, is to make the task of comparison-shopping more difficult and, in doing so, to fool the consumer into spending more money than they intended. In many cases the consumers who buy the "cheap" printers would have been better off with a different printer; but thanks in part to the "consumer-friendly" pricing, they miscalculated.
So Ritz tried to pull the same trick, and failed. Can you see why we don't feel so sympathetic?
Companies could avoid this sort of problem by simply basing their selling prices on the real cost of their merchandise instead of trying to play these elaborate games to deceive consumers.
No. You don't want it laughed out of court. You want this to be properly resolved. We don't need any more of the bullshit coming from the courts where it's decided that the case is not strong enough to set a precedent, so it's dropped instead of getting resolved.
What deep legal question do you see in this case that needs a precedent-setting answer?
For example, there's the question of whether there actually is code in the linux kernel that was improperly copied from proprietary sources. But that's not a particularly deep question. They compare the code, weigh the evidence, and decide whether there's copied code or not (probably not, given the evidence (or, rather, lack there of) presented so far). No Big Questions there.
--Bruce Fields
Re:unison is probably a better solution
on
Home Directory In CVS
·
· Score: 2, Informative
rsync is a uni-directional file synchronizer and it doesn't have an interactive interface
Yes, but it's trivial to run it twice, once in each direction, with arguments that result in updates propagating in both directions.
I used to depend on exactly that technique to keep my home directories in sync. It was a pain in the butt. If you have a file named "foo" in replica A and no such file in replica B, then rsync has no way to tell whether it should delete "foo" from A or copy it to B. For that you need to know some minimal information about what the replicas were like at the time of the last synchronization. Unison takes care of all this for you in a very clever way. It's really worlds better than just using rsync. I highly recommend it.
I don't recall saying it was a common problem; just a known weakness of land-line alarms, particularly for professionals (who are admittedly few... most burglaries are youths, or people looking for a quick score for some drug money). That said, you'd hate to be that one person frantically dialing for help, with the awful realization that you didn't have a backup plan.
Fair enough. Though personally for the moment I think this may fall below the "is this likely enough to bother thinking about" threshhold (and certainly below the "is this worth buying a cellphone" threshhold).
a burglar cuts your land line before hitting your house; oldest trick in the book.
Is this based on statistics or the movies? In what percentage of burglaries does this happen? And what percentage of 911 calls actually involve burglaries?
Lacking evidence to the contrary, I very much doubt this is common enough to make land lines less reliable than cell phones for making 911 calls.
Wouldn't they be better off spending that $250,000 on another programmer-year or two of code audits?
This whole business with bounties for virus writers is just an attempt at misdirection: draw the public's attention to the people writing the viruses instead and away from the fundamental flaws they're exploiting.
It's important that the public realize that the security holes exploited by the virus writers are also exploited in less public and more nefarious ways.
The notion of a free product that is in many ways superior to its commercial counterpart scares alot of people....It was only a matter of time before this ideology was challenged.
This is exactly what McBride and co. would like you to believe this is all about--it's all a grand free vs. proprietary battle. Look at their interviews. They go on at great length about this sort of thing.
Don't fall for their trap; SCO is not raising any interesting issues at all. They've simply been claiming, without any evidence whatsoever, that some of the code in linux violates their copyrights. If, despite all expectatations, this actually turns out to be true, then that code will of course have to be removed--you won't find any serious kernel developer or free software advocate who would tell you otherwise.
McBride likes to talk about the bigger issues, but that's just an attempt to distract you from their total lack of evidence.
The parallel that the author wants to draw between SCO's case and this one is far-fetched: SCO has been making public allegations and demands for months now without producing a shred of evidence, whereas the FSF has been quietly negotiating a solution to a well-documented violation. (We know their evidence is good because other individuals (not the FSF) have published detailed documentation, including, for example, step-by-step instructions on how to extract code from the Linksys devices and compare it to the kernel tree.)
Also, I see no evidence whatsoever for the allegation that the FSF is secretly hoping to trap companies into accidentally include GPL'd code in their products so that the FSF can force them to open source their software. As far as I can tell the FSF makes a great effort to explain the GPL and what it requires of licensees.
Grow up and realize you are in something larger than your grandmotehr's dining room. One persons etiquette is anotehrs' nightmare.
No, one person's etiquette is another person's etiquette. The rules that say unwanted interruptions are rude weren't just arbitrarily made up on the spot by me; they are long-standing and well-established.
You want to take food off of my kids' dinner table so you can sit at yours and not have to ignore the phone, or pay afew bucks to have the calls blocked.
That is a breach of etiquette, and of simple respect.
I know of no rule of etiquette or law that says that you have the right to make your living by any means necessary; some business practices have always been declared illegal, even though it may have meant a loss of jobs. I'm sorry to hear that you think this new legislation may put you out of a job, and wish you the best of luck finding employment elsewhere.
I know... I know... not a lot of sympathy, but still, I work for a business who would like to do nothing more than play by the rules,
No you don't, because the rules have always prohibited "telemarketing".
The fact that these were rules of etiquette and not of law is no excuse.
If people commit sufficiently egregious etiquette violations for a sufficiently long time, then eventually they irritate enough votors that the law steps in. The violators may then attempt to paint themselves as the innocent victims of changing times, acting suprised that it has "suddenly" become against the rules to interrupt people in their homes without their permission to make a sales pitch, or to pinch their secretary's butts, or whatever.
The rest of us will be less than impressed by this rather disingenuous plea for sympathy.
A customer is someone who buys something from you. If you download MP3s illegally, you're not buying them from any of the record labels. Therefore, the RIAA is not suing any its (technically, the labels') customers!
Yep. I've been a hawk for every bit of information I can get my hands on. I don't think a fbconsole on a Radeon 8500 LE should be this weird of an order. (I know, the devteam cannot test every combination of hardware, yadda, yadda).
You probably know this already, but if you have some time to spare and know your problems haven't already been reported, and you're willing to follow up, try patches, etc., it'd be worth sending a message to lkml with all the details. That's one of the ways developers manage to keep the kernel working on hardware they don't have direct access to.
Bottom line is you can complain about it all you want or you can actually try it and see that it works.
I've never doubted you on that. I use spam filters myself, and find that they work; that's not the point. Your original claim was that spam filters were now good enough that we no longer have to worry about the problem of spam. What the rest of us would like to point out is that the fact that some spam filters currently work reasonably well is *not* sufficient evidence to establish that they will work on their own as a long-term anti-spam solution.
Several attempts have been made to attack the tokenizer, which is one area DSPAM has a considerable lead on other tools. DSPAM performs several different deobfuscation techniques prior to tokenizing a message.
In other words, spammers have already started to attack bayesian filters (or at least filters that identify keywords) and DSPAM is using techniques to deal with those particular attacks. The bayesian filter didn't automatically learn to defend against the tokenizer attacks--humans had to intervene and write code. And the code they wrote doesn't deal in general with attacks against the tokenizer--it deals with the particular attacks that have been tried so far.
We can both imagine further attacks on the tokenizer, and we can both imagine defenses against those attacks. This is an arms race. It's not a very satisfactory long-term solution.
Even attaching ham messages doesn't quite do the trick, for the reasons I mentioned in my previous email.
I believe the reason you gave was that you thought the "ham"-identifying tokens would be too particular to the individual receiver? Again, I'm not so sure this is true--for example, any filter that I use has to (at a minimum) identify as "ham" almost all email from the linux-kernel mailing list and a dozen other lists on various topics. Any spammer can download the archives of a few big mailing lists and test out their spam against a bayesian filter that passes mail on those lists.
I doubt the ham each of us receives is *that* unique. And if even only 10% of the mail we receive is significantly generic, then this is enough---a spam filter that wrongly identifies 10% of my mail as spam is close to useless to me.
With the above 3 mechanisms, it is very difficult to craft a spam that will make it through a majority of filters
This is a bit like pointing out that exploiting some buffer overflow is difficult, and concluding that buffer exploits will never happen. The problem of course is that it only takes one person to figure out the exploit and automate it.
I haven't read the papers about bayesian filters (reccomendations? I'd be interested), but I'd think the first attack would be on the tokenizer. What does a bayesian filter do, for example, with a message consisting of nothing but tokens it's never seen before? (It should be possible to convert an arbitrary message to a message with unique tokens using unicode tricks and mispellings and such.)
Also my understanding is that bayesian filters only capture the frequency of tokens, with little or no information about their ordering. So tricks like appending ham-like messages to spam might be effective. As you point out, the notion of "ham-like" may vary significantly from user to user:
the spammer would need to come up with two adjacent tokens, case sensitive, that a majority of users are likely to have as very innocent in their dictionary...not a very easy feat.
We'd need to do experiements to determine if this is an easy feat or not; it could be that analysis of a few popular mailing lists and such would yield enough data about what "ham" looks like to be useful to a spammer. I'd think that Spam filters that really depend heavily on a small number of user-specific "good" tokens to identify ham would have unacceptably high false-positive rates. A great deal of the legitimate mail that I receive (e.g., mail from the linux kernel mailing lits) is not directed specifically at me.
It seems to me that the frequency of tokens in a message captures much too little information about the message, and it should be relatively easy to find ways to automatically munge spam messages to make those frequencies look innocent, without greatly degrading the spam signal.
Spammers spam because they make money. Educate people to ignore spam, and the spammers don't make money. Bingo, no more spam!
That might help. Though it only takes a few suckers.... (Either among the customers, falling for the spammers' sales pitches, or among the spammers, falling for the spam-software sellers' sales pitches.)
Actually the vast majority of my "spam" right now is the result of a virus that could just as well have been written by a teenager on a whim.
As long as the system is so fragile than anyone can exploit it with a minimum of effort just for fun, there's always going to be a problem.
Whine and insult me all you like... and you can throw all the papers you want to my way, but the proof is in the fact that I DONT GET SPAM (except for the mindless responses such as yours posted to slashdot).
One of the things mumblestheclown is pointing out is that the fact that you personally are currently managing to filter out your spam is *not* sufficent evidence to prove that the software you are using will be an effective long-term solution.
The software you're using (however clever it is, however hard it tries to "learn" new types of spam), has easily exploitable flaws. The spammers haven't gotten around to exploiting them because it probably hasn't seemed worth their while--probably not enough people are using the same type of filter yet. But they will, eventually. At which point filters that take a fundamentally new approach will be required. Which the spammers will eventually figure out a way around. Etcetera.
Most spam filters are designed with the goal of filtering out spam that is similar to currently circulating spam; they make no attempt to resist an intelligent person who has spent some time thinking about how to circumvent the filter.
Take a student who has had no experience with the subject matter. You think this approach would still work well?
Watching at double-speed itself might not be so important, but it might be a useful part of a student's strategy to take more control over their learning. For example, speeding through a set of lectures very quickly and then going back to study the interesting parts more carefully could be very effective.
So for those programmers thinking about UI, don't do it! Stick with command-line interfaces
The commandline is an interface just as a gui is, and it can be done well or badly. I'm sure we've all seen examples of bad commandline interfaces.
It's a trivial point, but one that tends to be forgotten in the rush to produce an interface that's "pretty" and uses lots of graphics.
The other common mistake seems to be to separate users into "geeks" and "grandmas" and to assume that user interface design is only a sort of pandering to the superficial aesthetic demands of the latter group.
User interface design is primarily about things like consistency and organization, not aesthetics, and bad interfaces annoy everyone, experts and beginners alike.
What should I ask SCO when I'm there if I get a chance to ask one question?
Based on previous stories the best thing to bring may just be a digital camera good enough to reproduce the text of any slides....
But personally I think it's most interesting to ask when we'll see evidence to allow us to evaluate SCO's claim that Linux infringes SCO's copyright. They seem to like the idea of turning this into a "free" vs. "proprietary" debate, which is of course just an attempt to draw attention from the main question of whether there's actually any infringement going on.
@stake was acting in their own interest. For them, Microsoft is a potential customer and keeping good relations is what they had in mind.
Let's not forget that there's a difference between acting in one's own interests and acting correctly.
To which you may respond that a corporation is required (by economic forces, by legal responsibilities to its shareholders, or whatever) to act in its own interests, even when such action is wrong.
Which a lot of people would say is one of the primary problems with corporations....
Slashdot Mirror
Unfortunately, others claim that this is mainly attributable to a decrease in cycling: http://www.cyclehelmets.org/papers/c2001.pdf
That depends on where you live, of course. Where I live it isn't illegal, at least not for adults.
--Bruce Fields
If you haven't already, try fooling around with different fenders. For some reason, most of them seem to be much too short; you want something that covers as much of the wheel as possible. Don't settle for something that doesn't work well; good fenders really do make a big difference. Some people even tack on a little extra themselves (do a google search for "bicycle" and "mudflaps").
My old 80's 10-speeds had brakes that were almost totally useless in the rain. With a new bike (low-end road bike, bought just last year), braking is awesome in any weather. I'm sorry, I don't know what the technical difference is. But I do know now that there exist brakes that work in the rain, so there is hope.
Keep riding!
--Bruce Fields
No doubt you also think it's consumer-friendly to advertise a printer based on its low initial cost in the hopes that the consumer won't realize till later that the cost of the printer itself will be insignificant compared to the cost of keeping it fed with ink.
The rest of us don't see it that way. To the rest of us it looks an awful lot like what they're trying to do, in both cases, is to make the task of comparison-shopping more difficult and, in doing so, to fool the consumer into spending more money than they intended. In many cases the consumers who buy the "cheap" printers would have been better off with a different printer; but thanks in part to the "consumer-friendly" pricing, they miscalculated.
So Ritz tried to pull the same trick, and failed. Can you see why we don't feel so sympathetic?
Companies could avoid this sort of problem by simply basing their selling prices on the real cost of their merchandise instead of trying to play these elaborate games to deceive consumers.
--Bruce Fields
What deep legal question do you see in this case that needs a precedent-setting answer?
For example, there's the question of whether there actually is code in the linux kernel that was improperly copied from proprietary sources. But that's not a particularly deep question. They compare the code, weigh the evidence, and decide whether there's copied code or not (probably not, given the evidence (or, rather, lack there of) presented so far). No Big Questions there.
--Bruce Fields
I used to depend on exactly that technique to keep my home directories in sync. It was a pain in the butt. If you have a file named "foo" in replica A and no such file in replica B, then rsync has no way to tell whether it should delete "foo" from A or copy it to B. For that you need to know some minimal information about what the replicas were like at the time of the last synchronization. Unison takes care of all this for you in a very clever way. It's really worlds better than just using rsync. I highly recommend it.
--Bruce Fields
Fair enough. Though personally for the moment I think this may fall below the "is this likely enough to bother thinking about" threshhold (and certainly below the "is this worth buying a cellphone" threshhold).
--Bruce Fields
Is this based on statistics or the movies? In what percentage of burglaries does this happen? And what percentage of 911 calls actually involve burglaries?
Lacking evidence to the contrary, I very much doubt this is common enough to make land lines less reliable than cell phones for making 911 calls.
--Bruce Fields
Wouldn't they be better off spending that $250,000 on another programmer-year or two of code audits?
This whole business with bounties for virus writers is just an attempt at misdirection: draw the public's attention to the people writing the viruses instead and away from the fundamental flaws they're exploiting.
It's important that the public realize that the security holes exploited by the virus writers are also exploited in less public and more nefarious ways.
--Bruce Fields
This is exactly what McBride and co. would like you to believe this is all about--it's all a grand free vs. proprietary battle. Look at their interviews. They go on at great length about this sort of thing.
Don't fall for their trap; SCO is not raising any interesting issues at all. They've simply been claiming, without any evidence whatsoever, that some of the code in linux violates their copyrights. If, despite all expectatations, this actually turns out to be true, then that code will of course have to be removed--you won't find any serious kernel developer or free software advocate who would tell you otherwise.
McBride likes to talk about the bigger issues, but that's just an attempt to distract you from their total lack of evidence.
The parallel that the author wants to draw between SCO's case and this one is far-fetched: SCO has been making public allegations and demands for months now without producing a shred of evidence, whereas the FSF has been quietly negotiating a solution to a well-documented violation. (We know their evidence is good because other individuals (not the FSF) have published detailed documentation, including, for example, step-by-step instructions on how to extract code from the Linksys devices and compare it to the kernel tree.)
Also, I see no evidence whatsoever for the allegation that the FSF is secretly hoping to trap companies into accidentally include GPL'd code in their products so that the FSF can force them to open source their software. As far as I can tell the FSF makes a great effort to explain the GPL and what it requires of licensees.
--Bruce Fields
No, one person's etiquette is another person's etiquette. The rules that say unwanted interruptions are rude weren't just arbitrarily made up on the spot by me; they are long-standing and well-established.
I know of no rule of etiquette or law that says that you have the right to make your living by any means necessary; some business practices have always been declared illegal, even though it may have meant a loss of jobs. I'm sorry to hear that you think this new legislation may put you out of a job, and wish you the best of luck finding employment elsewhere.
--Bruce Fields
I will spell-check my posts
I will spell-check my posts
I will spell-check my posts....
--Bruce Fields
No you don't, because the rules have always prohibited "telemarketing".
The fact that these were rules of etiquette and not of law is no excuse.
If people commit sufficiently egregious etiquette violations for a sufficiently long time, then eventually they irritate enough votors that the law steps in. The violators may then attempt to paint themselves as the innocent victims of changing times, acting suprised that it has "suddenly" become against the rules to interrupt people in their homes without their permission to make a sales pitch, or to pinch their secretary's butts, or whatever.
The rest of us will be less than impressed by this rather disingenuous plea for sympathy.
--Bruce Fields
There. The RIAA just sued a customer.
--Bruce Fields
You probably know this already, but if you have some time to spare and know your problems haven't already been reported, and you're willing to follow up, try patches, etc., it'd be worth sending a message to lkml with all the details. That's one of the ways developers manage to keep the kernel working on hardware they don't have direct access to.
--Bruce Fields
Have you seen this thread?
I've never doubted you on that. I use spam filters myself, and find that they work; that's not the point. Your original claim was that spam filters were now good enough that we no longer have to worry about the problem of spam. What the rest of us would like to point out is that the fact that some spam filters currently work reasonably well is *not* sufficient evidence to establish that they will work on their own as a long-term anti-spam solution.
--Bruce Fields
You mean this one?
In other words, spammers have already started to attack bayesian filters (or at least filters that identify keywords) and DSPAM is using techniques to deal with those particular attacks. The bayesian filter didn't automatically learn to defend against the tokenizer attacks--humans had to intervene and write code. And the code they wrote doesn't deal in general with attacks against the tokenizer--it deals with the particular attacks that have been tried so far.
We can both imagine further attacks on the tokenizer, and we can both imagine defenses against those attacks. This is an arms race. It's not a very satisfactory long-term solution.
I believe the reason you gave was that you thought the "ham"-identifying tokens would be too particular to the individual receiver? Again, I'm not so sure this is true--for example, any filter that I use has to (at a minimum) identify as "ham" almost all email from the linux-kernel mailing list and a dozen other lists on various topics. Any spammer can download the archives of a few big mailing lists and test out their spam against a bayesian filter that passes mail on those lists.
I doubt the ham each of us receives is *that* unique. And if even only 10% of the mail we receive is significantly generic, then this is enough---a spam filter that wrongly identifies 10% of my mail as spam is close to useless to me.
--Bruce Fields
This is a bit like pointing out that exploiting some buffer overflow is difficult, and concluding that buffer exploits will never happen. The problem of course is that it only takes one person to figure out the exploit and automate it.
I haven't read the papers about bayesian filters (reccomendations? I'd be interested), but I'd think the first attack would be on the tokenizer. What does a bayesian filter do, for example, with a message consisting of nothing but tokens it's never seen before? (It should be possible to convert an arbitrary message to a message with unique tokens using unicode tricks and mispellings and such.)
Also my understanding is that bayesian filters only capture the frequency of tokens, with little or no information about their ordering. So tricks like appending ham-like messages to spam might be effective. As you point out, the notion of "ham-like" may vary significantly from user to user:
We'd need to do experiements to determine if this is an easy feat or not; it could be that analysis of a few popular mailing lists and such would yield enough data about what "ham" looks like to be useful to a spammer. I'd think that Spam filters that really depend heavily on a small number of user-specific "good" tokens to identify ham would have unacceptably high false-positive rates. A great deal of the legitimate mail that I receive (e.g., mail from the linux kernel mailing lits) is not directed specifically at me.
It seems to me that the frequency of tokens in a message captures much too little information about the message, and it should be relatively easy to find ways to automatically munge spam messages to make those frequencies look innocent, without greatly degrading the spam signal.
--Bruce Fields
That might help. Though it only takes a few suckers.... (Either among the customers, falling for the spammers' sales pitches, or among the spammers, falling for the spam-software sellers' sales pitches.)
Actually the vast majority of my "spam" right now is the result of a virus that could just as well have been written by a teenager on a whim.
As long as the system is so fragile than anyone can exploit it with a minimum of effort just for fun, there's always going to be a problem.
--Bruce Fields
One of the things mumblestheclown is pointing out is that the fact that you personally are currently managing to filter out your spam is *not* sufficent evidence to prove that the software you are using will be an effective long-term solution.
The software you're using (however clever it is, however hard it tries to "learn" new types of spam), has easily exploitable flaws. The spammers haven't gotten around to exploiting them because it probably hasn't seemed worth their while--probably not enough people are using the same type of filter yet. But they will, eventually. At which point filters that take a fundamentally new approach will be required. Which the spammers will eventually figure out a way around. Etcetera.
Most spam filters are designed with the goal of filtering out spam that is similar to currently circulating spam; they make no attempt to resist an intelligent person who has spent some time thinking about how to circumvent the filter.
Bayesian filters are no exception here.
--Bruce Fields
Watching at double-speed itself might not be so important, but it might be a useful part of a student's strategy to take more control over their learning. For example, speeding through a set of lectures very quickly and then going back to study the interesting parts more carefully could be very effective.
--Bruce Fields
The commandline is an interface just as a gui is, and it can be done well or badly. I'm sure we've all seen examples of bad commandline interfaces.
It's a trivial point, but one that tends to be forgotten in the rush to produce an interface that's "pretty" and uses lots of graphics.
The other common mistake seems to be to separate users into "geeks" and "grandmas" and to assume that user interface design is only a sort of pandering to the superficial aesthetic demands of the latter group.
User interface design is primarily about things like consistency and organization, not aesthetics, and bad interfaces annoy everyone, experts and beginners alike.
--Bruce Fields
Based on previous stories the best thing to bring may just be a digital camera good enough to reproduce the text of any slides....
But personally I think it's most interesting to ask when we'll see evidence to allow us to evaluate SCO's claim that Linux infringes SCO's copyright. They seem to like the idea of turning this into a "free" vs. "proprietary" debate, which is of course just an attempt to draw attention from the main question of whether there's actually any infringement going on.
--Bruce Fields
Let's not forget that there's a difference between acting in one's own interests and acting correctly.
To which you may respond that a corporation is required (by economic forces, by legal responsibilities to its shareholders, or whatever) to act in its own interests, even when such action is wrong.
Which a lot of people would say is one of the primary problems with corporations....
--Bruce Fields