You also can incorporate spam-assassin as a message filter.
To do so:
Add a new message filter. In the top group box (the "If" box), add an item that is "Pipe Message to Shell Command". For the command enter: "spamassassin -e >/dev/null" Change "returns" to "returns greater than". Then set the value to "0" (zero). In the bottom group box (the "Then" box), choose the "Move to folder" option and send the message to a folder (I call mine "suspected-spam"). Add another item to "Stop Processing".
That should do it. If spam-assassin detects the message as being Spam, it will move it to that folder. Granted, you still need to peek at the folder and clean it out manually, but until it "learns" what is spam/ham, it's good to not have it simply delete the messages blindly.
Of course they'd have to supply patches more quickly.... I mean, hell, when you consider the number of security holes there are in Winblows compared to Linux -- besides, Microsloth has paid employees whose job is to provide those patches.... I'd think it's fair to say that most of the Linux community has other jobs and contributes to the community as much as they are able to do so.
As usual, more MS propaganda to continue to misinform the masses.
I've dealt with garbage collection in Java and now in Python. When you get into the mindset of a language that does this natively, I have found that your code naturally flows into that paradigm. I can't imagine trying to use garbage collection in C/C++ -- it just doesn't fit into the scheme of things for me. True, the STL has auto_ptr, and I have used that in the past -- works rather nicely, IMHO -- however the way I learned how to write clean, efficient C code was to make sure you write the code to deallocate memory when you write the code to allocate it, whenever possible. This works for me, mainly 'cause I've done it for so long. Granted, there are times when doing so is difficult -- there are times when you allocate in one function, but don't deallocate until a much later time in another function. I've written a couple of 100K+-line apps that do that (and have to juggle CORBA calls as well) and it is -very- difficult to debug. That's when you wish you had garbage collection.
At any rate... I have found that a number of programmers prefer GC simply because they don't want the hassle of worrying about cleaning up after themselves. For really good programmers... yeah, it's nice and it allows them to focus more on the task at hand. However, for not-so-good or poor programmers (and there are a number out there) it allows them to write poor code that could allocate memory without considering the consequences -- before I get flamed for this comment, yes I have seen such code, and from some people who were supposedly "really good programmers". When push comes to shove, nothing beats writing good, clean code in the first place, having already designed into the code where memory is allocated and where it is deallocated. Once you've done that, grab the profiler and look for ways to optimize. Chances are, the code will be cleaner and more elegant than if you were to use a GC-type solution. If not, maybe C/C++ isn't the right language for the task. Time to take a look at Python.:)
That's true. You just never see it called that. I still prefer breaking it all down into the various levels (i386, i486, etc.) as there are differences between them all. The problem for the distros is that you can't assume that Joe User is running the latest and greatest CPU. That's why they compile for the older processors. At least Mandrake makes the base point a Pentium chip... I can't imagine who would choose to stay with a 386 processor, unless they have no other option (besides upgrading). Of course, one could always go the "from source" route -- LFS, Gentoo, etc. -- but I don't think there are many people out there besides us geeks who would want to build their machine from nothing. Even I prefer to use a distro, and I've done an LFS machine -- not worth the time/energy invested into doing it for all my PCs, at least for me anyway.
For the [obviously] non-technical person who wrote this comment.... it's still called 'i386' because that is the platform name. It really should be called 'ix86' as, yes, the 386 went the way of the dodo bird a long time ago, but most people know what they're talking about when an i386 is mentioned -- an Intel 32-bit x86 architecture chip. Even [gasp] Windows users know this -- have you recently looked at a Win NT/2000/XP/2003 setup CD-R... there are two folders to note in the root of the CD: "ia64" and "i386". These hold the setup files for the 64-bit Intel architecture chip and the 32-bit Intel architecture chip, respectively. Just because you think it strange to use the old platform id doesn't mean it doesn't make sense to the rest of the computer world.
Slashdot Mirror
Hukt on fonix wurkt fir mee. Haow ubaowt u?
You also can incorporate spam-assassin as a message filter.
To do so:
Add a new message filter.
In the top group box (the "If" box), add an item that is "Pipe Message to Shell Command".
For the command enter:
"spamassassin -e >/dev/null"
Change "returns" to "returns greater than".
Then set the value to "0" (zero).
In the bottom group box (the "Then" box), choose the "Move to folder" option and send the message to a folder (I call mine "suspected-spam").
Add another item to "Stop Processing".
That should do it. If spam-assassin detects the message as being Spam, it will move it to that folder. Granted, you still need to peek at the folder and clean it out manually, but until it "learns" what is spam/ham, it's good to not have it simply delete the messages blindly.
Of course they'd have to supply patches more quickly .... I mean, hell, when you consider the number of security holes there are in Winblows compared to Linux -- besides, Microsloth has paid employees whose job is to provide those patches .... I'd think it's fair to say that most of the Linux community has other jobs and contributes to the community as much as they are able to do so.
As usual, more MS propaganda to continue to misinform the masses.
I've dealt with garbage collection in Java and now in Python. When you get into the mindset of a language that does this natively, I have found that your code naturally flows into that paradigm. I can't imagine trying to use garbage collection in C/C++ -- it just doesn't fit into the scheme of things for me. True, the STL has auto_ptr, and I have used that in the past -- works rather nicely, IMHO -- however the way I learned how to write clean, efficient C code was to make sure you write the code to deallocate memory when you write the code to allocate it, whenever possible. This works for me, mainly 'cause I've done it for so long. Granted, there are times when doing so is difficult -- there are times when you allocate in one function, but don't deallocate until a much later time in another function. I've written a couple of 100K+-line apps that do that (and have to juggle CORBA calls as well) and it is -very- difficult to debug. That's when you wish you had garbage collection. At any rate ... I have found that a number of programmers prefer GC simply because they don't want the hassle of worrying about cleaning up after themselves. For really good programmers ... yeah, it's nice and it allows them to focus more on the task at hand. However, for not-so-good or poor programmers (and there are a number out there) it allows them to write poor code that could allocate memory without considering the consequences -- before I get flamed for this comment, yes I have seen such code, and from some people who were supposedly "really good programmers". When push comes to shove, nothing beats writing good, clean code in the first place, having already designed into the code where memory is allocated and where it is deallocated. Once you've done that, grab the profiler and look for ways to optimize. Chances are, the code will be cleaner and more elegant than if you were to use a GC-type solution. If not, maybe C/C++ isn't the right language for the task. Time to take a look at Python. :)
That's true. You just never see it called that. I still prefer breaking it all down into the various levels (i386, i486, etc.) as there are differences between them all. The problem for the distros is that you can't assume that Joe User is running the latest and greatest CPU. That's why they compile for the older processors. At least Mandrake makes the base point a Pentium chip ... I can't imagine who would choose to stay with a 386 processor, unless they have no other option (besides upgrading). Of course, one could always go the "from source" route -- LFS, Gentoo, etc. -- but I don't think there are many people out there besides us geeks who would want to build their machine from nothing. Even I prefer to use a distro, and I've done an LFS machine -- not worth the time/energy invested into doing it for all my PCs, at least for me anyway.
For the [obviously] non-technical person who wrote this comment .... it's still called 'i386' because that is the platform name. It really should be called 'ix86' as, yes, the 386 went the way of the dodo bird a long time ago, but most people know what they're talking about when an i386 is mentioned -- an Intel 32-bit x86 architecture chip. Even [gasp] Windows users know this -- have you recently looked at a Win NT/2000/XP/2003 setup CD-R ... there are two folders to note in the root of the CD: "ia64" and "i386". These hold the setup files for the 64-bit Intel architecture chip and the 32-bit Intel architecture chip, respectively. Just because you think it strange to use the old platform id doesn't mean it doesn't make sense to the rest of the computer world.