Slashdot Mirror

See pp to package Perl 5 applications into standalone distributions.

Given all the bitching over this, you think some one would of done something with this leak already. So far the people who are against this seem to have a upper hand.

I am a bummed by how no one has made any decent use of it yet. I think a reason for this is because no one has yet published a easily readable version of it.

To this end I've actually written the Perl module DBI::Wikileaks::AfWD.

http://search.cpan.org/~vvelox/DBI-Wikileaks-AfWD/

Only Python comes close to having anything resembling Perl's level of testing. (Ruby's improved a lot thanks to Rubinius, but to my knowledge the latest stable releases don't include test suites.) PHP's testing was abysmal, last I checked.

None of those languages have anything like the CPAN, despite saying for years "We should build something like the CPAN."

None of those languages are as malleable as Perl 5; see MooseX::Declare for example, or even Moose.

PHP is still easier to deploy for web programs than Perl. Python has an advantage with GAE, and I understand Ruby has something called Heroku.

... when it languished under Larry Wall's negligent stewardship?

Healthy communities flourish from the healthy interactions between and cooperation of many individuals. If you thought Larry's job was to make sure that everyone is happy and doing exactly what he thinks they should do, you've never understood Larry or the Perl community.

It seems like the current way to be hip in developer circles is to make fun of Perl.

I really want to understand this phenomenon as I doubt most of these people bashing Perl have never even seen any Perl code written in the last 4 years. Hell, I could bet that a lot of people have never seen any *real* Perl code at all.

Perl 5 is a modern language which has the features of other currently more trendy dynamic languages and more. We have modern web frameworks. We have robust database bindings and state-of-the-art ORM libraries. We have have a well-tested modern object-system with optional declarative syntax. Perl is used by several high profile sites which, at this point, everyone already knows (BBC, DuckDuckGo, Slashdot, etc).

Perl 6 is a different language but shares a lot of the common minds behind all these awesome Perl 5 tools. However, even if you don't like Perl 5 for whatever reason keep in mind that Rakudo Star is a completely different thing (as a matter of fact, the name "Perl 6" should probably be dropped in favor of Rakudo - to avoid all this cargo-cult).

It seems like the current way to be hip in developer circles is to make fun of Perl.

I really want to understand this phenomenon as I doubt most of these people bashing Perl have never even seen any Perl code written in the last 4 years. Hell, I could bet that a lot of people have never seen any *real* Perl code at all.

Perl 5 is a modern language which has the features of other currently more trendy dynamic languages and more. We have modern web frameworks. We have robust database bindings and state-of-the-art ORM libraries. We have have a well-tested modern object-system with optional declarative syntax. Perl is used by several high profile sites which, at this point, everyone already knows (BBC, DuckDuckGo, Slashdot, etc).

Perl 6 is a different language but shares a lot of the common minds behind all these awesome Perl 5 tools. However, even if you don't like Perl 5 for whatever reason keep in mind that Rakudo Star is a completely different thing (as a matter of fact, the name "Perl 6" should probably be dropped in favor of Rakudo - to avoid all this cargo-cult).

It seems like the current way to be hip in developer circles is to make fun of Perl.

I really want to understand this phenomenon as I doubt most of these people bashing Perl have never even seen any Perl code written in the last 4 years. Hell, I could bet that a lot of people have never seen any *real* Perl code at all.

Perl 5 is a modern language which has the features of other currently more trendy dynamic languages and more. We have modern web frameworks. We have robust database bindings and state-of-the-art ORM libraries. We have have a well-tested modern object-system with optional declarative syntax. Perl is used by several high profile sites which, at this point, everyone already knows (BBC, DuckDuckGo, Slashdot, etc).

Perl 6 is a different language but shares a lot of the common minds behind all these awesome Perl 5 tools. However, even if you don't like Perl 5 for whatever reason keep in mind that Rakudo Star is a completely different thing (as a matter of fact, the name "Perl 6" should probably be dropped in favor of Rakudo - to avoid all this cargo-cult).

Gah, I always expect paragraphs to be added automatically in CMSes; to repost with paragraphs (albeit probably still with too few):

What major browser just added a few kludges? Gecko and Presto always used an XML parser. KHTML is the only UA I'm aware of that used their HTML parser for XHTML, but that never had much marketshare (WebKit has always used an XML parser, once it came into existence).

I'm not convinced uptake would be much quicker: most content nowadays comes through a CMS of some sort, almost all of which are nowhere near capable of guaranteeing their output will be well-formed (just try throwing in a U+FFFF character into most CMSes... heck, at a more basic level try U+0000). There's a very long way to come before software is anywhere near ready to be able to output XML safely everywhere (and ideally use a serializer to ensure that all output is well-formed).

As for the complexity of XML parsers relative of HTML5 ones, I'm not convinced having been involved in writing both. There's a lot of complexity both in tokenizing and parsing doctypes in XML. As for other languages: there was talk a couple years ago of libxml2 moving to the HTML5 parsing algorithm for its HTML parser once the spec stabilizes (which, for parsing at least, bar a few bugs in the foreign content insertion mode, it more or less has) which would cover C (and also most platforms), here's a C#/.NET one, though now outdated, and there's a Perl one on CPAN. I'd expect implementations to continue to appear in more and more languages.

Sure, getting the diversity of implementations to the level of XML will take a while, but quickly with implementations in C++, Java, Python, Ruby, C#, PHP, Perl you're already covering a large majority of applications today. Having only an XHTML serialization may have helped with future content, but there's a couple of decades worth of legacy content that will probably never go away: if you want to deal with the majority of web content you're still going to have to deal with HTML. (Equally, if you leave parsing undefined, you still need to run around reverse-engineering browsers, which is not a sustainable approach.)

What major browser just added a few kludges? Gecko and Presto always used an XML parser. KHTML is the only UA I'm aware of that used their HTML parser for XHTML, but that never had much marketshare (WebKit has always used an XML parser, once it came into existence). I'm not convinced uptake would be much quicker: most content nowadays comes through a CMS of some sort, almost all of which are nowhere near capable of guaranteeing their output will be well-formed (just try throwing in a U+FFFF character into most CMSes... heck, at a more basic level try U+0000). There's a very long way to come before software is anywhere near ready to be able to output XML safely everywhere (and ideally use a serializer to ensure that all output is well-formed). As for the complexity of XML parsers relative of HTML5 ones, I'm not convinced having been involved in writing both. There's a lot of complexity both in tokenizing and parsing doctypes in XML. As for other languages: there was talk a couple years ago of libxml2 moving to the HTML5 parsing algorithm for its HTML parser once the spec stabilizes (which, for parsing at least, bar a few bugs in the foreign content insertion mode, it more or less has) which would cover C (and also most platforms), here's a C#/.NET one, though now outdated, and there's a Perl one on CPAN. I'd expect implementations to continue to appear in more and more languages. Sure, getting the diversity of implementations to the level of XML will take a while, but quickly with implementations in C++, Java, Python, Ruby, C#, PHP, Perl you're already covering a large majority of applications today. Having only an XHTML serialization may have helped with future content, but there's a couple of decades worth of legacy content that will probably never go away: if you want to deal with the majority of web content you're still going to have to deal with HTML. (Equally, if you leave parsing undefined, you still need to run around reverse-engineering browsers, which is not a sustainable approach.)

But I do keep running into situations where I find myself muttering "This would be so much easier if I could just resolve a prolog expression

Perhaps AI::Prolog or Language::Prolog would be helpful. Or you could take advantage of some of Perl's dustier corners and write Prolog-like Perl.

But I do keep running into situations where I find myself muttering "This would be so much easier if I could just resolve a prolog expression

Perhaps AI::Prolog or Language::Prolog would be helpful. Or you could take advantage of some of Perl's dustier corners and write Prolog-like Perl.

http://search.cpan.org/~karasik/Win32-GuiTest-1.56/lib/Win32/GuiTest.pm

Perl has plenty of Windows-specific modules made for this type of application.

Nope, http://search.cpan.org/~rschupp/PAR-Packer-1.004/lib/pp.pm

Oh, I should caveat one thing. In order to develop perl scripts into a distributable, platform independent, one click executable, I've been using the PAR packager module for perl. Sometimes it produces slightly bloated .exe's (since it has to bring in all of the relevant code from any external modules and dependencies), but it seems to produce very stable executables on win32 systems.

..not on third-party apps?
Twitter, meet WWW::Mechanize.
WWW::Mechanize, meet a twat.

I'm offended by your statement that it's impossible to write valid Perl in Latin, and offer this counterexample. Arguably, a Latinised syntax fits it even better than an English-like one; in both Perl and Latin, there's often enough context to put things in a (relatively) arbitrary order. Of course, I'm someone whose signature is an INTERCAL statement, so you may want to take what I've said with that in mind.

I thought you said CPAN. Much confusion.

Looking at another Robots.txt file seems to return what I expect.

Let no rock remain unthrown when it shows Microsoft is in the wrong - even if they aren't

It really depends on what language you write your code in. Object-oriented languages in general require less documentation since good design and properly named methods and properties do document things relatively well .... Perl and C code, on the other hand, can be unmaintainable even with a number of comments, because the old functional design is not easily maintainable. Consider rewriting these in a more modern language.

Perl has support for OO, ranging from the built-in stuff to a full-blown object system like Moose. Perl also has an inline documentation system called POD that bears some similarity to Javadoc. This leads me to conclude that you either don't know what you're talking about, or have been working with very bad Perl programmers.

At my place of work, any code I write is likely going to be maintained for years, perhaps decades; even if it doesn't, someone else is going to end up having to fix something or add a feature, or perhaps it will be deprecated only to be pulled out of retirement later. I typically write a few paragraphs to describe the class (with example instantiation and usage) plus perhaps a sentence or two per method. None of that Javadoc-style documenting every argument and return value separately, though. But I make it decent, because even if the class is relatively simple, it might not be simple in a year's time - and if the documentation isn't there to begin with, future contributors might not bother to add their own.

Try looking at Perl code from 2009 instead.
You can say that Perl code from 2000 and Perl code written today are practically two different programming languages.

Differently from most other languages, Perl is an evolving language.

Just so you can get a clear example, compare the syntax of Perl code written using MooseX::Declare with whatever code you're dealing with:

    http://search.cpan.org/dist/MooseX-Declare/lib/MooseX/Declare.pm

I bet if it wasn't for the dollar signs in front of variable names, you wouldn't even recognize it as Perl.

So, yes, Perl code from the 2000 is mostly crappy. Look for the newer stuff.

PHP does not only what you need it to do, but what all sorts of web visitors want it to do as well. Isn't SQL injection beautiful? Thank you, PHP, for such ingenuities as magic_quotes, lack of placeholder/bindings for SQL (do not tell me to use mysqli, fuck you), and lack of casting (hey man let's invent === and !==, everyone will understand).

Why are you using PHP when you could be using Markup::Perl instead? Seriously. Every time I show coders this module, they stare at it for a while and then ask "...hmm, so what purpose does PHP serve again?"

I've read some posts here talking about APC, memcached, blah blah -- okay, memcached is pretty sweet, but APC is a pile of shit. Stay the fuck away from it, you'll thank me later. But people should be asking themselves: why do we need crap like this? Why do we need "caching daemons" and such added infrastructure (not built-in!) to solve shortcomings of languages? Hell, RRDtool has the same problem with regards to scalability -- Tobi's solution? Better introduce a caching daemon rather than admit the original design sucks balls. You can't polish a turd.

This just circles back to open-source and the incredibly-common-in-the-*IX-community ideal: "don't ever re-invent the wheel. Improve on it". This concept/ideal needs to be taken out and beat with a stick a hundred times over. Re-invent something from scratch if the existing design/implementation surrounding it DOES NOT suit your needs, or does not fit with your modus operandi. "It would be like pooping on poop." -- Triumph.

Sites like cpan.org already do the opposite. They take an author's _publicly visible_ email address and try to find a gravatar for it to publicly display if one's available.

I'd worry more about the continuing relevance of Perl in a niche which has come to be dominated more and more by PHP (eww!) and Ruby in recent years. It's not going away, certainly, but its relevance to the future of computing may be somewhat limited despite its technical merit.

CPAN functionality is available from your perl code (you can issue commands to install/update modules etc without having to start the interactive CPAN shell)

http://search.cpan.org/~andk/CPAN-1.9402/lib/CPAN.pm

Actually there is a procedure for taking over CPAN modules for which the original maintainer won't respond (or is dead, etc.) And if the original maintainer is responsive, but just no longer interested or too busy, they can add you as co-maintainer or transfer the distribution to you directly.

Perl developers know about this thing called CPAN. PHP doesn't even come close in this regard, and you really can't get a better language reference than perldoc. Honestly, if you can't write an app using Perl's built-in functions and the thousands of modules from CPAN, you probably shouldn't be programming. While choice in languages can vary widely according to the individual coder's personal preferences and particular suitability for a given task, the weakness you've cited is imaginary.

you might be interested in ack; http://search.cpan.org/~petdance/ack-1.90/ack-base ; it's written in perl, but it acts like grep for source code (it supports lots of languages); your command there would just be;

ack damnfunctionname

thats it, it'll print out the files and lines that match.

Try PAR.

Perl is only an acronym in certain contexts and PERL is a shibboleth! Fortunately, you can load PERL with this module: http://search.cpan.org/perldoc?Inline::PERL

Have you spent at least 6 months trying to become proficient in Ruby?

Indeed I have. It's a decent language. It has nothing on Perl 6 (and, frankly, it's missing a lot of nice features of Perl 5).

Where do you get proof for that....

Larry's exact quote is "I don't really know much about Python. I only stole its object system." You should have no trouble finding confirmation on the Internet.

Both Ruby 1.8 and 1.9 have severely more powerful OOP constructs than Perl 5.

Nonsense. Compare Perl roles to Ruby monkeypunching.

Perl 6 is "any decade now."

The twenty-second monthly release of Rakudo Perl 6 in a row will take place in two and a half weeks. You're almost two years out of date with respect to your Perl 6 information.

Perl 5 has bolt-on class-based objects. These superficially resemble C++/Java/C#'s classes.

Nonsense.

Ruby has objects resembling the king of OOP: Smalltalk.

Perl 5 objects (using Moose) have more features from Smalltalk than Ruby objects do then. Of course, that's because Moose backported them from Perl 6, which borrowed some of the formalisms from Smalltalk for the design of the particular feature I have in mind.

Ruby has open classes, true exception handling, method_missing(), duck typing, and reflection. Lambdas are truly useful (check out iterators).

Perl 5 has all of those as well. Perl 6 adds built-in support for roles, class finalization, junction types, optional typing, serialization, multi dispatch, and more. You can try them today.

In Perl 5, this is not an error....

... because of Perl 5's type system and Perl's nature as an operator-oriented language. I can understand how this might be confusing if you never learned the language, but it's a deliberate design principle. Don't pretend it's an accident perpetuated by clueless buffoons who never saw the grape-flavored wonder that is Ruby.

Why? Pod kinda sucks compared to the other two.

I've written books in XML and I've written books in PseudoPOD. I don't write books in XML anymore. My company's entire production system uses PseudoPOD.

Perl 5 development is stagnant for one simple reason: Perl 5 is near perfect, there is nothing left to be developed there.

I know you mean well, but despite the fact that it's certainly true that perl5 is a mature language, there's plenty of active development happening in the perl5 world. There were a lot of interesting features added to perl5 with the 5.10 release. Just to pick one, they added recursive regular expressions, which enabled Damian Conway to write this: Regexp::Grammars.

Some wanted better Perl with more consistent syntax. That's what Perl 6 is for. 5.10/etc are intermediate releases serving the purpose of facilitating future migration to Perl 6: some ambiguous constructs of previous version are gone in 5.10/etc.

That's a bit of an over-simplification of what perl6 is about, and there hasn't really been all that much removed with the release of 5.10 (maybe, pseudo-hashes?). The perl-porters care a lot about not breaking live code.

I personally do not care much about 6th - I yet to find any pathological problem in Perl 5 which would persuade me somehow to move to next big thing. Perl 5 is well documented, has piles of modules and examples all over the net. I see no point to move from it.

I'm not waiting with baited breath for perl 6 either, for much the same reasons... though I wouldn't say that perl 6 is uninteresting either. It's one of a handful of Latest Languages that I'd want to take the trouble to learn.

For your first two points, try Padre. For your fourth point, try MooseX::Declare.

I disagree on your third point. Ouch.

Perl probably has the best testing culture out there from the major programming languages, including Java on the list. Between TAP, Perl 5 core's large test suite and a myriad of test related modules it has automated testing well covered.

Did you know for example that when you upload something to CPAN, it gets automatically smoked on dozens of platforms and hundreds of different boxes, test reports sent to the author and assistance provided to diagnose platform specific problems if needed?

Manual testing is for the problems not caught by the huge array of automated tests.

Excel is an SQL-queryable database.

And when I hit "Reply to This", I was merely surmising it was possible to do, not that someone was dumb/bored enough to do it. Nearly 7 years ago, even.

Wow, go-go-gadget misinformation. Mac OS X Server is BSD based, and I've had great success installing any open source project that I needed, using ports, fink, gems, or CPAN if what came with operating system didn't do what I needed.

Also, the vast majority of services available on OS X Server are open source, which Apple does contribute back. So if you don't like how the Server Admin tool works, you can be a r3@l l33t h4xx0r and edit the config files in vi or emacs and do it yourself.

As for the submitter's original question, there are a number of useful tools available for mass deployments of Macs across a network. Tools like radmind, LanRev, Apple's PackageMaker, InstaDMG, and Casper Suite all have varying degrees of management of machine images, image distribution, etc. Also consider at least downloading the PDFs Apple provides for their built in services to learn the ins and outs of their tools allow you to do and not do. You can even modify existing services to use more recent versions of projects that come with OS X if you're missing something or need to upgrade to a newer version for some reason (although this will likely make you have to freeze your OS version in place, or else future updates will probably overwrite your changes.)

Administration of a network of Macs falls somewhere in between an Active Directory environment and a roll your own Linux/BSD network. The client administration is great, but not as comprehensive as Active Directory. However, you still have the freedom to tinker with the services that come with OS X Server and borrow and add capabilities from open source. There are also many other forums out there that have a much lower troll count than what you'll find here, with many knowledgeable and helpful folks who will actually attempt to address and answer your question.

Because seriously, why go to Slashdot if not for the trolling?

Perl has a nice way to generate .exe's from Perl scripts, involving:

cpan -i PAR::Packer

pp -o myprog.exe myprog.pl

The end result is a .exe that can be run directly, no need to install (it unpacks itself then runs). Includes all CPAN libraries that you might use in the script.

See http://search.cpan.org/dist/PAR-Packer/lib/pp.pm - on Windows, install Strawberry Perl, and everything above will 'just work'.

Hi, also take a look at http://search.cpan.org/.

Much is already there, but new good stuff can be, and is, added every day.

Perl is glue.

The GP was apparently talking about PERL, which is a joke programming language in which it's impossible to write maintainable code. You're thinking of the Perl programming language, which allows untrained novices to do useful things while not preventing diligent and careful programmers from writing effective and maintainable code.

You can safely ignore the opinion of anyone who spells the latter PERL.

Javascript did a pretty good job at this

No, it didn't. Google isn't doing anything the spammers couldn't have done themselves with a little bit of Perl.

Indeed.

I mean, I built an identical thing to what they've built (image recognition engine for fixed icons) once using the Perl regular expression engine (mostly just to prove it could be done). It was pretty awesome.

But I have no illusions that it is the sort of thing that I should be promoting on Slashdot. ...oh wait...

First, JavaScript is a very nice language indeed. If you've never learned functional programming, JavaScript is a good language to learn in. Why? You can actually do real work while learning! As for the new language spec...

Getters and setters are nice, but I'm not sure they serve a purpose in javascript--javascript is more functional than it is OO and I think people learning the language should change mindsets rather than the langage get bastardized to something it is not. I dunno, somebody can challenge me on this.

Good to see they are thinking about adding a "use strict". You aren't an adult language until you have a way to force variable declaration. Hopefully "use strict" will apply to a module or block, not to the entire project. I want to "strictify" my own JavaScript, but I dont want the browser to choke on some sloppy copy-and-paste deal from AdSense or analytics.

Lastly, JSON. There are a couple "gotchas" with it... namely when you generate JSON using a loosely typed language like Perl and try to feed it into a strongly typed language like C# (i.e. silverlight). Depending on the serializer / deserializer used on the strongly-typed side, you'll run into things.

For example, the deserializer in C# just might choke on this:
"themes": [ // it will puke on this:
        {
                "theme_id": "34", // i am a string!
                "last_mod": "2009-04-09 13:04:27.232-07" // I am a postgresql date, but I'd also barf on ISO8601
        }, // puke free:
        {
                "theme_id": 34, // I am an int!
                "last_mod": new Date(3000, 00, 01, 00, 00, 00) // i am a legit Date()
        }

]

Why? Perl serialized the integers as a string. Depending on the deseralizer, it might choke on those strings if it was expecting a number. YUI would also be pissed off about the date not being a javascript Date()--good luck finding a serializer that produces such a thing! My point? These are some surprise gotchas you have to worry about when dealing with JSON. Not sure who is to "blame"--perl for being loosely typed, the deserializers for being to strict. This would be a problem with XML as well though.

Here is proof positive of prior art:

http://search.cpan.org/~kulchenko/SOAP-Lite-0.55/

15 Apr 2002

SOAPsh.pl - Interactive shell for SOAP calls

http://search.cpan.org/~nwclark/perl-5.8.9/ext/B/B/Bytecode.pm:

NOTICE

There are also undocumented bugs and options.

THIS CODE IS HIGHLY EXPERIMENTAL. USE AT YOUR OWN RISK.

AUTHORS

Originally written by Malcolm Beattie and modified by Benjamin Stuhl .

Rewritten by Enache Adrian , 2003 a.d.

B::Bytecode is an experimental feature that's been largly abandoned since 2003. Perl5 is too much of a mess to make a bytecode compiler work. That's why Parrot exists.

I thought perl source was considered sufficiently obfuscated that it was safe from reverse-engineering in source form.

If you don't know Perl, you may have difficulty reading programs written in Perl. (I have a similar problem with Mandarin.) If you do know Perl, try B::Deparse for decoding obfuscated Perl.

You can use perl and python for windows.

For example, for perl there's Bundle::Win32

http://search.cpan.org/~jdb/Bundle-libwin32-0.30/libwin32.pm

Useful stuff like: Win32::TieRegistry , Win32::ChangeNotify

But be good and don't write malware. The antivirus people might give up trying to detect perl malware (think about it - polymorphic TMTDOWTDI perl malware...), they might just flag/blacklist perl itself :).

You absolutely need to install the latest perl before you use it - because the perl (or the modules installed with it) installed with your OS is always too old for any particular module you want to install

I've been using perl for about 8 years, and I've never encountered any such problem. For example, I stayed with perl 5.8 for quite a long time before switching to 5.10, and I never had any problem getting CPAN modules to compile.

and even then you have a chance that the module you want is either broken, or depends on a currently broken module.

This isn't a problem with CPAN, it's a problem with the author or maintainer of that module. For instance, I made the mistake of writing an app that depended on Audio::Play and Audio::Data. Then when I switched my desktop machine from BSD to Linux, I found out that I couldn't get it to compile on Linux. I'm a little less naive now. If you check the CPAN bug reporting system, you'll see that there are several important bugs in these modules that are years old, and haven't been fixed. If you look at the reviews on CPAN, you'll see clear signs of trouble. If you go to the parent module's page on cpan, and click on Perl/Platform Version Matrix, you'll see that it fails its test suite on a lot of platforms, on a lot of versions of perl. None of this is a big secret. You just have to do a little bit of homework before you hitch your wagon to a particular CPAN module.

You absolutely need to install the latest perl before you use it - because the perl (or the modules installed with it) installed with your OS is always too old for any particular module you want to install

I've been using perl for about 8 years, and I've never encountered any such problem. For example, I stayed with perl 5.8 for quite a long time before switching to 5.10, and I never had any problem getting CPAN modules to compile.

and even then you have a chance that the module you want is either broken, or depends on a currently broken module.

This isn't a problem with CPAN, it's a problem with the author or maintainer of that module. For instance, I made the mistake of writing an app that depended on Audio::Play and Audio::Data. Then when I switched my desktop machine from BSD to Linux, I found out that I couldn't get it to compile on Linux. I'm a little less naive now. If you check the CPAN bug reporting system, you'll see that there are several important bugs in these modules that are years old, and haven't been fixed. If you look at the reviews on CPAN, you'll see clear signs of trouble. If you go to the parent module's page on cpan, and click on Perl/Platform Version Matrix, you'll see that it fails its test suite on a lot of platforms, on a lot of versions of perl. None of this is a big secret. You just have to do a little bit of homework before you hitch your wagon to a particular CPAN module.

You can already do this now, with Amazon S3 and Brackup

It'll encrypt it, and split up the files, so the owner of the target host can't infer anything from the stuff you store there.

Just don't lose your key :)

I wrote something almost identical years ago, but couldn't since I'm not part of the security community it never really took off. Blacklists were The Thing at the time still...

http://search.cpan.org/~adamk/ThreatNet-DATN2004-0.20/lib/ThreatNet/DATN2004.pm

The test bots are still running in Freenode #threatnet

I say then that projects funded should help ensure that this remains the case. So perhaps more database interfaces for DBI.

What's supposed to be missing? There's around 300 hits on CPAN if you search for DBD.