5 ms·

> Debian GNU/Hurd is currently available for the i386 architecture with about 80% of the Debian archive, and more to come! Does Hurd still not support amd64?!

lol768 7y ago
From https://www.gnu.org/software/hurd/faq/64-bit.html https://www.gnu.org/software/hurd/faq/64-bit.html > There are currently no plan for 64-bit userland, but there are plans for 64-bit kernelland with 32-bit userland, which will notably permit to efficiently make use of more than 2 GiB memory and provide 4 GiB userland addressing space. Work on this is currently in the master-x86_64 and port-amd64 branches for GNU Mach. > That being said, you can always run a 32-bit version on a 64-bit machine, it just works, processes are just limited to a couple GiB available memory.
- StudentStuff 7y ago
  Debian x32 has a pretty similar concept wrt more efficient memory usage: https://wiki.debian.org/X32Port https://wiki.debian.org/X32Port
  - chrisseaton 7y ago
    You can also store pointers for more than 4 GB in a 32 bit address by compressing them.
    - comradesmith 7y ago
      But you are still using 32 bit registers so your load and save instructions can't really make use of compressed addresses
      - deleted 7y ago
        [deleted]
- nerdponx 7y ago
  I don't really understand how all this stuff works at the kernel level, but if you have a 64-bit kernel what would prevent you from also having 64-bit user programs?
  - _wmd 7y ago
    There is quite a lot of surface area between a program and the kernel - C library, dynamic linker, system call interface, memory layout, droves of permission and sanity checking logic etc. that would need to be updated too. A 64 bit kernel is a first step
colanderman 7y ago
That's ironic, given that last I heard anything about Hurd, it was that partition size was constrained by bus width (i.e., it couldn't access disks larger than 2 GiB on most computers at the time), but since everyone was moving to 64-bit architectures soon enough, that wouldn't be an issue. (Not sure where I heard that particular excuse, but the explanation why is here: [1]) 32-bit userland makes Hurd basically unusable for many server applications, where multi-gigabyte in-memory lookup tables are critical for performance. [1] https://developers.slashdot.org/comments.pl?sid=44492&cid=4622920 https://developers.slashdot.org/comments.pl?sid=44492&cid=46...

lol768 7y ago

From https://www.gnu.org/software/hurd/faq/64-bit.html https://www.gnu.org/software/hurd/faq/64-bit.html > There are currently no plan for 64-bit userland, but there are plans for 64-bit kernelland with 32-bit userland, which will notably permit to efficiently make use of more than 2 GiB memory and provide 4 GiB userland addressing space. Work on this is currently in the master-x86_64 and port-amd64 branches for GNU Mach. > That being said, you can always run a 32-bit version on a 64-bit machine, it just works, processes are just limited to a couple GiB available memory.

StudentStuff 7y ago
Debian x32 has a pretty similar concept wrt more efficient memory usage: https://wiki.debian.org/X32Port https://wiki.debian.org/X32Port
- chrisseaton 7y ago
  You can also store pointers for more than 4 GB in a 32 bit address by compressing them.
  - comradesmith 7y ago
    But you are still using 32 bit registers so your load and save instructions can't really make use of compressed addresses
    - deleted 7y ago
      [deleted]
nerdponx 7y ago
I don't really understand how all this stuff works at the kernel level, but if you have a 64-bit kernel what would prevent you from also having 64-bit user programs?
- _wmd 7y ago
  There is quite a lot of surface area between a program and the kernel - C library, dynamic linker, system call interface, memory layout, droves of permission and sanity checking logic etc. that would need to be updated too. A 64 bit kernel is a first step

colanderman 7y ago

That's ironic, given that last I heard anything about Hurd, it was that partition size was constrained by bus width (i.e., it couldn't access disks larger than 2 GiB on most computers at the time), but since everyone was moving to 64-bit architectures soon enough, that wouldn't be an issue. (Not sure where I heard that particular excuse, but the explanation why is here: [1]) 32-bit userland makes Hurd basically unusable for many server applications, where multi-gigabyte in-memory lookup tables are critical for performance. [1] https://developers.slashdot.org/comments.pl?sid=44492&cid=4622920 https://developers.slashdot.org/comments.pl?sid=44492&cid=46...