Re:$5 to anyone who proves this statement wrong-
on
The Economics of Spam
·
· Score: 2
open proxies
How much spam would we get rid of if there were no open proxies to abuse? I don't know, but it would be a lot I guess. Unfortunately that is more than we can possibly hope for, there are too many persons out there not capable of administrating a system properly.
But I do what I can to fight against the spam. I have installed an SMTP honeypot, and when they probe me for open relays, I will relay by hand. When they finally start trying to abuse my computer as open relay, it acts as a black hole. 50 000 000 spam mails have ended their life that way. Imagine how much spam we could get rid of if every slashdot reader would just receive and delete a few million spam mails.
In case anyone is interested, the source is here with slightly humorous responses.
smtphoneypot.c
We should only go to 3 if the new kernel breaks binary compatability with 2.4/2.5.
First of all make that if it breaks binary compatability with 2.4, because if binary compatibility is not preserved between 2.4 and the latest 2.5 kernel, there will be lot of incompatibilities within the 2.5 series as well. And what happened during the development is not what we want to talk about anyway.
But what do you have in mind, when talking about binary compatibility? AFAIK Linus does consider binary compatibility on the kernel/user mode interface to be important. Deprecated interfaces might be removed at some time, but before that it might even have produced warnings for some time if any programs used it.
When I upgraded from 2.2 to 2.4 binary compatibility was preserved (mostly), I did not replace any libraries or executables because of the kernel change. But I did find a few problems: rpc.rstatd would core dump on the first request, because of a change of the format of a/proc pseudofile. And ktop sundenly thought every process on the system was owned by root. Does this count as binary incompatibility?
I don't know how many interfaces changed between 1.2 and 2.0, I never used 1.2 my first kernel was 2.2. But I know that the reasons for Linus to choose 2.0 as version number was primarily the addition of SMP and portability to different platforms. Yet it might have remained binary compatible with 1.2. I suspect the executable format used by 1.2 was aout while today all executables are ELF. But kernels still have optional support for aout binaries. But actually I think even ELF support is optional, so I could build two 2.4 kernels with one supporting aout and the other supporting ELF, they will be same version number but obviously binary incompatible.
Don't expect any Linux kernel in the future to introduce major binary incompatibilities with your previous kernel. There will be changes, but they will be slow, so most executables will be usable across three or more kernel releases. It shouldn't be hard to find an executable working on 2.0, 2.2, 2.4, and the latest 2.5.
I don't think the 2.6 vs. 3.0 debate is over yet. But it seems to be quiet right now. I think the discussion will live up when the release date starts getting close about a year from now. And I even think there will be discussion after the release, because the version number come as a complete surprise to some people. And I will not try to guess how much doubt will be in Linus mind once he actually wants to release the thing.
But if you want to be unambigious when talking about it, you should call it 2.6. If it turns out not to be the case everybody will know that it was indeed 3.0 you were talking about. But if you talk about 3.0 already now, and it turns out to be called 2.6, then 3.0 might be something else released in the future.
Oops, you just made me notice I made a mistake. Once I used the word CD inapropriately. I said: "I will return the CD", which should have been "I will return the disc", because it is technically not a CD.
IIRC they're a mishmash of six or seven unix variants running on five different hardware platforms.
That sounds like a good choice. Running different hardware and software combinations should make them less prone to a single bug allowing a DoS attack.
three times the measured peak of such requests on the most loaded server
Does that actually mean, that the root servers are not designed such that a single can serve the entire net if needed?
So they say they are the dot in dot com, but they should really say they are the dot in dot com dot, because they are really the dot after com not the dot before com. However this last dot is often forgotten, it really means the name is absolute rather than relative. This is very much like the leading slash in paths to files.
Hmm, now I'm writing on slashdot about leading slashes and trailing dots, what a coincidence.
This just got me thinking about an idea that I might be using in the future. First of all if it is not stateted clearly on the cover that it is a CD, I will ask shop assistant if it is a CD, and if she says yes I will buy it. First thing to do when I come home is make a copy (that is actually legal where I live). If it fails I will return the CD and require them to return my money, because what they sold me does not apear to be a CD.
How would you ever find out about that? Look for the referer field in the weblogs? With the number of servers deliberately discriminating users of nonMS browsers you cannot expect refer fields to be true. Here is the last page I came across which plain refuses to be shown in any browser but IE.
Why could they even get additional bandwidth by changing their modem? If the provider wants to impose a limit, that should be done in their own hardware in their own end of the connection. If the system had been designed with this in mind, there wouldn't have been a case.
So they got it wrong when implementing the thing. There should be a cable on the receiver which you can connect to the keyboard for keyexchange. Just plug in the cable and wait a few seconds, when you disconnect the cable again you will know that now this keyboard will be sending only to this single receiver, and this receiver will be accepting input from only this single keyboard. There is no need to limit the key to 8 bits, I'd choose 256 bit AES if I was the one to design a wireless keyboard.
Or even better, whenever I don't use my wireless keyboard or mouse, I want to place it in the recharger connected to the receiver. Every time I need it, it will be fully charged and using a new random key.
The missing driver problem sounds like bullshit to me. Wireless keyboard should be transparent to the driver.
Yes. IIRC IPSec originated as a part of the IPv6 specification. Since then it has been backported to IPv4. This is a little unfortunate because that might actually slow down the transition from IPv4 to IPv6. Had IPv6 been a requirement to use IPSec, we might have seen IPv6 getting adopted a little faster.
Absolutely not. Making large memories matching the speed of the CPU is not feasible. If you want the speed of the memory to match the CPU speed, it has to be smaller. Since most modern systems uses paging/swapping, a smaller memory will cause more trashing on the disk and result in a slower system.
Instead of having to make one choice between speed and size, we have multiple levels of caches with different choices of speed and size. This actually gives a performance improvement. The remaining problem obviously is, that not all software was written with this in mind. Software actually written with the speed difference between L1 cache and swap file in mind can be 100 000 times faster than software not keeping this in mind.
However designing an algorithm for the number of different levels in a modern system is not feasible. There would be far too many parameters, and you couldn't optimize your algorithm for all of them. Instead what is needed in the future is cache oblivious algorithms, that will be efficient on one level without knowing the actual size of the cache and cachelines. The advantage is that since the efficiency is independend of the sizes, it will be efficient on all the levels at the same time. As data grows such an algorithm will become faster than any other algorithm.
The next step as cache oblivious algorithms are becoming more common is to design architectures with cache levels optimized for cache oblivious algorithms.
The "hacker's" own version of the story is here.
The report written to "datatilsynet" by a security expert is here. And the response is here.
The case has been discussed on usenet in the two groups dk.edb.sikkerhed and dk.videnskab.jura, and on the discussion forum related to a weekly computer newspaper. But all of this is in Danish, I don't think much has been written in other languages about this case.
How is KMail supposed to know if it is safe to "run" the attachment?
How is KMail supposed to know how to "run" the attachment?
It is two different questions, but the answer is the same. You give KMail a list of filetypes, and tell it what to do with them. The list could contain a flag specifying dangerous filetypes. If that feature does not exist in KMail, the filetype should be ommited from the list.
To me this sounds like a bug in the configuration rather than the software. And it does sound like a configuration mistake in the default install of this distribution.
Slashdot Mirror
open proxies
How much spam would we get rid of if there were no open proxies to abuse? I don't know, but it would be a lot I guess. Unfortunately that is more than we can possibly hope for, there are too many persons out there not capable of administrating a system properly.
But I do what I can to fight against the spam. I have installed an SMTP honeypot, and when they probe me for open relays, I will relay by hand. When they finally start trying to abuse my computer as open relay, it acts as a black hole. 50 000 000 spam mails have ended their life that way. Imagine how much spam we could get rid of if every slashdot reader would just receive and delete a few million spam mails.
In case anyone is interested, the source is here with slightly humorous responses. smtphoneypot.c
[Insert the obligatory joke about /. slashdotting this server too] :)
Seriously if a lot of people modified the trojan to connect and find out what the cracker is up to, we might find out some interesting stuff.
I wank 100 times a day
What do you do the rest of the day?
We should only go to 3 if the new kernel breaks binary compatability with 2.4/2.5.
/proc pseudofile. And ktop sundenly thought every process on the system was owned by root. Does this count as binary incompatibility?
First of all make that if it breaks binary compatability with 2.4, because if binary compatibility is not preserved between 2.4 and the latest 2.5 kernel, there will be lot of incompatibilities within the 2.5 series as well. And what happened during the development is not what we want to talk about anyway.
But what do you have in mind, when talking about binary compatibility? AFAIK Linus does consider binary compatibility on the kernel/user mode interface to be important. Deprecated interfaces might be removed at some time, but before that it might even have produced warnings for some time if any programs used it.
When I upgraded from 2.2 to 2.4 binary compatibility was preserved (mostly), I did not replace any libraries or executables because of the kernel change. But I did find a few problems: rpc.rstatd would core dump on the first request, because of a change of the format of a
I don't know how many interfaces changed between 1.2 and 2.0, I never used 1.2 my first kernel was 2.2. But I know that the reasons for Linus to choose 2.0 as version number was primarily the addition of SMP and portability to different platforms. Yet it might have remained binary compatible with 1.2. I suspect the executable format used by 1.2 was aout while today all executables are ELF. But kernels still have optional support for aout binaries. But actually I think even ELF support is optional, so I could build two 2.4 kernels with one supporting aout and the other supporting ELF, they will be same version number but obviously binary incompatible.
Don't expect any Linux kernel in the future to introduce major binary incompatibilities with your previous kernel. There will be changes, but they will be slow, so most executables will be usable across three or more kernel releases. It shouldn't be hard to find an executable working on 2.0, 2.2, 2.4, and the latest 2.5.
Wheren't we going to go straight to 3.0?
I don't think the 2.6 vs. 3.0 debate is over yet. But it seems to be quiet right now. I think the discussion will live up when the release date starts getting close about a year from now. And I even think there will be discussion after the release, because the version number come as a complete surprise to some people. And I will not try to guess how much doubt will be in Linus mind once he actually wants to release the thing.
But if you want to be unambigious when talking about it, you should call it 2.6. If it turns out not to be the case everybody will know that it was indeed 3.0 you were talking about. But if you talk about 3.0 already now, and it turns out to be called 2.6, then 3.0 might be something else released in the future.
Is the site slashdotted already or did somebody finally DoS the DNS system? The host www.socallinuxexpo.com in the link cannot be resolved.
they refuse to call the copy protected disc a CD
Oops, you just made me notice I made a mistake. Once I used the word CD inapropriately. I said: "I will return the CD", which should have been "I will return the disc", because it is technically not a CD.
Screw the IP change
./
No, screw those chicks. This is
IIRC they're a mishmash of six or seven unix variants running on five different hardware platforms.
That sounds like a good choice. Running different hardware and software combinations should make them less prone to a single bug allowing a DoS attack.
three times the measured peak of such requests on the most loaded server
Does that actually mean, that the root servers are not designed such that a single can serve the entire net if needed?
So they say they are the dot in dot com, but they should really say they are the dot in dot com dot, because they are really the dot after com not the dot before com. However this last dot is often forgotten, it really means the name is absolute rather than relative. This is very much like the leading slash in paths to files.
Hmm, now I'm writing on slashdot about leading slashes and trailing dots, what a coincidence.
This just got me thinking about an idea that I might be using in the future. First of all if it is not stateted clearly on the cover that it is a CD, I will ask shop assistant if it is a CD, and if she says yes I will buy it. First thing to do when I come home is make a copy (that is actually legal where I live). If it fails I will return the CD and require them to return my money, because what they sold me does not apear to be a CD.
but you CAN prove we didn't go there.
How?
Those are a lot of threads, displayed by a ps that doesn't grok threads
It could be running on Linux where a thread and a process is essentially the same thing.
and the Swedish :)
Don't forget Norwegian!
I should have mentioned that, but I was not 100% sure.
HALF SPEED in battery mode.
My old 33MHz laptop goes down to quarter speed when running on battery.
if I said PPS, who would understand it?
I would not, btw what is USPS?
The receiving OS would throw this packet away and send an ICMP error back
Not if it was programmed not to do so.
Vi is a word in several languages.
Yes, as an example "vi" happens to be the danish word for "we".
But what browser is the most common?
How would you ever find out about that? Look for the referer field in the weblogs? With the number of servers deliberately discriminating users of nonMS browsers you cannot expect refer fields to be true. Here is the last page I came across which plain refuses to be shown in any browser but IE.
Why could they even get additional bandwidth by changing their modem? If the provider wants to impose a limit, that should be done in their own hardware in their own end of the connection. If the system had been designed with this in mind, there wouldn't have been a case.
So they got it wrong when implementing the thing. There should be a cable on the receiver which you can connect to the keyboard for keyexchange. Just plug in the cable and wait a few seconds, when you disconnect the cable again you will know that now this keyboard will be sending only to this single receiver, and this receiver will be accepting input from only this single keyboard. There is no need to limit the key to 8 bits, I'd choose 256 bit AES if I was the one to design a wireless keyboard.
Or even better, whenever I don't use my wireless keyboard or mouse, I want to place it in the recharger connected to the receiver. Every time I need it, it will be fully charged and using a new random key.
The missing driver problem sounds like bullshit to me. Wireless keyboard should be transparent to the driver.
Yes. IIRC IPSec originated as a part of the IPv6 specification. Since then it has been backported to IPv4. This is a little unfortunate because that might actually slow down the transition from IPv4 to IPv6. Had IPv6 been a requirement to use IPSec, we might have seen IPv6 getting adopted a little faster.
Ultimately, caches are a hack
Absolutely not. Making large memories matching the speed of the CPU is not feasible. If you want the speed of the memory to match the CPU speed, it has to be smaller. Since most modern systems uses paging/swapping, a smaller memory will cause more trashing on the disk and result in a slower system.
Instead of having to make one choice between speed and size, we have multiple levels of caches with different choices of speed and size. This actually gives a performance improvement. The remaining problem obviously is, that not all software was written with this in mind. Software actually written with the speed difference between L1 cache and swap file in mind can be 100 000 times faster than software not keeping this in mind.
However designing an algorithm for the number of different levels in a modern system is not feasible. There would be far too many parameters, and you couldn't optimize your algorithm for all of them. Instead what is needed in the future is cache oblivious algorithms, that will be efficient on one level without knowing the actual size of the cache and cachelines. The advantage is that since the efficiency is independend of the sizes, it will be efficient on all the levels at the same time. As data grows such an algorithm will become faster than any other algorithm.
The next step as cache oblivious algorithms are becoming more common is to design architectures with cache levels optimized for cache oblivious algorithms.
The "hacker's" own version of the story is here. The report written to "datatilsynet" by a security expert is here. And the response is here. The case has been discussed on usenet in the two groups dk.edb.sikkerhed and dk.videnskab.jura, and on the discussion forum related to a weekly computer newspaper. But all of this is in Danish, I don't think much has been written in other languages about this case.
- How is KMail supposed to know if it is safe to "run" the attachment?
- How is KMail supposed to know how to "run" the attachment?
It is two different questions, but the answer is the same. You give KMail a list of filetypes, and tell it what to do with them. The list could contain a flag specifying dangerous filetypes. If that feature does not exist in KMail, the filetype should be ommited from the list.To me this sounds like a bug in the configuration rather than the software. And it does sound like a configuration mistake in the default install of this distribution.