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

  • #31
    Originally posted by xfcemint View Post
    Most of my software is multi-platform, but switching to 64-bits changes sizes of structures.
    what is a "structure" in this context?

    because variable sizes don't change and a "structure" in c/c++ is basically a list of variables.

    Comment


    • #32
      Originally posted by xfcemint View Post

      Thanks for the argumented and polite approach.
      It's not like you are providing much in the way of argument either. You're just verbosely describing a reaction, not why you should react.

      Comment


      • #33
        Originally posted by starshipeleven View Post
        what is a "structure" in this context?
        because variable sizes don't change and a "structure" in c/c++ is basically a list of variables.
        Structure, like what you get with a struct or class keywords.

        Sizes of pointers changes, therefore size of every structure containing a pointer changes. Also, size of every virtual class changes (due to pointer to virtual table).

        Edit: Ah I forgot about x32. Would it work? Let me think...
        Last edited by xfcemint; 06-21-2019, 06:57 PM.

        Comment


        • #34
          Originally posted by starshipeleven View Post
          It's not like you are providing much in the way of argument either. You're just verbosely describing a reaction, not why you should react.
          I'm not sure that I'm following you.

          But the things I wrote about what I have to do are more like "in the case of staying on Ubuntu and supporting Ubuntu".

          Of course, I'm not going to review my old code. If Ubuntu drops 32-bit, I'm not recompiling. If my dev tools stop working, I'll switch the distro. If I miss some of my old programs, I'll switch the distro. That is a pain, as I'll have to switch on 5 PCs, but it's easier than continuing without x86-32.

          Reasons? I value my time. I think that is more than a sufficient reason.

          Comment


          • #35
            Originally posted by starshipeleven View Post
            what is a "structure" in this context?
            because variable sizes don't change and a "structure" in c/c++ is basically a list of variables.
            Ok, so I can compile for x32 on Linux and for win32 on Windows. Ok, I can do that, it's not so hard to recompile.

            So the worst problems go away. I forgot about the existance of x32.

            Still, this problem remains:
            If my dev tools stop working, I'll switch the distro.
            Last edited by xfcemint; 06-21-2019, 09:04 PM.

            Comment


            • #36
              Originally posted by xfcemint View Post
              Sizes of pointers changes, therefore size of every structure containing a pointer changes. Also, size of every virtual class changes (due to pointer to virtual table).
              And this is an issue because?
              Don't tell me you were fapping with pointers (doing shenanigans to alter the pointer address) in non-performance-critical code.

              Most of the "issues" people face when migrating to 64bit are actually bad coding.

              Comment


              • #37
                Originally posted by xfcemint View Post
                I'm not sure that I'm following you.
                you didn't argue your point much, you just said what you would have to do to avoid perceived issues.

                Comment


                • #38
                  Originally posted by xfcemint View Post

                  Structure, like what you get with a struct or class keywords.

                  Sizes of pointers changes, therefore size of every structure containing a pointer changes. Also, size of every virtual class changes (due to pointer to virtual table).

                  Edit: Ah I forgot about x32. Would it work? Let me think...
                  If you're a programmer who has to care about struct sizes for being able to compile to 64-bit then you deserve every problem that comes your way for hardcoding it rather than using the sizeof operator in your malloc or just using C++ and the new keyword (or the relevant smart point initializer). Fix your code.

                  Comment


                  • #39
                    Originally posted by starshipeleven View Post
                    And this is an issue because?
                    Don't tell me you were fapping with pointers (doing shenanigans to alter the pointer address) in non-performance-critical code.
                    Most of the "issues" people face when migrating to 64bit are actually bad coding.
                    - I can remember using fast sqrt at least once. That involves converting a float to int32. Or double to long? I forgot. So I have to check it out. Right, it's float to int32 because it wouldn't be fast otherwise.
                    - Sometimes I'm just too lazy and I write a structure directly to a file in binary mode. This could be broken by 64-bit longs or pointers.
                    - other similar issues, but I just didn't think about them in detail yet. Because I don't have to. Because the said programs are specifically intended to work on 32-bit systems.

                    Is it bad coding? Perhaps. Perhaps not. Some of those techniques save a lot of development time. Also, a lot of developers use them (like dumping a structure to the file - that would be extremely common). The end program works correctly on all 32-bit platforms = all of today's platforms of significance.

                    Wait, what about CUDA and OpenCL? If pointer sizes change, Cuda kernels will break. Another thing to verify. I have made at least 4 CUDA programs, and one OpenCL.
                    Last edited by xfcemint; 06-21-2019, 08:08 PM.

                    Comment


                    • #40
                      Originally posted by [email protected] View Post
                      32 bit have to go sometime, so the line have to be drawn sooner or later.
                      I think that we should just abandon Linux support on bare metal. It is an ancient system, with kernel written in C (Rust FTW!) and based on UNIX from 1969 (not by source code, but by philosophy). If you have to run some legacy POSIX applications, you can do this on WSL under Windows 10. In long term, everyone should switch to Windows Lite based on WCOS (Windows Core OS). Modern UWP and PWA apps are all you need! We should get rid of this POSIX crap, and the sooner the better!
                      Insane? Of course! But no more insane than what you are suggesting here.
                      Microsoft tried to sell Windows RT without Win32 support and they failed. That's why they put a lot of effort into providing support for transparent x86 emulation in Windows 10 on ARM. They know that without it they have absolutely no chance in this market.

                      Originally posted by [email protected] View Post
                      What I do not understand is the panic attack some people are having, like if on the day of Ubuntu 19.10 launch suddenly their 32 bit software will stop working, even if they do not update, Y2K stile. My point is, if you really need it, just use a stable release of some distro. For exemple, Ubuntu 18.04 will receive updates until 2028!

                      I understand that some have a need to be on the bleeding edge for a specific reason, but the rest? Is just a compunction to be there. I now because I had it until the day I realized that all the hassle didn't worth it. Now I sail on LTS releases and couldn't be more relieved.
                      Public support ends in April 2023. Date 2028 applies to paid support - ESM (Extended Security Maintenance).
                      Have you ever tried to use Linux distribution on desktop 5 years after the release? I did. And believe me, this is not a pleasant experience.
                      You know what? Just try to create package of Flatpak 1.0 for Ubuntu 14.04 LTS. It was released before the end of public support for this distribution (April 2019). What's more, Ubuntu 14.04 LTS is still supported via ESM.
                      https://github.com/flatpak/flatpak/i...ment-249844529
                      https://github.com/flatpak/flatpak/issues/956
                      Just try and then tell me if it was easy. And if you fail, at least you understand why using old Ubuntu is a bad idea.

                      Oh, and one more thing. If you think that 32-bit support is just about some legacy software, you are wrong.

                      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.

                      Comment

                      Working...
                      X