mock

I don't think we really disagree all that much. I think the problem is really that content publishers have been dishonest about what they're selling. When I "buy" a DVD what have I actually bought? What does my mom think I've bought? This difference is I think what fuels the gasps of shock and horror at the size of the damages when it inevitably goes to court. The rental car on the other hand, isn't sold as a bait-and-switch.

Where we differ however, is that I don't see attempting to coercively redefine the contract as any less legitimate. If the law is an ass, especially if the law is an ass and has been completely captured by moneyed interests, then disobeying the law en masse until the weight of numbers brings the law into disrepute seems far more likely to push change (at least in this case) than passively boycotting.

(FWIW I also believe in jury nullification, which should give you an idea where I stand in the push and pull of rule-of-law vs will-of-the-people)

By using technology to put the power to coercively redefine the contract in the hands of the people, the content controller/producers are put in a squeeze. People don't have to pay them any more (which hits them in the wallet) - to fight that they will have to spend ever increasing amounts of money to buy laws and DRM technology. As they do so they will increasingly damage the economic and legal systems they depend upon by becoming ever more draconian, causing ever more collateral damage, with predictable consequences. It seems to me like a case of classic asymmetric warfare, and why they'll lose (or end up so changed from the fight that they'll wish they had).

I'm not sure that the cognitive dissonance is in the ease of committing the tort, rather, I suspect that "intellectual property" doesn't really fit most (non-technical) people's concept of what ought to be tortable. For most non-technical people (my mom, for example), having a thing implies the right to share it. When we treat a song or a piece of software or a movie as a "thing" we feed into this conception. Of course we, as technical people, know that it isn't really a thing. That in fact it's a licensing agreement granting you the limited ability to use information in certain ways. But that idea is complex, and not really well understood by most people (even technical people), and so we abstract it as "a thing" (intellectual property).

So when some poor soul winds up incurring 60k of damages just for clicking a button to trade "free" music of course this comes as a surprise. All of a sudden their mental model of "things" has broken down with no real warning that the level of damage could hit such extremes so quickly or that a harm was even being committed.

If we lived in a just society, the law would be re-evaluated to fit the ideas of right and wrong commonly held by the people (including content creators of course). Instead we will attempt to force a lossy abstraction on everyone and accept the inevitable unjust consequences.

While I agree that being an asshole is more frequently harmful than helpful, I don't think the behaviour in question here is actually assholic in nature. Every community needs to have a way of enforcing community values or that community will dissolve. That enforcement can be a police officer, a drill sergeant, a moderator, or just a loud mouthed member of the community that expresses the group's scorn for the behaviour in question.

What is important is that everyone who witnesses the policeman deliver a lecture to delinquent teens, the sergeant chew out a new recruit, the moderator remove a troll or flamebait, or the loud mouth deliver an invective laced screed to the newbie who just doesn't get it, gets the message that "certain behaviours aren't tolerated here" and by extension, other (more polite) behaviours are.

When the policeman gives you the nod on the street corner on your way to work, when the sergeant says, "Nice work", when the moderator uses something you wrote as an example of what a good post looks like, or when the community loudmouth bastard says "SHUT UP AND PAY ATTENTION TO HIM" and you realize he's talking about you - that's the point when you realize you're part of the community.

Lots of us use Perl these days. For example those of us that care about speed, stability, and sane backwards compatibility. WWW::Mechanize is still a great tool when appropriate. Catalyst and Moose are pretty awesome to work with as well. I'm pretty happy with the state of Perl these days, there are lots of reasons to recommend it, but if Python works for you, that's cool too.

Slightly more on topic - when Ovid first posted this to his feed, Stevan Little pointed out that you could already do it in Perl 5 ( http://gist.github.com/268717 ). Watching the give and take between the Perl 6 language and the Modern Perl movement is (I think) one of the more interesting and exciting areas of language development these days.

Lots of stuff that's built in Perl, doesn't really advertise itself as such. From my own experience in building products over the last 5 years, MailChannels Traffic Control ( http://mailchannels.com/product/ ) is built in Perl with some C where stuff needs to be speedier and Enquisite's products ( http://www.enquisite.com/products/ ) are all heavily Perl based on the back end with Flex RIA front ends.

I'm currently working on a new startup that's built in Perl as well. I picked it because I have lots of experience with the language (and as usual, I'm doing something "tricky" where a solid understanding of the language will really help), it deals well with the problem domain I'm working on, and I need both a good web framework (Catalyst), a backend job queuing and processing system (POE) plus a bunch of infrastructure bits that are conveniently already on CPAN. I've also noticed that finding good Perl people to work with has never been much of a problem, but that may just be an artifact of location (Vancouver/Victoria) and previous experience (I know a lot of ex-ActiveStaters). My experience has been that some of the more hyped languages/frameworks have a lot of snakeoil salesmen jumping on their bandwagon, which can make it tricky to discern the talented from the talkers.

One of the problems that the Perl community has (I think) is a lot of us don't really hype Perl that much as being the driving force behind some of the cool products we build in the same way that the Rails community, or some of the more "popular" frameworks/language communities do. This can lead to the appearance to outsiders that we're not innovating and that cool stuff isn't made in our favourite language. Rest assured, we are; it is.

The common case is not being bound by privacy law, but rather having a pr/marketing/sales challenge due to customer fears of the patriot act being used to nab data in the US. Your service allows me to give them a solid answer as to why that risk has been mitigated while simultaneously maintaining the advantages of S3. If you offered Canada only hosting it would be better still, but I'm not holding my breath waiting for a major cloud provider to offer entirely Canadian hosting.

I have a number of clients who can't keep their data in the US due to privacy considerations. Sadly, I can't send them to you until you accept Canadian customers. Which is unfortunate, as it's typically Canadian organizations that have this privacy issue with US backup providers.

(I recognize why you've made the decision that you did, but it is definitely preventing you from getting a certain class of customer who really actually cares about what you're selling vs other backup storage providers)

Because as a PHP programmer Perl will have areas of familiarity which may make the learning process easier. In return, you will gain a greater appreaciation for why the PHP developers made the decisions they did by seeing how it was done in a language they borrowed heavily from. As a bonus you'll learn to use a language that is ubiquitous in all sorts of sysadmin tasks, and have another tool that you can use when PHP isn't the right one for the job. Finally, knowing Perl will allow you to use the huge wealth of CPAN modules available to help you solve almost any task. At worst it will enable you to port them to your language of choice.

I'd say no it isn't in the aggregate harder. There are a few of forces at play that I think lead to this.

First of all you can now buy pretty good hacking tools in a can (CANVAS, Core Impact) that come complete with non public exploits. If you don't have the money, metasploit is pretty good as well. This drastically reduces the need to know the details of a particular exploit, and reduces the amount of toolsmithing required to pull off a penetration. Also, the reality is that exploits are now a business - they're for sale, for better or for worse, on the open market. If there's one thing our PWN2OWN competition at cansecwest proved, it's that for a sufficient amount of money someone will find you a hole in anything. If you have money, even if you're not that knowledgeable, being a blackhat isn't that hard.

Second, there is more stuff to exploit now than there has ever been before, both on and off the net (I'm looking at you SCADA). At least some of that stuff will be low hanging fruit built by programmers who either did not understand how to build secure systems, or didn't expect that those systems would be reachable in the way they are now. As the internet expands, and stuff keeps getting more smarts added to it, I think there is probably a trend in which new insecure stuff is being built faster than the old stuff is being secured (not that I can prove that). Things that previously weren't considered to be security critical, now are (XSS is still barely considered a "real" exploit).

Third, information about exploits, how to write exploits, and how to find vulnerabilities is now massively more available, both because of the change in philosophy around full disclosure, and because we now have more than a decade (two maybe?) of open research into the field. Bugtraq can be argued to have revolutionized security research because it opened up what was previously secret to the eyes of interested amateurs and academics. Today there is a community of security researchers who openly publish information that previously was only the domain of governments and the occasional large defence contractor. I think probably the public community is better at it too.

Balanced against this is all the research and technology on the defensive side (also helped by full disclosure), the forced public shaming to fix-their-broken-shit of various vendors (full disclosure again), and generally better knowledge of security best practices (anyone want to guess what I attribute this to?). All of which is to say that the things that worked 20 years ago are harder today than they were 20 years ago (social engineering sadly seems to be just as easy, and if anything more prevalent now) but it hardly seems to matter since lots more is easy now.

I Absolutely agree with regards to web frameworks. But there's a time and a place for apache modules, and mod_perl is definitely the tool for that job.

mod_perl2 is really difficult to beat if you need to dig into the guts of Apache. DBIx::Class is a huge win if you need/want an ORM but you've been given a really weird pre-existing DB schema. POE has been around forever, and makes really stable long running daemons that don't have to be babied. CPAN has stupid amount of tools for automating sysadmin tasks, all of which you'll probably end up using once, putting in a cronjob somewhere and forgetting about because it will just work. Any time you need to deal with something old, or weird, or both there's probably a CPAN module for that, you can find it via search, and it probably has tests and docs. Template Toolkit for creating uglyass text is both nice to use and full featured (if you don't want to go down the XSLT hole). I've also found that Perl handles I18N, unicode and uglier things (like shift-jis) fairly well. Almost every payment processor has a module, and they all have a standard(ish) API, so they're mostly interchangeable. Likewise crypto stuff is fairly standardized and pretty complete. In general, if you have to tie something to something else that's weird, Perl is a good bet (because someone has probably done it, put it on CPAN, and documented it).

That's a few of the problems I think it stands out as a great tool for.

Please stop using Perl.

Perl has been my startups' secret weapon, and I'd rather the competition didn't know about it. Perl let us deal with large volumes of data, at high throughput (there are several ISPs, Universities, and fortune 500 which use our product to protect their mail infrastructure from DDoS and Spam). At a former company it let us collect, parse, store, audit, and make predictions against millions of web hits per day, in close to real time, with cheap infrastructure. Perl has been solidly stable - it just runs - keeping our ecommerce infrastructure making money.

It has had few security issues over the years. It has had few backwards incompatibilities between versions over the years. As a component of our products, it's given me relatively little pain in performance, reliability and security. Development wise, I can't count the amount of time we've saved over the years thanks to not having to reimplement something because it's on CPAN, with a sensible license, with doumentation, tests, and in an easy to find and search location. As for code quality, Perl has great support for testing, support for automating code review (Perl::Critic), and a community of developers that are constantly making things better - but without breaking things that worked in the past (Moose has done amazing things for refactoring ugly OOP code, and you can use it with any of the other older OOP stuff).

I use it because it works well, seldom breaks, and causes me less hassle than anything else I've tried (C, Java, Python, PHP, Ruby). I've spent serious time with this language; I've maintained ugly old code from 10 years ago, and giant million++ line projects written in it. It has warts, sure, but what doesn't? I don't care; it's reliable. Big jobs, little jobs - it gets the job done. And that, to me, is more important than high minded ideals about aesthetics and purity.