Announcement

Collapse
No announcement yet.

Fedora Has Deferred Its Decision On Stopping Modular/Everything i686 Repositories

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

  • #21
    Originally posted by M@GOid View Post
    As I said before, Canonical's decision to abandon 32 bit packages will encourage other big name distros to do the same, people crying about it or not.
    There is a fundamental difference between 32-bit kernel/port support (what Fedora is trying to do) and multiarch/multilib support (what Canonical had planned before Valve spoke to them). It's like saying that dropping support for X.Org session and completely dropping support for X11 (including XWayland) is the same thing.
    Almost nobody cares about 32-bit systems, at least on modern desktops and servers. But people care about 32-bit software, because of backward compatibility and compatibility with Windows.

    Comment


    • #22
      Originally posted by dungeon View Post
      Ultimately to year 2025. as even Microsoft plan EOL for Windows 10 at year 2025. you know, nothing lasts forever really
      You are wrong. Microsoft has no plans to end support for Windows 10. Support for Windows 10 1507 (Threshold 1) will ended on October 14, 2025. However, Windows 10 1809 (Redstone 5) will be supported until January 9, 2029. Moreover, the next versions are planned for the coming years, and they will be supported even longer.


      Anyway, as long as Windows has support for 32-bit software, Linux should support it as well. Currently, the whole Windows ecosystem depends on x86-32 support and there are not even plans to change it.

      Comment


      • #23
        Originally posted by wizard69 View Post
        There is the mantra and then there is the reality, frankly MS Windows sucks as far as backwards compatibility goes. I know this personally from using various apps to support automation tooling. (In this case tools made of steel, not the common definition programmers use).

        Beyond that the whole point of open source is that legacy software should never be a show stopper. If you have unsupported and less than free software to worry about then you have problems. Frankly I’m not concerned. It is the nature of software that some will get left behind! There are many reasons but the hard one is the developer kicking the bucket. So even with 32 bit software eventually the package dies without maintenance.
        Let's compare Photoshop CC 2019 (20) for Windows with GIMP 2.10 for Linux. Both were released in 2018.

        Photoshop:
        + Probably the most advanced graphics editor on the world.
        - Requires WoW64. You will never be able to install it on a pure 64-bit WINE.

        GIMP:
        - Doesn't support CMYK at all.
        - Doesn't support non-destructive editing.
        - Unable to save undo history.
        - Uses the old GTK+2 toolkit and calls it "modern".
        - Uses unsupported WebKitGTK+ with tons of bugs, and by that I mean at least 150+ known security holes.
        + There are pure 64-bit packages.

        And now you say that Photoshop is legacy software, and maybe GIMP is modern?!

        I have a better idea: we should stop the development of all Linux software that depends directly or indirectly on libc (that means literally everything in the Linux world). Lazy developers should abandon obsoleted UNIX/POSIX/SUS standard and learn how to create modern apps with UWP on the Windows platform!

        Comment


        • #24
          Originally posted by MadeUpName View Post
          If you are fine with 15 year old binaries I can't imagine why you would have a problem with a 6 month old Linux distro. I would rather see dev resources go to more important issues.
          We should immediately stop the development of all Linux distributions and switch to Windows 10! You can always use WSL2 on Windows 10 to run your legacy software. If you are fine with 30 year old POSIX binaries, I can't imagine why you would have a problem with an old Linux distro on a lightweight virtual machine.

          See also:
          Originally posted by Plagman (Pierre-Loup A. Griffais from Valve)
          To provide some background, support for 32-bit libraries is required in order to run not only the Steam client, but also the thousands of games available on Steam that only support 32-bit environments. Enabling the Steam client to run in pure 64-bit environments, while feasible, would leave the vast majority of the current Steam library inaccessible to such users without an additional compatibility layer. Ensuring that all games a user owns remain fully playable wherever possible is a core principle of Steam, and we don't believe any solution that arbitrarily splits a user's library would be acceptable.
          Originally posted by Plagman (Pierre-Loup A. Griffais from Valve)
          Steam already bundles a lot of the dependencies needed by 32-bit games, but it currently relies on some key components being available on the host system: a 32-bit glibc, ELF loader, Mesa and NVIDIA graphics driver libraries, to name a few.

          Comment


          • #25
            Originally posted by Joe Braga View Post
            Why is Distro's Communities annoying about it? Can Somebody explain me the reason why Microsoft continues offering System, System32 and SystemWOW64 for backward compatibility with 32-bit libraries and softwares that has been developed based on Win32 Library and compiled with C++ 32-bit compiler even it has dropped the avaibility of IWindows 10's 32-bit ISOs since last year?
            How many times do I have to explain it?

            Originally posted by WINE
            When Windows began targeting 64-bit architectures, Microsoft decided to include a compatibility layer to support their massive universe of 32-bit applications. This kind of subcomponent, nicknamed WoW64 (for Windows on Windows 64-bit), is also implemented in Wine to solve the exact same problem.
            64-bit Wine built without 32-bit support will not be able to run ANY 32-bit applications, which most Windows binaries are. Even many 64-bit programs still include 32-bit components!
            Originally posted by dmitry (Dmitry Timoshkov from baikal.ru)
            Many 64-bit applications still use either a 32-bit installer or some 32-bit components. In comparison 64-bit Windows will support 32-bit (probably) forever.
            Originally posted by vincent (Vincent Povirk from CodeWeavers)
            Make that almost all applications. It's very unusual for a program to have a 64-bit installer, because it won't be able to control what happens when a user runs the installer on 32-bit Windows.

            In practice, the only cases where 64-bit only wine will be useful are when 64-bit applications are packaged some other way (such as a .zip, Steam Play, or packaging specifically for Wine) or for running Wine builtins like msidb.
            Originally posted by vincent (Vincent Povirk from CodeWeavers)
            Nor do I see much point in packaging a 64-bit-only Wine on our end. It's such a niche case for 64-bit-only Wine to be useful at all.
            See also:

            Comment


            • #26
              @the_scx
              Hey dude, relax:



              Comment


              • #27
                Originally posted by Joe Braga View Post
                Why is Distro's Communities annoying about it? Can Somebody explain me the reason why Microsoft continues offering System, System32 and SystemWOW64 for backward compatibility with 32-bit libraries and softwares that has been developed based on Win32 Library and compiled with C++ 32-bit compiler even it has dropped the avaibility of IWindows 10's 32-bit ISOs since last year?
                In opensource world, most if not all applications have been migrated to 64bit years ago, installation and use of older binaries is not a thing and it's usually annoying because they rely on system libraries that don't exist anymore or were updated, sometimes in non-retro-compatible ways.

                The only users of multilib in all Linux distros are binary-only applications. Steam and older games, Wine and Windows applications, old drivers for old printers, whatever.
                Non-critical at best, and in most cases it's probably better if they bundle their own 32bit libraries themselves.

                How is it, Multilib coulbe be deprecated?
                Yes. Canonical has already started the process for their own distro, Ubuntu.

                Projects like Flatpak and Snap can already allow older applications to run with a static (in the sense of no more updated) set of 32bit libraries.

                Comment


                • #28
                  Originally posted by the_scx View Post
                  Anyway, as long as Windows has support for 32-bit software, Linux should support it as well. Currently, the whole Windows ecosystem depends on x86-32 support and there are not even plans to change it.
                  Why would Linux need to care about old crap Windows applications.

                  Comment


                  • #29
                    Originally posted by the_scx View Post
                    Photoshop:

                    GIMP:
                    I'm quite frankly sick of these comparisons. The amount of people that actually NEED Photoshop-only features can be counted on a couple hands.

                    The only reason everyone uses Photoshop is because it's trivial to crack and has always been (on purpose, imho), but there are tons of graphic artists using Krita or other non-Adobe software and they are fine.

                    Comment


                    • #30
                      Originally posted by starshipeleven View Post
                      Why would Linux need to care about old crap Windows applications.
                      Because they probably run far better under Wine then Windows 10. We should promote Linux's superior retro Windows support.

                      Comment

                      Working...
                      X