Slackware 14.2 is still available as 32bit; I, for one, am not worried that my middle aged to elderly laptop and printer are going to outlast 14.2 support.

64Bit only is just a matter of time. At the moment I couldn't easily get by without multilib on my other PCs, but, as you say, when there's no need why bother?

1 members found this post helpful.

I've noticed on my personal machines that it seems like the only programs I look at that requires multilib are closed source binaries, and in my case, it is all games. I actually haven't installed multilib on my desktop yet, but the only thing that I can't do that I've wanted to is run steam.

If steam were to push for a 64bit client and make it readily known if a game is 32bit or 64bit, it would go a long way to minimize the need of some to use 32bit or multilib. Depending on what games are 32bit only, I may not even feel a need to install them rather than going multilib.

2 members found this post helpful.

Wine is the other one, at least for me. Funny that even on Linux, Windows still manages to hold us back.

3 members found this post helpful.

For me its pcsx2, I suppose they might actually finish their 64-bit port before Slackware drops 32-bit support...

1 members found this post helpful.

Now if everything in Steam can come together so it's only a 64bit app, without the need for multilib to use Steam, that would be nice.

Why not run Wine in a virtual machine that's 32 bit? (If it's a game, then that's all you have to say. Anything else should work well enough to not have to mess around with multilib.)

If you mean Virtualbox, it itself needs multilib to enable software virtualization for 32 bit guests.

fact is that the world says, if you need to run 32bit apps, use multilib.
Slackware does not include multilib today, I see this as a problem.
I do not think that the 3rd party solution is a solution, I see it more as a hack to fix something that is broken.

The world will continue to produce 32bit apps, those who do not need more than 4gb virtual address space work wonderful and faster as 32 bit apps, so in this sense 32 will not disappear, but 32 bit architecture as the main platform will, on x86 cpus.

I have one practical usage of Slackware left, beside just having it at home for fun.
For 90% of these videos, the presentation computer was a Slackware 14.2 notebook.
To continue to use Slackware for this purpose I need to know if Slackware is planning to add a fully functional compiler suite, if not, I will change to a distro that does provide it for the presentations.
Slackware is not my hobby, it is a tool I use. I try, and actually do, advocate for it and contribute back what is possible, but if it adds to much time burden, or requires me to hack it with 3rd party stuff to have basic functionality, than I will also have to step away from using it for the presentations.

1 members found this post helpful.

On my 64bit host without multilib, i run a 32bit lxc container to be able to run wine to use a tax app only available as closedsource 32bit, it works fine. No experience with gaming/steam-client.

I think it would be a good thing if Pat would not have the time consuming burden to provide 32bit slackware in the future. The community may help to provide a 32bit port, maybe fullblown(kde?) is unneeded if the main target is (just) a 32bit container.


Johannes

This is true. Either that, or run 32bit, but most systems will see a benefit of running a 64bit OS, so multilib is still important.

But this "hack" is becoming less and less needed. Of the 6868 scripts on SBo for 14.2, only 99 of them are limited to either 32bit or 64bit. Out of those 99, 39 don't work on 64bit machines (39%), while 60 don't work on 32bit machines (61%). If we look at 14.1 (5743 scripts), 54 scripts are unsupported on 64bit (81%), while only 13 are unsupported on 32bit (19%). If we go to 14.0 (3827 scripts), only 1 script doesn't work on 32bit (2%) while 49 won't work on 64bit (98%).

If anything, I would imagine Eric would be less and less likely to stop providing multilib (not that I'm suggesting this is on the horizon). But if Slackware didn't come with multilib when the majority of software that was tied to a specific architecture was tied to 32bit, it is unlikely that it would do it now that the tables are flipping and it is more likely software won't support 32bit distros (and it's more likely that users can get by on a pure 64bit distro). Plus, it seems like most uses cases requiring multilib are due to gaming, which is probably not a huge chunk of Slackware's users (although, I'd certainly be interested in data showing what the percentage actually is).

And if distros keep catering to 32bit software, there's no incentive to get away from it.

So nice words!

Oh, by "the community" you understand: Eric Hameleers? Then, in this case be kind to note that "the community" said clear that the maintaining of a 32-bit port is excluded, no far than in this very thread.

Be careful what you wish!

Contrary, Mr. Watson! Facts in the real World says: you should use a 32-bit operating system for running 32-bit apps.

Even in the "multilib" case, you run a (distinct) 32-bit operating system on top of a (common) 64-bit kernel.

And remember that that "multilib" is just the Slackware i586 adapted by Eric to be installed in the same partition with a x86_64 base one.

NO Slackware i586 === NO Multilib

According with the maintainers, not with me.

Thanks for the clarification. That we'd end up getting stuck with the /lib, /lib64 split long-term was the reason I always preferred the alternative /lib, /lib32 approach to multilib, though I understand the reasons why you went the way you did.

one more time, the no change required fraction shows only fundamental lack of knowledge, interesting to see you this time on this side of the fence.

OF course there are distributions where no i586 port exists, and they ship multilib. That Erics solution is a hack is something I mentioned.

For several years, I was myself maintainer of a Slackware-based distribution, which was basically a port to i586 when the Slackware was i486.

Hence, I was able to see myself the amount of work and complexity required to maintain a Slackware-like distribution.

According with my experience, I see today only one guy able to do a 32-bit port excluding our BDFL: Eric Hameleers, and he said nope.

OK, there is also our good British Doctor, but he looks totally uninterested by anything which does not wear the noble ARM inheritance.

The rest of "the community" either has no required knowledge, either has no enough resources or time to dedicate for this project.

With all respect, what Eric do is not a hack. This way do precisely everyone and it is the single way.

For example, for Qt, you need to build libraries for x86_64 and i586. Maybe the resource files are common.

Facts are, if Patrick will put down the i586 releases, but he will still ship 32-bit support, his volume of work is the same as shipping apart the i586 releases. That was said clear also by Eric, right in this thread.

With a caveat: guys like @LuckyCyborg cannot use the latest Slackware anymore.

BTW, blame Intel which treated the 64 bit support as a premium feature, and the commercial politics of those who sell hardware, but in many parts of the World you can still buy 32-bit hardware as brand new.

---------------------------------------------------
Practical example, to demonstrate that those who show us their Ryzens like tuned trucks does not represents The Real World. Or, at least not the entire World.

https://www.emag.ro/placa-video-sapp...IMILAR-1k3vwv8

Yup, even in a "illuminated" place like where I live, where I have that nation-wide 1Gbps Internet and 50GB monthly on phone, the typical guy buy for a home/office computer something like a brand new Radeon HD6450, which the enlightened minds from AMD declared it obsolete from long long long time ago.

PS. the Romanians arrived to have a meme: "he show us his Ryzen", referring to something similar with someone who go shopping with a truck like one from screenshot.

Attached Thumbnails

 

1 members found this post helpful.