1. 50
  1.  

  2. 33

    They’re more popular than ever, as AWS Lambda.

    1. 27

      If I was good at writing satire, I would write a satire article that is a CGI scripting tutorial, but never use the word CGI and instead call it a “new Open Source function as a service library”.

      Similar twist: “Hi folks, I wrote a new library that converts JVM byte code to WebAssembly. For the first time ever, we can write Java that runs in the browser! Never before seen!”

      1. 11

        They are both stack machines, so it should be simple enough I guess. Don’t give me ideas.

        1. 5

          Do it.

        2. 3

          I started trying to write this article a while back, not as satire, but as a direct comparison to the evolution of serverless. But then I realized it’s probably been done better than I could do and aborted.

          1. 7

            I have literally never not published something just because I think it might have been done. If I see something that is almost entirely what I wrote, sure, I’ll axe it. (Even retroactively, in one case, where I read someone else with a better take and thought, “oh, never mind then.”) But if I haven’t specifically read an article of what I want to write, then:

            1. I might have a unique take after all.
            2. Even if my take isn’t unique, it might be different enough to be helpful to someone else.
            3. Even if it’s neither unique nor different enough, if I’m not aware of it (and after deliberately cursory search can’t find it, if applicable), it will likely reach a different audience.

            In the draft post you’ve got, I think you are heading in a good direction, and it might be worth continuing. I’d suggest dropping the FastCGI/SCGI/WSGI/Rack section in favor of diving a lot more into early attempts to speed up CGI requests and how those relate to lambdas (you touch on mod_perl, but I’d also at least touch on PHP in particular, and quite possibly AOLServer, as close peers), highlighting similar issues with startup time and how lambdas are trying to solve them in their own ways/differently.

            The other way to approach this kind of thing, incidentally, which I like for my equivalent writings on these axes, is to walk through how trying to solve the problems with the old old-and-busted resulted in the new old-and-busted. You can write that kind of article sarcastically, but you definitely don’t have to; my article comparing Win32 to Flux has a bit of humor in it, but I deliberately avoided anything past that. If you went that route, the FastCGI/SCGI section fits better, but also pairs very nicely with talking about things like the Danga Interactive products (Gearman, memcache, Perlbal, etc.), which turn out to be necessarily reinvented whenever a PaaS-like environment is used.

            Anyway, all this to say: I’d love to see someone actually write a post along these lines. If you really don’t want to finish yours, you’ve given me half a mind to take my own stab.

          2. 3

            I have that as a laptop sticker. I don’t know if commercial advertising on lobste.rs is appropriate (even for an enterprise which makes me on the order of $2/month) so I won’t link it directly, but you could probably find it quite easily by searching redbubble.com for “serverless cgi-bin”

            There is the reasonable objection that using a FaaS platform you have the expectation that it will autoscale to performance levels far in excess of anything that cgi-bin of yore managed, but really, that’s a implementation detail not an attribute of the API

            1. 2

              Kelsey Hightower made a similar comparison at Gophercon: https://youtu.be/U7glyWYj4qg

              1. 2

                “This is xinetd… the new hotness”

                Love it.

          3. 25

            I am confused by the use of the past tense here.

            1. 8

              One of the best things in CGI in that era was CGI.pm which lived in Perl’s standard distribution from 1997 to 2015. The docs alone are still pretty amazing. Combined with taint mode it could sometimes lead to rather safe programming practices. And yes it is funny how much aws lambda, etc feel like a rehash, but ideally in a good way.

              docs: https://metacpan.org/pod/release/LDS/CGI.pm-3.05/CGI.pm

              perl taint: https://docstore.mik.ua/orelly/linux/cgi/ch08_04.htm

              For truly learning about how simple CGI is I think writing an unsafe cgi handler in c is a good way as per this example: http://jkorpela.fi/forms/cgic.html

              1. 3

                Combined with taint mode it could sometimes lead to rather safe programming practices.

                Until programming turned into copy and paste from Stack Exchange and everyone “fixed” tainted input with =~ /.*/

                1. 2

                  Before that, programming was copy and past from Matt’s Script Archives, so it’s not like things have gotten significantly worse.

              2. 7

                While the mechanisms for running them now allow the code to stay resident in memory between requests, Python’s WSGI – which is the standard gateway interface for Python web apps – is still very CGI-ish.

                The signature of a WSGI application is:

                def application(environ, start_response)
                

                Where:

                • environ is a dict (hash table) of the request environment, using many of the same standard keys as CGI.
                • start_response is a function that’s called to send the response status and headers.
                • The return value is an iterable which will yield the response body.

                Python web frameworks tend to hide this behind their own request/response abstractions and nicer life-cycle management, but under the hood it’s still the CGI programming model.

                1. 8

                  I’m not sure if it’s appropriate to talk about CGI like it’s dead. OpenBSD ships slowcgi(8) and their man page viewer in mandoc is a genuine CGI application. The BCHS people endorse pure CGI with C, too.

                  (Whether these are good ideas is another story, but they exist right now.)

                  1. 5

                    I use them for a couple things (the order form on https://atreus.technomancy.us being one of them), and they’re fantastically useful for sites like that which can be 99% static. I wish more people realized that not everything has to be full of moving parts everywhere.

                    1. 3

                      Whenever I have some sort of local web thing, I still use CGI. It’s easy and, like you say, works well when the site is mostly static. Adding all that other stuff seems like a complete waste.

                    2. 4

                      Author does write

                      CGI scripting was undoubtedly useful and continues to be useful for small scale web applications, such as developer utilities, simple form data collection and local intranet tools.

                      (my emphasis)

                      1. 1

                        Oh, I see. My bad. I skimmed the article too quickly.

                      2. 2

                        In the first draft of this article, I used the term “near obsolescence” rather than just the term “obsolescence”, because you’re right, there are still people out there using CGI scripts (I am one of them).

                        Ultimately, I removed the weakening word. Determining when a technology is obsolete is a tough call, and often opinion based. In this case, it’s my opinion. If the definition of obsolete is “no longer produced or used; out of date.”, then there are very few technologies that can truly and in all cases be described as obsolete. In the case of CGI scripts as they were used in the late 90’s, I think it’s safe to say that that train left the station a long time ago.

                        1. 4

                          First I thought no one needs this article, but then I realized I’m now old. ;)

                          By the way, why your website keeps making requests to https://rickcarlino.com/owa/blank.php ?

                          1. 1

                            I realized I’m now old

                            Same.

                            making requests to https://rickcarlino.com/owa/blank.php

                            Open Web Analytics

                            1. 2

                              It sounds like a rather intrusive approach, and for people on mobile, it’s not free of charge either.

                      3. 4

                        I’m still using cgit. CGI is alive and well ;-)

                        1. 3

                          Is it possible to optimize operating systems, so creating new processes would be cheap and connections to database fast? Context switching is not an issue, as most modern web apps use threads instead of processes and perform well. I don’t understand why database connections must be pooled and reused instead of closed and opened again, as there’s no intercontinental latency between webapp and database usually. And to add ability to start quick for languages? (some caching? The main issue seems to be is re-initialization of all dependencies).

                          Long-living processes of todays web applications are not absolute necessity. Trendy “serverless” environments (which are proprietary and non-standard) show that it’s possible, but maybe it’s possible with regular unix processes too?

                          1. 5

                            Yes, it is possible, and was done years ago. CGI isn’t as slow as people assume anymore (even back in the day, it wasn’t CGI that was slow per se, it was frequently the interpreter people used with it), and the isolated processed can give good reliability.

                            That said though, I rarely use the original version anymore, since scgi can do most the same things and does legit intend to be a lil faster…

                          2. 3

                            This article is a nice trip down memory lane to what first got me into web programming – Perl scripts in my cgi-bin directory of my ISP, to customize web forum software, and to get early blog software, like CuteNews and MovableType, up-and-running.

                            I’m surprised that the article doesn’t really go into detail as to how the main thing that “killed” CGI were new application-webserver interfaces that were specifically developed by the popular web frameworks to supplant CGI. That is, in languages beyond Perl, you had Struts / Spring MVC (Java), Sinatra / Ruby-on-Rails (Ruby) and web.py / Django (Python). To support these frameworks, a higher-level abstraction than CGI was developed and employed, namely the Servlet API in Java (earliest to market, I think), Rack in Ruby, and WSGI in Python. Python’s interface for this, WSGI, was written in a “RFC format” similar to the Servlet API, and is well described on Wikipedia – there, you’ll see it was directly influenced by Java’s Servlet API.

                            The basic change was from process isolation semantics (one-process-per-HTTP-request, which was common in simple/naive CGI implementations) to live webapp semantics (with a single process, or a pool of processes with minimal shared in-memory state, doing one-function-call-per-HTTP-request).

                            Obviously moving away from one-process-per-HTTP-request meant that these web frameworks could scale much more easily, both in terms of requests per second per single process, and in scale-out scenarios across multiple nodes. It also made it easier for these frameworks to handle common web programming tasks like routing, session state, and cookies. I personally remember that routing was the user-perceivable benefit here: it let you easily have web apps with very pretty public URLs.

                            Adrian Holovaty, one of the creators of Django, covers this history in a bit more depth here: http://www.holovaty.com/writing/well-crafted-websites/

                            1. 2

                              Another cause of CGI scripting’s demise was an inability to handle the complexity of large scale applications.

                              I don’t think this is quite fair; when I first learned Rails in the 0.9 days, CGI was the easiest way to get started with Rails, but the main reason people stopped using it had more to do with Rails than CGI. Basically the problem was that Rails took so long to start up. For runtimes that offer a quick boot, that isn’t a problem at all.

                              For Rails, FastCGI eventually displaced CGI, but it was much worse in almost every regard except startup time.

                              1. 1

                                were??? in the past? They are still around. I still use them a lot. They work great.

                                1. 1

                                  You can similarly create a fantastically easy secure web service using stunnel and inetd/micro_inetd, or even the newest websocketd.

                                  1. 1

                                    I still use CGI and SSI too.

                                    As another poster said, great for filling in small pieces of an otherwise largely static site.

                                    Also standard across most web servers.

                                    1. 1

                                      I thought it entertaining when I noticed cgi-bin in the url of my local councils web portal.