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?
(Score: 1, Insightful) by Anonymous Coward on Saturday December 26 2015, @12:31PM
Python.
(Or, actually, anything other than Perl.)
(Score: 0) by Anonymous Coward on Saturday December 26 2015, @01:45PM
I was kinda thinking perl should be avoided since it is mainly write-only.
Disclaimer: have not really used it much. (if at all)
(Score: 3, Touché) by isostatic on Saturday December 26 2015, @03:50PM
Perl allows you to create write only shit. So does Python. And Java. And Bash. And whatever you hipsters use.
(Score: 2) by bart9h on Monday December 28 2015, @07:02PM
Insightful, really?
This is the most stupid post ever on the history of internet!
You can dislike Perl all you want, but the question here is how to not break legacy websites using CGI.pm. If you would rewrite the site, in Perl or any other language, there would be no problem.
Whoever modded this insightful should have modpoints revoked forever.
(Score: 3, Touché) by chromas on Saturday December 26 2015, @12:43PM
"…and that's why this will be the last release of perl."
(Score: 2) by jdavidb on Saturday December 26 2015, @01:58PM
ⓋⒶ☮✝🕊 Secession is the right of all sentient beings
(Score: 0) by Anonymous Coward on Saturday December 26 2015, @01:11PM
Systemd-style BULLSHIT
You know opensource is gone when they start removing technologyies
"ITS EOL GUIZE!!!"
(Score: 0) by Anonymous Coward on Saturday December 26 2015, @01:15PM
Why not just keep it with some stdio warning that it is deprecated, and just have perl6 not include it, since everybody is supposed to be migrating to that in the next 15 years anyhow, right?
(Score: 1) by requerdanos on Saturday December 26 2015, @01:24PM
Looks like "CGI.bin" is already "end-of-life"?
(Score: 1) by crb3 on Saturday December 26 2015, @03:22PM
> If you upgrade to a new version of perl or if you rely on a system or vendor perl and get an updated version of perl through a system update, then you will have to install CGI.pm yourself with cpan/cpanm/a vendor package/manually. To make this a little easier the CGI::Fast module has been split into its own distribution, meaning you do not need access to a compiler to install CGI.pm
-- https://metacpan.org/pod/distribution/CGI/lib/CGI.pod#CGI.pm-HAS-BEEN-REMOVED-FROM-THE-PERL-CORE [metacpan.org]
That's as it should be IMO: if you really want folks to avoid it, just make it non-default so it's incrementally harder to put it into use.
(Score: 2) by stderr on Saturday December 26 2015, @05:22PM
Looks like "CGI.bin" is already "end-of-life"?
Have you tried looking for the right filename: CGI.pm?
alias sudo="echo make it yourself #" #
(Score: 2) by stderr on Saturday December 26 2015, @05:34PM
I now notice you were just pointing out that the summary got the filename wrong.
Well, never mind me then...
alias sudo="echo make it yourself #" #
(Score: 2) by mendax on Saturday December 26 2015, @01:42PM
This may have ramifications on us Soylentils thanks to the web app's Perl codebase. Time for a rewrite in something modern? Groovy and Grails anyone? Let the flames begin.
It's really quite a simple choice: Life, Death, or Los Angeles.
(Score: 3, Insightful) by mendax on Saturday December 26 2015, @01:45PM
Of course, this posting may just demonstrate how little I know about (or really care for) Perl.
It's really quite a simple choice: Life, Death, or Los Angeles.
(Score: 2) by jdavidb on Sunday December 27 2015, @02:06AM
ⓋⒶ☮✝🕊 Secession is the right of all sentient beings
(Score: 2) by The Mighty Buzzard on Sunday December 27 2015, @02:41AM
What he said. We're straight up mod_perl. Much snazzier than CGI.pm.
My rights don't end where your fear begins.
(Score: 2) by jdavidb on Sunday December 27 2015, @02:46AM
ⓋⒶ☮✝🕊 Secession is the right of all sentient beings
(Score: 0) by Anonymous Coward on Saturday December 26 2015, @03:49PM
Everyone knows Go is the language of the future!
(Score: 2) by Nerdfest on Saturday December 26 2015, @04:30PM
Go is pretty nice, but if you want a nicer low-ish level language, check out Rust. Both are too low level for something like a web service though, I think. I'm actually pretty impressed with Groovy and would use it over Java in pretty much all situations, although I haven't got into the Java 8 features much yet. From what I've seen though, Groovy does most of the same things as the Java 8 features better.
Obviously just opinions of course.
(Score: 2) by HiThere on Saturday December 26 2015, @08:26PM
That's not the use case for Perl. Awk would be closer, but is missing many of Perl's features. Perhaps you could do it in bash, but that would limit your coverage to Linux. Perhaps Ruby is the closest replacement, but that, also, is designed for a much different use case.
It's hard to think of any single language that could well replace what Perl does. A mix of shell scripting and Ruby would pretty much cover it, though, using shell scripting for part of the job and Ruby for the rest. (Of course some people just use one tool for every job...and many languages are flexible enough that it can be coerced into working with enough effort.)
Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
(Score: 0) by Anonymous Coward on Saturday December 26 2015, @09:05PM
It's hard to think of any single language that could well replace what Perl does.
What does Perl do? Be bloated and horrible? No worries, systemd's got you covered.
Of course some people just use one tool for every job...
I wonder if those people try to apply that in the real world as well. It's gonna be funny to see them try to build a house with nothing but a Swiss Army knife.
(Score: 3, Funny) by Post-Nihilist on Saturday December 26 2015, @10:24PM
You seems to be right
according to http://langref.org/all-languages/pattern-matching/searching/check-if-a-string-contains-a-match-to-a-regular-expression [langref.org] :
ruby
perl
groovy
python
Be like us, be different, be a nihilist!!!
(Score: 2, Informative) by requerdanos on Sunday December 27 2015, @07:03AM
Other advantages and disadvantages aside, I don't think that bash is limited to Linux [stackoverflow.com]...
(Score: 2) by Post-Nihilist on Saturday December 26 2015, @10:12PM
Be like us, be different, be a nihilist!!!
(Score: 3, Insightful) by jamesbond on Saturday December 26 2015, @01:49PM
Yeah, we should discourage and stop distribution of all discrete resistors and capacitors, after all, it's 2015. There is no need for them in the age of FPGAs and surface mounts! Oh wait ...
Seriously, unless that CGI.pm is maintenance nightmare and the mother of all security holes, why not let it as is? Why creates a problem that they themselves acknowledge will have a large potential impact to a lot of downstream users (<sarcasm> "small problems", indeed </sarcasm>) ?
The summary claims that "there is good technical reason for this removal" but is short on the details. And why is CGI a "technology that no one should not be using"? Again, claims, but short on justification.
(Score: 2) by TheRaven on Saturday December 26 2015, @02:10PM
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
(Score: 3, Informative) by bzipitidoo on Saturday December 26 2015, @02:34PM
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
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
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
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
sudo mod me up
(Score: 2) by VLM on Saturday December 26 2015, @02:49PM
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
sudo mod me up
(Score: 0) by Anonymous Coward on Sunday December 27 2015, @03:00AM
Suppose one is using/reusing old code.
(Score: 2) by TheRaven on Sunday December 27 2015, @09:04AM
sudo mod me up
(Score: 3, Interesting) by Pino P on Saturday December 26 2015, @05:57PM
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.
(Score: 2) by ledow on Saturday December 26 2015, @01:56PM
I am by no means a zero-day technology enthusiast. I just got onboard with HTML5 after finding that Emscripten lets me bring old C99 programs to the web and that it can replace both Flash and Java, in effect.
But, hell, just kill it already. People don't take hints. Dragging technology support forward just results in insecure software on new platforms as well as old.
Just stop including it, let those people RESPONSIBLE for MANAGING their own businesses based on it work out what they should do. If they deliberately decide to carry on on old tech because it hurts too much to do anything else, that's their conscious decision. If they decide to abandon it and find something else, that's their decision. But pretending to slowly support for a number of years until something breaks accidentally while it's been insecure and deprecated all that time, that's something that they will just take to mean they can carry on as normal without making such decisions.
Deprecate it. Announce it. Carry on.
But, to be honest, I don't know anyone who's still deploying Perl tech, even on their websites. Everything is PHP these days. Why Soylent/Slash is still developed in Perl, I have no idea. One would have thought that IT sites like that could emulate their old style (after all, what code PRODUCES the HTML is neither here nor there) in something a bit more modern.
There's nothing "wrong" with Perl CGI any more than there's anything "wrong" with executing a PHP program to produce an HTML output. It's basically the same thing. Do it as limited users, with strict checking, and it's all the same.
But if you're going to get rid of it, do so. If people don't upgrade to Perl 6 PURELY because it has no CGI, you know exactly what your language is used for in the real world and what users want. If it passes silently into the night and people upgrade to Perl 6 and nothing catastrophic is ever mentioned, you know that it doesn't really matter.
(Score: 2) by VLM on Saturday December 26 2015, @02:52PM
Basically its women's fashion, applied to tech. Why should anyone be permitted to wear bell bottoms, its current year. Any woman who cares switched to yoga pants a long time ago.
Stopping something that works is hard. People will just install it and it'll work great. If you want to sabotage you need to throw sand in the gears, actively include trojans and security holes. Thats the only way it'll work.
(Score: 2) by Marand on Saturday December 26 2015, @03:47PM
If you want to sabotage you need to throw sand in the gears, actively include trojans and security holes. Thats the only way it'll work.
Not even then; Microsoft tried that and there are still Windows XP holdouts despite their best efforts.
(Score: 0) by Anonymous Coward on Saturday December 26 2015, @04:00PM
It will keep happening until something is done about the saboteurs.
They pervade positions of command authority in opensource now.
(Score: 0) by Anonymous Coward on Sunday December 27 2015, @12:11AM
Why Soylent/Slash is still developed in Perl, I have no idea.
IMHO, Perl comes along for the ride because re-doing the whole thing in some other language *and* retaining familiar features would require too much time and/or money. Dice can't be counted on to do it without their sticky fingers getting in there and doing something evil. Soylent can't do it because... look at their fundraising goals and progress. That's just to maintain what we have.
(Score: 0) by Anonymous Coward on Saturday December 26 2015, @03:47PM
I noticed that they didn't give any alternatives in the article. What are you supposed to used instead of CGI.pm?
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.
CGI is dying, there's far better ways. But we won't list them.
(Score: 2) by isostatic on Sunday December 27 2015, @12:04AM
What are you supposed to used instead of CGI.pm?
https://metacpan.org/pod/CGI::Alternatives [metacpan.org]
Idiots
I've never seen anyone being so idiotic as to create a webpage using things like
However something like
(Score: 3, Funny) by PizzaRollPlinkett on Saturday December 26 2015, @04:39PM
I haven't used Perl for web development since before CGI.pm was even a thing...! I feel old.
(E-mail me if you want a pizza roll!)
(Score: 3, Insightful) by E_NOENT on Sunday December 27 2015, @12:59AM
I don't find it "write only" at all and to the contrary, find it a very expressive and powerful language.
I'll just show myself the door...
I'm not in the business... I *am* the business.
(Score: 0) by Anonymous Coward on Sunday December 27 2015, @03:52AM
In 2015, there are far better ways to write web applications in Perl.
Yes, it's called. nph-yourscript.pl. Non Parsed Headers. This allows my custom code direct access to the headers by telling the server not to fuck with my output. Interestingly this is also how I get Apache to run my C programs and ditch Perl (and HTTP) all together.
Why the fuck would I do that? We'll in $CURRENT_YEAR there are much better ways to develop Internet connected applications (which is what webpages are today -- shitty wanna-be applications).
Lucky for me, I never used CGI.pm except to get one-off scripts done. I'm ahead of the curve. I avoid needless throttling by making TCP connections look like HTTP, then "dowshifting" to raw packet streams. Where I have to provide browser support I use web sockets and Emscripten to compile my code for the browser (which compiles it into machine code and caches it, so it runs far faster than JavaScript).
I love you Perl. You'll always be my favorite Shell / Glue language, but your new bells and whistles are stupid and you remove functionality that makes my dinky maintenance scripts break for no fucking reason. Python is sexier but is fat and slow (stop fat-shaming, I know). Straight up C99, here to stay. With the advent of open source code and cross platform compiler tool chains, all this virtualized scripted bullshit is deprecated.
(Score: 1) by Noldir on Sunday December 27 2015, @01:56PM
What on earth are you trying to do? It sounds like you know one language and are trying to shoehorn that into every use case you have. And as you say so yourself there are better options available for web applications,so it sounds like a complete maintenance nightmare to boot...
(Score: 0) by Anonymous Coward on Sunday December 27 2015, @06:56PM
What on earth are you trying to do? It sounds like you know one language and are trying to shoehorn that into every use case you have.
You fool. You would consign yourself to a perpetuity of learning new language after new language, when instead we have the technology to compile any of your favorite compilable languages into any other language. I like C, so I can compile it into Java bytecode, or ASM.js, or Objective C. Fuck languages. They all suck. The future lies not in languages but the creation of API abstraction layers for each platform to adapt ANY language to run on ANY platform, and the barebones binding beneath it all will be in C, thus it is the language to use for best performance and barebones simplicity. Keep in Simple Stupid. And yet you complicate things with the moronic notion that there is a certain language for every problem space. BAH HUMBUG! That way lies obsolescence. You have been warned. The future is coming, soon you language zealots will be obsolete.
Does not Perl's Parrot VM point the way, albeit a flawed approach, you could compile damn near anything to run on Parrot VM. Fuck the VM though. Tell me what platform your running and I will, with the push of a few buttons, generate a deployment of my C code to operate thereupon. Be your platform "Javascript enabled browser" or be it iPhone or Android, or Linux or BSD or Mac, or Windows with or without the interface formerly known as Metro.
Cross platform and open source coding have made VMs obsolete -- I can simply compile for the target platform directly rather than write once and debug everywhere. Operating systems are irrelevant. No one buys an OS for its capabilities! They buy devices asking, "What software can I run atop it?" Well, if the devices and platforms will not come into standardization then that is fine, then applications will be written using a tool chain that allows deployment across EVERY platform regardless of how nonstandard the anti-competitive fuckwads desire to be. Don't like C? No problem. The compiler supports other languages as well... See? Just as the OS is irrelevant, so too will the Language be irrelevant.
As for maintenance nightmare? What is this you speak of? Having a system that's deployed in half a dozen languages is a fucking nightmare. Having tens or hundreds of such systems is a fucking nightmare. Writing your code to one API and fixing the maintenance issues at the platform abstraction level so that ALL OF YOUR PRODUCTS benefit simultaneously... That is not a nightmare but a dream come true!
Every problem in Computer Science can be solved by applying another level of abstraction. However, there is a special type of universal abstraction layer called Annealing whereby the surface interface is made uniform and the underlaying layer adapts freely to any problem space. Fool, I have proven my tool chain mathematically sound. While you learn $FLAVOR_OF_THE_WEEK language, I will merely add it to my compilation targets and release my entire software stack for that platform faster than you can get one product out the door.
"Maintenance headache"? HA! You wallow in such headaches and deny the universal process of life, the universe, and everything. Evolution is a dumb way of saying that Life is a planetary Annealing process. You will either embrace the universal truth of adaptation, or become extinct.