Announcement

Collapse
No announcement yet.

openSUSE Is Still Looking For Users To Step Up And Maintain 32-bit x86 Support

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Originally posted by skeevy420 View Post
    Devil's Advocate: That's to be expected. It makes more sense to buy current and supported hardware that has software support for a known amount of time than it is to pay someone to maintain software for an unknown amount of time on hardware that's becoming harder to find. If you're going to pay someone to develop or maintain software then you'd pay them to upgrade or rewrite whatever it is you depend on to work on current, preferably long term supported, hardware.

    Also, in some ways it is kind of like Wal-Mart going, "OK. So we're going to need some volunteers to stock produce for now on. Grab some veggies on your way in and put them on a shelf before you go shopping for or we're just not going to have the Produce Department any more." It makes me wonder what they were paying to keep an entire hardware architecture supported up until now and if it isn't at least worth considering offering some low ball positions that are geared for retired or poor developers that want something to do but either don't want the responsibilities or have the financial means of maintaining a company's software stack for free or out of pocket.
    Even though many professional programs' suites that we use on Windows still install the .exe program is still on program files(x86) even there is the x64 program files folder, I don't understand why Linux' community for every distro complains when the developers drop the 32-bit packages support, why others put these 32-bit libraries like a sandbox by flatpak or snap package for every distro that it won't depend on the packages that runs natively on the distro such as rpm, Deb or arch package

    Comment


    • #32
      Originally posted by Joe Braga View Post

      Even though many professional programs' suites that we use on Windows still install the .exe program is still on program files(x86) even there is the x64 program files folder, I don't understand why Linux' community for every distro complains when the developers drop the 32-bit packages support, why others put these 32-bit libraries like a sandbox by flatpak or snap package for every distro that it won't depend on the packages that runs natively on the distro such as rpm, Deb or arch package
      Because Windows never dropped 32-bit compatibility so some developers have never been compelled to go beyond 32-bit and since Windows and Intel still make and support 32-bit operating systems & compatibility layers and hardware a lot of developers still target 32-bit as their only target or their bare minimum. Why go beyond what you don't actually have to? Why support more than what you actually have to support?

      It also doesn't help that 64-bit was always touted as the platform that runs everything x86 and how a lot of 64-bit operating systems have supported multilib and backwards compatibility for the past 15-20+ years. On that same note, Microsoft, Apple, etc have a lot of money to ensure a good multilib solution exists and, in the case of Apple, can make special hardware just so x86 performance isn't utter crap on a different architecture and so that they can have backwards compatibility so their users can keep on running what they run as well as they have implemented FatELFs (multiple architecture binaries) so the same binary and library can run on PPC and x86.

      I don't know what the best solution is, but the nuclear route of dropping 32-bit and hoping in one hand kind of sucks. The Flat/Snap options kind of suck due to dropping 32-bit hardware in lieu of compat layers that could be further optimized, that take up a lot of storage space, and they don't even have tools like Flatseal so, unlike Microsoft and Apple, you end up being a command line warrior reading man pages instead of clicking a few things and getting on with your life.

      Now I wonder how Fat an i686/64-v2 binary would be or if an ObeseELF consisting of i686/v2/v3 could work...or all the levels for that matter...I figure that if regardless of what we do in the name of greater compatibility that if we're gonna be hit with a storage penalty then we might as well use a solution that supports more hardware and software combinations and optimizations instead of less.

      Comment


      • #33
        Michael where can I apply?

        Comment

        Working...
        X