Announcement

Collapse
No announcement yet.

OpenMandriva Is Also Making Plans To Move Away From 32-Bit Support

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

  • #21
    Originally posted by skeevy420 View Post
    Yeah, I misread ACTION: 2 to mean the i686 part of multilib and not the i686 version of the distribution. As long as multilib isn't dropped y'all should be just fine (unless something better and easier to maintain like a Wine for Linux32 emerges).
    Multilib essentially is wine for linux32 -- a set of libraries that are binary compatible with something being emulated (Windows/Linux32). On top of it, there's the setarch tool in util-linux (which in this context is comparable to the wine launcher).

    Originally posted by skeevy420 View Post
    I honestly can't think of a good reason to keep x86_32 outside of the usual "some business has some odd application that doesn't work on newer stuff" argument and the proper solution to that is create a job or three, hire a programmer or three, and get your stuff updated you shitty company or the other usual argument of "people from the third world" (but ARM and smartphones changes that 2010 idea).
    Agreed -- and unless that old application is REALLY REALLY REALLY broken (e.g. relying on a binary-only kernel module that exists only as an x86_32 binary -- but in that case it'll already depend on a prehistoric kernel version that no sane distribution would ship), it will run in multilib or at least in a chroot environment launched with setarch.

    And while I'm not a fan of the likes of flatpak, appimage or snap (way too much duplication -- bundled libraries waste space and cause security problems [e.g. zlib security problem found, system zlib updated, but there's still a broken zlib inside the flatpak --> application still vulnerable even though the user thought he fixed his system]), this sort of stuff is where that sort of tool can be useful (just build an appimage/flatpak/whatever from the existing x86_32 system to get all the libraries).
    But that's not even necessary given multilib is there to stay (at least as far as OpenMandriva is concerned).
    It's 2019. DOS hasn't really been used for 30+ years. Yet people still play games in dosbox. The C64 pretty much went out of the mainstream some 40 years ago -- yet we still include a C64 emulator. Given that and similar use cases, I predict we'll still have x86_32 multilib libraries in 2050 (30 years from now that most distributions are starting to phase out x86_32 and Microsoft starts getting serious about 64-bit applications to make wine32 obsolete).
    Even if if x86 is obsolete by 2050 and we're all on RISC-V, ARM, Loongson, Elbrus or OpenPOWER boxes (or yet another architecture that doesn't even exist yet, maybe RISC-VI), I expect we'll have some form of x86_32 multilibs combined with qemu or another CPU emulator (just for fun, I've tried -- running win32 applications on ARM with wine32 run through qemu with binfmt-misc is slow but possible. It'll likely work out of the box in a future OpenMandriva version).

    As for people from the third world, most people who think they're on prehistoric boxes have never been there. I've been to Ethiopia in 2007. Outside of the first-generation OLPC boxes that were being tried in a few schools, I didn't spot any x86_32 machines there even then. People either had no computers (sometimes no electricity to run them with), or halfway modern computers. Not a lot in between.

    And of course we can already run on lower end ARM boards that are cheaper than x86_32 boxes these days.
    Last edited by berolinux; 06-21-2019, 02:42 PM.

    Comment


    • #22
      Originally posted by berolinux View Post

      Multilib essentially is wine for linux32 -- a set of libraries that are binary compatible with something being emulated (Windows/Linux32). On top of it, there's the setarch tool in util-linux (which in this context is comparable to the wine launcher).
      I just mean something more standardized than distributions shipping 32bit versions of their software. Something able to emulate older kernel versions and what was used in previous generations. Like how in winecfg or with Windows compatibility mode we can pick from 3.1 to 10, some sort of "emulator" that did Debian 1 to 10 in the same manner so that we can preserve historical Linux like Wine helps preserve historical Windows as well as accommodate various legacy business and proprietary programs. I say Debian, but any old distribution like Debian or Slackware would work if they've been there from the beginning (or real close to it) and have clear and defined versions for a "Line" project to target like how Wine has clear and defined Windows versions to target.

      People in general like their older stuff for whatever reasons. It's why we have projects like Wine, Haiku, React, Retroarch, and a whole lot more. A topic like this wouldn't generate so much commotion if that weren't the case.

      Even if if x86 is obsolete by 2050 and we're all on RISC-V, ARM, Loongson, Elbrus or OpenPOWER boxes (or yet another architecture that doesn't even exist yet, maybe RISC-VI), I expect we'll have some form of x86_32 multilibs combined with qemu or another CPU emulator (just for fun, I've tried -- running win32 applications on ARM with wine32 run through qemu with binfmt-misc is slow but possible. It'll likely work out of the box in a future OpenMandriva version).
      They'll call it RISC-III in America.

      But, yeah, I agree with all of that. It's going to be really interesting when Linux distributions on random architectures are able to offer just as well or better (legacy) Windows support than Windows itself.

      Comment


      • #23
        Originally posted by [email protected] View Post
        There is nothing stopping people on using the latest kernel and graphic drivers on a Ubuntu LTS release.
        There is nothing stopping people from using a stable rolling release like OpenSUSE Tumbleweed where you don't need to micromanage that.

        Really, what's the fucking point of using a distro where you replace the core components with third party PPAs.

        Comment


        • #24
          Originally posted by berolinux View Post
          Unlike Ubuntu, OpenMandriva is most definitely not dropping 32bit libraries needed for Wine and Steam.
          The only think we're thinking of dropping is running the whole OS on 32bit x86 hardware.
          Which is fine for me. Really even dropping 32bit multilib is fine for me. Running old windows crap and old proprietary software should be pushed into decent sandboxing solutions that also can deal with providing a stable 32bit environment to run it without risk of future breakage.

          I was just explaining why people is angry at the thought of dropping 32bit multilib to that guy.

          Comment


          • #25
            Originally posted by Vistaus View Post

            What's that? The only PC104 I know is a common keyboard layout.
            Is your Google broken good sir?

            https://rtdusa.com/PC104/default.htm
            PC104 is an embedded computer standard defined by its compact footprint and its stacking bus structure. In essence, PC104 is a modular, ruggedized version of the PC. Instead of using a backplane, PC104 modules mate together via stackable ISA, PCI, and PCIe bus connectors. The stackable connectors and asymmetric corner mounting holes create a compact and modular rugged system.

            Comment


            • #26
              Originally posted by skeevy420 View Post

              "Herbs" have just recently became available in my state as a legal treatment.
              be wise legalize

              Comment


              • #27
                Originally posted by xfcemint View Post
                I thinky many (most?) developers, like myself, are having panic attacks
                If your software can't be recompiled to 64bits without fixing it, then it was shit.

                I mean, ok, a lot of commercial software is shit like that, but I'm not blaming the architecture change for that.

                Comment


                • #28
                  Originally posted by starshipeleven View Post
                  If your software can't be recompiled to 64bits without fixing it, then it was shit.

                  I mean, ok, a lot of commercial software is shit like that, but I'm not blaming the architecture change for that.
                  Most of my software is multi-platform, but switching to 64-bits changes sizes of structures. That change needs extensive testing.
                  How can I be sure that some old program of mine doesn't depend on some structure having exactly X bytes? Or some library that my program is using?

                  Very risky stuff.
                  Think of all the man-hours required for testing, and for checking every structure definition in the source code.

                  Comment


                  • #29
                    Originally posted by xfcemint View Post

                    I thinky many (most?) developers, like myself, are having panic attacks
                    - have to spend time updating my old software, for no reason (was working flawless). Need to read through my old code I have forgotten years ago.
                    - some of my utils might stop working. Major pain.
                    - can't compile a single source for x86-32 target for both Linux and Windows. Need to produce 64-bit versions of everything, and to test it.

                    It's a fuckup squared!

                    I hate Canonical. I hate Canonical. I hate Canonical. I hate Canonical. I hate Canonical. I hate Canonical. I hate Canonical.
                    Idiots like you are part of the problem!

                    Everything you said just says you are the problem.

                    Comment


                    • #30
                      Originally posted by brad0 View Post
                      Idiots like you are part of the problem!
                      Everything you said just says you are the problem.
                      Thanks for the argumented and polite approach.

                      Comment

                      Working...
                      X