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

[dungeon]

Debian will not drop anything 32-bit in the foreseeable future. Debian **still** supports m68k.

Yes, Debian supports m68k, but unofficially . So called Debian Ports have Unofficial or In Progress status really or to say it is something just community supported and unofficial. Debian officially only supports release architectures, which for Debian 9 currently are half 32bit and half 64bit

https://www.debian.org/ports/

It depends greatly on upstream support and then also on availbility of active porters. Obsolete survival rate there depends on porting efforts, fighting and probably luck

Statuses could be - Unsupported, Unofficial, In progress or Supported. There is a difference on these statuses and only what is really supported is what is officialy supported. Release architectures have official Supported status, but Ports are only Unofficial or In Progress.

How time goes more and more of these remaining 32bit arches would lose official Supported status For Debian i guess, in about maybe 5-10 years timeframe all 32bit arches would lose official Supported status and so on

Just mine definition of "foreseeable future", now of course if feasible various things might be possible but again unofficially.

[calc]

According to Ubuntu's popcon, there are 2071481 i386 installations and 685534 amd64 installations.

So, there are three as many times i386 installations than amd64 installations. So, good luck dropping the i386 port.

> https://popcon.ubuntu.com/

I'm surprised that many show up since it disabled by default.

[the_scx]

they want to move to x64 only binary

Who? WINE devs? Not at all! They recommend something completely opposite!

https://forum.winehq.org/viewtopic.php?p=104523&sid=466b0f944d1bf4a2413567e0f79e9f1f#p104523

"As for the Bad EXE error, it appears you are trying to run a 32 bit app with pure 64 bit Wine. That won't work."

https://www.centos.org/forums/viewtopic.php?p=206830#p206830

"The CentOS/RHEL Wine packages are broken by design. Pure 64 bit Wine is not a supported configuration."

https://wiki.winehq.org/Building_Wine#Shared_WoW64

"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!"

I can't see the point of using 32 bits in future

Trust me, for the end user it is easier and better to use pure 32-bit version of WINE (or 32-bit Windows or even Windows 10 on ARM with built-in x86-32 emulation) than use pure 64-bit version of WINE. Even today, most applications designed for Windows are still 32-bit or depend on 32-bit components. Want to run install 64-bit office app? You need to run the 32-bit installer first! Want to run 64-bit game? You need to run the 32-bit Steam client! It happens that the game contained in the 64-bit depot is in fact a 32-bit application.

my default wine install is 64 bits for long time and I can't notice any difference

You will see if you try running 32-bit software under PURE 64-bit version of WINE:

wine: Bad EXE format for <FILENAME>

To build a 32-bit version of WINE, you need the 32-bit chroot environment. To run a 32-bit Windows game (EXE PE32), you need the 32-bit version of WINE, which in turn requires 32-bit libraries, e.g. OpenGL (mesa-libGL, nvidia-x11-drv-32bit, etc.) and OpenAL libs, as well as i686 libc library of course.
To better imagine, let's look at EL (RHEL and its clones, such as CentOS, SL, OL, etc.). The WINE packages from EL7 main repo are broken by design. Pure 64-bit WINE is not a supported configuration. Of course you can install 32-bit version of WINE from somewhere (e.g. PlayOnLinux or custom i686 RPM package) or even try building 32-bit WINE yourself, but then you will face further difficulties. As it happens, EL does not provide all the necessary dependencies for 32-bit version of WINE. In particular, the openal-soft and nss-mdns are missing, so you have to build them on your own. Keep in mind that EL7 did not abandon 32-bit software completely, but only limited its use. It means it can be much worse. If Ubuntu goes this way, users won't be pleased.

https://wiki.winehq.org/CentOS/RHEL#For_Release_7

The EL example shows one more problem. To build 32-bit applications you actually need a 32-bit system in chroot - vide: mock config for i686 and 32-bit base system (repos for i686 arch), such as CentOS altarch-i686.

http://pastebin.centos.org/757466/

Please keep in mind that you need a lot of tools and libraries to build complex software. Just GCC/LLVM Toolchain, Boost, ICU, and a few other libs are usually not enough.

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.

[Vistaus]

Wine already support 64-bit applications, at least partially. However, the largest part of the Windows software catalog is 32-bit.

That was not my question.

[mulenmar]

It would be great if Valve would finally provide a 64bit build of Steam. This is overdue.

It'll be out shortly after Half-Life 3, with the full, developer-tools-included version of the Source 2 engine.

In other words: sometime after Sol balloons out past Mercury's orbit.

[Ardje]

The large majority of commercial games is 32-bit. You can't just kill 32-bit support.

The same applies to WINE. If you kill of 32-bit WINE, 90% of Windows applications will stop working.

I remember when Windows NT was available for the Dec Alpha processor. They even had big alpha based servers. And in the end, at least 50% of windows was run in an i386 emulator. So those expensive servers were also not the fastest running WIndows NT.
Even in that time, 16 bit was still a major thing which they called Windows-On-Windows, which is still preset in 64 bits windows, but for 32 in 64 bits.
It will take some time.
And I wouldn't really care about ubuntu for intel anyway. Ubuntu for arm is important though, as ubuntu is the only debian derived distribution that really has an up to date gstreamer.

[Ardje]

Even among servers and NASes, nobody is running a modern version of Linux on hardware that is only 32-bit. Furthermore, 32-bit ARM is not the same thing as 32-bit x86, so that can't be compared.

So pretty much everyone who matters witch such a decision is running x86-64 or something else.

You miss my point. i386^H^H^H586 hardware without amd64 mode is still being sold (and made actually).
And yes, I am running modern versions of linux. And I am not the one deciding, it usually is a customer that wants a solution with the hardware he already has.
If it were up to me, it would never be intel arch, and if it has to be: 64 bits as generic pc as possible. No industrial, no special, as that usually craps on you somehow.
I'd rather stick to a single ARM SoC for a few years.

[schmidtbag]

You miss my point. i386^H^H^H586 hardware without amd64 mode is still being sold (and made actually).

I'm aware; it really shouldn't be. To my recollection, the last 32-bit x86 CPU made by either Intel or AMD was from 2011, not including IoT processors. Not only was that waaay to late to ditch 32-bit, but the fact anybody is still making new hardware with those parts needs to stop. I'm don't even think VIA still makes 32-bit hardware.
As for the IoT processors, you wouldn't want to run Ubuntu on something like those anyway - too bloated.

[Weasel]

I hope some Ubuntu dev from that mailing list reads this here, because it's at a point where it's becoming a ridiculous situation. As usual, and just as I predicted, the lack of competence was obvious from a mile away. Please note that all of this is based on info from the ubuntu dev list that Michael posted a link to, so if you didn't read it I suggest you do so (if you don't know wtf I'm talking about).

Thing is this decision HAS NOTHING to do with HARDWARE. That is just an excuse, a cop out that works on the clueless masses. It's easier to say "but we can barely find hardware that can run this, so we can't test it!" as a reason for dropping it rather than "we don't like user choices, and we'd rather drop anything we don't like maintaining" or packages they don't "personally use" (hint: that **will** apply to packages they don't want to in the future).

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. So, what "old hardware inaccessibility" are we talking about here? Are you sure it's not just a red herring, really?


This time around, they got even MORE scapegoats out there, such as Meltdown. Splendid buffoonery. Now it's "i386 is not safe anymore due to meltdown, that's why we should drop it!", when again, they assume it's about HARDWARE, but it's **NOT** about hardware, don't even think about it.

Don't believe me? Remember how they were talking about this the first time? Mark Shutterworth promised "we won't drop i386 packages, just the images".

So why are they even TALKING or CONSIDERING such an idea of dropping i386 **PACKAGES** in the first place? Like, for real? Christ man, it hasn't even been TWO YEARS since he promised (LTS release cycle). This idea, by itself, is **COMPLETELY UNACCEPTABLE** and, once again, it has NOTHING to do with HARDWARE. So, stop LYING to the masses that it's i386 hardware that's hard to find, or whatever other bullshit you come up with.



Dropping the images is not a big deal IN THEORY, because you can always build a distro from packages yourself (easily in a container), with packages you want (i386). But this THEORY does not hold: once they get it in motion, they will START CONSIDERING dropping i386 packages -- again, pure software, which has NOTHING TO DO WITH HARDWARE. So what will the excuse be then? "We droppped images so we should drop packages too", see where I'm going? It gives them FUEL and a PRECEDENT, so it has to be stopped, because theory does not matter, only practice does. They're little weasels trying to play around words.

For example, there are **MANY** use cases for 32-bit userland, even if the kernel is 64-bit bit!!! Even a pure 32-bit userland, and especially in containers, like LXC, or VMs.

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.

Everyone knows that libraries are essential. But even non-libraries prove useful often. So, i386 packages are plenty useful even on 64-bit hardware. I want to install 32-bit userland in LXC, using my 64-bit kernel. It works, so why take it away from me? What argument is there? My PC is 2 years old. Hardware too old or what?

Repeat it after me 1000 times. i386 packages have nothing to do with i386 hardware. i386 packages have nothing to do with i386 hardware. i386 packages have nothing to do with i386 hardware. 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? Why is dropping packages EVEN CONSIDERED in the first place? *ESPECIALLY* so for libraries. Dropping normal packages is bad enough, but dropping LIBRARIES is absolutely UNACCEPTABLE and anyone who even CONSIDERED it should be fired on the spot. (NOTE: when I mean "drop", I don't mean "not part of default installation". Not bundling it by default is fine -- but dropping it as not giving the user an option to just install it from the repository, is disgracefully UNACCEPTABLE).

It should NEVER, EVER come to fruition. And sadly, dropping the images will make that thing that should never come closer to actually become a reality. Which is why dropping images by itself is bad, even if in theory it's not, because you can put yourself together a distro from the packages. But it's just 1 step closer to dropping the packages themselves (and perhaps, further, even alternative packages they dislike).

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.

[Weasel]

BTW this second post is for the people on Phoronix now (previous one was for ubuntu devs, mostly).

You guys talk about user choices, freedom, when talking about the good things of Linux.

You guys talk how the popularity of Windows (see my previous static linking example, which is prevalent in Windows apps) does not matter, Linux is much superior for freedom of control and decisions and such. (I agree)

But you guys talk how popularity suddenly matters when it comes to i386 Linux users? Is it because, this time, you're in the majority? Is that why it matter this time, but for a Windows user, popularity is not an argument to use against you (the Linux user)?

Stop being such hypocrites.

Linux is a choice, an unpopular one sadly, but so is using i386 on it, and your arrogance isn't any different than a Windows user.

If you keep talking down on people's choices who prefer to use i386 Linux for their own reasons (less memory use, development in containers, old apps, less footprint on disk (can be very useful when you have tens of containers)), then think about how you're acting just like a Windows user who thinks he knows best.

Just because this time you're in the majority of this group does not make you right.