That's exactly how my system is set up. (Well, except for the "Profit!" part.) But this one has a typical spamassassin score of only 3.0 and walks straight through greylisting. Read more on my blog.
I'm suprised that nobody has mentioned IM2000 yet. Dan Bernstein came up with a bunch of ideas about how to reform email, the most important of which is the outgoing mail is stored on the sender's server until it is picked up by the recipient. There are lots of unanswered questions about the design, but the seeds are there.
At a company I worked for a few years ago, I saw something similar happen. The marketing department had made some deal with a "partner" such that we would mail our customers with the partner's (spammy) message, in return for some favor that I don't recall now.
I found out about this only after we had done the mailing, since I was one of the responsible parties on the domain name registration. Lots of irate messages were coming back to all manner of corporate mailboxes. I think we even got listed on spamcop for a while.
When I approached the marketing department to educate them on the damage caused by this blatant spamming, I was met with complete indifference. Their rationale was that they had only received a few dozen complaints, so it wasn't a big deal. Their heads were as thick as bricks.
It was a rather surreal view into the mind of a marketing weenie. I don't recommend you go there, it's not clean.
Believe it or not, some webcasters were actually smart enough to do that! Radio Paradise, at least, has a bit that loops every few minutes explaining what's going on and how to help. Don't believe everything you read on the internet.
Re:FOR loops: a question, ANSI C++, C++98, C++99..
on
GCC 3.0 Released
·
· Score: 2
There's a nifty preprocessor hack you can use to get around this problem in compilers that don't properly support the standard:
#define for if(0);else for
This causes the scope of the for control variable to be correct, without affecting other control flow semantics. The only practical disadvantage is your compiler may warn about the constant value in a conditional. And your sensibilities may be offended by using the preprocessor to redefine a keyword.:)
You were probably reading from the point of view of a client. The client interface to IMAP is relatively nice and quite capable. Implementing the functionality on the other side (the server), is a completely different story altogether. It seems as though the designers of the IMAP protocol made some assumptions about the server implementation which influenced the design. So server implementations tend to have to work hard to provide all the features required by the RFC.
You guys have been saying the OGR is right around the corner for a long time now.
It's true, distributed.net has been, um, somewhat slow at getting OGR going. Most of the initial work was not actually OGR-related, but reworking the d.net client to support contest types other than brute force crypto cracking. There were a lot of subtle assumptions that needed to be changed for OGR.
The other chunk of work was the master server and proxy network - we want this to be fully automatic and not require any more work on the user's end than RC5 or CSC requires today (that is, nothing except saying "yes, I want to help with this project"). If you've ever run the original OGR client, you'll know what I'm talking about.
Finally, the distributed.net announcement that we would be searching for OGRs did not "kill" the original OGR effort. Mark et al discontinued the search after the 23 mark ruler for various reasons unrelated to distributed.net.
Currently, the d.net OGR client is nearly ready to go with the exception that there is an elusive bug that causes the client to hang for no apparent reason. The source code is available at http://www.distributed.net/source/ so if you'd like to try to track it down, feel free.
Amen. I can't fathom how somebody would presume to be qualified to design a site about the history of the World Wide Web -- and design it such that it can't even be viewed with Lynx.
I'm glad somebody mentioned chaotic behaviour. While this sounds like a noble cause, the mathematics behind the idea is not based on sound principles.
There is no evidence that weather and climate patters are not chaotic, and plenty of evidence that they are. No matter how fast your computer is, no matter how accurately you measure your initial parameters, no matter how comprehensive your model is, you simply cannot predict the future state of our atmosphere beyond a day or so (and usually we can't even do that). One of the properties of chaotic behaviour is that arbitrarily small varations in input parameters eventually cause perterbations that exceed the strength of the signal you're trying to predict. When those variations are introduced by measuring a physical property (which cannot be done exactly), it's just a matter of time before your prediction breaks down.
They say they will use the data for the last 50 years to "calibrate" the model. Or use it as input for a genetic algorithm or something. But as the typical disclaimer goes, past history is not representative of future performance. Suppose that a given model predicts the past 50 years of climate reasonably accurately. I would submit that this would happen only by chance, and that the same model would be meaningless for the next 50 years.
Why don't they try creating an algorithm that will predict the climate changes just between 1950 and 1975 (25 years)? Then see how that same algorithm does on the next 25 years (1975-present). Perhaps there will be a number of algorithms that match the first 25 years reasonably accurately, and maybe one or two that end up matching the next 25 years too. How would you have chosen the best one 25 years ago? What makes them think they can choose the best algorithm for the next 50 years, today?
I'm surprised nobody has mentioned FreeBSD and its cvsup system. After mucking around with Linux for a couple of years and never really getting comfortable with maintaining a system with RPMs etc, I disovered FreeBSD not too long ago.
I now have a completely up to date 3.3-STABLE FreeBSD installation on my trusty old P90 that used to run a crufty old RedHat 4.2 install. By watching the FreeBSD mailing lists, I can tell if there's something new I need. If so...
cvsup stable-supfile make world [1] make install make kernel mergemaster reboot
Presto! Completely up to date system. Why isn't it this easy with anything else? Why are binary distributions/updates/patches/etc so popular?
Slashdot Mirror
For what it's worth, I got one of these messages yesterday:t ml
http://www.livejournal.com/users/ghewgill/48677.h
Hopefully this will help people know what to look for.
That's exactly how my system is set up. (Well, except for the "Profit!" part.) But this one has a typical spamassassin score of only 3.0 and walks straight through greylisting. Read more on my blog.
Here is the article: http://mindprod.com/dirty.html
It's actually a very good introduction to the language and some of its capabilities.
Atentu al la elefantaj fekeregoj! Ili ankoraux vaporas sub la argxenta luno.
Hopefully you've upgraded spamassassin in the last six months or so. If you haven't, do it! Older versions of spamassassin get useless very quickly.
I'm suprised that nobody has mentioned IM2000 yet. Dan Bernstein came up with a bunch of ideas about how to reform email, the most important of which is the outgoing mail is stored on the sender's server until it is picked up by the recipient. There are lots of unanswered questions about the design, but the seeds are there.
Don't you mean Phreedomgnomes?
See jabber.com for a commercial company selling service and support for jabber.
At a company I worked for a few years ago, I saw something similar happen. The marketing department had made some deal with a "partner" such that we would mail our customers with the partner's (spammy) message, in return for some favor that I don't recall now.
I found out about this only after we had done the mailing, since I was one of the responsible parties on the domain name registration. Lots of irate messages were coming back to all manner of corporate mailboxes. I think we even got listed on spamcop for a while.
When I approached the marketing department to educate them on the damage caused by this blatant spamming, I was met with complete indifference. Their rationale was that they had only received a few dozen complaints, so it wasn't a big deal. Their heads were as thick as bricks.
It was a rather surreal view into the mind of a marketing weenie. I don't recommend you go there, it's not clean.
That reminds me of when it was cool to tell lusers that there was this huge ftp site at 127.0.0.1, just log in with your existing account...
Thank you very much for this introductory line in your comment. After quickly reading this, I knew I could immediately skip the rest of your post.
If only the whole slashdot community would follow SlugLord's lead, and let us all know when they've just posted a useless comment. Bravo!
What's with that abnormally low load average?
Believe it or not, some webcasters were actually smart enough to do that! Radio Paradise, at least, has a bit that loops every few minutes explaining what's going on and how to help. Don't believe everything you read on the internet.
There's a nifty preprocessor hack you can use to get around this problem in compilers that don't properly support the standard:
#define for if(0);else forThis causes the scope of the for control variable to be correct, without affecting other control flow semantics. The only practical disadvantage is your compiler may warn about the constant value in a conditional. And your sensibilities may be offended by using the preprocessor to redefine a keyword. :)
You were probably reading from the point of view of a client. The client interface to IMAP is relatively nice and quite capable. Implementing the functionality on the other side (the server), is a completely different story altogether. It seems as though the designers of the IMAP protocol made some assumptions about the server implementation which influenced the design. So server implementations tend to have to work hard to provide all the features required by the RFC.
The other chunk of work was the master server and proxy network - we want this to be fully automatic and not require any more work on the user's end than RC5 or CSC requires today (that is, nothing except saying "yes, I want to help with this project"). If you've ever run the original OGR client, you'll know what I'm talking about.
Finally, the distributed.net announcement that we would be searching for OGRs did not "kill" the original OGR effort. Mark et al discontinued the search after the 23 mark ruler for various reasons unrelated to distributed.net.
Currently, the d.net OGR client is nearly ready to go with the exception that there is an elusive bug that causes the client to hang for no apparent reason. The source code is available at http://www.distributed.net/source/ so if you'd like to try to track it down, feel free.
Amen. I can't fathom how somebody would presume to be qualified to design a site about the history of the World Wide Web -- and design it such that it can't even be viewed with Lynx.
There is no evidence that weather and climate patters are not chaotic, and plenty of evidence that they are. No matter how fast your computer is, no matter how accurately you measure your initial parameters, no matter how comprehensive your model is, you simply cannot predict the future state of our atmosphere beyond a day or so (and usually we can't even do that). One of the properties of chaotic behaviour is that arbitrarily small varations in input parameters eventually cause perterbations that exceed the strength of the signal you're trying to predict. When those variations are introduced by measuring a physical property (which cannot be done exactly), it's just a matter of time before your prediction breaks down.
They say they will use the data for the last 50 years to "calibrate" the model. Or use it as input for a genetic algorithm or something. But as the typical disclaimer goes, past history is not representative of future performance. Suppose that a given model predicts the past 50 years of climate reasonably accurately. I would submit that this would happen only by chance, and that the same model would be meaningless for the next 50 years.
Why don't they try creating an algorithm that will predict the climate changes just between 1950 and 1975 (25 years)? Then see how that same algorithm does on the next 25 years (1975-present). Perhaps there will be a number of algorithms that match the first 25 years reasonably accurately, and maybe one or two that end up matching the next 25 years too. How would you have chosen the best one 25 years ago? What makes them think they can choose the best algorithm for the next 50 years, today?
http://www.gaming-age.com/ne ws2/november98/111998e.htm
http://www.gamenfo.com/Dreamcast/dr eamcast.html (ick, apologies in advance for the popup)
The 56k modem is in a pluggable module, so evidently Sega designed for this.
I now have a completely up to date 3.3-STABLE FreeBSD installation on my trusty old P90 that used to run a crufty old RedHat 4.2 install. By watching the FreeBSD mailing lists, I can tell if there's something new I need. If so...
cvsup stable-supfile
make world [1]
make install
make kernel
mergemaster
reboot
Presto! Completely up to date system. Why isn't it this easy with anything else? Why are binary distributions/updates/patches/etc so popular?
[1] Okay, this step takes seven hours on a P90.
Today I converted all GIFs on my web site to PNG. I've been meaning to do that for a long time. Thanks, Unisys!