64bit Raspbian?

[jimmyken]

Hi, all!

Blessed Raspberry Pi 4 lunches.
Its SoC, BCM2711 (I guess, de facto BCM2838?) has a powerful 64bit CPU, ranging to the application for automotive.
Raspbian Buster also releases. I downloaded Buster and installed it to my SD Card using balenaEtcher on Windows. It works fine on my Raspberry Pi 3.
I also checked the boot folder of Buster and it prepares for Raspberry Pi 4.
I wonder if Buster seems to share other components between Raspberry Pi 4 and other Pis. It means Raspberry Pi 4 is running on 32bit.
How about 64bit Raspbian? Debian has the build for arm64. I'm really looking forward to seeing 64bit Raspbian as a powerful educational tool.

[fruitoftheloom]

Hi, all!

Blessed Raspberry Pi 4 lunches.
Its SoC, BCM2711 (I guess, de facto BCM2838?) has a powerful 64bit CPU, ranging to the application for automotive.
Raspbian Buster also releases. I downloaded Buster and installed it to my SD Card using balenaEtcher on Windows. It works fine on my Raspberry Pi 3.
I also checked the boot folder of Buster and it prepares for Raspberry Pi 4.
I wonder if Buster seems to share other components between Raspberry Pi 4 and other Pis. It means Raspberry Pi 4 is running on 32bit.
How about 64bit Raspbian? Debian has the build for arm64. I'm really looking forward to seeing 64bit Raspbian as a powerful educational tool.

The stance by the RPT / RPF, as stated by Simon Long in a response in the Buster Blog:

When someone demonstrates a clear advantage to using 64-bit on Pi platforms for common use-cases (other than “it’s newer”). 64-bit may be the current state of the art, but it would orphan the 10 million or so Pi 1, 2 and Zero boards out there – for us, it is more important to retain backward compatibility than to have the (very questionable) advantages of 64-bit.


All Raspberry Pi and Compute Module use the VideoCore Video Processing Unit, that is the main commonality.

The 4B is an evolution of previous models.


The Raspberry Pi 2B v1.2 and newer models are all ARMv8 and capable of running ARM64 Operating Systems, there are several 3rd party offerings....


This has been extensively discussed for 3 years

[jimmyken]

Hi, all!

Blessed Raspberry Pi 4 lunches.
Its SoC, BCM2711 (I guess, de facto BCM2838?) has a powerful 64bit CPU, ranging to the application for automotive.
Raspbian Buster also releases. I downloaded Buster and installed it to my SD Card using balenaEtcher on Windows. It works fine on my Raspberry Pi 3.
I also checked the boot folder of Buster and it prepares for Raspberry Pi 4.
I wonder if Buster seems to share other components between Raspberry Pi 4 and other Pis. It means Raspberry Pi 4 is running on 32bit.
How about 64bit Raspbian? Debian has the build for arm64. I'm really looking forward to seeing 64bit Raspbian as a powerful educational tool.

The stance by the RPT / RPF, as stated by Simon Long in a response in the Buster Blog:

When someone demonstrates a clear advantage to using 64-bit on Pi platforms for common use-cases (other than “it’s newer”). 64-bit may be the current state of the art, but it would orphan the 10 million or so Pi 1, 2 and Zero boards out there – for us, it is more important to retain backward compatibility than to have the (very questionable) advantages of 64-bit.


All Raspberry Pi and Compute Module use the VideoCore Video Processing Unit, that is the main commonality.

The 4B is an evolution of previous models.


The Raspberry Pi 2B v1.2 and newer models are all ARMv8 and capable of running ARM64 Operating Systems, there are several 3rd party offerings....


This has been extensively discussed for 3 years

I think RasPi4 is a revolution to make another 64bit OS, needed to separate from 32bit Raspbian.
In several applications, BCM2835 is still powerful and available in view of low energy and stable temperature. Plus, it has reliability since a decade.
Besides, BCM2711 is super powerful, it allows to fit with state-of-the-art technology.
I watched several professionals tried arm64 debian on RasPi3.

[Timescale]

I get the backward compatibility argument, but at some point being backward compatible means it isn't here-and-now compatible. Currently if you want to shun Google invested crud like Chromium and would like to run Firefox, you are stuck with Firefox ESR. I do not think it should be an adventure installing a third party 64 OS just to run a better browser.

It also seems like the 4gb variant of the 4 is going to be a massive hit. This is a hint that more ram is more better and more wanted. Next generation surely will offer even more, necessitating a 64bit OS by definition. Why not just have a 64bit flavour of Raspbian now?

[fruitoftheloom]

I get the backward compatibility argument, but at some point being backward compatible means it isn't here-and-now compatible. Currently if you want to shun Google invested crud like Chromium and would like to run Firefox, you are stuck with Firefox ESR. I do not think it should be an adventure installing a third party 64 OS just to run a better browser.

It also seems like the 4gb variant of the 4 is going to be a massive hit. This is a hint that more ram is more better and more wanted. Next generation surely will offer even more, necessitating a 64bit OS by definition. Why not just have a 64bit flavour of Raspbian now?

chromium-browser is open source:

https://www.chromium.org/

Google add their crud to their browser based on Chromium and Raspbian has never offered Google Chrome Browser.


Regards firefox-esr, that is a decision made by Debian, but at least in Raspbian Buster it is now based on the Quantum Browser Engine:

https://www.mozilla.org/en-US/firefox/6 ... easenotes/



If RPT / RPF offered ARM64 & x86-64 Linux Distros it would mean that the amount of work maintaining would increase considerably. Therefore other projects would be delayed and users would find something else to quibble about because of delays. There is already a long list of issues that need to be addressed which may affect all users not just the ARM64 users.......

[jerrm]

I get the backward compatibility argument, but at some point being backward compatible means it isn't here-and-now compatible.

This is the main pro-64 argument IMO. There are multiple projects that are 64 bit only now, and that is only going to get more prevalent.

I've never been a "we need 64 bit" evangelist, but 64 bit is undoubtedly the future. It doesn't have to happen immediately, but it's time to start moving in that direction.

[fruitoftheloom]

I get the backward compatibility argument, but at some point being backward compatible means it isn't here-and-now compatible.

This is the main pro-64 argument IMO. There are multiple projects that are 64 bit only now, and that is only going to get more prevalent.

I've never been a "we need 64 bit" evangelist, but 64 bit is undoubtedly the future. It doesn't have to happen immediately, but it's time to start moving in that direction.

The RPF / RPT are not stupid or blissfully unaware, question of priorities:

https://www.raspberrypi.org/forums/view ... p?t=232684

[Timescale]

chromium-browser is open source:

Still, I'd like to stay away from it as far as possible. Not only because it was started by Google (which is a big part of it), but also because it is inherently unsuitable for any serious web application deployment.

Regards firefox-esr, that is a decision made by Debian, but at least in Raspbian Buster it is now based on the Quantum Browser Engine:

That is great news..

[jerrm]

The RPF / RPT are not stupid or blissfully unaware, question of priorities:

https://www.raspberrypi.org/forums/view ... p?t=232684

Obviously. The Buster boot partition isn't 4x or so larger because the Buster kernel grew that much. Assumedly, a dual kernel Raspbian image with 32 bit userland is planned as the standard image,

Still, the same trite performance and memory arguments have been made here recently. A roadmap would be nice. Seems like Microsoft is more open about future plans than the RPF.

[rpdom]

A roadmap would be nice.

Roadmaps change. As do deadlines. Which are some of the reasons the RPF and RPT don't announce new products in advance.

[jimmyken]

A roadmap would be nice.

Roadmaps change. As do deadlines. Which are some of the reasons the RPF and RPT don't announce new products in advance.

From the discussion of fellows, I'm sure that the new 64bit OS will comes officially. It possible that RPF and RPT can create the arm64 OS and Raspbian can stay as armhf (Raspbian's armhf is special because it supports VFPv2 via many efforts).
BCM2711 and 4GB SDRAM also matches Android 64bit.

This is a know-how to install arm64 Ubuntu to RasPi3+. It's in Japanese though.
https://shibata-wk.hateblo.jp/entry/2019/04/06/004901

So, we need to consider of heat-treating when official 64bit OS comes true.
Powerful RasPi4, because of optimized power, seems to need any heat sink and air/water cooler.
I think the 28nm process of BCM2711, compared to 40nm process of others, take more efficient power. However, optimized 64bit power hots RasPi4. I also dream some official heat sink and cooler.

[geev03]

Installed the latest Moodle https://moodle.org on Raspbian 32bit on Pi4B - 4GB and got this warning

php not 64 bits
if this test fails, it indicates a potential problem
It has been detected that your site is not using a 64-bit PHP version. It is recommended that you upgrade your site to ensure future compatibility.

The installation was very fast compared to Pi3B but there is a need for 64 bit OS to fully realise the potential of this hardware.

[jamesh]

The RPF / RPT are not stupid or blissfully unaware, question of priorities:

https://www.raspberrypi.org/forums/view ... p?t=232684

Obviously. The Buster boot partition isn't 4x or so larger because the Buster kernel grew that much. Assumedly, a dual kernel Raspbian image with 32 bit userland is planned as the standard image,

Still, the same trite performance and memory arguments have been made here recently. A roadmap would be nice. Seems like Microsoft is more open about future plans than the RPF.

MIcrosoft can afford to tell people about their roadmaps, they have 131000 staff, 10 of thousand of engineers. They can absorb problems. We have 10 SW guys. That three orders of magnitude AT LEAST. So rather than announce in advance and disappoint, we don't announce in advance.

And the arguments are not trite, because as yet, we've never been given a solid gold argument that means we HAVE to move to 64bits.
Although, clearly, we will do at some point. It's not easy to do, and the support burden will likely double, which means more staff.

[jimmyken]

The RPF / RPT are not stupid or blissfully unaware, question of priorities:

https://www.raspberrypi.org/forums/view ... p?t=232684

Obviously. The Buster boot partition isn't 4x or so larger because the Buster kernel grew that much. Assumedly, a dual kernel Raspbian image with 32 bit userland is planned as the standard image,

Still, the same trite performance and memory arguments have been made here recently. A roadmap would be nice. Seems like Microsoft is more open about future plans than the RPF.

MIcrosoft can afford to tell people about their roadmaps, they have 131000 staff, 10 of thousand of engineers. They can absorb problems. We have 10 SW guys. That three orders of magnitude AT LEAST. So rather than announce in advance and disappoint, we don't announce in advance.

And the arguments are not trite, because as yet, we've never been given a solid gold argument that means we HAVE to move to 64bits.
Although, clearly, we will do at some point. It's not easy to do, and the support burden will likely double, which means more staff.

Staffs will have 2 OSs, 32bit and 64bit. It means the need of a power of 2, but not the multiples of 2, because of the product liability.
I imagine here is educational entity, KIDS FIRST. Does RPF really need the hot 64bit OS I and enthusiasts are dreaming?
I also think the 64bit work will come by Google or other entities because the work is so ambitious to fit with state-of-the-art technologies.
RPF and RPT can get the work from the super entity, and give the special impression to KIDS.