Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

· "Programming the Apache Lifecycle."
· OSCON
· stas
· More Wishlist stories
· Also by hfb

mod_perl Presence Dying at OSCON

posted by hfb on 2004.06.08 0:21   Printer-friendly
Wishlist
stas writes "It appears that in the last few years we have had fewer and fewer mod_perl talks and tutorials at the big (non-YAPC) conferences. And that's a bad trend. It certainly affects the number of mod_perl job offers, since those who decide which technology to choose for their next project go to those big conferences and chances are very high that they will pick the technology that had a dominating presence in terms of tutorials and presentations."
"How can you change that? Go to the big (non-YAPC) conferences and especially to mod_perl tutorials. Since conference organizers get a lion's chunk of their revenues (even if only to cut it even) from the tutorials, that's where the battle is. The fewer tutorials on the mod_perl technology you have, the fewer mod_perl presentations and overall presence will be, the fewer new mod_perl jobs will be created.

This year mod_perl's presence at OSCON really sucks. We have two tutorials which are under a question that will happen at all and just one mod_perl presentation. Plus a few more related presentations of technologies riding mod_perl. Just a few years ago, we had about 25 tutorials and presentations. If some of the mod_perl tutorials will be canceled this year, don't expect the conference organisers giving them a second chance next year, which brings us pretty close to a zero presence. And that's a gloomy future if you ask me.

So if you want to change things, go to your bosses and ask them to send you to the tutorials. If they can't afford two, make it one and make that choice Geoffrey Young's "Programming the Apache Lifecycle." Why Geoffrey's? It's because the stuff I'm going to teach you at my tutorial is ready available in the online documentation and you can read it by yourself. But not so for Geoff's unique material. And all those who have ever heard Geoff presenting, will agree with me, that he is one of the best speakers OSCON (and other conferences) ever had and most of us, speakers, need to learn from Geoff. I'd go for Geoff's talk just for the great experience, even though I know most of the material he presents. His tutorial will be covering both mp1 and mp2 if you didn't know.

So if you enjoy your mod_perl job and want to continue so in the future, make sure that you come to the mod_perl tutorials and presentations at OSCON and other big conferences.

p.s. the deadline for tutorial cutoffs (at least 20 attendees) is June 21th. So if you were planning to go to the tutorials, make sure you register (or add the tutorials if you already did) before that date."

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

mod_perl Presence Dying at OSCON 25 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.

  • I wonder if one thing holding people back on mod_perl is uncertainty as Apache and mod_perl move to version 2. I know that I personally don't even understand anymore which version of Apache is current and if version 2 is considered to be "released." I've been hearing about version 2 since 2001 or so, but it still seems to be the "development" version. And I hear vaguely that version 2 changes a lot of things, so this may have contributed to the fact that I haven't investigated mod_perl, yet. Perhaps man

    --
    J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers

    • Hey, how about a poll on the subject? How long has it been since use Perl; had a poll?

      What's holding you back from getting into mod_perl development:

      • Uncertainty about which version of Apache and mod_perl is current (fear of learning a technology only to watch it change)
      • Unaware of what benefit mod_perl provides
      • Aware of mod_perl's benefits but my work is not web-based
      • Tried mod_perl and it was unable to figure it out on my own
      • I write my Apache extensions in C (or Parrot, or whatever)
      • I'm such a procra
      --
      J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
    • We are almost there with 2.0.

      I'm currently working on finalizing the API. That means - getting *all* of the API fully tested and documented. I think I'm about half way through.

      Once this is done, there will be an API freeze. Then we need to fix a few remaining bugs (listed in todo/release file in the source distro) and then we will start releasing release candidates.

      I really hope to get most of this done somewhere this summer. Of course if we get help we can accomplish that faster. But so far noone has of
      --

      Stas Bekman [stason.org] of

      • Sadly, there is still a big uncertainty what the entire point of apache 2, aside from furious wanking from the apache foundation, is. Yes, users of inferior operating systems will see a big speed improvement, but if you don't, there is no point as far as I can see.
        --
        sky
        • Well, TPF has Perl6, the Apache Foundation has apache2/mod_perl2....but there are still p5 and apache/mod_perl to consider. Glass houses all around the village square.
          • Indeed, I do however fail to see how this answer relates to my question. What is the point of apache 2? Please do not get into a point of what perl 6 is, because I cannot answer that.
            --
            sky
            • Well, considering I'm in the camp of folks who don't really think there is an inherent meaning or point to life itself aside from the basics of life and reproduction, I'm probably not the best person to give an answer other than what folks give as a reason or justification for climbing Mt. Evererst: Because they can. If everything you did had a point to it, life would be rather dull.
              • Surely, the point of life is to argue endlesslessssly in different forums?
                --
                sky
                • Naw, it just keeps you occupied instead of bothering the rest of the planet who couldn't care less. :) Having a purpose doesn't usually imply a point.
  • I wanted to learn mod_perl but finding a cheap hosting company for mod_perl is *nigh* impossible while PHP is ruling the roost there. All the ISP's that have Perl in a CGI configuration have PHP in a mod_php configuration. That needs to change but probably won't. All the posts I read is mod_perl is a bear to configure properly and so ISP's won't (or don't) do it. I could be wrong but my experience shows not.
  • It may be that people are using mod_perl for the simplest of reasons (faster scripts and persistent database connections) so they feel they don't need more tutorials.
  • I think part of it just comes down to competition, really.

    Geoffrey's tutorial, for example, is up against both Damian Conway and MJD, which can't be helping things. Then you have the RT tutorial, which as a mod_perl application is probably siphoning away potential attendees.

    I'll be at the "Patterns In Perl" tutorial during that time frame. In a perfect world I'd like to see Geoffrey's tutorial -- it's just a case of too many tutorials, and only one of me.

    -Matt

  • Low-end users are flocking to PHP, as most ISP's are equipped with mod_php and there's a short learning curve.

    Users who want more of a full-blown application server or a framework for building a large-scale application like a CMS tend to consider Zope.

    Unfortunately, mod_perl seems to be squeezed in the middle, and the particular slice seems to be getting smaller...

    I'd love to see a Zope equivalent in Perl. The closest things I can think of are POE and Maypole. Both POE and Maypole are wonderful, but are
    • Java is a much more serious competitor than Zope. No one has built anything the size of Ticketmaster.com in Zope.
  • Although there is a further speed increase as a result of have the Perl forker running in the Apache process, I've found SpeedyCGI/PersistentPerl [daemoninc.com] to be a much easier solution than mod_perl itself. It can be installed without mucking with the apache conf file, can exist w/o being root, works for non-CGI scripts (can be used from the command line), and is overall much simpler (for me at least) to grok. I hope mod_perl continues its development and continues to be popular, but I think discussion of "mod_perl"
    • SpeedyCGI and PersistentPerl are replacements for only the part of mod_perl using Apache::Registry. But Apache::Registry is but a teeny tiny part of mod_perl. You owe it to yourself to explore the other 80% of mod_perl and see what you're missing. (Hint, it's not just the content phase!)
      --
      • Randal L. Schwartz
      • Stonehenge
  • For me, as with many I'm sure, the whole questions is whether I can *go* to the conference. If I wind up being able to go, then heck yeah, I'm all over the mod_perl tutorials, but I have to actually get there first.
  • I love mod_perl, but it's horrible. I love it because I know it well, it's very powerful. I've developed in it for years and therefor I have my own set of libraries and standard development methodologies that I have developed over the years that let me quickly write applications that are flexible and powerful. Unfortunatley that doesn't change the fact that for most people, mod_perl sucks.

    As I recently wrote in a post to the mod_perl advocacy mailing list:

    Mod_perl apps are too hard. Too hard to wri

  • i am a system administrator, not a programmer, and experience has taught me to go as far out of my way as feasible to resist mod_perl being installed on any machines that i'm responsible for.

    why?

    * mod_perl is the only thing i've ever used which makes apache segfault.
    * mod_perl is significantly harder to debug then cgi or even php.
    * with mod_perl my developers can bring down the entire web server with some casually bad code, and *i* have to track it down, proove that it was them and make them fix their cod
    • * mod_perl is the only thing i've ever used which makes apache segfault.

      It's true it can, but shouldn't. Perl rarely segfaults unless it has bad .xs libraries behind it although I think there are still some issues with bad sort subroutines doing it. If perl segfaults, apache segfaults since with mod_perl they are the same process.

      * mod_perl is significantly harder to debug then cgi or even php.

      Yup. It can be.

      * with mod_perl my developers can bring down the entire web server with some casually b

    • Hmm, sounds like you have a situtation that is a little bit too wild west. Maybe some better testing and configuration management practices would help. If you'd like suggestions on how to improve the safety of mod_perl, you're welcome to ask questions on the mailing list.

      mod_perl is the only thing i've ever used which makes apache segfault.

      Bugs in C code are what make apache segfault. That can be PHP extensions, Perl modules with XS code, C modules, etc. Segfault bugs in mod_perl itself are very rar

      • Hmm, sounds like you have a situtation that is a little bit too wild west. Maybe some better testing and configuration management practices would help. If you'd like suggestions on how to improve the safety of mod_perl, you're welcome to ask questions on the mailing list.

        I totally agree, it is too wild west but I'm just the sysadmin not the manager, not the team lead. I encourage proper configuration management procedures at every place I work but you don't always have supportive managment and sometimes

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.