Moin, On Tuesday 04 April 2006 01:35, Sébastien Aperghis-Tramoni wrote: > Tels wrote: > > Moin, > > Hello Tels, > > > OTOH, who still runs pre-5.8.x code deserves what they get. > > > > There are horrible bugs in older Perls, and I don't know why people > > still > > insist using insecure, buggy and feature-lacking code like 5.6. or > > even gasp 5.004. Just think "Unicode support", "hash randomization", > > "memory leaks". > > You forget that there's more than one way to use Perl :-)
:) > When Perl is used for sysadmin tasks, most of the features you listed > (and I could add "threads support", "new IO implementation", "signals > handling", "subroutines attributes") are of no to little use because > such Perl scripts are run for executing tasks that do not require > advanced Perl features like those just listed. Remember that on Unix > systems, Perl is like Bash, Sed and Awk, only more powerful (even if > it's by one or two orders). Do you replace your /bin/sh on your Solaris > with the latest Bash just because it has very new and cool features? > Usually you can't. Mainly because it could break things, and has little > to no added value. On workstations, poeple (e.g me, collegues, family etc) tend to install a new system every 2..3 years because the old(er) linux versions are usually lacking in feature (like, say, no unicode support, no support for modern hardware, buggy software, etc etc). OTOH, I have server systems running for like 3 years (or until the hardware burns down) because "it works". (Usually, after a few years you upgrade the system anyway, because the definition of "works" changed sufficiently, or the environment causes the machine to no longer "work" with others). In the former case I am not interested in running older perls, in the latter case I am not updating any module or software on the server unless its definitely broken, because updating lets say File::Temp would risk breaking the system, and users of the machine in question don't like downtimes. Now, there is definitely a difference between very "basic" modules that should run on 5.004, like File::Temp or whatever, and "fancy" stuff you don't want to run on such old systems, like say Graph::Easy, though. But for instance, I am totally at a loss why Version.pm needs to support 5.004 - I mean, if you are running such an ancient machine, why put a new Version.pm on it and risk breaking stuff? Likewise, why using BigInt on 5.004? The bugs in overload.pm alone would probably make your head spin. I think the worst case is that the testsuite runs ok, so you think it works, but it then breaks in many and subtle ways, exactly when you need it most. More below: > > Using these older Perls means you basically show the hard-working > > Perl5-Porters that you don't care for their work in improving Perl. > > But the Perl interpreter (which is what the P5Porters are working on) > and the Perl modules are mostly disconnected (*). Where would be the > interest to use an interpreted language if it were tied to a specific > version of the interpreter? Most Perl code out there don't require > recent features. > > To continue with my previous analogy, there are also many people that > work hard on the Linux kernel, the GNU system, and all the different > parts that compose a GNU/Linux distribution, but when a server is in > production, you can't upgrade it at your wish. > > (*) Yes, I know that the core Perl distribution includes many modules, > but ask any P5Porter and he'll answer you that the core is over-crowed > and that all core modules that can be made dual-life should be released > on the CPAN. > > > I know, now people will come out of the wood and say that they have > > that > > old system, and no, they can't upgrade Perl etc, never touch a > > running system etc yadda yadda. But what the heck do you then try to > > upgrade modules on said system when you didn't want to "touch the > > system"? > > My current $work is to write a Perl program that must execute on about > 1200 Linux servers, with Perl versions ranging from 5.004 to 5.8. I > can't upgrade Perl on these because they have different kernel / glibc > / gcc versions. But that's not a problem because I don't need to > upgrade Perl or the modules on said systems, just to put the modules I > need in a directory and "use lib /that/directory". Of course I need to > use modules that work with 5.004, or patch them so they work with > 5.004, but you could be surprised to see how little some of the patches > are. Can be as simple as removing "require 5.6" (as for File::Temp). > Most of the patches I've sent were less than 10 lines of differences. You $work is what I call a "special case". It is certainly not the generic case (at least for my userbase), and I don't think that authors should have to care for such special needs (unless they want :-D. The biggest problem you face IMHO is that the module might "work" in testing, but not in praxis. Dont think CPAN testers even do 5.6 anymore, and I do not havy anything older than 5.8.3 at my disposal. This means anything I release is _seriously_ undertested on older Perls. If you'd send me such a patch, I'd gladly add it, but I would still not be able to make guaranties, and the next version might easily break on $OldPerl again. For instance, silly example, the regexp engine blows the stack on anything except bleed. It will work in testing (duh!), it might even work on the server, but as soon as a user supplies sufficiently bad enough input data, it blows. The only way to avoid that is to upgrade your Perl/Kernel whatever. So while your patch seemingly makes the code work, the definition of "works" is, well, broad :) If you are sure you never get bad data, fine. If you can't be sure, upgrading kernel, glib and Perl etc might be nec. Anyway, I don't say that older support is not possible, but I think that the work should be done by whoever needs it (e.g. the few crazy people running such old stuff), and not by the author (who is overworked anyway). There is also the point that supporting ancient Perls means you can't use all the new, wonderfull features that were added to later versions of Perl, like our, warnings etc. Best wishes, Tels PS: Just a woeful tale from today: Want to show someone the wonderfull SVG I made today. Installed latest Firefox especially for that. It breaks and renders garbage. Turns out that the user in question *was* running Win98, and there is a problem rendering text in SVG on that system. (Don't even ask about unicode - luckily I didn't include a chinese character just for laughs). Now there are three options: * ask the user to upgrade the OS * live with it not working. * fix firefox, svg rendering lib and win98 unicode support. Will be done by about 2078. The user response will be "Well, Win98 works for me, why should I upgrade?". And then later "But why can't I see the nice SVG?" Which makes me bash my had into the wall... -- Signed on Tue Apr 4 19:08:06 2006 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email. "Now, _you_ behave!"
pgpGKnrentIEj.pgp
Description: PGP signature
