• t3rmit3@beehaw.org
    link
    fedilink
    arrow-up
    11
    ·
    3 days ago

    Understandable, but still kind of sad to see support for 32-bit dying. Mostly because it makes me feel old. :P

      • t3rmit3@beehaw.org
        link
        fedilink
        arrow-up
        10
        ·
        edit-2
        3 days ago

        Yes, but the architectures they are dropping are older 32-bit ones. That’s why I said support is “dying”, not “dead”.

        The changelog itself notes that this is about 32-bit support:

        Debian’s support for 32-bit PC (known as the Debian architecture i386) now no longer covers any i586 processor.

  • megopie@beehaw.org
    link
    fedilink
    arrow-up
    8
    ·
    3 days ago

    At this point systems that need it are probably a couple decades old at least.

    But I’m sure there are people out there who are using some ancient system/program because it does what they need and don’t want to buy a new license or pay for a subscription. Guess they’ll just have to stick with the older versions and keep their systems offline to avoid security issues. Or just emulate an older system when they need it.

    • Dave.@aussie.zone
      link
      fedilink
      arrow-up
      6
      ·
      edit-2
      2 days ago

      Lots of expensive industrial equipment runs these kinds of processors still. You can still buy motherboards with 8 bit ISA slots even, although you’ll pay quite a premium.

      But all of that kind of gear typically runs its own distro with an in-house build system. For example, my work uses a flavour of Buildroot for their embedded Linux systems and you can just set whatever processor type you like all the way back to plain old i386 when you build it.

  • deadcatbounce@reddthat.com
    link
    fedilink
    arrow-up
    4
    ·
    edit-2
    3 days ago

    Whilst other distros move to a Weston (corrections please?) era Intel x86 2013 ish?

    Bravo, I think. That’s going to be tough.

    On a related track, is there any talk of 128 bit chips in general?

    • The_Decryptor@aussie.zone
      link
      fedilink
      English
      arrow-up
      3
      ·
      3 days ago

      I think CHERI is the only real attempt at a 128 bit system, but it uses the upper 64 bits for metadata, so the address space is still 64 bits.

      • deadcatbounce@reddthat.com
        link
        fedilink
        arrow-up
        1
        ·
        3 days ago

        Thank-you a lot for that. I wander around the tech blogs like lobsters etc, Reddit and here but never see anything that i remember seeing (if you follow me), but I don’t consciously look.

        Encryption lengths are getting long so you’d think it was high time.

        Your description sounds like the advent of 32 bits where there was a 16 bit address bus stage.

        • spit_evil_olive_tips@beehaw.org
          link
          fedilink
          arrow-up
          2
          ·
          3 days ago

          Encryption lengths are getting long so you’d think it was high time.

          that’s unrelated - AES-256 for example can be executed just fine on either a 32- or 64-bit machine. in theory there’s nothing stopping you from running it on an 8-bit or 16-bit CPU (although other considerations related to the size of AES’s lookup tables make this unlikely). from some random googling, here is an implementation of Chacha20, another 256-bit encryption algorithm, for 8-bit microcontrollers.

          when we talk about 32 vs 64-bit CPUs, in general we’re only talking about the address space - the size of a pointer determines how much RAM the computer is able to use. 32-bit machines were typically limited to 4GB (though PAE helped kick that can down the road)

          CPU registers can also be sized independently of the address space - for example AVX-512 CPUs have a register that is 512 bits wide even though the CPU is still “64-bit”.

          • deadcatbounce@reddthat.com
            link
            fedilink
            arrow-up
            1
            ·
            edit-2
            3 days ago

            that’s unrelated - AES-256 for example can be executed just fine on either a 32- or 64-bit machine. in theory there’s nothing stopping you from running it on an 8-bit or 16-bit CPU (although other considerations related to the size of AES’s lookup tables make this unlikely). from some random googling, here is an implementation of Chacha20, another 256-bit encryption algorithm, for 8-bit microcontrollers.

            I started out programming a 6502a in 1980, 680X0 a little later in 87, so I get that bit, but it’s easier doing operations on a larger register. I remember writing code for 8 bit multiplication of 32 bit floating points.

            I enjoyed and understood the rest of your prose though. Didn’t do much/any programming/low level after say 2005, and regret it now. Trying to re-learn but things have moved on so much.

            I take that there isn’t much motivation in moving to 128 because it’s big enough; it’s only 8 cycles (?) to fill a 512 (that can’t be right?).

            • The_Decryptor@aussie.zone
              link
              fedilink
              English
              arrow-up
              1
              ·
              3 days ago

              I take that there isn’t much motivation in moving to 128 because it’s big enough; it’s only 8 cycles (?) to fill a 512 (that can’t be right?).

              8 cycles would be an eternity on a modern CPU, they can achieve multiple register sized loads per cycle.

              If we do see a CPU with 128 bit addresses anytime soon, it’ll be something like CHERI, where the extra bits are used for flags.

    • smeg@feddit.uk
      link
      fedilink
      English
      arrow-up
      7
      ·
      3 days ago

      Well yeah, isn’t long term support and stability Debian’s whole thing?