openSUSE Is Still Looking For Users To Step Up And Maintain 32-bit x86 Support

[debrouxl]

Can you actually post workloads like linux compile times on boinc ?

That's a conceptually interesting idea.
Technically, chances are that one could:
* instrument a build system + toolchain + set of headers to call the BOINC API at select places for providing progress information, poking the watchdog, etc.
* package the aforementioned components as a BOINC application, hopefully in a modular way;
* sign and package source code bases as BOINC Work Units.

Of course, some important matters, such as trustworthiness of built binaries, and ensuring that there's a sufficient quorum of computers not controlled by the same group of potentially malicious actors running the WUs, would have to be tackled beforehand Otherwise it's complexity for little benefit.

However, IIUC, the bottleneck does not lie in build automation for 32-bit x86 packages, or computing power to perform them; it's more a matter of finding humans able and willing to spending time importing new releases into the build system, adjusting the packaging for the new releases, fixing the code or build steps when something breaks on a 32-bit architecture, testing the resulting packages, etc. - despite fewer and fewer computers and their human rulers benefiting from said work, as time passes by.
From the POV of an unpaid maintainer working on one's free time, there must be some things which have higher impact for real-world users than attempting to help maintain large sets of 32-bit packages, "large" here meaning "larger than somewhat beyond the set of packages needed by 32-bit x86 Linux / Windows games and game platforms".

[skeevy420]

Devil's Advocate: That's to be expected. It makes more sense to buy current and supported hardware that has software support for a known amount of time than it is to pay someone to maintain software for an unknown amount of time on hardware that's becoming harder to find. If you're going to pay someone to develop or maintain software then you'd pay them to upgrade or rewrite whatever it is you depend on to work on current, preferably long term supported, hardware.

Also, in some ways it is kind of like Wal-Mart going, "OK. So we're going to need some volunteers to stock produce for now on. Grab some veggies on your way in and put them on a shelf before you go shopping for or we're just not going to have the Produce Department any more." It makes me wonder what they were paying to keep an entire hardware architecture supported up until now and if it isn't at least worth considering offering some low ball positions that are geared for retired or poor developers that want something to do but either don't want the responsibilities or have the financial means of maintaining a company's software stack for free or out of pocket.

[elbar]

To Bee or Not to Beep

[Charlie68]

I had a pc that only supported 32bit, after trying some distributions (including Debian and Tumbleweed) that still support it, I couldn't help but notice that many applications don't support 32bit, often there are problems and bugs that There are no 64bits, in the end I chose to take the notebook to the landfill. Being on 32bit gave the feeling of staying in a house that has to be torn down any day. So if there's no one willing to do the dirty work it's okay to archive this architecture, I'm sure other distributions will follow, because that's a natural end.

[elbar]

I couldn't help but notice that many applications don't support 32bit

Some apps think that assembler is the best way to do, but translation between langs(and even when there is no source should be Trial of Destiny for such TNG:Encounter at Farpoint ... And when there is some work problems, something Problem Associate it is... Or the Force be With You... Forever

[kpedersen]

I couldn't help but notice that many applications don't support 32bit,

I am sure that as a Linux user, you are familiar with the concept of finding an alternative that *does* work on your platform?

[erniv2]

Some apps think that assembler is the best way to do, but translation between langs(and even when there is no source should be Trial of Destiny for such TNG:Encounter at Farpoint ... And when there is some work problems, something Problem Associate it is... Or the Force be With You... Forever

You can have the 32bit compat packages compiled with x86-64-v2 anyway then you can run steam and they basically provide the same stuff but access registers that old hardware simply does not provide so it fails.

Example windows 11 is compiled for new cpu´s and surprise it runs wow64 and steam 32bit..........

And this homebrew assembly code thing is actually a thing of the past back when you had MMX registers and needed to tune your memcopy speed it was a thing even the linux kernel used such ugly things, but nowdays allmost all should just be C functions, stupid macros and asm stuff gets cleaned up all the time.

[Svyatko]

Some code requires SSE2 (Mesa 3D, Firefox, etc.), Chrome/Chromiums requires SSE3: https://forums.opensuse.org/t/who-ne...support/151252
AFAIK Tumbleweed i586 uses SSE. So, maintainers need to patch code.
Without these patches: there are too few ia-32 CPUs which support SSE2, but don't support x86-64 - that means very small market.

BTW: Tumbleweed developers reverted its decision to upgrade from x86-64 to x86-64-v2:

https://lists.opensuse.org/archives/...GMA77WVTCHHEQ/

## openSUSE Tumbleweed x86_64 stays at baseline ##
+ We will push on finding a better solution than moving the entire distro to any other architecture level. We're currently collecting ideas/proposals/solutions at https://en.opensuse.org/openSUSE:X86...tecture-Levels. It's even very likely that we come up with a plan of using combinations (of e.g hwcaps plus a 2nd baseline repo)

## openSUSE Tumbleweed i586 downgraded to a port ##
The i586 architecture keeps moving to openSUSE:Factory:LegacyX86 (the name still matches luckily). The repository will be published at https://download.opensuse.org/ports/...weed/repo/oss/. The usercount there is non-zero, but certainly not as large as the x86_64 userbase.

[stormcrow]

Ultimately the reason I eventually got rid of my old 32 bit Dell PowerEdge is the amount of electricity it takes to run it versus a modern, or even a 10 year old system, is significantly higher. These systems are no longer efficient for active use. For example, that old PowerEdge Pentium 4 based system the CPU by itself runs at 95 Watts whether it's idle or active. The people still using these systems are very unlikely to be running anything recent on them. So all this legacy stuff is less that there are systems still around that needs x86 native software, and more that vendors like Steam are dragging their feet on updating their software despite AMD64 systems dominating the desktop and server market for well over a decade.

There's no reason that a modern PC can't be used to compile these systems, since until recently, BIOS compatibility is still in UEFI firmware which means that these systems can still even boot MSDOS, so they can natively boot a 32bit system and still natively run most software since the 386 (assuming the software doesn't depend on timing issues). I'm not saying that this should be done, merely that it can be done... but frankly I think it's past time to be bending over for a multi-billion dollar company (Valve) that refuses to update its software frameworks, especially when they specifically turned to Linux to hedge their bets against Microsoft market dominance. Linux doesn't need Steam. Steam needs Linux (for their in-house game systems).

I k now that'll leave a lot of proprietary games behind, but anyone using Linux can figure out how to get these games to run on a native system as opposed to indefinitely holding back the rest of the software ecosystem to support Steam's laziness.

[erniv2]

Ultimately the reason I eventually got rid of my old 32 bit Dell PowerEdge is the amount of electricity it takes to run it versus a modern, or even a 10 year old system, is significantly higher. These systems are no longer efficient for active use. For example, that old PowerEdge Pentium 4 based system the CPU by itself runs at 95 Watts whether it's idle or active. The people still using these systems are very unlikely to be running anything recent on them. So all this legacy stuff is less that there are systems still around that needs x86 native software, and more that vendors like Steam are dragging their feet on updating their software despite AMD64 systems dominating the desktop and server market for well over a decade.

There's no reason that a modern PC can't be used to compile these systems, since until recently, BIOS compatibility is still in UEFI firmware which means that these systems can still even boot MSDOS, so they can natively boot a 32bit system and still natively run most software since the 386 (assuming the software doesn't depend on timing issues). I'm not saying that this should be done, merely that it can be done... but frankly I think it's past time to be bending over for a multi-billion dollar company (Valve) that refuses to update its software frameworks, especially when they specifically turned to Linux to hedge their bets against Microsoft market dominance. Linux doesn't need Steam. Steam needs Linux (for their in-house game systems).

I k now that'll leave a lot of proprietary games behind, but anyone using Linux can figure out how to get these games to run on a native system as opposed to indefinitely holding back the rest of the software ecosystem to support Steam's laziness.

To the steam thing it´s not realy their fault that steam still has a 32bit launcher it´s the game industries fault, cause games still use 32 bit code, and cause anti cheat engines still use 32 bit code.

I remember SWTOR omfg i was so fucking angry that it was 32bit, you had a render process that used up 2048mb, then you had a game engine process that used another 1-2gb, and then you had a coordinating process that used another 200-500 mb, just to bring together what you see on the screen what you input and what your char does.

Why was it so complicated ? because it was 32bit in a time when 4-8gb ram where already a thing, they had to work with the 32bit boundary of 2gb userspace and just the amount of textures for the planets used 2gb, and the complexity of the gameplay hitboxes weapon swings and whatever used another chunk of ram and then the third process was needed to actually move your char on the screen, if i think about it it makes me blow my top BOOM.