Announcement

Collapse
No announcement yet.

Ubuntu Developers Once Again Debate Dropping i386 Images, Then Discontinuing i386 Port

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

  • #41
    Originally posted by the_scx View Post
    TL;DR To run 32-bit Windows application under WINE, you need a 32-bit version of WINE (pure 32-bit WINE or mixed 32-/64-bit with enabled WoW64 support), which in turn requires 32-bit version of essential libraries in the system.
    IMHO, today pure 64-bit OS is practically useless on desktop.
    I suspect you would be surprised by how few people actually use WINE, or any other 32bit libraries, under Linux. I haven't had a need to have any multiarch packages installed in years.

    Comment


    • #42
      Originally posted by calc View Post
      I suspect you would be surprised by how few people actually use WINE, or any other 32bit libraries, under Linux. I haven't had a need to have any multiarch packages installed in years.
      Yeah and nobody cares about your anecdotal evidence.

      I use Wine for almost everything and my opinion is simply greater than your opinion.

      Thus I can conclude, "you would be surprised how many people actually use WINE, or any other 32bit libraries, under Linux", right?

      Comment


      • #43
        Originally posted by Weasel View Post
        So, what "old hardware inaccessibility" are we talking about here? Are you sure it's not just a red herring, really?
        Are you sure you are not the one making a red herring right here?

        What if he actually meant that they don't feel like having packages that a very limited minority of their userbase will actually use? Because that's the most likely meaning for "inaccessibility of old hardware". Why the fuck would someone want to run linux software that in Ubuntu is already available in 64bit in an inferior architecture if they can avoid it?

        I don't need to mention that 32-bit LIBRARIES should **ALWAYS** be available, so that one can use the 32-bit applications one already has.
        No no no.
        That's Windows.

        On Linux you are supposed to use the applications provided in the repositories, that's how most distros work. And since all 32bit applications in the repos are also 64bit, there is no point in supporting the 3 entities worldwide that compile their own 32bit application statically for some reason.

        I want to install 32-bit userland in LXC, using my 64-bit kernel. It works, so why take it away from me?
        Oh my god, they gave me something for free, and now they want to take it back, how bad of them to not keep giving me what I want for free.

        You can use them on 64-bit hardware, even a pure 32-bit userland (with 64-bit kernel).
        i386 packages are compiled for an architecture that won't make them use most of the modern CPU features, which makes them significantly less attractive for server use, which in turn is like 99% of the money they make.

        So why is the hardware argument reiterated over and over?
        Because that's the only valid reason to still have 32bit.
        The other reasons are
        -to use the distro wrong (i.e. install statically linked 32bit binaries because you think this is Windows),
        -to run proprietary applications that can and should be dealt with in a better way separately.

        And then people wonder why everyone loves static linking "bloat".
        I never seen statically linked applications worth a shit for Linux, where is all this mob with pitchforks you are talking about?

        Maybe because we're sick of relying on the decisions of these incompetent buffoons who want to DROP STUFF THEY DON'T LIKE.
        And by statically linking shit you manage to:
        -waste a ton of time as it is a PITA for anything that has a GUI
        -waste RAM as you load the libraries for each application
        -run applications that don't use anything resembling a modern CPU instruction so it performance is inferior to 64bit binaries.

        Congrats. Is adding that Windows feel to Linux so much worth it for you?

        Comment


        • #44
          Originally posted by Weasel View Post
          Yeah and nobody cares about your anecdotal evidence.

          I use Wine for almost everything and my opinion is simply greater than your opinion.

          Thus I can conclude, "you would be surprised how many people actually use WINE, or any other 32bit libraries, under Linux", right?
          Actually you would likely be in the minority as you appear by your own admission to only use Linux as a shell in which to launch Windows applications.
          Last edited by calc; 19 February 2019, 05:05 PM.

          Comment


          • #45
            Originally posted by calc View Post
            Actually you would likely be in the minority as you appear by your own admission to only use Linux as a shell in which to launch Windows applications.
            And who said it's not how majority of Linux users use their OS?

            You also use Linux as a shell in which to launch GTK/QT/whatever applications. Really what's the fucking difference? GTK/QT are not part of Linux any more than Wine is.

            Obviously terminal-only apps that exclusively use syscalls or low level libraries like libc are totally fine and I use them, too. I just don't want to mess with the instability clusterfuck that is the vast majority of the Linux userland. The Linux OS/kernel is great and I respect it, which is why I use it. The userland and platform sucks.

            Comment


            • #46
              Originally posted by starshipeleven View Post
              Are you sure you are not the one making a red herring right here?

              What if he actually meant that they don't feel like having packages that a very limited minority of their userbase will actually use? Because that's the most likely meaning for "inaccessibility of old hardware". Why the fuck would someone want to run linux software that in Ubuntu is already available in 64bit in an inferior architecture if they can avoid it?
              The majority of a minority is still a minority. That's the problem. They should care about the potential amount of users that don't use Linux yet, and don't do so for such reasons.

              Those are far more important than the current puppets using them, which basically tell them "look, I don't care how much you shit on me, I'll still use your distro" and thus provide zero value, they will use anything anyway.

              Originally posted by starshipeleven View Post
              No no no.
              That's Windows.

              On Linux you are supposed to use the applications provided in the repositories, that's how most distros work.
              Actually no, since even Torvalds complains about distros being retarded like that. Don't make me link that video again.

              See calc this is exactly why I "run windows apps" on Linux.

              Because Linux, to me, is the kernel (as its name is) not some piece of shit distro that treats its users like mobile muppets.

              Originally posted by starshipeleven View Post
              i386 packages are compiled for an architecture that won't make them use most of the modern CPU features, which makes them significantly less attractive for server use, which in turn is like 99% of the money they make.
              And nobody gives a shit.

              You must be one of those who gets shat on by bad company practice and doesn't complain about it, "because they make money". Yeah, cause you care about the wellbeing of them instead of yourself, or other users.

              Originally posted by starshipeleven View Post
              -waste a ton of time as it is a PITA for anything that has a GUI
              Unsubstantiated nonsense.
              Originally posted by starshipeleven View Post
              -waste RAM as you load the libraries for each application
              For crying out loud, libraries are MEMORY MAPPED. And even if they did waste more RAM (relocations perhaps), pointers are smaller, and that is important because cache is much more limited than RAM is.

              Originally posted by starshipeleven View Post
              -run applications that don't use anything resembling a modern CPU instruction so it performance is inferior to 64bit binaries.
              But it has better cache usage so can be faster in many cases. Most code out there isn't using modern CPU instructions anyway. And even if it is, the 32-bit version also uses them.

              Originally posted by starshipeleven View Post
              Congrats. Is adding that Windows feel to Linux so much worth it for you?
              Definitely, much better than some mobile circus environment. Well it's not like you will ever understand since you are too clouded into the "click to centralized crap store, download app, tap some buttons" instead of archiving your workflow.

              Software is data just like anything else.

              You're probably one of those who also finds no problems with streaming sites and "listens to music" on Youtube instead of archiving them personally and locally.
              Last edited by Weasel; 20 February 2019, 12:14 PM.

              Comment


              • #47
                Originally posted by Weasel View Post
                Hint: x86_64 hardware can perfectly run 32-bit code, including the kernel. 64-bit kernel can perfectly function with 32-bit userland. Heck, there are VIRTUAL MACHINES and CONTAINERS that can run 32-bit code at full speed.
                Unfortunately this is not true. 32 bit Linux has the 2038 problem. So Linux 64 bit kernel with 32 bit userland has a problem. What you said about virtual machines could be the long term answer.


                Originally posted by Weasel View Post
                I don't need to mention that 32-bit LIBRARIES should **ALWAYS** be available, so that one can use the 32-bit applications one already has. The kernel supports it, this is one reason people love static linking in Linux, because of distro devs.
                Clean install of 64 bit debian and ubuntu does not install any 32 bit userland libraries by default, Yes over 90+% of the Linux usage cases has no use for 32 bit libraries at all. This also brings problem if we can get rid of the under 10 percent using 32 bit user land we can drop the 32 bit syscalls out the kernel.

                Wine has been one of the major requiring parts of i386 runtime and syscalls. If the project hangover works out this may cease to be the case,.

                Does the ability to run 32 bit applications mean you have to have stack of 32 bit libraries? The answer gets interesting if hangover works the answer is no it not required instead make a small wrapper that thunks to the 64 bit version.

                Yes if I was Ubuntu or Debian I would be talking about dropping i386/32 bit userspace to have developers in the minority with 32 bit stuff look at migrating it.

                Of course with hangover method and other methods there may be no point to keep a 32 bit userspace provided by distribution. Yes 32 bit userspace could be something you have to use snap or flatpak to have to provide more pressure to stop using 32 bit.


                Originally posted by Weasel View Post
                But it has better cache usage so can be faster in many cases. Most code out there isn't using modern CPU instructions anyway. And even if it is, the 32-bit version also uses them.
                This is we are on Linux you are thinking windows. The best cache and memory is in fact x32-86. This is 32 bit in 64 bit protected mode. There is extra overhead switching from 64 bit ring 0 to 32 bit ring 0 compare 64 bit ring 0 to 64 bit ring 3 as well. So this has performance gains even if you don't use extra registers x32-86 provides.

                Do note I did not include best cpu usage. The Linux kernel wrappers converting 32 bit address space to 64 and back that the kernel has todo for 32 bit modes do come at a extra cpu price so the best cpu usage is pure 64 bit.

                Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite


                Weasel above is the real killer. Yes the last phoronix benchmarks of Linux 32 bit userspace vs 64 bit userspace. The claim of better cache usage advantages only make a handful of programs minor-ally faster. Building everything 64 bit gives way more advantages. The extra register count of 64 bit modes like x32-64 or pure 64 bit Linux give bigger performance boost than the cache and memory costs of 64 bit over 32 bit.

                Don't forget the fastest form of ram in you system is the registers so not using those comes at a very high cost of performing more cache operations that are way slower when value could have been stored in register.

                Performance is a reason to want to drop the 32 bit runtime off a cliff never to be used again. Legacy applications that are 32 bit are the hold outs. Wine could remove it blockade to it. That would leave valve and the other game providers to work out their solution for old applications.

                Comment


                • #48
                  Originally posted by Weasel View Post
                  See calc this is exactly why I "run windows apps" on Linux.
                  So you like uninspected Windows malware, got it.

                  One of the big points for Linux dists being packaged is that the code is inspected and self built.

                  Of course you still have problems like ppas/coprs/aur/etc in which anyone can upload to with little oversight. But users are warned of those issues.

                  Originally posted by Weasel View Post
                  Unsubstantiated nonsense.For crying out loud, libraries are MEMORY MAPPED.
                  Actually the Windows way of doing things even with libraries being memory mapped uses much more memory than is typical for Linux. It is one of the big reasons Windows is considered bloated compared to Linux. Under Windows every revision of every library that ever existed still exists for binary compatibility. Several different programs on the same system can easily and very often do run different versions of the same libraries, eating gobs of ram. On Linux the dists generally do a mass rebuild and switch to the newest library with each new release. This is being changed to some extent with flatpak/snaps having multiple versions of runtime, along with their lower quality code inspection mentioned above is going to bring Windows level of system "quality" to Linux, ugh.

                  Comment


                  • #49
                    Originally posted by calc View Post
                    So you like uninspected Windows malware, got it.

                    One of the big points for Linux dists being packaged is that the code is inspected and self built.

                    Of course you still have problems like ppas/coprs/aur/etc in which anyone can upload to with little oversight. But users are warned of those issues.
                    The developer of an app that you use is much more trustworthy than some random maintainer who "inspects" it. The one who loves malware and being ignorantly exploited here is you. Not to mention that everyone who thinks installing from say apt is "safe" (even with the bug recently fixed) is much more at risk than someone who scans and tests popular apps.

                    Originally posted by calc View Post
                    Actually the Windows way of doing things even with libraries being memory mapped uses much more memory than is typical for Linux. It is one of the big reasons Windows is considered bloated compared to Linux. Under Windows every revision of every library that ever existed still exists for binary compatibility. Several different programs on the same system can easily and very often do run different versions of the same libraries, eating gobs of ram. On Linux the dists generally do a mass rebuild and switch to the newest library with each new release. This is being changed to some extent with flatpak/snaps having multiple versions of runtime, along with their lower quality code inspection mentioned above is going to bring Windows level of system "quality" to Linux, ugh.
                    I have no idea what you are even talking about at this point. What has different versions to do with memory mapping at all?!?

                    And I personally don't give a shit what people "consider bloated" seeing as GNOME is just as bloated as Windows but open source zealots praise it. People's opinions are generally completely insignificant to me because they are usually wrong (and by wrong, I mean factually wrong, I do NOT believe in the "every opinion has some truth it in, in its own way" childish nonsense spread by the extreme left).


                    Now, in case you still don't get it: memory maps that have backing storage on disk (i.e. you memory map a file from disk) eat exactly zero memory unless they use "copy on write" (this isn't the case since the code is read-only). ZERO. The access to the disk is cached, sure, so it does eat up the cache to make it faster.

                    I mean it just is basics. What memory is there to use? Used memory means memory that cannot be discarded, memory that has to be swapped (written) to disk if the kernel feels like it won't be used. Why would you write memory that you haven't modified and you know exactly where to find it on disk already (the library itself)? The kernel isn't that stupid.

                    Comment

                    Working...
                    X