Announcement

Collapse
No announcement yet.

Ubuntu 19.10 To Drop 32-bit x86 Packages

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

  • Originally posted by the_scx View Post
    - Ubuntu is largely based on Debian, especially when it comes to basic packages.
    Ok, I think this reveals a major misunderstanding what Ubuntu is and does on top of Debian.

    Ubuntu does maintain their own complete infrastructure and does their own QA on the packages, expending considerable resources. Yes, these packages originally come from Debian. But Ubuntu is not like LMDE/Siduction/Aptosid/etc. which are basically lightly repackaged+reskinned Debian.

    Comment


    • Originally posted by the_scx View Post
      This is just a terrible idea.
      No its not as bad of idea as you are making out. Mesa/open source graphics drivers newest versions of libraries work perfectly with older versions of drivers so flatpak only need to ship 1 version of those being the current version per runtime at worst. The host can be using what ever open source graphics drivers it likes and it makes absolutely no issue because open source graphics driver also support programs using different versions of the userspace at the same time. This all comes from obeying Linux kernel policy to never break user space. Please note this policy does cover 2 programs attempting to use 2 different versions of a userspace interface library at the same time.


      The userspace driver version have to match the kernel driver version. Multiply it by every GPU vendor, including less known ones, such as VIA/S3G/Zhaoxin.
      VIA, S3G and Zhaoxin is like Mesa open source drivers. You only need the userspace new enough to support the card you have. If your kernel is running older kernel space driver the newer userspace libraries work anyhow. If 2 programs are running at the same time using two different userspace versions it works anyhow as well. Yes AMDPRO drivers are the same. So this lot is also only need to ship current version just like the open source drivers.

      Heck even the arm gpus closed stuff support using multi versions of the userspace libraries at the same time. Notice a trend yet.

      NVidia is the bastard party by self that you must use userspace libraries matching the kernel space drivers or it has major trouble. Don't even consider with Nvidia running two programs using two different versions of it userspace.

      NVidia is truly the odd vendor out on Linux native graphics support. Nvidia the only one where flatpak have to provide basically every single version of the userspace libraries to be sure that you have a userspace libraries that match the host kernel driver. Yes Nvidia is the only one I know of where the userspace and the kernel mode driver version have to match in the Linux graphics landscape. Everyone else making graphics drivers obeys the Linux rule of maintain api compatibility at the kernel boundary. It would be great if Nvidia came into line on this point.

      Please note NVidia license is also a ass. NVidia binary license allows you to install Nvidia drivers but it does not exactly allow you to copy. So legally flatpak in some countries cannot go copy the host installed NVidia libraries either so has to ship flatpaks of them. In this case with Ubuntu this is a good thing since this means Flatpak runtime are totally independent to host. As long as Ubuntu does not kill off Linux kernel 32 bit syscalls flatpak will work for 32 bit applications. Snap packages containign32 bit would die as well.

      Nvidia is not in conformance with Linux kernel policy this is why flatpak has to provide as many flatpaks for Nvidia. All the other GPU drivers I know made for Linux are made in conformance with Linux kernel policy.

      In some ways Ubuntu should just make it possible to make 32 bit snap packages using debian or flatpak runtimes as base. Lets be truthful a lot of the older 32 bit game binaries are not being updated for security faults so being sandboxed would not be a bad thing.

      Comment


      • Originally posted by chithanh View Post
        I'd say that running 32-bit proprietary applications on a desktop really is a small minority use case.
        Originally posted by the_scx View Post
        And I would say that most desktop users or at least a very significant group will come across such software.
        Originally posted by chithanh View Post
        Steam (all platforms) has 1 billion accounts, but most of them inactive or one of multiple accounts that belong to a single user. Monthly active users are at 90 million. Linux is around 1% of Steam survey respondents, so let's say 900k.
        Global installed base of PCs is 2.2 billion. Installed base of Ubuntu desktop was estimated at 40 million in 2015 (haven't found anything more recent).

        So no way that Steam users on PC or Ubuntu exceed 5%.
        You are miscalculating badly. Two reasons:

        1. Monthly active users on Steam are 90 million. That means many more have tried Steam and given up, or they don't play games at the given moment. So, the actual number of Steam users is much higher (many times higher) than the mentioned 90 million monthly active users. Therefore, it is likely that Steam usage on Ubuntu exceeds 5%, but we dont know the exact percentage.

        2. You mentioned, in the original post, "32-bit proprietary applications on a desktop". That suddenly got turned into "Steam". Steam does not distribute the the majority of "32-bit proprietary applications on a desktop".

        Comment


        • Originally posted by chithanh View Post
          When Linux was dropping modify_ldt() syscall which Wine depends on for running Win16 protected mode software on x86_64, it was Wine developers and users who objected. Precisely because running Win16 software on 64-bit Linux is still a major use case for Wine users.

          And yes, running Win16 protected mode software through emulation (as already happens for v86 mode software) or in a VM has been suggested in that very LKML thread, but such talk was quickly shut down by Linus.
          So, running win16 on Wine is a major use case there, but we should drop win32 on Wine now? Aren't you going against your own position?

          What you said just contributes to the position that backward compatibility is important, therefore Ubuntu shouldn't drop i386 libs.

          Comment


          • Originally posted by xfcemint View Post
            So, running win16 on Wine is a major use case there, but we should drop win32 on Wine now? Aren't you going against your own position?

            What you said just contributes to the position that backward compatibility is important, therefore Ubuntu shouldn't drop i386 libs.
            modify_ldt() looking at returning to qemu/vm was considered serous-ally by the wine project if the problem would not be fixed. Hangover is another wine usage developed depending on qemu. Completely out hangover should run 16 and 32 windows applications.

            v86 mode software is what wine puts out to dosbox. Wine project is not past using emulators where it suits so it keeps on working. Loss of vm86/v86 caused wine about year and a half of disruptions until dos applications windows applications called were working perfectly again. My problem with Ubuntu going 64 bit only is short notice wine project has to change. This normally needs about 2 years for a big change like this for the wine project to get everything in order.

            Comment


            • Originally posted by xfcemint View Post

              The point of the example packages given, like 'cheese', is that Ubuntu cared for the desktop users, even when their users' needs were frivolous, at least in the past. Ubuntu is not intended to be a serious server-only distribution, despite those customers' deep pockets.

              It's a rebuttal to this argument, which was lingering through:


              Ok, I can get behind that. And just to clarify, I am against this decision 100% just as you and the_scx are , couldn't just compute the logic about complaining about some desktop packages :-)

              Comment


              • Something seems really wierd here... Steve's post is mostly about dropping support for i386 (which seems OK at first glance) but it's not clear how that translates into dropping support for 32-bit userspace on x64 CPUs.

                Wondering if this is more of a typo/thinko that is getting out of control than an actual Canonical decision to drop 32-bit userspace ?
                Test signature

                Comment


                • Originally posted by bridgman View Post
                  Something seems really wierd here... Steve's post is mostly about dropping support for i386 (which seems OK at first glance) but it's not clear how that translates into dropping support for 32-bit userspace on x64 CPUs.
                  It's simple. No i386 libraries = 32-bit apps won't load.

                  Comment


                  • Originally posted by Weasel View Post
                    It's simple. No i386 libraries = 32-bit apps won't load.
                    And as long as you have a source of those libraries for the application with what ubuntu has done it does not matter. Like you snap or flatpak your need application and now it works again.

                    Comment


                    • Originally posted by xfcemint View Post
                      So, running win16 on Wine is a major use case there, but we should drop win32 on Wine now? Aren't you going against your own position?

                      What you said just contributes to the position that backward compatibility is important, therefore Ubuntu shouldn't drop i386 libs.
                      Do not put words in my mouth. Win16 is a major use case for Wine. It is not a major use case for Ubuntu or generic Linux users.

                      Originally posted by xfcemint View Post
                      You are miscalculating badly. Two reasons:

                      1. Monthly active users on Steam are 90 million. That means many more have tried Steam and given up, or they don't play games at the given moment. So, the actual number of Steam users is much higher (many times higher) than the mentioned 90 million monthly active users. Therefore, it is likely that Steam usage on Ubuntu exceeds 5%, but we dont know the exact percentage.
                      As I wrote, Steam accounts are at 1 billion now. But most of them are inactive or one of several accounts that belong to the same person.

                      If people have given up, then Steam is no longer a deciding use case for them.
                      Originally posted by xfcemint View Post
                      2. You mentioned, in the original post, "32-bit proprietary applications on a desktop". That suddenly got turned into "Steam". Steam does not distribute the the majority of "32-bit proprietary applications on a desktop".
                      There may be other users of proprietary 32-bit x86 software, sure. However, Steam and its games was mentioned as major use case for 32-bit x86 proprietary software that is in common use today and will never see an update for 64-bit. While the "never see an update" part is probably true, what we know about the actual numbers not support that dropping Steam would affect more than 5% of Ubuntu users.

                      Comment

                      Working...
                      X