Mailing List Archive

Raspberry Pi Zero (1st version) is 32-bit, as I think are the RPi 1 & 2.

-FG

> On Aug 14, 2023, at 22:42, Darren Duncan <darren@darrenduncan.net> wrote:
>
> ?I don't recall seeing this discussed and so am bringing it up now.
>
> (If there was solid prior discussion that someone knows of.
>
> Wider context is Perl's historically maintaining support for a wide variety of hardware architectures and operating systems in modern versions.
>
> Narrower context is Perl long being buildable for both 32-bit and 64-bit hardware architectures, such that how you build it determines the "native" size of an integer being 32 or 64 bits.
>
> My question is, do we know if there is a significantly sized user base that both continues to upgrade to newer Perl versions AND is running them on hardware that is natively 32 bits for integers.
>
> As far as I know, practically all hardware released for the last 15 years has had 64-bit CPUs and hence most builds of Perl would have been 64 bits. (At least all Macs were 64-bit from late 2006 or so.)
>
> I suspect that if the ability to produce a 32-bit build of Perl was deprecated this year and removed a few years later, it may make it significantly easier to maintain the Perl core and ecosystem due to removing a whole dimension of complexity.
>
> Does this seem like a reasonable change in principle, or are there still good reasons at this point to continue expressly supporting 32-bit builds indefinitely?
>
> Thank you for your thoughts.
>
> -- Darren Duncan

Darren Duncan <darren@darrenduncan.net> writes:

> I don't recall seeing this discussed and so am bringing it up now.
>
> (If there was solid prior discussion that someone knows of.
>
> Wider context is Perl's historically maintaining support for a wide
> variety of hardware architectures and operating systems in modern
> versions.
>
> Narrower context is Perl long being buildable for both 32-bit and
> 64-bit hardware architectures, such that how you build it determines
> the "native" size of an integer being 32 or 64 bits.
>
> My question is, do we know if there is a significantly sized user base
> that both continues to upgrade to newer Perl versions AND is running
> them on hardware that is natively 32 bits for integers.

It's not really possible, for the most part, to have a Linux
distribution without Perl.

We support various architectures in Gentoo with a 32-bit userbase,
but the main notable one would be 32-bit arm.

If you really must cull something, older OSes with unusual architectural
designs that complicate the code significantly would maybe be a better
idea, although I wouldn't suggest doing that either for the sake of it.

Not having to worry about this sort of breakage is also one of the big
selling points of Perl.

thanks,
sam

* Darren Duncan <darren@darrenduncan.net> [2023-08-14 19:41:15 -0700]:

> I don't recall seeing this discussed and so am bringing it up now.
>
> (If there was solid prior discussion that someone knows of.
>
> Wider context is Perl's historically maintaining support for a wide variety
> of hardware architectures and operating systems in modern versions.
>
> Narrower context is Perl long being buildable for both 32-bit and 64-bit
> hardware architectures, such that how you build it determines the "native"
> size of an integer being 32 or 64 bits.
>
> My question is, do we know if there is a significantly sized user base that
> both continues to upgrade to newer Perl versions AND is running them on
> hardware that is natively 32 bits for integers.
>
> As far as I know, practically all hardware released for the last 15 years
> has had 64-bit CPUs and hence most builds of Perl would have been 64 bits.
> (At least all Macs were 64-bit from late 2006 or so.)
>
> I suspect that if the ability to produce a 32-bit build of Perl was
> deprecated this year and removed a few years later, it may make it
> significantly easier to maintain the Perl core and ecosystem due to removing
> a whole dimension of complexity.
>
> Does this seem like a reasonable change in principle, or are there still
> good reasons at this point to continue expressly supporting 32-bit builds
> indefinitely?

I can't answer your question about software maintenance, but I can say that
there are plenty of 32 bit linux distros alive and kicking. "Retro" computing
fever has also only started to crack into 32 bit hardware. I suspect it's going
to be around for a very long time, basically indefinitely. This includes new
hardware being designed and build in the hobbiest/homebrew spheres. It would be
pretty bone headed to remove 32 bit support. I don't think you can make that
case at all.

Brett

>
> Thank you for your thoughts.
>
> -- Darren Duncan

--
--
oodler@cpan.org
oodler577@sdf-eu.org
SDF-EU Public Access UNIX System - http://sdfeu.org
irc.perl.org #openmp #pdl #native

On Tue, Aug 15, 2023 at 5:24?AM Sam James <sam@gentoo.org> wrote:

>
> Darren Duncan <darren@darrenduncan.net> writes:
>
> > I don't recall seeing this discussed and so am bringing it up now.
> >
> > (If there was solid prior discussion that someone knows of.
> >
> > Wider context is Perl's historically maintaining support for a wide
> > variety of hardware architectures and operating systems in modern
> > versions.
> >
> > Narrower context is Perl long being buildable for both 32-bit and
> > 64-bit hardware architectures, such that how you build it determines
> > the "native" size of an integer being 32 or 64 bits.
> >
> > My question is, do we know if there is a significantly sized user base
> > that both continues to upgrade to newer Perl versions AND is running
> > them on hardware that is natively 32 bits for integers.
>
> It's not really possible, for the most part, to have a Linux
> distribution without Perl.
>
> We support various architectures in Gentoo with a 32-bit userbase,
> but the main notable one would be 32-bit arm.
>
> If you really must cull something, older OSes with unusual architectural
> designs that complicate the code significantly would maybe be a better
> idea, although I wouldn't suggest doing that either for the sake of it.
>
> Not having to worry about this sort of breakage is also one of the big
> selling points of Perl.
>

Exactly, all of this.

Perl started out 32-bits, the idea that continuing to support it is much of
a drain is misguided. And frankly, even if it was, we should still support
it. I can think of several environments that are much more costly to
maintain that we still support because dropping actively maintained
platforms has never been our thing.

Leon

Hi there,

On Tue, 15 Aug 2023, Oodler 577 via perl5-porters wrote:
> on Mon, 14 Aug 2023, Darren Duncan wrote:
> ...
> do we know if there is a significantly sized user base that both
> continues to upgrade to newer Perl versions AND is running them on
> hardware that is natively 32 bits for integers.
> ...
> I suspect that if the ability to produce a 32-bit build of Perl was
> deprecated this year and removed a few years later, it may make it
> significantly easier to maintain the Perl core and ecosystem ...

Amongst other things this is a *huge* business investment issue. I
dread to think how much legacy business software is Out There which
can't be run on a 64-bit OS. There's legacy business software which
still runs on MS-DOS - well, nowadays it's often FreeDOS. Not long
ago I had an enquiry for supply of 3.5 inch floppy discs for a system
which tests motor vehicles to current standards set by my government.
Yes, they're still using computers of that vintage in MOT stations.

Back in February this year I saw this on this list:

| ... Anyone who wants complete stability has an easy way to achieve
| it: do not upgrade, ever.

I wanted to refute it then, but I didn't take up the issue at the time
because things seemed to me to risk getting emotional. I waited and
hoped for someone else on the list to pick it up. AFAICT nobody did,
which I found that distressing. It left me thinking "Ivory Tower".

There's no realistic choice not to upgrade. Major Linux distributions
still support 32 bit architectures, and Perl is included with them,
and whether the system's owner likes it or not Perl will be upgraded
when the system is upgraded for example for security reasons. Most of
the time the user would have no idea *how* not to upgrade, and most of
the time the user is *legally obliged* to upgrade, even if indirectly.
For example as a business which both employs people and engages in the
trade of goods we have to submit assorted tax returns to His Majesty's
Customs and Excise electronically using the Internet. That's the law.
The luxury of choosing to write the numbers on paper and lick a stamp
is no longer available to me. It would be grossly negligent and would
leave me open to legal action if the systems which are used to do this
work were not at least kept up to date with security patches.

We support customers who are using 32 bit architectures, and who will
certainly continue to do so for at least the next couple of decades.
They wouldn't thank me for telling them they had to re-invest in new
equipment everywhere just because 32 bit Perl was obsolete. Most of
them have never heard of Perl and don't know what an architecture is.

> Does this seem like a reasonable change in principle, or are there
> still good reasons at this point to continue expressly supporting
> 32-bit builds indefinitely?

I'd expect it to cause more problems than it might solve, and in any
case I can see no way to avoid it.

--

73,
Ged.

On 2023-08-14 8:41 p.m., Darren Duncan wrote:
> My question is, do we know if there is a significantly sized user base
> that both continues to upgrade to newer Perl versions AND is running
> them on hardware that is natively 32 bits for integers.

My ${DAYJOB} makes embedded systems for enterprise customers, based
mostly on arm32 with some i386, with ${REDACTED} but large production
numbers, and we use recent Perls on all of them. Mind, these are /new/
chips based on /new /in-house hardware designs. We have no plans to
pivot to x86_64 or arm64 anytime in the foreseeable future.

- R

Rarely post here, but feel I need to.
Bad idea, as others said, plenty of other little used OS' if you want to do
some support tidying. Raspberry Pi's 64bit OS is still mentioned as "not v
stable, and uses up more Ram, install the 32bit one for preference", plus
lots of older installs in the wild.

Jess

On Tuesday 15 August 2023 03:41:15 (+01:00), Darren Duncan wrote:

> I don't recall seeing this discussed and so am bringing it up now.
>
> (If there was solid prior discussion that someone knows of.
>
> Wider context is Perl's historically maintaining support for a wide
variety of hardware architectures and operating systems in modern versions.
>
> Narrower context is Perl long being buildable for both 32-bit and 64-bit
hardware architectures, such that how you build it determines the "native"
size of an integer being 32 or 64 bits.
>
> My question is, do we know if there is a significantly sized user base
that both continues to upgrade to newer Perl versions AND is running them
on hardware that is natively 32 bits for integers.
>
> As far as I know, practically all hardware released for the last 15
years has had 64-bit CPUs and hence most builds of Perl would have been 64
bits. (At least all Macs were 64-bit from late 2006 or so.)
>
> I suspect that if the ability to produce a 32-bit build of Perl was
deprecated this year and removed a few years later, it may make it
significantly easier to maintain the Perl core and ecosystem due to
removing a whole dimension of complexity.
>
> Does this seem like a reasonable change in principle, or are there still
good reasons at this point to continue expressly supporting 32-bit builds
indefinitely?
>
> Thank you for your thoughts.
>
> -- Darren Duncan
>

--
Sent with Vivaldi Mail. Download Vivaldi for free at vivaldi.com

--
Sent with Vivaldi Mail. Download Vivaldi for free at vivaldi.com

On Tue, Aug 15, 2023 at 09:33:09AM +0100, G.W. Haywood via perl5-porters wrote:
> Hi there,
>
> On Tue, 15 Aug 2023, Oodler 577 via perl5-porters wrote:
> > on Mon, 14 Aug 2023, Darren Duncan wrote:
> > ...
> > do we know if there is a significantly sized user base that both
> > continues to upgrade to newer Perl versions AND is running them on
> > hardware that is natively 32 bits for integers.
> > ...
> > I suspect that if the ability to produce a 32-bit build of Perl was
> > deprecated this year and removed a few years later, it may make it
> > significantly easier to maintain the Perl core and ecosystem ...
>
...
> There's no realistic choice not to upgrade. Major Linux distributions
> still support 32 bit architectures, and Perl is included with them,
> and whether the system's owner likes it or not Perl will be upgraded
> when the system is upgraded for example for security reasons. Most of
> the time the user would have no idea *how* not to upgrade, and most of
> the time the user is *legally obliged* to upgrade, even if indirectly.
> For example as a business which both employs people and engages in the
> trade of goods we have to submit assorted tax returns to His Majesty's
> Customs and Excise electronically using the Internet. That's the law.
> The luxury of choosing to write the numbers on paper and lick a stamp
> is no longer available to me. It would be grossly negligent and would
> leave me open to legal action if the systems which are used to do this
> work were not at least kept up to date with security patches.
>

And I have to add to it: one and half year ago I was working at Red Hat
as kernel developer and we still had to support kernel 2.6.x (RHEL5) for
costumers paying for the support on their 32bits systems. Even though
the systems were not new, the systems were not even close to "legacy".
Huge applications dealing with millions+ of requests and huge data were
passing by and being stored into those systems. As I was in kernel side
I didn't know what they were using on application side, but I'm pretty
sure Perl was included, even if only on the system side (many /bin and
/usr/bin are written in Perl, right?).

At the same time, some kernels were starting to get cross-compiled for
development and testing (64b building 32b images), but final images were
being built with real 32b systems and Perl is quite heavily present in
Linux kernel building system. So, IMHO, I don't think dropping 32b
support is an option for now, it certainly impacts Perl userbase (even
if indirectly).

(SIDE NOTE: I'm not even mentioning embedded system based on ARM, MIPS,
... which still are 32b and rely heavily on Perl and have 10y+ support
contracts. Some already mentioned it in the thread).

--
Bruno Meneguele | HEREDOC.IO
PGP Key: http://bmeneg.com/pubkey.txt

Hi there,

On Tue, 15 Aug 2023, Bruno Meneguele wrote:

> ... (many /bin and /usr/bin are written in Perl, right?).

raspberrypi:~# file /usr/bin/* /usr/sbin/* | grep Perl | wc -l
278

--

73,
Ged.

It might be better to start by dropping support for Irix and Tru64 who's support ended over 10 years ago.

This would be in line with the Lyon Amendment https://github.com/Perl-Toolchain-Gang/toolchain-site/blob/master/lyon-amendment.md (even if the "available for less than ten years" remains unclear)

Dean

On Tue, Aug 15, 2023, at 6:19 AM, G.W. Haywood via perl5-porters wrote:
> Hi there,
>
> On Tue, 15 Aug 2023, Bruno Meneguele wrote:
>
> > ... (many /bin and /usr/bin are written in Perl, right?).
>
> raspberrypi:~# file /usr/bin/* /usr/sbin/* | grep Perl | wc -l
> 278
>
> --
>
> 73,
> Ged.
>

On Tue, Aug 15, 2023 at 11:43?PM Dean Hamstead <dean@fragfest.com.au> wrote:

> It might be better to start by dropping support for Irix and Tru64 who's
> support ended over 10 years ago.
>
> This would be in line with the Lyon Amendment
> https://github.com/Perl-Toolchain-Gang/toolchain-site/blob/master/lyon-amendment.md
> (even if the "available for less than ten years" remains unclear)
>

The codebase contains exactly three Irix related ifdefs, and a couple more
True64 ones; all in areas of the code that haven't been touched in ages.
These are imaginary pains, they're by no means platforms that get in the
way of things

And to be honest we could probably drop 90% of it without dropping support
for any version released in the past 25 years if we really wanted to; **the
reason this hasn't happened yet is because it's actually work to drop
platforms**.

Leon