use Perl

Why not upload the raw footage to some alt.binaries UseNet newsgroup? I'm not exactly sure which one, but there surely must exist something like alt.binaries.conferences.video or something, right?

Then you (the one with the raw footage) would not have to pay bandwidth costs ad infinitum and it would be easy to link to the files (create an NZB file useful for any "modern" newsreader).

The person in the presentation could then take responsibility for publishing something edited if the ones that did the recording does not find time.

I'm going to assume that if you have the necessary hardware to record a fair amount of video, you also have access to some decent network from which you can upload the material to UseNet. If UseNet is not an alternative, there is always BitTorrent.

Just my 2c.

Now I'm only waiting for Cosimo to fix one bug in Win32::API that is a blocker for installing Padre on 64bit Strawberry and I'm good to go!

The cake is a lie.
The cake is a lie.
The cake is a lie.

You're idea about deployment as easy as PHP is spot on. The PHP concept of a web-based installer is really intuitive to work with for a novice.

I've been pondering this idea here:

http://github.com/robinsmidsrod/unnamed-perl-cms-project/blob/master/README#L82

If the novice could just download and install a web-based CPAN installer/updater to put on their shared hosting account and then just view that UI in their web-browser a lot would be done. To avoid the potential problem of a CPAN compiler fail (or lack of compiler) we could use binary PAR packages customized for the specific platform/distribution.

Obviously, we'd have to build some kind of automatic build system that compiles these binary PAR packages and publishes them in the public PAR repo. I'd suggest a stable/testing/unstable approach as Debian has to give the option of stability level.

The installer could also be configured automatically by pointing it at an URL with a configuration file specific for the application you're planning to use (maybe META.yml?).

If we have this we'd have an easy way of dealing with dependencies and the end user would just have to deal with the actual application installation procedure, not all the complications of using CPAN in a shell (which they are not familiar with, or might not even have access to).

Actually, after a couple of years of learning object-oriented programming at school and reading a really good book about planning (Eat That Frog! 21 Great Ways to Stop Procrastinating and Get More Done in Less Time by Brian Tracy) I have found another method that works remarkably well for me. Go backwards. Visualize the thing you want to build all completed and ready to work. Then pull it apart in large pieces (think nouns in singular). If the piece is still to complex for you to totally understand, pull it apart even more. Once you are finished picking the thing apart into understandable pieces you can actually start to think about what each piece does (those are your methods). Then the last part is just to assemble all of those pieces together like Lego bricks and you should have something that does what you wanted.

I look forward to seeing this data aggregated (like you suggest) some way in CPANDB.

Have you tried Linux::Smaps?

From the CPAN description: "The /proc/PID/smaps files in modern linuxes provides very detailed information about a processes memory consumption. It particularly includes a way to estimate the effect of copy-on-write. This module implements a Perl interface."

Does this only work with mod_perl-based software (I would think so), or can you use it with CGI-based dispatch?

Found this little thing that might interest you about one of the t/pty.t bugs. http://www.simplicidade.org/notes/archives/2007/01/graphviz_under.html It seems that the "bug" is still present in IPC-Run-0.83. I don't have access to a MacOSX machine, but maybe someone else can verify if it FAILs or PASSes.

The fact that you're looking for 'command.com' on Vista (which is no longer shipped with the OS) makes it fail for me. See more here: http://padre.perlide.org/trac/ticket/252#comment:6