Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should we still ship 32-bit x86 Linux binaries? #17504

Closed
laanwj opened this issue Nov 18, 2019 · 23 comments · Fixed by #18104
Closed

Should we still ship 32-bit x86 Linux binaries? #17504

laanwj opened this issue Nov 18, 2019 · 23 comments · Fixed by #18104
Milestone

Comments

@laanwj
Copy link
Member

laanwj commented Nov 18, 2019

I don't think there's any hurry to do this, just opening an issue as #17503 made me wonder.

In general, running bitcoind in 64 bit is unarguably better. 64-bit registers result in better validation performance and it allows leveldb to use mmap without worrying about virtual memory usage.

Back in the day, the rationale for removing 32-bit x86 builds for Windows but not Linux was that some cheapo VPS still used x86-32 bit.

Is this still the case in the year of (almost) 2020? Is anyone running x86-32 VMs for other purposes than testing software on that architecture? Even with that, how much testing are these binaries getting?

(to be clear, I'm not arguing to remove support for 32-bit, just to stop building and providing binaries for it. I also think ARM is a different matter.)

@hebasto
Copy link
Member

hebasto commented Nov 18, 2019

Agree to keep building and providing 32-bit binaries for ARM only.

@practicalswift
Copy link
Contributor

practicalswift commented Nov 18, 2019

Agreed. I think it makes sense to stop shipping 32-bit x86 Linux binaries.

More generally I think we should avoid providing binaries for obsolete or soon-to-be-obsolete platforms where we are uncertain about the amount of real world testing.

See some additional arguments in the somewhat related PR #16096 ("RFC: Improving testing under the remaining supported 32 bit platforms").

@emilengler
Copy link
Contributor

emilengler commented Nov 20, 2019

I'm neutral on this.
I don't use Bitcoin Core on any 32-bit device but there might be some people who don't know how to compile something and wanna run a full node on a very old (32-bit) computer that is no longer in productive use and I think it should never be complicated to setup a full node. I count the use of bitcoind and compiling as too complicated for the average user.

@laanwj
Copy link
Member Author

laanwj commented Nov 20, 2019

@emilengler The last 32-bit only physical Intel processor for general use was introduced in 2006. I don't think we have to worry that any are usable for running full validating nodes.
I'm only potentially worried about VPS here.

@maflcko
Copy link
Member

maflcko commented Nov 25, 2019

Freedesktop has stopped shipping 32bit runtimes for flatpak: https://gitlab.com/freedesktop-sdk/freedesktop-sdk/commit/1fa7b7b9e590b31601c2091edcd6dc3ea2e4f132 , so we will be unable to distribute the 32 bit flatpak in the long term: flathub/org.bitcoincore.bitcoin-qt#2 (comment)

I think if someone really wants to run on 32 bit, they can simply compile from source.

@maflcko
Copy link
Member

maflcko commented Nov 25, 2019

Also, starting with Ubuntu Bionic 18.04 and Fedora 31, neither OS will ship 32 bit iso images.

@maflcko
Copy link
Member

maflcko commented Nov 25, 2019

Similar to windows XP, what about we send out a tweet and a post to the mailing list asking if it would significantly hinder someone from running Bitcoin Core if the i686 builds were removed?

@A6GibKm
Copy link

A6GibKm commented Nov 25, 2019

Independent of the choice, providing support for 32bit should also mean to provide a 32bit binary, and, of course, providing a binary means that there is support for it. So I don't much see space for 32bit support and no 32bit binary being shipped.

@laanwj
Copy link
Member Author

laanwj commented Nov 25, 2019

So I don't much see space for 32bit support and no 32bit binary being shipped.

I disagree. There are more or less orthogonal. There's plenty of architecture/OS combinations that can run bitcoin core, and we'd try to fix (or at least take PRs for) if it no longer worked, but don't ship executables for.

Similar to windows XP, what about we send out a tweet and a post to the mailing list asking if it would significantly hinder someone from running Bitcoin Core if the i686 builds were removed?

Could do that at some point. I don't use twitter myself at the moment. I did ask on mastodon though, but got no response there.

@greenaddress
Copy link
Contributor

If this is about 'shipping' only then no feedback - but in terms of being able to build for linux 32 bit FYI I still use that to make NDK builds (requires arm, arm64, i686 and x86_64) - although I imagine not many new devices are i686 now

@laanwj
Copy link
Member Author

laanwj commented Dec 16, 2019 via email

@A6GibKm
Copy link

A6GibKm commented Dec 17, 2019

It would be still interesting to know how many clients are i686. But I am sure that even reporting arch is a bad practice from a privacy perspective.

@luke-jr
Copy link
Member

luke-jr commented Jan 3, 2020

A 32-bit VPS is likely to be to reduce RAM usage (which is usually the bottleneck on cheap VPSs). So 32-bit users are also likely to not have the RAM to compile their own (on the VPS).

That being said, I don't know that it makes sense to support cheap VPSs: full nodes exist for providing trust/security, and cheap VPSs are generally insecure by nature.

@maflcko
Copy link
Member

maflcko commented Jan 9, 2020

I sent a note out to the mailing list: https://lists.linuxfoundation.org/pipermail/bitcoin-core-dev/2020-January/000085.html
Could someone do the same for our twitter, maybe?

@laanwj
Copy link
Member Author

laanwj commented Jan 10, 2020

So 32-bit users are also likely to not have the RAM to compile their own (on the VPS).

OTOH compilation takes a lot less memory on 32 bit, too. But it's a good point.

@sha-265
Copy link

sha-265 commented Jan 10, 2020

How much RAM do I need to compile 32-bit build? I'm using the 32-bit build and I'm trying to figure out if I'll be able to compile it myself.

@maflcko
Copy link
Member

maflcko commented Jan 10, 2020

With debug symbols disabled and clang, it should use less than 1 GB. See https://github.com/bitcoin/bitcoin/blob/master/doc/build-unix.md#memory-requirements

@sha-265
Copy link

sha-265 commented Jan 10, 2020

Thanks, I think I will be able to compile by myself.

@cryptozeny
Copy link

cryptozeny commented Jan 10, 2020

Should we still ship 32-bit x86 Linux binaries?

in case VPS, i guess nobody use linux32 binary or architecture.

So 32-bit users are also likely to not have the RAM to compile their own (on the VPS).

good point

In general, running bitcoind in 64 bit is unarguably better. 64-bit registers result in better validation performance and it allows leveldb to use mmap without worrying about virtual memory usage.

totally agreed

Is anyone running x86-32 VMs for other purposes than testing software on that architecture? Even with that, how much testing are these binaries getting?

i feel nobody use linux32 on their VPS nowadays

I also think ARM is a different matter.

yeah

@laanwj
Copy link
Member Author

laanwj commented Feb 3, 2020

Okay, if it's anything to go by, I asked this on twitter a while ago:
https://twitter.com/orionwl/status/1215563281433341952

Two people (of 33541 impressions) told me they were using 32-bit x86 hardware but not the binaries we ship. I think for some kind of offline signing setup. For VPS, it's indeed irrelevant these days.

@maflcko maflcko added this to the 0.20.0 milestone Feb 3, 2020
@emilengler
Copy link
Contributor

Will we still run 32bit in CI?

@luke-jr
Copy link
Member

luke-jr commented Feb 3, 2020

We should, since 32-bit is still supported even if we're not providing binaries.

harding added a commit to bitcoin-core/bitcoincore.org that referenced this issue Feb 6, 2020
fa73ac1 download: Remove i686 Linux links (MarcoFalke)

Pull request description:

  There is only one known user of the i686 linux binary, so it is planned to be removed from the build and quality assurance pipeline. The last user (or users) is encouraged to compile locally with `make check && ./test/functional/test_runner.py` to run the tests on their target system. Using clang, this is possible even on systems with 1 GB of ram. See bitcoin/bitcoin#17504

  Prepare this website and remove the download link from it early.

ACKs for top commit:
  harding:
    Tested ACK fa73ac1

Tree-SHA512: f904d00371d077bf2fb88e69bdde120db518926556a709bc438407a7a00b0572efa61798e48c58e90aeb6191ab2ce2d5846ee178c3a0b5c5f34023999a0cfb41
@maflcko
Copy link
Member

maflcko commented Feb 7, 2020

The link has been removed from the website: https://bitcoincore.org/en/download/

UdjinM6 pushed a commit to UdjinM6/dash that referenced this issue Oct 23, 2021
…x and gitian

fae9084 build: Skip i686 build by default in guix and gitian (MarcoFalke)
fa55a25 depends: Remove reference to win32 (MarcoFalke)

Pull request description:

  Closes bitcoin#17504

  Now that we no longer provide downloads for i686 on our website (https://bitcoincore.org/en/download/), there is no need to build them by default.

  i686 can still be built in depends (tested by ci/travis) and in guix/gitian by setting the appropriate `HOSTS`.

ACKs for top commit:
  practicalswift:
    ACK fae9084 -- patch looks correct
  dongcarl:
    ACK fae9084 patch looks correct
  laanwj:
    Code review ACK fae9084
  hebasto:
    ACK fae9084, I have reviewed the code and it looks OK, I agree it can be merged.

Tree-SHA512: b000c19a2cd2a596a52028fa298c4022c24cfdfc1bdb3795a90916d0a00a32e4dd22278db93790b6a11724e08ea8451f4f05c77bc40d1664518e11a8c82d6e29
UdjinM6 pushed a commit to UdjinM6/dash that referenced this issue Dec 4, 2021
…x and gitian

fae9084 build: Skip i686 build by default in guix and gitian (MarcoFalke)
fa55a25 depends: Remove reference to win32 (MarcoFalke)

Pull request description:

  Closes bitcoin#17504

  Now that we no longer provide downloads for i686 on our website (https://bitcoincore.org/en/download/), there is no need to build them by default.

  i686 can still be built in depends (tested by ci/travis) and in guix/gitian by setting the appropriate `HOSTS`.

ACKs for top commit:
  practicalswift:
    ACK fae9084 -- patch looks correct
  dongcarl:
    ACK fae9084 patch looks correct
  laanwj:
    Code review ACK fae9084
  hebasto:
    ACK fae9084, I have reviewed the code and it looks OK, I agree it can be merged.

Tree-SHA512: b000c19a2cd2a596a52028fa298c4022c24cfdfc1bdb3795a90916d0a00a32e4dd22278db93790b6a11724e08ea8451f4f05c77bc40d1664518e11a8c82d6e29
@bitcoin bitcoin locked as resolved and limited conversation to collaborators Feb 15, 2022
Munkybooty pushed a commit to Munkybooty/dash that referenced this issue Nov 15, 2022
…tian

fae9084 build: Skip i686 build by default in guix and gitian (MarcoFalke)
fa55a25 depends: Remove reference to win32 (MarcoFalke)

Pull request description:

  Closes bitcoin#17504

  Now that we no longer provide downloads for i686 on our website (https://bitcoincore.org/en/download/), there is no need to build them by default.

  i686 can still be built in depends (tested by ci/travis) and in guix/gitian by setting the appropriate `HOSTS`.

ACKs for top commit:
  practicalswift:
    ACK fae9084 -- patch looks correct
  dongcarl:
    ACK fae9084 patch looks correct
  laanwj:
    Code review ACK fae9084
  hebasto:
    ACK fae9084, I have reviewed the code and it looks OK, I agree it can be merged.

Tree-SHA512: b000c19a2cd2a596a52028fa298c4022c24cfdfc1bdb3795a90916d0a00a32e4dd22278db93790b6a11724e08ea8451f4f05c77bc40d1664518e11a8c82d6e29
knst pushed a commit to knst/dash that referenced this issue Feb 9, 2023
…tian

fae9084 build: Skip i686 build by default in guix and gitian (MarcoFalke)
fa55a25 depends: Remove reference to win32 (MarcoFalke)

Pull request description:

  Closes bitcoin#17504

  Now that we no longer provide downloads for i686 on our website (https://bitcoincore.org/en/download/), there is no need to build them by default.

  i686 can still be built in depends (tested by ci/travis) and in guix/gitian by setting the appropriate `HOSTS`.

ACKs for top commit:
  practicalswift:
    ACK fae9084 -- patch looks correct
  dongcarl:
    ACK fae9084 patch looks correct
  laanwj:
    Code review ACK fae9084
  hebasto:
    ACK fae9084, I have reviewed the code and it looks OK, I agree it can be merged.

Tree-SHA512: b000c19a2cd2a596a52028fa298c4022c24cfdfc1bdb3795a90916d0a00a32e4dd22278db93790b6a11724e08ea8451f4f05c77bc40d1664518e11a8c82d6e29
PastaPastaPasta pushed a commit to knst/dash that referenced this issue Feb 20, 2023
…tian

fae9084 build: Skip i686 build by default in guix and gitian (MarcoFalke)
fa55a25 depends: Remove reference to win32 (MarcoFalke)

Pull request description:

  Closes bitcoin#17504

  Now that we no longer provide downloads for i686 on our website (https://bitcoincore.org/en/download/), there is no need to build them by default.

  i686 can still be built in depends (tested by ci/travis) and in guix/gitian by setting the appropriate `HOSTS`.

ACKs for top commit:
  practicalswift:
    ACK fae9084 -- patch looks correct
  dongcarl:
    ACK fae9084 patch looks correct
  laanwj:
    Code review ACK fae9084
  hebasto:
    ACK fae9084, I have reviewed the code and it looks OK, I agree it can be merged.

Tree-SHA512: b000c19a2cd2a596a52028fa298c4022c24cfdfc1bdb3795a90916d0a00a32e4dd22278db93790b6a11724e08ea8451f4f05c77bc40d1664518e11a8c82d6e29
gades pushed a commit to cosanta/cosanta-core that referenced this issue Dec 2, 2023
…tian

fae9084 build: Skip i686 build by default in guix and gitian (MarcoFalke)
fa55a25 depends: Remove reference to win32 (MarcoFalke)

Pull request description:

  Closes bitcoin#17504

  Now that we no longer provide downloads for i686 on our website (https://bitcoincore.org/en/download/), there is no need to build them by default.

  i686 can still be built in depends (tested by ci/travis) and in guix/gitian by setting the appropriate `HOSTS`.

ACKs for top commit:
  practicalswift:
    ACK fae9084 -- patch looks correct
  dongcarl:
    ACK fae9084 patch looks correct
  laanwj:
    Code review ACK fae9084
  hebasto:
    ACK fae9084, I have reviewed the code and it looks OK, I agree it can be merged.

Tree-SHA512: b000c19a2cd2a596a52028fa298c4022c24cfdfc1bdb3795a90916d0a00a32e4dd22278db93790b6a11724e08ea8451f4f05c77bc40d1664518e11a8c82d6e29
gades pushed a commit to piratecash/pirate that referenced this issue Dec 9, 2023
…tian

fae9084 build: Skip i686 build by default in guix and gitian (MarcoFalke)
fa55a25 depends: Remove reference to win32 (MarcoFalke)

Pull request description:

  Closes bitcoin#17504

  Now that we no longer provide downloads for i686 on our website (https://bitcoincore.org/en/download/), there is no need to build them by default.

  i686 can still be built in depends (tested by ci/travis) and in guix/gitian by setting the appropriate `HOSTS`.

ACKs for top commit:
  practicalswift:
    ACK fae9084 -- patch looks correct
  dongcarl:
    ACK fae9084 patch looks correct
  laanwj:
    Code review ACK fae9084
  hebasto:
    ACK fae9084, I have reviewed the code and it looks OK, I agree it can be merged.

Tree-SHA512: b000c19a2cd2a596a52028fa298c4022c24cfdfc1bdb3795a90916d0a00a32e4dd22278db93790b6a11724e08ea8451f4f05c77bc40d1664518e11a8c82d6e29
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

10 participants