Domain: develooper.com
Stories and comments across the archive that link to develooper.com.
Comments · 36
-
Re:"legitimate?"
I had the same problems. The server was bombarded with spam and couldn't process its normal mail. I fixed it by installing qpsmtpd http://smtpd.develooper.com/ , a fully programmable Perl smtp daemon that can function as a front end for qmail or postfix.
I needed some fancy logic, because I use mailing lists with dynamic addresses that have to be refused /accepted intelligently. Qpsmtp does that well. -
Flexible smtp daemon?
If you need a real flexible smtp daemon, and can program in perl, I would recommend qpsmtd. Give it a try, you can create your own plugins (to handle spam or whatever you need) so easily you won't believe it.
-
qpsmtpd
Take a look at qpsmtpd:
http://smtpd.develooper.com/ -
Re:Zend's ZActiveRecord Boondoggle
Perl's performance for CGI is bad without some sort way of increasing its speed. The major options for this are:
- Apache and mod_perl - This can work transparently, but if you look at it funny, it breaks.
Agreed... hate it.
- FastCGI - which isn't transparent by any stretch of the imagination.
I'll take your word on this one -- I've never used it.
- SpeedyCGI - Same problem as FastCGI.
Have to disagree with you on this. As long as your code is already use strict compliant, you shouldn't have to make any changes at all to get things running under SpeedyCGI. I've used it in quite a number of locations, both in a CGI context and for regular sysadmin and mail server duties, without any sort of mind-bending issues (except for if I was doing heavy shell file descriptor magic, since it moves things around when doing its pipe). Strongly recommended.
- PPerl - which isn't necessarily written for use in CGI.
True. See above. PPerl is an interesting choice if you *do* in fact need to do some heavy shell file descriptor magic (see http://smtpd.develooper.com/). I've kept with SpeedyCGI for other reasons though.
- Rolling a custom http server using HTTP::Daemon or Socket. Which is a really bad idea.
Not if you enjoy pain. =) -
Re:mod_smtpd (?)
It may seem bizarre to you, but apache.org's mail servers already run on an SMTPD that runs in the apache2 process. It's called Qpsmtpd.
-
Re:Rewrite, anyone?
qpsmtpd
http://smtpd.develooper.com/ -
Re:Not that great
Replying to myself...
So reading the full disclosure they used 4 quad xeons. That's 16 CPUs. Compared to apache.org's 2.
So using a pure perl SMTPD you can have this kind of throughput (~1m mails per day per CPU) with spam and virus filtering enabled.
No, I am not impressed with this benchmark. -
Not that great
I didn't even know there was a SPECmail, but this figure doesn't seem too outstanding to me.
Firstly I assume this is just a raw delivery setup - no spam or virus filtering. You'd be amazed how much of a difference this makes to any real world setup.
Secondly, apache.org does over 2 million mails a day on a dual 2.4Ghz Xeon using an SMTP server written in Perl. And that's with full anti-virus (clamav) and lots of different anti-spam measures including SpamAssassin (which is known to be slow - I know because I used to be one of the developers).
I also know of commercial setups doing over 50m (legit, well - mostly) mails a day. Using an SMTP Server designed with performance in mind. Perhaps they should submit for SPECmail ;-)
So 30 million doesn't seem terribly amazing to me. Perhaps Communigate Pro isn't a very fast mail server. -
SURBL resources, sa.surbl.org list renaming to ws.Hi All, First I wanted to let everyone know that the name of the SURBL list derived from Bill Stearns' sa-blacklist is changing from sa.surbl.org to ws.surbl.org . DNS for the old name will probably be up for another week or so before we switch it off. If anyone us using sa.surbl.org please update your rules or confs to use the new name: ws.surbl.org . The original SURBL derived from SpamCop URI domains remains unchanged at: sc.surbl.org . (One advantage of using Bill's list as an SURBL instead of hard-coded SpamAssassin rules is that it frees up a lot of SA memory and pushes storage of the spam domain data to your local DNS cache.)
Differences between the two lists and more topics about our project are described on the SURBL site. If anyone has a question or comment about SURBL you can write to me directly at jeffc at surbl dot org, or much better ask the growing SURBL community on our discussion list. The separate announcement list is a good way to keep up with news about the project. Archives of the lists are available on the list site.
Folks who have tried SURBL have generally been pleased with the results, and we expect to improve the ~60% spam detection rate and lower the already low (<0.1%) false positive rate further in the next version of the data engine behind sc.surbl.org. As has been previously mentioned, Devin Carraway has written an MTA use of SURBL domain data to check message body URIs in his qpsmtpd plugin called uribl. This is the first MTA use for SURBL that I've heard of, though I don't necessarily claim to have heard of all uses of SURBL so far. Some other folks are thinking about implementing a sendmail milter for which will probably use sc.surbl.org since they are also a major ISP source of SpamCop's data.
Since I probably won't be posting here too often, I'd like to thank some of the people who have been quietly very supportive and responsible for the success of this effort so far including Eric Kolve, Justin Mason, Daniel Quinlan, Raymond Dijkxhoorn, Julian Haight, Kelsey Cummings and others who already know how greatly they have helped to make SURBL possible.
One thing we could use some help with now are more BIND-compatible secondary DNS servers and rsynced rbldnsd servers. Please see the SURBL site for details, and lend a hand if you can. DNS traffic may get kind of heavy when SA 3.0 comes out since it has SURBL support in URIDNSBL (URIBL), so we definitely need some help with name service.
-
Okay, here's some MTA support
While I'm not totally sold on the idea, it seemed to have enough promise to be worth trying. So here's a plugin to qpsmtpd, a replacement smtpd for qmail (it also delivers to postfix, IIRC). Implements most of the basic suggestions in SURBL's proposal.
(I'd like to be able to slap a bell and yell "first implementation!" in a childish slashdot fashion, but I'd be surprised if this really was the first, since it's easy to do a simple implementation and parallels similar DNSBLs in some respects.)
-
Re:Sendmail?!
qmail is quite modular. If you really need your smtpd to do spam filtering, you can always replace qmail-smtpd with qpsmtpd, and plug it into spam assassin. Legendary qmail reliability/security/etc, except with the smtpd part written in... perl. Ok, maybe it sounds crazy, but I think it's still better than send*cough*remoteroot*cough*mail.
Personally, I run qmail (with the standard smtpd, not that perl one) on the mail server, and postfix on the mac laptop. Works for me. ;; nonyn -
Re:Independent code checking
Yup, code reviews are fraught with pitfalls.
Here's another scenario: you write a class, it gets reviewed by someone and they suggest you use a Factory pattern. You rewrite it to use Factory, and then it gets reviewed by someone else and they say "why are you adding in that Factory pattern? that just makes it more complicated to use - you're over abstracting!". Both reviewers are right in a way... it all depends on how the class is being used.
There's a nice discussion of alternatives to code reviews here.
tom -
qpsmtpd + clamav
[Disclaimer: I work in AV]
If cost is even slightly an issue, I can recommend using qpsmtpd and clamav. The clamav team are pretty fast at adding new virus signatures to their database, and they catch most of the common viruses out there. I've written a qpsmtpd plugin for clamav which you can find here.
I can't honestly recommend Sophos for gateway scanning. They are better on the desktop. If you can I would go for NAI who have the best gateway scanning of the commercially available scanners (according to our live tests).
Alternatively, if a 100% guarantee appeals to you, the company I work for, MessageLabs will give you a 100% guarantee against letting through an email virus. We'll also do spam scanning for you. Yes, I'm biased. -
I think Perl5/XS will be with us for long time...Don't worry about about Perl5/XS becoming obsoleted - it will be with us for a long time since the Parrot (perl 6 VM) project seems to be going nowhere fast. Parrot is suffering from kitchen sink/second system syndrome.
Recently, the DotGNU have made an overture to try to use the Parrot runtime for their C# compiler but found that Parrot needs a lot of work to get to the point where they could use it.
Some Parrot VM problems:
no calling conventions yet for subroutines. There is no hope of offering mixed language support unless they do this.
no conversion opcodes for various builtin types (float, char, short, int)
non-perl languages expected to provide additional support in the form of C code libraries for their opcodes. This would nix any hope of having a single standard universal virtual machine.
no way to call out to C code
no equivalent of Java's jar file or CLR's assemblies for parrot library distribution
way too many registers: their register based VM (32 int registers, 32 double registers, 32 string registers, 32 PMC registers plus various stacks) requires a sophisticated compiler to do proper register allocation and needlessly complicates their VM.
no consideration of threads in their design. How will they handle synchronization, for example?
The points above are not coding issues, but issues of design. It seems that Parrot is too hung up on making the VM efficient and are not seeing the bigger picture - to get the features in place first so that high-level languages can work. Or perhaps they should simply concentrate on getting Perl6 to work first. They need more focus. The project tries to be all things to all people, but ends up satisfiying no one. -
Re:Dijkstra
Yeah I don't think it's a troll as it seems to be coming from reliable sources. Apparently his family sent an email to the faculty at cs.utexas.edu which has been forwarded around. I would imagine it would show up in the news within a day. Here's a link to the email, on the perl5-porters list.
-
Re:pumpkin pumpkin whos got the pumpkinDavid,
Thank you for your post. First, I'd like to say that I hoping you are who you claim to be. The fact that you're posting as an AC, and that google doesn't know about you, and that you're not listed as a fink developer at the fink project member list, and that no reference of you exists at the fink-devel archive gives me pause. Appologies if my skepticism turns out to be unwarranted. For the sake of this response, I will assume that you are not trolling and are who you claim to be.
That being the case, I'm afraid you've been misled by the comment that you initially responded to. That comment was posted by someone who extracted out a small section of a report that I sent to various mailing lists last night. The comment to which you responded has effectively deprived you of the relevant context surrounding the issue. My full report can be found at the archives for the three lists I sent it to:
To summarize the report, there is a dyld issue of perl undefined symbols under Mac OS X, when fink is installed, and when the user has manually upgraded to perl 5.8.0. This issue effectively renders the new perl installation unusable, in addition to many things that depend on perl.This is caused by fink setting PERL5LIB to
/sw/lib/perl5 which contains one or more compiled XS modules. Since perl 5.8.0 is not binary compatible with any prior perl release all XS modules will have to be recompiled in order to not experience the show-stopping dyld issue.At this moment in time there have been several replies. One was a reply from Max Horn, a senior developer at fink. And, another reply was a reply from Michael Schwern, quality assurance manager for perl. Both acknowledge this as an issue and further outline the cause of this as well as possible permanent solutions.
The steps outlined in the 'RESOLUTION' section of the report are sane and well tested. They do indeed correct the issue that the report details, and should absolutely not cause any peripheral problems.
I'd like to request that if you further reply, please also do so on one of the three lists mentioned above so we can keep everyone in the loop.
Thank you!
-
Re:pumpkin pumpkin whos got the pumpkinDavid,
Thank you for your post. First, I'd like to say that I hoping you are who you claim to be. The fact that you're posting as an AC, and that google doesn't know about you, and that you're not listed as a fink developer at the fink project member list, and that no reference of you exists at the fink-devel archive gives me pause. Appologies if my skepticism turns out to be unwarranted. For the sake of this response, I will assume that you are not trolling and are who you claim to be.
That being the case, I'm afraid you've been misled by the comment that you initially responded to. That comment was posted by someone who extracted out a small section of a report that I sent to various mailing lists last night. The comment to which you responded has effectively deprived you of the relevant context surrounding the issue. My full report can be found at the archives for the three lists I sent it to:
To summarize the report, there is a dyld issue of perl undefined symbols under Mac OS X, when fink is installed, and when the user has manually upgraded to perl 5.8.0. This issue effectively renders the new perl installation unusable, in addition to many things that depend on perl.This is caused by fink setting PERL5LIB to
/sw/lib/perl5 which contains one or more compiled XS modules. Since perl 5.8.0 is not binary compatible with any prior perl release all XS modules will have to be recompiled in order to not experience the show-stopping dyld issue.At this moment in time there have been several replies. One was a reply from Max Horn, a senior developer at fink. And, another reply was a reply from Michael Schwern, quality assurance manager for perl. Both acknowledge this as an issue and further outline the cause of this as well as possible permanent solutions.
The steps outlined in the 'RESOLUTION' section of the report are sane and well tested. They do indeed correct the issue that the report details, and should absolutely not cause any peripheral problems.
I'd like to request that if you further reply, please also do so on one of the three lists mentioned above so we can keep everyone in the loop.
Thank you!
-
Re:pumpkin pumpkin whos got the pumpkinDavid,
Thank you for your post. First, I'd like to say that I hoping you are who you claim to be. The fact that you're posting as an AC, and that google doesn't know about you, and that you're not listed as a fink developer at the fink project member list, and that no reference of you exists at the fink-devel archive gives me pause. Appologies if my skepticism turns out to be unwarranted. For the sake of this response, I will assume that you are not trolling and are who you claim to be.
That being the case, I'm afraid you've been misled by the comment that you initially responded to. That comment was posted by someone who extracted out a small section of a report that I sent to various mailing lists last night. The comment to which you responded has effectively deprived you of the relevant context surrounding the issue. My full report can be found at the archives for the three lists I sent it to:
To summarize the report, there is a dyld issue of perl undefined symbols under Mac OS X, when fink is installed, and when the user has manually upgraded to perl 5.8.0. This issue effectively renders the new perl installation unusable, in addition to many things that depend on perl.This is caused by fink setting PERL5LIB to
/sw/lib/perl5 which contains one or more compiled XS modules. Since perl 5.8.0 is not binary compatible with any prior perl release all XS modules will have to be recompiled in order to not experience the show-stopping dyld issue.At this moment in time there have been several replies. One was a reply from Max Horn, a senior developer at fink. And, another reply was a reply from Michael Schwern, quality assurance manager for perl. Both acknowledge this as an issue and further outline the cause of this as well as possible permanent solutions.
The steps outlined in the 'RESOLUTION' section of the report are sane and well tested. They do indeed correct the issue that the report details, and should absolutely not cause any peripheral problems.
I'd like to request that if you further reply, please also do so on one of the three lists mentioned above so we can keep everyone in the loop.
Thank you!
-
Re:what about perl 6?
If you could write and use a Perl 6 program right now, maybe he'd include a chapter on it in his book.
heh. -
Re:So why don't you?
If you want to validate perl 6 code, you might want to check out:
http://archive.develooper.com/perl6-language%40per l.org/msg10223.html
--
ralph -
Re:What's wrong with Perl?
-
perlmonks
-
yes, jbennetto,
jbennetto, your little friends are wrong. They have been affected by the skepticism of a skeptical age. They do not believe except they see. They think that nothing can be which is not comprehensible by their little minds. All minds, jbennetto, whether they be men's or children's, are little. In this great universe of ours, man is a mere insect, an ant, in his intellect as compared with the boundless world about him, as measured by the intelligence capable of grasping the whole of truth and knowledge.
Whatever, I thought it was funny. -
Re:Perl isn't unreadable - some Perl programs areHaving used BASIC since I was a child and having just ported BASIC to Parrot, I can tell you:
- It predates "modern" Unix shells by a decade and Unix itself by at least 5 years.
- BASIC used $ to indicate string variables (LET A$="HELLO") and the lack of a type indicator to mean a number.
-
Parrot, Python and Perl 6
Seeing as how parrot is being developed pretty much entirely by Perl developers (heck, the development is being done on the perl6-internals mailing list), I think it's unlikely that it'll ever be adopted by the Python community.
Given that a Google search for "Parrot" on the Python.org shows 570 matches, I don't think so.Does Parrot even support real type systems, or does it only support Perl's broken "scalars are scalars" type system?
If you had ever clicked one of the links in my post, you'd have known that. There are these basic data types:- IV (integer)
- NV (floating-point)
- STRING (encoding-independent string)
- PMC (Parrot Magic Cookie)
Vtable Datatypes
And about ``Perl's broken "scalars are scalars" type system''. I won't argue with you, as you obviously have no idea what are you talking about, but other people may be interested in this subject as well, so I'll point out where to find informations on how these things are going to change in Perl 6: For a good introduction to Perl 6 in current shape read Larry Wall's Apocalypses and Damian Conway's Exegeses: For more detailed info, join the mailing lists and read the archives: There's more info about in on dev.perl.org - the Perl 6 homepage.The next major thing that Parrot needs to implement is PMCs; these are almost like Perl 5's SVs, only more so. A PMC is an object of some type, which can be instructed to perform various operations. So when we say
inc P1
to increment the value in PMC register 1, the increment method is called on the PMC - and it's up to the PMC how it handles that method.PMCs are how we plan to make Parrot language-independent - a Perl PMC would have different behavior from a Python PMC or a Tcl PMC. The individual methods are function pointers held in a structure called a vtable, and each PMC has a pointer to the vtable which implements the methods of its "class." Hence a Perl interpreter would link in a library full of Perl-like classes and its PMCs would have Perl-like behavior.
[ read more ]
-
Re:Yes, but...
It's one thing to program in good style, but it's another to have the language force you to. Yes, I'm still resentful over that.
It's a well known fact, even among Perl advocates, that the vast majority of Perl code is indecipherable. It isn't impossible to write fairly clean code in Perl, but the language certainly doesn't encourage it.Please, don't argue Perl vs. Python, it will only start pointless flame wars. Let's agree that it's just a matter of taste. Remember, There's More Than One Way To Do It. I personally prefer Perl, but it's a totally subjective opinion. Perl and Python are more or less equally powerful languages today. But what I'm really looking forward to is Parrot, i.e. the virtual machine for Perl 6 and, I hope, also for Python, Ruby, Tcl and maybe few other good languages. It's a VM and a low-level assembly language for that VM - the language, to which Perl 6 (and hopefully other high-level languages) will be compiled to (as a layer between Perl and the VM bytecode) like C is compiled to machine-specific Assembbler (between C and the machine code). See the examples of Parrot use and read Parrot: Some Assembly Required to see what it is. Also the perl6-internals at perl.org mailing list archives is a good place to start. I'd love to see Perl and Python playing nice together, thanks to Parrot. It'd be really cool if I could write a program in Perl with someone who writes his part in Python, and another one writing in Ruby. I would just use their classes and objects, they would just use mine as well, without worrying about the language of our implementation. Parrot can be the answer here. Would it be the end of language flame wars? I do hope so.
-
Re:Kudos, but not yet...
I won't give them a dime until they put more effort into being a bit nicer to people who need help.
You are entitled to do whatever you think is appropriate with your money.Personally, I've found them to be extremely helpful and a great resource. I've also seen them be downright nasty and arrogant towards people they perceive to be less than "elite".
You must have gotten this impression from the Usenet perl newsgroups. For a long time, the newsgroups were the resource for perl-related things. Usenet being a public forum, there are all kinds of people frequenting them. You cannot take any subset of them as representing the "perl community".I know there's been some effort to do that in the past, however it seems to have died out from a public image point of view.
Please visit Perl Monks and the perl beginners and the perl beginners-cgi mailing lists. These are amazing resources. /prakash -
Re:Kudos, but not yet...
I won't give them a dime until they put more effort into being a bit nicer to people who need help.
You are entitled to do whatever you think is appropriate with your money.Personally, I've found them to be extremely helpful and a great resource. I've also seen them be downright nasty and arrogant towards people they perceive to be less than "elite".
You must have gotten this impression from the Usenet perl newsgroups. For a long time, the newsgroups were the resource for perl-related things. Usenet being a public forum, there are all kinds of people frequenting them. You cannot take any subset of them as representing the "perl community".I know there's been some effort to do that in the past, however it seems to have died out from a public image point of view.
Please visit Perl Monks and the perl beginners and the perl beginners-cgi mailing lists. These are amazing resources. /prakash -
Perl Bioinformatics for AI Neuroscience
Anyone who wanders into the use of Perl for bioinformatics ought to consider the ultimate plunge into the use of Perl for neuroscientific Artificial Intelligence. Since v.t.y. Mentifex here has been coding the AI Brain-Mind in JavaScript for tutorial purposes and also in Forth for Intelligent Mind Roboinformatics, the switch-over to Perl is advancing so slowly that I must first promulgate some candidate AI module proposals for inclusion among the object-oriented Perl 5 Module List.
The Comprehensive Perl Archive Network (CPAN) contains some not-yet-implemented, suggested AI module namespaces for those who read the Beginning Perl book reviewed here on SlashDot and who may then wish to do some really exciting, wave-of-the-future Perl neuroscience theory and practice work.
-
Newbie users. newbie vendorsThis is at least partly the fault of vendors. Last year I had a temp job for a company that had their email system run by an Exchange server, thus everyone had to use Outlook. I was working on a Sun Blade workstation, but since Outlook doesn't seem to have a Solaris version, I had to check my email from an old Mac in an unused office. That was annoying to begin with, but worse was the fact that:
- it jeopardy quoted by default, and there was no way to override this setting
- it posted as HTML by default, and the only thing you could configure was which font you want to use, not "whether or not there is a defined font in the first place"
Etc. I tried to fight this by cutting & pasting my messages so that they'd be top-quoted -- The Way The Good Lord Intended -- but it was much too much of a pain in the ass, and being the only one in the company doing it just made me look funny. Likewise my selection of a monospace font -- it was like tilting at windmills.
Yes, it's sad that not everyone has been brought into the culture in such a way that old netiquette would be honored, but that's just how it works when a subculture gets promoted to the mainstream. Yes, Microsoft could have made it easier to configure Outlook -- and to be fair, Outlook Express *is* a nice email client on the Mac (I just wasn't allowed to use it), and newer versions than this one ('98?) might be more flexible) -- and there's really no defence for their wholesale scuttling of all but their way of quoting messages. But what's done is done: as long as I can keep using Pine or Mutt, and read most of the mail coming to me, I'm not going to lose any sleep over it. Times have moved on...
-
0.0.3? 0.0.4 is in the works...
If you're interested in Parrot, get the version from cvs, and get on the mailing list. There's a hell of a lot of interesting and cool stuff thats gone in since 0.0.3, not least of which is JIT on a few platforms (linux among them). Just check out the mailing list for details.
Oh, and if you run an unusual system, then get in contact with the parrot team! They need more exotic systems to get parrot building on!/p
-
Re:Who is Dan Sugalski?dan sugalski is working on perl 6. a lot. take a quick look through the perl6-internals mailing list archive to see just how active he is.
without dan perl 6 just won't be the same.
-
Re:OSS Test Harnesses? OSS Test Suites?Perl does have a test suite, as well as a dedicated group of QA people. (I promise!)
There's been work to get similar things for the kernel, as well.
I'd personally be a little scared of testing kernel functions, but I've tested a lot of so-called "untestable" things lately. It's worth doing.
-
Re:Perl6 multiway comparison requires telepathy
On the other hand, we are also told:
Did you notice that cunning $a == $b != NaN test in operator:EQ? This lovely Perl 6 idiom solves the problem of numerical comparisons between non-numeric strings.
which may be cunning, except of course with wow neat multiway comparisons it is equivalent to ($a == $b) && ($b != NaN), which doesn't do the advertised job.Actually, it does, as Damian pointed out to me when I asked about it earlier today.
-
Re:Perl6 multiway comparison requires telepathy
On the other hand, we are also told:
Did you notice that cunning $a == $b != NaN test in operator:EQ? This lovely Perl 6 idiom solves the problem of numerical comparisons between non-numeric strings.
which may be cunning, except of course with wow neat multiway comparisons it is equivalent to ($a == $b) && ($b != NaN), which doesn't do the advertised job.Actually, it does, as Damian pointed out to me when I asked about it earlier today.
-
Faster Perl
Well I suppose now somebody is going to have to update the Quantum modules so they use this stuff
:)
if (any(@value) is very useful, but the inclusion into Perl 6 is (AFAIK) currently under RFC . The thought of quantum Perl on a quantum computer makes me feel all tingley...
-- Dooferlad