Originally posted by the_scx
View Post
Announcement
Collapse
No announcement yet.
Ubuntu Developers Once Again Debate Dropping i386 Images, Then Discontinuing i386 Port
Collapse
X
-
Originally posted by calc View PostI 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.
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
-
Originally posted by Weasel View PostSo, what "old hardware inaccessibility" are we talking about here? Are you sure it's not just a red herring, really?
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.
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?
You can use them on 64-bit hardware, even a pure 32-bit userland (with 64-bit kernel).
So why is the hardware argument reiterated over and over?
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".
Maybe because we're sick of relying on the decisions of these incompetent buffoons who want to DROP STUFF THEY DON'T LIKE.
-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
-
Originally posted by Weasel View PostYeah 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?Last edited by calc; 19 February 2019, 05:05 PM.
Comment
-
Originally posted by calc View PostActually 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.
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
-
Originally posted by starshipeleven View PostAre 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?
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 PostNo no no.
That's Windows.
On Linux you are supposed to use the applications provided in the repositories, that's how most distros work.
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 Posti386 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.
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 GUIOriginally posted by starshipeleven View Post-waste RAM as you load the libraries for each application
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.
Originally posted by starshipeleven View PostCongrats. Is adding that Windows feel to Linux so much worth it for you?
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
-
Originally posted by Weasel View PostHint: 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.
Originally posted by Weasel View PostI 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.
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 PostBut 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.
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
-
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 PostUnsubstantiated nonsense.For crying out loud, libraries are MEMORY MAPPED.
Comment
-
Originally posted by calc View PostSo 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 calc View PostActually 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.
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
Comment