Announcement

Collapse
No announcement yet.

Canonical Developer Tries Running GOG Games On 64-Bit-Only Ubuntu 19.10 Setup

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

  • #81
    Originally posted by birdie View Post
    And no, flatpaks/snaps are an asinine solution because you still need 32bit OpenGL/Mesa libraries which must be kept up to date and which you cannot distribute as a part of your asinine monstrosities.
    You are wrong, mesa is a part of freedesktop's runtime. The steam Flatpak on Flathub is on the 1808 org.freedesktop.Platform runtime which means mesa 18.3. A new runtime is expected this August.

    Comment


    • #82
      Originally posted by vegabook View Post
      There's 10:1 help ration on google Ubuntu:Everything_Else. F That.
      Most solutions work on other distros as well, only very specific ones (issues with PPA's, apt, etc.) work on Ubuntu or Debian-based distros. But most generic stuff on Ubuntu sites/forums/discussions/whatever works on mast distros.

      Comment


      • #83
        Originally posted by DoMiNeLa10 View Post
        Legacy 32-bit software is mainstream as well.
        True but how we support that is big question. Does 32 bit support need to be in the main distribution install now we have snap and flatpak and docker? Maybe no it does not. And maybe no it should not be.

        I remember something else important. https://en.wikipedia.org/wiki/Year_2038_problem

        2038 clock problem effects the Linux kernel 32 bit syscall calls. To use time domains to cover this problem applications need to be on cgroups/namespaces. So in some ways getting rid of 32 bit support from the default install and forcing those programs into flatpaks or docker or snap is the correct solution.

        Also you said Legacy is normally another name for full of security faults this would be another reason to make those applications always in containers to reduce system access..

        As yet we don't know 19.10 syscall status. If the 32 bit support is only gone from userspace this is the a problem we can live with and maybe the correct way forwards.

        https://cateee.net/lkddb/web-lkddb/X...EMULATION.html and performs syscall minimisation configurations I am worried about. If Ubuntu turns those off the old VSYSCALL EMULATION that basically killed programs before 2013 and syscall minimisation would see 32 bit syscalls disappear kernel. As long as 19.10 does not do that getting 32 bit programs work for users will be just extra steps that they will have to run in something container-ed with a full runtime like snap or flatpak or docker.

        Storm meet teacup.

        Comment


        • #84
          Originally posted by oiaohm View Post

          True but how we support that is big question. Does 32 bit support need to be in the main distribution install now we have snap and flatpak and docker? Maybe no it does not. And maybe no it should not be.

          I remember something else important. https://en.wikipedia.org/wiki/Year_2038_problem

          2038 clock problem effects the Linux kernel 32 bit syscall calls. To use time domains to cover this problem applications need to be on cgroups/namespaces. So in some ways getting rid of 32 bit support from the default install and forcing those programs into flatpaks or docker or snap is the correct solution.

          Also you said Legacy is normally another name for full of security faults this would be another reason to make those applications always in containers to reduce system access..

          As yet we don't know 19.10 syscall status. If the 32 bit support is only gone from userspace this is the a problem we can live with and maybe the correct way forwards.

          https://cateee.net/lkddb/web-lkddb/X...EMULATION.html and performs syscall minimisation configurations I am worried about. If Ubuntu turns those off the old VSYSCALL EMULATION that basically killed programs before 2013 and syscall minimisation would see 32 bit syscalls disappear kernel. As long as 19.10 does not do that getting 32 bit programs work for users will be just extra steps that they will have to run in something container-ed with a full runtime like snap or flatpak or docker.

          Storm meet teacup.
          I don't think there's any need to speed up the transition to 64-bit, as everyone knows it's the future, and there is plenty of hardware that can't handle 64-bit for whatever reason (like low memory for certain windows boxes). At some point it will be normal to virtualize all of that software, because kernels will have no way to properly handle it, but that's a distant future from now. In reality, this is mostly about the hardware you're targeting when you're writing your software, rather than a bigger problem.

          Comment


          • #85
            Originally posted by birdie View Post
            You know why the whole world keeps running Windows which is full of telemetry and shat? It's because Microsoft perfectly knows what backward compatibility means. You can run most Windows 95 era 32 bit applications just fine in Windows 10 1904. With Linux it's either "progress" and or go f off. And most people stick to Windows because of that.

            Bloody idiots.
            Let me tell you one thing. This is very perfectly absolutely TRUE, and one of the biggest Linux problems. API/ABI compatibility is somewhat lacking, which means that some applications suddenly stop working due to "error while loading shared libraries" after a pacman -Syu. Backwards compatibility is paramount in operating system design, and it is hard to deny this fact.

            Comment


            • #86
              Originally posted by DoMiNeLa10 View Post
              I don't think there's any need to speed up the transition to 64-bit, as everyone knows it's the future, and there is plenty of hardware that can't handle 64-bit for whatever reason (like low memory for certain windows boxes). At some point it will be normal to virtualize all of that software, because kernels will have no way to properly handle it, but that's a distant future from now. In reality, this is mostly about the hardware you're targeting when you're writing your software, rather than a bigger problem.
              Really we do need to speed up. There are already security issues turn up from the 32 bit code stuff. OS X is getting rid of their 32 bit layer to address the 2038 problem now.

              There is no version of windows still getting all updates that is 32 bit only if you have not paid for extended support to Microsoft. Those of you using Windows 7, 8.1 and windows 10 32 bit your support from Microsoft is over unless you have paid. Windows 7 support goes completely dead at the start of 2020.

              there is plenty of hardware that can't handle 64-bit for whatever reason (like low memory for certain windows boxes).
              Problem all these machines should be disposed of. Windows they are running once you start paying the extended support to get the updates is more than getting a second hand machine that can run a 64-bit operating system.

              Worst not only can most of that hardware not run Windows 64 bit or Linux 64 bit most of the that hardware does not have the intel microcode updates to deal with the intel cpu faults. So is basically a security nightmare.

              Also intel with gcc and llvm on Linux and OS X fixed the compilers so there is no performance advantage to a 32 bit binary the 64 bit binary is always faster.

              The reality is the age over 32 bit applications is over. Anything 32 bit is technically legacy on x86. If you are making a new application today it should be 64 bit other wise you are supporting broken hardware with insecure software because of that hardware.

              Basically don't use hardware that should be in the scrap bin to say we don't need to transition to 64 bit now.

              Comment


              • #87
                Originally posted by tildearrow View Post

                Let me tell you one thing. This is very perfectly absolutely TRUE, and one of the biggest Linux problems. API/ABI compatibility is somewhat lacking, which means that some applications suddenly stop working due to "error while loading shared libraries" after a pacman -Syu. Backwards compatibility is paramount in operating system design, and it is hard to deny this fact.
                In fairness, if you plan a transition like Apple, you can bring over most or all developers to a new ISA and OS. You can also do what IBM does with the zSeries, which is basically provide backwards compatibility going back 50+ years. X86 is definitely in the later camp. People are still writing to SSE2, and x86 in general like Valve. You never do what Ubuntu has done here, which is literally just break compatibility with well maintained and regularly updating multilib libraries. You might not target X86 for a new library, but there's nothing wrong with maintaining and using what's working. It would be backwards compatibility if these libraries and Steam were not being maintained anymore.

                Multilib is as good a solution (low maintenance) as there is going to be for native x86 performance alongside amd64. It's just time to learn to love it.

                Comment


                • #88
                  As long as a sensible solution to running older 32bit games and programs is offered then I'm fine with whatever Ubuntu does. Sensible being the key word.

                  Comment


                  • #89
                    Originally posted by Melcar View Post
                    As long as a sensible solution to running older 32bit games and programs is offered then I'm fine with whatever Ubuntu does. Sensible being the key word.
                    Key word you said was older. Think about it games and other old 32 bit programs normally lost their source code and are no longer able to be updated for any security flaw that turns up. Some ways placing all these things in flatpak/snap/docker... to reduce system access for something possible security flawed and not fixable would be a good thing. I don't see any problem with 19.10 ubuntu dropping multi lib support now I have looked closer and 32 bit syscalls are still there. Just now means you need to container old applications that from a security point of view for the status of those applications is most likely the sensible thing todo.

                    Comment


                    • #90
                      Originally posted by oiaohm View Post
                      2038 clock problem
                      Clearly, you are trolling.

                      Comment

                      Working...
                      X