perl 5.8.5
Lars Erik Gullerud
lerik at nolink.net
Wed Oct 6 17:32:33 PDT 2004
On Wed, 6 Oct 2004, Ryan Newman wrote:
>> Even though I have hit some of these problems, I do think it is a
>> good idea to make the change to 5.8 as part of FreeBSD 5.3-release.
>> People should be taking a bit more time to check, cross-check, and
>> re-check everything they are running if they are upgrading to
>> 5.3-release from 4.x-release.
>>
>
> Having 5.3 default to perl 5.8 will add a lot of delay in several peoples
> migration from 4.x for sure.
Uh, I don't really understand this argument at all.
I happen to be one of the "lucky" people administering a couple of huge,
complex, perl-based applications, currently running on 4-STABLE servers and
perl 5.6 from ports. These are systems that are inherited after mergers, and
none of the original developers are available anymore. They are also written
with a lot of sloppy perl code, and break rather spectacularly with 5.8, which
seems to be a lot more strict in checking certain types of syntax. Now, since
people around here tend to value their sanity (and therefore also mostly use
Python, C or PHP), nobody really wants to touch these apps until they are
phased out and replaced sometime in the next couple of years.
However, one of the big differences between 4.x and 5.x is that perl is not in
the base system on 5.x but rather just a package - therefore I actually
consider it EASIER to move these systems to new servers on 5.x than moving them
to new boxes on 4.x. If perl 5.8 is the default, well, pkg_delete it and add
5.6, problem solved. If I can select 5.6 directly from sysinstall, even easier.
I don't really care what sysinstall tries to do by default.
Since said systems are very CPU-intensive and threaded, we eagerly anticipate
5.3-RELEASE to take advantage of the new SMP code - I've already set aside a
lot of testing time over the next few weeks to play with lifting these apps
over to a 5.3-BETA/RC and measure the performance on some multi-CPU Xeon
systems, and hopefully keep these apps running until their replacements are in
place - since "throwing hardware at the problem" has really been taken to its
limits on their current 4-STABLE incarnations.
/leg
More information about the freebsd-current
mailing list