|
in reply to Rediscovering Hubris
Today many are shunned because they use "ancient" Perls, anything less than 5.30 is "EOL".
I think you're missing two things here.
First, Perl has yearly releases because that's how the core team believes it can best continue to deliver value to Perl users for free. That's a balance of new features, bug fixes, optimizations, and security improvements. You're probably not paying for that. I'm probably not paying for that. No one in my company is writing a check to the Perl core team once a year to get this, so we don't have a lot of say in how the members of the core team spend their time.
Second, regardless of the success with which the core team has made it possible to run code written for 5.8 on 5.32, there are things you're not getting in 5.8 that you might really need from 5.32. Some of these are security improvements. Some are performance improvements. Some are subtle when you don't know you need them (Unicode improvements), but some are essential when you realize you do (Unicode improvements). Some are really difficult to overcome, such as building an older release on a newer platform.
No one should shun you for running an older version, but you're taking a lot of risk on yourself that running a newer release would otherwise let you avoid. If that's the right thing for your organization, that's one thing—but making that choice without acknowledging that you're on your own and you shouldn't expect core team support or free community support is another.
Does that help? |
Re^2: Rediscovering Hubris
by jcb (Parson) on Jan 18, 2021 at 23:44 UTC
|
Some are really difficult to overcome, such as building an older release on a newer platform.
If the situation here is as I understand it, I believe that it involves older releases installed long ago on older platforms, with no will to install newer releases for whatever reason. Managers can be "funny" that way and I have had to deal with similar situations in the past.
So the code here needs to run on many Perl versions, from 5.8 to 5.32 or so, whatever the various machines in $WORK's fleet have installed.
| [reply] |
|
|
The situation I'm thinking of is where the underlying machine has to upgrade (or is replaced), which is a hassle. If neither of those cases is true, some things are easier and some things are a lot more difficult.
| [reply] |
Re^2: Rediscovering Hubris
by Leitz (Scribe) on Jan 20, 2021 at 02:10 UTC
|
Why would the community not provide advice when I ask a question that is limited by an older Perl? While I have had people explicitly say they won't help because I'm not running a "supported" version, those people seem few and thankfully far between. Granted, there's a big difference between "must use print instead of say" and "we need the unicode support in version 5.XX". I completely agree that if I want something in 5.20 then gosh, I guess I'm using 5.20 or later.
Funny story: I was using an old OS based version of a language. Got a lot of flack for it and the whole "we won't support you" junk. I really liked the language, and started pulling daily dev builds. Even found and fixed a bug in the test suite. Then I'd get flack for using a version that was "too new." Can't please some people.
I haven't read "Modern Perl", but people whose opinion I trust recommend it. When a newbie asks about a good book, I'll recommend it. Vintage is nice in a car, great in a wine, but not so hot in a computer language. On the other hand, I'm finding "Perl Testing: A Developer's Notebook" to be priceless.
For me, having to use older Perl with minimal CPAN has been a very good thing. I am pushed to actually learn how things work. I can build a robust and portable, if not fancy, codebase. My path isn't how everyone else gets here, I'm okay with that. A friend wants to build something with 5.20 and lots of CPAN; cool.
The path to learn is difficult enough. Pushing against learners because they use older tools just weakens the community. If they can learn enough then they'll move forward when it works best for them.
Chronicler: The Domici War (domiciwar.net)
General Ne'er-do-well (github.com/LeamHall)
| [reply] |
|
|
Why would the community not provide advice when I ask a question that is limited by an older Perl?
I didn't use the word "advice", but I'll address this anyhow.
From a security perspective, if you ask "How can I harden my 5.8 application against user-input hash DDoS attacks?", the answer is going to be "Upgrade". You're unlikely to get someone to backport a hash seed randomization patch for free.
From a personal perspective, if you ask "How can I perform task $X, but only on 5.12 or earlier", that means I'd have to install an earlier version of Perl and think really hard about how to write something without regex improvements, signatures, postfix dereferencing, improved capture groups, lexical subs, or any of a dozen other little improvements I've grown accustomed to, not to mention code that only runs on newer releases (anything that relies on pluggable keywords, Mojolicious, etc etc.)
I don't see a lot of personal value to me in keeping around 30-odd versions of Perl to backport a solution to, so I'll just ignore it and move on.
That doesn't mean you should or shouldn't use a specific version; just that you should expect you've limited your peer pool when asking these kinds of questions.
| [reply] |
|
|
Good point, I need to keep that in mind when asking questions.
From a personal perspective, if you ask "How can I perform task $X, but only on 5.12 or earlier", that means I'd have to install an earlier version of Perl and think really hard about how to write something without regex improvements, signatures, postfix dereferencing, improved capture groups, lexical subs, or any of a dozen other little improvements I've grown accustomed to, not to mention code that only runs on newer releases (anything that relies on pluggable keywords, Mojolicious, etc etc.)
That level of language usage is outside my expertise and background; thank you for helping me see the issue better.
Chronicler: The Domici War (domiciwar.net)
General Ne'er-do-well (github.com/LeamHall)
| [reply] |
|
|
I agree having to use print with a newline instead of say is not a good reason to upgrade ...
yet I'm struggling to understand your seemingly blase attitude towards Security.
(Oh, and I strongly agree that chromatic's Perl (and agile dev) books are awesome! ;-).
I suspect you come from a different (smaller?) commercial environment than me. Do you have Security auditors?
We do, they use tools (luckily mostly Windows-only for now) and they have the ear of upper management.
If you're using a version of Perl open to security exploits (see perlsec ... DoS attacks based on Perl hash algorithmic complexity
spring to mind) or any product (including Perl) that is out of official support, they'd be all over you like hair on soap.
They don't have the time to understand all the nuances of every product running on every computer so they tend to heavily rely on tools
and enforce blanket rules, such as "you are not allowed to use a product that is out of support" or
"you must regularly check for exploits and patch your software promptly".
| [reply] |
|
|
Security and auditing are valid concerns, but dangerous topics to wander into.
My work has often been in larger shops; from a couple hundred servers, to a few thousand, and up to "we don't really know". Security, and auditing, varied. Early on "it works" was sufficient. Later, when corporate started listening to us talk about needing to upgrade and defend, internal and external auditing became more common. I won't say everything was perfect, but at least we could talk about things openly and management would listen.
However, Perl and CPAN quickly become issues. Large shops use a variety of "solutions", and those use a variety of languages and language tools. Large shops can seldom audit the tool chain. With CPAN, it becomes even more problematic; every module increases your vulnerability footprint and fragility. In general, a large shop has three options:
- Pay for support for every language and every module used.
- Pay for a large enough staff to support every language and module used.
- Shift legal liability to the OS and Solution vendors since that's what they are paid for.
Any guesses as to which one usually gets picked? :P
Keep in mind, we've seen OS vulnerabilities that only affect "Version X and later." New versions of software can provide new functionality as well as increased performance, etc. However, that very "new" is an open invitation to new bugs and vulnerabilities. All software has bugs. New software has new bugs. Assuming newer is better is not a valid security posture.
Chronicler: The Domici War (domiciwar.net)
General Ne'er-do-well (github.com/LeamHall)
| [reply] |
|
|
|
|
| [reply] |
|
|
Ha! Pretty funny.
On a serious note, I have given thought to studying the Perl compile process and tuning it for my nodes. Unfortunately, I have other projects demanding my time. Well, that's mostly honest. I seem to be at a transition stage. For a while, in a different language, I was deep into learning the ins and outs of the language for the joy of the language itself. With Perl, I'm focused on things I need to get done. I understand why the one door closed and the other partly opened, but I still mourn the loss.
Chronicler: The Domici War (domiciwar.net)
General Ne'er-do-well (github.com/LeamHall)
| [reply] |
|
|
