[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Re-evaluating architecture inclusion in unstable/experimental



On 9/29/18 12:02 PM, Adam Borowski wrote:
> With primary use cases being hosting of multiple containers, and/or running
> a large number-crunching cluster.  Sacrificing lots of human hassle for a 7%
> speed boost makes you a "Gentoo ricer"[1] on a desktop/laptop, but could be
> a nice thing on a $1M cluster.

It can be up to 50% which is why Intel's own C/C++ compiler actually provides
an option to automatically generate x86_64 code with 32-bit pointers:

> https://software.intel.com/en-us/node/523141

> But, recently someone approached me with exactly that use case.  He also
> required jessie, which happens to be the only release I have a consistent
> set of packages for.  The evaluation result was: nope.
> 
> A short while ago Linus pondered dropping x32, as it complicates kernel
> syscall code.  The only proof he was told that "it's still in use" was my
> https://debian-x32.org -- yet that site hasn't been updated since jessie.

I was actually on this discussion and I provided Linus with an up-to-date
x32 chroot to test the changes which apparently worked.

> Thus: I propose to drop x32, and reallocate your tuits to other archs.

Thanks, but x32 doesn't really use any resources and as long as the stuff
works, I don't see a reason to keep people from using it. If Linux upstream
decides to ax it, we will ax it here as well. Until then, it allows doing
some extra CI for package builds and edge cases.

And as long people invest resources in ports like Hurd and kFreeBSD, x32
is the lesser burden to be worried about.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


Reply to: