i386 in Ubuntu won't die
popey.com
popey.com
For example, with ebuild (or dpkg-repack or rpmrebuild) a person could build the compiler packages with all of the appropriate optimization flags for the chipset on the box where the package will be installed: https://packages.gentoo.org/useflags/custom-cflags
Cross-compilation is easier with clean build containers.
With distrobox (and qemu, qemu-user-static, and binfmt-support) https://github.com/89luca89/distrobox/blob/main/docs/useful_... :
$ uname -m
x86_64
$ distrobox create -i aarch64/fedora -n fedora-arm64
$ distrobox enter fedora-arm64
user@fedora-arm64:$ uname -m
aarch64Conflating i686 vs i386 with SIMD vs no SIMD is wrong. The Pentium Pro was an i686 processor with no SIMD, and the Pentium 2 was its successor that added MMX — a very narrowly-useful integer-only SIMD extension (which was first introduced on the pre-i686 Pentium MMX). Floating point SIMD (SSE) didn't show up until the Pentium 3 (on the Intel side; AMD's 3DNow was earlier but was eventually dropped).
It's certainly reasonable to enable SSE and SSE2 when building for 32-bit x86 these days, but calling that target "i686" doesn't accurately describe the hardware requirements.
I feel like "i586" and "i686" are sort of a hairball logistically. I can recall a friend in the late 1990s whose forum signature boasted having a "686" overclocked to 262MHz-- an AMD K6. While we sort of understand i586 to mean Pentium, and i686 to be PPro/PII/PIII and beyond, you can make cases for the non-Intel Pentium-class CPUs to be anywhere from i386 (NexGen Nx586-- where's the FPU),to i686 (something like a K6-IiI+ is clearly more advanced than, say, the original i586 Pentium 60, although not necessarily matching PPro additions one-for-one)
Going completely on a further tangent, it feels like we stopped awarding architecture tiers like that. There were definitely new instructions in some of the later-generation parts, why didn't the Pentium III with SSE, for example, become an 'i786' tier? Why is there only one 'amd64'? Guessing the overall strategy is that modern code feature-detects and compilers build a binary with multiple code paths-- something that will run grudgingly on a Pentium Pro or original Socket 940 Opteron, but will pick more efficient code paths on a more recent CPU. Although, wasn't that sort of the promise of things like Gentoo-- by building things yourself, you could make a hyper-lean system knowing it only needed to run on the exact hardware you had? I'd expect a marginal performance uptick, just because you'd be avoiding checks and branches related to feature selection and smaller binary sizes, but it doesn't seem like there's a clear consensus it carries its weight.
i386 intel's 386 architecture
ia64 intel's 64 bit architecture(aka the itanium)
amd64 amd's 64 bit architecture(aka the 64 bit extensions to i386 aka x86-64 aka x64)https://github.com/guillemj/dpkg/blob/6a03732ab0e917272a9fe1...
At least in gcc i686 is Pentium Pro, not Pentium II or MMX. It is important distinction as it lacks MMX extensions
But userspace is not the kernel, and a lot of userspace code requires newer CPUs, for good reason.
SSE2 is the endorsed floating point architecture for x86_64, although the 8087 extensions remain present.
It is reasonable to assert that i386 is an insufficient designation to describe these capabilities.
Funny to mention Wine specifically; they're implementing a more sophisticated Wine-on-Wine64 setup that, among other things, will make having 32-bit system libs unnecessary, through the power of Heaven's Gate, not unlike how Windows handles syscalls in real WoW64.
(As far as I understand it, Linux, having a stable syscall interface, just supports the old software interrupts for 32-bit syscalls, making this unnecessary. In fact, they seem to even work from a 64-bit process to some degree.)
WoW64 literally has an entire 32-bit equivalent to Windows's native 64-bit libraries and binaries.
I'm talking about just syscalls. Windows differs from Linux in that Windows doesn't have backwards compatibility for the kernel ABI but the userspace ABI; all of the syscalls HAVE to be dispatched by NTDLL, because the syscall numbers are not stable between kernel versions anyway. (Not that this entirely stops crapware like anti-cheat from doing so, but nonetheless.)
From my point of view, the closest Wine equivalent of a "syscall" would be calling out to UNIX system libraries, so it does bear some similarities even if it's not quite the same.
I don't personally want to open WOW64 NTDLL in IDA because doing so would probably limit me from contributing to Wine, but my understanding is that WOW64 NTDLL is just thunks to Win64 NTDLL, using an intermediate library (one of the wow64*.dlls presumably?) to perform a Heaven's Gate call into the 64-bit NTDLL.
From my research the situation is a bit murkier in that even 64-bit wine seems to require 32-bit components for some reason but that may be a basic packaging issue and the real blocker.
Do you have any supporting links I can read for your claims? I haven’t been able to find anything.
On Windows the syscall interface was, I believe, at int 2Eh. It should still work for backwards compatibility reasons, but WOW64 does not rely on it (and presumably, it is one of those things that Microsoft could take away at any time, just like how syscall numbers change and the PEB/TEB structures move around). Exactly what happens for WOW64 syscalls, I'm not sure, because I don't really want to look at disassembly listings for Windows DLLs, so unfortunately my understanding is limited to what things I know from reading books and Raymond Chen. It is quite likely I have some of the details a bit off, no question about that.
64-bit Wine does not require 32-bit components, but traditionally to make a WOW64 Wine build, you need to do a special build process that involves building Wine twice. This is likely where things get murky in terms of packaging, because you can still separate out the two builds of Wine. As far as I know, WOW64 in future versions of Wine will not work this way and shouldn't need 32-bit packages at all.
Unfortunately though I really don't know of a good source regarding the situation and history of it. I am pretty darn sure I saw this discussed on the Wine mailing list before, though.
Correct, with the “new”/32-bit-code-in-64-bit-process Wow64, there’s an option you pass to ./configure to specify what archs to build the PE DLLs for (i386 and x86_64 for this case)
Clarification: you could actually have Wow64 do IPC to 64-but wine to get rid of the need for a 32-bit wine, but I suspect there’s too much overhead for that, especially since WoW64 would still need to be in 32-bit.
As I understand it, the way that AMD64/EM64T processors actually evolved, rather than having completely separate "modes" for real mode/protected mode/long mode, instead, internally, the processors are more-or-less just masking features on and off. So jumping from 32-bit to 64-bit code isn't actually impossible, in fact it's obviously necessary for 32-bit code to be able to make syscalls in the first place, but what might not be clear is that at least on AMD64, you can do this jump purely in usermode, too.
The funny abilities of x86 processors even allow you to mix and match a bit with the different modes; For example, the old Linux x32 ABI[1], or Unreal Mode[2], not to mention the fact that older protected mode OSes (like Win9x) would often thunk to real mode for legacy drivers.
I don’t think there’s much of a performance effect, if anything it should be faster since all the Unix code running is 64-bit (and x86_64 has more registers, newer ISA extensions). You also don’t have to worry about Unix libraries eating up precious 32-bit address space.
The only current downside is OpenGL/Vulkan calls that return (64-bit) pointers to memory, those buffers need to be copied to 32-bit before being returned to the application. A Vulkan extension is in the works for that.
An obvious problem is the fact that 32bit applications will use 32bit addressing modes which are illegal when the processor is running in 64-bit mode.
Wow64 is just a support library to make 32bit apps run in a 64-bit OS, but that library itself is 32-bit.
If you have any supporting evidence to the contrary I’d love to read it because it’ll blow up my conception of how multi arch works on 64-bit.
Note that the concept of a process is irrelevant: processes don't exist to Intel processors. There was a concept called a "task" early on in I believe the 286 line, but nowadays all OSes just set up a single task segment on the CPU and do all of the context switching via other means, because it simply wound up being faster anyway. The processor just has tons of registers that you can flip around, and being able to switch between protected mode and long mode is a property of the code segment currently being executed (IIRC) which is something you can jump between in usermode using a far call. (And this is, as far as I know, just about the only way in which x86 segments remain relevant today.)
Thanks for correcting me!
[1] https://stackoverflow.com/questions/24113729/switch-from-32b...
But that's very windows specific, I think the general term is jumping between long mode and protected mode?
It works by setting a LDT with a 32-bit code segment and then doing a far/long cross-segment jump to the 32-bit segment. 32-bit code runs, and it jumps back to the 64-bit segment for Nt* “syscalls”, Unix lib calls, and signals.
I wonder though, whether with GeForce (etc), streaming games from the cloud, the local OS becomes even less important after all. Even a MacBook could be a decent gaming laptop (the hardware is already a superb gaming laptop, just apple keeps the software crippled).
Many of them would go back to Windows. Others would move to another Linux distro. Either way, Ubuntu would make a lot of people mad.
The steam console runs Linux. Android runs a Linux.
(That's the case for Android at least; I'm not sure about the Steam Deck.)
Android could swap out Linux for some other kernel (e.g. Fuchsia) relatively easily and users wouldn't notice. Google already did that with the Nest Hub.
AFAIK, the Steam Deck is a traditional Linux desktop (KDE), which automatically runs the Steam launcher (in full-screen Big Picture mode) by default (but you can easily exit it and go back to the normal desktop if you want).
It is simpler for when you have minimal hardware, but phones are no longer minimal.
The Steam Deck is a device serving a few million in a market of billions. The Switch outsold the Deck ten to one, with the Switch being an old console and the Deck in its release year.
Even with Steam Deck included in the survey, about 2% of Steam users (which is a subset of the gaming market) use Linux.
Ubuntu avoids Flatpak for strategic reasons, which is a valid choice that might make sense for developers, but it also makes Ubuntu less easy-to-use for people who just want to use their computer.
Is flatpack still Desktop focused , depends on desktop session or changed recently?
It this still holds true then your claim is bullshit, snap is a more powerful tool because I could setup CLI programs on a server without a desktop session.
From flatpack FAQ I still see
>Flatpak is designed to run inside a desktop session and relies on certain session services, such as a D-Bus session bus and, optionally, a systemd --user instance. This makes Flatpak not a good match for a server.
I suppose Ubuntu could stop packaging these files if they distributed all 32 bit software over snap or Flatpak, but I don't think this solves as many problems as removing x86 multiarch would create.
(Threads on x86-64 Linux can freely switch between 32-bit and 64-bit mode.)
It'll happen eventually, but I think we've still got a few years of multiarch ahead of us.
There is some serious aversion to providing users what they want in the Linux world.
Plus 32 bit software can still run if it's stacically linked or run inside a container. The only thing that doens't ship is the dynamic libraries for 32 bit executables to run.
It does get installed if you want to play games on Linux, though because computer games will require 32 bit libraries for many years to come.
I think probably the right way to handle 32-bit compat is well-integrated virtualization ala Classic Mode from OS X’s early days. When the user tries to run a 32-bit binary, boot up a minimal old copy of the host OS and run it there. It’s not as nice as running it directly, but I think that’s fine; it gently pushes devs to bring their antiquated software into the modern era while allowing users to continue to run it and keeps OS development unshackled from the past.
Twice as many packages run under Linux than under MacOS, specifically because of the lack of 32 bit support.
I know of very few actively-maintained 32-bit Mac applications that didn’t make it to 64-bit: MathType and AccountEdge are the ones I remember right now.
Linux throwing backwards compatibility and stability out the window is one of the biggest reasons it doesn't appeal to the common user. Note that Android provides this (granted less than Windows does), and we see common people use Android.
And before you mention it: Yes, I know Linus Torvalds is (sort of) adamant about backwards compatibility; the problem is the rest of Linux does not and will not care.
The Linux kernel itself is in fact very, VERY extensively backwards-compatible, which is why I find it particularly unfair (on top of being wrong) to use the label Dalewyn did. It's the installed userspace libraries that aren't - at least not in all cases, but the situation sure has improved a lot over the last decade or so.
Did I ever dispute that?
It's still not as bad as desktop Linux (e.g. some Loki games cannot even be loaded due to breaking changes in _glibc_ out of all libraries), but it is still bad enough to qualify as abysmal.
AFAIK, they don't need to be from the host, they only need to be compatible with the host hardware and the host kernel (and the kernel ABI stability rules makes this easier). For instance, when running the Steam flatpak, these libraries come from the freedesktop runtime, not from the host.
Not to mention, flatpak would still add nothing. Just additional annoyances.
From a technical perspective, steam was originally basically just a chroot-style environment that let you have an independent set of DLLs installed for each windows game on your machine.
Before that, I averaged four hours of fucking around with directx diagnostic bullshit whenever I bought a new AAA title for windows (and getting the new game to work usually broke some old games)
These days, Steam’s Linux support for Windows games is better than native Windows support ever was.
Currently, they require a fairly small base set of 32 bit Linux libraries with a relatively stable ABI. That lets them abstract away all the other crap on your Linux desktop.
Imho, the least they can do is get the basics right. Of course, it's Canonical's fault for pushing something that is not ready for the real world.
DISPLAY="$DISPLAY" gimp DISPLAY="$DISPLAY" gimp
Nor does Wayland, which is the default in Ubuntu now.
VNC or something similar might be a better choice
I use VNC all the time, but sometimes it is just more convenient to use a remote X connection.
As a comparison, windows remote desktop on the same network was pretty snappy at the time.
There are only a few things keeping me on Linux: Steam, Slack and Zoom. I haven’t checked for BSD support for any of that recently, but Slack used to(?) run better in the browser than in their app.
Edit: Also native docker, does that still have to live in a vm, windows/mac style?
After multiple years it’s still an intel binary on Mac, despite being a chrome wrapper and the Mac games in the catalogue all being native binaries at this point.
I would assume if not for the 64bit transition it would still be i386 on Mac as well.
RISC-V is inevitable.