Hacker News new | comments | ask | show | jobs | submit login
The Long Death of CGI.pm (perlhacks.com)
33 points by davorg on Dec 18, 2015 | hide | past | web | favorite | 34 comments



What's the strange bad-mouthing of Red Hat in this article? Upstream Perl comes with dozens of modules in the base tarball, and the packaging just splits that into separate RPMs so you can have more minimal installs. If you really want to install all the modules from the upstream tarball, you install perl-core which is a meta-package that pulls in everything. You can install CGI.pm either by:

    yum install 'perl(CGI)'
or by:

    yum install perl-core
and this works on Fedora and RHEL (I just checked).

The article claims it's not really what you would recognise as Perl and Red Hat [strips] out many parts of Perl that they consider non-essential both of which are plainly untrue.


Yes. And I mention both of those commands in the article.

The point is that the standard perl RPM does not contain everything that you would expect to see in a Perl installation. And whilst I agree that it is simple enough to fix that situation, many people running low-end web hosting services don't realise that the standard Perl installation is stripped back and don't do anything to rectify this - as demonstrated by the example in my article.

I really don't mind Red Hat providing a standard stripped-down Perl RPM. I just wish they had called it "perl-minimal" or something like that, saving the name "perl" for the full Perl RPM.


Well file a bug, I guess. The problem IMO is with the upstream Perl tarball which contains an ever increasing set of modules. The RPM packaging is (also IMHO) more rational.

The problem with dumb hosting providers is dumb hosting providers. I'm sure they'll find other ways to screw things up even if the package name was changed. Who uses web hosting these days anyway, when you can fire up a cloud instance and install whatever you like?


> Well file a bug, I guess.

That's not going to fix Centos 6 and 7 - both of which are mainstream in the web hosting industry right now.

And I've had this conversation with the Red Hat Perl packagers. They can't see the problem.

> The RPM packaging is (also IMHO) more rational.

To be clear, I also like the way that Red Hat splits the Perl RPM into individual RPMs for each module. My argument is only with the set of these RPMs that are installed alongside the main perl RPM.

> Who uses web hosting these days anyway, when you can fire up a cloud instance and install whatever you like?

Not you and me, of course. But I'm talking about people with no technical knowledge who rent some cheap web space and run a CGI guestbook program.

We could just ignore them. I suppose. Let them all switch to PHP. To be honest, I think most of them have already gone down that route.


> the upstream Perl tarball […] contains an ever increasing set of modules

I don't think this is true. I count a total of 6 modules added and 10 removed in stable releases of Perl from 5.12.0 (that is, since Perl adopted its current release-management process). Corrections welcome if I'm miscounting, of course.


TFA bad-mouths CGI, so let me ask: The only server-side technologies widely available on shared-hosting providers seem to be CGI and mod_php. What else are people supposed to use? Are you simply not worthy anymore unless you're willing to spring for a VPS?


Honestly, for low end stuff, mod_php is fine. I've just spent the day beating some circa y2k perl code into submission on a modern shared hosting platform too. That's sort of fine too (helps that I'm an expert and know how to make debugging the PoS easy).

Wordpress is an OK product. On the other hand I reckon php is a bad technology to stake your career on. Perl less so, bear in mind it's been around for several waves of the latest greatest thing and is still going strong. Still I quite enjoy javascript sometimes, it's like a syntactically crippled perl with good vendor support. Perl6 looks cool, I hope I get the opportunity to mess with its async stuff.


> Honestly, for low end stuff, mod_php is fine.

Then again, so's GCI.


Though all the forking of standard CGI makes it far less efficient, which is quite a concern to a cheap shared hosting provider in a saturated market: they need to cram as many accounts as possible on as few machines as possible to have any hope of not running the business at a loss.

Fast_CGI helps here of course, but then you have your users needing to be able to create long lived processes which moves the problem to one of memory use and process cycling & other management.


fwiw I'm currently working on tools to port a fastcgi perl cgi script to a more modern infrastructure, for money. I'll try and work up the fun bits into an article in due course.


Yeah, but Plack::Request/Response is a better API to the same for low end stuff and will expand to bigger things as required.


"At some point Perl 5.22 or one of its successors will make it into Red Hat Enterprise Linux. And at that point we have a problem."

This made me laugh this morning, version 5.22 will probably be included in the 8.0 release? So we have a few years to go. RedHat 6.* is still running Perl 5.10 so no worries about anything breaking in the next 5> years.

Edit: formatting


Further on, the article mentions that Red Hat actually already removed CGI.pm from the default installation of RHEL 6, because they install a stripped-down version of Perl.


Which is nonsense. Red Hat split up the perl package so you can install the modules separately.


It's not nonsense. That is what they do.

And, yes, it's easy enough to fix that (pointing that out was one of the main points of my article). But we're talking about low-end web hosting services where the web site owners don't have the root access to do that and the service providers either don't know what is missing or don't care about Perl enough to bother fixing it.


They also removed CPAN which is a pain in the ass.


As long as CGI is still available from CPAN, I don't really mind.

But I still think CGI scripts have their place, and I have written a bunch over the last two years at our company. I get that CGI has a number of problems, but for simple tasks I think it's a completely acceptable solution.

(Just to be clear, I am talking of CGI as in "web server calling an external program through a defined interface", not the HTML-generating stuff in Perl's CGI module - my scripts use Template::Toolkit for generating HTML.)


> There are good technical reasons for this. CGI is a dying technology. In 2015, there are far better ways to write web applications in Perl. We don’t want to be seen to encourage the use of a technology which no-one should be using.

I don't see the harm in including it. I would think it was enough to document the disadvantages.


That was a conversation that was finished 18 months ago. I'm not sure that anything can be gained by rehashing it. The best we can do is deal with the consequences.

The discussion is at http://www.nntp.perl.org/group/perl.perl5.porters/2013/05/ms... if you want the full details. But ultimately, I think they decided that having the module in the core was tantamount to a recommendation for its use.


I suppose you might want to use CGI.pm for some low level stuff but I find I can still get most of what I need by copy and pasting stuff from Matt's CGI scripts (http://www.scriptarchive.com/).


Consider using the "Not Matt's Script" versions (http://nms-cgi.sourceforge.net/news.html), but even that was last updated 2004. MSA was notorious for very bad examples of old-style perl, and there are much better ways of doing perl nowadays.

For a much more modern approach, use Plack/PSGI, and one of the many frameworks built using it.


The really galling thing is that Matt's scripts will continue to work find in this post-CGI world. The nms versions were written to the best practices of 2000 and therefore need CGI.pm.


Actually Matt's stuff DOESN'T use CGI.pm (at least what I'm familiar with). That was the thing - even when CGI.pm was the Better Practice, Matt didn't use it.

No one should use Matt's stuff, unless you want huge security exploits.


> Actually Matt's stuff DOESN'T use CGI.pm

Yes. That's the point I was making.


I really, really hope that this is simply a joke in bad taste.

Mind you, Matt's CGI scripts are no worse than a lot of PHP that is floating around these days...


Please don't promote matts script archive. It is responsible for tons of terrible, out dated perl code due to its (previously) high search ranking.


I thought this was well known enough everyone would get the joke. In fact, I was surprised to see Matt's scripts were still kicking around on a website other than the wayback archive.


I laughed.

(I came to make a cgi-lib.pl compatibility mode gag, but your joke was better...)


Is there anything I can't do in Swift? Perl is super cool, but Swift seems like it can now be used on most of your text parsing and big data crunching needs (DNA, lab R&D, etc) now.

And it was everyone's first web language in the day. I was super impressed when ran my first perl script. I was hooked. :-)


I'm a big fan of Swift 2.x and am doing most of my programming lately in either it or Perl. The two languages compliment each other very well. Lazy properties work as well in Swift as they do in Moose/Moo and handling options with the if let pattern fits well with the standard Perl if (my $var = ...) pattern. I can go on about some of the other things I've noticed but I'll leave it at those two.

As such, I think the answer to your question is eventually you'll have the same depth is Swift that the Perl community has but so far Swift is still behind in tooling and libraries for many things. Since server side Swift on Linux is weeks old, there isn't a simple well known go to library for web work like CGI.pm, or my preference for simple web services, Web::Simple. And of course if Windows is something you need to support Swift won't help you.


> Is there anything I can't do in Swift?

You can't do nostalgia for the good ol' days in Swift.


Ahhh, do you remember back in May, before Swift 2 came out? Good times man!

(I remember when my first eCommerce site broke when my webhost upgraded from Perl 4...)


> Is there anything I can't do in Swift?

Web pages on shared hosts without a swift compiler, which would be more or less all of them?


Why would you need the compiler on the host? Compile on a VM running the same OS and upload. If you're going to use swift to write your webapp I'm sure that's not too technical.




Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: