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

issue laanwj openend this issue on November 18, 2019
  1. laanwj commented at 11:07 am on November 18, 2019: member

    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.)

  2. laanwj added the label Brainstorming on Nov 18, 2019
  3. laanwj added the label Build system on Nov 18, 2019
  4. hebasto commented at 1:38 pm on November 18, 2019: member
    Agree to keep building and providing 32-bit binaries for ARM only.
  5. practicalswift commented at 3:05 pm on November 18, 2019: contributor

    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”).

  6. emilengler commented at 5:05 pm on November 20, 2019: contributor
    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.
  7. laanwj commented at 6:48 pm on November 20, 2019: member
    @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.
  8. MarcoFalke commented at 1:53 pm on November 25, 2019: member

    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: https://github.com/flathub/org.bitcoincore.bitcoin-qt/pull/2#issuecomment-557953031

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

  9. MarcoFalke commented at 1:59 pm on November 25, 2019: member
    Also, starting with Ubuntu Bionic 18.04 and Fedora 31, neither OS will ship 32 bit iso images.
  10. MarcoFalke commented at 3:32 pm on November 25, 2019: member
    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?
  11. A6GibKm commented at 4:20 pm on November 25, 2019: none
    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.
  12. laanwj commented at 7:01 pm on November 25, 2019: member

    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.

  13. greenaddress commented at 7:44 pm on December 16, 2019: 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
  14. laanwj commented at 8:10 pm on December 16, 2019: member

    This is only about shipping binaries.

    As for building from source, Bitcoin Core is portable software to both 32 and 64 bit architectures, even obscure ones (as far as realistic, but I see no reason at all to refuse building for i686).

  15. A6GibKm commented at 1:06 am on December 17, 2019: none
    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.
  16. luke-jr commented at 3:54 am on January 3, 2020: member

    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.

  17. MarcoFalke commented at 5:39 pm on January 9, 2020: member
    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?
  18. laanwj commented at 9:25 am on January 10, 2020: member

    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.

  19. sha-265 commented at 11:26 am on January 10, 2020: none
    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.
  20. MarcoFalke commented at 3:18 pm on January 10, 2020: member
    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
  21. sha-265 commented at 4:29 pm on January 10, 2020: none
    Thanks, I think I will be able to compile by myself.
  22. cryptozeny commented at 6:58 pm on January 10, 2020: none

    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

  23. laanwj commented at 9:46 am on February 3, 2020: member

    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.

  24. MarcoFalke removed the label Brainstorming on Feb 3, 2020
  25. MarcoFalke added this to the milestone 0.20.0 on Feb 3, 2020
  26. emilengler commented at 11:58 am on February 3, 2020: contributor
    Will we still run 32bit in CI?
  27. luke-jr commented at 1:24 pm on February 3, 2020: member
    We should, since 32-bit is still supported even if we’re not providing binaries.
  28. harding referenced this in commit 11940dd8c9 on Feb 6, 2020
  29. MarcoFalke commented at 2:47 pm on February 7, 2020: member
    The link has been removed from the website: https://bitcoincore.org/en/download/
  30. fanquake closed this on Feb 11, 2020

  31. UdjinM6 referenced this in commit 8e7bf394d1 on Oct 23, 2021
  32. UdjinM6 referenced this in commit b5f5bf7330 on Dec 4, 2021
  33. DrahtBot locked this on Feb 15, 2022
  34. Munkybooty referenced this in commit 98388ee60c on Nov 15, 2022
  35. knst referenced this in commit f7a4a85839 on Feb 9, 2023
  36. PastaPastaPasta referenced this in commit 1f9f160d24 on Feb 20, 2023

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2024-10-04 22:12 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me