Arch Linux pulls the plug on 32-bit

Post by lamontcg » Fri, Feb 10, 2017, 5:01 PM UTC

StreakyCobra wrote: post #12

It is one of the reasons that makes me love Arch: developers are pragmatic. They were always in the early birds for taking decision about the future, like switching to Python3 as default interpreter system-wide, embracing the change to systemd, and now this. The rolling release aspect imposes to stay as close as possible to upstream versions because upstream does not wait on Arch to update their dependencies to newer…

Post by kogepathic » Sat, Feb 11, 2017, 9:18 AM UTC

scandox wrote: post #187

kogepathic wrote: post #111

Earlier quoted context omitted.

If it's a DK200, then I've built grub to bypass secure boot. You can boot other Linuxes on it (e.g. Yocto) but as per my parent comment, not much will work. I have an SPI image and instructions to flash if you're interested. You'll need an SPI programmer like the ch341a. I think Intel is violating the GPL by not providing sources, since they include a written offer and GPL requires source availability for 3 years. I…

Honestly this all occurred over a year ago and I just ditched it

Post by poizan42 » Sat, Feb 11, 2017, 2:09 PM UTC

aaronmdjones wrote: post #139

poizan42 wrote: post #75

Earlier quoted context omitted.

There are a lot of things that gives bigger memory usage and larger code size that modern compilers do that we could try to address. * The stack is always kept aligned at 16 bytes boundary. This is needed for external calls by the ABI, but LTCG could drop these for internal calls and align the stack when needing SSE instead. This may be slightly more expensive than keeping the stack constantly 16-byte aligned, but it…

> * Inefficient instructions are replaced with more efficient instructions. For example gcc will for a simple x % 19 generate no less than 16 instructions instead of a single div/idiv. This is probably still faster, but it may still be detrimental if it's not in a hot path. It should be noted that gcc emits this even at -O0. Does it emit it at -Os ?

    main:
    .LFB0:
            .cfi_startproc
            pushq   %rbp
            .cfi_def_cfa_offset 16
            .cfi_offset 6, -16
            movq    %rsp, %rbp
            .cfi_def_cfa_register 6
            subq    $16, %rsp
            movl    %edi, -4(%rbp)
            movq    %rsi, -16(%rbp)
            movl    -4(%rbp), %ecx
            movl    $1808407283, %edx
            movl    %ecx, %eax
            imull   %edx
            sarl    $3, %edx
            movl    %ecx, %eax
            sarl    $31, %eax
            subl    %eax, %edx
            movl    %edx, %eax
            sall    $3, %eax
            addl    %edx, %eax
            addl    %eax, %eax
            addl    %edx, %eax
            subl    %eax, %ecx
            movl    %ecx, %edx
            movl    %edx, %esi
            movl    $.LC0, %edi
            movl    $0, %eax
            call    printf
            movl    $0, %eax
            leave
            .cfi_def_cfa 7, 8
            ret
            .cfi_endproc

    main:
    .LFB13:
            .cfi_startproc
            pushq   %rax
            .cfi_def_cfa_offset 16
            movl    %edi, %eax
            movl    $19, %ecx
            cltd
            movl    $.LC0, %esi
            movl    $1, %edi
            idivl   %ecx
            xorl    %eax, %eax
            call    __printf_chk
            xorl    %eax, %eax
            popq    %rdx
            .cfi_def_cfa_offset 8
            ret
            .cfi_endproc

Post by Latty » Sun, Feb 12, 2017, 4:30 AM UTC

rlpb wrote: post #194

Latty wrote: post #192

Earlier quoted context omitted.

I chose to run a bleeding edge distro to be on the bleeding edge. Requiring me to make the changes to be on the bleeding edge manually makes no sense. Expecting that is as weird as expecting super stable LTS releases to run the latest-and-greatest of everything.

> Requiring me to make the changes to be on the bleeding edge manually makes no sense. Which part of "You wouldn't have to do it manually" do you not understand?

Post by hobarrera » Sun, Feb 12, 2017, 9:11 AM UTC

rlpb wrote: post #190

hobarrera wrote: post #180

Earlier quoted context omitted.

The thing is, python guidelines (PEPs) stated that shebangs should specify python2 or python3 explicitly during the transition period. Using "#!/usr/bin/env python" for a project that was python2-only was not following guidelines, so the breakage was really the dev's fault. Also, the python2 symlink should have already been there. Bad packaging on some distros resulted in bad practices packaging by some devs. Don't b…

You're getting the ordering of events wrong. Arch's actions weren't in response to the PEP. The PEP was written in response to Arch's actions. > Also, the python2 symlink should have already been there. Nope. There was no such convention or specification at the time. There was, however, convention and specification (in the form of "what Python upstream build systems do") on what /usr/bin/python means, which is "Pytho…