Debian Likely Moving Away From i386 In The Near Future
web.archive.org

The article title is “Debian Likely Moving Away From i386 In The Near Future” but according to the article Debian will drop i386 support because it will be dropped from the kernel. Seems like bad news for permacomputing folks.

(EDIT) modified the title since it seems more accurate to say that 32-bit support is being dropped. (reference)

        • activistPnk@slrpnk.netOP
          41·
          11 months ago

          That’s quite interesting because the spy chips¹ began in 2008ish. So people who avoid the spy chips are losing options. There may not be many 64bit machines that pre-date the spy chips (edit: there might be a 5-year span of 64-bit AMD spy-free chips). I’m lucky to have a machine from 2008 just before the anti-consumer chips came out. IIUC there is only one modern architecture that avoids the spy chips: the IBM Power11.

          1: spy chips → Intel’s Management Engine/ARM trustzone/AMD’s Platform Security Processor; tech that is anti-non-corporate consumer

            • activistPnk@slrpnk.netOP
              1·
              11 months ago

              Referring to Minix was not my intent. A short overview of the issue is here. As you apparently know Intel chips after 2008 use Minix for the management engine but I’m not sure to what extent Minix itself is a factor the vulns. The problem is the mere existence of an attack surface hard-wired into processors that can be externally exploited when the purpose of the ME is useless to non-corporate users. Bugs have been discovered that enable attackers to install malicious firmware¹. AMD’s PSP is also a problem and I don’t know if the PSP OS has been revealed. PSP is composed of an ARM processor with Trustzone, but I don’t know what OS Trustzone uses.

              I just realized I forgot AMD PSP did not hit until 2013, so I guess there must be a lot of 64bit spychip-free boards out there made from 2008—2013.

              1: ⚠ that link is enshitified with autoplay so I suggest using Lynx to access it.

      • purplemonkeymad@programming.dev
        3·
        11 months ago

        No, that is not what it means. i386 is specifically the set of instructions that the 386 introduced. Later processors from intel added additional instructions, those were rolled into i686 as a set. i686 contains i386 so it can still run programs that target that, but a 386 can’t run a i686 program.

        i386 and i686 are both x86 32 bit instruction sets.

        What is happening is that the kernel will no longer support i386 as a target. So any processor that does not support at least i686 will stop working. This is basically anything before around a pentium 3 (iirc might be wrong about exact CPU.) Vista era computers should not be effected.

        The confusing part is that some distros have already dropped all 32bit for other reasons, but it would mean it would be hard for distros going forward to support 386 era processors.

  • Draconic NEO@lemmy.sdf.orgEnglish
    3·
    11 months ago

    The CADT model at it’s finest. It’s funny because Linux is considered the de facto choice for legacy hardware because it runs so well on it, or at least used to. The fact is the development model used by distros (and apparently also the Linux kernel as well) is absolutely awful, and it inevitably hurts movements that depend on it such as Permacomputing.

    • activistPnk@slrpnk.netOP
      1·
      11 months ago

      I don’t have a deep knowledge of the kernel to know if it’s as easy as simply adding in a separate module.

  • feoh@lemmy.sdf.orgEnglish
    21·
    11 months ago

    So it’s interesting reading all the folks talking about permacomputing and the like.

    And I think there’s merit to keeping those architectures around.

    But let’s turn this on its head, shall we? Where do we get the people who still have that hardware who are willing to actively take part in Linux kernel development?

    Like, to become facile enough with the process, tools and codebase to be able to bear the load of writing new security patches as vulnerabilities are found?

    It’s a hard problem. The number of people actively contributing to Linux is large in aggregate but VANISHINGLY small when it comes to any particular area of interest.