Stories
Slash Boxes
Comments

SoylentNews is people

posted by martyb on Saturday December 26 2015, @12:11PM   Printer-friendly
from the end-of-lifing-software-is-hard dept.

CGI.pm has been removed from the core Perl distribution. From 5.22, it is no longer included in a standard Perl installation.

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.

This does lead to a small problem for us though. There are plenty of web hosting providers out there who don't have particularly strong Perl support. They will advertise that they support Perl, but that's just because they know that Perl comes as a standard part of the operating system that they run on their servers. They won't do anything to change their installation in any way. Neither you nor I would use a hosting company that works like that – but plenty of people do.

The problem comes when these companies start to deploy an operating system that includes Perl 5.22. All of a sudden, those companies will stop including CGI.pm on their servers. And while we don't want to encourage people to use CGI.pm (or, indeed, the CGI protocol itself) we need to accept that there are thousands of sites out there that have been happily using software based on CGI.pm for years and the owners of these sites will at some point change hosting providers or upgrade their service plan and end up on a server that has Perl 5.22 and doesn't have CGI.pm. And their software will break.


What say you, fellow Soylents? How would you suggest "end-of-life"ing CGI.bin?

Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by TheRaven on Saturday December 26 2015, @02:10PM

    by TheRaven (270) on Saturday December 26 2015, @02:10PM (#281188) Journal

    And why is CGI a "technology that no one should not be using"?

    Ignoring the fact that you inserted a double negative when misquoting, CGI spawns a new process for each request. That means that there's no way to keep state internally to the program between requests and adds considerable overhead. If you don't need to keep any state, then you probably should be statically generating your site. If you do, then keeping all of the state in the database without any caching in the database client is probably not the right thing to do unless absolutely everything that you output comes from the database.

    --
    sudo mod me up
    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 3, Informative) by bzipitidoo on Saturday December 26 2015, @02:34PM

    by bzipitidoo (4388) on Saturday December 26 2015, @02:34PM (#281193) Journal

    FastCGI was one answer to this problem with CGI. FastCGI has been around for at least 15 years now. There is also mod_perl, specifically for Perl programs.

    So, yes, CGI should be retired. Just no reason to use CGI with FastCGI available. The summary could have named some names, instead of saying only that "there are far better ways", and also mentioned how long it has been, so people who don't know will realize FastCGI is plenty mature, it is not a new, untested, unsupported hack, with lots of unfinished work, nor is it a controversial change, like, oh, systemd.

    • (Score: 3, Insightful) by isostatic on Saturday December 26 2015, @09:46PM

      by isostatic (365) on Saturday December 26 2015, @09:46PM (#281284) Journal

      I don't need to scale. I just need to have a simple program executed via a known daemon with known security (Apache) and minimum extras, sometimes called through a web browser, often embedded in a program. I don't need state, I don't need a database, I need to execute a program via a web call.

      Not everything is Facebook. Not everything needs webscale. Not everything needs a framework. CGI.pm has been around for 20ish years, how many times has it been exploited?

      Leave it the fuck alone.

      • (Score: 1) by richardboegli on Saturday December 26 2015, @10:11PM

        by richardboegli (400) on Saturday December 26 2015, @10:11PM (#281292)

        Agreed, if it works and is not a security issue leave it alone.

        Why reinvent the wheel if the original requirements are still bring met by the original solution?

  • (Score: 1) by jamesbond on Saturday December 26 2015, @02:35PM

    by jamesbond (2383) on Saturday December 26 2015, @02:35PM (#281194)

    Yeah double negative typo, I know. Unfortunately I can't edit my post, but I'm glad you catch what I meant to say.

    I know CGI has all those downsides. It doesn't follow though, that *I* should be *prevented* from using it, if I want to - with me accepting all those downsides.

    Same reasons why nobody tries to remove discrete resistors from the shops. Because, it has its place. You won't put a discrete resistors in a production board the size of Raspi Zero. But you won't attempt to use a surface-mount resistor in breadboard too. Everything has its uses.

    So why makes life difficult for everybody by removing that choice? Perl is known for its versatility, there are many ways to do the same thing (even if it's inefficient). CGI is just one of those things. Why the sudden urge to remove that from its toolbox?

    • (Score: 2) by TheRaven on Saturday December 26 2015, @05:25PM

      by TheRaven (270) on Saturday December 26 2015, @05:25PM (#281226) Journal
      Discrete resistors have gone up in price as demand has gone down, so it's a fairly good analogy. The problem is that the cost of maintaining all of the legacy CGI crap isn't been covered by the people using it. As long as people are willing to pay for resistors, it makes sense to keep making and selling them. The people who want CGI, however, are not the ones paying to maintain it. If a codebase is in active development, then moving it to FastCGI or similar is a tiny incremental cost. If it isn't, then the person responsible for it probably isn't willing to invest the time in maintaining CGI support in other things either.
      --
      sudo mod me up
  • (Score: 2) by VLM on Saturday December 26 2015, @02:49PM

    by VLM (445) Subscriber Badge on Saturday December 26 2015, @02:49PM (#281199)

    As hardware speeds increase faster than users requirements, this becomes less important over time.

    Also, being unscalable, its only usable for maybe 95% of the internet, not 100%.

    For something like machine control its laughable. Unless the chinese have infiltrated, my spectrum analyzer at work will never have more than one user at a time, for example.

    • (Score: 2) by TheRaven on Saturday December 26 2015, @05:28PM

      by TheRaven (270) on Saturday December 26 2015, @05:28PM (#281228) Journal
      Your argument would have merit, if not for the fact that CGI also enforces a more difficult programming style. It now might make sense to burn some cycles in exchange for ease of programming, but it makes absolutely no sense to burn cycles in exchange for harder programming and that's what CGI offers.
      --
      sudo mod me up
      • (Score: 0) by Anonymous Coward on Sunday December 27 2015, @03:00AM

        by Anonymous Coward on Sunday December 27 2015, @03:00AM (#281356)

        Suppose one is using/reusing old code.

        • (Score: 2) by TheRaven on Sunday December 27 2015, @09:04AM

          by TheRaven (270) on Sunday December 27 2015, @09:04AM (#281405) Journal
          If you're using old code on the web without doing even basic security auditing... then expect complaints when your machine is used in a botnet to attack other people. If you're adapting it, then adapting CGI code to use FastCGI is usually a fairly trivial change.
          --
          sudo mod me up
  • (Score: 3, Interesting) by Pino P on Saturday December 26 2015, @05:57PM

    by Pino P (4721) on Saturday December 26 2015, @05:57PM (#281233) Journal

    Ignoring the fact that you inserted a double negative when misquoting, CGI spawns a new process for each request. That means that there's no way to keep state internally to the program between requests

    Except that's a good thing because HTTP is also stateless.

    keeping all of the state in the database without any caching in the database client is probably not the right thing to do unless absolutely everything that you output comes from the database.

    Just about everything you see on, say, a SoylentNews comments page comes straight from the database. And in my experience, the database server does its own caching.