Your mail to feedback@suse.de
- (deutsche Version unten) Dear SuSE Linux User, thank you for your message regarding hello. Please note that the email address you sent your message to ([EMAIL PROTECTED]) is no longer in use. Of course you still can send us your ideas, comments and bug reports related to our products! Please use our web pages: http://www.suse.de/feedback If you need support please contact our installation support [EMAIL PROTECTED], if you have a valid registration code or consult our support database at http://sdb.suse.de/sdb/en/html/ Thank you for your interest in SuSE Linux! - Sehr geehrter SuSE Linux-Benutzer, vielen Dank für Ihre Nachricht betreffs hello. Bitte beachten Sie, dass die von Ihnen verwendete Emailadresse ([EMAIL PROTECTED]) nicht mehr verwendet wird. Natürlich können Sie uns auch weiterhin Ihre Anregungen, Fehlermeldungen oder Verbesserungsvorschläge zusenden. Wir haben für Sie ein Webformular eingerichtet unter http://www.suse.de/feedback Falls Sie Unterstützung benötigen, wenden Sie sich bitte an unseren Installationssupport [EMAIL PROTECTED] oder konsultieren Sie unsere Supportdatenbank unter: http://sdb.suse.de/ Vielen Dank für Ihr Interesse an SuSE Linux! Ihr SuSE Linux Feedback Team -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Thank you for your interest in The Breakwaters.
Thank you for your interest in The Breakwaters. To inquire about availability or to make a reservationplease contact James Madru @ 508-775-6831. I will be happy to answer any questions you might have about the Breakwaters. Best regards James Madru -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Still Considering Debian - But Stuck!
Fred Whipple wrote: Hi Everyone, A while back I asked for some feedback and got a very rich set of info from folks about Debian used in a stable ISP environment as compared to other OS's and distributions. All the info was very helpful and helped us further solidify our desire (though not yet decision) to make Debian our platform as we move forward. We've run into a couple rather HUGE issues, though, that I'd like to get further feedback on. Not that I couldn't figure it all out for myself, but nothing beats someone else's experience when it comes to saving me the time and heartache ;-) Just about everyone warned me that the stable Debian distribution would be old and well tested/maintained, but I'm not sure I was prepared for just HOW old... Our company uses Java --- a LOT of Java. We therefore use a lot of threads, and a lot of threads. And a whole mess of threads, too. Under Red Hat 7.3, we found that when the system had a total of say, 10,000 PID's given out (nearly all of them to threads) the system would become very unstable. When we moved to Red Hat 9 for the affected systems, which includes the new 0(1) scheduler, and either a different kind of thread support in either the kernel or GlibC, this problem went away. I'm honestly not sure who is responsible for the way threads are handled, and I suspect it's not exclusively the kernel, but under RH9 each JVM (or any app with threads) gets a single PID as normal and all very strange behavior that we saw under RH7.3 disappears. I see that Debian 3.0r2 includes a nicely aged (like fine cheese) Linux 2.2 kernel. While I'm certain the aging process only makes its flavour stronger and more delectable, I'm afraid it's going to choke at the thought of 10,000 threads. Say nothing of 20,000. Now I imagine it's not so difficult to simply compile a recent 2.4 (2.5?) kernel and go from there. Is this fair? Or would you suppose that the current stable Debian is too old in other areas to properly handle kernel 2.4? Even if I replace the kernel, I'm concerned that there's more involved with the more efficient handling of threads from RH 7.3 to RH 9 than just a kernel change -- I have to think there was a significant rework of some libraries that made threads more efficient under RH9 as well. Would anyone be able to identify exactly what that re-working was, and conjecture if they think it can be done under 3.0r2? For that matter, would I at that point be running so much new technology that I may as well be running an unstable distribution of Debian? Finally, while I'm messing around with the kernel, I'd have to include support for ext3fs. In our environment, journaling is not an option, it's a base requirement. Of course replacing the kernel would pretty much give me kernel-level support for it. From that point, how complicated is it to get the rest of the tools to play nicely with ext3fs? I'd imagine that a large set of tools would need to be replaced, including e2fsck, mount, umount, etc. Thanks once again for all the info so far! -Fred Whipple The kernel can be made to support as many processes as you would like. Install a custom kernel http://sohd.suffolk.lib.ny.us/docs/debkern/debkern.htm. For ext3 support simply from a root prompt type tune2fs -j /dev/sda1 for the first scsi partition on the first scsi disk. I have never tried to support 1 processes on one box however: I use a linux virtual server cluster. http://www.linuxvirtualserver.org/ hope this helps bye for now syl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Still Considering Debian - But Stuck!
I don't have a footnote, but I believe a recent linux journal article says that the 2.6 kernel uses a posix threads library which are much nicer than linux threads and that redhat has backported this support to RH9 and the 2.4 kernel. It should be possible to DL the redhat 2.4 patches While this is true, it's only half of the issue. The other half (as others have mentioned) is glibc 2.3. Later, Dale -- Dale E. Martin, Clifton Labs, Inc. Senior Computer Engineer [EMAIL PROTECTED] http://www.cliftonlabs.com pgp key available -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
type in Jesus Help me and see that your business comes up
Hello. Type in "Jesus Help Me" and see what happens.
Re: I/O performance issues on 2.4.23 SMP system
Thanks to all who sent comments on this. I did some more testing and went straight to the source for input. snip if you want to try the 4G patch then i'd suggest Andrew Morton's -mm tree, which has it included: http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.2-rc2/2.6.2-rc2-mm2/ i've got a 2.4 backport too, included in RHEL3. (the SRPM is downloadable.) But extracting the patch from this srpm will likely not apply to a vanilla 2.4 tree - there are lots of other patches as well and interdependencies. So i'd suggest the RHEL3 kernel as-is, or the -mm tree in 2.6. Ingo /snip Of course, as newer kernels are released, Andrew releases newer -mm patches. This patch set solved the I/O problem and let me use 4GB RAM. Mark Ferlatte wrote: Daniel Erat said on Thu, Jan 29, 2004 at 08:08:49AM -0800: I was the poster who initiated the previous thread on this subject. The problem disappeared here after we went down to 2 GB of memory (although we physically removed it from the server rather than passing the arg to the kernel... shouldn't make a difference though, I'd imagine). We went straight from 4 GB to 2 GB, so I can't comment on the results of using 3 GB. Our problem didn't seem to directly correspond with the 1 GB threshold -- it wouldn't manifest itself until the server had allocated all 4 GB of RAM. After a reboot, it would be nice and speedy again for a day or two until all the memory was being used for buffering again. This was the behavior I saw as well. I did a bunch of research and source reading before actually figuring out what was going on; it wasn't a well documented bug for some reason... I guess there aren't that many people running large boxes using 2.4. This makes me think that the problems I saw with 2GB were not related to the IO subsystem, but were something else. Time to go play around a bit; getting those boxes up to 2GB without having to do a kernel patch/upgrade cycle would be nice. M -- Benjamin Sherman Software Developer Iowa Interactive, Inc 515-323-3468 x14 [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: I/O performance issues on 2.4.23 SMP system
I was the poster who initiated the previous thread on this subject. The problem disappeared here after we went down to 2 GB of memory (although we physically removed it from the server rather than passing the arg to the kernel... shouldn't make a difference though, I'd imagine). We went straight from 4 GB to 2 GB, so I can't comment on the results of using 3 GB. The above comment sounds a lot like a bounce buffer issue. This is not an IO issue. Bounce Buffer issues look a like like IO problems on the surface. However, the IO bus will get a messy from having to much memory feeding it. Bounce Buffer issues can occur anytime you use over 2GB of RAM on a 32bit system. I have a Dual SMP Xeon 700 (32 bit) with 10GB of RAM in it. It is under a 10-20% CPU load daily. Originally, I had a bounce buffer problem that occurred during backups and heavy IO loads. The output from sar, system activity report, told me that process switches were not recovering after backups. IO loads would 'snowball' after backups. Generally, the whole system seemed to get overwhelmed and unstable after a heavy IO event, like a backup. I found this strange. Since the patch has been applied the server has been running very stable for over 43 days. I fixed the problem with following: This Bounce Buffer problem was resolved with the 00_block-highmem-all-18b-3 patch. http://www.kernel.org/pub/linux/kernel/people/andrea For example, the following sar output shows a normal recovery after a heavy IO event: 22:30:01 all83 089 1302172 0.35 0.33 0.35 074 090 183 088 - backup started #rsync 100GB RAID 5 Array 23:40:01 all3 14 18261731166 1.44 1.46 1.52 00:00:02 cpu %usr %sys %nice %idle pswch/s runq nrproc lavg1 lavg5 avg15 _cpu_ 00:10:01 all3 14 18256793166 1.62 1.56 1.53 03 13 183 13 15 181 00:20:01 all4 14 18260683156 1.45 1.46 1.46 03 14 182 14 14 181 00:30:01 all2 13 18355855161 1.10 1.16 1.29 03 13 184 12 14 183 00:40:01 all38 18831912146 0.12 0.63 1.01 038 188 138 188 00:50:01 all33 095 863139 0.15 0.23 0.60 - sync finished If you sar output does not look like this after a backup, and you have more than 2GB of RAM something is probably going on with a buffer. You can fix it two ways, upgrade to a 64Bit machine or patch your kernel with the block-highmem patch written by Andrea. My Kernel: 2.4.18 image=/boot/vmlinuz-2.4.18 #Compiled using GCC-2.95 on new IMAP server #Debian 2.4.18 Kernel package #Debian 2.4.18 xfs kernel patch #block-highmemory patch from http://www.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/ #00_block-highmem-all-18b-3 #HIMEM Kernel Support to 64GB #HIMEME IO Support added label=LinuxHIMEM read-only My Hardware: 00:00.0 Host bridge: ServerWorks CNB20HE Host Bridge (rev 21) 00:00.1 Host bridge: ServerWorks CNB20HE Host Bridge (rev 01) 00:00.2 Host bridge: ServerWorks: Unknown device 0006 00:00.3 Host bridge: ServerWorks: Unknown device 0006 00:01.0 SCSI storage controller: Adaptec 7896 00:01.1 SCSI storage controller: Adaptec 7896 00:05.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet LANCE] (rev 44) 00:06.0 VGA compatible controller: S3 Inc. Trio 64 3D (rev 01) 00:0f.0 ISA bridge: ServerWorks OSB4 South Bridge (rev 4f) 00:0f.1 IDE interface: ServerWorks OSB4 IDE Controller 00:0f.2 USB Controller: ServerWorks OSB4/CSB5 OHCI USB Controller (rev 04) 01:01.0 RAID bus controller: IBM Netfinity ServeRAID controller 01:02.0 RAID bus controller: IBM Netfinity ServeRAID controller 02:06.0 Ethernet controller: Intel Corp. 82557 [Ethernet Pro 100] (rev 0c) On 03/02/04 13:25 -0600, Benjamin Sherman wrote: Thanks to all who sent comments on this. I did some more testing and went straight to the source for input. snip if you want to try the 4G patch then i'd suggest Andrew Morton's -mm tree, which has it included: http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.2-rc2/2.6.2-rc2-mm2/ i've got a 2.4 backport too, included in RHEL3. (the SRPM is downloadable.) But extracting the patch from this srpm will likely not apply to a vanilla 2.4 tree - there are lots of other patches as well and interdependencies. So i'd suggest the RHEL3 kernel as-is, or the -mm tree in 2.6. Ingo /snip Of course, as newer kernels are released, Andrew releases newer -mm patches. This patch set solved the I/O problem and let me use 4GB RAM. Mark Ferlatte wrote: Daniel Erat said on Thu, Jan 29,
Image::Magick and Movable Type
Does anyone know of a way to get Movable Type to detect that Image::Magick is installed? I've installed the perlmagick package, but MT still refuses to believe it's there, which is stopping me from making funky thumbnails for images I upload. When replying, please bare in mind that I know next to nothing about Perl - I couldn't even work out how to use CPAN under Debian.
Your mail to feedback@suse.de
- (deutsche Version unten) Dear SuSE Linux User, thank you for your message regarding hello. Please note that the email address you sent your message to ([EMAIL PROTECTED]) is no longer in use. Of course you still can send us your ideas, comments and bug reports related to our products! Please use our web pages: http://www.suse.de/feedback If you need support please contact our installation support [EMAIL PROTECTED], if you have a valid registration code or consult our support database at http://sdb.suse.de/sdb/en/html/ Thank you for your interest in SuSE Linux! - Sehr geehrter SuSE Linux-Benutzer, vielen Dank für Ihre Nachricht betreffs hello. Bitte beachten Sie, dass die von Ihnen verwendete Emailadresse ([EMAIL PROTECTED]) nicht mehr verwendet wird. Natürlich können Sie uns auch weiterhin Ihre Anregungen, Fehlermeldungen oder Verbesserungsvorschläge zusenden. Wir haben für Sie ein Webformular eingerichtet unter http://www.suse.de/feedback Falls Sie Unterstützung benötigen, wenden Sie sich bitte an unseren Installationssupport [EMAIL PROTECTED] oder konsultieren Sie unsere Supportdatenbank unter: http://sdb.suse.de/ Vielen Dank für Ihr Interesse an SuSE Linux! Ihr SuSE Linux Feedback Team
Thank you for your interest in The Breakwaters.
Thank you for your interest in The Breakwaters. To inquire about availability or to make a reservationplease contact James Madru @ 508-775-6831. I will be happy to answer any questions you might have about the Breakwaters. Best regards James Madru
Re: Still Considering Debian - But Stuck!
Fred Whipple wrote: Hi Everyone, A while back I asked for some feedback and got a very rich set of info from folks about Debian used in a stable ISP environment as compared to other OS's and distributions. All the info was very helpful and helped us further solidify our desire (though not yet decision) to make Debian our platform as we move forward. We've run into a couple rather HUGE issues, though, that I'd like to get further feedback on. Not that I couldn't figure it all out for myself, but nothing beats someone else's experience when it comes to saving me the time and heartache ;-) Just about everyone warned me that the stable Debian distribution would be old and well tested/maintained, but I'm not sure I was prepared for just HOW old... Our company uses Java --- a LOT of Java. We therefore use a lot of threads, and a lot of threads. And a whole mess of threads, too. Under Red Hat 7.3, we found that when the system had a total of say, 10,000 PID's given out (nearly all of them to threads) the system would become very unstable. When we moved to Red Hat 9 for the affected systems, which includes the new 0(1) scheduler, and either a different kind of thread support in either the kernel or GlibC, this problem went away. I'm honestly not sure who is responsible for the way threads are handled, and I suspect it's not exclusively the kernel, but under RH9 each JVM (or any app with threads) gets a single PID as normal and all very strange behavior that we saw under RH7.3 disappears. I see that Debian 3.0r2 includes a nicely aged (like fine cheese) Linux 2.2 kernel. While I'm certain the aging process only makes its flavour stronger and more delectable, I'm afraid it's going to choke at the thought of 10,000 threads. Say nothing of 20,000. Now I imagine it's not so difficult to simply compile a recent 2.4 (2.5?) kernel and go from there. Is this fair? Or would you suppose that the current stable Debian is too old in other areas to properly handle kernel 2.4? Even if I replace the kernel, I'm concerned that there's more involved with the more efficient handling of threads from RH 7.3 to RH 9 than just a kernel change -- I have to think there was a significant rework of some libraries that made threads more efficient under RH9 as well. Would anyone be able to identify exactly what that re-working was, and conjecture if they think it can be done under 3.0r2? For that matter, would I at that point be running so much new technology that I may as well be running an unstable distribution of Debian? Finally, while I'm messing around with the kernel, I'd have to include support for ext3fs. In our environment, journaling is not an option, it's a base requirement. Of course replacing the kernel would pretty much give me kernel-level support for it. From that point, how complicated is it to get the rest of the tools to play nicely with ext3fs? I'd imagine that a large set of tools would need to be replaced, including e2fsck, mount, umount, etc. Thanks once again for all the info so far! -Fred Whipple The kernel can be made to support as many processes as you would like. Install a custom kernel http://sohd.suffolk.lib.ny.us/docs/debkern/debkern.htm. For ext3 support simply from a root prompt type tune2fs -j /dev/sda1 for the first scsi partition on the first scsi disk. I have never tried to support 1 processes on one box however: I use a linux virtual server cluster. http://www.linuxvirtualserver.org/ hope this helps bye for now syl
Re: Still Considering Debian - But Stuck!
I don't have a footnote, but I believe a recent linux journal article says that the 2.6 kernel uses a posix threads library which are much nicer than linux threads and that redhat has backported this support to RH9 and the 2.4 kernel. It should be possible to DL the redhat 2.4 patches While this is true, it's only half of the issue. The other half (as others have mentioned) is glibc 2.3. Later, Dale -- Dale E. Martin, Clifton Labs, Inc. Senior Computer Engineer [EMAIL PROTECTED] http://www.cliftonlabs.com pgp key available
type in Jesus Help me and see that your business comes up
Hello. Type in "Jesus Help Me" and see what happens.
Re: I/O performance issues on 2.4.23 SMP system
Thanks to all who sent comments on this. I did some more testing and went straight to the source for input. snip if you want to try the 4G patch then i'd suggest Andrew Morton's -mm tree, which has it included: http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.2-rc2/2.6.2-rc2-mm2/ i've got a 2.4 backport too, included in RHEL3. (the SRPM is downloadable.) But extracting the patch from this srpm will likely not apply to a vanilla 2.4 tree - there are lots of other patches as well and interdependencies. So i'd suggest the RHEL3 kernel as-is, or the -mm tree in 2.6. Ingo /snip Of course, as newer kernels are released, Andrew releases newer -mm patches. This patch set solved the I/O problem and let me use 4GB RAM. Mark Ferlatte wrote: Daniel Erat said on Thu, Jan 29, 2004 at 08:08:49AM -0800: I was the poster who initiated the previous thread on this subject. The problem disappeared here after we went down to 2 GB of memory (although we physically removed it from the server rather than passing the arg to the kernel... shouldn't make a difference though, I'd imagine). We went straight from 4 GB to 2 GB, so I can't comment on the results of using 3 GB. Our problem didn't seem to directly correspond with the 1 GB threshold -- it wouldn't manifest itself until the server had allocated all 4 GB of RAM. After a reboot, it would be nice and speedy again for a day or two until all the memory was being used for buffering again. This was the behavior I saw as well. I did a bunch of research and source reading before actually figuring out what was going on; it wasn't a well documented bug for some reason... I guess there aren't that many people running large boxes using 2.4. This makes me think that the problems I saw with 2GB were not related to the IO subsystem, but were something else. Time to go play around a bit; getting those boxes up to 2GB without having to do a kernel patch/upgrade cycle would be nice. M -- Benjamin Sherman Software Developer Iowa Interactive, Inc 515-323-3468 x14 [EMAIL PROTECTED]
Re: I/O performance issues on 2.4.23 SMP system
I was the poster who initiated the previous thread on this subject. The problem disappeared here after we went down to 2 GB of memory (although we physically removed it from the server rather than passing the arg to the kernel... shouldn't make a difference though, I'd imagine). We went straight from 4 GB to 2 GB, so I can't comment on the results of using 3 GB. The above comment sounds a lot like a bounce buffer issue. This is not an IO issue. Bounce Buffer issues look a like like IO problems on the surface. However, the IO bus will get a messy from having to much memory feeding it. Bounce Buffer issues can occur anytime you use over 2GB of RAM on a 32bit system. I have a Dual SMP Xeon 700 (32 bit) with 10GB of RAM in it. It is under a 10-20% CPU load daily. Originally, I had a bounce buffer problem that occurred during backups and heavy IO loads. The output from sar, system activity report, told me that process switches were not recovering after backups. IO loads would 'snowball' after backups. Generally, the whole system seemed to get overwhelmed and unstable after a heavy IO event, like a backup. I found this strange. Since the patch has been applied the server has been running very stable for over 43 days. I fixed the problem with following: This Bounce Buffer problem was resolved with the 00_block-highmem-all-18b-3 patch. http://www.kernel.org/pub/linux/kernel/people/andrea For example, the following sar output shows a normal recovery after a heavy IO event: 22:30:01 all83 089 1302172 0.35 0.33 0.35 074 090 183 088 - backup started #rsync 100GB RAID 5 Array 23:40:01 all3 14 18261731166 1.44 1.46 1.52 00:00:02 cpu %usr %sys %nice %idle pswch/s runq nrproc lavg1 lavg5 avg15 _cpu_ 00:10:01 all3 14 18256793166 1.62 1.56 1.53 03 13 183 13 15 181 00:20:01 all4 14 18260683156 1.45 1.46 1.46 03 14 182 14 14 181 00:30:01 all2 13 18355855161 1.10 1.16 1.29 03 13 184 12 14 183 00:40:01 all38 18831912146 0.12 0.63 1.01 038 188 138 188 00:50:01 all33 095 863139 0.15 0.23 0.60 - sync finished If you sar output does not look like this after a backup, and you have more than 2GB of RAM something is probably going on with a buffer. You can fix it two ways, upgrade to a 64Bit machine or patch your kernel with the block-highmem patch written by Andrea. My Kernel: 2.4.18 image=/boot/vmlinuz-2.4.18 #Compiled using GCC-2.95 on new IMAP server #Debian 2.4.18 Kernel package #Debian 2.4.18 xfs kernel patch #block-highmemory patch from http://www.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/ #00_block-highmem-all-18b-3 #HIMEM Kernel Support to 64GB #HIMEME IO Support added label=LinuxHIMEM read-only My Hardware: 00:00.0 Host bridge: ServerWorks CNB20HE Host Bridge (rev 21) 00:00.1 Host bridge: ServerWorks CNB20HE Host Bridge (rev 01) 00:00.2 Host bridge: ServerWorks: Unknown device 0006 00:00.3 Host bridge: ServerWorks: Unknown device 0006 00:01.0 SCSI storage controller: Adaptec 7896 00:01.1 SCSI storage controller: Adaptec 7896 00:05.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet LANCE] (rev 44) 00:06.0 VGA compatible controller: S3 Inc. Trio 64 3D (rev 01) 00:0f.0 ISA bridge: ServerWorks OSB4 South Bridge (rev 4f) 00:0f.1 IDE interface: ServerWorks OSB4 IDE Controller 00:0f.2 USB Controller: ServerWorks OSB4/CSB5 OHCI USB Controller (rev 04) 01:01.0 RAID bus controller: IBM Netfinity ServeRAID controller 01:02.0 RAID bus controller: IBM Netfinity ServeRAID controller 02:06.0 Ethernet controller: Intel Corp. 82557 [Ethernet Pro 100] (rev 0c) On 03/02/04 13:25 -0600, Benjamin Sherman wrote: Thanks to all who sent comments on this. I did some more testing and went straight to the source for input. snip if you want to try the 4G patch then i'd suggest Andrew Morton's -mm tree, which has it included: http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.2-rc2/2.6.2-rc2-mm2/ i've got a 2.4 backport too, included in RHEL3. (the SRPM is downloadable.) But extracting the patch from this srpm will likely not apply to a vanilla 2.4 tree - there are lots of other patches as well and interdependencies. So i'd suggest the RHEL3 kernel as-is, or the -mm tree in 2.6. Ingo /snip Of course, as newer kernels are released, Andrew releases newer -mm patches. This patch set solved the I/O problem and let me use 4GB RAM. Mark Ferlatte wrote: Daniel Erat said on Thu, Jan
anti-virus messages
It's gone too far. We need to deal with the anti-virus spam problem. Many companies have stated that nothing other than a black-list will make them change their anti-virus setup. http://www.attrition.org/security/rant/av-spammers.html I think that we need to setup a DNSBL service to list machines that send out anti-virus messages. The following is required: A server hosted in Europe where bandwidth is cheap and laws are reasonable (not the US for legal reasons). A team of sys-admins (at least one of whom lives near where the server is hosted). They must have experience in running ISP servers and dealing with attacks (lots of people on this list have the skills). A team of programmers who can write the database code to manage the list of servers and track the status of all entries (has to contain the original message that caused the listing, the date of the entry, and any follow-up). A team of content administrators who sift through the anti-virus messages and deal with complaint messages. Some funding. But as hardware and bandwidth are getting cheap the people who do the work can probably afford to pay. If you are interested in joining then please contact me by private mail. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
