There's a strong core of "ham" that is "ham" for everybody, and sooner or later they're going to start abusing that.
Do you have evidence to back that assertion? In my case (I know it's just me), ham basically means either refering to my open-source projects or written in French (even then spambayes does a good job at rejecting French spam).
I don't think spammers are that dumb either. I see four main difficulties for them to overcome bayesian filters: 1) Differences between user's filters (which you said can be overcome because "ham is ham") 2) Lack of "training data" for them We have lots of data from which we can learn how to avoid spam, but they have very little data which they can use to "train" anti-filter techniques. 3) They have to get the main message through. Eventually, if you can detect all forms (that remains to be seen) of the word "Viagra", they simply can't use that word in their email anymore (assuming I've got no ham containing that word). 4) Because each spam message is different, they have to find a cost-effective way to make each of them immune to filters. That's not easy either.
I don't think any legitimate mail contains v|agr@ in it. If some ham was supposed to include a certain word, it would probably be already in my ham training set. I think the main problem is that there are just so many misspellings you can use in spam. Also, spelling "V I A G R A" causes problems because the words are just "V", "I", "A" and so on. That's why I think we'll need to: 1) Start using bigrams (or N-grams) 2) Start assigning a "spam probability" to unknown words or words that contain non-alpha chars.
Do you consider it "misleading" to label an Athlon running at 1.8GHz as a 2200?
Actually, the equivalent would be AMD selling an Athlon 1.8 labeled as "2.2 GHz". The 2200 is just a model number. You may say that (or the MP/XP) is misleading, but saying 9200 when it's 9000 is simply false. Then, the MP/XP is still fine with me. All the "MP" means is that "we guaranty that it'll work in a multi-processor machine".
Of course, i was just talking about the possibility to detect the steg itself, not the human factor... Even sending 24-bit music and all might sound suspect.
The other important issue is whether the "ennemy" knows what kind of steg you might use. That helps detection a lot.
...reporting any abnormal results (i.e. the presence of steganography). I personally don't think that is feasible...
I think it probably depends on where you hide the data. For instance, it's probably harder to hide data in the LSBs of an image than, e.g. a file that's supposed to be white noise ("Hey, my mic doesn't work, it only records noise. See for yourself"). Of course, the less data you encode, the harder it is to detect it.
I think your close to the reason. It seems like the companies in the US cover much smaller areas and can set whatever price they want when there's no other company in the area. If you look at Quebec (7M people), you've got one DSL provider (Bell Canada) and one (major) cable company (Videotron). Now, since they can't really change their rates according to the region (they'd get crucified), they have to compete against each other. Now even if in your region all you have is DSL, you still benefit the competition.
Re:Don't reinvent the wheel. Send it over SSL.
on
Feds Want to Tap VoIP
·
· Score: 2, Insightful
Isn't SSL designed for a streaming connection? In the case of VoIP, you need to have lots of small (10-40 bytes) chunks encrypted intependently (because some may get lost), so it's completely different than a TCP connection.
Seriously, I'm the author of Speex (the speech codec) and I'd be willing to help if someone wanted to design an open-source library to encrypt VoIP packets. This is a project I can't do only by myself because I lack the knowledge to use crypto stuff currectly (random stuff, padding, etc).
I think it would be nice to have such a library so that any VoIP application writer can easily integrate the crypto functionality.
Touch screen voting was used in a State House election that was won by twelve votes. Unfortunately, there were 134 people who went through the process of checking in to vote, but either did not vote or cast a vote that was not counted.
Assuming 50-50 vote distribution (i.e. very close), the 1 standard deviation uncertainty for 134 votes is actually 12 votes (sqrt(134)=11.576). This means that assuming 134 votes weren't counted, the current result has a 16% chance of being wrong.
(disclaimer: yes I made a couple other statistical assumptions here, but you get the idea)
Forget about US national security. The real reason for these measures is that someone in the Bush administration has been short-selling airline stocks. There really seem to be a real desire to drive the industry to the ground at all cost.
While I agree that it may take as long, there's also the possibility of a much faster outcome. The way SCO is acting (not giving any evidence), it wouldn't be too suprising to see the case dismissed easly. If they indeed send lame evidence, the case will go on, but everyone will see how lame the thing is and nobody will care about the trial anymore. At that point SCO might as well drop its case since the stock will be down and the bad publicity scheme against Linux will stop working. That's of course the optimistic view, but I still think it's realistic.
So it's not that easy, right? At least not as easy as the one click it takes to get rid of popups. The other non-easy thing is that I still want people to be able to reach me (being the author of a couple OSS packages) and the best way is to leave an address on a web site. So far it's been easier to just use a bayesian filter... hope it'll continue to work (so far, much less than 1% of the spam gets through).
We are scheduled to get rid of pop-up ads right after we deal with SPAM once and for all.
Isn't the problem already solved? I'm using Mozilla (galeon actually) and I'm only reminded popups still exist when I have to use a Windows machine that only has IE (not very often). I may have missed something, but it would seem like the SPAM problem is much further from being solved.
I've first seen that concept around 10 years ago (maybe it existed even before that) in the Hydro Quebec electrical car prototype. They had a 100 hp engine in each wheel. The project finally failed because of political issues and internal fights (too much fame too early). The car was already working, but I think the electrical wheels had some problems: 1) the wheels would heat and 2) the moving parts in the wheel add inertia when turning the wheels.
software fails the same way in controlled instances
That's true... in theory. In practice, there are many ways software can fail in random (in the weak sense) ways. Many of these are related to timing. For example if you have many threads and fail to lock things properly, the result will depend on when the tasks are preempted. You can also have different results because of the way the interrupts (disk, net,...) happen. There's also the not-initialize type of problem where the behaviour depends on whatever was there in memory before. There are probably many other ways for software to fail at random, including obscure combinations of events.
I'd say that the only kind of software that can't fail randomly is single-threaded and doesn't rely on any input other than regular files (and even then I'm not sure it's enough).
You must be able to accept some losses in the name of peace, progress and prosperity.
I think the real problem is losses that could have been prevented. It's easier to accept losses when it's something nobody expected than it is when (for Challenger) the engineers had told you "do not launch" or (for Columbia) "the wings might be damaged, please check before re-entry".
OK, so where do you draw the line? Did anyone who lost money by buying e.g. Enron stocks, deserve it because it was a stupid move? Or maybe those who thought LNUX at $300 was still a good deal?
Well, I settled for 100 Hz because 10 kHz was still causing about 10% overhead. Also, I haven't measured it, but the battery life was probably shorter.
Actually, there's a drawback of using HZ=1000: if you're using a laptop with a bad power supply (like mine), you end up with annoying noise at 1000 Hz when the system is idle. I had to go back to 100 Hz (actually, I tried HZ=1000 but it required changes to the source and the overhead is getting larger).
There's a difference here. Assuming there's stolen code in Linux (which i doubt), if SCO says "we own those lines", there's a chance that all the illegal code will be removed in the next weeks and then nobody will want to approach SCO's code with a 10-foot pole. However, if SCO says "we won't tell you what we own", the code stays in Linux forever. What's the best protection if your code is indeed stolen. Also, it's not like the code in question isn't already released to the public.
Not only does SCO have no case, but I'd bet that even if some of their code was in Linux, the judge could rule that SCO didn't do enough to get the damage repaired (code removed).
I think the minimum requirement for having a contract is a mutual agreement. With the GPL, you usually don't even have a contact with the author and the GPL itself says you do not have to agree to it and makes it clear it's not a contract.
As for SCO, the way I see it is that by releasing Linux under the GPL, they have given everyone a license for that code. I don't think they can back down on that one. Even if it was proven that there was misappropriated code (which I doubt), I think SCO has really given it away.
Slashdot Mirror
There's a strong core of "ham" that is "ham" for everybody, and sooner or later they're going to start abusing that.
Do you have evidence to back that assertion? In my case (I know it's just me), ham basically means either refering to my open-source projects or written in French (even then spambayes does a good job at rejecting French spam).
I don't think spammers are that dumb either. I see four main difficulties for them to overcome bayesian filters:
1) Differences between user's filters (which you said can be overcome because "ham is ham")
2) Lack of "training data" for them We have lots of data from which we can learn how to avoid spam, but they have very little data which they can use to "train" anti-filter techniques.
3) They have to get the main message through. Eventually, if you can detect all forms (that remains to be seen) of the word "Viagra", they simply can't use that word in their email anymore (assuming I've got no ham containing that word).
4) Because each spam message is different, they have to find a cost-effective way to make each of them immune to filters. That's not easy either.
I don't think any legitimate mail contains v|agr@ in it. If some ham was supposed to include a certain word, it would probably be already in my ham training set. I think the main problem is that there are just so many misspellings you can use in spam. Also, spelling "V I A G R A" causes problems because the words are just "V", "I", "A" and so on. That's why I think we'll need to:
1) Start using bigrams (or N-grams)
2) Start assigning a "spam probability" to unknown words or words that contain non-alpha chars.
Microsoft's superior Windows Media Audio
Will it also run on Microsoft's superior operating system so it can benefit from superior crashes and viruses?
Do you consider it "misleading" to label an Athlon running at 1.8GHz as a 2200?
Actually, the equivalent would be AMD selling an Athlon 1.8 labeled as "2.2 GHz". The 2200 is just a model number. You may say that (or the MP/XP) is misleading, but saying 9200 when it's 9000 is simply false. Then, the MP/XP is still fine with me. All the "MP" means is that "we guaranty that it'll work in a multi-processor machine".
Of course, i was just talking about the possibility to detect the steg itself, not the human factor... Even sending 24-bit music and all might sound suspect.
The other important issue is whether the "ennemy" knows what kind of steg you might use. That helps detection a lot.
...reporting any abnormal results (i.e. the presence of steganography). I personally don't think that is feasible...
I think it probably depends on where you hide the data. For instance, it's probably harder to hide data in the LSBs of an image than, e.g. a file that's supposed to be white noise ("Hey, my mic doesn't work, it only records noise. See for yourself"). Of course, the less data you encode, the harder it is to detect it.
Microsoft: *funds suicide bombers*
Israel: *nukes Redmond*
I think your close to the reason. It seems like the companies in the US cover much smaller areas and can set whatever price they want when there's no other company in the area. If you look at Quebec (7M people), you've got one DSL provider (Bell Canada) and one (major) cable company (Videotron). Now, since they can't really change their rates according to the region (they'd get crucified), they have to compete against each other. Now even if in your region all you have is DSL, you still benefit the competition.
Isn't SSL designed for a streaming connection? In the case of VoIP, you need to have lots of small (10-40 bytes) chunks encrypted intependently (because some may get lost), so it's completely different than a TCP connection.
Seriously, I'm the author of Speex (the speech codec) and I'd be willing to help if someone wanted to design an open-source library to encrypt VoIP packets. This is a project I can't do only by myself because I lack the knowledge to use crypto stuff currectly (random stuff, padding, etc).
I think it would be nice to have such a library so that any VoIP application writer can easily integrate the crypto functionality.
Touch screen voting was used in a State House election that was won by twelve votes. Unfortunately, there were 134 people who went through the process of checking in to vote, but either did not vote or cast a vote that was not counted.
Assuming 50-50 vote distribution (i.e. very close), the 1 standard deviation uncertainty for 134 votes is actually 12 votes (sqrt(134)=11.576). This means that assuming 134 votes weren't counted, the current result has a 16% chance of being wrong.
(disclaimer: yes I made a couple other statistical assumptions here, but you get the idea)
...before I even heard of the feature itself.
Forget about US national security. The real reason for these measures is that someone in the Bush administration has been short-selling airline stocks. There really seem to be a real desire to drive the industry to the ground at all cost.
I immediately replied 5-10 years.
While I agree that it may take as long, there's also the possibility of a much faster outcome. The way SCO is acting (not giving any evidence), it wouldn't be too suprising to see the case dismissed easly. If they indeed send lame evidence, the case will go on, but everyone will see how lame the thing is and nobody will care about the trial anymore. At that point SCO might as well drop its case since the stock will be down and the bad publicity scheme against Linux will stop working. That's of course the optimistic view, but I still think it's realistic.
So it's not that easy, right? At least not as easy as the one click it takes to get rid of popups. The other non-easy thing is that I still want people to be able to reach me (being the author of a couple OSS packages) and the best way is to leave an address on a web site. So far it's been easier to just use a bayesian filter... hope it'll continue to work (so far, much less than 1% of the spam gets through).
We are scheduled to get rid of pop-up ads right after we deal with SPAM once and for all.
Isn't the problem already solved? I'm using Mozilla (galeon actually) and I'm only reminded popups still exist when I have to use a Windows machine that only has IE (not very often). I may have missed something, but it would seem like the SPAM problem is much further from being solved.
I've first seen that concept around 10 years ago (maybe it existed even before that) in the Hydro Quebec electrical car prototype. They had a 100 hp engine in each wheel. The project finally failed because of political issues and internal fights (too much fame too early). The car was already working, but I think the electrical wheels had some problems: 1) the wheels would heat and 2) the moving parts in the wheel add inertia when turning the wheels.
software fails the same way in controlled instances
...) happen. There's also the not-initialize type of problem where the behaviour depends on whatever was there in memory before. There are probably many other ways for software to fail at random, including obscure combinations of events.
That's true... in theory. In practice, there are many ways software can fail in random (in the weak sense) ways. Many of these are related to timing. For example if you have many threads and fail to lock things properly, the result will depend on when the tasks are preempted. You can also have different results because of the way the interrupts (disk, net,
I'd say that the only kind of software that can't fail randomly is single-threaded and doesn't rely on any input other than regular files (and even then I'm not sure it's enough).
You must be able to accept some losses in the name of peace, progress and prosperity.
I think the real problem is losses that could have been prevented. It's easier to accept losses when it's something nobody expected than it is when (for Challenger) the engineers had told you "do not launch" or (for Columbia) "the wings might be damaged, please check before re-entry".
OK, so where do you draw the line? Did anyone who lost money by buying e.g. Enron stocks, deserve it because it was a stupid move? Or maybe those who thought LNUX at $300 was still a good deal?
Well, I settled for 100 Hz because 10 kHz was still causing about 10% overhead. Also, I haven't measured it, but the battery life was probably shorter.
I know, that's the patch I sent :)
Actually, there's a drawback of using HZ=1000: if you're using a laptop with a bad power supply (like mine), you end up with annoying noise at 1000 Hz when the system is idle. I had to go back to 100 Hz (actually, I tried HZ=1000 but it required changes to the source and the overhead is getting larger).
There's a difference here. Assuming there's stolen code in Linux (which i doubt), if SCO says "we own those lines", there's a chance that all the illegal code will be removed in the next weeks and then nobody will want to approach SCO's code with a 10-foot pole. However, if SCO says "we won't tell you what we own", the code stays in Linux forever. What's the best protection if your code is indeed stolen. Also, it's not like the code in question isn't already released to the public.
Not only does SCO have no case, but I'd bet that even if some of their code was in Linux, the judge could rule that SCO didn't do enough to get the damage repaired (code removed).
I think the minimum requirement for having a contract is a mutual agreement. With the GPL, you usually don't even have a contact with the author and the GPL itself says you do not have to agree to it and makes it clear it's not a contract.
As for SCO, the way I see it is that by releasing Linux under the GPL, they have given everyone a license for that code. I don't think they can back down on that one. Even if it was proven that there was misappropriated code (which I doubt), I think SCO has really given it away.